Vivado/Vitis new AXI peripheral - at wit's end

[engrpetero]

My current project contained two AXI peripherals I created.  It was working fine (or close to working, at least not producing any errors I couldn't live with).  I added a new AXI peripheral modeled off one of the original two.  In my main project (the one that contains the peripherals), I've updated the memory address of the new AXI peripheral to the desired value (it's very similar to the previous two). 

I've synthesized, implemented, generated bit stream many times, updated Vitis platform project many times, created new Vitis platform and application projects (also several times), and no matter what I do, the xparameters.h file always contains the incorrect AXI BASEADDR and AXI HIGHADDR for the new peripheral.  Moreover, it's killing my ability use the zybo uarts if I keep the new peripheral (they just don't work).

I'm at my wit's end on trying to figure out what to do next.  I can share anything related to what I've done and am doing.  I sure hope someone can help with a suggestion as I can't make any further progress.  Very annoying.  Any ideas?

Edited July 17, 2023 by engrpetero

[engrpetero]

Quote

Indeed. There's just no point to exporting HW that doesn't work to the software tools.

The only reason (I can think of right now) is to ensure something isn't wildly off track.  Since the subject here was an AXI-Lite peripheral, I first wanted to see if I could write to and read from the collection of registers before bothering with the user logic.  

Quote

If you have poor clock or IO timing constraints to start off with it's possible to have no issues show up even though your design won't work on actual hardware. Once IO timing constraints are in reasonable shape, you need to address issues caused by synthesis and place & route due to IO signals coming from all of the IO banks in regions that might span the entire device.

There are user manuals and tutorials for synthesis, timing closure, and related subjects as well as how to use the tools available in Vivado's Document Navigator; read them.   

Reading them again at this point will certainly be helpful.  Reading them before I had a meaningful design to consider was an academic exercise at best.  Now those docs should be much more useful.  Thanks for the suggestion/reminder.

Quote

For a significant design Vivado's own IP can cause hundreds of warnings, many of which can be forgotten about, but not ignored. Figuring out how to sort the really important ones from the not so important ones takes a bit of on-the-job training.

The sheer number of warnings is bewildering.  I generally assume Errors must be dealt with (or the design WILL NOT WORK), Critical Warnings should be dealt with (at minimum understood) (or the design most likely WILL NOT WORK), and Warnings should be understood (the design might work), even if ignored.  Good thing is they are often logically grouped together.  Bad thing is there is often little to go on to figure out a problem (even with the help of internet searches).

Here's a good example of the Warnings that show in my IP (Edit in IP Packager from my top level module)...

For the top section (Vivado commands), I have tried everything to remove the cause of those errors.  I've made no progress and have given up on them.

For the second section, I can find no additional info related to those warnings.  I have an AXI bus for this peripheral.  I have ports to match all the AXI-Lite expected ports and they are mapped correctly. 

I have a port S_AXI_CLK which is of interface definition type 'clock_rtl' and is mapped to port CLK of that interface definition.

I have a port S-AXI_RESETN which is of interface definition type 'reset_rtl' and is mapped to port RST of that interface definition.

I created a 'dummy' AXI Lite peripheral using the Vivado 'Create and Package New IP...' menu item and checked the port mappings for the S_AXI bus and those clock and reset ports and they were the same.

I have chosen to ignore those two warnings because 1) it seems my interface is setup correctly; 2) no changes to the interface seem to have any effect on those two error messages; 3) I can find no additional information online about how to resolve these warnings.  

I do have a hard time believing the warnings aren't relevant though.

[artvvb]

Hi @engrpetero,

The Vivado command warnings are largely irrelevant. The first one tells me that you have board files installed that make use of Xilinx part numbers that you don't have the device support for installed. As long as the specific board files it complains about aren't used in the project, these warnings are irrelevant.

The second warning tells me you installed board files through the Digilent-recommended flow of copying files downloaded from GitHub into a folder in the Vivado install directory. The warning occurs in case there are differences between the 1.1 version of the board files in the XilinxBoardStore repo and the Digilent vivado-boards repo, which could cause problems if moving the project to another computer and not bringing that dependency with - but there shouldn't be differences.

The IP packager warnings are related to config parameters for the clock and reset interfaces in the IP. These can be seen by double-clicking on the interfaces in the IP packager. To clear the warnings, the params should be updated to match the names of the actual ports of the IP, eg S_AXI_CLK's ASSOCIATED_RESET param should be changed to S_AXI_ARESETN. This could potentially affect parameter propagation between IPs, but I wouldn't expect this particular warning to cause issues with addressing. I could be wrong.

Information about what's in the Customization Parameters and Addressing and Memory tabs of your IP could be helpful. The aforementioned tcl scripts in charge of managing the base address and high address parameters and passing them to parameters can be found in the File Groups tab.

It could be easier to add your AXI controller to the project as an RTL module instead of an IP, since, given the correct signal names, Vivado can infer an AXI interface from the set of ports and hopefully not require you to mess around with the IP packager. That said, it's still painful when you need to manage parameters of the inferred interfaces in IPI - lots of random little bugs can still crop up, like not having the correct clock frequency set on an AXI interface.

Thanks,

Arthur

[JColvin]

Hi @engrpetero,

Edit: aw dang, Arthur beat me to it by a couple minutes.

The Vivado general warnings about board parts/files you might be able to remove, though I am not certain what you have tried already.

The first one with the 109 warnings about Vivado not finding a board part is an unfortunate side effect of having installed a board file but not having the associated FPGA/SoC part actually installed with software. What you can do to get rid of this is to go into the directory it mentioned and delete every board file you don't intend to use from the directory.
If you do end up getting one of those boards later, you can always reinstall it from the Xilinx Board Store at the "select a part" step of a new Vivado project.
Or at least that is what I have historically done when I didn't have some many types of FPGA/SoC hardware installed with my multitude of Vivado installs. I'm not sure what you have tried.

As for the Zybo Z7-10 1.1 board file being out of date, I'm not sure why this error is showing up as the Xilinx Board Store only has the board files that Digilent provided to them from our own repository sometime last year, so to the best of my knowledge they are identical in content. My best guess is that AMD is pushing people to use the Xilinx Board Store instead of locally copying and installing the files.

I am not certain at the moment for the IP Packager warnings about your interfaces not existing; I would have to do some more research.

Thanks,
JColvin

[engrpetero]

Thanks @artvvb and @JColvin for those posts.  They were helpful - sorry for taking so long to post back.  I was trying to learn as much as possible before responding.  A few things seem very clear from my experimenting over the last few days.

1. Don't bother exporting hardware unless synthesis, implementation, generating bitstream complete successfully and with no critical warnings.
2. It *seems* sometimes Vitis platform projects cannot be 'fixed' simply by updating hardware.  But it also *seems* new platform projects can always be created using the exported hardware file (again, as long as S,I,GBS complete successfully).
3. When I look more carefully at the warnings, it does seem they are well grouped so even though there may be several hundered (or 1000+ even), searching through them for relevant warnings isn't that bad.

The good news is that all three of my custom AXI peripherals are again at the correct memory addresses (xparameters.h file), they all S/I/GBS with no critical warnings and no other problematic warnings, and two of they actually work correctly (the third I knew still needed some work).  They might not be the most efficient (:-)) but they do seem to work.

@artvvb - the last paragraph in your post is something still for me to try.  Sometime, I'll get back to that.