Signal Processing Platform: A Tool Chain for Designing High Performance Signal Processing Applications

Sandeep Neema, Ted Bapty, Jason Scott, and Brandon Eames Institute for Software Integrated Systems, Vanderbilt University sandeep@isis.vanderbilt.edu Abstract
Embedded signal processing applications require highperformance in a small form-factor and low-power, necessitating the use of heterogeneous execution platforms including modern FPGA-s with embedded processor cores. We present SPP, a tool chain that supports model-based design of such high-performance signal processing applications. The tool chain consists of a semantically rich modeling environment, a design-space exploration tool, analysis tools, a synthesis tool and a heterogeneous dataflow execution platform. These tools are connected in a tool chain through a set of model translators supporting a coherent and consistent design flow. The emphasis of this paper is on the Signal Processing Modeling Language, its syntax and semantics. comprehensive list), however these are far removed from the low-level design specifics of the vendor tools. Also, given the scale and complexity of the platform and the class of applications, it is difficult to envision a single tool capable of provisioning all the desired functionality. A more feasible and scalable solution is to have an integrated suite of tools, organized and orchestrated in a coherent and consistent design flow, with a set of translators providing refinement and design translations across the multiple tools. This paper presents one such tool chain for designing high-performance signal processing applications, that we call the Signal Processing Platform (SPP). This tool chain is being supported by ESCHER [6], a non-for-profit consortium (supported by Government and Industrial funding) that provides a quality-controlled repository for serving the needs of the embedded systems research and user communities. The center-piece of the SPP tool chain is Signal Processing Modeling Language (SPML), a DomainSpecific Modeling Language [7], instantiated in GME [8], which provides high-level integrated modeling of hardware and software components, along with the design choices, enabling representation of system-wide design spaces. A Design Space Exploration tool (DESERT) [9] provides the ability to explore, navigate, and prune large design spaces with user-specified constraints on system properties (ex. time, power, area, size, etc.), retaining only those design configurations that are valid with respect to the constraints. The configurations in the pruned design space can be further subjected to a variety of fine-grained detailed analyses such as detailed timing, schedulability, and power by translating the design configurations into input specifications for appropriate simulation and analysis tools. Validated design configurations are then transformed into build specifications for the platform build system that performs the low-level code artifact generation, synthesizing glue and configuration code, communication interface code, and, where appropriate, structural VHDL code for hardware components. These low-level artifacts are compiled, linked, and deployed onto the target platform. Figure 1 shows the integrated SPP tool-chain. The rest of this paper is organized as follows. Section 2 provides a description of the SPML, its design rationale, and its syntax and semantics. Section 3 briefly describes the translators and tools included in the SPP tool-chain. Section

1. Introduction
Many embedded signal processing systems demand extreme high performance while putting a premium on the form factor and power consumption. Field Programmable Gate Arrays (FPGA), containing one or more embedded processor cores (hard or soft cores) within the FPGA fabric are quickly becoming a mainstream architecture for such systems. A slower clock (~300 MHz), as compared to commodity processors (~1 GHz) allows for lower power consumption, while a large programmable hardware fabric allows high-performance by exploiting the high degree of parallelism inherent in hardware to implement compute intensive signal processing operations such as FFT, Filters, and Correlation, among others. The embedded processor core on the chip facilitates the implementation of efficient control loops that are otherwise not amenable to programmable hardware-based implementations. The heterogeneity inherent in such solutions poses immense design challenges. Complexity arises most notably due to the design choices that are made available to the designer in terms of the distribution of functionality over the hardware-software boundary. While vendors offer tools to assist development, the tools typically only support low-level design, with little or limited support for highlevel design and design-space exploration. On the other hand there are high-level design tools modeling tools such as Ptolemy [1], Simulink/Stateflow [2], analysis tools such as Giotto [3], AIRES [4], UPPAL [5] (not a

0-7803-8865-8/05/$20.00 2005 IEEE.

302

4 provides concluding remarks and suggestions for future work.

SPML/GME System Design Space

S2D

DESERT
Design space exploration

MATLAB
Simulink/ Stateflow Ptolemy

SPML/GME Point-Design Configuration

S2A

Functional Validation

AIRES
Schedulability

Signal Flow Signal Flow Modeling Modeling

CO-Active
Execution Platform

Analysis Tools Analysis Tools

Libraries

VHDL

CONF

Comm Interf

Target Target HW HW

The main aspects of a signal processing system design include: components, which implement a signal processing function (filter, FFT, correlation, ), application algorithm, which is defined as a signal flow between components, hardware platform, which is a heterogeneous network of General Purpose Processors (GPP), Digital Signal Processors (DSP), and FPGA-s allocation and partitioning of application functionality over the hardware platform. SPML includes language constructs to specify these elements. Additionally, SPML also includes value-added constructs such as replicators, component-cores, datatyping which aids the productivity of a signal processing engineer and minimizes design iteration by introducing and enforcing a rich suite of semantic correctness rules. We briefly discuss the modeling aspects of SPML below.

Figure 1: Signal Processing Platform Tool Chain

2. Signal Processing Modeling Language

SPML is a DSML, developed using the principles of Model-Integrated Computing (MIC) [7]. Formally, a DSML is a five-tuple of concrete syntax (C), abstract syntax (A), semantic domain (S) and semantic and syntactic mappings ( M s , and M c ):
L = C , A, S , M s , M c

The C concrete syntax defines the specific notation used to express models, which may be graphical, textual or mixed. The A abstract syntax defines the concepts, relationships, and integrity constraints available in the language. Thus, the abstract syntax determines all the (syntactically) correct sentences (in our case: models) that can be built. (It is important to note that the abstract syntax includes semantic elements as well. The integrity constraints, which define well-formedness rules for the models, are frequently called static semantics.) The S semantic domain is usually defined by means of some mathematical formalism in terms of which the meaning of the models is explained. The M c : A C mapping assigns syntactic constructs (graphical, textual or both) to the elements of the abstract syntax. The M s : A S semantic mapping relates syntactic concepts to those of the semantic domain. The definition of the (DSM) language proceeds by constructing metamodels of the language (to cover A and C), and by constructing a metamodel for the semantics (to cover M c and M s ). In this section we will primarily focus on the abstract syntax of the SPML and describe it with metamodels.

D2S S2C

Figure 2: Application Dataflow Metamodel

2.1 Application Dataflow

Dataflow is a well-defined and well-accepted formalism for specifying signal processing applications. Briefly, a dataflow graph consists of a set of nodes performing computations, connected by directed links, representing the flow of data [11]. Figure 2 shows the metamodel1 of the dataflow modeling in SPML. Component and Container are abstract base classes that help capture common characteristics of the three main concrete dataflow classes: Primitive, Alternative, and The metamodels are specified as stereotyped UML class diagrams, where the stereotypes provide binding to concrete syntactic element provided by the underlying modeling framework (see [8] for details).
1

303

Compound. Compounds are the composite dataflow nodes; they contain dataflow sub-graphs. Alternatives are choice dataflow nodes; they have a rigorously defined interface (ports), and contain two or more alternate implementation of a defined functionality (see [9] on the use of alternatives to structure design spaces). Primitives are the leaf nodes in the hierarchy. Ports capture the input and output interfaces of components. Compounds contain Dataflow connections that are associations between ports representing the flow of data. Notice that connecting an output port of a Primitive to an output port of another Primitive does not make sense, yet the metamodel allows it. Furthermore, notice that it is not the case that the only kind of dataflow connection needed is one connecting output ports to input ports. All input ports of Compounds need to be connected to an input port of a contained component, for example. Therefore, it is more elegant to specify a generic Port to Port connection in the metamodel. The metamodel includes Object Constraint Language (OCL) [10] constraints, encoding well-formedness rules that restrict the possible connections to a set of meaningful combinations.

of the previously created types, which could also be made available as a pre-existing library of components, to define the dataflow for the entire system. Hierarchical description with alternatives is facilitated in this folder with the use of SCompound, and SAlternative. OCL constraints have been included in the metamodel that will prevent a user from inserting a Primitive or a Compound type within an SCompound or SAlternative. A commonly recurring pattern in multi-channel signal processing applications is the use of structurally repeated constructs i.e. same processing repeated over multiple signal channels. SPML facilitates this with macro replication constructs that are elaborated with plug-ins. Figure 3 and Figure 4 show the replication metamodel and a replication example, respectively. Replication is expressed by defining one copy of a construct, and associating a Replicator item with the construct. The association is expressed with the Replication connection. The Replicator has a ReplicationCount attribute that determines the number of replicas to be created. In the provided example, the dataflow involving the OBA2Eg, OBBWEst, and OBE2Ag is being replicated. Please note that the replication connection has been made to the OBBWest model, while only to the ports within OBA2Eg and OBE2Ag models. This indicates that while the entire OBBWest model must be replicated N times, only the ports within the OBA2Eg, and OBA2Eg models must be replicated. All dataflow connections associated with replicated objects are automatically replicated.

Figure 3: Replication Metamodel In a similar vein to the object-oriented dichotomy of types (classes) and instances (objects), the GME environment allows the creation of models as types, and their inclusion in other models as instances. In signal processing applications this becomes an extremely valuable feature since a component could be conceived of as a type that is instantiated in an application dataflow. In SPML we have systematically enabled the use of this capability, by defining a separate folder ComponentType for component types. In this folder a user can model the component types which can be Primitive, Alternative, or Compounds. A user is expected to build compound types using instances of primitive, alternative, or compound types that he/she has created earlier in the ComponentType folder. SPML provides a separate System folder for the creation of the overall system model, which specifies the application dataflow. In this folder a user is expected to use instances

Figure 4: Replication Example In order to support parameterizable dataflow components, such as an FFT routine with configurable buffer size, SPML allows the flexible specification of parameters, as well as the passing of parameter values across levels of hierarchy, as shown in the metamodel in Figure 2. The Parameter is a concrete class that captures parameters and parameter values. These can be contained in dataflow components. Value propagation across parameters

304

is modeled with the PConn connection. The Parameter class has a Value attribute that captures the value of the parameter. The parameter value may be over-ridden by associating it with another Parameter through the PConn connection.

2.2 Data Typing

Data typing and type matching is a critical concern in ensuring functional correctness of signal processing applications. A seemingly innocuous type mismatch could result in large and costly errors. In order to alleviate such commonly occurring mistakes, SPML facilitates strong data-typing. The ports of components are associated with data-types, and when the components are connected using dataflow associations, their interfaces are checked, thus ensuring that only compatible objects are connected. The data-type modeling aspect (shown in Figure 5) allows the specification of both simple and composite types. Simple types, such as Floats and Integers, specify their representation size, i.e. the number of bits used. Composite types (CompoundType) can contain simple types and other composite types. Attributes of the fields specify extra information such as array size or signed/unsigned type. All data-types supported by the C programming language can be modeled. Typing correctness is enforced during model building time, by checking the included OCL constraints. The user can press Check All in GME at any time to ensure that all connected ports have types that are compatible.

abstract base class. Both this connection and the TVDTR can be contained by dataflow Primitive components. TypeVar and DataTypeRef are concrete subclasses of TVDTR. DataTypeRef is a reference to a TypeBase model which is the base class of all data type models. It is often the case that the application components are programmed such that they can support different datatypes, with type specialization performed at build time. SPML allows the representation of type-polymorphic components with the use of explicit type variables (TypeVar), and thorugh the association of type polymorphic ports with TypeVars. The TypeVar is stereotyped as a Set, a GME container construct, which allows containment of same parented objects. The TypeVar contains as members DataTypeRefs, indicating valid concrete types that the type variable could be bound to. The BoundType attribute of the TypeVar captures the type bound to a particular instance of the component. OCL constraints have been included in the metamodel that ensure that every TypeVar has a valid bound type.

Figure 6: Dataflow and Data-type Composition In a type polymorphic component, type assignments are often constrained i.e. the data-type of the type polymorphic output port/s is determined by the data-type of the input port/s. SPML allows the capture of this dependency with the TypeRelation connection between TypeVars. The semantic implication of this connection is an equivalence relation between the associated TypeVars. More complex relations can be expressed as a set of tuples captured in the RelationExpression attribute of TypeRelation connection.

2.4 Hardware Platform and Allocation

The hardware platform modeling (Figure 7) allows the description of the target heterogeneous hardware architecture at a coarse granularity in order to allow partitioning and resource allocation in a distributed application. The main concepts include compute nodes, represented by the abstract base class Node, communication ports, represented by CommPort, and communication links, represented by Link connection. The Node class has been

Figure 5: Data-type Modeling The dataflow and the data-type modeling aspects are composed together according to the metamodel in Figure 6. Notice the TypeConn connection between PortParam (abstract base class of Port and Parameter) and the TVDTR

305

concretized into Architecture, representing a hierarchical resource network, FPGA, representing an FPGA device, CPU, representing a GPP or DSP device, AD, representing an analog to digital converter device, DA, representing a digital to analog converter device, SIM, representing a simulator, and MEM, a memory device. The rationale behind including a simulator in the platform model is to support hardware-inthe-loop simulation, where part of the application functionality is implemented in hardware and other part is implemented in a functional simulator. The SArchitecture class shown in the figure extends the type/instance dichotomy to hardware platform modeling as well. A library of compute Node types could be constructed in the HardwareType folder, and the system architecture is modeled by containing instances of these Node types in a SArchitecture model. The application dataflow needs to be mapped to the hardware. In SPML this is modeled using references; each dataflow node can contain a reference to the compute node to which it must be deployed. Figure 2 shows a NodeRef containment in dataflow Components.

supports an XML-based input for modeling a design space, and outputs the pruned design space in an XML-based output format. The details of the constraint satisfaction algorithm implemented in DESERT and the input/output interfaces of DESERT can be seen in [9]. For the purpose of SPP we have developed translators that map an SPML design space to DESERT and map the output of DESERT back into SPML. DESERT outputs the pruned design space as a collection of design configurations. A configuration selection tool allows the designer to pick a design configuration, and the original SPML model. A new SPML model containing the selected design configuration is synthesized by this translator. This selected configuration has all the design decision resolved i.e. all the alternatives are bound to a specific implementation, and all the resource decisions are suitably made. The rest of the design flow proceeds on this resolved design configuration model.

3.2 Structural Optimization Tool

A common concern when constructing signal processing applications from coarse grain components is structural redundancy and overhead. True benefit of component reuse is realized when large-grain components are reused. However, in order to make large-grain components reusable, the component developers cannot make any assumptions about the usage context and must include redundant functionality. For example, a Correlation component is composed with an FFT component, a matrix multiplier, and an IFFT component. In a usage context where a single signal is correlated with different matching filters, multiple instances of this Correlation component are used on the same source signal. In this case there is a structural redundancy and overhead from computing the FFT of the same signal multiple times. This overhead could be eliminated if one were to break apart the Correlation component, remove all the redundant FFT computations, and route the output of one of the FFT-s to the rest of multiplier components. This is precisely what we have done in the structural optimization tool. The concept is very similar to the common sub-expression elimination optimization concept in programming languages. This tool is not depicted in the tool-chain shown in Figure 1 since it is implemented as a plug-in to the SPML/GME modeling environment.

Figure 7: Hardware Platform Modeling

3. SPP Translators and Tools

The SPML language described in the prior section facilitates the design of a signal processing application by capturing the entire design space. In this section we briefly describe the tools and translators, included in the SPP tool chain, that systematically allow the refinement of the design space and the synthesis of a single design configuration that can be deployed on a heterogeneous hardware platform. Please note that some stages of the tool chain (ex: mapping to analysis tool AIRES) are still under development and as such are not elaborated upon here.

3.3 Data Type Resolution Tool

We mentioned earlier that SPML allows type polymorphic components, and also allows modeling dependencies between type variables of type polymorphic components. A signal processing application composed with such type polymorphic components must be postprocessed to resolve the type variables, binding them suitably to concrete types. Two constraints must be satisfied when performing type binding:

3.1 DESERT
DESERT is a standalone tool that performs constraintguided navigation and pruning of large design spaces expressed as hierarchically layered alternatives. DESERT

306

Ports connected through a dataflow connection must have matching types 2. Types bound to type variables must satisfy their respective Type relations, if any This could be modeled as a finite-domain constraint satisfaction problem, since each type variable can take values from a finite domain. It should be realized that this constraint satisfaction problem may have no solutions which indicates a modeling error; or multiple solutions which requires additional user input to converge to a single solution. We have implemented this concept in a data type resolution tool. This tool is not depicted in the tool-chain shown in Figure 1 since it is implemented as a plug-in to the SPML/GME modeling environment.

1.

chain, enabling a coherent design flow. The SPML language itself has several advanced modeling concepts, which represent several advancements in model-based design techniques, improving overall usability and productivity. The integrated tool chain is being prototyped and matured with a sequence of applications of small to moderate complexity.

5. References
[1] Lee E. A., "Overview of the Ptolemy Project," Technical Memorandum UCB/ERL M03/25, July 2, 2003, University of California, Berkeley, CA, 94720, USA [2] Mathworks web-site http://www.mathworks.com [3] Henzinger T. A., Horowitz B., Kirsch. C. M., Embedded control systems development with Giotto, Proceedings of the International Conference on Languages, Compilers, and Tools for Embedded Systems (LCTES), ACM Press, 2001, pp. 64-72. [4] Kodase S., Wang S., Gu Z., Shin K., "Improving scalability of task allocation and scheduling in large distributed real-time systems using shared buffers," 9th IEEE Real-Time and Embedded Technology and Application Symposium, Toronto, Ont, Canada, May 27-30, 2003. [5] Amnell T., et al., Uppaal - Now, Next, and Future, Proceedings of Modeling and Verification of Parallel Processes (MOVEP'2k), 2000 in LNCS Tutorial 2067, pages 100-125, F. Cassez, C. Jard, B. Rozoy, and M. Ryan (Eds.), 2001. [6] ESCHER - http://www.escherinstitute.org/index.asp [7] Karsai G., Sztipanovits J., Ledeczi A., Bapty T.: ModelIntegrated Development of Embedded Software, Proceedings of the IEEE, Vol. 91, Number 1, pp. 145-164, January, 2003. [8] Generic Modeling Environment: a metaprogrammable modeling environment. For details see: http://www.isis.vanderbilt.edu/projects/GME/ The downloadable package includes detailed documentation and tutorial for modeling and metamodeling in GME. [9] Neema S., Sztipanovits J., Karsai G., and Butts K., Constraint-based Design-Space Exploration and Model Synthesis, Proceedings of Embedded Software Conference (EMSOFT), 2003, in Lecture Notes in Computer Science (LNCS), Springer-Verlag 2003. [10] Jos Warmer, Anneke Kleppe: The Object Constraint Language: Precise Modeling with UML, Addison-Wesley, 1998 [11] Lee, E. A. and Messerschmidt, D. G., Static scheduling of synchronous data flow programs for digital signal processing, Transactions on Computers, C36 (1):24 --35, January 1987.

3.4 Synthesis Tool

The synthesis tool maps the SPML model to the CoActive execution platform. The CoActive execution platform is a heterogeneous dataflow execution platform. It includes a light-weight real-time non-preemptive kernel, a virtual hardware kernel, and a composable protocol stack for facilitating communication across heterogeneous devices. The virtual hardware kernel is designated virtual since it does not exist as a standalone entity in the FPGA hardware, rather as a collection of component wrappers that wrap the application components and glue them together through a set of built-in inter-component communication protocols for hardware components. Please note that by hardware component we refer to a soft or hard macro, implementing some functionality as a circuit in an FPGA. In the CoActive execution platform, communication between hardware and software components is facilitated by a set of interface components on the FPGA side, and a protocol stack on the GPP/DSP side. The CoActive execution platform is accompanied by a build tool that, given a flattened dataflow graph, a resource graph, and the resource/dataflow mapping, can synthesize all the necessary gluing and configuration artifacts for the execution platform. These artifacts include VHDL files for FPGA components, communication maps, schedule tables, and interface specifications, among others. The output of the build tool is ready to be compiled by a set of Makefiles included in the execution platform which generate the binaries for the target hardware. The Synthesis tool transforms the SPML model into an input for the CoActive platform build tool. This requires flattening the hierarchical dataflow graph, hierarchical architecture description, and the mappings.

4. Conclusions
Some of the ingredient tools that are used in this toolchain have been developed, tested, and demonstrated elsewhere. However, the SPP represents a first attempt to connect all these tools in the form of an integrated tool

307