31 Jan
2013
31 Jan
'13
6:42 p.m.
im wondering if anyone has played with these and what kind of
performance they might expect.
http://www.digilentinc.com/Products/Detail.cfm?NavPath=2,400,1028&Prod=…
assuming nothing breaks this year, it might be in the budget
kelly
31 Jan
31 Jan
11:23 p.m.
On Thu, January 31, 2013 9:42 am, Kelly Hirai wrote:
Looks interesting. What are you going to try to do with it? Should make a
nifty portable audio recorder. Should be able to be used as an ether net
sound card. I don't know how well it would work as a guitar effects box or
synth (hmm no midi in). It is meant to be a note pad. The thing you can't
tell from the write up is if there is any hardware that would interfere
with low latency audio. My netbook has that problem with the wireless
chip. I can have low latency audio or wireless, but not both.
--
Len Ovens
www.OvenWerks.net
1 Feb
1 Feb
5:41 p.m.
On 01/02/13 06:22, Len Ovens wrote:
It is certainly nothing like a note pad, it is an evaluation board with a chip
with programmable logic, designed for embedded systems:
http://en.wikipedia.org/wiki/Field-programmable_gate_array
The chip also has an ARM CPU and various other sections as well, and it is
mounted on an evaluation board that has the output pins wired up to some RAM, an
SD card, a Gbit ethernet controller and various other useful things. The
software required to program it is included (it has linux versions). If you want
to explore FPGA logic programming it could be really interesting. For example
seeing what you could do with a 5Mhz bitstream audio output into a very simple
digital amp circuit, or for various DIY interfaces through the GPIO ports. For a
few more $$ there is a pack of 15 cards that plug into those GPIO ports,
including some ADC/DAC stuff. There seem to be some interesting high speed
connection pins also. Being able to program the logic circuits and implement
things on that level allows very different kinds of approaches. Perhaps many
channels of audio output using bitstreams and fairly simple amplifier circuits
which could then be used with the Gbit ethernet to provide an interesting sound
output device. Just playing with ideas here.
Their other FPGA models without the fixed CPU etc might be interesting as well,
you can program a CPU in them if you want, though it won't be as fast as one
with fixed logic it is certainly more flexible if you don't need much in the way
of a CPU. This kit is half the price of the one above:
http://www.xilinx.com/products/boards-and-kits/HW-SPAR3A-SK-UNI-G.htm
There are open source hardware designs that can be put into these FPGAs as well
... look at:
http://opencores.org/
There is another hybrid approach to programmable logic plus a CPU that may be a
much more natural fit with audio DSP programming ...
http://www.stretchinc.com/products/s7000.php
here the idea is that the programmable logic is integrated with the CPU via 32
128-bit registers so that the logic part can be programmed as custom
instructions which are run in the CPUs instruction pipeline. This is quite
different to the Zedboard approach which puts the programmable logic more as
peripheral devices to the CPU. The Stretch seems reasonably mature, it is the
third generation since the original version (in 2004, with PPC CPUs instead of
ARM ones). FPGAs have been around for a very long time, but it seems only
recently got more useful or at least sellable.
The big selling point for Stretch on their website is that their compiler will
compile functions written in C or C++ into their programmable logic that can
then be run as single (big) instructions in the CPU. Also it seems the logic
section has somewhat larger units of logic ... in the Zedboard you have a large
array of 4-bit look up tables and sets of 4000-bit ram modules, connectible to
very configurable GPIO pins while in the Stretch they seem to have adders and
multipliers and so forth (probably much more useful in the context of compiling
code written as a function in a procedural language). No need to learn one of
the hardware logic languages, if the compiler is good enough to do that for you.
From the site it seems they have done quite interesting things with video
codecs, image recognition and such like. The logic part can be reset in 100
microseconds, so for audio use that is only about a 5 sample wait for a new set
of CPU instructions to be loaded. Potentially very interesting.
Simon
9:07 p.m.
On 02/01/13 16:41, Simon Wise wrote:
fpga seems a natural way to
express in silicon, data flow languages like
pd, chuck, csound, ecasound. regarding the stretch, the idea that one
could code in c or c++ might streamline refactoring code, but i'm still
trying to wrap my head around designing graph topology for code that is
tied to the program counter register. nor do i see the right peripherals
for sound. perhaps the g.711 codec support is software implementation
and could be rewritten. need stats on the 8 bnc to dvi adapter audio port.
on the xlinx side, would you really have to hack it in vhdl? rewriting
opcodes / function blocks in vhdl could be rewarding but still, that
would be the end of my time.
k.
11:12 p.m.
On Fri, Feb 01, 2013 at 08:07:46PM +0000, Kelly Hirai wrote:
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
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 perfectly
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 throws
away the whole canon of 'high level tools' or rather replaces it with
his own vision of it - with results that I haven't seen matched ever.
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
2 Feb
2 Feb
12:32 a.m.
On Fri, Feb 1, 2013 at 4:12 PM, Fons Adriaensen <fons(a)linuxaudio.org> 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
3 Feb
3 Feb
4:39 p.m.
On 02/02/13 07:32, Charles Z Henry wrote:
have you seen this:
http://haskell.cs.yale.edu/euterpea-2/
so the combination of using Euterpea in Haskell then compiling to vhdl or
verilog seems quite promising, and possibly a way to make audio use of FPGAs in
the context of a language that may be a more natural way to write for logic
implementations than many. I suspect Haskell's style of functional language and
the very serious efforts working with compilers for it could lead somewhere.
It's been on my TODO list for a few months now, recommended by my lecturer for
Programming Paradigms (we used F#), but the compiling to vhdl is news ... too
much to look at, too little time!
Simon
4 Feb
4 Feb
5:46 p.m.
Interesting! Euterpea looks very cool. I may just have to learn Haskell
sometime and try it out.
BTW, the compilation tools I mentioned are part of the Kansas-Lava package
in Haskell. You can have a look at the group's page
http://www.ittc.ku.edu/csdl/fpg/software.html
Dr. Gill is the researcher in charge of the group.
On Sun, Feb 3, 2013 at 9:38 AM, Simon Wise <simonzwise(a)gmail.com> wrote:
6 Feb
6 Feb
12:04 a.m.
On 02/01/2013 11:32 PM, Charles Z Henry wrote:
There is an older publication on Faust and FPGA, haven't read it tough:
http://faust.grame.fr/index.php/documentation/papers/31-dafx2006-art
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
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.
Jeremia
3 Feb
3 Feb
3:32 p.m.
On 02/02/13 04:07, Kelly Hirai wrote:
The Stretch seems to be focussed on video, the examples given to explain their
compiler process show it picking reasonably complex mathematical expressions
inside loops which it then converts to logic with registers in and out, I guess
probably duplicated logic if possible. That way the critical inner loops are
optimised. With video and image recognition stuff it could work very well, there
is lots of iterating over rows of pixels with convolutions and stuff in those
algorithms.
> on the xlinx side, would you really have to
hack it in vhdl? rewriting
> opcodes / function blocks in vhdl could be rewarding but still, that
> would be the end of my time.
The Xilinx software claims to include a large library of elements to use, not
sure what areas they would cover, and there seems to be some DSP stuff too,
perhaps at extra cost. The example application on the website is building
automotive sound systems ... which would involve filters, eqs, codecs, radio
decoders and so forth.
But the open source stuff seems pretty serious as well, with NASA and the
European Space Agency featuring as contributors. They probably use a lot of DSP,
in many frequency ranges, so maybe they have contributed more than just their
CPU designs?
For serious audio the large supply of GPIO pins connected to the FPGA all on the
chip seems to fit a physical control surface with lots of inputs and extremely
low latency very well. And as you say the dataflow languages seem to fit the
FPGA type of machine very well.
But all of this is serious, time consuming, work of course.
Simon
4443
days inactive
4448
days old
linux-audio-user@lists.linuxaudio.org
9 comments
6 participants
participants (6)
-
Charles Z Henry -
Fons Adriaensen -
Jeremia Bär -
Kelly Hirai -
Len Ovens -
Simon Wise