[sdiy] FPGA digital audio

[Magnus Danielson]

From: Grant Richter <grichter at asapnet.net>
Subject: Re: [sdiy] FPGA digital audio
Date: Sat, 05 Jan 2002 06:34:25 -0600

Grant, Paul,

> 
> > To be proud to have designed & made everything from scratch, and to have
> > a real application to explore and learn more about FPGA domain (which is what
> > DIY is all about IMHO)...
> > 
> If anyone does get serious about doing an FPGA design. My buddy Nick Hartl
> is the Xilinx field applications engineer (FAE) for the Chicago area. I
> mentioned the idea to him and he has indicated he would help out when he
> can. He's more into detectors for Fermi Lab, but he thinks the idea is
> "quite doable". Gate delays are a uniform 1 nanosecond.

Gate delays isn't everything. Signal propagation delay is another.

The tools naturally attempts to minimize the influence of that, and
there is special tricks like duplication of functions (which cost
logic gates but gains in propagation delay - you move the delay to the
input side before the inevitable flip-flop).

> FPGAs are really large RAMs which do logic by look up tables. They are now
> starting to get to the point where you an mix RAM and logic pretty easy (say
> for a quadrature sine wave generator, a frequency shifter is something that
> could be done in an FPGA). The strength is the software support and multiple
> input formats (schematic, VHDL, others). There are some advantages over a
> DSP approach unless you like to write software.

Right. The BlockRAM they have now is a god-sent gift and Xilinx where
actualy quite taken by supprise when people demanded much more of
it. It turned out that it was often that people had to walk long ways
to overcome the lack of easilly available RAM. I've been there and
done that.

> Some FPGA tips from him:
> 
> Convert all asynchronous signals to synchronous by registering at the input
> pins.

Indeed. This is really what helps getting most designs up to speed.

> Do a completely synchronous design using a single clock.

*Very* good advice. If you have multiple clocks, you need to do clock
boundary passages of signals, and that is really a pain in the ***.
If you don't do propper clock boundary handling you get more or less
frequent spurious behaviour. They are nasty and is best avoided by
propper design. There are, however, cases where you justfully can't
avoid them.

> Always bring at least 4 or more pins to test points for internal probing
> (you can route any signal to a test point to see if it is doing what you
> think)

I'd even say more pins!

>From my own experience I'd say that the form of debugging you can
achieve fairly quickly by pulling out a few signals can be sometimes
crutial to pin down what is really going on.

> Don't hand route (except as a very last resort)

Indeed.

But he has missed one thing which is assumed in the buissness, but if
you come from a traditional background not much thought of until the
tools complaints:

Do not use latches - use flip-flops!

Why?

There's many reasons, but one of them is that when a latch is "open"
you achieve a much longer combinatorial depth than otherwise and this
easilly make the combinatorial length going throuh the latch the
longest one in the entier construction and thus limit the maximum
clockspeed of the design.

This all relates to one of the lessons one has to learn, that one
wants to keep the combinatorial depths as small as possible and keep
things happening in maximum parallelism in order to best make use of
the silicon. Long combinatorial paths is cut up and flip-flops is
inserted inbetween and thus allows for higher speed. All this leads to
thinking about the RTL (Register Transfer Logic) where you have the
logic sitting between registers and processing when you transfer
between one set of register to another set of registers.

Please pay attention to timings and see where the worst path is, this
can give you good help.

If one plans to do DSP stuff in FPGAs, then it simply becomes a topic
on not attempting to have to many operations between the set of
flip-flops. In DSP applications there often presents itself many good
places where flip-flops may be instered or even required for the
normal operation, so in practice it should not be too much of trouble.

It is usually best to design things with a clear though of how it
could be represented and knowing how things becomes synthesized. This
is when you usually best can tweak a design into a limited cell count.

Cheers,
Magnus