2
\$\begingroup\$

I want to learn to make DSP hardware

I have never done any DSP and only a little bit of programming, but I have been making analog circuits for 15 years. I like the idea of learning FPGAs because it sounds more like building circuits, but people often say FPGAs are really difficult. Maybe these people are used to sequential programming. I am wondering if FPGAs are more easy to learn than microprocessors if doing the things that FPGAs are good at. For example if I want to make an FIR filter, will an FPGA will be more intuitive?

\$\endgroup\$
  • 16
    \$\begingroup\$ No​​​​​​​​​​​​​​​​​​​​​​​ \$\endgroup\$ – PlasmaHH Feb 4 '16 at 14:51
  • 1
    \$\begingroup\$ Many FPGAs include DSP resources and the vendors software includes core generators that will write the DSP specific code for you, such as a FIR filter, that you can configure in a wizard. That said, the FPGA can be a very complicated thing to figure out on first crack, more than just HDL code. But, you have the ultimate flexibility with an FPGA. \$\endgroup\$ – johnnymopo Feb 4 '16 at 14:54
  • \$\begingroup\$ you may find it useful to study DSP on Matlab or similar environment before going embedded. \$\endgroup\$ – Aenid Feb 4 '16 at 15:23
  • \$\begingroup\$ I imagine leaning on Matlab will be useful to learn general concepts of DSP, but it will not teach me about the physical context of the DSP implemented on particular hardware. It is that physical context with fewer levels of abstraction that seems so appealing about FPGAs. Maybe I should also start buy leaning simple blinking LED type tutorials on YouTube. I am learning the maths stuff also, such as Fourier transforms, convolution, Laplace, that sort of stuff. \$\endgroup\$ – John Spence Feb 4 '16 at 15:37
  • \$\begingroup\$ To be honest, blinking LED tutorials will teach you nothing about FPGAs. Rather you would need to start researching/learning how digital logic circuits behave, and trying to represent different circuits purely in logic (counters, registers, gates, etc). \$\endgroup\$ – Tom Carpenter Feb 4 '16 at 17:15
3
\$\begingroup\$

Take a tip from which way the professional industry is moving. Some organisations program the DSP parts of their FPGAs by writing a MATLAB or C program, then use a synthesis tool to compile it to VHDL. Much the same as most people stopped writing machine code or assembler, when compilers became accepted as the way to do it.

However, these tools are usually very expensive, and hinting at them how to parallelise the design is a huge learning curve, so they're not applicable to hobbyists at the moment. Not many companies use them for production either, because there are still plenty of DSP engineers that grumble 'they can do it better on the hardware than a compiler', just like assembler programmers used to grumble 30 years ago.

Even if you do actually want to target hardware eventually, always start with an easy to use tool like MATLAB (costs), Octave (free) or Python+numpy+matplotlib (free), so you can see what's happening, and generate some test vectors to prove out your hardware.

You will be able to do audio DSP quite happily in reasonably available DSP microprocessors. However, doing radio frequency work will need FPGA.

\$\endgroup\$
  • \$\begingroup\$ Neil, you seem to be suggesting that a hardware description language is a low level way of working, but I thought that there were ways to do HDL using graphical techniques that are more like a schematic drawing. Which would be a high level way of working that better describes an FPGA than C programming. Sorry I have not done too much research. \$\endgroup\$ – John Spence Feb 4 '16 at 16:06
  • 3
    \$\begingroup\$ @NickCollier schematic level entry for FPGA designs is next to useless. You would end up spending more time trying to connect things up with half-baked tools than to just write it in HDL. In terms of describing what goes on in an FPGA, HDL languages are far superior, and in some ways could be considered higher level than the schematic entry. You can't really use C to describe FPGAs, they are completely different beasts, but DSP stuff tends to be fairly procedural, so you can to some extents describe it in C and port that to an FPGA (but the tools to do so are underdeveloped). \$\endgroup\$ – Tom Carpenter Feb 4 '16 at 17:10
  • \$\begingroup\$ Furthermore to add, HDL were created specifically because people were tired of having to lay out and design ICs graphically, which was the only way to do it for many years. HDLs are indeed a step up. \$\endgroup\$ – whatsisname Feb 4 '16 at 17:16
  • \$\begingroup\$ What Tom said. Graphical entry methods tend to be tied to one tool, and often effectively one version. Pure text VHDL will work with any vendor, tool, simulator, any time, any place, any where. You can use C to describe the compute intensive parts of the design, compile those to parallel hardware, then 'wire' the system together with VHDL. MATLAB does has a graphical tool called Simulink that 'eases' DSP block entry, that can be used as the source of compiled VHDL, but that's mucho denarios. \$\endgroup\$ – Neil_UK Feb 4 '16 at 17:18
2
\$\begingroup\$

Whether you use a microcontroller with DSP functionality, a DSP chip or an FPGA is (at least theoretically) not as important as what algorithms and filter coefficients that you use. So once you make the leap to digital processing, it becomes a matter of whether you need the performance that only an FPGA can give you or not. Even within an FPGA design you have various trade-offs, for example, we're doing a CORDIC calculation and to save resources we serialize the calculations so that fewer multipliers are required. You can make small changes such as unrolling loops with microcontrollers, but basically you're stuck with the processor(s) on the chip and that's that.

I don't think it's at all easier to use FPGAs.. the parts are generally in needy packages (BGA typically), they need a lot of power and different power supplies, the flexibility leads to more variation in performance (due to layout, for example) and power consumption is also more variable. Keep in mind that you will typically need other functionality to get signals in and out and for supervisory tasks. Chips like the Zynq combine a small 32-bit microcontroller ARM core with an FPGA and should be the best of both worlds, but we've found the learning curve to be fairly arduous, even with expensive tools such as added cost MATLAB packages. Many complaints exist about the vanilla FPGA tools, if you look at the forums and they tend to be expensive if you need all the capability.

Right now, I think the combination of a processor and FPGA is a good solution for many signal processing tasks, whether integrated or not (there is also the possibility of 'soft' processors on the FPGA, but they tend to be a bit underwhelming in performance and use a lot of resources).

\$\endgroup\$
0
\$\begingroup\$

FPGAs are more expensive, more complex, have less user-friendly software tools and are harder to debug.

I would say that the easiest way to get started in DSP is in PC software, starting with higher-level tools like Matlab, intermediate difficulty languages like Python (with numpy this is quite fast enough for mere audio), down to C.

Once you have an algorithm working in C it can be ported to a microcontroller or dedicated DSP.

\$\endgroup\$
0
\$\begingroup\$

Like many have pointed out that FPGA can be tough for learning the DSP algorithms themselves. I think one of the main reasons you would use an FPGA is to reduce the processing time. But implementing an algorithm on the FPGA does require you to learn an HDL. Even if you use pre built IPs you still need to connect and perform inter IP communication if necessary. A DSP based micro controller would be much easier to deal with.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.