datasheets.com EBN.com EDN.com EETimes.com Embedded.com PlanetAnalog.com TechOnline.com  
Events
UBM Tech
UBM Tech

Design Article

Comment


Andreas Mauderer

7/13/2012 5:29 AM EDT

Hi Michael,

Thank you very much for your questions.
1. HDL Coder ...

More...



mdos

6/21/2012 5:39 AM EDT

A couple of questions coming from not very clear issues in the article:
1. ...

More...

System-level design of mixed-signal ASICs using Simulink: Efficient transitions to EDA environments

Andreas Mauderer, Jan-Hendrik Oetjens - Robert Bosch GmbH, Wolfgang Rosenstiel - University of Tuebingen

5/28/2012 10:29 AM EDT

Transitions in the digital domain
The current design-flow of digital automotive ASIC parts commonly starts on register-transfer level (RTL) using VHDL or Verilog (henceforth referred to as HDL descriptions). Therefore, we define these models as IL models in the digital domain. For transitions between Simulink models and these HDL descriptions, there are two different kinds of solutions, which are depicted in Figure 2.


Figure 2: Transitions in the digital domain.

One kind of solutions are high-level synthesis (HLS) transitions (see arrow 1 in Figure 2), which refine a behavioral description of an SL model into a cycle-accurate description of an IL model by performing scheduling, allocation and binding. The other kind of solutions are mapping transitions (see arrow 2 in Figure 2), which transform an SL model that is already refined down to an RTL description into an IL model without performing any refinement. We focus on mapping transitions, because high-level synthesis transitions make it difficult to formally verify resulting HDL descriptions (see (2)).

A mapping transition from Simulink models described on RTL to HDL is realized by MathWorks HDL Coder. HDL Coder is compatible with Simulink models containing a subset of the standard Simulink blockset, Stateflow models and MATLAB Code. Additionally, HDL Coder offers the possibility to explore the trade-off between area and timing. Therefore, different implementations for Simulink blocks are provided on the one hand. On the other hand, HDL Coder can modify the SL model by applying distributed pipelining, streaming and resource sharing to subsystems.

Optimizations
We want to assist the developer in developing Simulink designs that result in efficient HDL designs. Therefore, we developed two optimization approaches. They were derived from our experience in developing Simulink SL models representing datapath-oriented applications. These optimizations showed a significant improvement of our SL design flow.

Timing optimization
Signals in digital signal processing designs are often processed at different sample rates: While for example analog signals are sampled at a very high rate for the improvement of the signal-to-noise ratio, the internal computation at lower rates reduces the computational effort in the design. Transitions between different sample rates are realized by decimation and interpolation of signals. Such systems containing multiple sample rates are called multirate systems.

Simulink is capable of modeling multirate systems. Decimation or interpolation of signals can be achieved for example by using rate transition blocks or counters and switches. While developers often model decimation and interpolation of signals correctly based on their signal processing knowledge, it might occur that sample rates of blocks are higher than the sample rates of the connected signals. Because HDL Coder translates Simulink sample rates directly into clock rates, this results in unnecessarily high clock rates in the HDL description.

For avoiding too high clock rates, we developed Timing Optimization, which checks a Simulink model for blocks whose connected signals change at a lower rate than the blocks' sample rates. When the sample rate of blocks is adjusted to the alteration rate of the connected signals, then HDL Coder runs the resulting HDL components at a corresponding lower clock rate. This results in relaxed timing constraints for logic synthesis and reduced power consumption. Furthermore, if a block such as a derivation block contains delay blocks and its sample rate can be reduced by a certain factor, then the number of delays can be decreased by the same factor. This leads to fewer registers in the HDL description. The alteration rate of signals is determined by simulation. After changing the sample rates, an automated verification is executed by simulating the model and comparing the systems outputs. This is necessary since some combinations of blocks might lead to a different behavior when their sample rate is reduced.

Figure 3 shows an example of a system of two Simulink blocks. The value R is the rate at which a signal changes, which is also depicted in the signal sequences next to the signals. S represents the sample rate of a block that results in the used clock rate in the HDL description. The decimation block reduces the incoming signal rate by a factor of 2. The processing block then receives a signal with a change rate of 5 kHz and outputs a signal with the same rate, yet this block is executed with a sample rate of 10 kHz. Therefore, the processing block's sample rate can be reduced by a factor of 2.


Figure 3: Timing Optimization

This optimization identifies characteristics of Simulink models which lead to inefficient HDL descriptions and improves these characteristics. The optimization depends on signals' sample rates occurring during simulation. Thus it is crucial that the testbench stimuli of the SL model are sufficient for covering all possible scenarios that are specified. Furthermore, this optimization enables the quick assembling of an SL model using existing Simulink subsystems and the adaption of the subsystem to the alteration rates of the incoming signals.

Word-length optimization
At the beginning of a common system-level design flow, Simulink models representing digital hardware often use floating-point signals. For a resulting efficient hardware implementation, a fixed-point representation of the design is needed, which supports the needed value ranges and precisions for every signal.

MathWorks Fixed-Point Tool – part of Simulink Fixed Point – assists the developer in the adaption of signals’ integer bits to the used value ranges. We extend this functionality by providing an optimization that reduces the fractional bits of signals. Since the modification of fractional bits of signals influences their precision, we consider the impact on the output behavior of the overall system. This also allows the identification and reduction of blocks that have little or no impact on the system's behavior. We are looking for the most efficient hardware implementation that doesn’t change the system’s behavior.

For this purpose, we use the stochastic optimization method Simulated Annealing. We explore the solution space by increasing and decreasing the integer and fractional bits of randomly chosen blocks. The resulting solution specifies word-lengths for every block while the resource consumption should be minimal and no deviation of the system's output signals is allowed.

In Figure 4 the Simulated Annealing algorithm for our specific problem is shown: We start with an initial SL model that contains signal values that lead to the desired signal processing behavior. This behavior will be used in further optimization as reference behavior. In the following, the model is rated by estimating the resulting hardware resource consumption of the digital component. After that, it will be decided if the solution will be accepted. Better solutions are always accepted, and depending on the current temperature, worse solutions are accepted with a specific probability. This prevents the algorithm from getting stuck in local optima. Furthermore, it is checked if the model violates the allowed signal deviation. If the model is not accepted, then a new model is created by modifying the fixed-point type of randomly chosen blocks. If the model is accepted, the current model is replaced. After that, depending on the number of iterations, the temperature is reduced. If no new model was accepted for a defined number of iterations, the algorithm is stopped. Otherwise, a new model is created and the loop starts again.


Figure 4: Simulated Annealing flowchart

The exploration at SL in the Simulink environment has the advantage that the impact of the digital part's change of functionality on the overall system is directly visible. As with Timing Optimization, the outcome of this optimization strongly depends on the SL testbench stimuli.





Frank Eory

5/30/2012 5:49 PM EDT

Excellent article. This is the first I have read of mixed-signal code generated by Simulink being brought into Cadence's ADE. Nice work!

Sign in to Reply



mdos

6/21/2012 5:39 AM EDT

A couple of questions coming from not very clear issues in the article:
1. How well does this methodology HLS perform to designs with complex control flow? I only show a couple of statements about data-path dominated (I suppose stream-based) designs...
2. It seems that because you are using simulated annealing to convert from floating point to fixed point, you will be getting different implementations from the same spec. every time you run the tool!
Isn't this a burden for verification groups?
3. I don't see any formal methods used in the translation flow, from simuling models down to HDL implementations. How do you guarantee the correctness of the functionality of results? Even more, how do you prove the implementation functionality matches that of the specification?

b.r.
Michael

Sign in to Reply



Andreas Mauderer

7/13/2012 5:29 AM EDT

Hi Michael,

Thank you very much for your questions.
1. HDL Coder does not perform any high-level synthesis in terms of scheduling, binding and allocation. Instead, HDL Coder performs a direct mapping between Simulink blocks and VHDL/Verilog constructs both for data-flow and control-flow dominated designs. The presented optimizations only address data-flow dominated designs.
2. For the same specification the word-length optimization will result in the same implementation as long as the same seed for the random number generator is used. Yet, you are addressing an interesting point, as small changes in the specification can result in completely different word-lengths in the implementation. The most important verification step here is the comparison between floating-point and fixed-point model. We achieve that by simulating both designs in Simulink using testbench stimuli that are representing the specified behavior of the design. After that, by considering the signal deviations, we examine if the fixed-point model still fulfills the spec. The verification between the Simulink model and the generated RTL code is also done simulation based.
3. For data-flow dominated designs, which are addressed by our optimizations, the resulting Simulink models and RTL implementations are verified as described above. Control-flow dominated implementations resulting from HDL Coder can be formally verified by property checking against properties that represent the specified behavior.

I hope I answered your questions. If any more questions occur, please feel free to post them.

Regards,

Andreas

Sign in to Reply



Please sign in to post comment

Navigate to related information

Datasheets.com Parts Search

185 million searchable parts
(please enter a part number or hit search to begin)