Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMar2019

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 159100

Article: 159100
Subject: Re: Vivado parses wicked slow
From: already5chosen@yahoo.com
Date: Thu, 28 Jul 2016 15:32:22 -0700 (PDT)
Links: << >>  << T >>  << A >>
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 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.
> >=20
> > Also, it takes over 3 minutes to P&R this design, which comprises a con=
stant mult with 50 LUTs.  Seems pretty slow.
>=20
> If Brand X isn't up to snuff, maybe switch to Brand I, formerly A.
>=20
> Kevin Jennings

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.



Article: 159101
Subject: pin configuration for I2C on altera Max 10 using i2c_opencores IP
From: tomberge@gmail.com
Date: Fri, 29 Jul 2016 01:21:44 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi,

I am using a max 10 FPGA, and trying to communicate with an I2C slave.
I am using the HSMC connector to connect to another board where the I2C sla=
ve is located.
I have tested the SDA and SCL lines, so I know they are mapped through the =
HSMC port correctly. Then I added pullup resistors to the I2C slave PCB, pu=
lling the line to 3.3v. However, when I program the FPGA both SDA and SCL l=
ines get pulled down to 1.9V, so it seems like they are driving against the=
 pullup instead if beeing tri-stated?
I have added OPNDRN primitives to the output pins and according to the synt=
hesis report, the output pins are configures as opendrain. Is there any oth=
er type of configuration that needs to be set?

Article: 159102
Subject: Re: pin configuration for I2C on altera Max 10 using i2c_opencores IP
From: BobH <wanderingmetalhead.nospam.please@yahoo.com>
Date: Fri, 29 Jul 2016 06:55:40 -0700
Links: << >>  << T >>  << A >>
On 07/29/2016 01:21 AM, tomberge@gmail.com wrote:
> Hi,
>
> I am using a max 10 FPGA, and trying to communicate with an I2C slave.
> I am using the HSMC connector to connect to another board where the I2C slave is located.
> I have tested the SDA and SCL lines, so I know they are mapped through the HSMC port correctly. Then I added pullup resistors to the I2C slave PCB, pulling the line to 3.3v. However, when I program the FPGA both SDA and SCL lines get pulled down to 1.9V, so it seems like they are driving against the pullup instead if beeing tri-stated?
> I have added OPNDRN primitives to the output pins and according to the synthesis report, the output pins are configures as opendrain. Is there any other type of configuration that needs to be set?
>
Your output structure needs to support it. In Verilog, this works:

tri1 SCL, SDA;   // out to pins

// internal use signals
wire SCL_in, SDA_in;
wire SDA_out, SCL_out;

// hookup the pin signals
assign SDA = SDA_out ? 1'bz : 1'b0;
assign SCL = SCL_out ? 1'bz : 1'b0;

// grab the input values
assign SCL_in = SCL;
assign SDA_in = SDA;



Article: 159103
Subject: Re: pin configuration for I2C on altera Max 10 using i2c_opencores
From: Tim Wescott <seemywebsite@myfooter.really>
Date: Fri, 29 Jul 2016 12:56:12 -0500
Links: << >>  << T >>  << A >>
On Fri, 29 Jul 2016 01:21:44 -0700, tomberge wrote:

> Hi,
> 
> I am using a max 10 FPGA, and trying to communicate with an I2C slave.
> I am using the HSMC connector to connect to another board where the I2C
> slave is located.
> I have tested the SDA and SCL lines, so I know they are mapped through
> the HSMC port correctly. Then I added pullup resistors to the I2C slave
> PCB, pulling the line to 3.3v. However, when I program the FPGA both SDA
> and SCL lines get pulled down to 1.9V, so it seems like they are driving
> against the pullup instead if beeing tri-stated?
> I have added OPNDRN primitives to the output pins and according to the
> synthesis report, the output pins are configures as opendrain. Is there
> any other type of configuration that needs to be set?

What is powering that output bank?  If it's powered by 1.8V, are the pins 
compatible with higher supply voltages?  1.9V sounds like an open-drain 
output that's powered by 1.8V and isn't 3.3V compatible.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

I'm looking for work -- see my website!

Article: 159104
Subject: Re: Lattice Diamond 3.7 and Synplify
From: Brian Davis <brimdavis@aol.com>
Date: Fri, 29 Jul 2016 16:25:50 -0700 (PDT)
Links: << >>  << T >>  << A >>
rickman wrote:
>
> I have already tried running Synplify manually and it does not start 
> bringing up an error report that doesn't say anything about the error
>
Just to clarify, does that same error also happen if you run Synplify completely outside of Diamond, from the Start Menu under Lattice_Diamond_xxx/Accessories?

>
> returns an error 3 when from from within Diamond. 
>
>From page 496 of C:\lscc\diamond\3.7_x64\synpbase\doc\user_guide.pdf
"
" The software uses the following error codes:
" 0 - OK
" 2 - logical error
" 3 - startup failure
" 4 - licensing failure
" ...
"

'Startup Failure' sounds to me like an install or DLL issue- I'd try a clean install and/or running under a DLL checker like DependencyWalker.

-Brian


Article: 159105
Subject: Re: Lattice Diamond 3.7 and Synplify
From: rickman <gnuarm@gmail.com>
Date: Fri, 29 Jul 2016 22:51:49 -0400
Links: << >>  << T >>  << A >>
On 7/29/2016 7:25 PM, Brian Davis wrote:
> rickman wrote:
>>
>> I have already tried running Synplify manually and it does not start
>> bringing up an error report that doesn't say anything about the error
>>
> Just to clarify, does that same error also happen if you run Synplify completely outside of Diamond, from the Start Menu under Lattice_Diamond_xxx/Accessories?
>
>>
>> returns an error 3 when from from within Diamond.
>>
> From page 496 of C:\lscc\diamond\3.7_x64\synpbase\doc\user_guide.pdf
> "
> " The software uses the following error codes:
> " 0 - OK
> " 2 - logical error
> " 3 - startup failure
> " 4 - licensing failure
> " ...
> "
>
> 'Startup Failure' sounds to me like an install or DLL issue- I'd try a clean install and/or running under a DLL checker like DependencyWalker.

Thanks for the info.  I've already done the uninstall and install again 
thing.  How do you trouble shoot something like this?  I'm getting zero 
help from Lattice.

-- 

Rick C

Article: 159106
Subject: Re: Constant Mult: The State of High Level Synth (Part II)
From: Johann Klammer <klammerj@NOSPAM.a1.net>
Date: Sat, 30 Jul 2016 11:56:25 +0200
Links: << >>  << T >>  << A >>
On 07/28/2016 03:48 AM, Kevin Neilson wrote:
> Interestingly, the following loop also implements the multiply as a
> lookup table with 1 LUT per output bit without having to write out
> the case statement.
> 
> reg [5:0] x; integer   ii; always@(posedge i_clk) for (ii=0; ii<64;
> ii=ii+1) if (x==ii) p <= 956*ii;
> 
> 
> One thing you have to do in this field is to constantly look at the
> synthesized design to see if it came out how you'd planned.  That is
> something high-level users aren't supposed to have to do.  Imagine if
> a Javascript coder had to look at the compiled machine code to see if
> the compiler did what he wanted.  I don't think they work on that
> level.
> 
looks like they don't do optimization on that stuff...
have you tried yosys? I'm pretty sure It'll do that for you. 
or perhaps bare ABC... if you have some other way to convert 
to blif or AIG or sthg...

or perhaps you've missed some synth option...?





Article: 159107
Subject: Re: Constant Mult: The State of High Level Synth (Part II)
From: Kevin Neilson <kevin.neilson@xilinx.com>
Date: Sat, 30 Jul 2016 12:11:28 -0700 (PDT)
Links: << >>  << T >>  << A >>
I imagine Synplify would do a better job, but I don't have it.  It seems li=
ke Vivado just wants to do any multiplication in a DSP48, and if you don't =
do that, it has poor heuristics.  If I were going to need this a lot, I'd j=
ust make my own function with some good heuristics (e.g., if it's a constan=
t mult and the constant has a CSD representation with <=3D3 ones, then use =
a ternary adder...).  I would've expected these rules to have been build in=
to the synthesizer, though.  It's pretty basic.

Article: 159108
Subject: Re: Constant Mult: The State of High Level Synth (Part II)
From: Tim Wescott <tim@seemywebsite.com>
Date: Sat, 30 Jul 2016 14:43:05 -0500
Links: << >>  << T >>  << A >>
On Sat, 30 Jul 2016 12:11:28 -0700, Kevin Neilson wrote:

> I imagine Synplify would do a better job, but I don't have it.  It seems
> like Vivado just wants to do any multiplication in a DSP48, and if you
> don't do that, it has poor heuristics.  If I were going to need this a
> lot, I'd just make my own function with some good heuristics (e.g., if
> it's a constant mult and the constant has a CSD representation with <=3
> ones, then use a ternary adder...).  I would've expected these rules to
> have been build into the synthesizer, though.  It's pretty basic.

Speaking as someone who does mostly software and circuit design, with 
enough FPGA knowledge to be dangerous -- the optimizer doesn't seem to be 
trying very hard.

-- 
Tim Wescott
Control systems, embedded software and circuit design
I'm looking for work!  See my website if you're interested
http://www.wescottdesign.com

Article: 159109
Subject: Re: Constant Mult: The State of High Level Synth (Part II)
From: Tim Wescott <tim@seemywebsite.com>
Date: Sat, 30 Jul 2016 14:44:12 -0500
Links: << >>  << T >>  << A >>
On Sat, 30 Jul 2016 12:11:28 -0700, Kevin Neilson wrote:

> I imagine Synplify would do a better job, but I don't have it.  It seems
> like Vivado just wants to do any multiplication in a DSP48, and if you
> don't do that, it has poor heuristics.  If I were going to need this a
> lot, I'd just make my own function with some good heuristics (e.g., if
> it's a constant mult and the constant has a CSD representation with <=3
> ones, then use a ternary adder...).  I would've expected these rules to
> have been build into the synthesizer, though.  It's pretty basic.

Could it be that when you tell the thing to not use a DSP block it's 
interpreting that to mean "just don't optimize this"?

-- 
Tim Wescott
Control systems, embedded software and circuit design
I'm looking for work!  See my website if you're interested
http://www.wescottdesign.com

Article: 159110
Subject: Re: Altera Ethernet MAC without DMA
From: Jakab Tanko <jakab.tanko@gmail.com>
Date: Sun, 31 Jul 2016 23:10:57 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Thursday, July 28, 2016 at 12:09:12 PM UTC+2, Theo Markettos wrote:
> Jakab Tanko <jakab.tanko@gmail.com> wrote:
> > Hi all,
> > 
> > I have a design that uses Altera Ethernet MAC and 
> > I would like to connect it to NIOS without DMA.
> > Any suggestions? 
> 
> The MAC (at least the 10G MAC which I've worked with) has Avalon stream
> pipes in and out for packet data.  So you just need something to generate a
> stream of 64 bit words.  The Altera supplied stream-to-memory-mapped
> components only go as wide as 32 bits.  So I wrote a very simple FIFO to
> stream converter, with 64 bit Avalon ST and 32 bit Avalon MM ports.  Write
> words into a pair of 32 bit FIFO registers, 64 bit words come out on the
> stream.  Another register handles start-of-packet/end-of-packet bits.
> 
> You probably don't want my code (it's in Bluespec), but it shouldn't take
> long to write something similar.  Alternatively you could use the Altera 32
> bit components and make something to double up two words on a 32 bit stream
> to be a single 64 bit stream word.
> 
> Theo

Hi Theo,

Thanks for the reply,
In this design I have the 1G MAC but the problem is the same;
Can't connect Avalon streaming ports (ST) to the NIOS directly
so I will follow what you did and build my own bridge(s),

Cheers,
Jakab

Article: 159111
Subject: Re: Vivado parses wicked slow
From: already5chosen@yahoo.com
Date: Tue, 2 Aug 2016 03:34:22 -0700 (PDT)
Links: << >>  << T >>  << A >>
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 real=
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.
> > >=20
> > > Also, it takes over 3 minutes to P&R this design, which comprises a c=
onstant mult with 50 LUTs.  Seems pretty slow.
> >=20
> > If Brand X isn't up to snuff, maybe switch to Brand I, formerly A.
> >=20
> > Kevin Jennings
>=20
> Quartus2 v.15.x suffers from similar problems.
> Finding syntax errors in small designs is 10-20 times slower than, for ex=
ample, 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 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.



Article: 159112
Subject: Re: Vivado parses wicked slow
From: Kevin Neilson <kevin.neilson@xilinx.com>
Date: Tue, 2 Aug 2016 09:51:34 -0700 (PDT)
Links: << >>  << T >>  << A >>
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.

Article: 159113
Subject: Re: Vivado parses wicked slow
From: already5chosen@yahoo.com
Date: Wed, 3 Aug 2016 04:02:19 -0700 (PDT)
Links: << >>  << T >>  << A >>
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 woul=
d parse & synthesize small designs in a matter of seconds.  On the other ha=
nd, I made a test case for Vivado:
>=20
> Vivado 2016.2 Test Case:  Module with One Flipflop
> ---------------------------------------------------
> Synthesis time:  58s
> Place & Route:  1:58s
> Synth & PAR Together:  2:40
>=20
> 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 differen=
t things on these small designs eats up a lot of my time.=20
>=20
> 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 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=20

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.


Article: 159114
Subject: Re: Vivado parses wicked slow
From: Kevin Neilson <kevin.neilson@xilinx.com>
Date: Wed, 3 Aug 2016 09:51:14 -0700 (PDT)
Links: << >>  << T >>  << A >>
Yes, these results do seem unreasonably bad.  I'll try a different computer.

Article: 159115
Subject: Re: Vivado parses wicked slow
From: Leonardo <capossio.leonardo@gmail.com>
Date: Thu, 4 Aug 2016 03:16:16 -0700 (PDT)
Links: << >>  << T >>  << A >>
El jueves, 28 de julio de 2016, 22:53:29 (UTC+10), Gabor escribi=C3=B3:
> 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 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.
> >=20
> > Also, it takes over 3 minutes to P&R this design, which comprises a con=
stant mult with 50 LUTs.  Seems pretty slow.
>=20
> 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.
>=20
> 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.
>=20
> By the way, when you say Vivado took 20 seconds to find the error,
> was that running simulation or synthesis?
>=20
> --=20
> Gabor

The multi-driven net problem was a headache in=20
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.

Article: 159116
Subject: Re: Vivado parses wicked slow
From: already5chosen@yahoo.com
Date: Thu, 4 Aug 2016 05:20:33 -0700 (PDT)
Links: << >>  << T >>  << A >>
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 s=
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.
>=20
> Also, it takes over 3 minutes to P&R this design, which comprises a const=
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.

Article: 159117
Subject: Re: Vivado parses wicked slow
From: Cecil Bayona <cbayona@cbayona.com>
Date: Thu, 4 Aug 2016 10:05:31 -0500
Links: << >>  << T >>  << A >>
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

Article: 159118
Subject: Re: Vivado parses wicked slow
From: Theo Markettos <theom+news@chiark.greenend.org.uk>
Date: 04 Aug 2016 16:39:58 +0100 (BST)
Links: << >>  << T >>  << A >>
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

Article: 159119
Subject: Re: Vivado parses wicked slow
From: Cecil Bayona <cbayona@cbayona.com>
Date: Thu, 4 Aug 2016 10:55:03 -0500
Links: << >>  << T >>  << A >>


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

Article: 159120
Subject: Re: Vivado parses wicked slow
From: already5chosen@yahoo.com
Date: Thu, 4 Aug 2016 11:13:39 -0700 (PDT)
Links: << >>  << T >>  << A >>
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=
=20
> > Lattice FPGA to create small CPUs and notice that the newer versions of=
=20
> > the Diamond software is considerably slower that some of the older=20
> > versions also by several factors. So one wonders how can all these=20
> > software packages suffer from a major slowdown in performance. Maybe=20
> > some commonly used libraries?
>=20
> My guess would be the synthesis process has become more heavyweight as ti=
me
> has gone on.  Modern FPGAs are much larger than older ones, which means m=
ore
> housekeeping / management of data structures, databases, libraries etc an=
d a
> more complex flow.
>=20
> 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=
.
>=20
> 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 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.

Article: 159121
Subject: Re: Vivado parses wicked slow
From: rickman <gnuarm@gmail.com>
Date: Thu, 4 Aug 2016 17:04:49 -0400
Links: << >>  << T >>  << A >>
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

Article: 159122
Subject: Re: Vivado parses wicked slow
From: Kevin Neilson <kevin.neilson@xilinx.com>
Date: Fri, 5 Aug 2016 09:12:03 -0700 (PDT)
Links: << >>  << T >>  << A >>
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.

Article: 159123
Subject: Re: Vivado parses wicked slow
From: already5chosen@yahoo.com
Date: Sat, 6 Aug 2016 16:14:45 -0700 (PDT)
Links: << >>  << T >>  << A >>
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?

Article: 159124
Subject: Re: Vivado parses wicked slow
From: already5chosen@yahoo.com
Date: Sun, 7 Aug 2016 07:12:03 -0700 (PDT)
Links: << >>  << T >>  << A >>
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.




Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMar2019

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search