Prev: PCB routing issues for sync SRAM
Next: Version of Xilinx ISE for Spartan 6 FPGAs
From: glen herrmannsfeldt on 26 Mar 2010 17:14
In comp.arch.fpga Thomas Entner <thomas.entner(a)entner-electronics.com> wrote:
(snip)

> I do not know the book, but it is hard for me to not disagree with the
> statement, that a digital logic designer is not responsible for the
> speed of the circuit. Especially when you are talking about domino
> logic, etc. in your other posts, when I remember right ;-)

I disagree. In many FPGA projects, speed is the reason for doing
the project. Many things can be done on existing processors, but
not quite fast enough. The primary goal, then, is to design
the logic to be fast. In the case of pipelined arrays, one
might need to maximize speed/cost, which is, again, a logic
design problem.

There are also many problems where speed isn't so important.

-- glen
From: Patrick Maupin on 26 Mar 2010 20:12
On Mar 26, 4:14 pm, glen herrmannsfeldt <g...(a)ugcs.caltech.edu> wrote:

> I disagree.  In many FPGA projects, speed is the reason for doing
> the project.  Many things can be done on existing processors, but
> not quite fast enough.  The primary goal, then, is to design
> the logic to be fast.  In the case of pipelined arrays, one
> might need to maximize speed/cost, which is, again, a logic
> design problem.  
>
> There are also many problems where speed isn't so important.

Well, to be fair, the discussion about speed was about CMOS design,
and transistor-level CMOS is a different skill than digital design
(although it often resides in the same individual).

But to your point about FPGAs, I agree that an "FPGA designer" often
needs to be acutely aware of how to make things go fast in an FPGA
(which is often more a matter of being willing to experiment, and
certainly doesn't require the same low-level hardware understanding as
dealing with domino logic does). Where I work, we build real chips,
but emulate them in FPGAs. Gates are so cheap these days, and the
real silicon is so fast, that my mantra to the digital designers is
always to make it work well and fast in the FPGA, and the chip will
take care of itself. If you code in a fashion that is designed to be
highly optimized for real silicon, sure you might save a milli-cent
per chip, but if you weren't able to emulate it at speed (or even if
you were able to emulate it at speed, but only through heroic work by
the FPGA emulator guy and multiple 30 hour PAR sessions), that could
cost you a lot more than your putative savings.

Regards,
Pat
From: Weng Tianxiang on 27 Mar 2010 22:26
On Mar 26, 5:12 pm, Patrick Maupin <pmau...(a)gmail.com> wrote:
> On Mar 26, 4:14 pm, glen herrmannsfeldt <g...(a)ugcs.caltech.edu> wrote:
>
> > I disagree.  In many FPGA projects, speed is the reason for doing
> > the project.  Many things can be done on existing processors, but
> > not quite fast enough.  The primary goal, then, is to design
> > the logic to be fast.  In the case of pipelined arrays, one
> > might need to maximize speed/cost, which is, again, a logic
> > design problem.  
>
> > There are also many problems where speed isn't so important.
>
> Well, to be fair, the discussion about speed was about CMOS design,
> and transistor-level CMOS is a different skill than digital design
> (although it often resides in the same individual).
>
> But to your point about FPGAs, I agree that an "FPGA designer" often
> needs to be acutely aware of how to make things go fast in an FPGA
> (which is often more a matter of being willing to experiment, and
> certainly doesn't require the same low-level hardware understanding as
> dealing with domino logic does).  Where I work, we build real chips,
> but emulate them in FPGAs.  Gates are so cheap these days, and the
> real silicon is so fast, that my mantra to the digital designers is
> always to make it work well and fast in the FPGA, and the chip will
> take care of itself.  If you code in a fashion that is designed to be
> highly optimized for real silicon, sure you might save a milli-cent
> per chip, but if you weren't able to emulate it at speed (or even if
> you were able to emulate it at speed, but only through heroic work by
> the FPGA emulator guy and multiple 30 hour PAR sessions), that could
> cost you a lot more than your putative savings.
>
> Regards,
> Pat

Thomas,
1. Speed is the life of a digital design.
2. When dealing with FPGA, I know how a logic design affects its speed
by counting how many number of inputs are there for a logic equation,
no more than that.
3. When dealing with modern more than 1GHz ASIC, all logic may be
implemented as a domino logic which has nothing to do with how a non-
domino logic is compiled by a compiler.

In both situation, one doesn't have to know how a non-domino logic is
compiled.

For example, it is to determine if a 32-bit data is a data zero by
following equation:
IsZero <= a1 or a2 or ... or a31;

A digital circuit designer for either FPGA or modern more than 1GHz
ASIC doesn't have to understand how the logic is compiled by a
compiler:
IsZero <= (a1 or a2 or ... or a4) or ... (a30 or a31);
or
IsZero <= (a1 or a2 or ... or a3) or ... (a28 ... or a31);

The book: Logical Effort: Designing Fast CMOS Circuits (The Morgan
Kaufmann
Series in Computer Architecture and Design) by Ivan Sutherland,
Robert
F. Sproull, and David Harris (Paperback - Feb. 16, 1999)
tells that when 4 inputs of OR gates may be the fastest.

The information is really useless.

Weng





 | 
Pages: 1
Prev: PCB routing issues for sync SRAM
Next: Version of Xilinx ISE for Spartan 6 FPGAs