Cons of FPGA

[silusilusilu@gmail.com]

I don't know so much about FPGA, so: what are tha cons of use it?When
fpga is avoided and an asic is used?
thanks

 

[bill.sloman@ieee.org]

I don't know so much about FPGA, so: what are tha cons of use it?When
fpga is avoided and an asic is used?
thanks

It's all about non-recurring costs.

I don't know the current figures, but getting an asic means paying for
the device level design and the masks required to turn the design into
working silicon, both of which meant spending tends of thousands of
dollars up front, which used to mean that you have to expect to be
able to sell about 100,000 parts before you could start making money
on the lower cost of the part itself.

 

[Rene Tschaggelar]

I don't know so much about FPGA, so: what are tha cons of use it?When
fpga is avoided and an asic is used?
thanks

A FPGA is on the route to an asic if the specifications permit. For
standard applications this is the case and help you save costs while
developping an asic.

 

[David L. Jones]

I don't know so much about FPGA, so: what are tha cons of use it?

Depends entirely what you compare it to in different apps.
A CON for one app might be might not be a CON for another application.

Some potential CONs:
- they can use a lot of power
- the packages can be BIG. Higher density forces you to use bigger packages
(see my rant: http://www.alternatezone.com/eevblog/?p=32 )
- they can be very expensive (thousands of $$$$ *per chip* for the really
high end devices)
- they can require external programming devices (some are built in)
- they can take time to "boot up" (a few are instant-on)

When fpga is avoided and an asic is used?

When you have enough money and volume, and/or need lower power, smaller die
size etc.

Dave.

 

[MooseFET]

I don't know so much about FPGA, so: what are tha cons of use it?When
fpga is avoided and an asic is used?
thanks

It is really really hard to make a low noise amplifier with good
distortion numbers from an FPGA.

Before you design in an FPGA, CPLD or even a simple PAL, send me an e-
mail asking if I have designed it in. If I have don't use it. I am
still batting 1000 on every part like that I design in, they quit
making.

But seriously, it is all about the engineering time per unit sold.

Also don't write off the idea of using a micro too quickly. If you
can make a micro do it, it will likely be cheaper than an FPGA to
implement.

 

[Jon Kirwan]

I don't know so much about FPGA, so: what are tha cons of use it?When
fpga is avoided and an asic is used?
thanks

Well, I think your homework has been done for you, now.

Jon

 

[Peter]

FWIW, I stopped using FPGAs in 1997 at the Xilinx XC3064 level.

The tools kept changing, they washed their hands of their older
dongles (I had to find a Russian cracker to crack the s/w so I could
carry on using the stuff I paid $xxxxx for) and it made sense only if
one was working with the tools full-time.

Leave it for a year and the tools have changed and you have more to
learn.

The designs are not backward compatible so the only way to run an FPGA
product for say 10 years is to dedicate a special PC to the FPGA
station and keep the various version of the software on it. And hope
the dongles don't break off

And design rules which worked for a few years would stop working once
Xilinx made their D-types faster so the D-Q propagation time became
shorter than the short-interconnect delay - that broke a lot of my
designs and obviously would break any ASIC design because a
fundamental assumption of any synchronous design is that the
interconnect has less delay than the logic.

It just became a huge hassle to maintain the capability.

Obviously hard logic is the only way to do a lot of stuff but I would
try using a fast microcontroller, perhaps with a bit of external
logic, if possible. The assembler for it can run in a DOS box of any
OS and the design is easy to revisit after x years.

But then I am in industrial electronics and run products for 15 years
+.

 

[Anssi Saari]

FWIW, I stopped using FPGAs in 1997 at the Xilinx XC3064 level.

The tools kept changing, they washed their hands of their older
dongles (I had to find a Russian cracker to crack the s/w so I could
carry on using the stuff I paid $xxxxx for) and it made sense only if
one was working with the tools full-time.

Interesting, but these days tools are usually free from the vendor,
except support for the largest parts. Dongles are pretty rare these
days, I think you can get dongles for Altera tools, but there are
other solutions too, like floating licenses or locking to particular
computer, MAC address or HD number or some such.

There were other problems too in the old days, like the myriad of
HDLs. I had to port some Lattice CPLDs to current devices a few years
ago. One was done in Abel, which is no problem, but the other two were
in "LHDL", Lattice's proprietary language. Good thing they had a
knowledgeable FAE...

But then I am in industrial electronics and run products for 15 years
+.

But isn't one use for programmable logic in industrial electronics
implementing old chip functionality inside FPGAs, when those things go
out of production or can't otherwise be used? Especially for products
that have to last longer than 15 years... I did that kind of project
once, implemented some really weird old Siemens 2 Mbps switch chip and
put a good old 8259 in there too.

 

[Peter]

Interesting, but these days tools are usually free from the vendor,
except support for the largest parts.

Xilinx used to charge $thousands for the routing stuff (XACT 6) but
the schematic entry stuff (Viewlogic 4 in those days) was pricey too.
I've still got all that stuff, in boxes somewhere.

One customer came back a year back for a re-order but luckily I found
some of the XC3064s somewhere and used the original hex file.

Dongles are pretty rare these
days, I think you can get dongles for Altera tools, but there are
other solutions too, like floating licenses or locking to particular
computer, MAC address or HD number or some such.

Yeah, really great. An even better way to get screwed.

There were other problems too in the old days, like the myriad of
HDLs. I had to port some Lattice CPLDs to current devices a few years
ago. One was done in Abel, which is no problem, but the other two were
in "LHDL", Lattice's proprietary language. Good thing they had a
knowledgeable FAE...

I gather than most FPGA designs moved to VHDL type tools in recent
years. Again, they were pricey, unless you went for the bottom end. I
recall doing a really weird design flow once: it was a horrid state
machine which I did in CUPL, then used some Viewlogic tool to
synthesise the schematic from the logic equations, then merged this
into the rest of the design. In VHDL, this would all just come
together. But what a learning curve.

But isn't one use for programmable logic in industrial electronics
implementing old chip functionality inside FPGAs, when those things go
out of production or can't otherwise be used? Especially for products
that have to last longer than 15 years... I did that kind of project
once, implemented some really weird old Siemens 2 Mbps switch chip and
put a good old 8259 in there too.

Sure, that's one app. But these are big jobs. I once spent a year on
one design.

It's an interesting way to make a living as a consultant, but when in
manufacturing one avoids dead end technologies, which FPGAs are - not
because the chips become unavailable (you can still buy an XC3064) but
because the tools are so hard to learn and to maintain.

 

[Glen Walpert]

And design rules which worked for a few years would stop working once
Xilinx made their D-types faster so the D-Q propagation time became
shorter than the short-interconnect delay - that broke a lot of my
designs and obviously would break any ASIC design because a
fundamental assumption of any synchronous design is that the
interconnect has less delay than the logic.

Your fundamental assumption amazes me. I have only done 1 project
with FPGAs (polar format variable pixel rate video controller and
dual-port video memory DMA controller for a RADAR target generator),
but knowing how clueless I was on the subject I hired a mainframe ASIC
logic designer to teach me how to do rigorous synchronous state
machine design. Rule one was *never* use single rank transparent
latches, because race conditions can occur if signal propogation
around the loop is faster than the latch transparent time, and
parts/processes are constantly getting faster. With dual rank latches
and a two phase clock there is *no* dependency on minimum propogation
delays. The "D-Q propogation time" through the two latch ranks
includes the minimum time between first and second clock phases; which
can be (usually is?) different from the time between the second clock
phase and the first (allowing longer time for propogation of async
gates than sync latches, as required by your worst case timing
analysis.)

Until your post I never suspected that anyone did it any other way.

 

[Rich Grise]

Use vacuum tubes -- it's a proven technology .

I grew up on toooooobz - when they invented the transistor, it took
me awhile to wrap my head around how they worked; then along came the
JFET and I was, like, "Hallelulah! A transistor that acts like a toob!"
;-)

Cheers!
Rich

 

[Peter]

Your fundamental assumption amazes me. I have only done 1 project
with FPGAs (polar format variable pixel rate video controller and
dual-port video memory DMA controller for a RADAR target generator),
but knowing how clueless I was on the subject I hired a mainframe ASIC
logic designer to teach me how to do rigorous synchronous state
machine design. Rule one was *never* use single rank transparent
latches, because race conditions can occur if signal propogation
around the loop is faster than the latch transparent time, and
parts/processes are constantly getting faster. With dual rank latches
and a two phase clock there is *no* dependency on minimum propogation
delays. The "D-Q propogation time" through the two latch ranks
includes the minimum time between first and second clock phases; which
can be (usually is?) different from the time between the second clock
phase and the first (allowing longer time for propogation of async
gates than sync latches, as required by your worst case timing
analysis.)

Until your post I never suspected that anyone did it any other way.

I think if you look at schematics of standard 74HC type logic, where
there is just one clock, or look in any textbook which shows
schematics of shift registers, counters, etc, they all use just the
one common clock line, and obviously they all rely on the D-Q
propagation time being longer than any timing skew on the clock wire.
This is how people have been building logic for far more years than I
have, AFAIK...

With most logic, one doesn't have the luxury of a 2 phase clock. In an
FPGA you can do all kinds of things...

 

[krw]

I think if you look at schematics of standard 74HC type logic, where
there is just one clock, or look in any textbook which shows
schematics of shift registers, counters, etc, they all use just the
one common clock line, and obviously they all rely on the D-Q
propagation time being longer than any timing skew on the clock wire.
This is how people have been building logic for far more years than I
have, AFAIK...

But as D-Q has gotten faster, clock skew has also dropped. Clock
trees are pretty impressive these days. I've never seen a fast-mode
(set up) timing problem in a properly designed circuit. I saw it in
LSSD ASIC designs (two phase clocks with transparent latches), but it
was always checked.

With most logic, one doesn't have the luxury of a 2 phase clock. In an
FPGA you can do all kinds of things...

Because you can make horrid designs doesn't mean you should.

 

[krw]

Xilinx used to charge $thousands for the routing stuff (XACT 6) but
the schematic entry stuff (Viewlogic 4 in those days) was pricey too.
I've still got all that stuff, in boxes somewhere.

In 1999 the Xilinx Alliance place and route tools were about $1000. I
was using Synplify for synthesis because the Xilinx' stuff sucked. The
free stuff is much better now.

One customer came back a year back for a re-order but luckily I found
some of the XC3064s somewhere and used the original hex file.


Yeah, really great. An even better way to get screwed.

How so? MACs can be spoofed too.

I gather than most FPGA designs moved to VHDL type tools in recent
years. Again, they were pricey, unless you went for the bottom end. I
recall doing a really weird design flow once: it was a horrid state
machine which I did in CUPL, then used some Viewlogic tool to
synthesise the schematic from the logic equations, then merged this
into the rest of the design. In VHDL, this would all just come
together. But what a learning curve.

It's all pretty much free now, except the very high end parts. I
suppose the idea is that if you can afford $5K-$10K parts you can
afford the tools to go with them. ;-)

Actel comes with Synplify and ModelSim. The FAE told me the other day
that other than being the slow version, ModelSim isn't crippled (10K
line limit) as the Xilinx and Altera versions are.

Sure, that's one app. But these are big jobs. I once spent a year on
one design.

A year isn't really a very long time.

It's an interesting way to make a living as a consultant, but when in
manufacturing one avoids dead end technologies, which FPGAs are - not
because the chips become unavailable (you can still buy an XC3064) but
because the tools are so hard to learn and to maintain.

I guess if you avoid some problems you can ignore some solutions.

 

[langwadt@fonz.dk]

I think if you look at schematics of standard 74HC type logic, where
there is just one clock, or look in any textbook which shows
schematics of shift registers, counters, etc, they all use just the
one common clock line, and obviously they all rely on the D-Q
propagation time being longer than any timing skew on the clock wire.
This is how people have been building logic for far more years than I
have, AFAIK...

in an FPGA it's all build in, the hold time on the flops is
practically zero with
clock skew is taken into account, so static time analysis just works
when you do a nice synchronous design.
You only have to make sure the delay from flop to flop is less than
the clock cycle
plus setup time.

With most logic, one doesn't have the luxury of a 2 phase clock. In an
FPGA you can do all kinds of things...

you don't need that, run everything on the same clock and all you need
to know is
that the logic delay between flops is shorter than the clock period.

-Lasse

 

[Glen Walpert]

I think if you look at schematics of standard 74HC type logic, where
there is just one clock, or look in any textbook which shows
schematics of shift registers, counters, etc, they all use just the
one common clock line, and obviously they all rely on the D-Q
propagation time being longer than any timing skew on the clock wire.
This is how people have been building logic for far more years than I
have, AFAIK...

74HC is edge triggered, not transparent, so a two phase clock is not a
necessity there. I misinterpreted your issue, associating a D-Q
propogation time as a property of transparent latches only, and Clk-Q
time the propogation delay of interest for edge triggered latches.
Clk-Q propogation time being faster than clock skew is a problem only
if a fast Q out gets to another D input before it gets its clock (+/-
hold requirement), which sounds like something that might happen if
there are no gates in that signal path, which could be avoided (e.g.
two inverters flagged not to be optimized out) without resorting to a
2 phase clock IMO although a 2 phase clock could also solve that
problem.

 

[Peter]

In 1999 the Xilinx Alliance place and route tools were about $1000. I
was using Synplify for synthesis because the Xilinx' stuff sucked. The
free stuff is much better now.

I paid several times that much for the XACT routing tool.

However, I used it out of a batch file only - never really had to
interact with it.

How so? MACs can be spoofed too.

Indeed but do you know this is what the application uses, for sure? It
also means you have to maintain a network card of a type whose MAC can
be re-written; AFAIK most can't be.

I never understood why the vendors charged so much. The s/w cannot be
used with any other chip.

The Viewlogic (Xilinx restricted) package could not be free because
Xilinx (et al) had to pay for it.

 

[Anssi Saari]

Xilinx has clearly stated in comp.arch.fpga that the 'webpack' is not intended for professional use.
That was obvious to me the first time I used that...

You are absolutely right. ('webpack' is the free Xilinx software', at least
last time I looked).

That's pretty funny, since the paid for version is exactly the same,
except it supports more chips. But yes, they have bugs. Sometimes very
annoying ones, like the one where their tool for configuring a clock
generator (DCM) decided to ground the clock output. Since it was an
internal clock the tools cleverly optimized most of the logic away
since it had no clock. The reason didn't exactly jump out either, so
it took a while...

 

[krw]

I paid several times that much for the XACT routing tool.

I don't remember all the details of the software offerings, a decade
back. Wasn't XACT the full package with the synthesis tools? Anyway,
Alliance was the Xilinx specific PAR and timing tools only. Something
else was needed to get up to the netlist.

However, I used it out of a batch file only - never really had to
interact with it.


Indeed but do you know this is what the application uses, for sure? It
also means you have to maintain a network card of a type whose MAC can
be re-written; AFAIK most can't be.

I don't know now. IIRC, back then you could take your pick; MAC or
disk S/N. I don't really care now, since the tools are free. Last
year I was contracting for a defense company. They made all the tool
choices (ISE and ModelSim) and supported the installations so didn't
much care. ;-)

Back in '99-'01 the tools used printer port dongles. I justified a
laptop (as long as I had to justify it to VPs it was a nice one ;-) as
my design platform, so I could use the tools in the lab too. At one
time I had over $75K in FPGA development software on it. Those days
are long gone. Good thing, my current employer would croak if I gave
them that bill. ;-)

I never understood why the vendors charged so much. The s/w cannot be
used with any other chip.

Because they can. At least that was the answer I got when I asked the
question. Their bean counters had to justify the development cost and
"selling chips" wasn't good enough. Yes, dumb.

The Viewlogic (Xilinx restricted) package could not be free because
Xilinx (et al) had to pay for it.

Yes, but Xilinx could have subsidized it. Actel does that now with
Synplify for their products. Depending on the priority for the next
project, I may use their part. The power consumption numbers look
really nice for a hand-held device. My applications have no need for
speed and flash configuration is a big advantage too. I'm also
waiting to see the final specs on the Cypress PSoC-3. I'm hoping that
it can replace most of our analog stuff and maybe displace FPGAs
before we start. ;-)

 

[Peter]

I don't remember all the details of the software offerings, a decade
back. Wasn't XACT the full package with the synthesis tools? Anyway,
Alliance was the Xilinx specific PAR and timing tools only. Something
else was needed to get up to the netlist.

XACT had no schematic entry support. It took the netlist, basically.