<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 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 class="gmail_extra"><br></div><div class="gmail_extra">All the same, it's a bit limited when compared to x86_64 
instruction sets.  I think it's nearly impossible to get pd running on a
 fpga with decent performance (I can speak only of the software I know 
well enough).  But there's the rub anyway--your x86_64 processors don't have access to interfaces by themselves.  On opencores, there's a fpga QPI endpoint.  Wouldn't it be cool to build an audio interface *directly* off the processor's QPI lanes?  I know... I'm dreaming<br>
</div><br></div><div>Chuck<br></div><div> </div></div></div></div></div></div></div></div>