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 158025

Article: 158025
Subject: Re: Distributed ram timing qurry
From: "kaz" <37480@FPGARelated>
Date: Fri, 10 Jul 2015 15:46:18 -0500
Links: << >>  << T >>  << A >>

>
>What you're asking is device-related.  What FPGA family are you using?
>Generally speaking, Xilinx devices can implement distributed memory
>FIFO pretty well, but you need to limit the depth of the FIFO to
>get it to run at high clock rates.  Also there's a big difference
>between common-clock FIFO and independent-clock FIFO.  The first
>kind can be implemented in SRL, the second cannot.
>
>Also it would be good to see a full failing path from your timing
>report (.twr file) to see if this is a logic level issue or
>a routing length issue.
>
>-- 
>Gabor

It is Virtex 6 and I have achieved better than 368MHz at module level.
At integration (into very large project) it fails marginally. As I said it
is the path from read register to fifo data output (single clock 16 words
depth, distributed ram).I don't expect any logic apart from fifo stages
implemented in luts. I am just asking if there is anyway to improve such
paths. I tried block ram and it failed very badly. 

Kaz


---------------------------------------
Posted through http://www.FPGARelated.com

Article: 158026
Subject: Re: Distributed ram timing qurry
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Fri, 10 Jul 2015 21:11:07 +0000 (UTC)
Links: << >>  << T >>  << A >>
kaz <37480@fpgarelated> wrote:

(snip, and previously snipped)

> It is Virtex 6 and I have achieved better than 368MHz at module level.
> At integration (into very large project) it fails marginally. As I said it
> is the path from read register to fifo data output (single clock 16 words
> depth, distributed ram).I don't expect any logic apart from fifo stages
> implemented in luts. I am just asking if there is anyway to improve such
> paths. I tried block ram and it failed very badly. 

Do you mean that it fails, even when timing satisfies the 
post-route timing data?

That isn't good.

-- glen

Article: 158027
Subject: Re: Dynamic Array in VHDL
From: jonesandy@comcast.net
Date: Fri, 10 Jul 2015 14:15:47 -0700 (PDT)
Links: << >>  << T >>  << A >>
You didn't mention whether this is purely for simulation (e.g for architecture exploration) or for synthesis (building and FPGA).

I am not sure that referencing a variable for a type declaration is correct, but some synthesis tools may allow it anyway (since the variable could not have changed value except at run time.)

Declarations must be based on static information, known at compile time.

Your entity could use a generic (a static kind of "port") to pass this size information in at compile/synthesis time, but that is about as dynamic as it gets for architecture or process declarative regions. 

Most tools allow specifying the value of top level generics on the command line and/or in a project file.

For simulation, subprograms can declare items based on argument values, but for synthesis, this places constraints on how the subprogram is called, and whether those argument values can be known at synthesis time.

VHDL (for simulation only) has dynamic memory allocation, and pointers (called access types) with which you can dynamically create data structures. But they are not synthesizable.

Andy

Article: 158028
Subject: Re: Distributed ram timing qurry
From: "kaz" <37480@FPGARelated>
Date: Fri, 10 Jul 2015 16:18:32 -0500
Links: << >>  << T >>  << A >>
>kaz <37480@fpgarelated> wrote:
>
>(snip, and previously snipped)
>
>> It is Virtex 6 and I have achieved better than 368MHz at module level.
>> At integration (into very large project) it fails marginally. As I
said
>it
>> is the path from read register to fifo data output (single clock 16
words
>> depth, distributed ram).I don't expect any logic apart from fifo
stages
>> implemented in luts. I am just asking if there is anyway to improve
such
>> paths. I tried block ram and it failed very badly. 
>
>Do you mean that it fails, even when timing satisfies the 
>post-route timing data?
>
>That isn't good.
>
>-- glen

No, by module level I mean when compiled on its own. The actual project is
not based on any incremental approach or logic lock but all the lower
modules are just added to project to be fitted freely anywhere it chooses.


Kaz 
---------------------------------------
Posted through http://www.FPGARelated.com

Article: 158029
Subject: Re: Distributed ram timing qurry
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Fri, 10 Jul 2015 22:45:36 +0000 (UTC)
Links: << >>  << T >>  << A >>
kaz <37480@fpgarelated> wrote:
>>kaz <37480@fpgarelated> wrote:
>>(snip, and previously snipped)
(snip)
>>> It is Virtex 6 and I have achieved better than 368MHz at module level.
>>> At integration (into very large project) it fails marginally. As I
>>> said

(snip, I wrote)
>>Do you mean that it fails, even when timing satisfies the 
>>post-route timing data?

(snip)
> No, by module level I mean when compiled on its own. The actual 
> project is not based on any incremental approach or logic lock 
> but all the lower modules are just added to project to 
> be fitted freely anywhere it chooses.

I use Spartan, so it might be different.

Some years ago, I was working on a project where the pre-route
timing was so good, maybe twice as fast as it needed to be, and
I didn't even bother to look at the post-route timing until I 
tried it, and it didn't work.

At least for Spartan, the routing is optimized over the whole chip.

Well, there are things that you can do to give hints and such,
but it is easily possible that changing one part changes the timing
of some unrelated part.

It might be that you can route some modules, keep them fixed while
you route others. That probably makes more sense in big designs.

But whatever it does, it should meet post-route timing, and
you should run that to be sure that is fast enough.

-- glen



Article: 158030
Subject: Re: Calculate dynamic power at fmax in Quartus
From: rich.cahill@gmail.com
Date: Sun, 12 Jul 2015 15:47:13 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Friday, July 10, 2015 at 10:36:17 AM UTC-7, abd_elhamid_ wrote:
> Dear All,
> 
> Why dynamic power after compilation complete equal to zero, any idea how
> can I calculate dynamic power at max freq in Quartus?
> 
> Regards
> 
> 
> 
> 
> ---------------------------------------
> Posted through http://www.FPGARelated.com

Is Power Play turned on in the Settings menu?

Article: 158031
Subject: Special issue of Xcell Journal
From: mike.santarini@gmail.com
Date: Mon, 13 Jul 2015 15:22:21 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hey folks, my team just posted a new issue of Xcell Journal.

Here is the link to the pdf: http://www.xilinx.com/publications/archives/xcell/Xcell92.pdf

Here is the link to the digital magazine version:

http://issuu.com/xcelljournal/docs/xcell_journal_issue_92

Cheers,

Mike Santarini

Article: 158032
Subject: Aligning symbols with IDELAY / ISERDES in Xilinx 7-series devices.
From: Mike Field <mikefield1969@gmail.com>
Date: Mon, 13 Jul 2015 21:32:23 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi,

I'm working in Artix-7 and I've got a workable way to adjust the bitslip an=
d IDELAY tap settings to lock onto an incoming TMDS encoded stream, but is =
there a better way?

Currently I count the symbol error rate on the link, and if the rate of bad=
 symbols is greater than 1:2^20 I then move on to a higher delay tap settin=
g.=20

If the delay's tap setting wraps I also assert bitslip input on on the ISER=
DES for a cycle, allowing me to try a different alignment.

It works well enough in practice but seems ungainly, and has a few problems=
 lurking under the covers - if the error rate is very close to 1:2^32 it wi=
ll never lock, and a second problem is that it might decide to stick with a=
n IDELAY that is marginal (e.g. has errors but less than one in a million),=
 without discovering that a better setting could be one tap away.=20

And not so much a problem for video but if it does get errors it can take a=
 while to come back into sync (7M symbols or so)

The 7-series I/O Resource User Guide is very good at telling you what is th=
ere for you to use,  but not how best to do it - any suggests would be grat=
efully accepted!

Mike

PS. Code is at http://hamsterworks.co.nz/mediawiki/index.php/SERDES_symbol_=
locking if you want a look at it.



Article: 158033
Subject: Re: Aligning symbols with IDELAY / ISERDES in Xilinx 7-series
From: Tobias Baumann <ttobsen@hotmail.com>
Date: Tue, 14 Jul 2015 12:57:13 +0200
Links: << >>  << T >>  << A >>
Hi Mike,

I always use 2 independent types of alignment: Bit- and Word alignment.

In first case I ensure that I sample the data as close as possible in 
the middle of the data eye. This can be performed by example of using 2 
delays for one data lane with an variable offset between them.

Lets say you have a M-delay and a S-Delay for your data lane (for 
example you can use IBUFDS_DIFF_OUT buffers on Artix 7 devices when 
using LVDS). M is at step n and S will be oscillated about amount of 
shifts, lets say 2 (this depends on the tap width and the width of the 
open data eye). So S will have the tap values n+2 -> n-2 -> n+2 -> n-2 
and so on. Now you compare your data between M and S. When they are 
equal you sample in the middle of the data eye and everything is fine. 
When not you have to tap M in the opposite direction until the data is 
equal.

I like this technique, because the bit alignment is performed in real 
time, which ensures that the link is up in every case (for example 
voltage or temperature can change).

When this works you have the most technical part of alignment done. To 
implement word alignment, you have to know some known symbols in your 
data stream. When you find them, everything is good, when not you have 
to perform bitslips until you get them.

Nice regards,
Tobias


Article: 158034
Subject: Image Compression in an FPGA
From: rickman <gnuarm@gmail.com>
Date: Fri, 24 Jul 2015 18:57:54 -0400
Links: << >>  << T >>  << A >>
Someone is looking to generate compressed images in an FPGA to display 
graph data on a browser.  Looking around the GIF, TIFF or PNG formats 
seem rather straightforward to implement.  Anyone know of an 
implementation of one of these in an HDL?  It doesn't need to implement 
the entire standard, just enough to generate one image style.

-- 

Rick

Article: 158035
Subject: Free Lattice FPGA
From: "Michael Kellett" <nospam@invalid.com>
Date: sat, 25 jul 2015 09:17:07 +0100
Links: << >>  << T >>  << A >>
I'm turning out a cupboard and have found 10 off Lattice
LFECP10E-4FN256C - still sealed in dry packs. Location SW Scotland -
seems  a shame to bin them  - I'll try to give them away at the
Wuthering Bytes jolly in Hebden Bridge at the end of Septemebr unless
someone here would like them first.

Contact me direct if you are interested.

mk AT mkesc DOT co DOT uk

Michael Kellett

Article: 158036
Subject: Re: Image Compression in an FPGA
From: Theo Markettos <theom+news@chiark.greenend.org.uk>
Date: 25 Jul 2015 19:19:13 +0100 (BST)
Links: << >>  << T >>  << A >>
rickman <gnuarm@gmail.com> wrote:
> Someone is looking to generate compressed images in an FPGA to display 
> graph data on a browser.  Looking around the GIF, TIFF or PNG formats 
> seem rather straightforward to implement.  Anyone know of an 
> implementation of one of these in an HDL?  It doesn't need to implement 
> the entire standard, just enough to generate one image style.

Does it actually need to be compressed, or will wrapping headers around
uncompressed data be enough?  All of those have uncompressed formats that
will be accepted by a web browser - that may suffice if you aren't concerned
about bandwidth, and would be easier to implement.

Theo

Article: 158037
Subject: Re: Image Compression in an FPGA
From: rickman <gnuarm@gmail.com>
Date: Sat, 25 Jul 2015 17:32:09 -0400
Links: << >>  << T >>  << A >>
On 7/25/2015 2:19 PM, Theo Markettos wrote:
> rickman <gnuarm@gmail.com> wrote:
>> Someone is looking to generate compressed images in an FPGA to display
>> graph data on a browser.  Looking around the GIF, TIFF or PNG formats
>> seem rather straightforward to implement.  Anyone know of an
>> implementation of one of these in an HDL?  It doesn't need to implement
>> the entire standard, just enough to generate one image style.
>
> Does it actually need to be compressed, or will wrapping headers around
> uncompressed data be enough?  All of those have uncompressed formats that
> will be accepted by a web browser - that may suffice if you aren't concerned
> about bandwidth, and would be easier to implement.

Yes, I suspect he can even use a fully uncompressed format like bitmap. 
  His requirements to be for the format to be "widely supported" which 
doesn't indicate how recent the browsers need to be and to produce the 
image files with little working memory.

He seems to like SVG which seems to meet the latter requirement well if 
meeting the former requirement is a bit fuzzy.  It looks like nearly all 
browsers currently support SVG but only the more recent versions of some.

He does not seem to be limited to connection bandwidth and has not 
indicated his needed update rate.  This guy often posts discussion 
points without giving details until you offer a solution that does not 
meet one of the unmentioned requirements.  Looks like SVG may be the way 
he goes.

-- 

Rick

Article: 158038
Subject: Re: Image Compression in an FPGA
From: "Tomas D." <mailsoc@gmial.com>
Date: Sun, 26 Jul 2015 22:24:02 +0100
Links: << >>  << T >>  << A >>


"rickman" <gnuarm@gmail.com> wrote in message 
news:moufqn$8d1$1@dont-email.me...
> Someone is looking to generate compressed images in an FPGA to display 
> graph data on a browser.  Looking around the GIF, TIFF or PNG formats seem 
> rather straightforward to implement.  Anyone know of an implementation of 
> one of these in an HDL?  It doesn't need to implement the entire standard, 
> just enough to generate one image style.

There are lots of JPEG encoders out there. Maybe use one?

Tomas D. 



Article: 158039
Subject: Re: Image Compression in an FPGA
From: rickman <gnuarm@gmail.com>
Date: Sun, 26 Jul 2015 17:52:28 -0400
Links: << >>  << T >>  << A >>
On 7/26/2015 5:24 PM, Tomas D. wrote:
> "rickman" <gnuarm@gmail.com> wrote in message
> news:moufqn$8d1$1@dont-email.me...
>> Someone is looking to generate compressed images in an FPGA to display
>> graph data on a browser.  Looking around the GIF, TIFF or PNG formats seem
>> rather straightforward to implement.  Anyone know of an implementation of
>> one of these in an HDL?  It doesn't need to implement the entire standard,
>> just enough to generate one image style.
>
> There are lots of JPEG encoders out there. Maybe use one?

Thanks for the advice.  I will use it in the spirit it was intended.  :)

-- 

Rick

Article: 158040
Subject: Re: Image Compression in an FPGA
From: Theo Markettos <theom+news@chiark.greenend.org.uk>
Date: 27 Jul 2015 15:48:28 +0100 (BST)
Links: << >>  << T >>  << A >>
rickman <gnuarm@gmail.com> wrote:
> He seems to like SVG which seems to meet the latter requirement well if 
> meeting the former requirement is a bit fuzzy.  It looks like nearly all 
> browsers currently support SVG but only the more recent versions of some.

If you're just plotting X/Y then SVG may suffice, if you can make a suitable
wrapper around it.

One other thought - get the browser to do the work.  Just emit the data in
whatever format you fancy - JSON is a simple one, but even base64 might work
- and then just include some Javascript that plots it in the browser for
you.  There's lots of libraries for that:
http://www.sitepoint.com/15-best-javascript-charting-libraries/
You can just use a URL so don't need the JS framework on the FPGA.

Lots of 'analytics' sites do this - download the table of (eg) share
prices as XML or JSON and plot locally, rather than plotting server-side. 
Makes for better interaction too - easier to navigate when your browser has
the dataset.

Theo

Article: 158041
Subject: Finally! A Completely Open Complete FPGA Toolchain
From: rickman <gnuarm@gmail.com>
Date: Mon, 27 Jul 2015 12:34:21 -0400
Links: << >>  << T >>  << A >>
I am very impressed.  I was reading about Antti's incredibly tiny FPGA 
project board and saw a mention of a FOSS FPGA toolchain.  Not just the 
compiler, but the entire bitstream generation!

http://hackaday.com/2015/07/03/hackaday-prize-entry-they-make-fpgas-that-small/

Several people have built on each other's work to provide "a fully open 
source Verilog to bitstream development tool chain for the Lattice 
iCE40LP with support for more devices in the works."

http://hackaday.com/2015/05/29/an-open-source-toolchain-for-ice40-fpgas/

https://github.com/cseed/arachne-pnr

I haven't tried any of it yet, but I am very impressed that they are 
reverse engineering the devices so that they can generate bit streams 
and not rely on the vendor.

-- 

Rick

Article: 158042
Subject: Re: Finally! A Completely Open Complete FPGA Toolchain
From: rickman <gnuarm@gmail.com>
Date: Mon, 27 Jul 2015 13:25:18 -0400
Links: << >>  << T >>  << A >>
On 7/27/2015 12:34 PM, rickman wrote:
> I am very impressed.  I was reading about Antti's incredibly tiny FPGA
> project board and saw a mention of a FOSS FPGA toolchain.  Not just the
> compiler, but the entire bitstream generation!
>
> http://hackaday.com/2015/07/03/hackaday-prize-entry-they-make-fpgas-that-small/
>
>
> Several people have built on each other's work to provide "a fully open
> source Verilog to bitstream development tool chain for the Lattice
> iCE40LP with support for more devices in the works."
>
> http://hackaday.com/2015/05/29/an-open-source-toolchain-for-ice40-fpgas/
>
> https://github.com/cseed/arachne-pnr
>
> I haven't tried any of it yet, but I am very impressed that they are
> reverse engineering the devices so that they can generate bit streams
> and not rely on the vendor.

I found another link relating to the tools called "IceStorm".

http://www.clifford.at/icestorm/

-- 

Rick

Article: 158043
Subject: Re: Finally! A Completely Open Complete FPGA Toolchain
From: Tim Wescott <seemywebsite@myfooter.really>
Date: Mon, 27 Jul 2015 12:57:12 -0500
Links: << >>  << T >>  << A >>
On Mon, 27 Jul 2015 12:34:21 -0400, rickman wrote:

> I am very impressed.  I was reading about Antti's incredibly tiny FPGA
> project board and saw a mention of a FOSS FPGA toolchain.  Not just the
> compiler, but the entire bitstream generation!
> 
> http://hackaday.com/2015/07/03/hackaday-prize-entry-they-make-fpgas-
that-small/
> 
> Several people have built on each other's work to provide "a fully open
> source Verilog to bitstream development tool chain for the Lattice
> iCE40LP with support for more devices in the works."
> 
> http://hackaday.com/2015/05/29/an-open-source-toolchain-for-ice40-fpgas/
> 
> https://github.com/cseed/arachne-pnr
> 
> I haven't tried any of it yet, but I am very impressed that they are
> reverse engineering the devices so that they can generate bit streams
> and not rely on the vendor.

Kewl.

It'll be even more kewl if it shames the vendors into being open with 
their bitstream specifications.  I have no idea why they seem to feel 
this needs to be held so close to their chests.

-- 

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

Article: 158044
Subject: Re: Finally! A Completely Open Complete FPGA Toolchain
From: rickman <gnuarm@gmail.com>
Date: Mon, 27 Jul 2015 14:30:34 -0400
Links: << >>  << T >>  << A >>
On 7/27/2015 1:57 PM, Tim Wescott wrote:
> On Mon, 27 Jul 2015 12:34:21 -0400, rickman wrote:
>
>> I am very impressed.  I was reading about Antti's incredibly tiny FPGA
>> project board and saw a mention of a FOSS FPGA toolchain.  Not just the
>> compiler, but the entire bitstream generation!
>>
>> http://hackaday.com/2015/07/03/hackaday-prize-entry-they-make-fpgas-
> that-small/
>>
>> Several people have built on each other's work to provide "a fully open
>> source Verilog to bitstream development tool chain for the Lattice
>> iCE40LP with support for more devices in the works."
>>
>> http://hackaday.com/2015/05/29/an-open-source-toolchain-for-ice40-fpgas/
>>
>> https://github.com/cseed/arachne-pnr
>>
>> I haven't tried any of it yet, but I am very impressed that they are
>> reverse engineering the devices so that they can generate bit streams
>> and not rely on the vendor.
>
> Kewl.
>
> It'll be even more kewl if it shames the vendors into being open with
> their bitstream specifications.  I have no idea why they seem to feel
> this needs to be held so close to their chests.

I seriously doubt this will ever happen.  They have all done this nearly 
100% of the time and I'm sure they are convinced it is the best way to 
do business.  From what they have said their concern is that with open 
source tools their hardware will be subject to "problems" caused by poor 
tools.  Or maybe they limit access to chip features through the tools 
which they couldn't do with FOSS tools.  I seem to recall someone 
ranting that a line of Altera parts had some devices which were labeled 
as smaller chips but would load and run a bitstream for a larger part. 
I expect this would show up quickly and clearly if the tools were FOSS.

Those who have been in this business long enough may remember the line 
of parts Xilinx made specifically to support an open bit stream.  It was 
popular with academia and a number of papers were written about 
researchy things you might do with it.  I'm not sure what Xilinx's 
motive was for producing these chips, but they dropped the line and 
crushed the molds.  I'm pretty sure there is no mention of these parts 
anywhere on their site now.  Or did I only dream all of that?

-- 

Rick

Article: 158045
Subject: Re: Finally! A Completely Open Complete FPGA Toolchain
From: "Tomas D." <mailsoc@gmial.com>
Date: Mon, 27 Jul 2015 21:01:31 +0100
Links: << >>  << T >>  << A >>
> Those who have been in this business long enough may remember the line of 
> parts Xilinx made specifically to support an open bit stream.  It was 
> popular with academia and a number of papers were written about researchy 
> things you might do with it.  I'm not sure what Xilinx's motive was for 
> producing these chips, but they dropped the line and crushed the molds. 
> I'm pretty sure there is no mention of these parts anywhere on their site 
> now.  Or did I only dream all of that?

Maybe you will also be interested in this:
https://recon.cx/2015/slides/recon2015-18-andrew-zonenberg-From-Silicon-to-Compiler.pdf

Tomas D. 



Article: 158046
Subject: Re: Finally! A Completely Open Complete FPGA Toolchain
From: Brian Drummond <brian@shapes.demon.co.uk>
Date: Tue, 28 Jul 2015 10:06:48 +0000 (UTC)
Links: << >>  << T >>  << A >>
On Mon, 27 Jul 2015 14:30:34 -0400, rickman wrote:

> On 7/27/2015 1:57 PM, Tim Wescott wrote:
>> On Mon, 27 Jul 2015 12:34:21 -0400, rickman wrote:
>>
>>> I am very impressed.  I was reading about Antti's incredibly tiny FPGA
>>> project board and saw a mention of a FOSS FPGA toolchain.  Not just
>>> the compiler, but the entire bitstream generation!

>>> http://hackaday.com/2015/05/29/an-open-source-toolchain-for-ice40-
fpgas/
>

Excellent! Though I'm not surprised it's Lattice, I vaguely recall 
looking through an early (pre-2000) toolchain of theirs and thinking the 
details were closer to the surface than with other vendors.

> Those who have been in this business long enough may remember the line
> of parts Xilinx made specifically to support an open bit stream.  It was
> popular with academia and a number of papers were written about
> researchy things you might do with it.  I'm not sure what Xilinx's
> motive was for producing these chips, but they dropped the line and
> crushed the molds.  I'm pretty sure there is no mention of these parts
> anywhere on their site now.  Or did I only dream all of that?

Indeed you didn't dream the XC6200 series. It wasn't so much that Xilinx 
developed them, as they bought the company that did (Algotronics or 
Algotronix I think, based in Edinburgh). Presumably they bought them for 
tech in general or possibly some key patents rather than the specific 
device family. 

Which was something of a dead end in other respects, too fine grained (I 
believe' 1 gate, 1FF per CLB). Much simpler and more regular, but 
wouldn't scale too well to million-CLB devices dominated by routing, 
where the XC4000 and later devices would give the same capacity with a 
much smaller and cheaper die.

I think it was that simple regular structure that made opening the 
bitstream format attractive, as well as killing the device long-term.

You may also recall a company that successfully reverse-engineered the 
bitstream for Xilinx devices, and started to market their own independent 
toolchain.

Yup, Xilinx bought them too. But their name lives on in the .ncd (neocad) 
file extension.

-- Brian

Article: 158047
Subject: Re: Finally! A Completely Open Complete FPGA Toolchain
From: rickman <gnuarm@gmail.com>
Date: Tue, 28 Jul 2015 13:32:39 -0400
Links: << >>  << T >>  << A >>
On 7/28/2015 6:06 AM, Brian Drummond wrote:
> On Mon, 27 Jul 2015 14:30:34 -0400, rickman wrote:
>
>> On 7/27/2015 1:57 PM, Tim Wescott wrote:
>>> On Mon, 27 Jul 2015 12:34:21 -0400, rickman wrote:
>>>
>>>> I am very impressed.  I was reading about Antti's incredibly tiny FPGA
>>>> project board and saw a mention of a FOSS FPGA toolchain.  Not just
>>>> the compiler, but the entire bitstream generation!
>
>>>> http://hackaday.com/2015/05/29/an-open-source-toolchain-for-ice40-
> fpgas/
>>
>
> Excellent! Though I'm not surprised it's Lattice, I vaguely recall
> looking through an early (pre-2000) toolchain of theirs and thinking the
> details were closer to the surface than with other vendors.
>
>> Those who have been in this business long enough may remember the line
>> of parts Xilinx made specifically to support an open bit stream.  It was
>> popular with academia and a number of papers were written about
>> researchy things you might do with it.  I'm not sure what Xilinx's
>> motive was for producing these chips, but they dropped the line and
>> crushed the molds.  I'm pretty sure there is no mention of these parts
>> anywhere on their site now.  Or did I only dream all of that?
>
> Indeed you didn't dream the XC6200 series. It wasn't so much that Xilinx
> developed them, as they bought the company that did (Algotronics or
> Algotronix I think, based in Edinburgh). Presumably they bought them for
> tech in general or possibly some key patents rather than the specific
> device family.
>
> Which was something of a dead end in other respects, too fine grained (I
> believe' 1 gate, 1FF per CLB). Much simpler and more regular, but
> wouldn't scale too well to million-CLB devices dominated by routing,
> where the XC4000 and later devices would give the same capacity with a
> much smaller and cheaper die.
>
> I think it was that simple regular structure that made opening the
> bitstream format attractive, as well as killing the device long-term.
>
> You may also recall a company that successfully reverse-engineered the
> bitstream for Xilinx devices, and started to market their own independent
> toolchain.

It has been a very long time, but I don't think NeoCAD was spitting out 
bitstreams for Xilinx parts where they?  I may not remember it right, 
but I thought their claim to fame was their router which did a better 
job than the Xilinx tools which is why Xilinx bought them.  Rather than 
bury the NeoCAD tools and moving on, they shipped the NeoCAD tools as 
their main tool.  They reverse engineered the routing I know.  I guess 
it wouldn't be so hard to figure out the bit stream too.

I recall that NeoCAD was supporting other companies because they 
realized what a large job it was to write their own tools.  So other new 
entries to the market used NeoCAD as their only tool.  There were 
clauses in place to give them rights to the software if NeoCAD was 
bought by a competitor, which is what happened.  I'm not sure that was 
much solace since they all ended up having to support their own software 
at that point which is what they were trying to get away from.

> Yup, Xilinx bought them too. But their name lives on in the .ncd (neocad)
> file extension.

I seem to recall having the NeoCAD tools for some product other than 
Xilinx.  It may be the ORCA devices which Lucent produced with their 
license from Xilinx.  Not an XC4000 clone, but used Xilinx patents with 
similar functionality.  I seem to recall they had the first CLBs where 
all components were not equivalent.  Lattice does that in several of 
their FPGA lines now that they have the Lucent FPGA products and Xilinx 
licenses.

I recall that Altera has terms in their software to limit what you can 
do with the bit stream.  If you want to make an ASIC you *have* to come 
to them.  That killed a company who was providing exactly that service, 
bit stream to ASIC.  Do all the FPGA makers do that?  I would think that 
alone would be reason enough to reverse engineer the bit stream.  That 
company could then produce the bit stream themselves which would retain 
the 1:1 relation between your verified FPGA design and the ASIC.

Maybe that is why FPGA companies don't want FOSS tools?  It would take 
away their ASIC business.  Is that very popular anymore?  I haven't seen 
it promoted in years.

-- 

Rick

Article: 158048
Subject: FPGA board to interface with ADC (>10 GHz) and generate 5Gbps PRBS
From: vmenon <vivek.v80@gmail.com>
Date: Tue, 28 Jul 2015 10:48:09 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hello all,

I am designing a circuit that requires a 10 GHz ADC and a FPGA to generate a 5 Gbps PRBS. I am not able to find a high speed ADC and a supporting FPGA evaluation board. Does anyone know/ can recommend a board?

 

Thanks in advance,

V

Article: 158049
Subject: Re: Finally! A Completely Open Complete FPGA Toolchain
From: Jan Coombs <Jan-54 <jenfhaomndgfwutc@murmic.plus.com>>
Date: Tue, 28 Jul 2015 19:59:38 +0100
Links: << >>  << T >>  << A >>
On Tue, 28 Jul 2015 13:32:39 -0400
rickman <gnuarm@gmail.com> wrote:
 
> I recall that NeoCAD was supporting other companies because
> they realized what a large job it was to write their own
> tools.  So other new entries to the market used NeoCAD as
> their only tool.  There were clauses in place to give them
> rights to the software if NeoCAD was bought by a competitor,
> which is what happened.  I'm not sure that was much solace
> since they all ended up having to support their own software
> at that point which is what they were trying to get away from.
> 
> > Yup, Xilinx bought them too. But their name lives on in
> > the .ncd (neocad) file extension.
> 
> I seem to recall having the NeoCAD tools for some product
> other than Xilinx.  It may be the ORCA devices which Lucent
> produced with their license from Xilinx.  Not an XC4000 clone,
> but used Xilinx patents with similar functionality.  I seem to
> recall they had the first CLBs where all components were not
> equivalent.  Lattice does that in several of their FPGA lines
> now that they have the Lucent FPGA products and Xilinx
> licenses.

And NeoCAD is still around:

************************************************************
**  Lattice Synthesis Engine                              **
************************************************************

synthesis -f "spi12_impl1_lattice.synproj"
synthesis:  version Diamond (64-bit) 3.4.0.80

Copyright (c) 1991-1994 by NeoCAD Inc. All rights reserved.
Copyright (c) 1995 AT&T Corp.   All rights reserved.
Copyright (c) 1995-2001 Lucent Technologies Inc.  All rights
reserved. Copyright (c) 2001 Agere Systems   All rights reserved.
Copyright (c) 2002-2014 Lattice Semiconductor Corporation,  All
rights reserved. Tue Jul 28 19:53:33 2015

Jan Coombs
-- 
email valid, else fix dots and hyphen
jan4clf2014@murrayhyphenmicroftdotcodotuk





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