Model-Based Design for Embedded Systems- P22 pot

Nicolescu/Model-Based Design for Embedded Systems 67842_C019 Finals Page 606 2009-10-14 606 Model-Based Design for Embedded Systems Moore” flows, that is, capable of simultaneously handling both “silicon complexity” and “system complexity.” Designing in the context of increased silicon complexity (i.e., the number of individual elements) is managed through the development of methods capable of handling multiple abstrac- tion levels and models of computation; while increased system complexity (i.e., number of different domains or concepts) requires that methods inte- grating other physical domains be developed. The urgency of this function- ality for current SoC/SiP design flows is only too apparent from the data available from the ITRS (see Table 19.1), where it is clear that the earliest bottlenecks stem from the integration of heterogeneous content. The field of designmethods, in general terms, is a vibrant field of research, and is often applied to the management of design, production, logistics, and maintenance processes for complex systems in the aeronautic, transport, and civil engineering sectors, to name but a few. The microelectronics industry, over the years and with its spectacular and unique evolution, has built its own specific design methods while focusing mainly on the management of complexity through the establishment of abstraction levels. Today, the emergence of device heterogeneity requires a new approach, and no existing toolhasthenecessaryarchitecturetoenablethesatisfactorydesignofphysically heterogeneous embedded systems. The development of such software tools is a critical step to enable the widespread deployment of such systems. The main objective of such an evolution is to reduce the design time in order to meet time to volume constraints. It is widely recognized that for complex systems at advanced technology nodes, a radical evolution in design tools and methods is required to reduce the “design productivity gap.” Production capacity increases annually by around 50%, while design capacity increases annually by a rate of only 20%–25% [ITR2007]. All ITRS Roadmaps (and intermediate updates) since 2003 clearly state that “Cost [of design] is the greatest threat to continuation of the semiconductor roadmap. Today, many design technology gaps are crises,” and identify this topic as one of the three main challenges to system design in the current post–45 nm era. It is clearly expressed that these “New technologies will require new modeling approaches, new types of creation and integration guidelines and rules, and, depending on the numbers of such design starts, may foster whole new toolsets.” The issues pertaining to heterogeneous systems design methods and associated tools thus form part of the spectrum of highly rele- vant and long-term research topics. The European Commission also stresses the importance of design technology for nanoelectronic architectures of the future ∗ : “There will be a need for new design approaches that make it pos- sible to reuse designs easily when new generations or families of products appear. These approaches should be coupled with automatic translation of the resulting high-level designs into device manufacture.” ∗ “Vision 2020—Nanoelectronics at the centre of change” http://cordis.europa.eu/ nanotechnology. Nicolescu/Model-Based Design for Embedded Systems 67842_C019 Finals Page 607 2009-10-14 Platform for Model-Based Design of Integrated Multi-Technology Systems 607 TABLE 19.1 Selected Design Technology Bottleneck Predictions Year of Production 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 DRAM half-pitch (nm) 68 59 52 45 40 36 32 28 25 22.5 20 17.9 15.9 14.2 12.6 11.3 Design block reuse (% to all logic size) 35 36 38 40 41 42 44 46 48 51 52 Accuracy of high-level estimates (% vs. measurements) 60 63 66 70 73 76 80 83 86 92 94 SoC recongurability (% of SoC functionality recongurable) 28 28 30 35 38 40 42 45 48 53 56 AMS automation (% vs. digital automation) 17 17 24 24 27 30 32 35 38 43 46 AMS modeling methodology (% vs. digital methodology) 58 60 62 65 67 70 73 76 78 83 86 Parameter uncertainty (% effect (on signoff delay)) 6 8 10 11 11 12 14 15 18 20 20 Simultaneous analysis objectives (# objectives during optimization) 456666788 88 Synthesized AMS content (% of total design analog content) 15 16 17 18 19 20 23 25 28 35 40 38 40 41 42 44 46 48 49 51 54 55 57 58 70 73 76 80 83 86 90 92 95 97 99 100 35 38 40 42 45 48 50 53 60 62 65 68 17 24 27 30 32 35 38 40 43 50 52 55 58 65 67 70 73 76 78 80 83 90 92 95 98 15 18 20 20 22 25 26 28 566667888 8 888 8 25 28 30 35 45 50 55 60 Manufacturable solutions exist, and are being optimized. Manufacturable solutions are known. Interim solutions are known. Manufacturable solutions are not known. Source: ITRS, Sematech, 2007, http://www.itrs.net. Nicolescu/Model-Based Design for Embedded Systems 67842_C019 Finals Page 608 2009-10-14 608 Model-Based Design for Embedded Systems Without the introduction of new design technology, design cost becomes prohibitive and leads to weak integration of high added value devices (such as sensors and RF circuits) for the various application sectors (automotive/- transport, biomedical, telecommunications, etc.). A high-level vision of the maturity of existing abstraction levels for various physical domains is given in Table 19.2, with examples of adequate modeling languages or simulation engines where solutions exist. To achieve design technology capable of fully exploiting the potential of heterogeneous SoC/SiP in a holistic approach, high-level modeling tech- niques capable of covering more physical domains should be developed, and cosimulation/cosynthesis methods and tools should aim to cover more abstraction levels. It is consequently clear that the impact of heterogeneity on design flows is or will be high, and necessary to facilitate heterogeneous device integration in SoC/SiP. This chapter is structured as follows. We first describe the architecture and philosophy of the RUNE II platform for the development of predictive design methods and tools for heterogeneous SoC, in a “More than Moore” context. We focus specifically on the design process, on the use of specific abstraction levels in the process and how design information can be cap- tured in a model for synthesizable analog and mixed-signal (AMS)/multi- technology (MT) intellectual property (IP), implemented in a high-level Unified Modeling Language (UML)/Extensible Markup Language (XML) framework. This design technology is applied to the exploration of an MT example: The elaboration of novel integrated optical interconnect schemes in the context of heterogeneous 3D integration. We focus on the use of a pho- tonic interconnect layer enabled by 3D integration, and on the quantitative exploration of how such an approach can improve performance metrics of on-chip communication systems. We cover the establishment of functional and structural models for the simulation and synthesis of an optical link, and develop a method for optical point-to-point link synthesis. The investigation program, defined with respect to a set of performance metrics such as gate area, delay, and power, is shown to give uniquely detailed results for this new technology. Finally, some ideas will be given for the future evolution of integrated SoC and for the requirements for design technology to accompany this evolution. 19.2 Rune II Platform The ongoing Rune II project ∗ aims at researching novel design methods capa- ble of contributing to the management of the increasing complexity of the ∗ http://sourceforge.net/projects/runeii. Nicolescu/Model-Based Design for Embedded Systems 67842_C019 Finals Page 609 2009-10-14 Platform for Model-Based Design of Integrated Multi-Technology Systems 609 TABLE 19.2 Abstraction Levels for Various Physical Domains and Related Modeling Languages Domain Software Digital Analog Radiofrequency Mechanical Optical Fluidic Chemical Level of Abstraction Transaction SystemC/UML SystemVenilog SystemC Macro-architecture SystemC SystemVerilog Micro-architecture SystemC/VHDL SystemVerilog Ptolemy/Matlab/SystemC-AMS SystemC Matlab Block VHDL RF simulation / VHDL- AMS VHDL- AMS Circuit Electrical simulation RF simulation VHDL- AMS VHDL- AMS Physical Finite elements methods Finite difference FEMLab Analytical Manufacturable solutions exist, and are being optimized. Manufacturable solutions are known. Manufacturable solutions are NOT known. Nicolescu/Model-Based Design for Embedded Systems 67842_C019 Finals Page 610 2009-10-14 610 Model-Based Design for Embedded Systems SoC/SiP design process because of growth in both silicon complexity and in system complexity. As indicated above, current design technology is at its limits. It is in particular incapable of allowing any exploration of high- and low-level design tradeoffs in systems comprising digital hardware/software components and multiphysics devices (e.g., instruction line or software argu- ments against sensor or device characteristics). Such functionality is required to design (for example) systems in which power consumption is critical. The ultimate overall goals of the platform include • The definition and development of a coherent design process for het- erogeneous SoC/SiP capable of effectively managing the whole of the heterogeneous design stages—through multiple domains and abstrac- tion levels. A primary objective is to make clear definitions of the levels of abstraction, the associated design and modeling languages, and the properties of the objects at each level, whatever their natures (software components, digital/AMS/RF/multiphysics hardware). We consider it to be necessary to clearly define the scheduling of the design stages (which one can also regard as transformation actions applied to the various components) in an approach of “V-cycles” or “spiral” type, as well as the rules necessary for the validation of each stage. This makes it possible to establish the logistics of the design process, in particular for actions that could be carried out in parallel, and to take a first step toward a truly holistic design flow including economic and contextual constraints. • The heterogeneous specification of the system by high-level modeling and cosimulation approaches; as well as the establishment of methods for executable high-level specifications of SoC/SiP including AMS and multiphysics components. The rationale for this is to allow the analysis of design criteria early in the design cycle. • The extension of current hardware/software partitioning processes to nondigital hardware. Methods to formalize power, noise, silicon real estate, and uncertainty estimation in AMS and multiphysics compo- nents need to be developed, thus allowing the estimation of feasibility as critical information for the partitioning process. Although this infor- mation is intrinsically related to the implementation technology, efforts need to be made to render the formulation of information as qualita- tive as possible (thus circumventing the need to handle, in the early stages of the design process, the necessary numerical transposition to the technology). This formulation is employed to enrich the high-level models in the system. • The development of hierarchical synthesis and top-down exploration methods, coherent with the design process model mentioned above, for SoC/SiP comprising multiple levels of abstraction and physical domains. Synthesis information for AMS/MT components is formal- ized and added to behavioral models as a basis for synthesizable AMS/MT IP, and developed tools exploit this information and are Nicolescu/Model-Based Design for Embedded Systems 67842_C019 Finals Page 611 2009-10-14 Platform for Model-Based Design of Integrated Multi-Technology Systems 611 intended to guarantee the transformation of the system specifications into a feasible set of components specified at a lower (more physi- cal) hierarchical level. Since multiple levels of abstraction are implied in the process, it is necessary to clearly specify bridges between the levels (through performance-based partitioning and synthesis). Here again, technology independence is a key point for the establishment of a generic approach, and makes it possible to generate predictive infor- mation when the approach is coupled with device models at future technology nodes. • The validation of design choices using model extraction and cosim- ulation techniques. This relates to a bottom-up design process and requires model order reduction techniques for the modeling of non- electronic components (including the management of process and environmental variability), as well as the abstraction of time at the sys- tem level. This opens the way to the development of formal verification methods for AMS/MT to supplement the design flow for “More than Moore” systems. These concepts contribute to our vision of a high-level design flow embod- ied in an experimental design platform for heterogeneous SoC/SiP, shown in Figure 19.2. The ultimate goal is to enable the concurrent handling of hardware/software and AMS/MT components in architectural exploration. As shown in Figure 19.2, there is a clear bridge between system-level and physical-level (or domain-specific) phases of design—in our view this bridge System-level IP repository System model HW+SW +AMSMT data models Domain-specific IP repository User Cockpit Autopilot Power Robustness Feasibility Cost Estimate Performance Power Timing Variability Placement Analyze HW AMSMT SW Interconnect Packaging Optimize Function Domain Specifications Define FIGURE 19.2 Target SoC/SiP design flow. Nicolescu/Model-Based Design for Embedded Systems 67842_C019 Finals Page 612 2009-10-14 612 Model-Based Design for Embedded Systems is critical to setting up a continuum of abstraction levels between system and physical design, enabling detailed analysis of cross-domain tradeoffs and the correct balancing of constraints over the various domains, and hence the achievement of optimally designed heterogeneous systems. The main impact would be to combat the current inefficiency in design processes between (1) the apriorigeneration of component specification sets at the system level in the presence of uncertainty concerning the feasibility of these sets in the tar- get technology and (2) the a posteriori evaluation of the differences between specified and real component performance levels, generated at the physical level in the presence of uncertainty of their impact and potential degrees of freedom available at the system level. Learning systems can of course capi- talize on the repeated use of estimation, optimization, and analysis to refine the accuracy of predictions. A typical example of where such exploration would be required is in the optical interconnect demonstrator: based on software application con- straints, system optimization requires the analysis of tradeoffs between (for example) (1) the number of cores (and parallel software tasks) that can be linked efficiently by optical interconnect to reduce the power contribution of the data processing part of the application and (2) the technology char- acteristics leading to a specific data rate/power ratio and the power con- tribution of the data communication part of the application. Hence such design technology can also be viewed as a high-level guide for design management. In this section, we will first focus on a preliminary definition of abstrac- tion levels and how they fit into a model for the design process. We will then consider the various elements pertaining to heterogeneous components required for the design process at various abstraction levels, and formalize this in a model for synthesizable AMS/MT IP, which we then show how to implement in UML/XML. 19.2.1 Abstraction Levels The concept of abstraction levels is one that must be addressed for heteroge- neous SoC/SiP. Valid abstraction (i.e., when there is a clear and explicit path to simplify representation at a higher level for all considered objects) is diffi- cult to achieve when tightly coupled physical phenomena are present in the system—this is the case even for digital electronics at nanometric technol- ogy nodes, and the rise in AMS, RF, and heterogeneous content to address future application requirements compounds this problem. Efficient ways must be found to incorporate nondigital objects into design flows in order to ultimately achieve AMS/RF/heterogeneous/digital hardware/software codesign. While hierarchy in the digital domain is based on the levels of signal abstraction, AMS/MT hierarchy is typically based on structural decompo- sition. It is necessary to combine and represent both types of hierarchy for Nicolescu/Model-Based Design for Embedded Systems 67842_C019 Finals Page 613 2009-10-14 Platform for Model-Based Design of Integrated Multi-Technology Systems 613 Structural decomposition Structural aggregation m: Higher structural level n: Lower structural level Xy: Child block ID Top-down propagation Bottom-up extraction w: Higher abstraction level n: Lower abstraction level Mobility through abstraction levels Circuit Structural decomposition and aggregation 0_A f 0_A s 0_A b 0_A c 1_A f 2_A f 2_A s 2_A b 2_B b 2_B s 2_B f 2_C f 2_C s 2_C b 2_A c 2_B c 2_C c 1_A s 1_A b Block System 1_B b 1_B s 1_B f 1_A c 1_B c T01Bf T01Af Ny: Structural block ID Tfs0A Tfs1A Tfs1B T12Bf T12Cf T12Cs T12Cb T12Cc T12Af T12Bf T12As T12Bb T12Bc T12Ac T12Ab Tsb1B Tbc1B Tbc2A TwxNy TmnXy Tbc2B Tsb2B Tfs2B Tfs2C Tsb2C Tbc2C Tsb2A Tfs2A Tsb1A Tbc1A Tsb0A Tbc0A T01Ac T01Bc T01Ab T01Bb T01As T01Bs Function FIGURE 19.3 Modeling abstraction and structural hierarchies. heterogeneous synthesis processes: hierarchy based on levels of abstraction, and hierarchy based on structural decomposition. Figure 19.3 shows a Petri net style diagram [GIR2002] where the ovals (places) represent IP blocks with various levels of abstraction (F, functional/mathematical; S, system; B, block; C, circuit/component). A loose association between these levels and existing modeling languages can be established: MATLAB R ∗ /Simulink R † for the top two levels; Verilog-AMS for the block level; and SPICE/Spectre for the circuit/component level. In the diagram, the boxes situated on arcs between places at different abstraction levels represent transitions, and indi- cate the processes used to move between abstraction levels while preserving the properties of each block’s functionality. Structural decomposition can be represented by a set of transitions from one block to several other blocks (usually at the same abstraction level) and is also represented in Figure 19.3. For example, 0_A is the overall system to be designed and is comprised of components 1_A and 1_B. 1_B can be fur- ther decomposed into 2_A, 2_B, and 2_C. As can be seen from the diagram, some places (with dotted lines) are not accessible: at the functional level, this concerns 2_{A,B,C} f and illustrates the nonrepresentativity of strong physical ∗ http://www.mathworks.com/products/matlab. † http://www.mathworks.com/products/simulink. Nicolescu/Model-Based Design for Embedded Systems 67842_C019 Finals Page 614 2009-10-14 614 Model-Based Design for Embedded Systems coupling between IP blocks at this abstraction level; and at the circuit level, it concerns 0_A c , illustrating the nonsimulability of the overall system at circuit level. It is worth noting that while single direction transitions are the usual rep- resentation in this type of diagram, we have for simplicity here merged both structural transitions (decomposition and aggregation) and abstraction level transitions (top-down propagation, or “refinement,” and bottom-up extrac- tion, or “abstraction”). This approach enables clarification of the available/necessary steps in the design process. It is quite clear that several routes exist to achieve com- plete top-down synthesis of each individual component in the system, and conversely several routes enable the bottom-up validation of the whole (the top-down and bottom-up routes do not necessarily pass through the same places). 19.2.1.1 Model for Synthesizable AMS/MT IP Most analog and RF circuits are still designed manually today, resulting in long design cycles and increasingly apparent bottlenecks in the overall design process [GIE2005]. This explains the growing awareness in indus- try that the advent of AMS/MT synthesis and optimization tools is a nec- essary step to increase design productivity by assisting or even automating the AMS/MT design process. The fundamental goal of AMS/MT synthesis is to generate quickly a first-time-correct sized circuit schematic from a set of circuit specifications. This is critical since the AMS/MT design problem is typically under-constrained with many degrees of freedom and with many interdependent (and often conflicting) performance requirements to be taken into account. Synthesizable (soft) AMS IP [HAM2003] extends the concept of digital and software IP to the analog domain. It is difficult to achieve because the IP hardening process (moving from a technology-independent, structure- independent specification to a qualified layout of an AMS/MT block) relies to a large extent on the quality of the tools being used to do this. It is our belief that a clear definition of AMS/MT IP is an inevitable requirement to pro- vide a route to system-level synthesis incorporating AMS/MT components. Table 19.3 summarizes the main facets necessary to AMS/MT IP, where each constituent element of design information is identified and the role of each is described. Figure 19.4 shows how these various facets of AMS/MT IP should be brought together in an iterative single-level synthesis loop. This represents “structural” decomposition transitions. First, the set S of the performance criteria, originating from the higher hierarchical structural level n + 1in Figure 19.4, is used to quantify how the IP block should carry out the defined function. Performance criteria are composed of functional specifi- cations and performance specifications: for example in an amplifier, S will Nicolescu/Model-Based Design for Embedded Systems 67842_C019 Finals Page 615 2009-10-14 Platform for Model-Based Design of Integrated Multi-Technology Systems 615 TABLE 19.3 AMS/MT IP Block Facets Property Short Description Function definition Class of functions to which the IP block belongs. Performance criteria set S Quantities necessary to specify and to evaluate the IP block. Terminals Input/output links to which other IP blocks can connect. Structure Internal component-based structure of the IP block. Design variable set V List of independent design variables to be used by a design method or optimization algorithm. Physical parameter set P List of physical parameters associated with the internal components. Evaluation method ∗ e Code defining how to evaluate the IP block, that is, transform physical parameter values to performance criteria values. Can be equation or simulation based (the latter requires a parameter extraction method). Parameter extraction method Code defining how to extract performance criteria values from simulation results (simulation-based evaluation methods only). Synthesis method ∗ m Code defining how to synthesize the IP block, that is, transform performance criteria requirements to design variable values. Can be procedure- or optimization based. Constraint distribution method ∗ c Code defining how to transform IP block parameters to specifications at a lower hierarchical level. contain gain (the single functional specification), bandwidth, power supply rejection ratio, offset, etc. They have two distinct roles, related to the state of the IP block in the design process. • As block parameters when the IP block is a component of a larger block, higher up in the hierarchy, in the process of being designed. In this case it can be varied and must be constrained to evolve within a given design space, i.e., s low_i < s i < s high_i . • As specifications when the IP block is the block in the process of being designed (such as here). In this case the value s i is a fixed target and will be used to drive the design process through comparison with real performance values s ri . Several possibilities exist to construct an error function ε, the most common being a sum of n (the size of S) weighted [...]... defines general structure necessary for evaluation FIGURE 19.9 Definition of classes in UML for test benches, evaluation and synthesis scenarios for the integrated optical link Optical point to point link defines structure Generic link defines performance criteria Synthesizable (from interfaces) 628 Model-Based Design for Embedded Systems Platform for Model-Based Design of Integrated Multi-Technology... model Stimuli Constraint distribution method *c Synthesis method *m Design variables to physical parameter conversion method *r Evaluation and parameter extraction methods *e Physical parameters P Design variables V Performance criteria S Components of soft-IP library 616 Model-Based Design for Embedded Systems Platform for Model-Based Design of Integrated Multi-Technology Systems 617 (wi ∀i ∈ {0,n −... analog/RF architectural specification values for block-level synthesis in an optimal top-down approach by making reasoned architectural choices about the structure to be designed For general compatibility with system-level design flows, we chose to represent this aspect with UML UML 2.0, adopted as a standard by Object Management Platform for Model-Based Design of Integrated Multi-Technology Systems... efficiency:double{Total efficiency=0.0} #Bandwidth:double{Bandwidth>0.0} #Area:double{Area>0.0} #In:Electrical node #Oout:Optical node Source Platform for Model-Based Design of Integrated Multi-Technology Systems 625 626 Model-Based Design for Embedded Systems TABLE 19.4 Optical Device Parameters Source Parameter Min Value Max Value Units Total efficiency Area Threshold current Bandwidth 0.1 10... combinations of design variables as exploratory points in the design space according to *m:S→V The number of design variables defines the number of dimensions of the design space The design variables must be independent of each other, and as such represent a subset of IP block parameters (i.e., performance criteria, described above) in a structure definition For example, a differential amplifier design variable... 632 Model-Based Design for Embedded Systems The results obtained were compared to the performance of 1.1 μm pitch unshielded electrical interconnect, synthesized with another toolset and using the same specifications as drivers for the synthesis process [OCO2007] The simulation conditions were • Inverters (as buffers for each electrical interconnect segment) with a 2/1 PMOS-to-NMOS ratio were used • For. .. +selectTopology():void (choice of most suitable structure) +setPerformances():void (set up performance criteria vector) (b) FIGURE 19.6 (a) UML class diagram showing representation of hierarchical dependencies between AMS/MT IP blocks (b) UML class definitions for hierarchically dependent AMS/MT IP blocks 622 Model-Based Design for Embedded Systems each facet of the AMS/MT IP requirements set out... number is used for long links, it is still clear that the use of optical links will free up a large number of transistors for use in functions other than interconnect (data processing, memory, etc.) 19.4.2 Delay Analysis The link sizing method described in Section 19.3.2 was applied according to the specifications for the PTM 65, 45, and 32 nm technologies The 50% Platform for Model-Based Design of Integrated... two main ways: • Through direct code evaluation, such as for active surface area calculations • Through simulation (including behavioral simulation) for accurate performance evaluation (gain, bandwidth, distortion, etc.) If the IP 618 Model-Based Design for Embedded Systems block is not described in a modeling language that can be understood by a simulator, then this requires a gateway to a specific simulator... (http://www.eas.asu.edu/∼ptm/) Platform for Model-Based Design of Integrated Multi-Technology Systems 631 be carried out However in the sizing process this problem was circumvented by using the Morikuni formula to estimate noise at block level, as previously described • No automatic layout generation tools were used, as it is not in general possible to achieve optimal layout for high-speed analog circuits . Nicolescu /Model-Based Design for Embedded Systems 67842_C019 Finals Page 608 2009-10-14 608 Model-Based Design for Embedded Systems Without the introduction of new design technology, design cost. specifi- cations and performance specifications: for example in an amplifier, S will Nicolescu /Model-Based Design for Embedded Systems 67842_C019 Finals Page 615 2009-10-14 Platform for Model-Based Design of. solutions are NOT known. Nicolescu /Model-Based Design for Embedded Systems 67842_C019 Finals Page 610 2009-10-14 610 Model-Based Design for Embedded Systems SoC/SiP design process because of growth