Xband

I think "X" for a value in a bus means "don't care", so it will trigger on anything, meaning that run trigger and run trigger immediate are effectively doing the same thing - which is a long way of saying that yes, the channel might not have time to start before data is captured from it. Try something like this, valid and ready are only both high when data is moving:

Hey XBand,
How are you starting the ILA, using Run Trigger Immediate? Setting up a trigger should let you narrow in on only when interesting events are happening, by doing something like triggering on a read address channel tvalid signal being high at the same time as the corresponding tready signal. Pairing ILAs with the Vitis debugger can also be helpful, so that you can manually step through code and precisely control what state the hardware and software are in when you run the ILA. If a trigger set up to trigger on valid and ready for some channel never fires, it means that that stream isn't being used at all.
The screenshot below shows a trigger setup. It's not a meaningful one in this case, just a project I happened to have open, but hopefully helps for seeing the UI. In the trigger setup pane, the plus button adds signals to the trigger. The "And gate" icon shows that everything in the list below must be true for a trigger to occur. In this case, a trigger occurs when the pLockLostRst signal is high, and the dbg_pBitslip bus matches "3" (3'b011). The Settings pane gives a little bit more info - the trigger position in window field specifies where in the chart the trigger condition will be displayed; changing it lets you see more data in front of or behind the trigger condition. The window data depth shows how many clock cycles the ILA is capturing.

The ILA should always be driven by the clock associated with the AXI stream interface, and I'd expect to see build errors when that isn't the case.
Thanks,
Arthur

These settings are for the application project rather than the system project, as it's the part that holds the actual C sources - the system project is a wrapper that can have multiple applications in it, like multiple baremetal applications for multiple processor cores, for example. See the selected stuff below. The Assistant identifies what type of project each of them is, but the properties are only accessible through the Explorer pane.
 

Hey, sorry for the delay.
Unfortunately, whenever I've seen invalid xpfm files, I've needed to recreate a workspace... Speculating, but it's possible that copying or moving a workspace directory from one place on your system to another could cause it.
It's great that the hardware project is working!
Thanks,
Arthur

Mamatchai, I'll need a bit of time to reproduce and double-check whether there are other important interrupts.
Addresses for PL IP are different per project, they're assigned in the address editor in Vivado. You can either let Vivado automatically assign them (the default behavior) or manually set them. Either way, the address map is exported with the XSA file after generating a bitstream, along with various additional information about the hardware design (this is also how IP configuration information makes its way into the files used by *_LookupConfig functions). Including the xparameters file in your code and using the macros it defines is recommended in case the peripheral addresses are changed in Vivado.

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.

@artvvb, 
Moving that definition fixed it on my side too, thanks for a small win here and great instructions getting through the process.  I found this quite valuable as a training intro to the ILA process.  Cant say I would have successfully debugged and found the problem but its a good step in the process!
Glossed over the bit about triggering the acquisition twice and seeing the difference in the buffer.  My success was getting all of your steps to line up and work.  Spent 2 days messing around after trying to address a buffer overflow diagnosis from the AMD help site, finally restored the settings and things worked after rebooting the machine.  This platform seems to have an infinite number of issues to deal with.  
 
Thanks again for the help!

@artvvb, 
thanks for putting this together.  I'll need some time to absorb all that is going on, its a great tutorial.   

Running through the debugging process:
Using a 20-word (80-byte) transfer for the sake of being able to see things on screen. Below is the input stream going into the DMA. You can see that it counts from 0 to 19, and on that 19 (the 20th word), tlast is asserted. If an issue with the counter module was causing the first two words to be corrupted, I'd expect to see it here, but everything looks as expected. - If the DMA worked perfectly, but the counter provided data to it that didn't match what I expected, then the data seen in software would also be wrong, not the case here, since we see the expected 0, 1, 2, 3, ...

Below is the output of the DMA, the AXI master interface that writes to DDR. The DMA takes the input stream, breaks it up into bursts, and sends data to DDR by first writing an address and then the data - here you can see the first ten bytes are transferred in one burst, starting with address 0x2062d8. After the DMA transfer is complete, the processor will be able to access that memory and see the new data. Again, if there was an issue with the DMA or the counter, I'd expect to see it here, potentially by seeing a value other than 0 or 1 on the WDATA bus at the start of the transfer.

Now in the Vitis debugger, this is where we can actually see the bug. I can look at the data in DDR after the transfer by setting a breakpoint after the Xil_DCacheInvalidateRange call, and using the "Memory" view to monitor the address that the buffer is pointing at. In this case, I have two breakpoints set. One at the start of the do_transfer function, so that I can check the buffer address in the "Variables" view. I take that buffer address and add it to the memory view, which shows me that the data is set up as expected - in the code pictured, I'm zeroing everything other than the first word to make sure that the expected value after DMA is different from the known value before the transfer.

Hitting continue to go to the next breakpoint, we can see that everything except for the first two words is updated correctly - the red delta indicates that there's a difference in the value at that memory address since the last time the processor was halted:

This is then checked by the program and the pass/fail is printed to console, in this case a fail since the first two words don't match the expectation.

So, the issue doesn't seem to be with the hardware, at least up to the DMA output. Either the first two words aren't being written by the DMA transfer at all, or they are overwritten behind the scenes after the transfer is completed (overwritten specifically back to the original state).
Moving the buffer declaration out of the do_transfer function so that it's a global variable seems to consistently fix it (it puts the buffer at a different place in memory). That said, I'm still not sure what exactly is going on. I tried increasing both the stack and heap sizes in lscript.ld to 0x200000, which didn't help. I also tried checking the "allow unaligned transfers" box in the DMA settings, since alignment can also matter, which also didn't help.

Hopefully my thought process is relatively clear.

Ugh, I'm really sorry, there's a bug I didn't catch... The hardware design seems to be fine but the second word in the buffer is getting overwritten at some point, possibly due to insufficient memory in the stack/heap, memory alignment, or some pointer issue. Taking a look.
I also likely should have started a new thread when posting the example code, rather than replying into this one.

@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.  

Looking into it. The calibration reader app expects the names to be "Zmod ADC 1410-105" and "Zmod DAC 1411-125", based on the original names of the products before a rebrand. The EEPROM contents that store the product model name must have been changed. Changing lines 23:27 and 53:57 of main.c in the calibration_reader app as follows should clear the issue, using this as the point of comparison if you've made any changes: https://github.com/Digilent/Eclypse-Z7-SW/blob/ddr-streaming/src/calibration_reader/src/main.c.
Thanks,
Arthur

@artvvb
I have the hardware design loaded and a software SOC testing now.  Exciting progress!  Getting an XAXIDMA_Device_To_DMA transfer length failure now!  Progress!
Thanks for your continuing support, sorry to have two separate threads on my issues going.

Posted a project  and some constraints over here: 
 
Just means that you are trying to use the same location constraint for two different pins - more incorrect constraints. sADC_Sclk_1 should probably be at AA13.

Hi @Xband
The AXI port names in the list of unplaced ports make me think that you have the wrong top module. Please make sure that the block design HDL wrapper is set as the top module for your project in the sources pane. It should be bolded, like here:

You can change which module is selected as the top module by right-clicking on the one you want and selecting "Set as Top".
Thanks,
Arthur

Please review your HDL wrapper module, and confirm that all port names in XDCs match names in the wrapper. The issue with the github source that you linked is that it is intended to be used with a script that reproduces part of a block design, which also finds and replaces all of the "nameHier" text in the XDC. It then has the correct names of ports, since it creates the ports in a known way, as long as ports aren't manually renamed later.

Thanks,
Arthur

@artvvb
I think the problem my have popped up because I started the project first adding the Zynq processor and other parts, running the connection automation along the way, then later I added the "clock wizard" ip.  Could have been the root of the issue.  I went back and rebuilt the project again and seem to have avoided this problem so far.  Thanks again for your help.

Also, a tangentially related issue I've run into before, the default "single-ended clock capable pin" input source parameter of the clock wizard can lead to critical warnings in the implementation methodology reports. Using "global buffer" ought to resolve it. More info here: https://support.xilinx.com/s/question/0D52E00006hpQy0SAE/ps-clock-as-pll-input?language=en_US
Thanks,
Arthur
 

In addition to project settings, I believe Tools -> Settings -> IP Defaults will add the IP repo to all future projects. Might not always be desired, if you're managing multiple versions of the same repo or IPs, but it's an option.

Ok, 
I think I have it now, added it through "settings" rather than the "+" icon.  Don't recall this process previously, Thanks for your help. 
 
 

Hey Xband,
Ports and clocks referenced in constraints need to match ports and clocks in your design. Presumably, you have two instances of the ADC controller instantiated, which both have their own ports connected to input/output ports. This means that, for example, I'd expect that you would need to be constraining two instances of each port - let's say for example "ZmodA_dADC_Data_0[0]" and "ZmodB_dADC_Data_0[0]" instead of a single "dADC_Data_0[0]" twice.
Also note that the ports for the DAC controller, which are constrained to the Zmod B pins, aren't 1:1 matches with the ADC controller's; the clocks go in different directions for one example.
Broadly, how I'd approach it would be to start by copying the Zmod A constraints, update all of the package_pin locations to match corresponding locations in Zmod port B, then update all of the names in get_ports, get_pins, and get_clocks calls to match the names used by the second controller in the hardware design.
For an overview of constraints, you might check out these blog posts. They're not 100% applicable, and this is a very complex design to be trying to modify when starting out, but they might help with some terminology.
https://digilent.com/blog/the-constraints-file-also-known-as-magical-moving-stairs/ https://digilent.com/blog/constraining-ports-manually-via-xdc-file-vs-board-files/ Xilinx's UG903 covers everything in excruciating detail:
https://docs.xilinx.com/v/u/2019.1-English/ug903-vivado-using-constraints Thanks,
Arthur

Hi @Moshe_va, welcome to the forums.
acquireTriggeredPolling makes use of trigger hardware built into the AXI controller IP in order to detect signal conditions on either scope input channel; it doesn't accept external triggers.
An external trigger could be brought into the FPGA PL through a Pmod port - in which case it would need to be LVCMOS3V3 compatible. If you need hardware timing for it, then the AXI controller for the Zmod ADC and zmodlib sources would need manual modification, and the FPGA image and Petalinux image would need to be rebuilt.
If you don't need hardware timing, you could potentially use an AXI GPIO or an EMIO GPIO connected to a Pmod port, with or without an interrupt - the FPGA image would still need rebuilt, and drivers for whichever GPIO was used would need to be represented in Petalinux. In this situation, the Zynq PS would detect a GPIO event and manually trigger an acquisition, using acquireImmediatePolling.
Thanks,
Arthur

Hi @timmy,
There's a bug in the DMA implementation in Vivado. The "Width of Buffer Length Register" parameter in the DMA configuration should be increased to 16 bits from 14 bits, to increase the amount of data that a single DMA transfer is capable of sending to the circle buffers - this value reflects a maximum number of bytes that can be transferred. Currently, when the length of the transfer is written to the DMA, the top two bits are masked off, and only a quarter of the maximum amount of data can be sent.
Once the hardware is regenerated and the new HDF file has been used to update the hardware platform, no software changes are required to get it working.
Updated sources should be available on Github soon, at least for the baremetal projects.
Thanks,
Arthur

Hello everyone
Is there someone who can help me with this problem?
I'm going to modify the AXI_ZmodADC1410 IP to let it control two ADC 1410 controller. This is my idea to let only one core of my Eclypse z7 to to control both ADCs (until now I had to connect ADC and core in a one to one fashion) and let the other core to do all the elaborations and transportation to the PC.
I started modifying the IP but the problem here is that I can not use the Bus interface of digilent, because I can not find it in the original IP
Do you have any suggestion? Thank you very much for your help
Have a nice day
Riccardo

I have a digilent eclypse z7  card and connected zmod adc1410-105 to it. I write software in the cpp language on petalinux using the default bsp provided .
I want to use the zmod adc 1410 library.
From this library I want to use a function called “acquireTriggeredPolling “In order to offer a reading of 4 kilobytes of data that is sampled cyclically every 10 milliseconds, the goal is to start sampling according to an external trigger.
1- Which input should I connect the external trigger to?
2 - How do I integrate (if required) this input through the software in order to use it as a trigger in the function I mentioned
3 - Are changes in bsp required?
4-Is 3.3 volts the correct voltage for the trigger?
 
Thanks.