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
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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 76675

Article: 76675
Subject: Re: Open source FPGA EDA Tools
From: "Antti Lukats" <antti@case2000.com>
Date: Wed, 8 Dec 2004 23:27:02 +0100
Links: << >>  << T >>  << A >>

"SG" <gupt@hotmail.com.NOSPAM> wrote in message
news:m34qiw7az2.fsf@agni.ics.uci.edu...
>
> The key things here is that ST Micro is going after the embedded FPGA
> market.   This is not an established market and Xilinx & Altera will
> have advantages only in terms of tool familiarity.
>
> About ST's architecture, if the Logic synthesis and P&R tools are open
> source, it should be very easy to figure out what the architecture
> is.  Also, I don't think its a very big innovation, otherwise, ST
> would go after the standalone FPGA market, instead of a non-existant
> embedded FPGA market.
>
> My 2 cents.
> Sumit

hm Xilinx and IBM are (or did try to be?) on the "embedded FPGA market?
http://www.xilinx.com/company/press/kits/xil_ibm/xil_ibm_faq.pdf

so its at least not first attempt of "embedded FPGA" ,also leopard logic is
offering something similar: low cost kinda-asic where part of the die is
FPGA like

antti




Article: 76676
Subject: Re: Fpga prices
From: Ben Twijnstra <btwijnstra@gmail.com>
Date: Wed, 08 Dec 2004 22:27:06 GMT
Links: << >>  << T >>  << A >>
Hi Dan,

> I need an information about some prices for some fpga.
> 
>  Acex1k speed -1, 208 pins.
>  Cyclone speed -6, 240pins.
> 
>    Thanks,

Check http://www.arrow.com. 

Do realize that you haven't specified the actual size of the device, just
the pin count, family and speed grade. No mention of gate/LE count.

Best regards,


Ben


Article: 76677
Subject: Re: Searching for rad tolerant, non-volatile (once programmable) FPGA
From: rickman <spamgoeshere4@yahoo.com>
Date: Wed, 08 Dec 2004 17:51:19 -0500
Links: << >>  << T >>  << A >>
"Marcio A. A. Fialho" wrote:
> 
> I'm looking for a rad-tolerant, non-volatile (preferably programmable
> at once) FPGA or CPLD, for a new project (a satellite instrument).

I just found this in my in box...

http://www.reed-electronics.com/ecnmag/article/CA486284?nid=2023&rid=1102926705

Aeroflex is a company that seems to take other company's products and
building them for military and aerospace applications.  They are making
an industrial version of the Hynix ARM chip along with this FPGA which
is apparently a hardened Quicklogic device.  

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 76678
Subject: Re: Open source FPGA EDA Tools
From: Jim Granville <no.spam@designtools.co.nz>
Date: Thu, 09 Dec 2004 11:55:42 +1300
Links: << >>  << T >>  << A >>
Kees van Reeuwijk wrote:
> rickman <spamgoeshere4@yahoo.com> wrote:
> 
>  
> 
>>No open source tool will be much better in those areas as has been
>>discussed here many times.  Unlike software tools, FPGA tools have to
>>evolve much more quickly to adapt to the changes in FPGAs and FPGA
>>markets.  This results in lots of updates and lots of bugs. 
> 
> 
> Perhaps, but the point remains that quite a lot of people would be happy
> with not-so-bleeding-edge FPGAs and a more accessible toolset than brand
> X or A offer. So, if you already have not-so-bleeding-edge FPGAs, open
> sourcing your toolset is one way of meeting that demand. And potentially
> a very effective way: if you play it right, you can get a lot of help
> from the open-source community.

Ideally, yes.
But open source means different things, to different people :
you need to watch the fine print.

  This from TI:
> NEW CODE COMPOSER ESSENTIALS OFFERS OPEN SOURCE IDE FOR TI'S ULTRA-LOW POWER MSP430 MICROCONTROLLERS
> The CCEssentials IDE was designed specifically to offer users an intuitive interface 
> combined with the industry's highest C code density...

sounds good so far...

..then the fine print kick in further down...
> 
> CCEssentials IDE for MSP430 microcontrollers will be available for free and includes an 
> 8K byte C complier and unlimited assembler. 
> CCEssentials Pro IDE features unlimited C and assembly code space for $499.

So, if they can offer a crippled C compiler, then clearly the source is 
not all that open ?!
-jg



Article: 76679
Subject: Re: Open source FPGA EDA Tools
From: rickman <spamgoeshere4@yahoo.com>
Date: Wed, 08 Dec 2004 18:01:09 -0500
Links: << >>  << T >>  << A >>
Kees van Reeuwijk wrote:
> 
> rickman <spamgoeshere4@yahoo.com> wrote:
> 
> 
> > No open source tool will be much better in those areas as has been
> > discussed here many times.  Unlike software tools, FPGA tools have to
> > evolve much more quickly to adapt to the changes in FPGAs and FPGA
> > markets.  This results in lots of updates and lots of bugs.
> 
> Perhaps, but the point remains that quite a lot of people would be happy
> with not-so-bleeding-edge FPGAs and a more accessible toolset than brand
> X or A offer. 

That remains to be seen.  From what I can tell, there is actually little
demand for less capable chips with less capable but open-source tools. 
The issue is not the number of people who want this, the question is how
many chips can they sell?  The money is in volume and not many chip
users can sacrifice the advantages of the most current technologies.  It
will make their products more expensive and not competitive.  

In reality the current tools work and actually work pretty well.  So
well that college students are designing chips in junior level classes. 
If it ain't broke, don't fix it! 


> So, if you already have not-so-bleeding-edge FPGAs, open
> sourcing your toolset is one way of meeting that demand. And potentially
> a very effective way: if you play it right, you can get a lot of help
> from the open-source community.

Neither of us really have any stats about the level of demand.  I guess
we'll find out when products roll out the door.  :)


> > (BTW
> > Mentor, are you *ever* going to fix the bug where Modelsim crashes
> > randomly for no special reason???)  I dont' see open source tools fixing
> > any of this.  The current open source front end tools are still far
> > inferior to vendor supplied tools.
> 
> I had to laugh when I saw that combination of sentences. The whole open
> source movement was started by people that got frustrated with software
> vendors that ignored bug reports. And it does help.

Yeah, I know.  But that is a community of software people who are using
software tools.  I worked in construction in my youth and I saw
carpenters make a lot of tools out of wood, and metal workers make tools
from metal, but not much the other way around.  This has been discussed
many, many times here and I still don't see any open source tools that
are worth using.  


> > Not before I retire....  but hey, "build it and they will come".
> 
> Personally, I believe this is possible, but the problem is always that
> the stuff on offer has to be right. A vendor with a weak FPGA and a
> rotten toolset will get nowhere. A vendor with a good FPGA and a good
> toolchain may well have a smash hit. But I think the key phrase in this
> business plan is KEEP IT SIMPLE.

What is possible?  That I will retire?   :)  

I agree that the whole package has to be right.  But a good FPGA will
always outweigh a good toolset because the FPGA is a recurring cost.  If
you have to spend a few more bucks on tools or using tools, that will
have less impact on your bottom line.  If your project is a lower volume
run where the development cost is relevant, then it is not big enough to
matter to the FPGA maker.  

And the discussion goes on, and on, and on...

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 76680
Subject: Re: making an fpga hot
From: Ray Andraka <ray@andraka.com>
Date: Wed, 08 Dec 2004 18:02:19 -0500
Links: << >>  << T >>  << A >>
The logic transitions in the routing and subsequent differential delays through
the LUT can make for many more transitions than a simple buffer implemented in a
LUT.  Unless all the LUT inputs are precisely timed so that the edges change
together, you wind up with a walk through several of the LUT addresses in the
process of settling to the next clock.  A paper presented at FPGA a few years
ago went as far as to say that as much as 30-40% of the power in a typical fpga
design is due to propagating glitches in the logic between flip-flops, and they
showed that by heavily pipelining the design, the power consumption improved
dramatically.

Symon wrote:

> Hi Paul,
> Comments/Questions below!
>
> "Paul Leventis (at home)" <paulleventis-news@yahoo.ca> wrote in message
> news:686dnTKPrvwyGyvcRVn-pQ@rogers.com...
> > (2) LUT Configuration.  A LUT configured as an AND gate does not burn
> > nearly
> > as much power as one configured as an XOR.  This difference is due to the
> > number of internal nodes in the circuit that toggle states upon the toggle
> > of in input signal.  On top of this, (blah, blah, XORs transition more)
>
> Could you explain that a little more? I thought that the LUT was just a 16x1
> RAM. Is the extra power consumed only when two inputs change? e.g. 00 => 11
> into the XOR would still have 0 as its output but it might transistion
> through the 1 output state? I understand that XOR gates are more likely to
> transition, but you seem to be saying there's some additional internal
> reason why they consume power.
>
> >
> > Paul Leventis
> > Altera Corp.
> >
> Cheers, Syms.

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 76681
Subject: Re: how to speed up my accumulator ??
From: rickman <spamgoeshere4@yahoo.com>
Date: Wed, 08 Dec 2004 18:04:31 -0500
Links: << >>  << T >>  << A >>
John_H wrote:
> 
> Noise shaping is the right way to go for a superb quality synthesizer, but
> the correction phase error - the output from the noise shaper - needs to be
> applied based on the synchronous edge position relative to the "ideal" edge
> position - the input to the noise shaper.  (Pseudo)Random doesn't do it.
> 
> All this assumes, of course, that there's an analog PLL driven by the single
> bit, noise-shaped NCO output.  Without the PLL to filter out the high
> frequency phase noise of a Sigma-Delta style NCO, the jitter is still around
> 1 reference clock period peak-to-peak, maybe worse.

That answers a question I have had for a long time.  It occured to me a
long time ago to use an analog PLL to smooth out the ragged edges in an
NCO clock.  But no one I spoke to about it could say if it would work. 
I always figured that the low pass filter would do the smoothing for
me.  

I should never have doubted myself.  ;)

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 76682
Subject: Re: Open source FPGA EDA Tools
From: rickman <spamgoeshere4@yahoo.com>
Date: Wed, 08 Dec 2004 18:09:12 -0500
Links: << >>  << T >>  << A >>
Antti Lukats wrote:
> 
> "SG" <gupt@hotmail.com.NOSPAM> wrote in message
> news:m34qiw7az2.fsf@agni.ics.uci.edu...
> >
> > The key things here is that ST Micro is going after the embedded FPGA
> > market.   This is not an established market and Xilinx & Altera will
> > have advantages only in terms of tool familiarity.
> >
> > About ST's architecture, if the Logic synthesis and P&R tools are open
> > source, it should be very easy to figure out what the architecture
> > is.  Also, I don't think its a very big innovation, otherwise, ST
> > would go after the standalone FPGA market, instead of a non-existant
> > embedded FPGA market.
> >
> > My 2 cents.
> > Sumit
> 
> hm Xilinx and IBM are (or did try to be?) on the "embedded FPGA market?
> http://www.xilinx.com/company/press/kits/xil_ibm/xil_ibm_faq.pdf
> 
> so its at least not first attempt of "embedded FPGA" ,also leopard logic is
> offering something similar: low cost kinda-asic where part of the die is
> FPGA like

No they are not the first.  The key here is that this is a niche market
with a small total size, although growing.  I doubt that an FPGA vendor
can survive just supplying this one market.  I expect they either see
this as a way to bring in more ASIC customers or they will branch out to
full FPGA chips.  BTW, wasn't that Lucent's marketing strategy to
acquire ASIC customers by getting them to prototype with primitive
compatible Orca FPGAs?  I believe they sold off the Orca line to
Lattice...  guess that didn't work out too well for them.  

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 76683
Subject: Re: Open source FPGA EDA Tools
From: rickman <spamgoeshere4@yahoo.com>
Date: Wed, 08 Dec 2004 18:13:27 -0500
Links: << >>  << T >>  << A >>
SG wrote:
> 
> The key things here is that ST Micro is going after the embedded FPGA
> market.   This is not an established market and Xilinx & Altera will
> have advantages only in terms of tool familiarity.

Yes, but it is a very small market still.  They must have something else
in mind with this as a foothold.  

> About ST's architecture, if the Logic synthesis and P&R tools are open
> source, it should be very easy to figure out what the architecture
> is.  Also, I don't think its a very big innovation, otherwise, ST
> would go after the standalone FPGA market, instead of a non-existant
> embedded FPGA market.

You may be right.  Certainly you don't need the *best* FPGA to market it
as a partially reprogrammable ASIC.  But some FPGA vendors are saying
that ASICs are loosing market share to FPGAs in a big way.  Perhaps that
opens up a middle ground or maybe it is the *worst* of both worlds, a
long lead time ASIC that you have to configure at boot time... :) 

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 76684
Subject: Re: Open source FPGA EDA Tools
From: rickman <spamgoeshere4@yahoo.com>
Date: Wed, 08 Dec 2004 18:15:15 -0500
Links: << >>  << T >>  << A >>
Jim Granville wrote:
> 
>   This from TI:
> > NEW CODE COMPOSER ESSENTIALS OFFERS OPEN SOURCE IDE FOR TI'S ULTRA-LOW POWER MSP430 MICROCONTROLLERS
> > The CCEssentials IDE was designed specifically to offer users an intuitive interface
> > combined with the industry's highest C code density...
> 
> sounds good so far...
> 
> ..then the fine print kick in further down...
> >
> > CCEssentials IDE for MSP430 microcontrollers will be available for free and includes an
> > 8K byte C complier and unlimited assembler.
> > CCEssentials Pro IDE features unlimited C and assembly code space for $499.
> 
> So, if they can offer a crippled C compiler, then clearly the source is
> not all that open ?!
> -jg

They said the IDE is open source, not the compiler.  

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 76685
Subject: Re: Xilinx Read First Write First
From: "Harish" <harish.vutukuru@gmail.com>
Date: 8 Dec 2004 15:28:59 -0800
Links: << >>  << T >>  << A >>
Thanks for the reply. I read the data sheet and it clarified all the
queries I had.
I am just quoting the same here.

For synchornous clocks.
1. If both ports read simultaneously from the same memory cell: Both
Data_out ports will have the same data.
2.If both ports write simultaneously into the same memory cell:
The data stored in that cell becomes invalid (unless both ports write
identical data).
3. If one port writes and the other port reads from the same memory
cell:
The write operation succeeds, and the data to be read out from the read
port will be determined by the read output mode


Article: 76686
Subject: Re: Open source FPGA EDA Tools
From: Mike Treseler <mike_treseler@comcast.net>
Date: Wed, 08 Dec 2004 16:26:28 -0800
Links: << >>  << T >>  << A >>
rickman wrote:

> I still don't see any open source tools that are worth using.  

On the back end that may be true.
However, emacs vhdl-mode and "make"
are useful to me at the front.

       -- Mike Treseler


Article: 76687
Subject: Re: making an fpga hot
From: "Paul Leventis \(at home\)" <paulleventis-news@yahoo.ca>
Date: Wed, 8 Dec 2004 19:58:27 -0500
Links: << >>  << T >>  << A >>
Hi Symon,

> > (2) LUT Configuration.  A LUT configured as an AND gate does not burn
> > nearly
> > as much power as one configured as an XOR.  This difference is due to
the
> > number of internal nodes in the circuit that toggle states upon the
toggle
> > of in input signal.  On top of this, (blah, blah, XORs transition more)
>
> Could you explain that a little more? I thought that the LUT was just a
16x1
> RAM. Is the extra power consumed only when two inputs change? e.g. 00 =>
11
> into the XOR would still have 0 as its output but it might transistion
> through the 1 output state? I understand that XOR gates are more likely to
> transition, but you seem to be saying there's some additional internal
> reason why they consume power.

While logically a LUT is just 16x1 ROM, physically it is not built the same
way as a RAM.

A traditional RAM is built with a 2D-array of bits, where a row is selected
by decoding the address, and a pair of differential bit lines per cell is
precharged and then the cell pulls one side down which is amplified by a
sense-amplifier to speed things up (gross simplification).  In that
structure, regardless of what you are reading, you burn the same power since
the reads are differential, and you burn power on each read, regardless of
the previously read value, since all that precharge, pull-down and sensing
happens every read.

A LUT however is traditionally built as a multiplexor tree.  You have 16
SRAM cells feeding a tree of 2:1 muxes.  The 4 inputs of the LUT each
control one level of the tree.  There is a diagram below for a 2-LUT.

Let's take a 2-LUT implementing an XOR as an example (see diagram).  We have
x = A?1:0 and y = A?0:1, and f = B?y:x.  Let's say A switches from 0-->1
(and B = 0).  Node x toggles from a 0 to 1.  Node y toggles from a 1 to a 0.
And node f toggles from a 0 to a 1 (with x).  So you have not only the
output of the LUT toggling, but also the internal stages.  If you extend the
example to an N-LUT, you'll see that a toggle on input A results in 2^(N-1)
first stage nodes toggling, 2^(N-2) second stage, etc. or 2^N - 1 nodes
toggling *internal* to the LUT.  If you look at an AND instead, you'll see
that only one first stage node toggles state with a change in A.

     A    B
+-+  |    |
|0|-|\  x |
+++ | |__ |
+-+ | |  |\
|1|-|/   | |
+++  |   | |__ f
+-+  |   | |
|1|-|\  y| |
+++ | |__|/
+-+ | |
|0|-|/
+++

So in conclusion, an XOR not only results in a higher output switching
probability (which should be modeled by your simulation vectors or assumed
toggle rate), but also results in higher *internal* switching activity.
Hence power of a LUT is not constant in LUT mask.  In fact, it also changes
as a function of what the "static probabilities" of each input are, or % of
the time those inputs are 1 or 0, since assymetric LUT masks result in
assymetric internal states as a function of input values.

Regards,

Paul Leventis
Altera Corp.










Article: 76688
Subject: Re: making an fpga hot
From: "Paul Leventis \(at home\)" <paulleventis-news@yahoo.ca>
Date: Wed, 8 Dec 2004 20:09:55 -0500
Links: << >>  << T >>  << A >>
Hi Ray et al:

Good point on glitching.  On a related note, this glitching also makes power
analysis difficult.  Even with good-quality simulation vectors for a design,
the resulting gate-level simulation results will contain glitches.  Are the
glitches real?  If so, then they should count towards power.  But
sufficiently short glitches will never propagate through the routing, or
even through the gate.

This is why we recommend that our users employ glitch filtering on
simulation results.  This can be done with the Quartus II 4.2 simulator or
with 3rd party simulators (via the control file emitted by Quartus II).  We
find that very glitchy designs do not correlate well unless this glitch
filtering is used.  In addition, the resulting VCD files produced by 3rd
party sims need to be further filtered by Quartus in order to improve
accuracy further.

For further information on power analysis, the Quartus II PowerPlay Power
Analyzer and glitch filtering specifically, please see
http://www.altera.com/literature/hb/qts/qts_qii53013.pdf.

And yes, pipelining is an excellent way to reduce glitching and thus dynamic
power.  At some point, the pipeline registers and additional clock routing
will add more power than the glitches removed, but for glitch-heavy designs
(anything with XORs, such as adders, multipliers, and parity trees, and
"randomizing" circuits such as encryption) pipeling will help a lot.

Regards,

Paul Leventis
Altera Corp.



Article: 76689
Subject: Re: Performance claims
From: "Paul Leventis \(at home\)" <paulleventis-news@yahoo.ca>
Date: Wed, 8 Dec 2004 20:21:46 -0500
Links: << >>  << T >>  << A >>


I would like to offer some clarification of points raised in this
whitepaper, first in summary and then in some detail.  I will occasionally
refer to our web-based performance seminar
(http://seminar2.techonline.com/s/altera_dec0704) for further details.



* Constraints.  The clock constraint methodology we employ matches

  that outlined in the whitepaper.  It is good to see that both

  companies can agree on something!



* High-Effort Compiles.  We run the ISE software in the mode that

  yields the highest results across our benchmark set.  We also run a

  seed sweep ("multi-pass") for ISE at the end of the process.



* Retiming.  ISE does not offer physical synthesis during place and

  route.  Quartus II does.  We do not use XST (and hence XST

  retiming) since we find this results in a far greater disadvantage

  for Xilinx than when we use a common synthesis tool (Synplicity in

  this case).



* Block Performance.  Maximum block toggle rates are pretty worthless

  if the fabric that stitches the blocks together can't keep up.  Our

  design set includes a variety of types of resources including RAMs

  and DSPs, yet yields +39% performance advantage.  Why?  Our blocks

  have comparable propagation delays which it turns out matters more,

  and our logic & routing are substantially faster.  Also, our Fmax

  limits have increased in Quartus II 4.2 and will continue to

  increase as we complete our detailed characterization process.



* Design entry.  Good advice that applies to any modern FPGA

  (Stratix II and Virtex-4).



* Speed Grades.  We compare to what's available in the software.  If

  users know how much faster a -12 device will be (we do not), they

  can derate our 39% average performance advantage accordingly.





Clock Constraints

^^^^^^^^^^^^^^^^^

    We appear to agree on how to constrain clocks.

    For synthesis, we employ the flow suggested by Synplify to optimize
multiple clock designs.  This results in optimization of all clock domains.
Are there other ways to do it?  Probably -- but since Synplicity Pro 7.7 is
a common-denominator in our comparisons, it is hard to see how changing this
would affect the 39% average performance advantage that we see for Stratix
II.

    For ISE, as outlined in the web-seminar (slide #9) and other locations,
we constrain each clock independently and iterate to find the best such
(tight) constraints.  As you suggest, we do not look at paths that cross
clock domains (difficult to do in an apples-to-apples way).  We do not over
constrain ISE as we have found this degrades Xilinx performance.  Slide #10
shows the results of the iterative constraint process for one design (with
two clocks); I think it highlights the rigour and correctness of this
process.

    I should point out that for Quartus II, we don't need to jump through
hoops since applying a global 1 Ghz constraint on the clocks will result in
each clock being optimized as best as possible.





Synthesis/P&R Effort

^^^^^^^^^^^^^^^^^^^^

    On the P&R front, we use the ISE settings that yield the best
performance results across our benchmark set.  We also run a seed-sweep (or
"multi-pass" compile) using ISE at the end of our iterative process.

    For synthesis, we have no reason to believe that enabling a high-effort
mode in Synplicity would change the conclusions of our comparison, since we
are using the same synthesis tool for both Stratix II and Virtex-4.





Register Retiming/Physical Synthesis

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

    Quartus II can perform physical synthesis optimizations during
place-and-route.  These algorithms have access to detailed placement and
timing information, enabling further optimization that synthesis just can't
know about.  ISE does not provide any such optimizations.  Note: We always
include Tco and Tsu constraints, so our re-timer will not violate I/O timing
to improve core speed.

    We did not use Synplicity's retiming options during these comparisons,
and are in the process of evaluating how the comparison changes when we use
these options.  While one might guess that these optimizations would reduce
Quartus' physical synthesis upside, register retiming is only one of the
many algorithms employed in Quartus physical synthesis and is responsible
for a very small part of +39% performance we see.

    I'm told that ISE also offers some sort of retiming option during
synthesis with XST.  We find that using XST yields much worse Xilinx results
(which make us look much better), so do not use XST, and hence do not use
that retiming option.





Block Performance

^^^^^^^^^^^^^^^^^

    Our benchmarking results address overall performance across real
designs.  These designs contain RAMs, DSP/MAC/Multipliers, adders, counters,
and other such building blocks in a large variety of sizes and varying
quantities.  We do not claim that Stratix II is 39% faster on all building
blocks, but rather that when you put it all together Stratix II is 39%
faster.

    Why is this?  Fundamentally, the logic and routing of Stratix II is
significantly faster -- and you need logic & routing to stitch together the
blocks.  Also, critical paths often start or end on a RAM/DSP, and are very
rarely just a RAM/DSP toggling in isolation.  The timing microparameters of
the RAM/DSP are quite comparable between the two families.  According to the
Virtex 4 data sheet, the DSP microparameters are faster in the -12 device
and we will certainly rerun the analysis when Xilinx releases software that
enables this fastest speed grade.

    Our Fmax limit is not simply just 1/Tco.  The block toggle rate limits
imposed by Quartus II are selected based on characterization to guarantee
operation of our devices in all environments, under all noise and switching
conditions.  When you clock a block very quickly, you start getting
interesting effects that can affect operation.  As we complete the
characterization of hard IP blocks, we will raise these limits.  The Quartus
II 4.2 software introduces higher Fmax limits than stated in this table, and
further increases are likely in future software releases.





Speed Grades

^^^^^^^^^^^^

    I believe we have addressed this in numerous forums.  We use the
available speed grades in the software.  We can't compare to something we
can't get our hands on.  Users can derate our +39% average performance
result by the difference between our fastest and medium speed grade to get a
flavour for how things will compare if & when a fast Virtex-4 speed grade is
made available.



Regards,



Paul Leventis

Altera Corp.



Article: 76690
Subject: Re: Performance claims
From: "Paul Leventis \(at home\)" <paulleventis-news@yahoo.ca>
Date: Wed, 8 Dec 2004 20:32:25 -0500
Links: << >>  << T >>  << A >>
[In my attempt to text-format my first posting, I somehow double spaced
it... weird.  If I fail this time, my descent into management is complete.]

I would like to offer some clarification of points raised in this
whitepaper, first in summary and then in some detail.  I will occasionally
refer to our web-based performance seminar
http://seminar2.techonline.com/s/altera_dec0704) for further details.

* Constraints.  The clock constraint methodology we employ matches
  that outlined in the whitepaper.  It is good to see that both
  companies can agree on something!

* High-Effort Compiles.  We run the ISE software in the mode that
  yields the highest results across our benchmark set.  We also run a
  seed sweep ("multi-pass") for ISE at the end of the process.

* Retiming.  ISE does not offer physical synthesis during place and
  route.  Quartus II does.  We do not use XST and hence XST retiming)
  since we find this results in a far greater disadvantage for Xilinx
  than when we use a common synthesis tool (Synplicity in this case).

* Block Performance.  Maximum block toggle rates are pretty worthless
  if the fabric that stitches the blocks together can't keep up.  Our
  design set includes a variety of types of resources including RAMs
  and DSPs, yet yields +39% performance advantage.  Why?  Our blocks
  have comparable propagation delays which it turns out matters more,
  and our logic & routing are substantially faster.  Also, our Fmax
  limits have increased in Quartus II 4.2 and will continue to increase
  as we complete our detailed characterization process.

* Design entry.  Good advice that applies to any modern FPGA (Stratix
  II and Virtex-4).

* Speed Grades.  We compare to what's available in the software.  If
  users know how much faster a -12 device will be (we do not), they
  can derate our 39% average performance advantage accordingly.

Clock Constraints
^^^^^^^^^^^^^^^^^
    We appear to agree on how to constrain clocks.
    For synthesis, we employ the flow suggested by Synplify to optimize
multiple clock designs.  This results in optimization of all clock domains.
Are there other ways to do it?  Probably -- but since Synplicity Pro 7.7 is
a common-denominator in our comparisons, it is hard to see how changing this
would affect the 39% average performance advantage that we see for Stratix
II.
    For ISE, as outlined in the web-seminar (slide #9) and other locations,
we constrain each clock independently and iterate to find the best such
(tight) constraints.  As you suggest, we do not look at paths that cross
clock domains (difficult to do in an apples-to-apples way).  We do not over
constrain ISE as we have found this degrades Xilinx performance.  Slide #10
shows the results of the iterative constraint process for one design (with
two clocks); I think it highlights the rigour and correctness of this
process.
    I should point out that for Quartus II, we don't need to jump through
hoops since applying a global 1 Ghz constraint on the clocks will result in
each clock being optimized as best as possible.

Synthesis/P&R Effort
^^^^^^^^^^^^^^^^^^^^
    On the P&R front, we use the ISE settings that yield the best
performance results across our benchmark set.  We also run a seed-sweep (or
"multi-pass" compile) using ISE at the end of our iterative process.
    For synthesis, we have no reason to believe that enabling a high-effort
mode in Synplicity would change the conclusions of our comparison, since we
are using the same synthesis tool for both Stratix II and Virtex-4.

Register Retiming/Physical Synthesis
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    Quartus II can perform physical synthesis optimizations during
place-and-route.  These algorithms have access to detailed placement and
timing information, enabling further optimization that synthesis just can't
know about.  ISE does not provide any such optimizations.  Note: We always
include Tco and Tsu constraints, so our re-timer will not violate I/O timing
to improve core speed.
    We did not use Synplicity's retiming options during these comparisons,
and are in the process of evaluating how the comparison changes when we use
these options.  While one might guess that these optimizations would reduce
Quartus' physical synthesis upside, register retiming is only one of the
many algorithms employed in Quartus physical synthesis and is responsible
for a very small part of +39% performance we see.
    I'm told that ISE also offers some sort of retiming option during
synthesis with XST.  We find that using XST yields much worse Xilinx results
(which make us look much better), so do not use XST, and hence do not use
that retiming option.

Block Performance
^^^^^^^^^^^^^^^^^
    Our benchmarking results address overall performance across real
designs.  These designs contain RAMs, DSP/MAC/Multipliers, adders, counters,
and other such building blocks in a large variety of sizes and varying
quantities.  We do not claim that Stratix II is 39% faster on all building
blocks, but rather that when you put it all together Stratix II is 39%
faster.
    Why is this?  Fundamentally, the logic and routing of Stratix II is
significantly faster -- and you need logic & routing to stitch together the
blocks.  Also, critical paths often start or end on a RAM/DSP, and are very
rarely just a RAM/DSP toggling in isolation.  The timing microparameters of
the RAM/DSP are quite comparable between the two families.  According to the
Virtex 4 data sheet, the DSP microparameters are faster in the -12 device
and we will certainly rerun the analysis when Xilinx releases software that
enables this fastest speed grade.
    Our Fmax limit is not simply just 1/Tco.  The block toggle rate limits
imposed by Quartus II are selected based on characterization to guarantee
operation of our devices in all environments, under all noise and switching
conditions.  When you clock a block very quickly, you start getting
interesting effects that can affect operation.  As we complete the
characterization of hard IP blocks, we will raise these limits.  The Quartus
II 4.2 software introduces higher Fmax limits than stated in this table, and
further increases are likely in future software releases.

Speed Grades
^^^^^^^^^^^^
    I believe we have addressed this in numerous forums.  We use the
available speed grades in the software.  We can't compare to something we
can't get our hands on.  Users can derate our +39% average performance
result by the difference between our fastest and medium speed grade to get a
flavour for how things will compare if & when a fast Virtex-4 speed grade is
made available.

Regards,

Paul Leventis
Altera Corp.



Article: 76691
Subject: Re: Open source FPGA EDA Tools
From: rickman <spamgoeshere4@yahoo.com>
Date: Wed, 08 Dec 2004 20:47:01 -0500
Links: << >>  << T >>  << A >>
Mike Treseler wrote:
> 
> rickman wrote:
> 
> > I still don't see any open source tools that are worth using.
> 
> On the back end that may be true.
> However, emacs vhdl-mode and "make"
> are useful to me at the front.

Are you talking about an editor???  I guess you can consider that a tool
for FPGA design, but I think you know I am talking about synthesis,
simulation and P&R.  

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 76692
Subject: Re: fpga prices
From: Chris Carlen <crcarle@BOGUS.sandia.gov>
Date: Wed, 08 Dec 2004 17:52:25 -0800
Links: << >>  << T >>  << A >>
Hernán Sánchez wrote:
> Hi Kubik.
> 
> You can also find boards in http://www.xess.com/  Good prices.
> 
> Cheers,


Ooh, yummy!  I was hoping to find a Spartan 200k board with more than 
1MB RAM than the Digilent board has.



-- 
_______________________________________________________________________
Christopher R. Carlen
Principal Laser/Optical Technologist
Sandia National Laboratories CA USA
crcarle@sandia.gov -- NOTE: Remove "BOGUS" from email address to reply.

Article: 76693
Subject: Re: how to speed up my accumulator ??
From: Allan Herriman <allan.herriman.hates.spam@ctam.com.au.invalid>
Date: Thu, 09 Dec 2004 14:42:01 +1100
Links: << >>  << T >>  << A >>
On Wed, 08 Dec 2004 18:04:31 -0500, rickman <spamgoeshere4@yahoo.com>
wrote:

>John_H wrote:
>> 
>> Noise shaping is the right way to go for a superb quality synthesizer, but
>> the correction phase error - the output from the noise shaper - needs to be
>> applied based on the synchronous edge position relative to the "ideal" edge
>> position - the input to the noise shaper.  (Pseudo)Random doesn't do it.
>> 
>> All this assumes, of course, that there's an analog PLL driven by the single
>> bit, noise-shaped NCO output.  Without the PLL to filter out the high
>> frequency phase noise of a Sigma-Delta style NCO, the jitter is still around
>> 1 reference clock period peak-to-peak, maybe worse.
>
>That answers a question I have had for a long time.  It occured to me a
>long time ago to use an analog PLL to smooth out the ragged edges in an
>NCO clock.  But no one I spoke to about it could say if it would work. 

I must be a 'no one'.

Rick, we have discussed this before, e.g. in this thread:
http://groups-beta.google.com/group/comp.arch.embedded/browse_frm/thread/7e0ec68b5c53e4

This is something I've done in real designs.  I've also developed
tools for estimating the output jitter of the NCO, taking the loop
bandwidth (and order) of the PLL into account.
It is possible to achieve very low levels of jitter at the PLL output,
if the frequencies are carefully chosen such that the higher level
spurious signals at the output of the NCO are well outside the PLL
loop bandwidth.

>I always figured that the low pass filter would do the smoothing for
>me.  

Exactly.  Although this does require the phase detector to be linear
(otherwise the jitter signals will be demodulated).  Common phase
detector types (e.g. most digital phase detectors driving charge
pumps) aren't particularly linear due to inexact balance between the
pull-up and pull-down current sources.  A figure of 10% is sometimes
quoted.

Regards,
Allan

Article: 76694
Subject: Re: Open source FPGA EDA Tools
From: "Tony Burch" <tony@burched.com.au>
Date: Thu, 9 Dec 2004 15:07:12 +1100
Links: << >>  << T >>  << A >>
"SG" <gupt@hotmail.com.NOSPAM> wrote in message 
news:m3wtvsk5mo.fsf@agni.ics.uci.edu...
>
> Looks like ST Micro has been trying to unsuccessfully develop a new
> FPGA for many years with 100s of engineers.  The good thing to come
> out of this project is that they are open-sourcing the EDA tools they
> developed for their FPGA.  These tools (Synthesis, P&R etc) are
> available at:
> http://www.gospl.org
>
> Specifically, see:
> http://www.gospl.org/fpl/static/aboutgospl.jsp
>
> This is good for researchers to play around with tools.  And at first
> glance, looks like a true open-source license (publish any changes to
> source code that you make).  However, ST benefits the most, since they
> get free tool enhancement, while they sell their FPGA fabric as an
> embedded FPGA fabric.
>
> Sumit

It seems that the GOSPL project is not just focused on development
of the tools, but also of the target architectures.  From their website:

"It provides a platform to innovate, improve and define next
generation FPGA architectures and to design optimized silicon
using state-of-the-art circuit designing techniques."

The website implies that users are encouraged to also develop
new FPGA architectures.  There may be an opening here for alot of
interesting FPGA-on-FPGA projects (synthesise your own FPGA architecture
into a Xilinx, Altera, Lattice, ... device).

Something like the old "Meta Programmable Gate Array" project
http://ce.et.tudelft.nl/~reinoud/mpga/README.html


Tony Burch

BurchED, Making FPGA Prototyping Easy, http://www.BurchED.biz
BurchED FPGA boards...
*  Largest number of accessible I/O pins.
*  Widest selection of plug-on modules.
*  Ideal for prototyping real-world designs.
*  Economical for engineering and advanced student projects.



Article: 76695
Subject: Atari 10-in-1 Joystick
From: "Hendra" <u1000393@email.sjsu.edu>
Date: 8 Dec 2004 22:22:40 -0800
Links: << >>  << T >>  << A >>
Has anyone seen Atari 10-in-1 Joystick?
www.walmart.com/catalog/product.gsp?product_id=2233972
It looks really cool! This is the first time that I have seen a
commercially available Atari Resurrection implemented in hardware.
Others are usually emulated in software.
I wonder what kind of chip inside that joystick? Is it an FPGA? And how
many gates would it take to make those games?

Hendra


Article: 76696
Subject: Re: Atari 10-in-1 Joystick
From: "Antti Lukats" <antti@case2000.com>
Date: Thu, 9 Dec 2004 08:47:21 +0100
Links: << >>  << T >>  << A >>
"Hendra" <u1000393@email.sjsu.edu> wrote in message
news:1102573360.598385.97830@c13g2000cwb.googlegroups.com...
> Has anyone seen Atari 10-in-1 Joystick?
> www.walmart.com/catalog/product.gsp?product_id=2233972
> It looks really cool! This is the first time that I have seen a
> commercially available Atari Resurrection implemented in hardware.
> Others are usually emulated in software.
> I wonder what kind of chip inside that joystick? Is it an FPGA? And how
> many gates would it take to make those games?
>
> Hendra

there is also commodore-in-joystick
as those products are deep low priced they do have an ASIC inside not FPGA.
made in china.
at 18.77USD end user price it is not possible to have FPGA based product.
not yet, the FPGA prices are not so down!
BTW in Germany the same thing costs 34EURO !!

I think the atari in joystick is made by that guy who had a webpage about
the 2600 in FPGA, he never released any design files and went commercial.
The commodore-in-joystick is designed by and girl named Jeri who also
designed C1 reconfigurable computer, but then obviously decided there is
more money in joystick business.

antti



Article: 76697
Subject: Re: making an fpga hot
From: "Symon" <symon_brewer@hotmail.com>
Date: Thu, 9 Dec 2004 00:30:25 -0800
Links: << >>  << T >>  << A >>
Hmm, that's very interesting. I wonder if the FPGA vendors have got their 
SLICEs back to front? I.e. the FFs should feed directly into the LUTs within 
the SLICEs, instead of the other way round that exists now. If it saved even 
20% of the power, it'd be worth it. Instead of using all the FFs for 
pipelining, you use them to replicate signals within the SLICEs to prevent 
the glitchy power thing. Hmm, interesting indeed! Thanks Ray.
Cheers, Syms.
"Ray Andraka" <ray@andraka.com> wrote in message 
news:41B787FB.B377EF49@andraka.com...
> The logic transitions in the routing and subsequent differential delays 
> through
> the LUT can make for many more transitions than a simple buffer 
> implemented in a
> LUT.  Unless all the LUT inputs are precisely timed so that the edges 
> change
> together, you wind up with a walk through several of the LUT addresses in 
> the
> process of settling to the next clock.  A paper presented at FPGA a few 
> years
> ago went as far as to say that as much as 30-40% of the power in a typical 
> fpga
> design is due to propagating glitches in the logic between flip-flops, and 
> they
> showed that by heavily pipelining the design, the power consumption 
> improved
> dramatically.
>



Article: 76698
Subject: 100MHz Microblaze and 50 MHz OPB
From: "Julien" <jeyries@hotmail.fr>
Date: 9 Dec 2004 00:43:07 -0800
Links: << >>  << T >>  << A >>
Hello all,

i have a hard time to route my Microblaze sucessfully at 100 MHz
(virtex2 xc2v3000 -5). it seems the limiting point is linked to the
OPB, because i have  2 masters (dopb + iopb) and many peripherals.
here is my question :

is it possible to clock Microblaze with a 100 MHz clock while having
the OPB and its peripherals runnning with a 50 MHz clock ?
has this configuration ever been tested by someone here ?
thank you,

Julien.


Article: 76699
Subject: BurchED FPGA Newsletter, December 2004
From: "Tony Burch" <tony@burched.com.au>
Date: Thu, 9 Dec 2004 21:33:04 +1100
Links: << >>  << T >>  << A >>
BurchED, Making FPGA Prototyping Easy, http://www.burched.biz

In this newsletter:
(1) Sale ending on Saturday.
(2) Free Stuff.
(3) User Login Area.
(4) User website spotlight for December.
(5) How are your latest projects going?

(1) Sale ending on Saturday.
Our sale, offering 10% to 25% off all items, is ending on this Saturday, 11 
December 2004. If you can't purchase this week, please request a quotation 
online - quotations at the sale prices are valid for 30 days.

(2) Free Stuff.
We want to remind everyone about our free stuff, including mailed sets of 
printed product brochures. And also the absolute best guarantee in the 
industry - if you break your FPGA, we will fix it for free!  For details 
please see http://www.burched.biz/FreeStuff.html

(3) User Login Area.
The Sydney-X1 user login area now also has the schematic for the 
B5-Audio-Out module.  Over the coming week, we will be consolidating the 
user login areas into a single user login area, so that all users will have 
access to all of the applications, including the Pacman demo.  For example, 
Super-Value-Pack users will be able to run the Pacman demo (with sound if 
you add a B5-Audio-Out to your system 
http://www.burched.biz/b5audioout.html )

(4) User website spotlight for December.
Altium DXP / Nexar design software
http://www.altium.com/dxpcentral/thirdpartyboards/search/
BurchED boards can be used with the Altium DXP / Nexar design software, by 
connecting Altium's Universal JTAG Interface. Have a look at DXP / Nexar - 
it is a serioulsy powerful design environment for FPGA design (just turn a 
blind-eye to those other develolpment boards while you are there:):) ).

(5) How are your latest FPGA projects going?
As always, we are interested to hear about your latest FPGA projects and 
applications.  Please drop me a line, any time, at tony@burched.com.au





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
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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