FPGA vs ASIC

When it comes to designing for fpgas or asics there are a lot of
guidelines/rules that need to be followed consistently between the
both.  Yes! things dealing with verilog event queue, metastability and
asynchronous clock domains, etc.  What I am wondering is what are the
key differences between the designs targeted toward one or the other.
Thought it may make an interesting discussion.

Some that come to mind are -

+ Number of logic levels between flops
+ Uniform delay through a lut vs different delays through nand gates.
Asic delays highly dependent on the synthesizer and coding style?
FPGAs more forgiving about how the combinatorial logic is coded?
+ Asynchronous resets in fpgas
+ Clock gating not as efficient in fpga therefore use flop enables.
Require changes to the coding style?
+ Others?

On Fri, 26 Oct 2007 12:51:59 -0000, fpgabuilder
<fpgabuilder-groups@yahoo.com> wrote:

>When it comes to designing for fpgas or asics there are a lot of
>guidelines/rules that need to be followed consistently between the
>both.  Yes! things dealing with verilog event queue, metastability and
>asynchronous clock domains, etc.  What I am wondering is what are the
>key differences between the designs targeted toward one or the other.
>Thought it may make an interesting discussion.
>
>Some that come to mind are -
>
>+ Number of logic levels between flops
>+ Uniform delay through a lut vs different delays through nand gates.
>Asic delays highly dependent on the synthesizer and coding style?
>FPGAs more forgiving about how the combinatorial logic is coded?
>+ Asynchronous resets in fpgas
>+ Clock gating not as efficient in fpga therefore use flop enables.
>Require changes to the coding style?

All good questions, although some of your implied conclusions
are arguable at best.

>+ Others?

I'd suggest the following:
- cost per function (much higher in FPGA) vs. 
  NRE (much higher in ASIC)
- speed/density/power: cutting-edge ASIC will always win on
  all three of these, but the configurability and low NRE of
  FPGA may well win for many applications
- instant-on: most FPGAs need configuration on power-up, and
  this can take some time; ASICs just need stable power rails
  and a reset
- can't integrate custom analog functionality on an FPGA?

But you specifically talked about "designing for"; in that
case, I suspect your next big question should be about
large, fixed functions.  If you want a multiplier, or a
memory, in an FPGA you need to use one of the available
preset configurations of a built-in hard macro.  If you
don't have enough of those hard macros, tough luck.
By contrast, such functions in ASIC are usually provided
as parameterized library macros that can be built in any
reasonable size or shape, and in any number, up to the 
device limits.  And, of course, if you don't use some
hard-macro resource on an FPGA, it's just wasted.  
The FPGA vendors work hard (and smart) to get the balance
about right for the majority of their customers, and to
keep the cost penalties reasonable for the others; but
the issue is definitely there.
-- 
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which 
are not the views of Doulos Ltd., unless specifically stated.

Jonathan Bromley wrote:

> - speed/density/power: cutting-edge ASIC will always win on
>   all three of these, but the configurability and low NRE of
>   FPGA may well win for many applications

This is only true when working in the same feature size.  FPGAs tend to 
be on the bleeding edge of process where ASIC starts usually lag behind 
by at least one or two process generations.  Generally speaking, a lag 
of 2 generations puts a reasonably carefully executed FPGA design pretty 
much on par with an ASIC design in terms of the speed/power/density.

Another factor to consider for FPGAs is that design errors do not 
restart the design cycle clock the way an ASIC error can.

On Oct 26, 7:31 am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:
> All good questions, although some of your implied conclusions
> are arguable at best.

such as?

>
> >+ Others?
>
> I'd suggest the following:
> - cost per function (much higher in FPGA) vs.
>   NRE (much higher in ASIC)

In favor of fpga I would also put down less rigid market window/
size.

> - speed/density/power: cutting-edge ASIC will always win on
>   all three of these, but the configurability and low NRE of
>   FPGA may well win for many applications
> - instant-on: most FPGAs need configuration on power-up, and
>   this can take some time; ASICs just need stable power rails
>   and a reset
> - can't integrate custom analog functionality on an FPGA?
>
> But you specifically talked about "designing for"; in that
> case, I suspect your next big question should be about
> large, fixed functions.  If you want a multiplier, or a
> memory, in an FPGA you need to use one of the available
> preset configurations of a built-in hard macro.  If you
> don't have enough of those hard macros, tough luck.
> By contrast, such functions in ASIC are usually provided
> as parameterized library macros that can be built in any
> reasonable size or shape, and in any number, up to the
> device limits.  And, of course, if you don't use some
> hard-macro resource on an FPGA, it's just wasted.
> The FPGA vendors work hard (and smart) to get the balance
> about right for the majority of their customers, and to
> keep the cost penalties reasonable for the others; but
> the issue is definitely there.
> --
> Jonathan Bromley, Consultant
>
> DOULOS - Developing Design Know-how
> VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services
>
> Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
> jonathan.brom...@MYCOMPANY.comhttp://www.MYCOMPANY.com
>
> The contents of this message may contain personal views which
> are not the views of Doulos Ltd., unless specifically stated.

All good comments.  But they are more related to the FPGA vs ASIC
trade studies...  I am more interested in differences in design
practices...

On Fri, 26 Oct 2007 15:10:25 -0000, fpgabuilder
<fpgabuilder-groups@yahoo.com> wrote:

>On Oct 26, 7:31 am, Jonathan Bromley wrote:
>> All good questions, although some of your implied conclusions
>> are arguable at best.
>
>such as?

"Uniform delay through a LUT" is some way off the truth
these days - fanout delay typically dominates over 
LUT/gate internal delays, and in more recent processes
it's routing delay that matters even more; these issues
hit both ASIC and FPGA designers, albeit with many
differences of detail - as I'm sure you're aware.

"FPGAs more forgiving about how the combinatorial 
logic is coded?"  Not in my experience, for sure - 
although of course almost all of that stuff is
the synthesis tool's problem, not the designer's.

But, to reiterate: interesting questions.  All the
more interesting because the answers to them 
continue to shift thanks to new FPGA, ASIC and 
design tool technology.

> In favor of fpga I would also put down less
> rigid market window/size.

Indeed.

[...]
>All good comments.  But they are more related to the FPGA vs ASIC
>trade studies...  I am more interested in differences in design
>practices...

Well.... I think I know what you're getting at, but surely 
awareness of market issues is a vital skill for designers,
and such issues have a huge influence on design practice?
-- 
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which 
are not the views of Doulos Ltd., unless specifically stated.

"Ray Andraka" <ray@andraka.com> wrote in message 
news:fonUi.949$6e6.111@newsfe16.lga...
> Jonathan Bromley wrote:
>
>> - speed/density/power: cutting-edge ASIC will always win on
>>   all three of these, but the configurability and low NRE of
>>   FPGA may well win for many applications
>
> This is only true when working in the same feature size.  FPGAs tend to be 
> on the bleeding edge of process where ASIC starts usually lag behind by at 
> least one or two process generations.  Generally speaking, a lag of 2 
> generations puts a reasonably carefully executed FPGA design pretty much 
> on par with an ASIC design in terms of the speed/power/density.
>
> Another factor to consider for FPGAs is that design errors do not restart 
> the design cycle clock the way an ASIC error can.

I'd add that IOs for new FPGAs easily outperform IOs for ASICs at a feature 
size that allows a reasonable NRE.  For the 0.18 and 0.15 micron ASICs, the 
IOs just don't compete with FPGAs!  With all the discussion on how ASICs can 
perform better than FPGAs, I was lulled into a false sense of adequacy. 
Compromising on I/O just sucks.  Go Go FPGAs! 

On Oct 26, 10:51 am, fpgabuilder wrote:
> + Others?

On an FPGA your logic will probably run half as fast as the block
memories while on an ASIC it is the other way around. This could lead
to different design styles.

-- Jecel

On 26 Okt., 14:51, fpgabuilder <fpgabuilder-gro...@yahoo.com> wrote:
> When it comes to designing for fpgas or asics there are a lot of
> guidelines/rules that need to be followed consistently between the
> both.
[..]
> Some that come to mind are -
>
> + Number of logic levels between flops
> + Uniform delay through a lut vs different delays through nand gates.
> Asic delays highly dependent on the synthesizer and coding style?
> FPGAs more forgiving about how the combinatorial logic is coded?

I have a different experience. The points above are more a question of
how hard you squeece a technology than a question between ASIC and
FPGA. You can have relaxed designs in both where you don't have to
bother and you can have designs on the edge of  the technology in
both. The only major difference for the points above I would agree is
when it comed to adders because nearly every actual fpga provides fast
carry logic which I haven't seen in ASIC so far. This means that in
ASIC you have a lot faster adders than ripple carry while in fpga you
will use the ripple carry in most cases.

> + Asynchronous resets in fpgas

????

> + Clock gating not as efficient in fpga therefore use flop
enables.

This is one of the most important changes. I have designs which are
implemented in asic and fpga and this is one of the most important
changes.

> + Others?

Whenever I have a relaxed design, I code in a way that fits for all.
If i need to squeeze the last out of the technology, my code depends
on the choosen tech-lib and wouldn't even be easy  portable between
different technologies of the same vendor, so why bother between asic
and fpga?

bye Thomas

On Sat, 27 Oct 2007 00:39:05 -0700, Thomas Stanka
<usenet_nospam_valid@stanka-web.de> wrote:

>when it comed to adders because nearly every actual fpga provides fast
>carry logic which I haven't seen in ASIC so far. 

Almost all ASIC libraires I've used has a full adder in it which is
basically what a fast carry logic is in an FPGA where they have
hardwired full adders which don't need to be made from luts and don't
need the programmable interconnect. I'ts very easy to accomplish the
same in an ASIC.

Are Asics and FPGA's really that close?

The following paper by Kuon and Rose compares a 90nm standard cell
asic technology with a 90nm FPGA, and shows that the FPGA takes a 40x
density hit (only 20x if include FPGA hard macros), critical path
delay 3-4x slower, and dynamic power 12x more.

"Measuring the Gap between FPGAs and Asics", Kuon and Rose,
Proceedings of the 2006 ACM/SIGDA 14th international symposium on
Field programmable gate arrays. Abstract below.

They made the comparison by implementing the following design
elements.

Design,    ALUTs,   Total Memory, 9x9 Bits Multipliers
booth 68 0 0
rs encoder 703 0 0
cordic18 2 105 0 0
cordic8 455 0 0
des area 595 0 0
des perf 2 604 0 0
fir restruct 673 0 0
mac1 1 885 0 0
aes192 1 456 0 0
fir3 84 4 0
diffeq 192 24 0
diffeq2 288 24 0
molecular 8 965 128 0
rs decoder1 706 13 0
rs decoder2 946 9 0
atm 16 544 0 3 204
aes 809 0 32 768
aes inv 943 0 34 176
ethernet 2 122 0 9 216
serialproc 680 0 2 880
fir24 1 235 50 96
pipe5proc 837 8 2 304
raytracer 16 346 171 54 758


Abstract
This paper presents experimental measurements of the differences
between a 90nm CMOS FPGA and 90nm CMOS
Standard Cell ASICs in terms of logic density, circuit speed
and power consumption. We are motivated to make these
measurements to enable system designers to make better informed
choices between these two media and to give insight
to FPGA makers on the deficiencies to attack and thereby
improve FPGAs. In the paper, we describe the methodology
by which the measurements were obtained and we show that,
for circuits containing only combinational logic and flipflops,
the ratio of silicon area required to implement them in
FPGAs and ASICs is on average 40. Modern FPGAs also
contain "hard" blocks such as multiplier/accumulators and
block memories and we find that these blocks reduce this
average area gap significantly to as little as 21. The ratio
of critical path delay, from FPGA to ASIC, is roughly 3 to
4, with less influence from block memory and hard multipliers.
The dynamic power consumption ratio is approximately
12 times and, with hard blocks, this gap generally becomes
smaller.


> > This is only true when working in the same feature size.  FPGAs tend to be
> > on the bleeding edge of process where ASIC starts usually lag behind by at
> > least one or two process generations.  Generally speaking, a lag of 2
> > generations puts a reasonably carefully executed FPGA design pretty much
> > on par with an ASIC design in terms of the speed/power/density.
>
> > Another factor to consider for FPGAs is that design errors do not restart
> > the design cycle clock the way an ASIC error can.
>
> I'd add that IOs for new FPGAs easily outperform IOs for ASICs at a feature
> size that allows a reasonable NRE.  For the 0.18 and 0.15 micron ASICs, the
> IOs just don't compete with FPGAs!  With all the discussion on how ASICs can
> perform better than FPGAs, I was lulled into a false sense of adequacy.
> Compromising on I/O just sucks.  Go Go FPGAs!