basic DSP with FPGA

Hi all, I'm new to FPGA stuff... i have an idea of making an audio spectrum analyzer implemented on a fpga, displaying data on a VGA monitor (spartan-3 starter kit). I guess I will need to filter the audio data in some way (band pass filters for each channel?), and I want to do it with the FPGA. That is, I'll get some ADC and plug it to the FPGA, and then process the audio, first some basic filters for audio manipulation (low pass, "bass boost", etc), and then move on to something more complex.. Does anyone have some pointers of how to implement this kind of filtering with FPGAs?

Regards, Hernan

PS. Happy new year! (31/12/2005 9:51 PM here)

Reply to
drg
Loading thread data ...

This is basic DSP stuff. At its most basic you're just implementing the math on an FPGA; in reality you're going to be doing a bunch of messing around with the details of the process.

You really need to know three things: DSP, FPGA design, and optimizing FPGA designs for DSP. For the DSP part of it I recommend "Understanding Digital Signal Processing" by Rick Lyons. I learned logic design by osmosis, so I can't recommend any one text. When you get to the part of merging the two onto a real, live FPGA I'd check the Xilinx web site for app notes.

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com
Reply to
Tim Wescott

Alternatively use Altera instead where the DSP tools come fitted as standard. You can create your own filter specification by specifying number of bits/filter type/number of stages/sample rate etc. The tool will then plot the actual achieved response which you can then tweak dynamically. Code is then generated which you then drop into your design. Simplicity itself really if you do not want to get deep into the math.

Slurp

Reply to
Slurp

yes, that's my problem, the maths. I'm still in college (systems engineering), but I have yet to learn all that advanced math to understand even the most basic DSP text. These are all full of huge formulas and complex numbers... I'm not trying to sound lazy but I don't think it has to be that complicated.

I just need a routine, and to learn how to use it (I seem to have found it at opencores

formatting link
along with DSPlay to generate the coefficients.

Regards, hjf

Reply to
drg

I'm not quite sure but spectrum analyzer sounds like FFT.

I suggest you start doing all this at a higher level, let's say Ada or C#. You can do your researches without dealing with FPGAs and so on.

You already know that this is DSP stuff, but it doesn't matter if you use your normal CPU or a real DSP (probably as VHDL).

You'll see that (in general) a DSP is just a processor which is good for MAC: multiply-and-accumulate, so to say "*" and "+", but you can also do this with your Athlon ;)

Have a look at PCM to understand how audio data is represented for processing, what a sample is and why PCM is almost Wave. You can compare your results by looking at .

Then start writing your code in a highlevel language and use normal wave-files (or raw PCM) to feed your software audio processor. You can write some basic effects like "echo" by filling a buffer, dividing (lowering volume) and adding it to the main signal after some delay (sidechain-FIFO).

You can change the volume by multiplying the signal with a scalar.

After you've done all this, you can get a real ADC, a soft-IP DSP, poke everything to your FPGA and use your new hardware to do the job ;) Until then, read/write from/to wave files or your soundcard.

I suggest you use Linux, have a look at the "sox" manpage, play with sox -x -t raw/wav and so on. If your CPU is fast enough, you can read vom /dev/dsp, calculate some functions and write the results back to /dev/dsp. I usually read from wave files and write to /dev/dsp to get an immediate impression of what goes wrong... ;)

There is also some more audio processing software for Linux, most of it is open source, so you can see how to implement the FFT for your spectrum analyzer, filter effects (see LADSPA) and so on.

I haven't ever tried a real DSP, but some datasheets claim FFT-optimization, so it might be possible to pass a buffer to a special asm-function, returning the FFT-transformed of the input.

One word left: you'll probably implement your filters in your DSP's assembler. So to say: it is all about software and it is hardware specific. That's why you can use a highlevel language to understand what's going on. Filtering is more or less easy, have a look at your opencores example:

y[n] = b10*x[n] + b11*x[n-1] + b12*x[n-2] + a11*y[n-1] + a12*y[n-2]

where x[n] represents the current input, x[n-1] is the previous sample, y[n-1] is the previous output sample and all "a"s and "b"s are simple coefficients for fitting the desired curve. y[n] is your current output.

With libao, one can write this program in less than 10 minutes, it goes like this:

procedure iir is b10 : constant Float := 1.2345; b11 : constant Float := 2.3456; b12 : constant Float := 3.4567; a11 : constant Float := 4.5678; a12 : constant Float := 5.6789;

x, x1, x2, y, y1, y2 : Float := 0.0;

begin loop x := Get_Input; -- however y := b10 * x + b11 * x1 + b12 * x2 + a11 * y1 + a12 * y2; Output (y); -- however y2 := y1; -- prepare for next cycle y1 := y; x2 := x1; x1 := x; end loop; end iir;

The convolution of the input signal with this mask isn't that hard, all the trick is in the mask. I'm currently doing some digital image processing with C++, in most cases this means looping over the image, consider the pixels in the neighbourhood and somehow adding them to the current pixel. This is pretty much how audio processing works: look at current, some older and perhaps some newer samples, take them in consideration and output something according to this consideration ;)

Get a book or google for digital signal processing.

HTH

--
mail: adi@thur.de  	http://adi.thur.de	PGP: v2-key via keyserver

Lieber ein Busenwunder als ein wunder Busen
Reply to
Adrian Knoth

Hello Herman,

Number of choices....

1....Altera DSP Builder 2....Xilinx Coregen 3....Tyder IP Code Generator 4....Google

Regards Bob drg wrote:

Reply to
stenasc

Reply to
David R Brooks

Heh. The math will come in handy when (not if) you design doesn't work correctly. You really need to build a basic understanding of what you are trying to do first. How else are you going to find out what's wrong when things start to misbehave ? What you are trying to do sounds like a very interesting - but also very complex - project. I would guess that you need to go through the following steps - Note that you can shortcut the process a lot of places by using already existing modules. This of course will get you to your goal faster, but you will learn less in the process - YMMV:

1) You need to buy/make an A/D converter module for the starter kit, since it does not come with one. 2) Design a filter bank. For spectrum analysis a 3rd octave bank is probably what you want. You can get plenty of references for how to design that on Google. This will involve IIR filters - so knowing the math (and how to implement them in fixed point) will be useful unless you shortcut the process and grab some already-made implementation from somewhere. It will REALLY help you debugging your system if you have a known-to-work high level implementation (Matlab, Numerical Python or C as a last resort) that you can compare your results to. 3) Get the filter bank implemented in some HDL (I prefer Verilog but others prefer VHDL). Here a book like "Digital Signal Processing With Field Programmable Gate Arrays" by Uwe Meyer-Baese might come in handy. Alternatively Mathworks and others will happily compile your high-level implementation directly to your FPGA to the tune of big $$$. But again - you will learn less in the process. If you choose to implement yourself I can recommend using the free Xilinx tools to do implementation and simulation. 4) A filter bank does not a spectrum analyzer make. You need to present this on the VGA output. This means building a graphics frame buffer structure for outputting the graphics, and then some kind of processor structure to fill the frame buffer in a sensible way based on the filter bank output. Here I guess that the best way to go would be to get an already made processor core like the picoblaze and use that to do the presentation. For the frame buffer you will be able to find examples on the web.

Have fun - I mean it - I for one find it to be a very interesting project, that you will learn a lot from if you choose to dwelve into all the topics involved.

-- Brian

Reply to
Brian Dam Pedersen

Hi One thing at practical side. You should remember about simple analog Low-pass filter before A/D converter. If you'll forget it You will be very surprised. It could be that you'll see signals on your spectrum analyzer that you can't hear at all (Nyquist, aliasing...)

Good luck.

Jerzy Gbur

Reply to
jerzy.gbur

Hi Hernan, Maybe you should stop using your time on your Spectrum Analyser project and spend it learning the maths? Just a thought? ;-) Cheers, Syms.

Reply to
Symon

All of the folks that I've ever met with the title "systems engineer" are people who are very good at math* _and_ at applying it to the real world. I'm not sure what systems engineering one could do without that capability.

  • Regrettably the 's' fell overboard somewhere in the Atlantic.
--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com
Reply to
Tim Wescott

Comment:

If I had been able to use MatLab, MatchCad, or Mathematica when I was in school, I would be even further along than I am today. With these math tools avaialble, get one, and master it.

The idea of hand cranking any of the DSP math is so paiful (I did it!) that now I can not even imagine doing it by hand today.

You learn the concepts, and the theory faster if you have something that allows you to get through the math bits.

As a good friend of mine once said "the faster I can make mistakes, the fatser I can learn." With a good math program, you can make mistakes faster than ever.

And the development of the DSP code is now aligned with the math simulation tools:

formatting link

so you can not only see if your maths are working, but then download it, and see if it works in reality!

Aust> drg wrote:

Reply to
Austin Lesea

Well first off, I'd like to thank all the people who answered this. This group seems to be much helpful than comp.os.linux :D

Regarding to the maths... well yeah what I'm saying is this. It's like college physics: When you learn theory you see all those scary derivates and integrals and greek letters that don't seem to make any sense. But in practice, there are just multiplications and divisions and things like that. So what I think is that there must be some practical way that just involves a few calculations and you are set. Or at least a computer program that can help. I keep my HP 49G handy in case something gets too nasty ;).

Anyways I have yet to take calculus 2 where they teach the fourier series (which I think will help me a lot with this, right?). Right now I'm studying to take the final for computers architecture. I'm writing programs in machine language and designing adders and multipliers that work in BCD or gray code. So to "Symon"... this few years of fiddling with microcontrollers and FPGAs have helped me a lot. Sometimes it's easier (or better) to learn with practice than sitting and making exercises on a book. :)

To implement the DSP things... I found what I think it's an easier solution: Nullsoft DSP Studio... that is, the DSP that comes with Winamp. It provides you with the current sample and then you can manipulate it and return it to Winamp. It then plays it back through the speakers. Who would have thought that a music player can help you learn DSP?

As for the A/D converters, TI seems to have quite a few audio ADCs and DACs, and they have provided me some free samples in the past ;)

Again thanks everyone for answering.

Hern=E1n

Reply to
drg

Hi Hernan, So, Symon is my real name, I just had a sixties' mother! It's not "Symon"! ;-) I'm glad you learned about microcontrollers hands-on. My point is that I bet you didn't try to fiddle with microcontrollers without first learning how to use a PC. FWIW, my own experience is that you'd be better off learning the maths first before you design DSP algorithms. Austin makes a great point in that there are many tools nowadays that let you play with the mathematics which could give you a good start! Anyway, good luck whatever you choose! Cheers, Syms. p.s. As for newsgroups, folks are quite friendly on comp.dsp too.

Reply to
Symon

GNU Octave is free.

formatting link

Some of us learn more/better when we make our mistakes in the low level details. Maybe only the first few mistakes while getting off the ground.

--
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.
Reply to
Hal Murray

but it's very difficult to get off the ground in a dark, remote place where you don't know anyone and don't speak their language :P

Reply to
drg

Can you speak English? ;-)

formatting link
formatting link

Both articles give you a basic start. The links at the bottom of these pages send you to a load of free online stuff to help you learn more. Links like this one:-

formatting link

Hopefully you can use this online stuff along with your Spartan kit to learn pretty efficiently. When you get stuck, I'm sure folks on CAF and comp.dsp will be more than glad to offer you further pointers. People seem to be more helpful if you've put in some work yourself; they tend to be wary of 'homework' posts!

HTH and good luck, Syms.

p.s. Just to make sure, you know about

formatting link
, right?

Reply to
Symon

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.