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 159075

Article: 159075
Subject: Re: Mod-24: The State of High-Level Synthesis in 2016
From: Kevin Neilson <kevin.neilson@xilinx.com>
Date: Tue, 26 Jul 2016 10:43:20 -0700 (PDT)
Links: << >>  << T >>  << A >>
That's what they like to say.  It sounds nice.  But software engineers still can't program parallel processor arrays well, let alone FPGAs. 

These tools can all make a functional FPGA, but if it uses too many gates and has too many levels of logic, you're better off using software.

Article: 159076
Subject: Re: Mod-24: The State of High-Level Synthesis in 2016
From: rickman <gnuarm@gmail.com>
Date: Tue, 26 Jul 2016 13:43:40 -0400
Links: << >>  << T >>  << A >>
On 7/26/2016 1:30 PM, Kevin Neilson wrote:
> They did claim that software engineers with no hardware experience could be designing FPGAs after a very short training period.  Which might have been true.  But there's a difference between doing FPGAs and doing them well.

I suppose the proof of the pudding is in the eating.  Who is using this 
tool for production in this way?

-- 

Rick C

Article: 159077
Subject: Re: Mod-24: The State of High-Level Synthesis in 2016
From: Tom Gardner <spamjunk@blueyonder.co.uk>
Date: Tue, 26 Jul 2016 18:50:15 +0100
Links: << >>  << T >>  << A >>
On 26/07/16 18:43, Kevin Neilson wrote:
> That's what they like to say.  It sounds nice.  But software engineers still can't program parallel processor arrays well, let alone FPGAs.
>
> These tools can all make a functional FPGA, but if it uses too many gates and has too many levels of logic, you're better off using software.

Be aware that the "high frequency trading" mob put
trading algorithms (i.e if X then buy shares Y)
into FPGAs to shave off the odd millisecond latency.
Obviously development turnaround time for the
algorithms is very important.

That's a good use-case for software->gates.

They've also laid their own $600m trans-Atlantic
fibre optic cable to avoid contention and latency,
and have bought up all the microwave transmission
towers between Chicago and New York because the
speed of light in fibres is noticeably slower than
that in air.


Article: 159078
Subject: Re: Xilinx Platform cable USB and impact on linux without windrvr
From: Johann Klammer <klammerj@NOSPAM.a1.net>
Date: Tue, 26 Jul 2016 19:52:23 +0200
Links: << >>  << T >>  << A >>
On 07/25/2016 08:03 PM, adityaishwar1994@gmail.com wrote:
> Getting following error at make step:
> 
> adityapappu@adityapappu-NV55C:/opt/Xilinx/usb-driver$ make cc -Wall
> -fPIC -DUSB_DRIVER_VERSION="\"2016-07-23 20:34:57\""  usb-driver.c
> xpcu.c parport.c config.c jtagmon.c -o libusb-driver.so -ldl -lusb
> -lpthread -shared parport.c: In function ‘parport_transfer’: 
> parport.c:21:23: warning: variable ‘last_pp_write’ set but not used
> [-Wunused-but-set-variable] static unsigned char last_pp_write = 0; 
> ^ /usr/bin/ld: cannot open output file libusb-driver.so: Permission
> denied collect2: error: ld returned 1 exit status Makefile:28: recipe
> for target 'libusb-driver.so' failed make: *** [libusb-driver.so]
> Error 1 adityapappu@adityapappu-NV55C:/opt/Xilinx/usb-driver$
> 
The first one is a warning and may be harmless, the second one says 
it can not open libusb-driver.so: Permission denied. 
check the permissions. Perhaps you had run the build before as root. 
and now it can not overwrite the file, but that is just a guess... 



Article: 159079
Subject: Re: Mod-24: The State of High-Level Synthesis in 2016
From: gtwrek@sonic.net (Mark Curry)
Date: Tue, 26 Jul 2016 22:59:24 -0000 (UTC)
Links: << >>  << T >>  << A >>
In article <5792e5fa$0$2798$c3e8da3$76491128@news.astraweb.com>,
Allan Herriman  <allanherriman@hotmail.com> wrote:
>
>I find it easy to ignore HLS, but I still suffer from it because it 
>splits the tool vendors' development budget across multiple tools.
>
>
>I got all excited when I first heard about high level synthesis.  Then I 
>discovered that the language was C - hardly high level, and not 
>particularly well suited to the sorts of things that FPGA coders need to 
>do.
>It's not about making a better language though - it's about allowing non-
>FPGA people to do FPGA things, all in the name of market share.

"High Level Synthesis" tools, IMHO are poorly named.  Most of the current
incantations don't move the design abstraction level up.  Rather, they 
force the abstraction LOWER for the software engineering person.

My software team could use HLS tools.  They'd have a learning curve to lower
their current abtraction level.  They'd need to start "thinking hardware", and
consider the inherent parallelism of hardware.

They're quite capable of this.  Problem is they DONT WANT to.  They'd prefer
to be moving their software coding to a higher level of abstraction (through
advances is SW languages and techniques). Then leave all these 
"fiddly hardware details" to the hardware designers.

For the hardware designers, C (or C++) is a very poor basis for a hardware
description language.

So HLS continues its small market penetration of "unique" designs only...

Regards,

Mark 

Article: 159080
Subject: Re: Mod-24: The State of High-Level Synthesis in 2016
From: Kevin Neilson <kevin.neilson@xilinx.com>
Date: Tue, 26 Jul 2016 17:11:45 -0700 (PDT)
Links: << >>  << T >>  << A >>
I think Celoxica is defunct.

Article: 159081
Subject: Re: Mod-24: The State of High-Level Synthesis in 2016
From: Theo Markettos <theom+news@chiark.greenend.org.uk>
Date: 27 Jul 2016 11:14:26 +0100 (BST)
Links: << >>  << T >>  << A >>
Mark Curry <gtwrek@sonic.net> wrote:
> They're quite capable of this.  Problem is they DONT WANT to.  They'd prefer
> to be moving their software coding to a higher level of abstraction (through
> advances is SW languages and techniques). Then leave all these 
> "fiddly hardware details" to the hardware designers.

Indeed.  It puzzles me why hardware designers would think that a pile of
nested for loops consist of a high level abstraction.

If we're concentrating on compute to the exclusion of all else (as HLS seems
to), the algorithm might be defined in terms of matrix operations, so surely
it's that which should be the input to the HLS toolchain?  In a matrix
multiply, say, the parallelism is inherent and it is friendly to the
programmer: they want to compute matA*matB and all the other details can be
left to the tool to figure out.  At the very least it leaves plenty more
scope for the tool to improve, rather than trying to unpick C loops that
represent matA*matB.

Matlab isn't a great language for many reasons, but it does make it possible
to write code with implicit parallelism pretty easily, without even thinking
about it.  That would be heading towards my definition of 'high level'.

(I'm not familiar with Simulink-to-gates flows, because I'm not a great fan
of schematics.  Perhaps the tools are better in this space)

Theo

Article: 159082
Subject: Re: Mod-24: The State of High-Level Synthesis in 2016
From: rickman <gnuarm@gmail.com>
Date: Wed, 27 Jul 2016 10:41:04 -0400
Links: << >>  << T >>  << A >>
On 7/26/2016 8:11 PM, Kevin Neilson wrote:
> I think Celoxica is defunct.

So there it is!

-- 

Rick C

Article: 159083
Subject: Re: Mod-24: The State of High-Level Synthesis in 2016
From: Jecel <jecel@merlintec.com>
Date: Wed, 27 Jul 2016 10:33:57 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Wednesday, July 27, 2016 at 11:41:11 AM UTC-3, rickman wrote:
> On 7/26/2016 8:11 PM, Kevin Neilson wrote:
> > I think Celoxica is defunct.
> 
> So there it is!

Celoxica was a very successful company that was bought out by
a much larger competitor and immediately shut down. This left
many customers who loved the product without any good options.

And this is why I refuse to use non open source tools no matter
what advantages they claim to have. You can't know if they will
still be available tomorrow. The exception (for now) is the
vendor tools for generating the FPGA bitfiles.

-- Jecel

Article: 159084
Subject: Re: Mod-24: The State of High-Level Synthesis in 2016
From: rickman <gnuarm@gmail.com>
Date: Wed, 27 Jul 2016 14:05:52 -0400
Links: << >>  << T >>  << A >>
On 7/27/2016 1:33 PM, Jecel wrote:
> On Wednesday, July 27, 2016 at 11:41:11 AM UTC-3, rickman wrote:
>> On 7/26/2016 8:11 PM, Kevin Neilson wrote:
>>> I think Celoxica is defunct.
>>
>> So there it is!
>
> Celoxica was a very successful company that was bought out by
> a much larger competitor and immediately shut down. This left
> many customers who loved the product without any good options.
>
> And this is why I refuse to use non open source tools no matter
> what advantages they claim to have. You can't know if they will
> still be available tomorrow. The exception (for now) is the
> vendor tools for generating the FPGA bitfiles.

At least with open source tools you can't be disappointed by a total 
lack of support.  My installation of Lattice Diamond errors out when I 
perform synthesis and I can't get any help from the vendor support... at 
all!

-- 

Rick C

Article: 159085
Subject: Re: Mod-24: The State of High-Level Synthesis in 2016
From: Kevin Neilson <kevin.neilson@xilinx.com>
Date: Wed, 27 Jul 2016 14:46:55 -0700 (PDT)
Links: << >>  << T >>  << A >>
Even with your example of a matrix multiplication, there is still a lot to =
figure out.  For one thing, you usually have to fold the multiplication bec=
ause you don't have the resources to do the whole thing in parallel.  The M=
atlab->gates tool that I used once is long gone.

I just spent several days implementing a design that I modeled in two lines=
 of Matlab code.  For a tool to have converted those two lines into a good =
hardware implementation would've been difficult.

Article: 159086
Subject: Re: Mod-24: The State of High-Level Synthesis in 2016
From: Kevin Neilson <kevin.neilson@xilinx.com>
Date: Wed, 27 Jul 2016 14:49:59 -0700 (PDT)
Links: << >>  << T >>  << A >>
The high-level design tools I've used weren't very abstracted.  To make something work well, I had to keep moving to lower levels of abstraction.  In tool that was supposed to be high-level I found myself instantiating DSP48s.  Not very abstract.

Article: 159087
Subject: Constant Mult: The State of High Level Synth (Part II)
From: Kevin Neilson <kevin.neilson@xilinx.com>
Date: Wed, 27 Jul 2016 16:16:13 -0700 (PDT)
Links: << >>  << T >>  << A >>
Here's another example that shows just how far removed we are from high-level synthesis.

I need to multiply a 10-bit number by 956.  I could use a DSP48, but it's overkill, and to meet timing I'd probably have to pipeline it fully and have 3 cycles of latency.  So I write this code and force Vivado not to use DSP48s:

reg  [9:0] x;  // multiplicand
reg [19:0] p; // product
always@(posedge clk) 
  p <= x*956;

This has 58 LUTs, 3 separate columns of carry chains, and fails timing at my clock speed.

I'd guess that the synthesizer fully optimizes a simple constant multiplier, but just for fun I go down a level of abstraction, looking at the binary representation of 956, and making a CSD (canonical signed digit) version:

reg  [9:0] x;  // multiplicand
reg [19:0] p; // product
always@(posedge clk) 
  p <= (x<<10) - (x<<6) - (x<<2);   // same as x*956

Results:  19 LUTs, meets timing with 850ps slack.  There is only 1 carry chain (ternary add?).

So what I am saying is that I can't even use the '*' sign.  I have to go down a level of abstraction in order to make a multiplier that will meet timing.  If I can't use the multiply sign, why would I believe I could use C code?

Article: 159088
Subject: Vivado parses wicked slow
From: Kevin Neilson <kevin.neilson@xilinx.com>
Date: Wed, 27 Jul 2016 16:21:09 -0700 (PDT)
Links: << >>  << T >>  << A >>
Vivado is supposed to be really fast, but I've noticed it parses really slo=
wly.  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 jus=
t 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 constan=
t mult with 50 LUTs.  Seems pretty slow.

Article: 159089
Subject: Re: Mod-24: The State of High-Level Synthesis in 2016
From: Theo Markettos <theom+news@chiark.greenend.org.uk>
Date: 28 Jul 2016 00:38:41 +0100 (BST)
Links: << >>  << T >>  << A >>
Kevin Neilson <kevin.neilson@xilinx.com> wrote:
> Even with your example of a matrix multiplication, there is still a lot to
> figure out.  For one thing, you usually have to fold the multiplication
> because you don't have the resources to do the whole thing in parallel. 
> The Matlab->gates tool that I used once is long gone.
> 
> I just spent several days implementing a design that I modeled in two
> lines of Matlab code.  For a tool to have converted those two lines into a
> good hardware implementation would've been difficult.

I agree, you can't expect the tool to just do it - there are many things
that need to be tweaked.  But those are architectural design choices, which
are different from writing Verilog or VHDL.  By all means expose the
tradeoffs to the designer in a way they understand, just don't make them
write HDL.  Software folks are familiar with the idea of different data
structures having difference performance qualities.  But by and large a
serial 'program' isn't a helpful way to expose tradeoffs to either the
software or hardware engineer.

As I said, this ignores the elephant in the room that is communication. 
Your C code has this illusion that it lives in a flat uniform memory space
because it's behind a cache, an MMU, a prefetcher and a standard library,
that do a lot of work (in terms of time, area and power) to make it look
that way.  To get good performance, you need both a way to write the compute
and a way to move the data around to the right place at the right time. 
'HLS' tools are usually poor at handling that: I don't know a HLS 'C to
gates' tool that it would make sense to write a cache in, for example.

Theo

Article: 159090
Subject: Re: Lattice Diamond 3.7 and Synplify
From: Brian Davis <brimdavis@aol.com>
Date: Wed, 27 Jul 2016 17:49:32 -0700 (PDT)
Links: << >>  << T >>  << A >>
rickman wrote:
>
> When I attempt to synthesize through the Diamond GUI 
> I get "error code 3".
>

1) Have you tried switching synthesis to LSE then back again?

2) Do you get the same error message if you run
   synthesis manually from within the Synplify GUI?
e.g.:
  - open project in Diamond
  - click the big red "S" in the toolbar 
     (which opens Synplify with the project sources)
  - hit "RUN" in Synplify
  - exit Synplify
  - back in Diamond, Design->Refresh Design to update status
  - run MAP and PAR as usual

-Brian

Article: 159091
Subject: Re: Constant Mult: The State of High Level Synth (Part II)
From: Kevin Neilson <kevin.neilson@xilinx.com>
Date: Wed, 27 Jul 2016 18:38:31 -0700 (PDT)
Links: << >>  << T >>  << A >>
I realized that in my application, x probably only needs to be 6 bits wide.=
  So I synthesized that, and got something with carry chains in it.  Wait a=
 minute... if each LUT is a 64-bit lookup table, wouldn't you synthesize a =
constant multiplication by a 6-bit multiplicand as a lookup, with 1 LUT per=
 output bit and 1 level of logic?  Yes, you would.  No carry chains.  But i=
n order to do that, I had to write the logic like this:

reg [5:0] x;
always@(posedge clk)
  case(x)
    0: p<=3D956*0;
    1: p<=3D 956*1;
...
    63: p<=3D956*63;
 endcase

Yes, that's how I had to write it.  High-level synthesis!

Article: 159092
Subject: Re: Vivado parses wicked slow
From: KJ <kkjennings@sbcglobal.net>
Date: Wed, 27 Jul 2016 18:47:48 -0700 (PDT)
Links: << >>  << T >>  << A >>
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 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.

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

Kevin Jennings

Article: 159093
Subject: Re: Constant Mult: The State of High Level Synth (Part II)
From: Kevin Neilson <kevin.neilson@xilinx.com>
Date: Wed, 27 Jul 2016 18:48:38 -0700 (PDT)
Links: << >>  << T >>  << A >>
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 statem=
ent.   =20

reg [5:0] x;
  integer   ii;
always@(posedge i_clk)
  for (ii=3D0; ii<64; ii=3Dii+1)
    if (x=3D=3Dii) p <=3D 956*ii;


One thing you have to do in this field is to constantly look at the synthes=
ized design to see if it came out how you'd planned.  That is something hig=
h-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 h=
e wanted.  I don't think they work on that level.

Article: 159094
Subject: Re: Lattice Diamond 3.7 and Synplify
From: rickman <gnuarm@gmail.com>
Date: Wed, 27 Jul 2016 23:13:18 -0400
Links: << >>  << T >>  << A >>
On 7/27/2016 8:49 PM, Brian Davis wrote:
> rickman wrote:
>>
>> When I attempt to synthesize through the Diamond GUI
>> I get "error code 3".
>>
>
> 1) Have you tried switching synthesis to LSE then back again?
>
> 2) Do you get the same error message if you run
>    synthesis manually from within the Synplify GUI?
> e.g.:
>   - open project in Diamond
>   - click the big red "S" in the toolbar
>      (which opens Synplify with the project sources)
>   - hit "RUN" in Synplify
>   - exit Synplify
>   - back in Diamond, Design->Refresh Design to update status
>   - run MAP and PAR as usual

Thanks for the suggestions.  I had already switched the tool too LSE and 
back because that's the only way to get the Diamond refresh tool to use 
VHDL-2008.  But I did it again and this time tried running the LSE 
synthesis which worked.  But I can't use LSE for the chip I am working 
with, an old XP device.

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, 
but tells me to call Synopsis support.

I recall that a license issue with Synplify returns an "error 2".  This 
returns an error 3 when from from within Diamond.

Why is Lattice support being such buttheads?  They asked me for a 
screenshot of the directory dialog for the installation directory which 
I provided.  Then no reply for a week and a half.  I've made two more 
replies with additional information and still nothing.

-- 

Rick C

Article: 159095
Subject: Re: Lattice Diamond 3.7 and Synplify
From: rickman <gnuarm@gmail.com>
Date: Wed, 27 Jul 2016 23:43:29 -0400
Links: << >>  << T >>  << A >>
On 7/27/2016 11:13 PM, rickman wrote:
> On 7/27/2016 8:49 PM, Brian Davis wrote:
>> rickman wrote:
>>>
>>> When I attempt to synthesize through the Diamond GUI
>>> I get "error code 3".
>>>
>>
>> 1) Have you tried switching synthesis to LSE then back again?
>>
>> 2) Do you get the same error message if you run
>>    synthesis manually from within the Synplify GUI?
>> e.g.:
>>   - open project in Diamond
>>   - click the big red "S" in the toolbar
>>      (which opens Synplify with the project sources)
>>   - hit "RUN" in Synplify
>>   - exit Synplify
>>   - back in Diamond, Design->Refresh Design to update status
>>   - run MAP and PAR as usual
>
> Thanks for the suggestions.  I had already switched the tool too LSE and
> back because that's the only way to get the Diamond refresh tool to use
> VHDL-2008.  But I did it again and this time tried running the LSE
> synthesis which worked.  But I can't use LSE for the chip I am working
> with, an old XP device.
>
> 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,
> but tells me to call Synopsis support.
>
> I recall that a license issue with Synplify returns an "error 2".  This
> returns an error 3 when from from within Diamond.
>
> Why is Lattice support being such buttheads?  They asked me for a
> screenshot of the directory dialog for the installation directory which
> I provided.  Then no reply for a week and a half.  I've made two more
> replies with additional information and still nothing.

I noticed there was an update so I installed it, no change.

I just realized that when I was having trouble with the tool recognizing 
I was using VHDL-2008, they told me to change the VHDL setting in LSE. 
I didn't have an option to change any LSE settings.  Support wasn't on 
the ball enough to figure out that you can't use LSE with the old XP 
parts.  Wow...

-- 

Rick C

Article: 159096
Subject: Altera Ethernet MAC without DMA
From: Jakab Tanko <jakab.tanko@gmail.com>
Date: Wed, 27 Jul 2016 23:19:33 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi all,

I have a design that uses Altera Ethernet MAC and 
I would like to connect it to NIOS without DMA.
Any suggestions? 

Thanks,
--
Jakab 

Article: 159097
Subject: Re: Altera Ethernet MAC without DMA
From: Theo Markettos <theom+news@chiark.greenend.org.uk>
Date: 28 Jul 2016 11:09:07 +0100 (BST)
Links: << >>  << T >>  << A >>
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

Article: 159098
Subject: Re: Vivado parses wicked slow
From: GaborSzakacs <gabor@alacron.com>
Date: Thu, 28 Jul 2016 08:51:04 -0400
Links: << >>  << T >>  << A >>
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

Article: 159099
Subject: Re: Vivado parses wicked slow
From: Kevin Neilson <kevin.neilson@xilinx.com>
Date: Thu, 28 Jul 2016 13:43:08 -0700 (PDT)
Links: << >>  << T >>  << A >>
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.



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