Re: [LAU] zedboard fpga dev board and linux audio

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: Fons Adriaensen <fons@...>, linux-audio-user <linux-audio-user@...>
Date: Friday, February 1, 2013 - 11:32 pm

--001636c5b4723b2a0704d4b22750
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Feb 1, 2013 at 4:12 PM, Fons Adriaensen wrote:

> On Fri, Feb 01, 2013 at 08:07:46PM +0000, Kelly Hirai wrote:

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.

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

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

Chuck

--001636c5b4723b2a0704d4b22750
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Fri, Feb 1, 2013 at 4:12 PM, Fons Adriaensen <fon=
s@linuxaudio.org
> wrote:
On Fri,=
Feb 01, 2013 at 08:07:46PM +0000, Kelly Hirai wrote:

> fpga seems a natural way to express in silicon, data flow languages li=
ke

br>
still
s
ls
br>
ort.

There are many ways to use an fpga. I've got a friend who's a=
real
wizard in this game, and his approach is quite unusual but very
effective.
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,
maybe having 5 to 20 carefully chosen instructions, usually all of them
conditional (ARM style), and coded if necessary in very wide instruction
words so there's no microcode and these processors are incredibly fast.=

It takes him a few hours to define such a processor, and a few more hours
more to create an assembler for it in Python. Then he starts coding the
required algorithms using these processors.
If necessary, he'll revise the processor design until it's perfectl=
y
matched to the problem. In all cases I've watched, this results in
something that most other designers couldn't even dream of in terms
of speed and efficiency - not only of the result, but also of the
design process and hence the economics.
All of this is of course very 'politically incorrect' - he just thr=
ows
away the whole canon of 'high level tools' or rather replaces it wi=
th
his own vision of it - with results that I haven't seen matched ever.Gotta say, you guys impress me.=A0 I think emb=
edded programming is=20
pretty tough.=A0 I bombed my FPGA class last spring--I gave up too soon=20
for that class, but haven't given up altogether.=A0 There's a lot o=
f value
for rt-audio there.One topic of research where I'm at (I=
TTC/KU)
concerns compilation from Haskell (a relational language) to verilog or=20
vhdl for synthesis on fpga's--not going through the usual chain of=20
defining a processor but actually building the specific functions (greater =
utilization this way as I understood it).=A0 Maybe someday Faust (the audio=
relational language) will=20
have a similar compiler target like this too=
All the same, it's a bit limited w=
hen compared to x86_64=20
instruction sets.=A0 I think it's nearly impossible to get pd running o=
n a
fpga with decent performance (I can speak only of the software I know=20
well enough).=A0 But there's the rub anyway--your x86_64 processors don=
't have access to interfaces by themselves.=A0 On opencores, there'=
s a fpga QPI endpoint.=A0 Wouldn't it be cool to build an audio interfa=
ce *directly* off the processor's QPI lanes?=A0 I know... I'm dream=
ing
Chuck=A0<=
/div>

--001636c5b4723b2a0704d4b22750--

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
[LAU] zedboard fpga dev board and linux audio, Kelly Hirai, (Thu Jan 31, 5:42 pm)
Re: [LAU] zedboard fpga dev board and linux audio, Len Ovens, (Thu Jan 31, 10:23 pm)
Re: [LAU] zedboard fpga dev board and linux audio, Simon Wise, (Fri Feb 1, 4:41 pm)
Re: [LAU] zedboard fpga dev board and linux audio, Kelly Hirai, (Fri Feb 1, 8:07 pm)
Re: [LAU] zedboard fpga dev board and linux audio, Simon Wise, (Sun Feb 3, 2:32 pm)
Re: [LAU] zedboard fpga dev board and linux audio, Fons Adriaensen, (Fri Feb 1, 10:12 pm)
Re: [LAU] zedboard fpga dev board and linux audio, Charles Z Henry, (Fri Feb 1, 11:32 pm)
Re: [LAU] zedboard fpga dev board and linux audio, Jeremia Bär, (Tue Feb 5, 11:04 pm)
Re: [LAU] zedboard fpga dev board and linux audio, Simon Wise, (Sun Feb 3, 3:39 pm)
Re: [LAU] zedboard fpga dev board and linux audio, Charles Z Henry, (Mon Feb 4, 4:47 pm)