Model-Based Design for Embedded Systems- P21

Chia sẻ: Cong Thanh | Ngày: | Loại File: PDF | Số trang:30

Thêm vào BST

Báo xấu

50
lượt xem 4
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

Model-Based Design for Embedded Systems- P21:The unparalleled flexibility of computation has been a key driver and feature bonanza in the development of a wide range of products across a broad and diverse spectrum of applications such as in the automotive aerospace, health care, consumer electronics, etc.

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: Model-Based Design for Embedded Systems- P21

576 Model-Based Design for Embedded Systems g at tn−1 + 0.5hn and tn−1 + 0.75hn , we must fire but not postfire these actors. Postfiring the actors would erroneously commit them to state updates before we know whether the step size hn is valid. Thus, in effect, the solver must provide them with tentative inputs at each tag (one tag for each of these time values), as shown in Equations 17.5 and 17.6, and find a fixed point at that tag. But it must not commit the actors to any state changes until it is sure of the step size. Avoiding invocation of the postfire method successfully avoids these state changes, as long as all actors conform to the actor abstract semantics. This mechanism is similar to that used in Simulink, where the model_update method is not invoked until a simulation step is concluded. We can now see that CT operates similar to DE models, with the only real difference being that in addition to using an event queue to determine the advancement of time, we must also consult an ODE solver. The same fireAt mechanism that we used in DE would be adequate, but for efficiency we have chosen to use a different mechanism that polls relevant actors for their constraints on the advancement of time and aggregates the results. In our implementation, any actor can assert that it wishes to exert some influence on the passage of time by implementing a ContinuousStepSizeController interface. All such actors will be consulted before time is advanced. The Integrator actors implement this interface and serve as proxies for the solver. But given this general mechanism, there are other useful actors that also implement this interface. For example, the LevelCrossingDetector actor implements this interface. Given a CT input signal, it looks for tags at which the value of the signal crosses some threshold given as a parameter. If a step size results in a crossing of the threshold, the actor will exert control over the step size, reducing it until the time of the crossing is identified to some specified precision. Since the CT director only assumes that component actors conform to the actor abstract semantics, these actors can be opaque composite actors that internally contain SR or DE models. Moreover, a CT model can now form an opaque composite actor that exports the actor abstract semantics, and hence CT models can be included within SR or DE models and vice versa (subject again to the constraint that if SR is at the top level, then it must be explicit about time). A simple example is shown in Figure 17.8. The top-level model is DE rep- resenting a sequence of discrete jobs with increasing service requirements. For each job, a random (exponential) service rate is generated. The inside model uses a single integrator to model the (continuous) servicing of the job and a level-crossing detector to detect completion of the job. 17.8 Software Implementation A prototype of the techniques described here in Ptolemy II is available in an open-source form (BSD-style license) at http://ptolemy.org. We started with
Mixed Continuous and Discrete Systems 577 DE director Ramp TimedPlotter Job processor ColtExponential Trigger Lambda TimedDelay Delay of 0.0 Continuous director TimedPlotter ZeroOrderHold LevelCrossingDetector2 Job JobDone Falling 0.0 AddSubtract ZeroOrderHold3 Integrator2 Rate + – FIGURE 17.8 CT opaque composite actor within a DE model. the SRDirector created by Whitaker [48], which was based on an SR direc- tor in Ptolemy classic created by Edwards and Lee [17]. We then used this director as a base class for a new ContinuousDirector. Unlike the predecessor CTDirector created by Liu [37], this new director realizes a fixed point seman- tics at each discrete time point. The discrete time points are selected from the time continuum, as explained above, in response to actors that invoke fireAt and actors that implement ContinuousStepSizeController. The latter include integrator actors, which use an underlying ODE solver with variable step size control. We modified SRDirector and implemented ContinuousDirector so that both now rigorously export the actor abstract semantics. That is, when the fire method of either director is invoked, the director does not commit to any state changes, and it does not invoke postfire on any actors contained in its composite. Thus, if those actors conform to the actor abstract semantics, then so does the opaque composite actor containing the director.
578 Model-Based Design for Embedded Systems These improvements led to significant improvements in simplicity and usability. Before we had a menagerie of distinct versions of CTDirector, but now we only need one. Previously, in order to compose CT models with other MoCs (such as DE for mixed signal models and FSM for modal models and hybrid systems), we needed to implement specialized cross-hierarchy operations to coordinate the speculative execution of the ODE solver with the environment. This resulted in distinct directors for use inside opaque composite actors and inside modal models. We also acquired the ability to put SR inside CT models. This is extremely convenient, because SR can be used to efficiently specify numeric compu- tations and complex decision logic, where the continuous dynamics of CT is irrelevant and distracting. Note that it would be much more difficult to use dataflow models, such as SDF [31] inside CT models. This is because in dataflow models, communication between actors is queued. In order to sup- port the speculative executions that an ODE solver performs, we would have to be able to backtrack the state of the queues. This would add considerable complexity. SR has no such difficulty. Since the CT MoC is a generalization of the SR, in principle, SR becomes unnecessary. However, SR is much simpler, not requiring the baggage of support for ODE solvers, and hence is more amenable to formal analysis, optimization, and code generation. 17.9 Conclusions In this chapter, we explain an operational semantics that supports mixtures of SR, DE, and CT MoC, and outline a corresponding denotational semantics. Dialects of DE and CT are developed that generalize SR, but provide com- plementary modeling and design capabilities. We show that the three MoCs can be combined hierarchically in arbitrary order. Acknowledgments We thank to Jie Liu, Xiaojun Liu, Eleftherios Matsikoudis, and Reinhard von Hanxleden for their major contributions to our understanding of this topic, to the software on which we base this chapter, and to the contents of this chapter. The work described in this chapter was supported in part by the Cen- ter for Hybrid and Embedded Software Systems (CHESS) at UC Berke- ley, which receives support from the National Science Foundation (NSF
Mixed Continuous and Discrete Systems 579 awards #0720882 (CSR-EHS: PRET), #0647591 (CSR-SGER), and #0720841 (CSR-CPS)), the U. S. Army Research Office (ARO #W911NF-07-2-0019), the U. S. Air Force Office of Scientific Research (MURI #FA9550-06-0312 and AF- TRUST #FA9550-06-1-0244), the Air Force Research Lab (AFRL), the State of California Micro Program, and the following companies: Agilent, Bosch, HSBC, Lockheed-Martin, National Instruments, and Toyota. References 1. G. A. Agha, I. A. Mason, S. F. Smith, and C. L. Talcott. A foundation for actor computation. Journal of Functional Programming, 7(1):1–72, 1997. 2. R. Alur, T. Dang, J. Esposito, Y. Hur, F. Ivancic, V. Kumar, I. Lee, P. Mishra, G. J. Pappas, and O. Sokolsky. Hierarchical modeling and analysis of embedded systems. Proceedings of the IEEE, 91(1):11–28, 2003. 3. A. Basu, M. Bozga, and J. Sifakis. Modeling heterogeneous real-time components in BIP. In International Conference on Software Engineering and Formal Methods (SEFM), pp. 3–12, Pune, India, September 11–15, 2006. 4. A. Benveniste and G. Berry. The synchronous approach to reactive and real-time systems. Proceedings of the IEEE, 79(9):1270–1282, 1991. 5. A. Benveniste, L. Carloni, P. Caspi, and A. Sangiovanni-Vincentelli. Heterogeneous reactive systems modeling and correct-by-construction deployment. In EMSOFT, Philadelphia, PA, 2003, Springer. 6. G. Berry. The Constructive Semantics of Pure Esterel. Book Draft, 1996. http://www-sop.inria.fr/meije/esterel/doc/main-papers.html 7. G. Berry. The effectiveness of synchronous languages for the develop- ment of safety-critical systems. White paper, Esterel Technologies, 2003. 8. G. Berry and G. Gonthier. The Esterel synchronous programming lan- guage: Design, semantics, implementation. Science of Computer Program- ming, 19(2):87–152, 1992. 9. R. Boute. Integrating formal methods by unifying abstractions. In E. Boiten, J. Derrick, and G. Smith (editors,) Fourth International Confer- ence on Integrated Formal Methods (IFM), 2999: Canterbury, Kent, U.K., April 4–7, 2004, LNCS, pp. 441–460, Springer-Verlag. 10. C. Brooks, A. Cataldo, C. Hylands, E. A. Lee, J. Liu, X. Liu, S. Neuendorf- fer, and H. Zheng. HyVisual: A hybrid system visual modeler. Technical
580 Model-Based Design for Embedded Systems report UCB/ERL M03/30, University of California, Berkeley, CA, July 17, 2003. 11. J. T. Buck, S. Ha, E. A. Lee, and D. G. Messerschmitt. Ptolemy: A frame- work for simulating and prototyping heterogeneous systems. Interna- tional Journal of Computer Simulation, Special issue on “Simulation Software Development,” 4:155–182, 1994. 12. L. P. Carloni, M. D. DiBenedetto, A. Pinto, and A. Sangiovanni- Vincentelli. Modeling techniques, programming languages, and design toolsets for hybrid systems. Technical Report IST-2001-38314 WPHS, Columbus Project, June 2004. 13. C. G. Cassandras. Discrete Event Systems, Modeling and Performance Anal- ysis. Irwin, Boston, MA, 1993. 14. A. Cataldo, E. A. Lee, X. Liu, E. Matsikoudis, and H. Zheng. A construc- tive fixed-point theorem and the feedback semantics of timed systems. In Workshop on Discrete Event Systems (WODES), Ann Arbor, MI, July 10–12, 2006. 15. A. Deshpande, A. Gollu, and P. Varaiya. The Shift programming lan- guage for dynamic networks of hybrid automata. IEEE Transactions on Automatic Control, 43(4):584–587, 1998. 16. R. Djenidi, C. Lavarenne, R. Nikoukhah, Y. Sorel, and S. Steer. From hybrid simulation to real-time implementation. In 11th European Simula- tion Symposium and Exhibition (ESS99), pp. 74–78, Erlangen-Nuremberg, Germany, October 1999. 17. S. A. Edwards and E. A. Lee. The semantics and execution of a syn- chronous block-diagram language. Science of Computer Programming, 48(1):21–42, 2003. 18. J. Eker, J. W. Janneck, E. A. Lee, J. Liu, X. Liu, J. Ludvig, S. Neuendorffer, S. Sachs, and Y. Xiong. Taming heterogeneity—The Ptolemy approach. Proceedings of the IEEE, 91(2):127–144, 2003. 19. G. S. Fishman. Discrete-Event Simulation: Modeling, Programming, and Analysis. Springer-Verlag, New York, 2001. 20. P. Fritzson. Principles of Object-Oriented Modeling and Simulation with Mod- elica 2.1. Wiley, New York, 2003. 21. A. Girault, B. Lee, and E. A. Lee. Hierarchical finite state machines with multiple concurrency models. IEEE Transactions On Computer-Aided Design of Integrated Circuits and Systems, 18(6):742–760, 1999.
Mixed Continuous and Discrete Systems 581 22. G. Goessler and A. Sangiovanni-Vincentelli. Compositional modeling in Metropolis. In Second International Workshop on Embedded Software (EMSOFT), Grenoble, France, October 7–9, 2002, Springer-Verlag. 23. G. Goessler and J. Sifakis. Composition for component-based modeling. Science of Computer Programming, 55:161–183, 2005. 24. P. L. Guernic, T. Gauthier, M. L. Borgne, and C. L. Maire. Programming real-time applications with SIGNAL. Proceedings of the IEEE, 79(9):1321– 1336, 1991. 25. N. Halbwachs, P. Caspi, P. Raymond, and D. Pilaud. The synchronous data flow programming language LUSTRE. Proceedings of the IEEE, 79(9):1305–1319, 1991. 26. F. Herrera and E. Villar. A framework for embedded system specification under different models of computation in SystemC. In Design Automation Conference (DAC), San Francisco, CA, July 2006. ACM. 27. C. Hewitt. Viewing control structures as patterns of passing messages. Journal of Artifical Intelligence, 8(3):323–363, 1977. 28. A. Jantsch. Modeling Embedded Systems and SoCs—Concurrency and Time in Models of Computation. Morgan Kaufmann, San Francisco, CA, 2003. 29. E. A. Lee. Modeling concurrent real-time processes using discrete events. Annals of Software Engineering, 7:25–45, 1999. 30. E. A. Lee. Embedded software. In M. Zelkowitz (editor), Advances in Computers, vol. 56. Academic Press, London, U.K., 2002. 31. E. A. Lee and D. G. Messerschmitt. Synchronous data flow. Proceedings of the IEEE, 75(9):1235–1245, 1987. 32. E. A. Lee and S. Neuendorffer. MoML—A modeling markup language in XML. Technical report UCB/ERL M00/12, UC Berkeley, Berkeley, CA, March 14, 2000. 33. E. A. Lee, S. Neuendorffer, and M. J. Wirthlin. Actor-oriented design of embedded hardware and software systems. Journal of Circuits, Systems, and Computers, 12(3):231–260, 2003. 34. E. A. Lee and A. Sangiovanni-Vincentelli. A framework for comparing models of computation. IEEE Transactions on Computer-Aided Design of Circuits and Systems, 17(12):1217–1229, 1998. 35. E. A. Lee and H. Zheng. Operational semantics of hybrid systems. In M. Morari and L. Thiele (editors), Hybrid Systems: Computation and Control
582 Model-Based Design for Embedded Systems (HSCC), Zurich, Switzerland, March 9–11, 2005. LNCS, 3414: pp.25–53, Springer-Verlag. 36. E. A. Lee, H. Zheng, and Y. Zhou. Causality interfaces and compositional causality analysis. In Foundations of Interface Technologies (FIT), Satellite to CONCUR, San Francisco, CA, August 21, 2005. 37. J. Liu. Responsible frameworks for heterogeneous modeling and design of embedded systems. PhD thesis Technical Memorandum UCB/ERL M01/41, December 20, 2001. 38. X. Liu and E. A. Lee. CPO semantics of timed interactive actor net- works. Technical report EECS-2006-67, UC Berkeley, Berkeley, CA, May 18, 2006. 39. X. Liu, E. Matsikoudis, and E. A. Lee. Modeling timed concurrent sys- tems. In CONCUR 2006—Concurrency Theory, Bonn, Germany, August 27–30, 2006. LNCS, 4137: Springer. 40. Z. Manna and A. Pnueli. Verifying hybrid systems. Hybrid Systems, LNCS, 736: pp. 4–35, 1992, Springer. 41. D. A. Mathaikutty, H. D. Patel, and S. K. Shukla. A functional program- ming framework of heterogeneous model of computation for system design. In Forum on Design and Specification Languages (FDL), Lille, France, September 2004. 42. P. Mosterman. An overview of hybrid simulation phenomena and their support by simulation packages. In F. Varager and J. H. v. Schuppen (editors), Hybrid Systems: Computation and Control (HSCC), Bergen Dal, the Netherlands, 1999, LNCS, 1569: pp. 165–177, Springer-Verlag. 43. W. H. Press, S. Teukolsky, W. T. Vetterling, and B. P. Flannery. Numerical Recipes in C: The Art of Scientific Computing. Cambridge University Press, Cambridge, MA, 1992. 44. I. Sander and A. Jantsch. System modeling and transformational design refinement in forsyde. IEEE Transactions on Computer-Aided Design of Cir- cuits and Systems, 23(1):17–32, 2004. 45. S. Swan. An introduction to system level modeling in SystemC 2.0. Tech- nical report, Open SystemC Initiative, May 2001. 46. M. M. Tiller. Introduction to Physical Modeling with Modelica. Kluwer Aca- demic Publishers, Norwell, MA, 2001. 47. F. D. Torrisi, A. Bemporad, G. Bertini, P. Hertach, D. Jost, and D. Mig- none. Hysdel 2.0.5—User manual. Technical report, ETH, 2002.
Mixed Continuous and Discrete Systems 583 48. P. Whitaker. The simulation of synchronous reactive systems in Ptolemy II Master’s Report Memorandum UCB/ERL M01/20, Electron- ics Research Laboratory, University of California, California, CA, May 2001. 49. B. P. Zeigler, H. Praehofer, and T. G. Kim. Theory of Modeling and Simula- tion. 2nd edition, Academic Press, Orlando, FL, 2000.
18 Design Reﬁnement of Embedded Mixed-Signal Systems Jan Haase, Markus Damm, and Christoph Grimm CONTENTS 18.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 585 18.1.1 Previous Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 586 18.1.2 Design Refinement of E-AMS Systems with OSCI AMS Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 587 18.2 OSCI SystemC-AMS Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 588 18.3 Design Refinement of Embedded Analog/Digital Systems . . . . . . . . . . . . . . . . . . 591 18.3.1 Use Cases of SystemC AMS Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 591 18.3.2 Design Refinement Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 592 18.3.3 Methodology-Specific Support in SystemC AMS Extensions . . . . . . . 595 18.3.4 Methodology-Specific Support in a Methodology- Specific Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 596 18.4 Simple Example for a Refinement Step Using Converter Channels . . . . . . . . . 597 18.5 Conclusion and Outlook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 600 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 601 18.1 Introduction There is a growing trend for closer interaction between embedded hard- ware/software (HW/SW) systems and their analog physical environment. This leads to systems in which digital HW/SW is functionally interwoven with analog and mixed-signal blocks such as radio-frequency (RF) inter- faces, power electronics, and sensors and actuators, as shown, for example, by the communication system in Figure 18.1. We call such systems “embed- ded analog/mixed-signal (E-AMS) systems.” Examples of E-AMS systems are cognitive radios, sensor networks, and systems for image sensing. A chal- lenge for the development of E-AMS systems is to understand and consider the interaction between HW/SW and the analog and mixed-signal subsys- tems at architecture level. Complexity of modern systems often requires methodologies that hide complexity and allow designers an incremental, interactive approach that 585
586 Model-Based Design for Embedded Systems Radio Microcontroller Upper layer transceiver protocols Wakeup Oscillators radio wakeup timers Low-level MAC packet handling layer(s) Energy supply functions Security management Sensor interfaces Node power management SoC/SiP FIGURE 18.1 A node of a sensor network serving as an example of an E-AMS architecture. step-by-step leads to an implementation. In this approach, it is crucial to obtain very early feedback on the impact of nonideal properties onto overall system performance, which requires considering interaction of HW/SW and AMS subsystems. In the SW engineering community, extreme programming [17] uses a stepwise approach that starts with code fragments that are successively “refined” by SW engineers. Refinement of SW systems has been known for a long time (e.g., [15]). However, the SW-oriented approaches are restricted to pure SW systems and do not deal with specific problems in the design of E-AMS systems. In the realm of formal “property refinement” of embedded systems, a (formal) property that is present and proved in a system spec- ification is maintained by proved design steps (e.g., [16]). In this chapter, we describe a design refinement approach for E-AMS systems. Similar to extreme programming, and in the same vein of “property refinement,” it is an incremental approach. Compared to extreme programming, however, it is more specifically tailored to E-AMS system design, whereas compared to property refinement we do not intend to provide a formal proof. 18.1.1 Previous Work SystemC [1] supports the refinement of HW/SW systems down to RTL by providing a discrete-event (DE) simulation framework. Design refine- ment of HW/SW systems starts with a functional, untimed specification that
Design Reﬁnement of Embedded Mixed-Signal Systems 587 is successively augmented with timing information, power consumption, and more accurate modeling of communication and simulation of poten- tial HW/SW architectures. However, the properties of E-AMS systems are much more diverse than only timing, performance, and power consump- tion. A key issue is the accuracy that is determined by noise, sampling fre- quencies, quantization, and very complex, nonlinear dependencies between subsystems: Often, accuracy of the AMS part is improved by digital signal processing (DSP) software in the HW/SW part. SystemC offers neither an appropriate methodology for refinement of E-AMS nor support for the mod- eling and simulation of analog, continuous-time systems. Support for modeling and simulation of E-AMS systems is offered by tools such as Simulink R [3] and Ptolemy II [4]. While their support for system-level design also facilitates capturing continuous-time behavior, these tools lack appropriate support for the design of HW/SW (sub)systems at the architecture level in a manner that, for example, SystemC does. Hardware description languages (HDLs) dedicated to the design of AMS systems such as VHDL-AMS [5] and Verilog-AMS [6] target the design of mixed-signal subsystems close to implementation level such as analog/dig- ital (A/D) converters, but modeling HW/SW systems based on HDLs is cumbersome. To support HW/SW system design, cosimulation solution frameworks mix SystemC and Verilog/VHDL-AMS. However, although the resulting heterogeneous framework allows designers the modeling of mixed HW/SW and AMS architectures, it does not support interactive evaluation of different potential architectures in a seamless design refinement flow. 18.1.2 Design Reﬁnement of E-AMS Systems with OSCI AMS Extensions An earlier work by the open SystemC initiative (OSCI) [12] presented an AMS extension that augments SystemC with the ability to model and sim- ulate AMS subsystems at functional and architectural level [7,8]. Further- more, this work specifically intends to support design refinement of E-AMS. Design refinement of E-AMS starts with a functional description that is used as an “executable specification.” In “architecture exploration,” properties of different subsystems such as • Noise, distortions, and limitation effects • Quantization and sampling frequencies • Partitioning of (A/D/SW) are added to the functional specification. The impact of these properties on the overall system performance (accuracy, power consumption, etc.) is deter- mined by modeling and simulation. In this chapter, we assume that the reader is familiar with SystemC 2.0. We first present a brief overview of the SystemC AMS extensions. A more detailed overview of the AMS extensions is provided in [9,12]. Then, we
588 Model-Based Design for Embedded Systems describe typical use cases of SystemC AMS extensions to focus on architec- ture exploration and to classify different levels of refinement and refinement activities. 18.2 OSCI SystemC-AMS Extensions The SystemC AMS extensions provide support for signal flow, data flow, and electrical networks, as shown in Figure 18.2. Electrical networks and signal- flow models use a linear differential and algebraic equation (DAE) solver that solves the equation system and that is synchronized with the SystemC ker- nel. The use of a linear DAE solver restricts networks and signal-flow com- ponents to linear models in order to provide high simulation performance. Data-flow simulation is accelerated using a static schedule that is computed before simulation starts. This schedule is activated in discrete time steps, where synchronization with the SystemC kernel introduces timed semantics. It is therefore called “timed” data flow (TDF). The SystemC AMS extensions define new language constructs identified by the prefix sca_. They are declared in dedicated namespaces sca_tdf (TDF), sca_eln (electrical linear networks (ELN)), and sca_lsf (linear signal flow (LSF)) according to the underlying semantics. By using names- paces, similar primitives as in SystemC are defined to denote ports, inter- faces, signals, and modules. For example, a TDF input port is an object of class sca_tdf::sca_in. LSF and linear electrical networks (LEN) are specified by instantiating components of the AMS extensions library such as resistors, capacitors, and Application written by the end user AMS methodology-specific elements SystemC elements for AMS design refinement, etc– methodology- specific Timed data Linear signal Electrical linear User-defined elements flow (TDF) flow (LSF) networks (ELN) AMS extensions transaction modules modules modules modules, ports level ports ports terminals signals modeling, signals signals nodes (e_g_aditional cycle bit solvers/ accurate Scheduler Linear DAE solver simulators) modeling etc_ Synchronization layer SystemC language and C/C++ language FIGURE 18.2 AMS extensions for the SystemC language standard.
Design Reﬁnement of Embedded Mixed-Signal Systems 589 (controlled) current sources for LEN or integrators and adders for LSF. TDF requires some new syntactic elements and is crucial for understanding the SystemC AMS extensions. In the following, we will concentrate on TDF models. TDF models consist of TDF modules that are connected via TDF signals using TDF ports. Connected TDF modules form a contiguous graph structure called TDF cluster. Clusters must not have cycles without delays, and each TDF signal must have one source. A cluster is activated in discrete time steps. The behavior of a TDF module is specified by overloading the predefined methods set_attributes(), initialize(), and processing(): • The method set_attributes() is used to specify attributes such as rates, delays, and time steps of TDF ports and modules. • The method initialize() is used to specify initial conditions. It is executed once before the simulation starts. • The method processing() describes time–domain behavior of the module. It is executed with each activation of the TDF module during the simulation. It is expected that there is at least one definition of the time step value and, in the case of cycles, one definition of a delay value per cycle. TDF ports are single-rate by default. It is the task of the elaboration phase to compute and propagate consistent values for the time steps to all TDF ports and modules. Before simulation, the scheduler determines a schedule that defines the order of activation of the TDF modules, taking into account the rates, delays, and time steps. During simulation, the processing() methods are executed at discrete time steps. Example 18.1 shows the TDF model of a mixer. The processing() method will be executed every 1μs. SCA_TDF_MODULE(mixer) // TDF primitive module definition { sca_tdf::sca_in rf_in, lo_in; // TDF in ports sca_tdf::sca_out if_out; // TDF out ports void set_attributes() { set_timestep(1.0, SC_US); // time between activations } void processing() // executed at each activation { if_out.write( rf_in.read() * lo_in.read() ); } SCA_CTOR(mixer) {} }; Example 18.1 TDF model of a mixer. Predefined converter ports (sca_tdf:: sc_out or sca_tdf::sc_in) can establish a connection to a SystemC DE channel, for instance, sc_signal, to read or write values during the first
590 Model-Based Design for Embedded Systems delta cycle of the current SystemC time step. Example 18.2 illustrates the use of such a converter port in a TDF module modeling a simple A/D converter with an output port to which a SystemC DE channel can be bound. This A/D converter also scales the input values based on a given input range to fit the range of the output data type, while clipping the inputs out of range. SCA_TDF_MODULE(ad_converter) // simple AD converter { sca_tdf::sca_in in_tdf; // TDF port sca_tdf::sc_out out_de; // converter port to DE domain double in_range_min, in_range_max; // expected range of input values double scaleFactor; // scaling factor due to input range void processing() { double val; if(in_tdf.read() > in_range_max) val = pow(2,12)-1; // clip if else if(in_tdf.read() < in_range_min) val = 0; // necessary else val = (in_tdf.read() - in_range_min) * scaleFactor; // scale otherwise out_de.write( static_cast(val) ); { ad_converter(sc_module_name n, double _in_range_min, double _in_range_max) { in_range_min = _in_range_min; in_range_max = _in_range_max; scaleFactor = (pow(2,12)-1)/(in_range_max - in_range_min); { }; Example 18.2 TDF model of a simple A/D converter using a converter port. The SystemC AMS simulation kernel uses its own simulation time tTDF that usually differs from the SystemC simulation time tDE . If a pure TDF model is used in a simulation, the SystemC AMS simulation kernel blocks the DE kernel, and so the DE simulation time does not proceed at all. That is, in general we have tTDF ≥ tDE . In a mixed TDF-DE model, interconnected by converter ports, there is of course the need for synchronization. If there is an access to a converter port within the processing() method of a TDF module, the SystemC AMS simulation kernel interrupts the execution of the static schedule of TDF modules and yields control to the SystemC DE simulation kernel, such that the DE part of the model can now execute, effectively proceeding tDE until it is equal to tTDF . Now, the DE modules reading from signals driven by TDF
Design Reﬁnement of Embedded Mixed-Signal Systems 591 26 ms 32 ms 38 ms 26 ms 32 ms 38 ms tTDF TDF-module M1 Token p1 p2 valid at 26 28 30 32 34 36 38 40 42 ms 26 29 32 35 38 41 ms Timestep = 6 ms tDE Rate 3 Rate 2 20 ms 38 ms 20 ms 38 ms Synchronization tTDF tDE FIGURE 18.3 Synchronization between tTDF ↔ tDE . modules can read their new values at the correct time, and TDF modules reading from signals driven by DE modules can read their correct current values. Figure 18.3 shows an example using a TDF module M1 with input rate 3, output rate 2, and a time step of 6 ms. The data tokens consumed are on the left-hand axis, and those produced are on the right-hand axis. The numbers below the tokens denote the time (in ms) at which the respective token is valid. The time spans above the tokens indicate the values of tTDF when the respective tokens are consumed and produced, respectively. The time spans below indicate the according values for tDE . At the beginning of the exam- ple, tTDF > tDE already holds until tTDF = 38 ms. Then the SystemC-AMS sim- ulation kernel initiates synchronization, for example because M1 contains a converter port that it accesses at this time or because another TDF module within the same TDF cluster accesses its converter port. It has to be underlined that SystemC AMS extensions are recently avail- able as beta version and are under public review. This means that language features may change. In the current draft standard, for example, name spaces are introduced and the keywords are slightly changed. 18.3 Design Refinement of Embedded Analog/Digital Systems To increase design productivity, it is not sufficient to just use the AMS exten- sions in the same way as, for example, VHDL-AMS was used. The most important thing is to use the new language in a design methodology that enables designers to fully take advantage of the new features of SystemC AMS extension. 18.3.1 Use Cases of SystemC AMS Extensions System AMS extensions are extensively applicable to all design issues of E-AMS systems at the architecture level: executable specification, architecture
592 Model-Based Design for Embedded Systems exploration, virtual prototyping, and integration validation as discussed in [12]. For executable specification, a functional model is used that most notably uses the TDF model of computation and (continuous-time) transfer functions that are embedded in single TDF nodes. For architecture explo- ration, for each node of the executable specification an implementation (ana- log, digital HW, DSP + SW) is assumed and evaluated using modeling and simulation. Virtual prototyping allows SW developers to develop and ana- lyze software that, for instance, compensates nonideal properties of the ana- log parts. After implementation, integration validation provides confidence in the functional correctness of each designed component in the context of the overall system. Figure 18.5 depicts an example of a simple executable specification cap- tured by using the TDF MoC by a signal processing chain using functional blocks. For architecture exploration, partitions of the TDF model are mapped to components from different implementation domain (analog, DSP-SW) at the architecture level. To analyze a different architecture, filter 1 in Figure 18.5 can, for example, be shifted from the analog domain to a DSP implementation. 18.3.2 Design Reﬁnement Methodology The intent of the design refinement methodology is to “successively” aug- ment and integrate properties of an implementation into a functional model, and to instantaneously analyze their impact by modeling and simulation. We assume that the refinement starts with a functional model given as an executable specification using the TDF model of computation and embedded continuous transfer functions as shown by Figure 18.4. DSP Functional LNA Mixer Filter algorithm model in TDF Architecture AMS ADC/DAC DSP model in (ELN) (DE) DE, ELN FIGURE 18.4 An architecture exploration by mapping a functional model to architecture- level processors, and repartitioning of an E-AMS system by moving a com- ponent from the analog domain to a DSP implementation.
Design Reﬁnement of Embedded Mixed-Signal Systems 593 In order to incrementally transform this functional model into models that allows designers evaluation of different architectures, we use the fol- lowing refinement activities: • Refinement of computation replaces algorithms, models, and data types of the functional model by algorithms, models, and data types that more accurately match the intended architecture. However, the model of computation and the overall structure of the executable specifica- tion remain unchanged. For example, refinement of computation can add noise and distortions to a mixer. A model is called a “compu- tation accurate model,” if it yields similar results as the implementa- tion, where similar results means that the expected properties of the implementation and the properties of the computation-accurate model are—within tolerances—similar. The purpose of the refinement of computation is to analyze the impact of nonideal behavior of an archi- tecture using a simple functional model. • Refinement of structure (repartitioning) maps partitions of the functional model to components at architecture level that can realize the same (or similar in the same sense as above) behavior using other methods, operating principles, or models of computation (MoC). For example, refinement of structure can map a continuous-time transfer function to a DSP method implemented using a DSP processor. We furthermore distinguish between Top-down refinement by creative design of new structures. Bottom-up refinement by integration (reuse) of existing models, code fragments, and designs. After application of all steps of refinement to a model, we refer to it as a “structure accurate model.” The purpose of the refinement of the structure is to introduce the architecture’s structure and the architec- ture’s MoC in all components. • Refinement of interfaces replaces functional means for modeling com- munication (e.g., an interface specification) and synchronization with physical models of communication and synchronization (e.g., a pin- accurate bus or electrical nodes). We call the result of (full) refinement of interfaces an “interface-accurate or pin-accurate model.” The pur- pose of refinement of interfaces is to enable circuit level design which is based on pin-accurate models, and to enable the validation of system integration. Because we consider an incremental methodology, refinement activities that only refine a partition of a system are supported as well. If only a subset of all refinement activities has been performed, we call the model partially (computation/structure/interface) accurate. Although many refinement activities can be performed in an independent manner, there is a “natural” or “logical” order to the refinement activities:
594 Model-Based Design for Embedded Systems First algorithms, (functional) models and methods should be defined by a refinement of computation—this to consider the expected or estimated inac- curacies from analog parts by a refinement of computation. This step is done first because the impact of noise and inaccuracies in AMS systems is often mission-critical. Usually a refinement of structure is implicitly introduced by defining (DSP) methods and (functional) models because this assumes ana- log or digital implementations, but without distinguishing between HW or SW implementations. Second, the algorithms must be mapped to processors by refinement of structure. This most notably adds accuracy of timing, provides more accurate computation results compared with the “implementation level,” and pro- vides more accurate information on the use of other resources (e.g., power and CPU time). The changed operation principle often includes the specifi- cation of new methods. This is especially the case if we refine a block from the TDF MoC to a pure digital implementation. In this case, we also have to provide new methods for communication and synchronization that ensure the function of the block to be executed in the same order as before. Finally, the interfaces of the components are refined. This is usually the final step, because it does not contribute to the functional behavior but significantly decreases the simulation performance. Nevertheless, interface- accurate models are necessary as a starting point for ASIC/FPGA design, for integration verification, and for virtual prototyping. It is important to note that for integration validation and virtual prototyp- ing the models should be computation accurate and only be interface accu- rate where needed in order to obtain high simulation performance. Figure 18.5 shows a typical schedule of the use cases and refinement activities. A major example is that the refinement activities and use cases can be overlapping in time: ASIC/FPGA/SW design of a single component can start after refinement of structure, but before all interfaces are completely defined, and integration validation can start immediately when an interface- accurate model becomes available. Functional level (executable specification) Refinement of Abstraction computation Refinement of structure Refinement of Integration Design time validation interfaces Architecture level ASIC/FPGA/SW design FIGURE 18.5 Use cases and refinement activities.
Design Reﬁnement of Embedded Mixed-Signal Systems 595 18.3.3 Methodology-Speciﬁc Support in SystemC AMS Extensions While many modeling languages and tools can be used to specify the mod- els necessary for design refinement as described above, the corresponding effort required by the designer may vary significantly. In the following we identify means to efficiently perform the refinement activities. SystemC AMS extensions already offer some support for refinement that are likely to make it easier for designers to follow a seamless flow as described in this chapter: Refinement of computation uses the functional model from the exe- cutable specification. Therefore, the required changes can be made in the processing() section of the TDF modules. For example, the noise of an assumed analog implementation of a mixer can be modeled and analyzed by adding just a single line of code to a mixer modeled as multiplier in the executable specification: void processing() // Mixer refined with distortions and noise { double rf = in1.read(); double lo = in2.read(); double rf_dist = (alpha - gamma * rf * rf ) * rf; // added line double mix_dist = rf_dist * lo; if_out.write( mix_dist + my_noise() ); } This “refinement of computation” basically yields similar behavior as the original model, and allows a designer to very quickly evaluate the impact of noise and distortions in a mixer to, for example, the bit error rate of a transceiver system while taking advantage of the simulation performance of a functional model. Refinement of structure/repartitioning activities most notably change the model of computation in which a component is used. This unfortunately requires some effort from the designer. The SystemC AMS extension sup- ports this by providing name spaces for all MoCs in which the same iden- tifiers are used for the modeling infrastructure such as ports, signals, etc. Although a complete reuse of models in another MoC is not possible because this requires translating the semantics, for example, from a DAE to a discrete model, at least ports, signals, and other basic, rather syntactic parts can be maintained, and changes are restricted to the lines that really are important to express the semantics. Often a reuse of existing models of components is possible—no design really proceeds in a strict top-down manner. There- fore, the case of “bottom-up refinement of structure” is quite often. In this case, an existing structure (e.g., a circuit level implementation) is integrated into a functional or architecture level model. SystemC AMS supports these refinement activities by a wide range of converters between the available MoC. Where possible, converter ports are provided (TDF). When MoC do