A Framework for the Design of Mixed-Signal Systems with Polymorphic Signals

A Framework for the Design of Mixed-Signal Systems with Polymorphic Signals Rüdiger Schroll *1) Wilhelm Heupke *1) Klaus Waldschmidt *1) Christoph Grimm *2) *1) Technische Informatik *2) Institut für Mikroelektronische Systeme University of Frankfurt a.m. Vienna University of Technology Frankfurt, Germany Vienna, Austria http://www.ti.cs.uni-frankfurt.de/ http://www.ict.tuwien.ac.at/ Abstract Embedded systems are very heterogeneous: They include software, analog/rf, digital hardware, and non-electronic components such as sensors or actuators. To handle the high complexity, an efficient and flexible simulation methodology is needed. Therefore we present a framework in SystemC-AMS that enables communication of different models of computation (MoCs) via polymorphic signals. Thereby mixed-level simulation, successive refinement and the evaluation of synthesized components are supported. Key-Words: polymorphic signals, design, systems, refinement, communication, mixed-signal, SystemC-AMS 1 Introduction 1.1 Overview Nearly all embedded designs involve to some extent analog hardware. Current hardware platforms permit the fast and accurate digital processing of analog signals using DSPs or FPGAs, while the non ideal properties of analog circuits are becoming more dominant by shrinking, lower voltages, higher temperatures and higher signal frequencies. Therefore, pure analog circuits are combined with digital systems that realize dedicated tasks in digital circuits, compensate the errors and deviations of analog circuits by e.g. calibration, or augment analog circuits with new features such as on-line diagnosis or fail-safe properties. Furthermore embedded systems use an increasing number of sensors, actors or even RF s to react dynamically to their environment. The increasing functional integration in combination with adaptive behavior of software components, FPGAs or parameterizable analog switched capacitor circuits creates many opportunities for circuit design and applications. However, the resulting design alternatives can only be analyzed with appropriate EDA software. SystemC(-AMS) provides appropriate means for specification, modeling, simulation, and synthesis of adaptive and re-configurable mixed-signal systems. In this context we want to support the system design and provide a framework that allows designers an easy exchange of different models, e.g. to exchange a transfer function against a netlist without modifications of the other models and signals in the system. Furthermore it supports both top down and bottom up design: In a top down design flow, it supports the performance exploration of different architectures, and In a bottom up design flow, it provides a test bench for the system verification of refined or synthesized components of the system. Section 2 describes the refinement methodology and the evaluation of synthesized dimensioned circuits in a system test bench. In section 3 the communication principle of the polymorphic signal is explained. Section 4 gives an idea of time savings using polymorphic signals for system design. Examples are presented in section 5 and section 6 concludes the paper. 1.2 Requirements and approach In model based design, designers use different pre-defined schemes for communication and synchronization. These are called models of computation (MoCs). Different MoCs are used, depending on the architecture to be modeled: E.g. This work has been supported within the BMBF/edacentrum project SAMS [9].

analog circuits are modeled by differential and algebraic equations (DAEs), while DSP methods are modeled by static dataflow with constant time steps. Because the MoC specifies the behavior of communication, there is no need for the designer to model communication in an explicit way. Therefore, model based design allows designers the evaluation of different architectures in an earlier stage of the design process. Particular research on the use of different MoCs and model based design has been done within the design framework Ptolemy [1]. The aim of model refinement is a stepwise, successive design and verification process, where each design issue can be evaluated immediately. This means, that simulation in an early design stage with very abstract models should be possible, and that the effort to change a model to a refined one, must be small. In contrast to pure model based design, this permits an earlier evaluation of system properties, can increase re-usability of models, and provides a closer link between a design issue and its reasons. There are many problems that occur with the refinement of a single component. The refined model does not fit to the complete system and converters have to be written manually. This could be very time consuming and is error-prone. Another aspect is that many different design languages are used at the different abstraction levels. This severely hinders small incremental refinement steps. To change this situation we deliver a framework that reduces the effort of a stepwise refinement vastly. We use so called polymorphic signals that allow us a direct communication between different models of computation. All needed converters are included in this polymorphic signal. There is a lot of aspects for using SystemC(AMS) as the underlying design language: First it allows models at different abstraction levels, so that there is no language brake for several steps in in the refinement process. Having one language to describe hard- and software allows the hardware designers and software developers to understand what the respectively other ones are doing. Another advantage one should not forget is that the whole source code of SystemC, written in C++, is available. The argument to use C++ for soft- and hardware lies in the fact that in many designs the software is the largest fraction and the most complex part. As Figure 1 shows, we support the top down approach with the refinement and evaluation of architectures and the bottom up approach by providing a system test bench for synthesized dimensioned circuits. executable specification (abstract models) refinement Figure 1 detailed models implementation refinement synthesis Design flow evaluation of architectures system test bench evaluation in a system test bench For some steps mostly at lower abstraction levels instead of a manual refinement an automatic synthesis can be used. A problem with the design flow is the performance evaluation of designed or synthesized circuits. The impact of the synthesized and dimensioned circuits has to be analyzed. For this purpose we provide a consistent system test bench, where also the synthesized and dimensioned circuits can be simulated immediately. 1.3 Related work In Simulink continuous and discrete components can be coupled directly. But there is no explicit type checking as in VHDL-AMS because Simulink is an interpreter. Without a strict type checking an interactive work is easier. SystemC 2.0 introduces a very generic approach, where signals are accessed via s which can be realized in different ways. This allows the introduction of different models of computation by using different implementations of the [5]. However, the type checking between the s is very strict. E.g. the combination requires the use of converter modules. In Ptolemy II/Chess [1, 6], behavioral types provide basically the same functionality as the signal s in SystemC 2.0. In extension to SystemC 2.0, automata permit the coupling of different models of computation provided there is a subtype relation between them [6]. Note that the subtype relation applies to the value types and to the protocols that implement a model of computation (`behavioral types'). Unfortunately, a subtype relation often does not exist, or can even be misleading because semantic is not considered. In [7, 8], polymorphic signals for signal processing systems were introduced. However, the implementation described in [7] is restricted to

discrete event (DE) and static dataflow () MoCs. In the following we introduce application specific semantic types and a polymorphic signal class that covers the MoCs used in signal processing applications at different levels of abstraction. Compared to Ptolemy, polymorphic signals are application specific, and are not a generic modeling property. The restriction to a domain of applications such as signal processing applications has the advantage, that we can assume that all (polymorphic) signals are approximations of an `ideal', continuoustime signal. This gives all conversions an intuitive understanding. 2 System design with polymorphic signals The framework is based on SystemC-AMS [3] that permits modeling and simulation of signal processing systems. In the following we give a brief introduction of SystemC-AMS. Then we describe the refinement, and the evaluation of synthesized circuits in a test bench. 2.1 SystemC-AMS In SystemC a system is specified by a structure of modules that are connected by directed signals. Modules have ports that allow access to an that is part of the signal. SystemC-AMS is an extension of SystemC that provides means for the modeling of signal processing systems and is structured in three layers [3]: The view layer allows the specification of behavior in different ways such as transfer functions, net lists, or a cluster of signal processing functions. The solver (simulator) layer provides means which execute a specification given at the view layer, e.g. a coordinator which implements the static dataflow MoC, or a solver for linear and non-linear differential equations that have been extracted from the net list view. The synchronization layer couples different solvers (simulators). For this coupling the static/synchronous data-flow () model of computation is used. Note, that both synchronization layer and solver layer introduce an underlying model of computation, but with different aims and requirements: The synchronization layer couples simulators which might also be external simulators such as SPICE. The solver (simulator) layer provides different means for the modeling and simulation of signal processing systems in SystemC. 2.2 Refinement The design of signal processing systems begins with a block diagram which describes the basic structure of the system. Sample frequencies, range of values, and bit widths are not yet known. For the first simulations, designers use the MoC `continuous-time (CT) signal flow'. This model of computation assumes that all connections between modules have the semantics of mathematical equations, and that there is neither an order of execution nor a width of time steps given. Furthermore, signals have no limitation and no quantization. For signal processing systems, there are realizations with fundamentally different behavior: digital signal processing using a DSP or a FPGA, and on the other hand analog realizations. We can easily model the behavior of these implementations by replacing the MoC and/or the signal types of the executable specification by more appropriate ones, which implicitly introduces properties of a realization. Examples of properties of digital signal processing systems that have to be evaluated are primarily sampling frequencies f, quantization steps Q, and range of values (limitation). A useful MoC for modeling digital signal processing is static dataflow with constant time steps 1/f. Appropriate signal values are integers that model Q and the realization's range of values. Properties of analog circuits that are modeled are limitation, limited band width and precision. The refinement process successively replaces modules of the executable specification by modules that model the implementation. This also affects the interaction with other blocks via ports, and may introduce incompatibilities or inconsistencies. Potential changes create the following problems: Changing the model of computation requires the use of other s and different protocols for the transport of data. Data is not only transported, but also might have different meanings, e.g. a sequence of bank account numbers, or an approximation of a continuous-time signal, or even conservative nodes following Kirchhoff laws. Range and quantization/precision are restricted, e.g. from general `real' to a discrete `integer' representation with limitation. Because of these changes, the intuitive composition of a new model by just replacing a module by a more detailed one will not work quite often: In most cases the resulting models are

inconsistent, and require further actions to convert signal types, protocols, and semantics. Of course, designers can manually write converters that adapt value types, s and change semantics. In a limited range, this can be done automatically considering that the ranges of values (and s) are compatible with subtypes. Therefore behavioral types in PtolemyII convert protocols by construction of a common automaton, but without considering the meaning of signals. This extends compatibility, but does not consider semantics of the data transported via a signal. Semantic issues can only be treated in an implicit or automatic way, if we know the semantics. In order to allow the conversion of signals in a more general way, we assume that signals have semantic types. A semantic type of a signal is an abstract interpretation of a signal. In the following we consider signal processing applications. The knowledge of the semantics allows us to formulate different views of one signal, that depend on the signature (, value type) used to access the signal. We call such signals polymorphic signals (for a domain of applications). 2.3 Evaluation of synthesized dimensioned analog circuits in a system test bench Beside the refinement process there is another field, where polymorphic signals can help: After the synthesis of analog circuits these have to be tested in a test bench. In current projects an approach for the synthesis of analog circuits is made [9]. We analyze the synthesized circuits. Analyzing the result of synthesis in a test bench, specific for a component s function is required, and this test bench has to be created manually. As a test bench for overall system simulation the executable specification could be used, provided signal types and number of pins have not changed within the design process. This is usually the case. So the integration of the component is validated by an overall system simulation. 3 Polymorphic signals In the following, we describe the details of our polymorphic signal. In signal processing applications, signals are more or less good approximations of continuous-time signals. Such applications are specified with the following models of computation, depending on the level of abstraction, and implementation: Static dataflow with constant time steps, but very often with different data rates resp. time steps (multi-rate systems) (). Discrete event system (DE). Continuous-time signal flow (simulated by static dataflow with adaptive time steps) (CT-SF). Net lists (CT-NET) describing (electrical) networks. The polymorphic signal covers converters that have to be implemented manually. Additionally it checks the coupled MoCs, e.g. for type consistency, value range adaptation, communication testing, etc. Figure 2 shows a polymorphic signal implemented in SystemC-AMS. On the left side is a module and on the right side a linear electrical network. The polymorphic signal is between them, attached to both s. In this context the polymorphic signal creates a voltage source and sets the voltage source to the value given by the internal abstract representation. module 1 port Figure 2 DE DE polymorphic signal internal abstract representation Polymorphic signal CT CT U(t) module 2 This internal abstract representation of the polymorphic signal is a queue that stores each event as a tuple ( v, t ) whereas v is a value (of type i i t i double) at time point (of type sc_time). The queue is limited to a maximum number of events n, determined by the following equation: n k t s,max = (1) where t s,min t s,max i is the maximum possible time step, k the factor of the multi-rate dataflow, and smallest possible time step. t s,min is the The polymorphic signal converts each written value into a double value, which is stored together with the corresponding time point in this inner abstract representation, visualized in figure 3. Depending on the MoC, there are different types of read and write accesses (described in [8]).

Figure 3 4 value (v i, t i ) (v i +1, t i +1 ) (v i +2, t i +2 ) time frame [now s,max - t,now] (v i +3, t i +3 ) (v i +4, t i +4 ) (v i +5, t i +5 ) Internal abstract representation in a polymorphic signal as a queue of events (value, time) As described in section 2.2, the refinement of signal processing systems is characterized by modules with different sample rates, ranges of values, etc. The polymorphic signal for signal processing applications supports this refinement by providing the following functionality: It implicitly converts sample rates: The signal may have different samples rates at the writing (input) and the reading (output) port. It implicitly adapts the range of values: The range of values at the writing port is adapted to the range of values at the reading port. These ranges have to be set at the reading and writing ports. It implicitly converts different models of computation: The polymorphic signal can be read or written from the above mentioned models of computation. The polymorphic signal provides means for specification (or modeling) of noise and deviations for semi-symbolic analysis [4]. Polymorphic signals can actually be used to couple modules in the supported models of computation without requiring the insertion of additional converters. The polymorphic signal should also hide the complexity of simulator coupling - a designer just sees the polymorphic signal in SystemC-AMS, and in the analog simulator an additional node connected to a source. Time savings with polymorphic signals time The design of a typical system consists of a µc, FPGA and some analog periphery. Classically at the system level Matlab is used for the simulation. For the simulation of the analog electronic at the circuit level, a Spice derivative is used. For the specification of digital electronics Verilog or VDHL are used, while the simulation uses a digital simulator e.g. Modelsim and finally the program code for the µc is written in C. With the conventional top down design flow there are a number of bottle necks and time consuming steps. In a design testing and adoption of value ranges, number formats and models of computations has to be done for each signal. So a lot of debugging problems can occur and one can overlook many errors. Furthermore the program code of the µc or DSP does not run together with the circuit simulator or only with problems, as the µc-program code is not part of the circuit level and requires different simulation technology. In this situation polymorphic signals together with SystemC-AMS can save design time of up to several months, if we think of an otherwise needed manual simulator coupling, several different design languages and problems that are hard to debug - or even worse not tested interaction between hard- and software during the design phase. In our approach, there is only one language for most of the design where an executable specification in SystemC-AMS is implemented and used for simulation. The different models are connected via polymorphic signals. Each single model can be exchanged with a more detailed model at any time. Afterwards the system can be simulated directly. So with polymorphic signals a simple exchange of models is possible. 5 Example As an example we chose a control loop shown in Figure 4. It controls the voltage of a power driver. The voltage is measured, and a difference between the actual value and the programmed value is calculated. Then, a PI controller computes a new pulse width. ctrl_out Figure 4 Pulse former PI controller Uprog 255 ~ctrl_out on_off + PWM Controller - UC Power driver Figure 4 shows the block diagram, for which we used the model of computation. For the

refinement of computation we exchanged single modules with modules that use other abstraction levels and therefore other models of computation (CT-SF DE). low rate high rate synthesized circuits bottom up and the refinement of heterogeneous systems top down. For low level analog circuits as they are used in the common approach and also for legacy models, we need to couple simulators. In the industry a lot of models are already present. These are implemented in Matlab, Spice and many other simulation environments. Reusing them is an important aspect. So we are currently working on coupling methods for SystemC-AMS with different other simulation environments. A simple simulator coupling is already implemented, but we want to integrate this coupling and the polymorphic signals, so that the designer does not have to care much about this coupling. Figure 5 Output of PWM driver with different sample frequencies Figure 5 shows two different output signals that are produced by changing the sample frequencies and models of computation. In a new simulation run the power driver is replaced by an RC-circuit shown in figure 6. The polymorphic signal automatically creates a voltage source that allows a direct communication. ctrl_out Figure 6 6 Pulse former PI controller Uprog 255 ~ctrl_out on_off + - UC PWM Controller with an RC circuit The modified PWM driver model, simulated with two different sample frequencies delivers no visible difference to the one shown in figure 5. This comes to no surprise as the RC circuit was built from a transfer function that modeled the power driver. Conclusions This paper presented a framework for a more efficient and flexible design flow of mixed signal systems. An easy exchange of different models of computation is possible with polymorphic signals. Therefore this methodology provides a consistent system test bench that supports the evaluation of References [1] E. Lee, et al, Actor-Oriented Design of Embedded Hardware and Software Systems. Journal of Circuits, Systems, and Computers, June 2003. [2] J. Eker, et al., Taming heterogeneity - the Ptolemy approach, Proc. of the IEEE, Volume: 91, Issue: 1, Jan. 2003, pp.127-144. [3] K. Einwich, et al, Mixed-Signal Extension for SystemC. In Eugenio Villar and Jean Mermet, editors, SystemC Specification and Design Languages. Kluwer Academic publishers, Apr 2003. [4] Ch. Grimm, et al., Analysis of Mixed-Signal Systems with Affine Arithmetic, IEEE Transactions on Computer Aided Design of Circuits and Systems, Volume: 24, Issue:1, 2005. [5] St. Swan. An Introduction to the System-Level Modeling in SystemC 2.0. Technical report, Open SystemC Initiative, 2001. [6] E. Lee, et al. A Behavioural Type System and its Application in Ptolemy II. Formal Aspects of Computing, 2004. [7] Ch. Grimm. Modeling and Refinement of Mixed Signal Systems with SystemC. In SystemC- Methodologies and Applications. Kluwer Academic Publisher (KAP), June 2003. [8] R. Schroll, et al. HEAVEN: A Framework for the Refinement of Heterogeneous Systems. In Forum on Specification and Design Language (FDL 04), Lille, France, September 2004. [9] http://www.em.cs.uni-frankfurt.de/sams/, 2006