UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Participant jesperjustesen
Participant
11,229 Views
Registered: ‎01-19-2016

Random runs of OutOfContext modules

Jump to solution

Hi,

 

In my vivado (2015.4) project I have a structure where IP's are maintained in a project different from the "main-project". Both "IP-project" and "main-project" is stored in a revision control system. I am using the "Full revision control" approach recommended by Xilinx where all IP resources are stored. I generate all output products in the "IP-project" and submit to the revision control system.

 

Whenever I do a "fresh" checkout from revision control i would belive that all IP's would appear as up-to-date in the "main-project". Indeed the IP's appears as "up-to-date" when i use  report_ip_status in the "main-project" (Refer to the attached capture). Despite the IP status, a random selection of the IP's are launched as "out-of-context module runs" when i launch runs in the "main-project". If I repeat the process of "fresh" checkout and launch run, random combinations of the IP's will be launched.

 

I am able to do a "fresh" checkout, generate output product in the "IP-project" and then launch runs in the "main-project" - but then the idea about storing IP's to avoid re-generation is wasted.

 

Thanks.

Jesper

 

Capture.PNG
CaptureRun.PNG
0 Kudos
1 Solution

Accepted Solutions
Highlighted
Participant jesperjustesen
Participant
21,824 Views
Registered: ‎01-19-2016

Re: Random runs of OutOfContext modules

Jump to solution

 

Thanks for the thorough elaboration.

 

Inspired by the timestamp based explanation i looked into the options of our revision control system (Perforce).

It turns out that the default setting is that files get a timestamp based on the point in time of the checkout - excactly as you suggest. I now use the perforce "Preserve original modification time"-option and the IP's are now correctly detected to be up-to-date.

 

I should mention that during the initial experiment with the perforce setting i didn't manage to make it work. As a result i briefly looked into using a tcl-script to update the timstamp of only the .dcp files. It actually worked, but it would have been an ugly solution.

 

Jesper

2 Replies
Historian
Historian
11,184 Views
Registered: ‎01-23-2009

Re: Random runs of OutOfContext modules

Jump to solution

You are looking at two different things here.

 

The report_ip_status is checking the version of the IPs used in this project against the most current versions of the IP available in the tool. So these will all remain up to date until you migrate to 2016.1. If, in 2016.1, there is a newer version of the FIFO generator (later than 13.0 Rev 1), the Status will change to out of date, and you will get a recommendation. At this point you will have the option of updating the IP to the newest version, leaving it alone, or manually regenerating/recusomizing it. This check is done only using the .xci file (where all the version and customization information of your core are kept).

 

So, the .xci is the "source" of your IP - it contains all the information required to use your IP (at least for most IP). However, to actually use it, some "targets" have to be built. These are "instantiation_template", "synthesis", "simulation", "implementation", "testbench", ... Each of these targets are built using the "generate_target" command, and end up creating files in the IP directory. These files, in turn, are actually used by the different processes.

 

Like other things in the project infrastructure, there is a built-in dependency management system. The tool tracks what is out of date with respect to its source using date stamps; if your .v file is newer than your synthesized .dcp file, then the synthesis is out of date, and needs to be re-run.

 

When you check out a fresh working copy of your revision controlled IP directory, all these files get date/time stamped based on the time of checkout. So even though they were all built and up to date when you checked them in, they now have new dates and times. This messes up the dependency mangement system, which sees some of the targets as being older than the .xci file (the dependency tree is probably more complex than this), and hence forces the "generate_target" step to be re-run on the IP. Since none of the sources have really changed, the built result will end up being identical to the previous one, but this consumes CPU time before processes (synthesis/implementation/simulation) of your main project can begin.

 

Unfortunately, while I know what is causing this, I do not have a solution for it...

 

Avrum

Highlighted
Participant jesperjustesen
Participant
21,825 Views
Registered: ‎01-19-2016

Re: Random runs of OutOfContext modules

Jump to solution

 

Thanks for the thorough elaboration.

 

Inspired by the timestamp based explanation i looked into the options of our revision control system (Perforce).

It turns out that the default setting is that files get a timestamp based on the point in time of the checkout - excactly as you suggest. I now use the perforce "Preserve original modification time"-option and the IP's are now correctly detected to be up-to-date.

 

I should mention that during the initial experiment with the perforce setting i didn't manage to make it work. As a result i briefly looked into using a tcl-script to update the timstamp of only the .dcp files. It actually worked, but it would have been an ugly solution.

 

Jesper