1. Trang chủ
  2. » Công Nghệ Thông Tin

Model-Based Design for Embedded Systems- P62 docx

10 218 0

Đang tải... (xem toàn văn)

THÔNG TIN TÀI LIỆU

Thông tin cơ bản

Định dạng
Số trang 10
Dung lượng 322,93 KB

Nội dung

Nicolescu/Model-Based Design for Embedded Systems 67842_C018 Finals Page 596 2009-10-1 596 Model-Based Design for Embedded Systems not provide means to describe new primitive modules, and thus no con- verter ports can be used, converter modules are provided (ELN, LSF). The motivation for providing a basic set of predefined converters is that replac- ing single blocks of a TDF cluster with structure or even interface-accurate models leads to a heterogeneous structure that combines • TDF (and embedded transfer functions) for the executable specification • LSF signals (or ELN nodes) for analog implementation • SystemC DE signals for digital implementation • TDF with bit-true data type for DSP SW implementation The potential use of SystemC AMS modules (and thus converter ports, converter modules) in hierarchical models as well as in hierarchical chan- nels motivates a more sophisticated support for the design refinement of structure. 18.3.4 Methodology-Specific Support in a Methodology- Specific Library Although SystemC AMS provides a basic set of converters, a richer and more flexible set of converters is useful for design refinement, especially in the case of structure refinement, where a functional (or computation accurate) block is replaced with an interface and structure accurate block. In this case, the MoC often differ from the originally used TDF model of computation. Although in all cases the basic set of converters allows the design engineer to set up a valid model, some additional effort and changes to the overall system structure are typically needed. However, these changes may violate principles of refinement that require changes to be made in a local sense, and with low effort This violation may occur in particular in case of struc- tural refinement by integrating circuit level models into functional models: In this case, a refinement step would require the design engineer to modify the overall model by introducing converter modules or converter ports that translate the functional semantics (e.g., data flow, signal flow) into physical sizes of electrical nodes. To relieve the design engineer of this awkward and error prone con- version tasks, the concept of polymorphic signals has been developed [10], and has been recently extended to a facility called “converter channel” [11]. Converter channels can automatically connect SystemC modules that are modeled using different MoCs, such as the TDF MoC of the SystemC AMS extensions, or the DE MoC that is native to SystemC, while also performing data-type conversion. The idea of the converter channel is that the designer declares the MoC and the data type of the module that writes to the con- verter channel, as well as up to two additional data types for the modules that read from this channel. The MoC of the reading modules can be deter- mined automatically by the interface that is implemented by the respective port. Nicolescu/Model-Based Design for Embedded Systems 67842_C018 Finals Page 597 2009-10-1 Design Refinement of Embedded Mixed-Signal Systems 597 Module MoC 1 Module MoC 1 Module MoC 1 Module MoC 2 Module MoC 2 Module MoC 3 Converter Data type DT 1 Data type DT 2 Data type DT 1 Data type DT 1 Data type DT 1 Data type DT 3 Input signal Output signal 3 Output signal 2 Output signal 1 MoC 1 MoC 1 DT 1 DT 2 Converter MoC 1 MoC 2 DT 1 DT 1 Converterchannel < MoC 1 , DT 1 , DT 2 , DT 3 > Converter MoC 1 MoC 3 DT 1 DT 3 FIGURE 18.6 Internal structure of a converter channel connected to multiple reading modules. The converter channel then instantiates the appropriate signal(s) for the writing module and the reading module(s), together with converter modules that do the actual conversion work (see Figure 18.6). In the case of TDF→DE conversion, for example, the respective converter module will utilize the con- verter port described above. If the data types are different, the converter module will also perform the data-type conversion. As an option, the con- verter channel can also scale the input data, for example when converting double values to data types such as sc_uint<n>. In this case, the user passes the expected input range to the converter channel, such that this range is scaled to the natural range of the target data type, while clipping every input data out of bounds. Therefore, the converter channel can completely replace the simple A/D converter from Example 18.2. Besides the conversion work, the converter channel can also be used for “integration validation.” It can check, for example, if a DE input is under sampled when converting to TDF, which can occur if the DE input changes more frequently compared to the sample rate of the TDF reader. Also, the converter channel can check and handle some corner cases in process net- work (PN) ↔ TDF conversion (see [11]). Finally, data type conversion issues such as overflow are detected. 18.4 Simple Example for a Refinement Step Using Converter Channels In this section, we present an example that illustrates a single refine- ment step in the design of a software defined radio (SDR). An overview Nicolescu/Model-Based Design for Embedded Systems 67842_C018 Finals Page 598 2009-10-1 598 Model-Based Design for Embedded Systems Sine rf_in Mixer Mixedsig Converter channel Lowpass (TDF or ELN) Demodulate_an Network (ELN) or behavioral model (TDF) Software (DE or PN) Demodulate_sw 1p_out 1 3 2 4 TDF-signal FIGURE 18.7 A refinement example: SW-defined radio. of a simple SDR system is shown in Figure 18.7. The RF input signal is mixed with a sine wave of the same frequency as the carrier signal and the result is processed by a lowpass filter. After that, the demodu- lation follows. For demodulation, different realizations are possible: The most power efficient implementation is pure hardware (A/D) and the most flexible one considering support for different standards is the pure software realization. Usually, a compromise between these two realiza- tions has to be found considering flexibility, accuracy/bit width/bit error rate (BER), power consumption, and required computing performance (costs). The evaluation of the architecture variants necessitates the study of an overall system. Starting with a pure functional model, a refinement step could, for example, replace the TDF modulator with a model using the DE MoC. More general, the A/D/SW partitioning could be altered successively and the results could be compared until evaluation yields acceptable results. These refinement steps can be modeled efficiently using converter channels because they automatically adopt data types and model of computation. As a simple example for some refinement steps, we use the simple SDR concept as illustrated by Figure 18.7. The input of the software demodulator is an integer with fixed bit width. Example 18.3 shows the corresponding top-level SystemC code using two converter channels. bitwidth=8; sca_tdf::sca_signal<double> rf_in; // incoming RF-signal sca_tdf::sca_signal <double> sine; // sine waverf_in converterchannel<TDF, double> mixedsig; // RF-signal multiplied with sine-wave converterchannel<TDF,double, sc_int<bitwidth>>lp_out; // output of lp-filter lp_out.setRangeScaling( -1. , 1. ); // assuming the value range within [-1,1] Nicolescu/Model-Based Design for Embedded Systems 67842_C018 Finals Page 599 2009-10-1 Design Refinement of Embedded Mixed-Signal Systems 599 mixer mix("mix"); // mixes the two input signals mix.in1(rf_in); mix.in2(sine); mix.out(mixedsig); lowpass_behavioural lp("lp"); // lowpass filter, either T-SDF-module lp.in(mixedsig); // or electrical network lp.out(lp_out); demodulate_sw dem_sw("dem_sw", bitwidth); // software demodulator with dem_sw.in(lp_out); // sc_int<bitwidth> input demodulate_an dem_an("dem_an"); // analogue demodulator dem_an.in(lp_out); Example 18.3 SW-defined radio with converter channels Regarding design space exploration and mixed level simulation, this example gives rise to the following tasks (the numbers refer to those in Figure 18.7): 1. Realizing the lowpass filter either as a (behavioral) TDF-module or as an elec- trical network. 2. Realizing the software demodulator either as a PN or as a DE module. 3. Varying the bit width of the input of the software demodulator. 4. Realizing the analog demodulator either as a (behavioral) TDF-module or as an electrical network. To further complicate matters, any subset of these tasks can be performed in parallel. It is clear that the effort for manually inserting (and adapting) the appropriate converters would be significant. For example, assume an initial model with the lowpass filter and the analog demodulator modeled as TDF modules and the software demodulator modeled within the PN MoC, taking sc_int<bitwidth> inputs. We then would need a TDF→PN converter from the output of the lowpass filter to the software modulator, which would also convert double values to sc_int<bitwidth> values. Now, executing the tasks above would require the following manual conversion steps (in addition to the design of ELN modules itself): 1. Realizing the lowpass filter as an electrical network: I. Insert a TDF→ELN converter between the mixer and the low- pass filter. II. Replace the initial TDF→DE converter by an ELN→DE con- verter, which also converts physical sizes in double precision to sc_int<bitwidth>. III. Instantiate appropriate signals to connect the TDF→ELN con- verter with the ELN→KPN converter. 2. Realizing the software demodulator as a DE module: Replace the ini- tial TDF→DE converter by a TDF→DE converter, which also converts Nicolescu/Model-Based Design for Embedded Systems 67842_C018 Finals Page 600 2009-10-1 600 Model-Based Design for Embedded Systems double to sc_int<bitwidth>. Note, that using a SystemC AMS converter port makes no sense here since the analog demodulator is still in the TDF domain. Instantiate appropriate signals to connect them. 3. Varying the bit width of the input of the software demodulator: Change the output of the TDF→DE converter and the type of the signal that connects it to the software demodulator to sc_int<new_bitwidth>.The data-type conversion algorithm of the converter must also be altered slightly. Note, that a converter that takes the bitwidth as parameter would alleviate the design effort. 4. Realizing the analog demodulator as an electrical network: Insert a TDF→ELN converter between the lowpass filter and the analog demod- ulator. Instantiate an appropriate signal to connect them. Obviously, steps 1–4 are a significant effort for a design engineer and there- fore are against the principle of interactive, iterative refinement. By using converter channels, however, the code for each of the possible variants would be very similar to the code in Example 18.3. The value of the variable bitwidth would change as well as the class names of the respective mod- ules (e.g., changing lowpass_behavioral to lowpass_electrical). This simple example shows the convenience that converter channels offer to the design engineer. 18.5 Conclusion and Outlook With the AMS extensions, SystemC becomes amenable to modeling HW/SW systems and—at functional and architecture level—analog and mixed-signal subsystems. The intended use cases include executable specification, archi- tecture exploration, virtual prototyping, and integration validation. We have described a methodology that efficiently uses the AMS extensions together with the newly introduced converter channels. To support it the concept of a converter channel has been introduced. It is desirable to incorporate an even more abstract view into the method- ology, namely Transaction Level Modeling (TLM) [2], which allows design engineers to perform abstract modeling, simulation, and design of HW/SW system architectures. The idea of TLM is to abstract away the low-level events occurring in bus communication into a singledata object called “trans- action,” that is passed from process to process by method calls. TLM not only enables early software development, but also enhances simulation perfor- mance. Recently, the OSCI released the TLM 2.0 standard [13], and an exten- sion library with facilities for TLM (mainly method interfaces and a standard transaction object, the “generic payload”). Parts of the standard are cod- ing guidelines for different coding styles. Especially the “loosely timed cod- ing” style contains state of the art simulation techniques for fast simulation. Nicolescu/Model-Based Design for Embedded Systems 67842_C018 Finals Page 601 2009-10-1 Design Refinement of Embedded Mixed-Signal Systems 601 By allowing processes to run ahead of global simulation time (temporal decoupling) locally, context switches can be reduced, which increases sim- ulation performance, possibly for the price of a lower simulation accuracy. In [14], an early approach was presented to couple loosely timed TLM models with models using the AMS extensions. It was shown that the loosely timed modeling style of TLM 2.0 can be exploited efficiently to fit with the AMS extensions TDF MoC, preserving the high simulation performance of both the simulation approaches. The key idea there emerged from the obser- vation that TDF processes also run ahead of the SystemC simulation time (see Figure 18.4). Therefore, it is possible to set up converters that incorpo- rate both temporal decoupling effects as well as trigger synchronization only when needed. With an efficient TLM-AMS extensions coupling available, the first step is implemented for an integrated E-AMS systems refinement approach using TLM and AMS extensions. References 1. IEEE Std. 1666–2005. IEEE Press, New York. 2. F. Ghenassia (editor), Transaction Level Modeling with SystemC, Springer, Dordrecht, the Netherlands, 2005. 3. The MathWorks R  Simulink R  , http://www.mathworks.com/products/ simulink 4. 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, v.91, No. 1, pp. 127–144, January 2003. 5. IEEE Std. 1076.1-2007. IEEE Press, New York. 6. Accellera: Verilog-AMS Language Reference Manual Version 2.2, 2004. Analog & Mixed-Signal Extensions to Verilog HDL; http://www.verilog.org/verilog-ams/ 7. OSCI AMS Working Group, SystemC AMS extensions Requirements Speci- fication, 2007. 8. A. Vachoux, C. Grimm, and K. Einwich, SystemC extensions for hetero- geneous and mixed discrete/continuous systems. In: International Sym- posium on Circuits and Systems 2005 (ISCAS ’05), Kobe, Japan, May 2005. IEEE Press, New York. 9. C. Grimm, Modeling and refinement of mixed signal systems with SystemC. In: SystemC: Methodologies and Applications, Kluwer Academic Publisher (KAP), Norwell, MA, June 2003. Nicolescu/Model-Based Design for Embedded Systems 67842_C018 Finals Page 602 2009-10-1 602 Model-Based Design for Embedded Systems 10. R. Schroll, Design komplexer heterogener Systeme mit Polymorphen Signalen. PhD thesis, Institut für Informatik, Universität Frankfurt, Germany, 2007. 11. M. Damm, F. Herrera, J. Haase, E. Villar, and C. Grimm, Using converter channels within a top-down design flow in SystemC. In: Proceedings of the Austrochip 2007, Graz, Austria, 2007. 12. C. Grimm, M. Barnasconi, A. Vachoux, and K. Einwich, An introduc- tion to modeling embedded analog/mixed-signal systems using Sys- temC AMS extensions. OSCI, June 2008. www.systemc.org 13. Open SystemC Initiative. OSCI TLM2.0 standard, June 2008. http://www.systemc.org 14. M. Damm, C. Grimm, J. Haase, A. Herrholz, and W. Nebel, Connecting Systemc-AMS models with OSCI TLM 2.0 models using temporal decou- pling. In: Proceedings of the Forum on Specification and Design Languages (FDL), Stuttgart, Germany, 2008. 15. N. Wirth, Program development by stepwise refinement. Communica- tions of the ACM, 14 (1971), S. 221–227. 16. J. Romberg and C. Grimm, Refinement of hybrid systems from formal models to design languages. In C. Grimm (editor), Languages for System Specification, Kluwer Academic Publisher: Dordrecht, Boston, New York, London, 2004. 17. M. Fowler, Refactoring: Improving the Design of Existing Code, Addison- Wesley, London. Nicolescu/Model-Based Design for Embedded Systems 67842_C019 Finals Page 603 2009-10-14 19 Platform for Model-Based Design of Integrated Multi-Technology Systems Ian O’Connor CONTENTS 19.1 Rationale for Multi-Technology Design Exploration 603 19.2 Rune II Platform 608 19.2.1 Abstraction Levels 612 19.2.1.1 Model for Synthesizable AMS/MT IP 614 19.2.2 UML/XML Implementation 618 19.3 Multi-Technology Design Exploration Application: Integrated OpticalInterconnect 622 19.3.1 Models for the Simulation and Synthesis of an Optical Link 622 19.3.2 Optical Point-to-Point Link Synthesis 623 19.3.3 Performance Metrics and Specification Sets 630 19.4 Integrated Optical Interconnect Investigation Program and Results 631 19.4.1 Gate Area Analysis 632 19.4.2 Delay Analysis 632 19.4.3 Power Analysis 634 19.5 Conclusions and Ideas for the Future 638 Acknowledgment 640 References 640 19.1 Rationale for Multi-Technology Design Exploration Until recently, the single recognized vector enabling the improvement of the silicon system performance was perceived to be the progressive reduction (scaling) in CMOS device dimensions. Popularly known as Moore’s law, this trend will lead to the emergence of transistors of physical gate lengths of 10–18 nm in the 2010–2015 timeframe, according to the predictions of the ITRS. ∗ Consequently, the complexity of systems on chip (SoC) will reach unprecedented levels (high-performance microprocessors already contain over 10 9 transistors). However, the pursuit of Moore’s law through scal- ing will meet significant future, intrinsic device hurdles (such as leakage, ∗ International Technology Roadmap for Semiconductors (http://www.itrs.net/). 603 Nicolescu/Model-Based Design for Embedded Systems 67842_C019 Finals Page 604 2009-10-14 604 Model-Based Design for Embedded Systems interconnect, static power, quantum effects) to the capability of realizing system architectures using CMOS transistors with the performance lev- els required by future applications. It is recognized that these limitations, as much fundamental as economic, require the semiconductor industry to explore the use of novel devices able to complement or even replace the CMOS transistor in SoC within the next decade. Hence, from the miniaturization of existing systems (position sensors, labs on chip, etc.) to the creation of specific integrated functions (memory, radio frequency (RF) tuning, energy, etc.), nanoscale and nonelectronic devices are being integrated to create nanoelectronic and heterogeneous systems in pack- age (SiP), SoC, and 3D integrated circuits. This approach for future systems will have significant impact on several economic sectors, and is driven by • The need for the miniaturization of existing systems to benefit from technological advances and improve performance at lower overall cost • The potential replacement of specific functions in SoC/SiP with nanoscale or nonelectronic devices (nanoswitches, optical interconnect, magnetic memory, etc.) • The advent of high-performance user interfaces (virtual surgical oper- ations, games consoles, etc.) • The rise of low-power mobile systems (communications and mobile computing) and wireless sensor networks for the measurement of phe- nomena inaccessible to single-sensor systems In fact, the maturity and necessary diversification of integration technologies mean that three research directions are now open, as shown in Figure 19.1, an extended version of ENIAC ∗ ’s vision: “More Moore” (continued scaling); “More than Moore” (diversification); “Beyond Moore” (alternative devices). While “More Moore” focuses on the pursuit of traditional scaling for com- putation, “More than Moore” enables interaction with the real world and also system performance improvement through “equivalent” scaling with unconventional devices. It is clear that future SoC will be based on increas- ingly complex and diversified integration technologies in order to achieve unprecedented levels of functionality. While the general benefits of heterogeneous integration appear to be clear, this evolution represents a strong paradigm shift for the semiconductor industry. This shift toward diversification and away from the scaling trend that has lasted over 40 years is possible because the integration technology (or at least the individual technological steps) exists to do so [ROO2005]. However, the capacity to translate system drivers into technology require- ments (and consequently guidance for investment) to exploit such diversi- fication is severely lacking. Such a role can only be fulfilled by a radical shift in design technology to address the new and vast problem of hetero- geneous system design while remaining compatible with standard “More ∗ European Nanoelectronics Initiative Advisory Council (http://www.cordis.lu/ist/eniac). Nicolescu/Model-Based Design for Embedded Systems 67842_C019 Finals Page 605 2009-10-14 Platform for Model-Based Design of Integrated Multi-Technology Systems 605 System technologies Baseline CMOS Memory More Moore More than Moore Sense interact empower Nondigital content multilevel heterogeneous integration (SiP or 3DSIC) Physical heterogeneity System miniaturisation (wireless sensor networks, ambient intelligence, labs on chip, etc.) specific functions (MEMS resonators, optical interconnect, etc.) Compute store Digital content complex design (SoC) Evolutionary technologies, massive complexity MoC and abstraction level heterogeneity RF Passives HV power Sensors actuators Biological fluidics (a) (b) Design technologies Architectural improvement vector Multidomain improvement vector Economic and physical obstacles More Moore technological and physical constraints Design methods and tools Complexity RF and AMS sensor and actuator The function view combining two worlds: HW and SW yet with very different design paradigms + HdSW Reduced physical dimensionsFull system in a package FIGURE 19.1 (a) ENIAC’s vision of future integration technology diversification in the semiconductor industry. (b) The impact of technology diversification impact on design technology. (Adapted from ENIAC (European Nanoelectronics Initiative Advisory Council) SRA2007, http://www.eniac.eu.) . Norwell, MA, June 2003. Nicolescu /Model-Based Design for Embedded Systems 67842_C018 Finals Page 602 2009-10-1 602 Model-Based Design for Embedded Systems 10. R. Schroll, Design komplexer heterogener. Improving the Design of Existing Code, Addison- Wesley, London. Nicolescu /Model-Based Design for Embedded Systems 67842_C019 Finals Page 603 2009-10-14 19 Platform for Model-Based Design of Integrated. Technology Roadmap for Semiconductors (http://www.itrs.net/). 603 Nicolescu /Model-Based Design for Embedded Systems 67842_C019 Finals Page 604 2009-10-14 604 Model-Based Design for Embedded Systems interconnect,

Ngày đăng: 03/07/2014, 17:21

TỪ KHÓA LIÊN QUAN