Graphical programming for DSPs

Graphical programming paradigms have continually evolved to address these problem. In this paper, we will present how graphical programming can be used to target DSPs, giving users the option to completely design, prototype and deploy their system from a graphical environment.

Graphical Programming
Graphical programming languages use block diagrams to represent systems. The blocks typically represent computations and the arrows connecting the blocks represent flow of data. Graphical programming is based on the "dataflow" paradigm, which in mathematical terms is a directed graph with nodes that represent computations and arcs connecting the nodes that represent the flow of data. Nodes may incorporate subsystems that also consist of a series of nodes and arcs. Alternatively, the subsystems may contain algorithms implemented in a primitive language such as assembly or C.

Graphical programming languages lend themselves naturally to embedded and DSP programming. This has resulted in much research and development of graphical programming languages and tools. There are a number of tools that allow a mixture of visual and textual programming, such as Signal[1], Lustre[2] and Silage[3]. There are also completely graphical programming environments such as Ptolemy[4] from University of California, Berkeley and National Instruments LabVIEW.

One of the key strengths of graphical programming languages is that users can port the same design to multiple targets with little to no code changes. LabVIEW[5] from National Instruments has the ability to target many hardware platforms, including desktop systems, handheld computers, real-time systems, FPGA-based boards, 32-bit MPUs and DSPs. But the real power of graphical programming lies in the fact that the designer always stays at the higher level of abstraction (graphical interface) and does not need to interface with the low-level code that is generated for the target.

Empowering Domain Experts
This section gives a brief overview of how graphical programming can help domain experts. To learn more about this topic, see the article Graphical tools for rapid design, prototyping, and deployment.

DSPs are now being considered and used in many applications. The designers of these applications are not necessarily experts at programming DSPs. For such designers, conventional DSP programming methods present a steep learning curve, making it difficult to use DSPs. Graphical programming languages alleviate this problem by providing a simple, easy-to-use interface. This interface can be used to quickly design, prototype and deploy DSP systems without DSP expertise. Figure 1 compares the steps that are required when using conventional and graphical programming techniques for DSPs.

Figure 1. Comparison between conventional and graphical programming methods for programing DSPs.

As figure 1 illustrates, using conventional techniques, the domain expert has to also be a DSP algorithms and design expert or depend on teams of people who are. Graphical programming languages abstract these steps, allowing the domain expert to focus on the application design rather than implementation details. This leads to faster development and time-to-market. (More information about this topic can be found in the article mentioned above.) Let us now focus on some of the key advantages that graphical programming environments bring to the domain expert programming DSPs.

Simple Drag-and-Drop Interface
DSP programming has traditionally involved thousands of lines of textual code. This has made designing, testing and debugging the system a confusing and difficult process. In contrast, graphical programming languages provide a dataflow paradigm with a drag-and-drop interface. This reduces the learning curve drastically and makes the design process far more intuitive.

Figure 2 shows an example graphical program from LabVIEW. Two things are apparent when you look at Figure 2. First, the user interface and functionality of the application are clearly separated. This gives the user greater control over the design of the algorithm itself. Second, textual code is not required, although existing C code can be plugged in if desired. (This is explained in a following section.)

(Click to enlarge)
Figure 2. An Example Graphical Program.