Xband

maybe found it, board image not set in hardware platform in Vivado.... Still not sure what to do.

Newest woe. Tried...Close Vitis, re export hardware, relaunch in new application directory/project, rebuilt application and project. Interspersed with invalid platform issues. Have no clue. New voo doo or ideas welcome, Thanks,

LED come on when I push the switch! Success I guess. @artvvb thanks for your time.

Rebuilt the project with new hardware reference and the include reference cleared.

My intent for understanding this simple example was to use a button to "trigger" the AXI data read from the Zmod 1410 that would be running continuously. Do you think controlling tvalid with this would work? Maybe not how its normally done.

thanks for all your help with this

I made the changes and regenerated the bitstream and it seems to work? Though it still claims to overwrite the constraint file. I'm at a loss to understand how in the hell I would know to change these button and led references as has been done. Why is this not already in the Eclypse Z7 xdc master? I looked at the board files and couldn't find this name referenced in the places I looked? updated the hardware reference in vitis and now still get the missing "include' directory which was there before, possibly related to the updated device ID stuff for 2023, not sure there though.

I'm not sure how to specify Custom.

May have an issue with the top level module, must be set to automatic, cannot figure out how to change it. Also button and led not showing as gpio in ".v" file. input [1:0]btn_tri_i; output [5:0]rgbled_6bits_tri_o;

General message warning,

maybe this error is a clue that two things are happening here that I"m not aware of, [IP_Flow 19-4994] Overwriting existing constraint file 'c:/Users/LENOVO/Documents/GitHub/project_button/project_button.gen/sources_1/bd/design_1/ip/design_1_auto_pc_0/design_1_auto_pc_0_ooc.xdc' @artvvb

Thanks for the response, I'll sort through it, I seem to miss the intent of these dual use example structures, looking for an easy example and end up in a loop of hell.

Going back to basics trying to reproduce an intro button/led example project on a Digilent EclypseZ7 board following instructions below; https://digilent.com/reference/programmable-logic/guides/getting-started-with-ipi Immediately I run into problems after changing the constraint file as given in the instruction, though I then figure out the example is written for the Zybo-Z7 so I try to adapt accordingly for my Eclypse board. I get critical warning for buttons and LED's,: [Vivado 12-584] No ports matched 'btn[0]'. ["C://GitHub/project_button/project_button.srcs/constrs_1/imports/digilent-xdc-master/Eclypse-Z7-Master.xdc":11] All I have done is uncomment the master board file that I found, set_property -dict { PACKAGE_PIN C17 IOSTANDARD LVCMOS33 } [get_ports { btn[0] }]; #IO_L11P_T1_SRCC Sch=btn[0] set_property -dict { PACKAGE_PIN C18 IOSTANDARD LVCMOS33 } [get_ports { btn[1] }]; #IO_L11N_T1_SRCC Sch=btn[1] RGB LEDs set_property -dict { PACKAGE_PIN A17 IOSTANDARD LVCMOS33 } [get_ports { led0_b }]; #IO_L9N_T1_DQS_AD3N Sch=led0_b set_property -dict { PACKAGE_PIN B16 IOSTANDARD LVCMOS33 } [get_ports { led0_g }]; #IO_L8P_T1_AD10P Sch=led0_g etc.. Just trying to reproduce the simple test project that the board ships with, any insight into this issue? I've created a much more complex project with the ADC board so I was under the impression I understood what was going on, perhaps not. Tried changing button names to “btn_tri_io[#]”, didn't work. The tutorial goes on about how these are “ tri state” where you get i,o,t states default in the Axi_gpio block design, this doesn’t happen for me, which is why I’m wondering if the EclypseZ7 board has this hardware or if there’s been another change in 2023 be whatever they’re running. It would seem that the baseline xdc file would have the proper name existing, wouldn’t this be reflected somewhere in the board documentation? I’ve changed and am updating the bitstream again, the design validated. I’ll update again, thanks for your help. I posted this to reddit earlier. Thanks for any help.

@thinkthinkthink, Thanks for chiming in, with my current level of understanding of Axi stream and such I don't want to do anything "manually" necessarily and am hoping Vivado does things correctly when letting wizards work. I'm reading this as I should delete the current ILA setup and try the debug path to let Vivado correctly make the connections? That is what I'll do next. I've already punted the stream combiner so will do a similar process with the stream fifo related signals. My interpretation is that by running the tdata signals into the AXI4-Stream Data FIFO that I'm relying on the this IP to properly configure the AXI stream and that these packaged tready, tvalid,tlast will be taken care of within this box. Let me know how I'm wrong about this philosophy if its bad. The below screenshot shows the new ILA generated with debug and connection automation. I''ll follow up later, hope it works! I'm happy to learn this option today. Thanks!!,

@artvvb, Thanks, that pdf was a bit stale, I have the fifo S axi going to the axi_dma in the design now, not sure if it makes any difference in what you're suggesting. Also have a constant (1) tied to tvalid on the fifo. Perhaps the axi_combiner wouldn't be necessary if I were to concat the data stream together before sending it into the fifo, I could eliminate the combiner and its issues. Let me know if you think that might help. Thanks

@artvvb I'm still not able to get the AXI stream active. Have triggers set up as you suggest, and trigger through the software side in Vitis sometimes, it is not consistent to get the tdata output from the ADC that way though. Also FYI, I'm using the older ADC IP (pre production) version. I do not want the triggering as set up in the Zmod Scope IP. The sawtooth wave form is data accumulator DSP, so data is coming out of the 1410-105, just that the AXI does not initialize. Thanks for anything,

I'm also running different Vitis Software dShow Replyebugger projects, sometimes to get the ILA to trigger.

@artvvb, I'm triggering omn the data coming from the ADC, perhaps the AXI doesn't have time to get started?

Greetings, I have a hardware design using the Zmod ADC that runs but the axi streams are "Inactive". I tried changing the clock source from the Zynq processor, as some previous error suggested an issue but the design seems to work as I get tdata out of the ADC and am able to use DSP on the data but the AXI stream isn't working. Any basic Ideas? I'm using the old 1410 IP, pre scope, no level triggers, just enable acquisition with a digital. Attached are the block design and the ILA scope screen capture. I've searched some Xilinx forums but nothing jumps out, something about "instantiating" that I don't understand. Perhaps somebody here can help. Thanks, design_1.pdf

I don't seem to have all these options enabled?

New issue that a source file is for some reason looking for a version from a USB drive that a previous version of the code was loaded from, I cannot seem to make the new directory stick even though I can navigate and choose what seems to be the proper file. This seems to keep the Vivado ILA from triggering so I cannot see what is happening to AXI variables. Thanks for any help.

Hi, I have what seems to be a working hardware design with the Zmod 1410 scope module (see below). My thought then was to modify the DDR example code removing all references to "triggering" (I don't care about that at this point) and recycle the multi S2MM_cyclic_transfer_test example. I created a new "helloworld" application in Vitis, copied the main.c from the above application and rebuilt the project. Then added what seemed to be relevant libraries in the main.c file. I did this 2 times and am having the same problem with the UserRegister path, I've built and cleaned the project, the cleaned version looks like it should run but then cannot find a valid platform when I try to launch from the Debug hardware option. Seems to be the same path issue for both versions, I was worried the "datatrans_" directory path was causing some problem so built the new "axidata" version. The scope below shows a 1MHz sine wave with 100MHz ADC sample from the Zmod and the lower sawtooth is a DSP accumulator. These seem ok before the AXI stuff happens is why I claim the hardware design is ok. Any ideas on what could be the problem? Thanks, Error: Error while launching program: The platform 'C:/GitHub/WN_Zmod/Vitis_notrig/design_1_wrapper_1/export/design_1_wrapper_1/design_1_wrapper_1.xpfm' used by the system project 'axidata_system' is not valid. The platform 'C:/GitHub/WN_Zmod/Vitis_notrig/design_1_wrapper_1/export/design_1_wrapper_1/design_1_wrapper_1.xpfm' used by the system project 'axidata_system' is not valid. Description Resource Path Location Type Invalid project path: Include path not found (C:\..\GitHub\WN_Zmod\Vitis_notrig\datatrans_\Debug\_sdk\bsp\ps7_cortexa9_0\include). datatrans_ pathentry Path Entry Problem Description Resource Path Location Type Invalid project path: Include path not found (C:\..\GitHub\WN_Zmod\Vitis_notrig\design_1_wrapper_1\export\design_1_wrapper_1\sw\design_1_wrapper_1\standalone_ps7_cortexa9_0\bspinclude\include). axidata pathentry Path Entry Problem

Are these addresses constant for the Eclypse Z7 platform or do you need to look at this file each time when wanting to get data? I was wondering how these came about, does building an application in Vitis automatically assign the values or properly route existing hardware values? or other magic? Thanks,

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