02-27-2018 03:15 AM
I'm moving a lot of work from Vivado 2015.2 to Vivado 2017.3
The new version seems to have a significant problem:
The software interface, in particular editing BD designs is incredibly slow,
expecially when the project complexity grows up.
It takes several seconds
to validate BD design,
to make a connection between IP blocks,
to switch from a bd to another,
to refresh ip catalog,
to upgrade IPs
and so on.
This problem is surely related to the size of the project: bigger the project, slower the interface.
Is also relative to the presence of OOC synthesis: more OOC synth, slower the interface.
Can I do something to solve this problem?
There is a patch related to?
I noticed this "bad" behaviour starting from Vivado 2016.4, while Vivado 2015.2 continues to run fluently.
I use a Workstation with Ubuntu 16.04, 8-Core, 64GB RAM
I have no congestions problems in terms of CPU usage or RAM usage
Thank you in advance
02-27-2018 09:22 AM
set_param project.hsv.draftModeDefault only
Execute in TCL console. Seems newer versions have been thrashing for no reason. Let us know if that solves it.
03-06-2018 12:41 AM
03-06-2018 07:39 AM
OK, that is odd, as for me, it is faster. Check it is using all the threads (processors) it should in your system. The latest Vivado is able to use 6 processors for many operations, as opposed to the earlier versions which maxed out at 4. 2017.4 finds and uses 6 threads with no extra TCL commands by itself (for me). Never used .3 (but I suspect is is identical). Fairly big change between .2 and .4 (moving towards a unified HLS/SDx version for everything), so perhaps .3 needs some extra TCL help (for threads? etc.)?
03-09-2018 03:46 AM
vivado use all the threads it should.
The problem is evident when the OOC ip are run: more OOC synth, slower the interface
It works fine with no OOC synth and with the TCL command
set_param project.hsv.draftModeDefault only
The project is very huge, because of it fit the xczu9eg
In the project there are 4-5 BDs with a common wrapper and every BD has various xilinx and custom IPs.
Moreover I use also the RTL modules in the BDs so I can't use the TCL command:
set_property source_mgmt_mode DisplayOnly
Any other suggestions?!?
Thanks in advance
03-09-2018 12:41 PM
How many OOC runs would you say you have in the project (tens, hundreds, thousands)?
Do you generate output targets for the BDs as OOC per IP or OOC per BD?
One thing I've seen if there are hundreds of OOC runs (generated with OOC per IP) was that Vivado was slowed down due to the overhead of monitoring the status of all of the OOC runs. There was a fix put in back in 2015.x time frame to cut down the interval of the monitor checks if the time to complete all of the checks exceeded the interval. However, there is still going to be a performance degradation with a significant number (hundreds). The slowness will be more obvious is the project is on a network drive.
03-12-2018 02:12 AM
03-12-2018 12:42 PM
If what you are seeing is in any way related to the number of runs, then generating with OOC per BD should definitely help. This will reduce the OOC runs for the BD from hundreds to one.
The specific issue I was referring to is documented in https://www.xilinx.com/support/answers/67729.html
In Vivado 2016.3 there was a fix made to resolve the slow down problem. This fix takes the time to monitor all the runs and automatically adjusts the frequency of the monitoring so that it is never greater than 20%. That fix is still in the Vivado 2017.x code so the degradation of a lot of runs should not be as great but could still take a bit of processing time.
It is possible the developer put in some type of param when he implemented the fix that would allow the interval to be adjusted. However, if changing to OOC per BD is an option, that would be your best solution.
03-13-2018 07:06 AM
03-13-2018 02:50 PM
FYI: I followed up with the developer mentioned in my previous post. There was not a param added to manually adjust the monitor interval. The software just manually adjust based on the time it takes to monitor all runs.
He asked if you could create an SR and submit the design in order to get this fixed.
He was also interesting in knowing if turning off the automatic update of hierarchy had any effect on the responsiveness.
You can do this from the Tcl console by running "set_property source_mgmt_mode None [current_project]"
03-14-2018 04:12 AM