artvvb

Hi @artvvb
I followed your instruction and changed the memory size of Microblaze to 128k by adding a new Microblaze IP in Block Design and I got the result that I expected. You can see the picture below.
Thank you very much for helping me do my work ! 
 Bach

No need for any of it - you can simply change the address range in the address editor, and Vivado will figure out the rest by itself:

If you have separate instruction and data buses (like it's shown in the screenshot), you will need to change it in both places.

Hi @Bach
Local memory size is set when you run Block Automation to build out the system around the Microblaze processor in Vivado - you can't change local memory size from Vitis as the amount of BRAM dedicated to it is part of the hardware design. The easiest way to increase it is often to go back to Vivado, strip out Microblaze and many of the core blocks that come with it, add a Microblaze IP back into the design, and rerun Block Automation picking the largest local memory available (likely 64k). If you need more than 64k of memory and your board has DDR, you should use it (again, by modifying the hardware design).
Alternatively, reduce the amount of memory used by your software app - common libraries for C/C++, even stdio, can be too large for a system with very little memory.
Thanks,
Arthur

For interrupts, there might be a way to work around it by making sure that zmodlib and the constructors for its classes either don't reinitialize the xscugic driver, or to make sure the constructors get called before the ethernet code initializes the driver. A quick way to check it would be to comment out or remove code from the functions in Zmod/baremetal/intc.c (assuming you're using baremetal).
XStatus fnInitInterruptController(XScuGic *psIntc) { return XST_SUCCESS; } void fnEnableInterrupts(XScuGic *psIntc, const ivt_t *prgsIvt, unsigned int csIVectors) { return; } This would prevent zmodlib from reinitializing the interrupt controller and from registering any interrupts - which also means no interrupts that zmodlib uses would work anymore and you'd have to rely on the Polling acquisition functions. I'm not 100% sure whether there are other interrupts in zmodlib that are still used when using Polling functions, but I don't think so.
That said, either a substantial rewrite of the ethernet code (so that it uses zmodlib's intc API) or a rewrite of the zmodlib source so that it can be told to not reinitialize the interrupt controller would probably be the better long-term solution.
Hope this helps,
Arthur

ZMODADC1410_REG_ADDR_TRIG is an offset - there should be a corresponding BASEADDR (base address) macro in the "xparameters.h" file, add the offset to the base address, rather than just using the offset. In the screenshot in my previous comment, you can see the addresses are coming from "XPAR_AXI_DMA_0_BASEADDR + * + XAXIDMA_*_OFFSET". Ignore the middle value, it's specific to the DMA IP and doesn't apply to the Zmod ADC controller. You should have something like "XPAR_(Zmod ADC controller name)_BASEADDR + ZMODADC1410_REG_ADDR_TRIG".
I apologize if that's not super clear - if you have the Vivado project, you can also see where base addresses are assigned for different peripherals in the Address Editor, something like this is usually in the 0x40000000+ range (that DMA core in the screenshot is at address 0x40400000). You can also get this info in the hardware platform SPR file, though the xparameters.h header is where to get it for the code itself.

Got it makes sense. Thanks for your help. 

Got it!!!!
 
Thank you so much....

Hi @Mamatchai
Edit: There's no specific zmodlib API function for reading back the trigger value after it's written, you'd need to store data in the application calling setTrigger or one of the acquire functions. The rest of this comment is about how to work around this.
So these tips are mainly for baremetal. Linux user space virtual addresses probably complicate things, and could require modifications to zmodlib sources. A screenshot showing each is attached.
You can view values stored in memory-mapped registers in the debugger - though this feature has had a bug in some versions of Vitis where only the lowest byte of each word can be viewed (this can be seen in the screenshot).
You can also use a debugger expression to determine the value of the register at a particular point in the code, by dereferencing its address. Note that the debugger may not have access to macros coming in from headers like xparameters for this, so you may need to declare the pointer in the code.
If you're trying to modify the code to read the register value and then use it for something, you can use the above method of dereferencing a pointer that has been set to the register address.
Hope this helps,
Arthur

Hi @jcorleto
1,2,3,4: yes
These are application features available with any supported device.

Hey Julii,
Are you using Eclypse and Zmods or some other Zynq + ADC setup? The rest of my comments below assume Eclypse along with the IP cores provided for it that handle the ADC interface.
If you're looking for the ADC configuration portion of this, the low-level low-pass filter demo might be helpful: https://digilent.com/reference/programmable-logic/eclypse-z7/demos/low-level-low-pass-filter. The ZmodScopeController IP used in the demo is specifically targetted to the Eclypse and the Zmod products that support it, but its architecture might be relevant for implementing a similar controller for another ADC and board - depending on the vendor of your parts, you may find similar controllers and examples provided by them.
For designing the HLS module, Digilent doesn't have much if any material for it on the web. I'd recommend starting out by finding a passthrough example that you can work from and modifying it to suit your needs. This might be suitable (and the rest of UG1399 is also relevant): https://docs.xilinx.com/r/2023.1-English/ug1399-vitis-hls/AXI4-Stream-Interfaces-without-Side-Channels.
How data is packed in the source AXI stream interface is also extremely relevant. For example, for the ZmodScopeController, the data format is defined in the IP Top Level Port Description table of the user guide on page 21 (particularly cDataAxisTdata), and in the ADC Calibration section, pages 7-9: https://github.com/Digilent/vivado-library/blob/master/ip/Zmods/ZmodScopeController/docs/ZmodScopeController.pdf.
Thanks,
Arthur

Hi @CEEJ38, welcome to the forums.
There are two versions of the Zedboard board files, one from Avnet and one from Digilent. Please make sure you are using the Digilent version as the Avnet version does not include Pmod interfaces - installation instructions can be found here: https://digilent.com/reference/programmable-logic/guides/installing-vivado-and-vitis#install_digilent_s_board_files.
Alternatively, you can manually constrain your Pmod ports instead of relying on the board files. The "Add GPIO Peripherals to a Block Design" section of this guide discusses how to do this, in the context of some button inputs: https://digilent.com/reference/programmable-logic/guides/getting-started-with-ipi#add_gpio_peripherals_to_a_block_design. I would recommend this approach over the board files for this kind of I/O interface, as the board files and IP presets can obscure some important details of what is going on that are better to learn sooner rather than later (I/O constraints, configuring IP as necessary for the peripherals you're talking to, etc).
Thanks,
Arthur

Could you share the rgb_gen source and IP configuration settings?
Looking at the block design, please check your reset polarity. The "locked" outputs from the clocking wizard IPs are active high - when high, they indicate that the clocks are working. It looks like rgb2dvi and your rgb_gen module are working, but the data path through dvi2rgb may not be. Both dvi2rgb and rgb2dvi have active high resets by default, which are used in your design.
What Digilent provides to test and debug the core is described in the "Debugging" section of the dvi2rgb IP core user guide, there are some internal logic analyzers that can be optionally instantiated and used to check signals while a board is programmed, but no simulation sources are provided (though you can still create testbenches yourself, as you are doing). Based on its datasheet, rgb2dvi doesn't have similar debugging logic.

Hi @Julii
The following describes a minimal PL -> PS transfer example. Code was tested on an Eclypse in Vivado/Vitis 2023.1. An AXI stream counter module is used to generate stimulus for the DMA's AXIS_S2MM port and Verilog source code for it is attached. It has a couple of control signals - when start is asserted, it asserts tvalid and counts whenever tready is asserted until it reaches a software-specified limit, at which point it asserts tlast, sends a final beat, and pauses until start is sent again. AXI GPIOs are used to hit the counter's control ports from software.

Source code:
axis_counter.v
The DMA was configured as follows. Scatter Gather was turned off, the width of buffer length was maximized, and the read channel was disabled. Width of buffer length is an important parameter, as it defines the maximum number of bytes that can be sent in a single transfer (2**26 in this case). I didn't touch "allow unaligned transfers" but it would be helpful if you're working with u8 arrays, as it allows the software to be more flexible in where DDR buffers are located.
\
The Zynq PS had the HP0 port enabled so that the DMA could use it to push data to DDR.
For software, registers are directly accessed via pointers that are pointed at the corresponding addresses, to showcase how to avoid using the xaxidma and xgpio drivers. It follows the process outlined in the Programming Sequence -> Direct Register Mode section of the DMA product guide: https://docs.xilinx.com/r/en-US/pg021_axi_dma/Direct-Register-Mode-Simple-DMA. The software sets the Runstop bit in the DMA's S2MM control register, sets the destination address and buffer length, then configures the AXI stream counter and starts it. Once the S2MM status register's Idle bit returns to "1", it invalidates the cache and verifies that data has been successfully transferred.
main.c
This system accounts for several potential stumbling blocks:
1. The DMA S2MM interface's tready bit cannot be relied on to prevent data from flowing into the DMA before software initiates a transfer. It comes up as soon as the DMA comes out of reset. This means it's important to manually start upstream IP after setting up the S2MM transfer.
2. The module upstream of the DMA must assert tlast at the right time. If tlast is not asserted before the buffer that the DMA is pointing at would overflow, the DMA will lock up and needs to be manually reset to continue being used.
3. If the PS cache is enabled, data you're trying to write or access from software may not be the same as that seen by hardware. Manually flushing and invalidating relevant ranges of addresses ensures that the two are in sync.
4. Lastly, pay attention to where your buffers are placed in memory. If the memory segment they're placed in is not located in DDR, the DMA may not be able to access them. If the memory segment is too small, you may see issues like stack overflows.
Hope this helps,
Arthur

Hi @Ppspendse
Digilent doesn't provide example simulation sources for this core. If you haven't, please refer to the user guide: https://github.com/Digilent/vivado-library/blob/master/ip/dvi2rgb/docs/dvi2rgb.pdf. Sections on clock recovery and designing with the core should be helpful. Several other documents it references, including DDWG's DVI spec, may also help.
Thanks,
Arthur

The Arty A7 board file comes with the configuration for MIG.
For instructions on setting up the MIG on Arty A7, you can refer to the first chapter of this tutorial. The tutorial is focused on MicroBlaze; nevertheless, setting up the MIG is the same for both MicroBlaze and PL logic.

The problem was with the type of USB cable. Thank you @artvvb !

Hi @SGdigi, welcome to the forums.
The localhost connected in the hardware list means that the hardware server is up and running but it can't find your device.
There are a couple of possibilities.
1. Please try using an alternate USB cable - some charging cables are not capable of transferring data. If you are using a cable that came with the board, it should be okay.
2. Drivers may not be installed correctly: Assuming you are using Windows - if not, please let me know what OS you are using - please use the Device Manager to check whether cable drivers are installed. You should see two USB serial converters as in this comment:
If the device doesn't show up correctly, you should attempt to install the drivers either by installing Adept from this page - https://digilent.com/reference/software/adept/start - or by rerunning the Vivado installer from the Tools -> Add Design Tools or Devices menu option, as there's a checkbox on one of the screens that installs drivers (documented in this guide - https://digilent.com/reference/programmable-logic/guides/installing-vivado-and-vitis).
3. If neither of the above works, the programming circuitry on your board may be damaged, in which case you may need to pursue an RMA.
Thanks,
Arthur
 

A month ago I got everything to work and then the exam weeks came around, so I forgot to inform you. Thank you for your help. It is much apprechiated. 

Hi,
I've tried to rebuild all my application using 2023.1 tools and boot image works fine. 
Thanks
Davide

Thank you all for the help.
The problem was in one of the two drivers (the bus one) and in the working policy of the notebook that made it not working .Finally, it worked with these drivers https://digilent.com/reference/software/adept/start?_ga=2.225815646.578235468.1707132485-1962113075.1645638136 .
Hope it will help others in future

Hi Kishore,
My colleague @artvvb loaded image 0.3 onto an SD card, booted the Eclypse Z7 without anything plugged into Zmod A or B, and confirmed that he was able to set the voltage to 1.8V and then 3.3V using the decutil setviocfg command. He measured voltages of 1.821V and 3.327V. Please download the v0.3 image here and then follow Step 2 of the "Setting up the Linux Projects" section described here to get our petalinux image up and running. Once you've booted please execute "sudo decutil setviocfg -chanid a -override y -enable y -voltage 1800" to set enable VADJA and set the voltage to 1.8V. If you want to do the same for VAJDB then you can execute "sudo decutil setviocfg -chanid b -override y -enable y -voltage 1800".
Please let me know if this works, and again, make sure you have no boards or cables connected to ZMOD A or ZMOD B.
Thanks,
Michael

Hi!
In a project of mine, I want to use this 3.5″ 480x320 TFT SPI display based on the ILI9488 display controller. 
I, therefore, ported the ILI9488 Arduino library for use on AMD Xilinx SoC and FPGA. The integral part was porting of the Adafruit_GFX library because the ILI9488 library is based on it. I removed all Arduino-specific code, optimized SPI writes for the capabilities of Xilinx SPI libraries, and made other modifications.
I published the library and sample projects on the GitHub repository.
You can see the capabilities of the library in this video.
I tested the library on AMD Xilinx Zynq-7000 SoC and Artix-7 FPGA (running on MicroBlaze soft CPU).
The repository contains sample projects that run on Digilent boards Zybo Z7, Arty A7 and Cmod A7.
I also provided a detailed step-by-step tutorial on how to use the display on the Zynq board Cora Z7.
The library supports both Zynq Processing System SPI and AXI Quad SPI IP.
The library also supports both Zynq Processing System EMIO GPIO and AXI GPIO IP.
Different kinds of SPI and GPIO can be combined (e.g., you can use AXI SPI with PS GPIO and vice versa). All four combinations are supported by the library. Three out of four combinations are showcased by the sample projects in the repository.
I tested the ILI9488 library with a standalone application running on ARM core or MicroBlaze. I believe it should also work on a PetaLinux app.
Viktor

The female host Pmod connector on the Basys 3 (and other Digilent products) is a Sullins PPTC062LJBN-RC, with 100 mil pitch between each of the pins.
Thanks,
JColvin

Hey Sven,
The adapter won't come with them, but there are various banana plug to X connector adapters that can be sourced from other vendors online that should work, see below for an example of USB (note that I have not tried this particular product).
Max current is listed in the specs in the reference manual (https://digilent.com/reference/test-and-measurement/current-and-power-adapter/reference-manual), there are a couple of different range selections, but the widest is up to 25 A.
Thanks,
Arthur

@artvvb, 
Thanks for the help, 
 I just cheated and copied the bit file it was complaining about into the directory.  It actually ran, while that is good I'll follow your directions and try to clean it all up.  Glad that my setup isn't necessarily bad with the Win10, though it seems I"m able to find every way to mess things up.  
Thanks again.