DSP frameworks

Jon Jacky, August 2004

Comparison Table


We are evaluating signal processing and control frameworks for our project to build an MRFM molecular imager.

Different MRFM subsystems work a very different speeds, so different technologies might be appropriate for each. Vacuum and cryo are quite slow (a few Hz). Scanning (piezo control and interferometric sensing) go up to audio frequencies. Cantilever sensing and control (interferometry and RF coil) go up to radio frequencies.

It appears that none of the existing frameworks is designed for closed loop control at radio frequencies.

Back to top.


A DSP framework provides a way to program networks by connecting independently programmed signal processing blocks. Many variations and additional features are possible.

MRFM requires a framework with these features:

Real time
Networks must be executed with deterministic timing. The performance metrics for real-time DSP are sampling frequency and jitter (variation in sampling interval). Real time sometimes uses two platforms (hardware and software): one for execution and another for cross-development. A self-hosted system uses the same platform for both.
Short latency
Latency (end-to-end delay through signal path from input to output) cannot be inferred from sampling frequency. Minimum latency is imposed by fixed elements in the signal path, especially hardware FIFOs. Short latency is vital for closed-loop control. The performance metric is the latency itself. MRFM demands latency <~ 50 usec. None of the existing frameworks is designed for closed loop control at radio frequencies. Most depend on large FIFOs to achieve high sampling rates with low jitter.
For real time systems which are not self-hosted, it is very useful to be able to develop most of the software on a general-purpose computer, without access to the (expensive, exotic) real time platform. The simulator may execute the same code as the real time platform (but not in real time), or the simulator may use a different language that is compiled (translated) for the real time platform.
DSP library
Any DSP framework provides a programming language (and coding standards) for coding new blocks, and a library of predefined blocks.
A simple embedded signal processing network only has analog input(s) and output(s). Richer frameworks also provide ways for users and client programs to interact with the running network (to adjust parameters or collect data). These additional functions may run on the same platform as the signal processing network, or on a separate remote host. They must use some protocol to communicate with the signal processing networks. Simple remote protocols handle one data channel per TCP/IP socket with ad-hoc encoding of data types; more elaborate protocols (such as EPICS CA or Labview dstp) handle naming and addressing for many data channels on a single socket and built-in encoding for many data types.
GUI library
A framework that provides a GUI must also provide a programming language (and coding standards) for coding new widgets, and a library of predefined widgets.
There may be a separate scripting language for defining networks, which is different from the programming language for the signal processing blocks and GUI widgets. Some frameworks provide a graphical scripting language (so programmers can draw the networks).
An interactive system allows (some) scripting language statements to be entered and executed without shutting down and restarting the system. This makes it convenient to experiment with network designs.
Supervisory control
Supervisory control provides ways to reconfigure the networks in a running system under program control (more drastically than merely changing parameters such as gains or filter taps). For example, a program might switch between several different networks for the same signal path to adapt to changing conditions, activate different networks in different operating modes, or deactivate networks to conserve computing resources.
Documentation is available so programmers and users needn't infer coding standards and design from code.
Open source
Source code and documentation is available for inspection, copying, modification, and redistribution under some reasonable license.

Back to top.

Here are some open source or academic systems.

GNU Radio
GNU project; appears to be active and growing rapidly. Resourceful use of available hardware: uses cable modem tuner with PCI ADC, built-in PC audio, video; has recently designed and fabricated RF ADC/DDC/DUC/DAC board with FPGA that connects to USB port. Development is self-hosted on the same platform. Nice separation between signal processing engine (in C++) and scripts that define networks (in Python). Signal processing and GUI (Python again) run on same platform, communicating through shared memory. The GNU Radio code was initially based on the PSpectra code from MIT but has evolved considerably. Most GNU Radio developers use Linux but it has also been ported to other platforms, including Mac OS X, BSD, and even Windows.
From the SpectrumWare software radio project at MIT in the late 90's. Appears inactive, code apparently no longer available, but lives on in GNU Radio (there is a gnuradio-0.9/src/pspectra directory in early GNU Radio distributions). There is also a company devoted to commercializing this work. SpectrumWare ran on a PC running Linux, with an external analog mixer and a custom PCI I/O card called GuPPI. The JSAC98 paper is on hardware and operating system requirements for doing signal processing on general purpose computers, on an innovative software downconversion method, and on the internals of PSpectra (Called SPECTRA in that paper).
Academic project at MIT in the mid-90's; appears inactive but code is still available. Influenced PSpectra, the basis for GNU radio. VuSystem is not really a DSP framework, but a multimedia framework for video and audio with relaxed real-time requirements. Instructive nevertheless; nice separation between "in-band" signal processing path (in C++) and "out-of-band" control and GUI programming (in Tcl/Xt). JSAC96 paper thoroughly documents motivation and design.
Used by LIGO, many big accelerator labs. Uses VxWorks realtime platform connected to remote GUI through TCP/IP. Designed for very large distributed systems. Supports its own channel access (CA) protocol that runs on top TCP/IP, for communicating many I/O channels among many real time platforms and GUI hosts. Started at LANL, has large international user/developer community. Big and complex, very steep learning curve, a career path in itself. This community has vast experience using VxWorks and VME at the limits of their capabilities. EPICS is not really a DSP framework; they use EPICS to connect custom-programmed DSPs to remote GUI etc.
Academic project at Berkeley, long running under several names since early 80s. Several commercialized versions, most recently from Agilent. Ptolemy is apparently only a simulator, not a real-time system, but it is apparently programmed using techniques adaptable to real time: next-state simulation and synchronous data flow. Therefore the code and (voluminous) documentation (including many academic papers) may be worthy of study.

Here are some commercial systems.

LabView/RealTime Module
Commercial product from National Instruments (NI). Nicely integrated system with NI hardware/software throughout. Labview virtual instruments (VIs) running on GUI host (PC or Mac) communicate over TCP/IP with NI's real time computer and I/O cards in NI PXI crate. NI supports a data socket transfer protocol (dstp) on top of TCP/IP for building distributed systems; it seems to play a similar role as CA in EPICS. Very attractive if NI products provide acceptable performance, or if it is easy to integrate higher performance non-NI components and custom software.
http://zone.ni.com/devzone/conceptd.nsf/webmain/9149C3CA1B23B6C3862569920055F425?opendocument http://zone.ni.com/devzone/conceptd.nsf/webmain/9574A2833AB0F8B086256CB4006A1EF7?opendocument
Matlab/Simulink/Stateflow/Realtime Workshop
Commercial products from Mathworks. Generates C code from Simulink models.
Commercial product from RTI. Uses Matlab/Simulink as input language.
Commercial product from dSPACE (German, with American subsidiary). Uses Matlab/Simulink/Stateflow as input language.

Back to top.

Other resources

Paper on BLOSIM, apparently an early ancestory of Ptolemy, on the internals of a DSP framework.

Papers from a company formed to commercialize the MIT SpectrumWare work on software radio.

Back to top.

Comparison table

DIY means Do It Yourself, must be programmed by the user without support from the framework.

Feature\Framework GNU Radio PSpectra VuSystem
(also here)
EPICS Ptolemy
(also here)
Application Software radio Software radio Multimedia
Accelerator control
(large distributed control systems)
Electronics CAD Laboratory data acquistion control systems
Real time OS Linux
(not RT-Linux etc.)
also Mac OS X, others
Linux Unix
(not really real time)
RTEMS (open source)
N/A Labview Real-Time
Real time hardware PC with cable modem tuner and PCI ADC or
PC with external tuner and custom PCI I/O card Workstation with audio/video
Sun 10/512
DEC 3000/400
VME (many boards)
PC (not usually)
NI PXI crate
Real time
development platform
Linux etc. (self-hosted) Linux (self-hosted) Unix (self-hosted) Tornado/Sun
DIY script/Linux
(can self-host on PC)
N/A Labview on Windows, Mac, (Unix/Linux?)
Real time sampling frequency 64 MS/s, 12-bit AD
N/A N/A ?
Short latency Probably not on this hardware Probably not No Yes (on some hardware) N/A ?
Real time latency 48 msec in one experiment
(probably could do much better)
N/A ?
Simulator N/A (self-hosted) N/A (self-hosted) N/A (self-hosted) (can self-host on PC) That's all it is (maybe with stubs to simulate PXI side)
DSP language C++ C++ C++ C, C++ C++ Labview (also C in CINs?) Matlab
DSP library signal sources 29
signal sinks 6
FIR filters 6 (data types)
FIR filters w/freq shift 6
type conversion 1
yes > 50 blocks DIY
(not EPICS emphasis)
GUI host Linux etc. Linux Unix Windows
Unix, Linux
(no Mac sightings)
(same as DSP) Windows, Mac, (Unix/Linux?)
GUI protocol (in memory) (in memory) (in memory) CA on TCP/IP (in memory) dstp on TCP/IP
GUI language Python (also here) ? Tcl/Xt Custom GUI tools Tcl/Tk Labview
GUI library About 30 Python files
(see screenshots)
? > 50 scripts Huge (for their tools) Huge
Scripting language Python ? Tcl Several custom languages
(some graphical)
VxWorks Windshell
(not usually)
Interactive Looks possible ? Yes (not usually) (can you add/revise VIs without reboot PXI side?)
Supervisory control DIY looks possible ? Yes DIY (using their tools) DIY
Documentation Linux Journal articles
Web pages generated
from code by doxygen
PSpectra literature
Academic papers, especially JSAC98 Academic papers, especially JSAC96 Lots, but mostly opaque
Training through APS
Academic papers
Agilent documentation
Open source Yes Yes
(but unavailable)
Yes Yes ? No No
Status Active Inactive
(lives on in GNU Radio)
(influenced PSpectra)
Active ? Active
(commercial product)
(commercial product)

Back to top.