mini-rant: Vivado is bloody slow!

[mrflibble]

<rant>Deity Dancemove Fornication Messiah! Vivado is a steaming pile of slowness from millenias past!</rant>

Right. Feel much better now. Anyways, is it just me, or is the Vivado gui painfully slow?

press synthesis button

What's that Mr User sir? You want a synthesis run? Allow me to forward this button press related request to the tcl scripting engine factory summoner. Right, tcl scripting engine factory has been summoned. We can now get the tcl scripting engine from the factory. Ready for it? Okay here we go!!! .... Yes, we got a tcl scripting engine from the factory. About to start tcl scripting engine. Tcl scripting engine starting .... now! Okay, tcl scripting engine started. Now loading the tcl script ... almost done. Done! Starting tcl script. Oh wait a bit while I animate some pixels to show the tcl script is running. Done with those pixels. Okay now where were we? Ah yes, line 1 of that synthesis tcl script. Interpreting line 1 of tcl script. Executing line 1 of YIAAAAAARGH!!!!!!

WTF is this? 1980's and I am running this on my Amiga 500? *twitch*

How it should be done is: *press button* followed by text flashing by so fast I cannot even read it, followed by *job done* in lets say 1-2 seconds max for a bleeding trivial design. Didn't xilinx pay attention in software useability class or something?

ISE is not exactly fast but Vivado is just horrible right now. Did I miss the magic settings somewhere? Tell the tcl interpreter to maybe cache interpreter results? Read more than 1 line in one go? Anything?

 

[TrickyDicky]

Not had to use it in anger yet. But they do seem to be pushing non-project flow on more serious users - ie. enter all the tcl commands yourself, because the project based flow is rather limited.
They even admit that its rather slow for small designs compared to ISE, but much faster compiling larger designs. Its quite difficult to compare though as they compile for different devices.

 

[mrflibble]

Some time ago I installed vivado to give it a spin. And then uninstalled it again because synthesis support for systemverilog was a bit disappointing. But due to a recent interest in using Zynq parts I thought I'd give it another go. That and SV synthesis support looks a lot better these days.

But it really is slow. IMO it takes way too long before it starts to "do anything". By which I mean it fafs about wasting precious seconds of my time before it fires the actual synthesis task. I suspect I will end up with a Makefile based workflow which hopefully will be faster, but I'm not there yet.

 

[pbernardi]

Blame the Java.

Sometimes I think Java is dedicated process responsible for slowing down PC's performance.

 

[axcdd]

Did you use newest vivado version ?

My colleges that are mainly altera and now SoC-cycloneV/Zynq engineers says vivado enviroment is way-way-way faster then quartus for sw/hw purposes.

Personaly i never tryed newest vivado

 

[mrflibble]

Blame the Java.

I will happily blame crap performance on java. ;-) Maybe using another JRE or tweaking some gc settings will help.

Did you use newest vivado version ?

My colleges that are mainly altera and now SoC-cycloneV/Zynq engineers says vivado enviroment is way-way-way faster then quartus for sw/hw purposes.

Yup, latest version (2014.3.1).

And it could very well be that the vivado backend (synth, map, P&R) is fast for large designs. It's just that the overhead for running a simple synthesis from the gui seems rather high for a small designs. It literally takes seconds after I press synthesize before it starts doing any cpu intensive work.

And to be honest, if I have to choose where Xilinx spends their budget I'd rather have a good backend than a shiney and fast frontend. But this really is sub-standard for a gui in 2014 IMO. Anyways, I'm hoping I can maybe tweak something to get it a bit faster. One thing I haven't done yet (because I don't expect large benefits) is to put vivado on SSD. Right now it's on HDD. Experience with ISE was that using SDD was a waste of precious fast storage, since it hardly influenced runtime. Another thing that might help is putting all the design files on local ramfs instead of nfs. If it does something totally stupid like licking & tasting a particular filehandle every nanosecond then that might make a difference.

 

[ads-ee]

I havent noticed any slowness, but the I barely use project flow. And the design I did use it on was very large (~4hr build on ISE was ~1.5-2hr on Vivado the biggest speedup was synthesis). My current Vivado design is entirely scripted. Though even non-project flow uses an in memory 'project'.

 

[mrflibble]

That's encouraging to hear, because that would mean that while the gui may be slow the rest is fast.

What do you use for your scripting? That, and do you have a tool to generate scripts for you or do you handcraft scripts for each new project?

Though even non-project flow uses an in memory 'project'.

What do you mean by this?

 

[ads-ee]

The synthesis is fast in Vivado, but unfortunately on that particular project due to the excessive number of control sets, we had to go back to using XST for synthesis, as there weren't enough "knobs" to turn in Vivado synthesis to get both the fast synthesis and the QoR we needed to not exceed the LUT count that kept the design from becoming over utilized.

The non-project flow creates in some cases a hidden project to do certain things. e.g. Using a BD design requires a project, creating custom library components (for a BD design) requires a project. The unnamed project gets created in memory and is never written to the disk. The project directory structure gets created though.

- - - Updated - - -

Not had to use it in anger yet. But they do seem to be pushing non-project flow on more serious users - ie. enter all the tcl commands yourself, because the project based flow is rather limited.
They even admit that its rather slow for small designs compared to ISE, but much faster compiling larger designs. Its quite difficult to compare though as they compile for different devices.

With large design a scripted flow doesn't have to unload/reload the design into memory every single time it switches between synth-map, map-route, route-bitgen. That unloading then reloading a 60MB+ file (dcp - design checkpoint file) takes a bit of time. In the scripted flow you can run the whole thing in memory and only write out a design checkpoint when you feel like it.