cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
564 Views
Registered: ‎07-23-2019

TCL scripts and Vivado versions

Jump to solution

 

Tcl scripts are great (especially when the only alternative is to rebuild projects by hand). Probably everyone has experienced each tcl is bound to a specific and unique Vivado release. Whenever I got a Tcl that didn't match my Vivado release I used to "cheat" the script by changing the release version and run it to see where it blows up... I know the official procedure is to run it with the stated release, but who does that? That would mean in practice having all releases installed, something like 15 Vivados just for the last 5 years.

Is there an alternative to having every single Vivado release installed? A conversion tool? A guide to properly upgrade tcl scripts to the latest release? Any Xilinx plans to make tcl kind of universal or at least compatible for a series of releases? Any potential problem with my style of "run it and check the line where it blows up"?

1 Solution

Accepted Solutions
florentw
Moderator
Moderator
502 Views
Registered: ‎11-09-2015

Hi @archangel-lightworks 

The main limitation is the version of the IPs which will not match. Most of the time this is fine to just change the version of the IPs manually in the script. So running the script and checking where it fails is fine for many cases.

But this issue is that you not know if the IPs has changed in a way that it requires the design to be updated (this will be only in few cases). So if you really want to do it properly, you might need to check the change log for the IPs manually.

If you generate the project in the vivado version the design was created for, first that give you an opportunity to have the design which was working. Then when you upgrade to the newer vivado version, vivado will generate a ip change log that you can check to see quickly if there is any change you need to apply to your design. So it is convenient in a way but I agree it is not convenient to install many versions of the tools. This is still the way I would recommend.

I believe now the recommendation is to keep the BD instead of the TCL file when archiving a project. This way you can open it in a newer vivado version


Florent
Product Application Engineer - Xilinx Technical Support EMEA
**~ Don't forget to reply, give kudos, and accept as solution.~**

View solution in original post

2 Replies
florentw
Moderator
Moderator
503 Views
Registered: ‎11-09-2015

Hi @archangel-lightworks 

The main limitation is the version of the IPs which will not match. Most of the time this is fine to just change the version of the IPs manually in the script. So running the script and checking where it fails is fine for many cases.

But this issue is that you not know if the IPs has changed in a way that it requires the design to be updated (this will be only in few cases). So if you really want to do it properly, you might need to check the change log for the IPs manually.

If you generate the project in the vivado version the design was created for, first that give you an opportunity to have the design which was working. Then when you upgrade to the newer vivado version, vivado will generate a ip change log that you can check to see quickly if there is any change you need to apply to your design. So it is convenient in a way but I agree it is not convenient to install many versions of the tools. This is still the way I would recommend.

I believe now the recommendation is to keep the BD instead of the TCL file when archiving a project. This way you can open it in a newer vivado version


Florent
Product Application Engineer - Xilinx Technical Support EMEA
**~ Don't forget to reply, give kudos, and accept as solution.~**

View solution in original post

492 Views
Registered: ‎07-23-2019

 

That's my current process and worries. Saving the bd is a helpful tip

0 Kudos