Re: Why No Process Shrink On Prior FPGA Devices ?

This is a meaningful exchange of ideas.
But:
We have a "Toyota", it's called Spartan.
More seriously:
Mask shrinks, or redesigns to a maller geometry would definitely make
the chip smaller, probably cheaper, but would achieve only a tiny
performance boost.
The days are long gone when the next technology made the chip
automatically much faster.
If we can eke a 10% speed improvement out of the process alone, we are
happy.
The real speed boost of 30+% comes mainly from more creative designs
and architectures, hard cores and better software. But not from smaller
feature sizes and thinner gate oxide.
(The trace-to-trace capacitance actually goes up with narrower traces
packed more closely together).
Higher performance requires radical innovation and real cleverness
these days.
Peter Alfke
=================
tweed_deluxe wrote:
Thanks for the replies folks, I appreciate it.

These are answers I suspected but wanted to hear from the horses mouth.

I think the second paragraph of my post is the crux of what I was
getting at and Jim's comments are particularly germane. Is the aspect
of maintaining pinout compatability across a few device generations a
poor business case as well ? It would appear to be so ...

I understand the "Porsche" design philosophy and the apparant need to
remain on the bleeding edge (with the silicon) in order to create
and/or sustain a position of market leadership. It's one particular
facet of a business model and, sometimes, it makes for wonderful
magazine advertisements. For now, it seems that the company with the
biggest baddest FPGA is a pre-requisite for making the most money.
(Although placing and routing a fully loaded V4 LX200 on a Windows box
is an exercise in extreme patience :) )

From a financial perspective, Toyota is more successful company than
Porsche. I realize that these automobile analogies can be taken far
out of context. But there are times when I can't help but desire a
little more "Toyota" and a little less "Porsche" from the big FPGA
outfits.

The rapid evolution of the silicon and underlying change in FPGA
feature sets does impose challenges (i.e. consequences). The need to
significantly re-work existing hardware that seeks a modest tech
re-fresh is self evident .... and a rubbing point for ordinary average
joe's like me.

However, the stresses placed on the tool-chain developers cranking out
ISE, EDK, SysGen, and related IP must be formidable. It probably also
makes things interesting for the FAE staff and support services. The
latest "gee-whiz" device will (and does) pre-empt soreley needed
improvments to the design tools as well as refined integration and
interplay between them. Integration that truly renders platform FPGA
design fluid, user friendly, bug-free, and productive. I'm not saying
that Xilinx hasn't made key strides in merging the EDK, ISE, DSP, and
other flows. It is the basis for many shining moments in our shop.
But, we've been users since day 1 and its got a long long way to go
before my co-workers and I go through a day without muttering a four
letter word :).

Maybe all of this banter is/was simply about wondering where to put the
eggs in the FPGA basket. Asking if there is possibly more money to be
made by offering a "lesser device" or "more comprimised design
approach" that, increases the investment in other areas to yield
visibly superior tools, more FPGA IP, a quantum leap in productivity,
ease of upgrading to future silicon devices etc.


Regards,


Chris

.

Relevant Pages

  • Re: Why No Process Shrink On Prior FPGA Devices ?
    ... I understand the "Porsche" design philosophy and the apparant need to ... The rapid evolution of the silicon and underlying change in FPGA ... visibly superior tools, more FPGA IP, a quantum leap in productivity, ...
    (comp.arch.fpga)
  • Re: free software/open source projects and FPGA?
    ... FPGA and electronics design/verification community. ... for maximal cost-effectiveness and productivity. ... things will depend on whether hardware design ... becomes a "mainstream" software development technology. ...
    (comp.arch.fpga)
  • Re: Series Termination
    ... reduced the trace width necessary for a particular transmission line. ... So far there is no useful output from the FPGA, ... much design there yet) and transmitted. ... loops with multiple caps on the supply lines. ...
    (sci.electronics.design)
  • Re: How big is my vhdl and am I approaching some size limitation on the chip.
    ... put you off going for FPGA. ... The Virtex range is ... ERROR:Cpld:1063 - Design requires at least 947 macrocells, ...
    (comp.arch.fpga)
  • Re: AES encryption of bitstream - is my design secure?
    ... that someone will find an affordable use for the hardware. ... "face recognition" as hardware algorithm in FPGA, ... Better for Design ... but are these really easier with a new bitstream attack? ...
    (comp.arch.fpga)
Loading