Vivado parses wicked slow

[Kevin Neilson]

Vivado is supposed to be really fast, but I've noticed it parses really 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 time it because the error message appears while my pinky is still on the carriage 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 time.

Also, it takes over 3 minutes to P&R this design, which comprises a constant mult with 50 LUTs. Seems pretty slow.

 

[KJ]

On Wednesday, July 27, 2016 at 7:21:26 PM UTC-4, Kevin Neilson wrote:

Vivado is supposed to be really fast, but I've noticed it parses really 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 time it because the error message appears while my pinky is still on the carriage 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 time.

Also, it takes over 3 minutes to P&R this design, which comprises a constant mult with 50 LUTs. Seems pretty slow.

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

Kevin Jennings

 

[GaborSzakacs]

Kevin Neilson wrote:

Vivado is supposed to be really fast, but I've noticed it parses really 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 time it because the error message appears while my pinky is still on the carriage 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 time.

Also, it takes over 3 minutes to P&R this design, which comprises a constant mult with 50 LUTs. Seems pretty slow.

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?

--
Gabor

 

[Kevin Neilson]

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.

 

On Thursday, July 28, 2016 at 4:47:52 AM UTC+3, KJ wrote:

On Wednesday, July 27, 2016 at 7:21:26 PM UTC-4, Kevin Neilson wrote:
Vivado is supposed to be really fast, but I've noticed it parses really 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 time it because the error message appears while my pinky is still on the carriage 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 time.

Also, it takes over 3 minutes to P&R this design, which comprises a constant mult with 50 LUTs. Seems pretty slow.

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

Kevin Jennings

Quartus2 v.15.x suffers from similar problems.
Finding syntax errors in small designs is 10-20 times slower than, for example, 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 analysis.

 

On Friday, July 29, 2016 at 1:32:43 AM UTC+3, already...@yahoo.com wrote:

On Thursday, July 28, 2016 at 4:47:52 AM UTC+3, KJ wrote:
On Wednesday, July 27, 2016 at 7:21:26 PM UTC-4, Kevin Neilson wrote:
Vivado is supposed to be really fast, but I've noticed it parses really 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 time it because the error message appears while my pinky is still on the carriage 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 time.

Also, it takes over 3 minutes to P&R this design, which comprises a constant mult with 50 LUTs. Seems pretty slow.

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

Kevin Jennings

Quartus2 v.15.x suffers from similar problems.
Finding syntax errors in small designs is 10-20 times slower than, for example, 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 analysis.

Out of interest, I went to quantify my feelings about slowness of small designs 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 thinking".

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.

 

[Kevin Neilson]

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.

 

On Tuesday, August 2, 2016 at 7:51:38 PM UTC+3, Kevin Neilson wrote:

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.

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 Quartus.
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 faster 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 faster cores. And, of course, good fast SSD.

 

[Kevin Neilson]

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

 

[Leonardo]

El jueves, 28 de julio de 2016, 22:53:29 (UTC+10), Gabor escribiĂł:

Kevin Neilson wrote:
Vivado is supposed to be really fast, but I've noticed it parses really 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 time it because the error message appears while my pinky is still on the carriage 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 time.

Also, it takes over 3 minutes to P&R this design, which comprises a constant mult with 50 LUTs. Seems pretty slow.

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?

--
Gabor

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.

 

On Thursday, July 28, 2016 at 2:21:26 AM UTC+3, Kevin Neilson wrote:

Vivado is supposed to be really fast, but I've noticed it parses really 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 time it because the error message appears while my pinky is still on the carriage 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 time.

Also, it takes over 3 minutes to P&R this design, which comprises a constant 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 synthesis. 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 know if they are caught in Verilog as well.

 

[Theo Markettos]

Cecil Bayona <cbayona@cbayona.com> wrote:

A recurring theme all this talk of slower FPGA software. I been using
Lattice FPGA to create small CPUs and notice that the newer versions of
the Diamond software is considerably slower that some of the older
versions also by several factors. So one wonders how can all these
software packages suffer from a major slowdown in performance. Maybe
some commonly used libraries?

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

 

On Thursday, August 4, 2016 at 6:40:03 PM UTC+3, Theo Markettos wrote:

Cecil Bayona <cbayona@cbayona.com> wrote:
A recurring theme all this talk of slower FPGA software. I been using
Lattice FPGA to create small CPUs and notice that the newer versions of
the Diamond software is considerably slower that some of the older
versions also by several factors. So one wonders how can all these
software packages suffer from a major slowdown in performance. Maybe
some commonly used libraries?

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

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 designs, 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.

 

[Cecil Bayona]

A recurring theme all this talk of slower FPGA software. I been using
Lattice FPGA to create small CPUs and notice that the newer versions of
the Diamond software is considerably slower that some of the older
versions also by several factors. So one wonders how can all these
software packages suffer from a major slowdown in performance. Maybe
some commonly used libraries?

On 8/4/2016 7:20 AM, already5chosen@yahoo.com wrote:

On Thursday, July 28, 2016 at 2:21:26 AM UTC+3, Kevin Neilson wrote:
Vivado is supposed to be really fast, but I've noticed it parses really 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 time it because the error message appears while my pinky is still on the carriage 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 time.

Also, it takes over 3 minutes to P&R this design, which comprises a constant 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 synthesis. 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 know if they are caught in Verilog as well.

--
Cecil - k5nwa

 

[Cecil Bayona]

On 8/4/2016 10:39 AM, Theo Markettos wrote:

Cecil Bayona <cbayona@cbayona.com> wrote:
A recurring theme all this talk of slower FPGA software. I been using
Lattice FPGA to create small CPUs and notice that the newer versions of
the Diamond software is considerably slower that some of the older
versions also by several factors. So one wonders how can all these
software packages suffer from a major slowdown in performance. Maybe
some commonly used libraries?

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.
--
Cecil - k5nwa

 

[rickman]

On 8/4/2016 11:55 AM, Cecil Bayona wrote:

On 8/4/2016 10:39 AM, Theo Markettos wrote:
Cecil Bayona <cbayona@cbayona.com> wrote:
A recurring theme all this talk of slower FPGA software. I been using
Lattice FPGA to create small CPUs and notice that the newer versions of
the Diamond software is considerably slower that some of the older
versions also by several factors. So one wonders how can all these
software packages suffer from a major slowdown in performance. Maybe
some commonly used libraries?

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.

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.

--

Rick C

 

[Kevin Neilson]

On Wednesday, August 3, 2016 at 10:51:18 AM UTC-6, Kevin Neilson wrote:
> Yes, these results do seem unreasonably bad. I'll try a different computer.

I tried a different computer and got the same results.

 

On Friday, August 5, 2016 at 7:12:13 PM UTC+3, Kevin Neilson wrote:

On Wednesday, August 3, 2016 at 10:51:18 AM UTC-6, Kevin Neilson wrote:
Yes, these results do seem unreasonably bad. I'll try a different computer.

I tried a different computer and got the same results.

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

 

On Sunday, August 7, 2016 at 2:14:48 AM UTC+3, already...@yahoo.com wrote:

On Friday, August 5, 2016 at 7:12:13 PM UTC+3, Kevin Neilson wrote:
On Wednesday, August 3, 2016 at 10:51:18 AM UTC-6, Kevin Neilson wrote:
Yes, these results do seem unreasonably bad. I'll try a different computer.

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 <= not ff;
end if;
end process;

dout <= ff;

end architecture a;

----- end of one_ff.vhd



---- one_ff.xdc

set_property IOSTANDARD LVCMOS25 [get_ports clk]
set_property IOSTANDARD LVCMOS25 [get_ports dout]

set_property PACKAGE_PIN L12 [get_ports clk]
set_property PACKAGE_PIN H12 [get_ports dout]

create_clock -period 10.0 -name clk [get_ports clk]


---- end of one_ff.xdc


---- one_ff.xpr
<?xml version="1.0" encoding="UTF-8"?>
<!-- Product Version: Vivado v2016.1 (64-bit) -->
<!-- -->
<!-- Copyright 1986-2016 Xilinx, Inc. All Rights Reserved. -->

<Project Version="7" Minor="12" Path="C:/xxx/one_ff.xpr">
<DefaultLaunch Dir="$PRUNDIR"/>
<Configuration>
<Option Name="Id" Val="0dc300cc961141dfa832739f8361bf18"/>
<Option Name="Part" Val="xc7z010iclg225-1L"/>
<Option Name="CompiledLibDir" Val="$PCACHEDIR/compile_simlib"/>
<Option Name="CompiledLibDirXSim" Val=""/>
<Option Name="TargetLanguage" Val="VHDL"/>
<Option Name="BoardPart" Val=""/>
<Option Name="ActiveSimSet" Val="sim_1"/>
<Option Name="DefaultLib" Val="xil_defaultlib"/>
<Option Name="EnableCoreContainer" Val="FALSE"/>
<Option Name="CreateRefXciForCoreContainers" Val="FALSE"/>
<Option Name="IPUserFilesDir" Val="$PPRDIR/one_ff.ip_user_files"/>
<Option Name="IPStaticSourceDir" Val="$PPRDIR/one_ff.ip_user_files/ipstatic"/>
<Option Name="EnableBDX" Val="FALSE"/>
<Option Name="WTXSimLaunchSim" Val="0"/>
<Option Name="WTModelSimLaunchSim" Val="0"/>
<Option Name="WTQuestaLaunchSim" Val="0"/>
<Option Name="WTIesLaunchSim" Val="0"/>
<Option Name="WTVcsLaunchSim" Val="0"/>
<Option Name="WTRivieraLaunchSim" Val="0"/>
<Option Name="WTActivehdlLaunchSim" Val="0"/>
<Option Name="WTXSimExportSim" Val="0"/>
<Option Name="WTModelSimExportSim" Val="0"/>
<Option Name="WTQuestaExportSim" Val="0"/>
<Option Name="WTIesExportSim" Val="0"/>
<Option Name="WTVcsExportSim" Val="0"/>
<Option Name="WTRivieraExportSim" Val="0"/>
<Option Name="WTActivehdlExportSim" Val="0"/>
<Option Name="GenerateIPUpgradeLog" Val="TRUE"/>
</Configuration>
<FileSets Version="1" Minor="31">
<FileSet Name="sources_1" Type="DesignSrcs" RelSrcDir="$PSRCDIR/sources_1">
<Filter Type="Srcs"/>
<File Path="$PPRDIR/one_ff.vhd">
<FileInfo>
<Attr Name="UsedIn" Val="synthesis"/>
<Attr Name="UsedIn" Val="simulation"/>
</FileInfo>
</File>
<Config>
<Option Name="DesignMode" Val="RTL"/>
<Option Name="TopModule" Val="one_ff"/>
<Option Name="TopAutoSet" Val="TRUE"/>
</Config>
</FileSet>
<FileSet Name="constrs_1" Type="Constrs" RelSrcDir="$PSRCDIR/constrs_1">
<Filter Type="Constrs"/>
<File Path="$PPRDIR/one_ff.xdc">
<FileInfo>
<Attr Name="UsedIn" Val="implementation"/>
</FileInfo>
</File>
<Config>
<Option Name="ConstrsType" Val="XDC"/>
</Config>
</FileSet>
<FileSet Name="sim_1" Type="SimulationSrcs" RelSrcDir="$PSRCDIR/sim_1">
<Filter Type="Srcs"/>
<Config>
<Option Name="DesignMode" Val="RTL"/>
<Option Name="TopModule" Val="one_ff"/>
<Option Name="TopLib" Val="xil_defaultlib"/>
<Option Name="TopAutoSet" Val="TRUE"/>
<Option Name="TransportPathDelay" Val="0"/>
<Option Name="TransportIntDelay" Val="0"/>
<Option Name="SrcSet" Val="sources_1"/>
</Config>
</FileSet>
</FileSets>
<Simulators>
<Simulator Name="XSim">
<Option Name="Description" Val="Vivado Simulator"/>
<Option Name="CompiledLib" Val="0"/>
</Simulator>
<Simulator Name="ModelSim">
<Option Name="Description" Val="ModelSim Simulator"/>
</Simulator>
<Simulator Name="Questa">
<Option Name="Description" Val="Questa Advanced Simulator"/>
</Simulator>
<Simulator Name="IES">
<Option Name="Description" Val="Incisive Enterprise Simulator (IES)"/>
</Simulator>
<Simulator Name="VCS">
<Option Name="Description" Val="Verilog Compiler Simulator (VCS)"/>
</Simulator>
<Simulator Name="Riviera">
<Option Name="Description" Val="Riviera-PRO Simulator"/>
</Simulator>
<Simulator Name="ActiveHDL">
<Option Name="Description" Val="Active-HDL Simulator"/>
</Simulator>
</Simulators>
<Runs Version="1" Minor="10">
<Run Id="synth_1" Type="Ft3:Synth" SrcSet="sources_1" Part="xc7z010iclg225-1L" ConstrsSet="constrs_1" Description="Vivado Synthesis Defaults" State="current" Dir="$PRUNDIR/synth_1" IncludeInArchive="true">
<Strategy Version="1" Minor="2">
<StratHandle Name="Vivado Synthesis Defaults" Flow="Vivado Synthesis 2016"/>
<Step Id="synth_design"/>
</Strategy>
<GeneratedRun Dir="$PRUNDIR" File="gen_run.xml"/>
</Run>
<Run Id="impl_1" Type="Ft2:EntireDesign" Part="xc7z010iclg225-1L" ConstrsSet="constrs_1" Description="Default settings for Implementation." State="current" Dir="$PRUNDIR/impl_1" SynthRun="synth_1" IncludeInArchive="true">
<Strategy Version="1" Minor="2">
<StratHandle Name="Vivado Implementation Defaults" Flow="Vivado Implementation 2016"/>
<Step Id="init_design"/>
<Step Id="opt_design"/>
<Step Id="power_opt_design"/>
<Step Id="place_design"/>
<Step Id="post_place_power_opt_design"/>
<Step Id="phys_opt_design"/>
<Step Id="route_design"/>
<Step Id="post_route_phys_opt_design"/>
<Step Id="write_bitstream"/>
</Strategy>
<GeneratedRun Dir="$PRUNDIR" File="gen_run.xml"/>
</Run>
</Runs>
</Project>

---- end of one_ff.xpr

According to my measurements synthesis took ~15s, implementation ~40s and write_bitstream ~20s. When launched together all three took ~65s.
Which is ridiculous, but somewhat less ridiculous than your results.

 

On Friday, August 5, 2016 at 12:04:52 AM UTC+3, rickman wrote:

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.

--

Rick C

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.