Xband

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!

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

@artvvb, Thanks for noticing, exactly what in this ILA scope could lead you to this diagnosis?

@artvvb Not sure if its successful or not, looks like it read 64 bits, 0-63, though the added code says test failed. Not sure how to interpret the result. I was going to move this topic to a new thread but not sure of a smooth process for doing so. thanks for insight.

@artvvb, When I run this the data never flows into the while loop in the software, my serial terminal output is a few "test done" printf statements. When the ILA is launched it is "waiting for trigger" 0 of 1024 samples. Is there an obvious problem? Thanks,

@artvvb, can you elaborate a bit on the control_0 part of this design? Are these just 2 GPIO blocks? Its impossible to tell what they are connected to, my options for the Z7 are the button or leds. It seems like the data is streaming from this gpio. Otherwise this seems like a nice instructional piece of code, but for this exclusion. Sorry it may be obvious to some. Thanks,

@rarow, I did a similar thing with pulsed LED with triggering a camera. I couldn't see the LED since the pulse was so short it didn't make enough light for me to see with my eyes. Though I finally timed the camera so I could see the led flashing, so you might need better eyes! :)

Could also be termination of the signal contributing to this. Typically there can be a factor of 2 if you’re reading a 50ohm termination at high impedance 1Mohm. I cannot recast what the zmod sma termination is, but I know it’s listed numerous places in the documentation.

@artvvb, continuing to beat this dead horse. Attached is a pdf of the hardware design that seems to compile and can generate a bitstream, though with some errors. The DDR software will run but since the multi streaming code is written for a 32bit buffer I cant extract it. I went into the HW code and made the original AXI stream 64bits depth and tried to change appropriate buffer indexing in the s2mm_cyclic_transfer code but cannot get to the data. I"m not sure this was successful. I've changed the u32 for the Bufferlength to u64 and tried to propagate these changes to indexing through to multi streaming main code. Could you give a rough overview on which values should change to u64 (in the s2mm_cyclic_transfer main) or perhaps just a link to some code that would spit the actual hardware buffer out so I can confirm it has changed to 64bit depth. I seen to recall you being against changing this depth to 64, which is entirely reasonable given the complexity that the stream depends on, I tried to preserve the 32bit axi stream data through all the original hw in the base fpga design and then combine the stream just befor the DMA transfer coming out of the ZmodScope Port A. I think the basic concept of pulling out the data, using the DSP accumulator and then combining back into the AXI stream should work, though I could be really screwed up with the timing even if it compiles. I'm interested in using the simulation to try and ring out the timing but this DDR project is pretty deep and I'm not sure how to implement that, though I see you have the ILA ip scattered throughout for this purpose. Have a good weekend, sorry I always post these on Friday but I'll typically work through the week trying to get something going and then succumb to the frustration later in the week. Thanks for any help. ZmodScope_PortA_2_9_2024.pdf

Deleted post.

@artvb Hi, I was able to get my modifications to the DDR project to compile and run with the baseline streaming sw project, though the project added DSP integration of the ADC values are not integrating. I tried to replace the ADC output in the stream with the integration values from each channel though I'm still getting the baseline values coming through. My current guess is that there is an issue with the triggering and/or the writing into the AXI stream isn't working properly. To try and diagnose and understand more wanted to run the simulation and ring out the triggering and clocks to help with understanding, but am getting a silly error that I've found others having in the AMD forums, "default_nettype is none" issues with a couple of clock signals. Another problem is that the Vitis project seems to be locked and will not allow me so save my changes, thus every time I launch the project from scratch I need to go back and redo. I know this is a bit vague, but I could use a bit of direction if you have any suggestions. Thanks!

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

Now perhaps I've had every version of this problem, now the log says its loading the correct bit file but the error pops up with an old one. Hi, I have a modified streaming DDR program that I want to test changes I've made to the fpga from a working version of the DDR streaming example. I have loaded and confirmed software Vitis project is working, calibration read and S2mm_cyclic_transfer work. The "easiest" solution would be to read the xsa export into the Vitis application after confirming the working software, at least this seems straightforward. Though I have struggled with these applications getting all of the source files to read properly and have had a night mare resetting the BSP what seems like hundreds of times to finally get the Vitis project to work consistently. Not sure I want to deal again with fallout of destroying a working project through the process. Any advice on the best way to approach this? Running the projects on a Win10 machine Vivado 2023.1. Is this a particularly buggy setup in general? Also I cannot save, or Save As from the Vitis File menu, it is greyed out so none of the changes can be saved at the project level. Thanks,

Seemed to have everything compiled in the hardware, went to Vitis in and rebuilt the project seemed ok, had issues getting anything to respond after programming the device over and over. Switched to another board which I have and then had this strange error which probably comes from the "calibration" routine. Had previously run the demo which is why there are "button x pressed!" in the serial display. "Unsupported Zmod" was after reprogramming the fpga and then loading the software from Vitis. Try more later.

@artvvb, updated the ip and things seem better, creating a new HDL wrapper and will try synthesis. Got through synthesis and implementation. A timing failure. Bitstream generated fine. Will try to load onto the hardware when I get a chance. Upgrading the IP seemed to resolve the issue. I wasn't sure if it should be done, let sleeping dogs lie was my approach until spiraling into the doghouse. Thanks for the support.

@zygot yeah I had the main project working quickly also, its the modifications that cause problems and the accompanying gaps in the workflow in Vivado that come along. I search Xilinx forums each time before reposting here and find people encountering the exact problems I am having years ago and there are not clear solutions to the same annoyance I'm having. Part of my problem could be I'm using 2023.1 and the original project is in 20xx.x, I don't know. At some point I might download the same version and go through it. The current stumbling block is that Vivado changed the directory for ip from the baseline to a "temporary" and seemed to forget it does this for some reason. So I as a novice need to figure out what trick I can pull to make it ok. Maybe rebuilding the project in an earlier version is the best solution at this point, I don't know.

Thanks, that's helpful. I've been at this sporadically while taking care of a family member who has been in and out of the hospital. Again I don't see it as a problem with the hardware, Vivado is a mess and non intuitive, I'm using the proper platform for my application . I"ve been cordial with your drop in remarks, I suggest you unfollow the conversation if you don't have anything to contribute.