DSP frameworks

Jon Jacky, August 2004

Requirements
Features
Frameworks
Resources
Comparison Table

Requirements

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.

Features

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.
Simulator
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.
GUI
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.
Scripting
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).
Interactive
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
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.
http://www.gnu.org/software/gnuradio/index.html
http://www.linuxjournal.com/article.php?sid=7319
http://www.linuxjournal.com/article.php?sid=7505
PSpectra
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).
http://www.sds.lcs.mit.edu/SpectrumWare/home.html
http://www.sds.lcs.mit.edu/~vanu/JSAC98.ps
VuSystem
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.
http://tns-www.lcs.mit.edu/vs/vusystem.html
http://tns-www.lcs.mit.edu/publications/JSAC96.html
EPICS
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.
http://www.aps.anl.gov/epics/
Ptolemy
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.
http://ptolemy.berkeley.edu/
http://eesof.tm.agilent.com/products/e8823a-a.html

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://www.ni.com/realtime/
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.
http://www.mathworks.com/products/rtw/description1.html
http://www.mathworks.com/products/featured/prodcode.html
http://www.mathworks.com/products/rtw/related.html
Constellation
Commercial product from RTI. Uses Matlab/Simulink as input language.
http://www.rti.com/products/constellation/index.html
dSPACE
Commercial product from dSPACE (German, with American subsidiary). Uses Matlab/Simulink/Stateflow as input language.
http://www.dspace.de/ww/en/pub/home.htm

Back to top.

Other resources

Paper on BLOSIM, apparently an early ancestory of Ptolemy, on the internals of a DSP framework.
 http://www.eecs.berkeley.edu/~messer/PAPERS/IEEE/Jan84-1.pdf

Papers from a company formed to commercialize the MIT SpectrumWare work on software radio.
http://www.vanu.com/techpubs.html

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) 		Labview
Realtime 		Matlab
Realtime
Application Software radio Software radio Multimedia
(Video/audio)		 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)		 VxWorks
RTEMS (open source)		 N/A Labview Real-Time
Real time hardware PC with cable modem tuner and PCI ADC or
USRP board for RF ADC/DDC/DUC/DAC with FPGA 		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)		 N/A NI CPU
NI PXI crate
Real time
development platform		 Linux etc. (self-hosted) Linux (self-hosted) Unix (self-hosted) Tornado/Sun
Tornado/Windows
DIY script/Linux
RTEMS/Linux
(can self-host on PC)		 N/A Labview on Windows, Mac, (Unix/Linux?)
Real time sampling frequency 64 MS/s, 12-bit AD
on USRP		 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
Simulink
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) 		Labview
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		 NI
documentation		 Mathworks
documentation
Open source Yes Yes
(but unavailable)		 Yes Yes ? No No
Status Active Inactive
(lives on in GNU Radio)		 Inactive
(influenced PSpectra)		 Active ? Active
(commercial product)		 Active
(commercial product)

Back to top.