Design Article
Comment
Andreas Mauderer
mdos
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
Abstract
Simulink models are used as executable specifications in commonly used design flows for mixed-signal ASICs. Based on these specifications, analog and digital components are directly implemented in mixed-signal design environments. This step constitutes a large leap of abstraction. In this work, we address this aspect by showing and discussing an approach for automated transitions from Simulink models representing analog and digital components to HDL descriptions using HDL Coder. On the one hand, we translate analog Simulink components into continuous-value discrete-time HDL descriptions that can serve as reference behavioral models in the mixed-signal design environment. On the other hand, for digital Simulink components, we developed optimizations for Simulink models in order to achieve resource-efficient HDL descriptions. Both solutions in the analog and digital domain were integrated into Simulink Model Advisor. An evaluation of the presented design flow, as applied to an automotive hardware design, is shown.
Introduction
Electronic Control Units (ECUs) in the field of automotive electronics generally interact with the physical environment by using sensors and actuators. Thereby, mixed-signal ASICs (Application Specific Integrated Circuits) are needed as an interface between microcontrollers and sensors as well as actuators. In this work, we focus on ASICs connected to sensors, whereby the sensor is often enclosed with the ASIC into a system-in-package (SiP). In the most general case, mixed-signal ASICs consist of analog, non-programmable digital and programmable digital components.
The increasing integration density of ASICs allows more and more functionality, which leads to more complex ASIC designs. These require a holistic view on a high abstraction level at the beginning of the design. Therefore, a system-level (SL) design methodology is needed, where all ASIC components and the associated sensor are modeled in a common SL design environment. In standard flows, the design starts by developing an SL model that serves as executable functional specification. Based on this specification, the particular ASIC components are designed on implementation level (IL) isolated from the overall system and without any reuse of the design effort performed at SL. The isolation between SL and IL constitutes a gap in the design flow, which leads to redundant implementation efforts and consistency problems between SL and IL. Furthermore, the isolation of components from the overall system during implementation leads to lost optimization potential. That is why in (1), we proposed a seamless SL design methodology, which uses automated transitions from SL to IL models in order to reduce the effort of design transfer between SL and IL (see Figure 1).

System-level design environment: Simulink
For heterogeneous systems, SL design environments have to support the description of system components from different domains. We use MATLAB/Simulink (see (4)) as SL design environment, which constitutes a de facto standard for signal processing design in automotive applications.
Simulink is a graphical multi-domain design environment and supports multiple models of computation like continuous-time, discrete-time and electrical modeling. Thereby, Simulink models can include blocks from the Simulink library as well as blocks described in different languages like MATLAB, Stateflow and Simscape, and programming languages like C and C++. Simulink library blocks allow the description of analog circuits both as continuous-time and discrete-time signal-flow models. Simscape offers the possibility to model systems as physical networks. It can be used for the modeling and simulation of electrical systems whereby these systems obey Kirchhoff's laws. With Simscape, Simulink is also suited for the description of analog components and sensors as electrical and mechanical systems.
Simulink models are used as executable specifications in commonly used design flows for mixed-signal ASICs. Based on these specifications, analog and digital components are directly implemented in mixed-signal design environments. This step constitutes a large leap of abstraction. In this work, we address this aspect by showing and discussing an approach for automated transitions from Simulink models representing analog and digital components to HDL descriptions using HDL Coder. On the one hand, we translate analog Simulink components into continuous-value discrete-time HDL descriptions that can serve as reference behavioral models in the mixed-signal design environment. On the other hand, for digital Simulink components, we developed optimizations for Simulink models in order to achieve resource-efficient HDL descriptions. Both solutions in the analog and digital domain were integrated into Simulink Model Advisor. An evaluation of the presented design flow, as applied to an automotive hardware design, is shown.
Introduction
Electronic Control Units (ECUs) in the field of automotive electronics generally interact with the physical environment by using sensors and actuators. Thereby, mixed-signal ASICs (Application Specific Integrated Circuits) are needed as an interface between microcontrollers and sensors as well as actuators. In this work, we focus on ASICs connected to sensors, whereby the sensor is often enclosed with the ASIC into a system-in-package (SiP). In the most general case, mixed-signal ASICs consist of analog, non-programmable digital and programmable digital components.
The increasing integration density of ASICs allows more and more functionality, which leads to more complex ASIC designs. These require a holistic view on a high abstraction level at the beginning of the design. Therefore, a system-level (SL) design methodology is needed, where all ASIC components and the associated sensor are modeled in a common SL design environment. In standard flows, the design starts by developing an SL model that serves as executable functional specification. Based on this specification, the particular ASIC components are designed on implementation level (IL) isolated from the overall system and without any reuse of the design effort performed at SL. The isolation between SL and IL constitutes a gap in the design flow, which leads to redundant implementation efforts and consistency problems between SL and IL. Furthermore, the isolation of components from the overall system during implementation leads to lost optimization potential. That is why in (1), we proposed a seamless SL design methodology, which uses automated transitions from SL to IL models in order to reduce the effort of design transfer between SL and IL (see Figure 1).

Figure 1: SL design methodology using automated transitions
Assisted refinement of SL model components with respect to the surrounding system and automated top-down transitions from SL to IL are suggested in order to transfer design effort from SL to IL. SL and IL are defined as follows: At SL, the whole ASIC and its connected sensor is considered in a common design environment, whereby the ASIC SL model consists of analog, digital and software partitions. Then again, there are IL models, which describe a system component of a single domain in its domain-specific language and design environment. IL models are later refined down to a physical implementation either in a manual or an automated design flow that depends on the particular domain. After we provided approaches for top-down transitions from MATLAB/Simulink both in the digital and the analog domain (see (2) and (3)), in this article, we present the combination of both approaches and their application to an automotive mixed-signal hardware design.System-level design environment: Simulink
For heterogeneous systems, SL design environments have to support the description of system components from different domains. We use MATLAB/Simulink (see (4)) as SL design environment, which constitutes a de facto standard for signal processing design in automotive applications.
Simulink is a graphical multi-domain design environment and supports multiple models of computation like continuous-time, discrete-time and electrical modeling. Thereby, Simulink models can include blocks from the Simulink library as well as blocks described in different languages like MATLAB, Stateflow and Simscape, and programming languages like C and C++. Simulink library blocks allow the description of analog circuits both as continuous-time and discrete-time signal-flow models. Simscape offers the possibility to model systems as physical networks. It can be used for the modeling and simulation of electrical systems whereby these systems obey Kirchhoff's laws. With Simscape, Simulink is also suited for the description of analog components and sensors as electrical and mechanical systems.
Navigate to related information


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