How to use M and Simulink for DSP control and datapath design

Over the last decade, digital signal processing (DSP) has become a significant part of semiconductor applications; today, DSP is a key factor in the progress of wireless communications and digital multimedia products. The algorithms central to these applications continue to become more sophisticated and complex in order to achieve the higher performance and capacity demanded by end-user markets. This results in challenges for IC design teams to deliver increasingly complex IP with faster design cycles.

The EDA (electronic design automation) industry typically addresses this type of productivity challenge with higher levels of abstraction coupled with more automatic paths to implementation. One of many examples was the shift in the early 1990s from schematic capture to the high-abstraction/high-productivity approach of logic synthesis. The move to formal property checking through property specification languages for higher productivity and more comprehensive IC verification is another. While the need is there today, there is not an equivalent approach for DSP designs that raises the abstraction level together with an automated implementation path.

This paper discusses the tradeoffs of abstraction versus implementability and highlights an approach of embedding M into Simulink to gain some of the advantages of both. By supporting a broad subset of M operators and built-in functions and adhering to some simple programming guidelines, significant efficiencies can be gained in design capture and debugging for certain types of applications.

Challenges facing DSP language-based flows
To start, it's important to note that we are considering automated implementation paths and not just description and modeling efficiency. To provide abstraction layer benefits, a flow must provide efficient high-level modeling and an automated implementation path.

The C and Matlab (M) languages have become popular for modeling DSP algorithms because of the more concise expression of behavior. However, these lack an effective automated path to implementation.

In order to become implementable, the tradeoff for description languages like C or M is to become less concise. For example, Simulink from The Mathworks addresses key issues for discrete-time implementation that have had some success for IC implementation, but many designers would prefer to describe behavior in strictly C or M.

The general problem with automatic implementation from M – and from many languages in general – is that necessary parameters are left out of the description and can't be unambiguously determined from the model. Most notable is the lack of fixed-point typing, sample rate timing, and parallelism. These are very important aspects of algorithm implementation, and tradeoffs between them usually have significant impact on the area, speed, and algorithm performance of the implementation. Yet this is the entire point of M – to provide a high level of abstraction for algorithm modeling.

M uses dynamic typing, floating-point calculations, and shared-memory for simulation, which often leads to model behavior that requires very expensive logic and memory, i.e. behavior that is not very implementable. This highlights the challenge of implementing M algorithms and also why it requires so much effort in hand coding RTL. Attempts to address these issues include creating new libraries of functions and signal declarations, adding language constructs, or using compiler methods to specify the interpretation. However, the further one deviates from the language, the abstraction benefits and intuitive nature of the language are lost.

Requirements for implementability
To avoid ambiguity during an automated transformation from algorithm to HDL code, there are some key requirements for the higher level description. These include well defined fixed-point and sample rate values for variables and signals, and explicit parallelism (to allow for architectural abstraction and downstream optimization).

More critically, device architecture and timing characteristics are needed to guide the automated implementation flow in order to produce a more optimal result. Today there is no single DSP description language that accomplishes our dual goal of being concise and being implementable. However, these elements do exist today across several languages and models – and, with careful planning, these elements can be used to accomplish our goals.

Crafting a flow from what exists today
Simulink provides an efficient design and simulation framework for creating high-level algorithm models coupled with limited capabilities that directly assist in implementation. More specifically, it allows for defining sample rates and fixed-point data types, a discrete-time modeling engine, and a rich set of mathematical operations and analysis tools. Furthermore, it includes methods for automatically propagating the fixed-point types and sample rates through the algorithm datapath. This saves significant time in capturing algorithm behavior, similar to the way dynamic typing in M eliminates the need to specify types in the code (one of the advantages of M over C).

However, even though Simulink provides a good simulation and modeling framework, libraries available in Simulink may fall short in implementability and also in providing a higher level of abstraction and ease of use. For example, some library components suffer from similar issues found in M models, namely simulation and memory behavior that does not implement well in silicon, or insufficient flexibility in choosing streaming-based or block-based processing. Another pitfall is forcing the user to specify too much detail in the model, such as clocks, enables, and hard coding architectural implementations for area and performance tradeoffs. This approach limits the benefits of abstraction and essentially becomes a schematic capture tool with simple RTL generation.

Another existing tool for high level DSP implementation is the Synplify DSP "true DSP" synthesis solution. The strategy taken by Synplify DSP software is to provide an implementation "synthesis" flow from algorithm models and to maintain a high level of hardware abstraction in the modeling library. This is achieved by a well defined Blockset (Simulink library) and a Synthesis Engine. A second important goal of the library, in addition to hardware abstraction, is to provide the most efficient and concise means of expressing and analyzing algorithm behavior in order to save user time and effort in capturing designs.

To summarize, there are critical requirements for implementation that Simulink/Synplify DSP satisfy that M alone does not. As suggested in Table 1, there are several examples where languages like M provide an easier way to capture and debug algorithm behavior. Table 1 also suggests that there are tradeoffs between modeling/abstraction versus implementability. This is why the "ideal" design flow would be a hybrid, where language-based entry can be used alongside Synplify DSP/Simulink in such cases as the language-based entry could be unambiguously implemented.

Table 1. Comparison of different design techniques.
(Click this image to view a larger, more detailed version)

The remainder of this paper proposes such a flow. Synplicity believes that by embedding language-based capabilities into Simulink, it is possible to gain some of the advantages of efficient expression and design capture, while still providing all the capabilities for implementation tradeoff exploration.