[sdiy] FPGA digital audio

[Magnus Danielson]

From: "Jay Schwichtenberg" <schwich at qwest.net>
Subject: RE: [sdiy] FPGA digital audio
Date: Sat, 5 Jan 2002 12:06:54 -0800

> I did sound cards for a while and we used Altera FPGAs as our 'SoundCache'
> controller. We had a card that interfaced directly to the ISA bus via the
> FPGA and cards that went through a PCI controller to a FPGA. The FPGA would
> handle the transfer of data to/from system buss to cache and to/from cache
> to the converters and all the stuff in between (timers, interrupts). At
> first our routes were taking about 8 hrs for the ISA controller. With better
> tools and faster computers we got that down to about 1-2 hrs for the PCI
> designs. On the ISA card we had a EEPROM that we could reprogram once it was
> programmed through the FPGA. For the PCI cards we had enough I/O bits in the
> PCI controller where we could program the FPGA from the driver on startup. I
> did a little of the coding in AHDL (Altera's version of VHDL) but not much,
> we had a hardware guy do that. I think that the advantage that the hardware
> guy had over me (software guy with good EE skills) was that he knew how to
> optimize the design. In reallity I view software pretty much the same as
> VHDL code. All the logic, state machines and asynchronous issues I've had to
> deal with in realtime software only not quite as fast.

I think here is one classic misstake that you are refering to.

There are two kinds of people comming to VHDL, the software guys and
the hardware guys. The software guys just view it as another software
languague and their designs often make a losy hardware synthesis. The
hardware guys on the other hand have problems with the langugue (with
due curses emitted, spontaniously or not) and they will make designs
which probably make good hardware, but is a hell to simulate (which
takes understanding in software). Also, hardware guys do not
parametrize their blocks where as software guys are able to do it.

You have to think in a little of both ways, and they will actually
affect different details most of the times. It also pays of knowing
your actual FPGA hardware so that you can envision how well a certain
style of design may map onto it. Experience show that if you have a
pretty good vision of that, then this is what the synthesis tools will
also give you.

> * Always save a few pins for debugging. You have 10000 gates in a package
> and if you can't see what is inside to debug it you're hosed. (Give me the
> days where I can put my scope on bit 6 of a flip chip accumlator.)

I really agree! Which flip-chip based machine are we talking about
here? The PDP-8? (Incidently I am reading alot of PDP-x material right now.)

> * Yes use the auto-router in the software. You get into a real big bucket of
> worms (more like a 50 gallon drum) if you have to hand optimize/route a
> chip.

Indeed. Unless you have been given an extensively lecture on signal
delays on silicon and are willing to spend time calculating alot of
them yourself, you are far better off with using those tools. When
speed comes into play this is what you usually want to do. You can
also do guided place and route, so that you at least lock crutial
stuff into good places. You can, however, achieve many of those
benefits by just picking good pins for your signals, since this will
automatically give the "right" hints.

> * Always give yourself some way of field programming the FPGA or FPGA ROM.

Indeed. If you are using SRAM based FPGAs (like Xilinx which I happend
to fancy) then doing it like this is certainly worth it. Nowdays you
could even let your computer do it as part of bootstrap, since then
when you upgrade the software files you can also update the FPGA
files.

I know a product (handheld so it had to be minimalistic) where the CPU
actually programs it's glue-logic FPGA (which also do the full DRAM
controler) from the common FLASH as an early part of the bootstrap
process. This allows them to upgrade both FPGA and SW in one single
image. They did fail many times as they tried this out, but once it
worked it actually accelerated their turn-around times alot. They did
not have to have any glue logic to make the CPU keep reading the FLASH
and program the FPGA! ;O)

Cheers,
Magnus