Vivado parses wicked slow

lowly. To test this I timed it. I have a design with about 20 lines of co de. It uses an undeclared reg. If I try to compile with with Modelsim fro m the command line, I get an error immediately. I mean, I can't even time it because the error message appears while my pinky is still on the carriag e return. When I try to synthesize with Vivado, it takes over 20 seconds j ust to tell me I have an undeclared reg. That seems like a really long tim e.

ant mult with 50 LUTs. Seems pretty slow.

If Brand X isn't up to snuff, maybe switch to Brand I, formerly A.

Kevin Jennings

I've just started using Vivado, which was supposed to be a ground-up totally new software with no inheritance from ISE. However I have already noticed that it has some of the same quirks that ISE does. One thing I noticed in ISE, and it may be related to the time you take to find an error, is that when you ask to check syntax on one module it actually parses the entire design hierarchy - even if the module you wanted checked is only in the project but not a part of the design hierarchy. Other quirks include pointing to a different net when reporting a multi-driven net. Generally when Vivado reports a multi-driven net there is one somewhere in the design, just not the net it is reporting. Good luck finding the actual net. I used to have a similar issue in ISE where it would report GND as multi-driven.

What was clearly a totally new design is the user interface. Even when Vivado has the exact same function as ISE you need to know the new name to find it. For example, "IP Integrator" is clearly Core Generator just repackaged for Vivado.

By the way, when you say Vivado took 20 seconds to find the error, was that running simulation or synthesis?

That is running "synthesis". It doesn't actually get to synthesis, since there is an elaboration(?) error. I've actually never used the Vivado simulator. I could never even get Isim to parse my code, so I haven't tried a Xilinx simulator in years.

slowly. To test this I timed it. I have a design with about 20 lines of code. It uses an undeclared reg. If I try to compile with with Modelsim f rom the command line, I get an error immediately. I mean, I can't even tim e it because the error message appears while my pinky is still on the carri age return. When I try to synthesize with Vivado, it takes over 20 seconds just to tell me I have an undeclared reg. That seems like a really long t ime.

stant mult with 50 LUTs. Seems pretty slow.

Quartus2 v.15.x suffers from similar problems. Finding syntax errors in small designs is 10-20 times slower than, for exam ple, in v.9.1. Not just syntax checks, all phases of processing of small designs in v.15.x feel MUCH slower than in earlier versions. May be, except for timing analy sis.

ly slowly. To test this I timed it. I have a design with about 20 lines o f code. It uses an undeclared reg. If I try to compile with with Modelsim from the command line, I get an error immediately. I mean, I can't even t ime it because the error message appears while my pinky is still on the car riage return. When I try to synthesize with Vivado, it takes over 20 secon ds just to tell me I have an undeclared reg. That seems like a really long time.

onstant mult with 50 LUTs. Seems pretty slow.

ample, in v.9.1.

.x feel MUCH slower than in earlier versions. May be, except for timing ana lysis.

Out of interest, I went to quantify my feelings about slowness of small des igns in Quartus Prime v.15.1 relatively to previous versions. Here are results for project with ~250 LEs.

Analysis & Syntesis: Device Time Quartus II 9.1 Quartus II 13.1 Quartus Prime 15.1 Cyclone III 2s 2s N/A Cyclone IV E 2s 2s 11s Stratix IV 4s 2s 12s Cyclone V EB N/A 2s 12s

Fitter: Device Time Quartus II 9.1 Quartus II 13.1 Quartus Prime 15.1 Cyclone III 3s 4s N/A Cyclone IV E 2s 4s 4s Stratix IV 29s 20s 19s Cyclone V EB N/A 20s 24s

Timing Analysis: Device Time Quartus II 9.1 Quartus II 13.1 Quartus Prime 15.1 Cyclone III 2s 2s N/A Cyclone IV E 1s 2s 2s Stratix IV 4s 3s 3s Cyclone V EB N/A 7s 7s

So, slowdown of Analysis & Syntesis is not my imagination, it is very real and certainly pushes the time from category "fast enough" (at least on fast CPU/SSD as in my tests) into category "annoying, disrupts a flow of thinki ng".

On the other hand, slowdown of fitter is related to new devices (Startix IV and all '5' series) rather than to specific version of Quartus software.

Interesting. I haven't used Synplify in a while, but I feel like it would parse & synthesize small designs in a matter of seconds. On the other hand, I made a test case for Vivado:

Vivado 2016.2 Test Case: Module with One Flipflop

--------------------------------------------------- Synthesis time: 58s Place & Route: 1:58s Synth & PAR Together: 2:40

Seems pretty weak. Does not even include time to "open" design. I do a lot of small test cases in order to get synthesis right and trying different things on these small designs eats up a lot of my time.

I might remind you, this design contained one flipflop. I don't know how fast the computer is, but it was very lightly loaded.

d parse & synthesize small designs in a matter of seconds. On the other ha nd, I made a test case for Vivado:

lot of small test cases in order to get synthesis right and trying differen t things on these small designs eats up a lot of my time.

fast the computer is, but it was very lightly loaded.

I can't confirm your results. According to my measurement, Vivado handling of small designs *is* awfully slow. but not nearly as slow as you suggest. I tested with the same design that I used for comparison of versions of Qua rtus. The Vivado test computer was somewhat slower than the one I was using with Quartus (Core i7-3770 vs Xeon E3-1271 v3), but also had fast SSD. I specified the smallest of all Zync devices - xc7z010iclg225-1L. Synthesis took 23s (wall clock time) Implementation took 42s

And remember, my test case was significantly bigger than yours.

So, either something is wrong in your project settings or you should buy fa ster computer. That is, not more cores, the 2nd CPU core only helps by few per cents and any number of cores above 2 makes no difference at all, but f aster cores. And, of course, good fast SSD.

Yes, these results do seem unreasonably bad. I'll try a different computer.

slowly. To test this I timed it. I have a design with about 20 lines of code.. It uses an undeclared reg. If I try to compile with with Modelsim from the command line, I get an error immediately. I mean, I can't even ti me it because the error message appears while my pinky is still on the carr iage return. When I try to synthesize with Vivado, it takes over 20 second s just to tell me I have an undeclared reg. That seems like a really long time.

stant mult with 50 LUTs. Seems pretty slow.

The multi-driven net problem was a headache in ISE. In vivado you'll also get an obscure report about some net being multi

-driven, but you can workaround it quite easily doing a post-synthesis DRC check, it will show more clearly which nets are conflicting.

lowly. To test this I timed it. I have a design with about 20 lines of co de. It uses an undeclared reg. If I try to compile with with Modelsim fro m the command line, I get an error immediately. I mean, I can't even time it because the error message appears while my pinky is still on the carriag e return. When I try to synthesize with Vivado, it takes over 20 seconds j ust to tell me I have an undeclared reg. That seems like a really long tim e.

ant mult with 50 LUTs. Seems pretty slow.

BTW, if you are new to Vivado then you possibly didn't pay attention to "on

-the-fly" syntax checking feature.

This feature allows to catch simple syntax mistakes without running synthes is. Just open your HDL source in the editor and follow red marks. In VHDL undeclared signals are caught by "on-the-fly" checker just fine. I don't kn ow if they are caught in Verilog as well.

My guess would be the synthesis process has become more heavyweight as time has gone on. Modern FPGAs are much larger than older ones, which means more housekeeping / management of data structures, databases, libraries etc and a more complex flow.

I wouldn't be surprised if this causes more initial setup, with the expectation this will be paid back by making building a complex design quicker. They probably aren't optimised for building very simple designs.

Theo

I my case this is compared to a couple of revisions back but you are right I'm currently using a Brevia 2, not a big FPGA, it the smallest device in it's family, and I'm using less than half of the logic, in some cases way less than half the logic.

The wait has changed from 20 seconds or less to build the whole project to several minutes making it an annoyance to have to build the entire project. Still compared to using real hardware and changing the wiring, which would make the project quite a difficult task to change, using a FPGA is quite liberating.

me

ore

d a

That's the theory. In practice, for non-tiny designs (compilation of several minutes) I don't see that initial slowness pays back. Mostly I see the same ~10s difference between Quartus II 13.1 and Quartus Prime 15.1 that I measured on tiny desi gns, persists on bigger designs as well. May be, for designs that take dozens of minutes it would be different. I am certainly not going to measure.

I know that the simulators are intentionally speed crippled to encourage users to upgrade to paid versions. I don't know if they do the same thing with synthesis tools or not.

I tried a different computer and got the same results.

May be, two slow computers? Can you report specs?

In order to be sure that we are talking about the same thing I also created single-ff test case. Here are source/settings/project:

----- one_ff.vhd

library ieee; use ieee.std_logic_1164.all;

entity one_ff is port ( clk : in std_logic; dout : out std_logic ); end entity one_ff;

architecture a of one_ff is signal ff : std_logic; begin

process (clk) begin if rising_edge(clk) then ff

We are talking about X&A own integrated synthesis. I don't believe that there is a difference between "paid" and "free" tools except that "free" tools can't target certain devices. Anyway, all my Quartus measurements were "paid". Vivado measurements were sort of paid too - license came due to voucher that was attached to Zync Eval. board.