<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
On 02/01/2013 11:32 PM, Charles Z Henry wrote:
<blockquote
cite="mid:CAPfmNOGqgzP9nbQc9dJdZUZug-4AB0+CcT+WQyrukGm-E93zyQ@mail.gmail.com"
type="cite">
<div dir="ltr"><br>
<div>
<div>
<div>
<div>
<div class="gmail_extra">
<div class="gmail_quote">On Fri, Feb 1, 2013 at 4:12
PM, Fons Adriaensen <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:fons@linuxaudio.org"
target="_blank">fons@linuxaudio.org</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin: 0px
0px 0px 0.8ex; border-left: 1px solid rgb(204,
204, 204); padding-left: 1ex;">
<div class="im">On Fri, Feb 01, 2013 at 08:07:46PM
+0000, Kelly Hirai wrote:<br>
<br>
> fpga seems a natural way to express in
silicon, data flow languages like<br>
> pd, chuck, csound, ecasound. regarding the
stretch, the idea that one<br>
> could code in c or c++ might streamline
refactoring code, but i'm still<br>
> trying to wrap my head around designing
graph topology for code that is<br>
> tied to the program counter register. nor
do i see the right peripherals<br>
> for sound. perhaps the g.711 codec support
is software implementation<br>
> and could be rewritten. need stats on the 8
bnc to dvi adapter audio port.<br>
<br>
</div>
There are many ways to use an fpga. I've got a
friend who's a real<br>
wizard in this game, and his approach is quite
unusual but very<br>
effective.<br>
In most cases, after having analysed the problem
at hand, he'll design<br>
one or more ad-hoc processors in vhdl. They are
always very minimal,<br>
maybe having 5 to 20 carefully chosen
instructions, usually all of them<br>
conditional (ARM style), and coded if necessary in
very wide instruction<br>
words so there's no microcode and these processors
are incredibly fast.<br>
It takes him a few hours to define such a
processor, and a few more hours<br>
more to create an assembler for it in Python. Then
he starts coding the<br>
required algorithms using these processors.<br>
If necessary, he'll revise the processor design
until it's perfectly<br>
matched to the problem. In all cases I've watched,
this results in<br>
something that most other designers couldn't even
dream of in terms<br>
of speed and efficiency - not only of the result,
but also of the<br>
design process and hence the economics.<br>
All of this is of course very 'politically
incorrect' - he just throws<br>
away the whole canon of 'high level tools' or
rather replaces it with<br>
his own vision of it - with results that I haven't
seen matched ever.<br>
</blockquote>
<div>
<div><br>
Gotta say, you guys impress me. I think
embedded programming is pretty tough. I bombed
my FPGA class last spring--I gave up too soon
for that class, but haven't given up
altogether. There's a lot of value for rt-audio
there.<br>
<br>
</div>
One topic of research where I'm at (ITTC/KU)
concerns compilation from Haskell (a relational
language) to verilog or vhdl for synthesis on
fpga's--not going through the usual chain of
defining a processor but actually building the
specific functions (greater utilization this way
as I understood it). Maybe someday Faust (the
audio relational language) will have a similar
compiler target like this too<br>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<br>
There is an older publication on Faust and FPGA, haven't read it
tough:<br>
<a class="moz-txt-link-freetext" href="http://faust.grame.fr/index.php/documentation/papers/31-dafx2006-art">http://faust.grame.fr/index.php/documentation/papers/31-dafx2006-art</a><br>
<br>
I have implemented a runtime-configurable audio SoC on FPGA as a
semester project as part of my graduate program. The data processing
runs completely without a processor but all the audio filters were
hand-crafted in Verilog. That's certainly not the way to go for more
complex filters. But a nice little guitar FX to play around with :-D<br>
<br>
As the Zynq is a FPGA/ARM combo, maybe it's possible to write a Jack
client that runs on Linux on the ARM and offloads some more complex
FIR filters to the FPGA fabric. This filter acceleration approach in
general is a hot research topic a few colleagues of mine are
researching in.<br>
<br>
Jeremia<br>
</body>
</html>