Testing hardware(Vivado) with known working software (Vitis)?

[Xband]

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,

Edited January 18 by Xband
Update before response, pretty much a log file here

[artvvb]

Win10 is what I use and, anecdotally, 2023.1 is one of the more stable versions of the tools I've seen.

For the specific error, this can show up when a platform project's hardware specification is updated with an XSA with a different filename than the one originally used - it could be something else, but this is my best guess. Run and Debug configurations name the bitstream after the XSA. The Run/Debug configurations aren't updated when an XSA is switched out, but the bitstream is, causing a mismatch that leads to this error. If you look in the folder listed, I would imagine you would see a bit file with a different name.

To fix this, you can get to the configurations through the dropdowns next to the debug and run buttons:

In the dialog, go to the Target Setup tab and check whether the "bitstream file" field matches what is actually in the folder:

To work around this long-term, you need to either always use the same name for the XSA for your platform (maybe storing new exports in a different folder to prevent overwriting the original), or go in and update this field every time you change the name.

[Xband]

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

[Xband]

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

50 minutes ago, Xband said:

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.  

Look through the verilog source files for a line that says "`default_nettype none" and either comment it out or remove it. These lines are usually right at the top of a file. This is effectively a compiler directive that tells the tool that when it sees a signal that either doesn't have a declaration (a declaration meaning "wire my_signal;" for example) or a declaration with an unspecified type ("input my_input" isn't specified as a reg or a wire), then it should throw an error instead of picking one automatically. Using these default_nettype statements can be useful for catching other silly errors like typos in variable names - for example, if the default nettype is wire, as is default when it's not specified, then a simple typo in a signal name anywhere in a module will introduce a new signal with that alternate name.

Alternatively, find each of the nets that it's complaining about, and make sure that they are specified as wires or regs. If it's complaining about signals in the block design wrapper, then I would be confused, it should be declaring all of the signals properly for this - could be a Vivado version difference or bug in 2023.1. Do note that a single signal could be defined across multiple lines - in the attached screenshot, DDR_addr is both defined in the module port list at the top, defined as an inout, and then finally declared as a wire.

50 minutes ago, Xband said:

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 don't entirely follow what you mean by this. Generally, files in a workspace are saved individually when you are working within the tool - The File -> Save operations only apply to the file currently open in the center pane. If you're trying to make a backup of everything in the workspace, exporting projects to a ZIP file might be an okay way to go. Getting your files into version control in git or something similar is also an option, but is an entire can of worms. When you launch the project from scratch, are you creating a new workspace?

 

[Xband]

Deleted post.

 

Edited January 27 by Xband
Forget about request