Vivado IP board change/Retarget IP

[engrpetero]

My target is the Zybo-Z7-10.  I have been away from embedded dev for some months.  I also had a HDD crash so I'm working with a new drive.  I was using Vivado2019.1 (and the associated Vitis) for a project.  With that version of Vivado, I could go through the whole project flow and create the appropriate .xsa file for the project, then could do Vitis development for the generated hardware.

When I re-imaged the computer with new HDD, I downloaded Vivado2020.1.1 (and associated Vitis).  I also downloaded/copied/pasted the Digilent board files to the appropriate location in the Vivado directory. I'm now trying to go through the entire Vivado flow and regenerate the hardware platform (.xsa file) to continue working on the Vitis C software.  Unfortunately, Vivado is giving me an error about 'IP board change' and needing to 'Retarget IP' (see image).  When I click on the 'More info' link for each of the two items, a popup 'change log' shows that says 'no changes'.  The second image shows the dialog when I click the 'IP board change' link.

I'm not sure where to go from here to get this back in a working state.  Any suggestions greatly appreciated (sorry if this is in the wrong forum!).  (BTW - I cross-posted over on the Xilinx forums).

 

[JColvin]

Hi @engrpetero,

Is there not a button at the bottom of the IP Status that lets you "upgrade selected" (presuming I recall the text correctly)? What happens if you click the "Retarget IP" button?

Thanks,
JColvin

 

[engrpetero]

There is.  It says 'Selected IPs can't be upgraded'. (which I hadn't seen before).  The icon next to those IPs has a little red 'lock' symbol next to it.  Not sure what it means (the Vivado docs haven't been helpful in that regard, yet, at least).

[engrpetero]

I forgot to attach the picture of the dialog that pops up when I click 'Retarget IP'.  I've looked for the 'upgrade flow' (and googled it) and have found nothing.

 

[zygot]

Xilinx IP gets "locked" if you create the IP for one target FPGA and then try to use it for a different device. The red lock symbol just indicates that you have to "upgrade" your IP for the current target. Really this usually just means regenerating the IP output products. Sometimes, IP gets locked when created in a different version of Vivado and then you try and rebuild your project in a newer verision of Vivado. Vivado 2019.1 ( ...I think that was the culprit ) changed how IP handled internally so it basically broke all existing projects created in earlier versions of Vivado using Xilinx IP.

There are occasions where IP created for one FPGA device isn't supported in another FPGA device. When this is the case you have to created a new version of whatever you need from scratch. If you work at it you can usually figure out the settings from the original IP. Sometimes, the IP changes and settings or options disappear. For this case you need to figure out a work-around; that is create new IP to replace what Vivado won't let you use.

Like bad assembler or C compilers the error messages from Vivado aren't necessarily helpful in figuring out what the exact problem is or what the appropriate solution is.... as if we can't create enough 'fun' to deal with on our own...

Part of the 'ecstasy' and 'horror' of relying on vendor supplied IP, especially the free stuff, is that you are almost guaranteed that between Vivado versions it will get, changed, get broken, get removed, or worse. That's one of the costs of 'free', 'drag and drop' design methodologies. HDL design is a lot more stable but also a lot more difficult. Pick your poison. 

Since I'm in a particularly gracious mood this morning I'll note that I't possible to create a design in all HDL and years later come back to it and have a really hard time figuring out how it worked or how to change it. This is really a problem when bequeathed project created by former employees from an unfriendly manager. The difference between text based design sources and 'drag and drop' based design sources is that for the text based ones you have a chance at properly documenting your work in case you have to revisit it months or year later. If you have to rely completely on someone else's effort then you're kinda stuck when it doesn't work out as expected. This is one aspect in which FPGA development is similar to software development. Sometimes what makes or breaks a design isn't obvious from the sources.

[engrpetero]

Thanks for taking the time to post that, @zygot.  Odd that for this project, the IP in question were/are both Xilinx items (the ZYnq7 processing system and the Processor System Reset, both of which indicate 'no changes' between versions).

I started over with a fresh copy of the original project that worked with Vivado 2019.1.  I've been able to Update IP, Run Synthesis,, Run Implementation, and Generate Bitstream without seeing any apparent errors.  I hate when things seemingly resolve themselves like this since I have no idea what caused it or why it seems to work now. 

The Vitis app that uses this hardware platform is still not working yet (hardware platform is always out of date and I can't successfully build it).  But perhaps this problem is at least temporarily solved (or perhaps the reason the Vitis hardware platform never gets out of date is due to a problem with the Vivado stuff.  The error on building the Vitis platform project does point to a specific non-Xilinx custom IP).

[zygot]

Unfortunately, for FPGA designs based on ZYNQ or MicroBlaze a lot of Xilinx IP has both 'hardware' i.e. PL aspects and PS software aspects. The software side gets broken a lot more frequently than the hardware. The more com0plicated, the more things to break...

This might be an option for you and perhaps not, but using the latest version of Vivado isn't the best strategy. You are almost guaranteed that newer versions of Vivado will break old hardware and or software support. I suggest upgrading to the latest version of the tools only when necessary to support a new device. This depends on how much time you have to play with surprises from the tools instead of doing work on your project. Vitis is a seismic change for Xilinx software development ( though oddly they still haven't merged Linux support into it ) and seems to be going in the direction of an OpenCL wannabe. Take some time to review the newer devices.

This is just an informal 'sense' that I have; but it seems that when a new device, like the 7000 series ZYNQ, appear the tools try hardest to support it and this includes the free IP available. THat observation might be helpful or not...

[engrpetero]

That's a great idea I hadn't thought of.  It doesn't look like 2019.1 is available on the Xilinx website.  But 2019.2 is.  Let me give that a try and I'll post back.

[JColvin]

Vivado 2019.1 is available; it's just listed in the archive section: https://www.xilinx.com/support/download/index.html/content/xilinx/en/downloadNav/vivado-design-tools/archive.html.

[zygot]

I still use my Win7 box with Vivado 2016.2 for a lot of development. Sometimes this is because of node-locked device licenses, but usually because I don't want to spend the time trying to migrate over to my Win10 box and Vivado 2019.1. I just haven't had a good reason for tying to download the 67 GB Vivado 2020.1 tools and rolling the dice on how usable it will be.

I have a few Linux platforms on which I can do FPGA development but the Xilinx tools haven't historically been as 'cohesive' on Linux as on Windows. I do sometimes use Vivado 2015.3 on my Centos 6 box from which I am currently typing. Really, except for the latest UltraScale Zynq devices Vivado 2015.3 supports any of the Digilent boards that I have... and I have a lot of them.

As @JColvinmentioned, you can find most versions of Vivado if you know where to look. One thing's for sure, the earlier versions aren't 40+ GB downloads. I live about 20 blocks away from broadband ( I've always been 'this close' to broadband...) and that has made looking for options more compelling. And that's been a good thing for a number of reasons.

[engrpetero]

(I just saw @JColvin post so I'll get the 2019.1 version next. :-)  In the meantime, since I bothered to do the following, I thought I'd post it)...

OK. so I tried the same things on 2019.2 (Vivado and Vitis).  I restored a 'fresh' copy of the projects that were successful on 2019.1.  Perhaps I've got a setting not configured correctly in Vivado.  The Synthesis, Implementation, and Bitstream portions of the flow all complete successfully (no errors, some warnings though). 

I then go to File->Export->Export Hardware (note I haven't exported the bitstream)to export the Hardware, creating a new .xsa file.  I then go to Vitis and load my previous project and am told the platform project is out of date.  I right-click the project and choose Update Hardware Specification, pointing to the new .xsa file I just created. 

Vitis tells me the hardware was successfully updated.  I then attempt to build the platform project which completes but gives on error (see screenshot below).  I'm not an experienced TCL user - and the error doesn't ring any bells for me as to how to solve.  Googling didn't provide any hits on 'Xilinx HwDb creation' that had anything even related to the issue (I only looked through the first two pages of search results).

I should probably mention I'm using the default Vivado settings for things (nothing customized outside of the Project)

[zygot]

Ok, so what follows is likely not germane to you problems but I've been meaning to post about a recent experience and you've problem reminds me about it.

So, a few months ago after perhaps 50 FPGA development projects on my Win10 box, I was getting annoyed beyond reason that it was taking Windows 30-60 seconds to open or save a simple, small HDL text file. After some searching I came to the conclusion that Windows File Search Indexing was the perp. I stopped Indexing for the development disk and that cleared up the ridiculous waiting for opening text files. I thought that everything was good.

Later I was working on a few SBC running Linux / PCIe FPGA project, and setup a Samba shared directory so that I could transfer data and files because I was doing the actual FPGA development on the WIN10 box. Turns out that if you pin a networked shared drive to Win10 and the drive isn't available you get a corrupted search index. Well, recently I've been working on a new Vivado project, totally unrelated to the SBC or shared directories, and Vivado has been giving me fits that I don't ever remember encountering. I always use my own code editor, and not one that the Windows registry know about, and I having getting bizarre problems with Vivado. It just never seemed to know when my source files were bring updated. Simulations didn't change, even when I changed the sources... even when I opened the sources in the Vivado editor and changed them. I'd turn off the PC and re-open Vivado and Vivado would tell me that the synthesis and implementation were out of date, even though I didn't make any changes since the last time Vivado thought that they were. Turns out that Windows Search was still causing problems. So, now I've completely disabled the Windows Search and Indexing service completely. Much better, thank you. Now, part of the problem is that Win10 is really wonky and still burdened with behaviors that have never been corrected. But a large part of the problem is that Vivado does some really really bad things that gets itself confused.  

I understand that Microsoft wants to ram a new UI down Win10 user's throats soon. Oh, Oh, i have a suggestion. Make Win10 look and behave just like Win7, when everything mostly worked just fine.

Sorry, I'm done now...

[engrpetero]

So I've got it working.  Not exactly thrilled with it yet (it seems a bit fragile since I'm not sure what everything is actually pointing to and I need to do some better documenting/moving around).  I mentioned my old HDD was corrupted - it wouldn't boot (and it was smaller than I needed).  Turns out most of the file system was still intact.  And luckily for me, my laptop (which is my dev computer) had the ability to have two SSDs.  So I connected the old drive (now D) and was able to actually see most of the old file system.

Turns out I was using 2019.2 Vivado and Vitis.  I was able to run Vivado/Vitis from the old drive and when I repointed all file references to 'D' instead of 'C', I was able to Update the Hardware Specification in Vitis and then successfully build the Vitis project.  I'll stay with 2019.2 for now - but on the new drive 'C'.  I'll spend some time this afternoon moving files over the appropriate place on 'C' and carefully note what is going on until everything works from C.

You guys have been invaluable to me here - mainly to keep me thinking and going based on your suggestions.  Much appreciated.  Thank you!

Hopefully, I won't have to post any more to this thread and things will be in 'good shape' going forward with 2019.2.