Beginner DSP Projects

[ho0pla]

Hey all

I've just recently got my Nexys 4 DDR Board.

I am looking for some intro DSP projects to do on my FPGA.
I took a DSP course last year but it was pretty much only theory. So I know the theory very well, but am not sure what is a good project to start out in DSP?

Any suggestions would be appreciated, thank you!

[xc6lx45]

Well, if you want my opinion, DSP on FPGA is a fairly specialized niche application. It's a long walk to come up with a project that really fits into that niche, justifying an FPGA (rather pair a $0.50 FPGA for programmable IO with one or more high-end DSPs for the number crunching if someone claims "we need an FPGA").

For studying, it can be "interesting" in a sense that you get to know quite a few dragons on a first-name basis. But then, is it productive to spend weeks on fixed point math when everybody else uses floats on a DSP / CPU when "time-to-market" is #1 priority. Maybe not. DSP is more fun in Matlab (Octave). And there is no point in FPGA for performance unless you have exhausted the options at algorithm level (again, exceptions e.g. well-defined brute-force filtering problems)

A lot of the online material is "sponsored" by companies that sell FPGA silicon by the square meter (Yessir. We have Floats!). But this is largely for the desperate and ill-informed (of course, there are viable use cases - say high volume basestations or automotive with need for EOL in a decade or two. As said, a niche application).

When you take the direct route, you'll run into a question like, "how on earth could I implement an audio mixing console when the FPGA has only 96 multipliers". Challenge me or anybody who has read some books and you'll find it can be done on a single multiplier (say, 100 MHz at 96 kHz is 86 multiplications per sample for 12 channels. It's just an example. In reality I'd use a few with "maintainability" of the code my major concern). The point is, the skill ceiling is fairly high but so is the design effort. It only makes sense if I plan to sell at least a hundred gazillon devices.

On the other hand, if you separate DSP and FPGA, you'll find that a lot of the Matlab (Octave) magic maps 1:1 to real life on any modern CPU platform by importing e.g. the "Eigen" library into my C code.

 

 

[zygot]

I'll offer a somewhat alternate view from the one that @xc6lx45has provided.

In commercial practice there is a lot of DSP work done on FPGA devices. I would agree with the sentiment that I am inferring from xc6lx45's comments above that doing DSP in FPGA is really hard. It is not for beginners as you have to understand and account for all of the minutia without high level canned code ( libraries ) that are available in say OCTAVE or C libraries. I would respectfully disagree with most of the other commentary above. DSP on and FPGA is fun once you have a certain amount of expertise. Riding a unicycle is fun for a few individuals but certainly not something that I would enjoy ( I don't enjoy bleeding and bruising...).

In my experience the typical approach to DSP in an FPGA is to test an algorithm in MATLAB or OCTAVE and all of the high level keywords that are available. Then devise a simpler easy to understand algorithm in OCTAVE just using basic math and if..then..else type statements that is good enough to accomplish the task at hand. You'll have to understand the basic math and difference between floats and fixed point ( and binary fixed point for that matter ). That simpler OCTAVE coding will be your map to implementing a DSP algorithm using the resources available in an FPGA.  If you start off with something too complicated you'll get discouraged, quit and feel bad about yourself. That doesn't mean that you can't do some interesting things.

I suggest that you start with a simple filtering ( no feedback ). Try to describe your idea in OCTAVE and then figure out how to do it in digital logic. OCTAVE can help design the coefficients. After you have working HDL simulations compare the HDL simulation results to the OCTAVE results. You don't have to do fixed point representation in OCTAVE to see if you are close to being correct.

I spent many years doing DSP assembly coding for actual DSP processors before trying to implement DSP in logic. I would strongly encourage those  interested in DSP to get some expertise in something like MATLAB, then C coding for a DSP processor using canned libraries ( look at Texas Instruments for resources ), and lastly trying to to DSP in logic. Of course, if you haven't mastered FPGA logic development this could be tough slogging. I certainly helps to have some basic and advanced experience instrumenting and debugging your logic on a working FPGA platform before trying to implement complex designs.

I've mentioned this in another thread but understanding DSP theory using a MATLAB or C libraries that hide all of the hard stuff is one level of "understanding". Being able to implement an equivalent DSP algorithm using basic math and flow control such as the if..then..else commands is quite another level of "understanding". If you have reached the proper level of "understanding" then you might well find quite a bit of enjoyment and fun in doing DSP in an FPGA.

[D@n]

@ho0pla,

You should thank @zygot for such sensible advice: build it in Matlab or Octave, get it working, then port to hardware.  Let me add another step in the middle, though, that I'm sure @zygot would agree with: Octave, then simulation, then hardware.  After that, the sky's the limit!  Well, you might want to study a particular application of interest as well.  DSP is such a varied field, and so many things from so many fields are called DSP that ... well, it's hard for me to pontificate from here.

Still, if you are interested in some examples, feel free to read some of ZipCPU's DSP articles on line.  (The ZipCPU is the name of a CPU/processor I've built, and now blog about under the name ZipCPU.)  They tend to hit on many topics surrounding DSP theory and implementation.  Indeed, I recently posted a rather cool simulation demo of a spectrogram to github.  There's a nice screenshot avaialble there too in order to give you an idea of how far you might get with simulation.

Perhaps these ideas might stir up in your mind a project you'd like to try?

Dan

[zygot]

18 hours ago, D@n said:

Octave, then simulation, then hardware

Yes Dan he certainly would agree with your advice.

Test, verify, test, verify. Let it be your mantra. Test and verify the main result that you are looking for.  Test and verify all of the component parts ( particularly in logic ) in case you want to reuse any modules or components. Test and verify corner cases. Test and verify consistency of results between all of the implementations. For the logic implementation there will be more subtle and complicated aspects to consider and test for. Assume nothing.

If all of this doesn't sound like fun ( I'm taking the long view by using that word) ... perhaps consider a different way to spend your free time.

Oh, and I forgot to mention the most important part. Don't do it for self-defense. You can learn a lot more during the test and verification stages... you know, the part where most people have gone on to other things assuming that everything works, than you can learn during the basic design processes. Testing and verification generally requires another level of awareness to issues not obvious in the original conceptual stages. That's my experience.