Model-Based Design for Embedded Systems- P22 pot

To achieve design technology capable of fully exploiting the potential of heterogeneous SoC/SiP in a holistic approach, high-level modeling niques capable of covering more physical domai

Moore” flows, that is, capable of simultaneously handling both “siliconcomplexity” and “system complexity.” Designing in the context of increasedsilicon complexity (i.e., the number of individual elements) is managedthrough 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 dataavailable from the ITRS (see Table 19.1), where it is clear that the earliestbottlenecks stem from the integration of heterogeneous content.

The field of design methods, in general terms, is a vibrant field of research,and is often applied to the management of design, production, logistics, andmaintenance processes for complex systems in the aeronautic, transport, andcivil engineering sectors, to name but a few The microelectronics industry,over the years and with its spectacular and unique evolution, has built itsown specific design methods while focusing mainly on the management

of complexity through the establishment of abstraction levels Today, theemergence of device heterogeneity requires a new approach, and no existingtoolhasthenecessaryarchitecturetoenablethesatisfactorydesignofphysicallyheterogeneous 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 thatfor complex systems at advanced technology nodes, a radical evolution indesign tools and methods is required to reduce the “design productivitygap.” Production capacity increases annually by around 50%, while designcapacity increases annually by a rate of only 20%–25% [ITR2007] All ITRSRoadmaps (and intermediate updates) since 2003 clearly state that “Cost [ofdesign] 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 requirenew modeling approaches, new types of creation and integration guidelinesand rules, and, depending on the numbers of such design starts, may fosterwhole new toolsets.” The issues pertaining to heterogeneous systems designmethods and associated tools thus form part of the spectrum of highly rele-vant and long-term research topics The European Commission also stressesthe importance of design technology for nanoelectronic architectures of thefuture∗: “There will be a need for new design approaches that make it pos-sible to reuse designs easily when new generations or families of productsappear These approaches should be coupled with automatic translation ofthe resulting high-level designs into device manufacture.”

∗“Vision 2020—Nanoelectronics at the centre of change” http://cordis.europa.eu/nanotechnology.

Without the introduction of new design technology, design cost becomesprohibitive and leads to weak integration of high added value devices (such

as sensors and RF circuits) for the various application sectors transport, biomedical, telecommunications, etc.) A high-level vision of thematurity of existing abstraction levels for various physical domains is given

(automotive/-in Table 19.2, with examples of adequate model(automotive/-ing languages or simulationengines where solutions exist

To achieve design technology capable of fully exploiting the potential

of heterogeneous SoC/SiP in a holistic approach, high-level modeling niques capable of covering more physical domains should be developed,and cosimulation/cosynthesis methods and tools should aim to cover moreabstraction levels It is consequently clear that the impact of heterogeneity

tech-on design flows is or will be high, and necessary to facilitate heterogeneousdevice integration in SoC/SiP

This chapter is structured as follows We first describe the architectureand philosophy of the RUNEII platform for the development of predictivedesign methods and tools for heterogeneous SoC, in a “More than Moore”context We focus specifically on the design process, on the use of specificabstraction 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-levelUnified Modeling Language (UML)/Extensible Markup Language (XML)framework This design technology is applied to the exploration of an MTexample: The elaboration of novel integrated optical interconnect schemes inthe context of heterogeneous 3D integration We focus on the use of a pho-tonic interconnect layer enabled by 3D integration, and on the quantitativeexploration of how such an approach can improve performance metrics ofon-chip communication systems We cover the establishment of functionaland structural models for the simulation and synthesis of an optical link, anddevelop a method for optical point-to-point link synthesis The investigationprogram, defined with respect to a set of performance metrics such as gatearea, delay, and power, is shown to give uniquely detailed results for thisnew technology Finally, some ideas will be given for the future evolution ofintegrated SoC and for the requirements for design technology to accompanythis evolution

The ongoing RuneIIproject∗aims at researching novel design methods ble of contributing to the management of the increasing complexity of the

capa-∗http://sourceforge.net/projects/runeii.

VHDL- AMSVHDL- AMS

SoC/SiP design process because of growth in both silicon complexity and insystem complexity As indicated above, current design technology is at itslimits It is in particular incapable of allowing any exploration of high- andlow-level design tradeoffs in systems comprising digital hardware/softwarecomponents 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 erogeneous SoC/SiP capable of effectively managing the whole of theheterogeneous design stages—through multiple domains and abstrac-tion levels A primary objective is to make clear definitions of the levels

het-of abstraction, the associated design and modeling languages, and theproperties of the objects at each level, whatever their natures (softwarecomponents, 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 thevarious components) in an approach of “V-cycles” or “spiral” type, aswell as the rules necessary for the validation of each stage This makes

it possible to establish the logistics of the design process, in particularfor actions that could be carried out in parallel, and to take a first steptoward a truly holistic design flow including economic and contextualconstraints

• The heterogeneous specification of the system by high-level modelingand cosimulation approaches; as well as the establishment of methodsfor executable high-level specifications of SoC/SiP including AMS andmultiphysics 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 tonondigital hardware Methods to formalize power, noise, silicon realestate, 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 mation is intrinsically related to the implementation technology, effortsneed to be made to render the formulation of information as qualita-tive as possible (thus circumventing the need to handle, in the earlystages of the design process, the necessary numerical transposition tothe technology) This formulation is employed to enrich the high-levelmodels in the system

infor-• The development of hierarchical synthesis and top-down explorationmethods, coherent with the design process model mentioned above,for SoC/SiP comprising multiple levels of abstraction and physicaldomains Synthesis information for AMS/MT components is formal-ized and added to behavioral models as a basis for synthesizableAMS/MT IP, and developed tools exploit this information and are

intended to guarantee the transformation of the system specificationsinto 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 thelevels (through performance-based partitioning and synthesis) Hereagain, technology independence is a key point for the establishment of

a generic approach, and makes it possible to generate predictive mation when the approach is coupled with device models at futuretechnology nodes

infor-• The validation of design choices using model extraction and ulation techniques This relates to a bottom-up design process andrequires model order reduction techniques for the modeling of non-electronic components (including the management of process andenvironmental variability), as well as the abstraction of time at the sys-tem level This opens the way to the development of formal verificationmethods for AMS/MT to supplement the design flow for “More thanMoore” systems

cosim-These concepts contribute to our vision of a high-level design flow ied in an experimental design platform for heterogeneous SoC/SiP, shown

embod-in Figure 19.2 The ultimate goal is to enable the concurrent handlembod-ing ofhardware/software and AMS/MT components in architectural exploration

As shown in Figure 19.2, there is a clear bridge between system-level andphysical-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

Power Robustness Feasibility Cost Estimate

Performance

Power Timing

Variability Placement

Analyze HW

is critical to setting up a continuum of abstraction levels between system andphysical design, enabling detailed analysis of cross-domain tradeoffs andthe correct balancing of constraints over the various domains, and hence theachievement of optimally designed heterogeneous systems The main impactwould be to combat the current inefficiency in design processes between (1)

the a priori generation 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 physicallevel in the presence of uncertainty of their impact and potential degrees offreedom available at the system level Learning systems can of course capi-talize on the repeated use of estimation, optimization, and analysis to refinethe accuracy of predictions

A typical example of where such exploration would be required is inthe optical interconnect demonstrator: based on software application con-straints, system optimization requires the analysis of tradeoffs between (forexample) (1) the number of cores (and parallel software tasks) that can belinked efficiently by optical interconnect to reduce the power contribution

of the data processing part of the application and (2) the technology acteristics leading to a specific data rate/power ratio and the power con-tribution of the data communication part of the application Hence suchdesign technology can also be viewed as a high-level guide for designmanagement

char-In this section, we will first focus on a preliminary definition of tion levels and how they fit into a model for the design process We willthen consider the various elements pertaining to heterogeneous componentsrequired for the design process at various abstraction levels, and formalizethis in a model for synthesizable AMS/MT IP, which we then show how toimplement in UML/XML

diffi-to ultimately achieve AMS/RF/heterogeneous/digital hardware/softwarecodesign

While hierarchy in the digital domain is based on the levels of signalabstraction, AMS/MT hierarchy is typically based on structural decompo-sition It is necessary to combine and represent both types of hierarchy for

Structural decomposition

Structural aggregation

m: Higher structural level n: Lower structural level Xy: Child block ID

Top-down propagation Bottom-upextraction

w: Higher abstraction level n: Lower abstraction level

System

1_Bb1_Bs1_Bf

T01Bf T01Af

Ny: Structural block ID

Tfs0A

Tfs1A

Tfs1B T12Bf

T12Bb

T12Bc T12Ac T12Ab Tsb1B

Tbc1B

Tbc2A

TwxNy TmnXy

Tbc2B Tsb2B

Tfs2B

Tfs2C

Tsb2C

Tbc2C Tsb2A

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 Petrinet style diagram [GIR2002] where the ovals (places) represent IP blockswith various levels of abstraction (F, functional/mathematical; S, system; B,block; C, circuit/component) A loose association between these levels andexisting modeling languages can be established: MATLAB∗ R /Simulink† Rfor the top two levels; Verilog-AMS for the block level; and SPICE/Spectrefor the circuit/component level In the diagram, the boxes situated on arcsbetween places at different abstraction levels represent transitions, and indi-cate the processes used to move between abstraction levels while preservingthe properties of each block’s functionality

Structural decomposition can be represented by a set of transitions fromone 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 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, thisconcerns 2_{A,B,C}fand illustrates the nonrepresentativity of strong physical

fur-∗http://www.mathworks.com/products/matlab.

† http://www.mathworks.com/products/simulink.

coupling between IP blocks at this abstraction level; and at the circuit level, itconcerns 0_Ac, illustrating the nonsimulability of the overall system at circuitlevel.

It is worth noting that while single direction transitions are the usual resentation in this type of diagram, we have for simplicity here merged bothstructural transitions (decomposition and aggregation) and abstraction leveltransitions (top-down propagation, or “refinement,” and bottom-up extrac-tion, or “abstraction”)

rep-This approach enables clarification of the available/necessary steps inthe design process It is quite clear that several routes exist to achieve com-plete top-down synthesis of each individual component in the system, andconversely several routes enable the bottom-up validation of the whole (thetop-down and bottom-up routes do not necessarily pass through the sameplaces)

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 overalldesign 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 automatingthe 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 istypically under-constrained with many degrees of freedom and with manyinterdependent (and often conflicting) performance requirements to be takeninto account

Synthesizable (soft) AMS IP [HAM2003] extends the concept of digitaland software IP to the analog domain It is difficult to achieve because the

IP hardening process (moving from a technology-independent, independent specification to a qualified layout of an AMS/MT block) relies

structure-to a large extent on the quality of the structure-tools being used structure-to do this It is our beliefthat 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 eachconstituent element of design information is identified and the role of each isdescribed

Figure 19.4 shows how these various facets of AMS/MT IP should bebrought 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+ 1 inFigure 19.4, is used to quantify how the IP block should carry out thedefined function Performance criteria are composed of functional specifi-

cations and performance specifications: for example in an amplifier, S will

TABLE 19.3

AMS/MT IP Block Facets

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

blocks can connect

IP block

Design variable set V List of independent design variables to be

used by a design method or optimizationalgorithm

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 physicalparameter values to performance criteriavalues Can be equation or simulationbased (the latter requires a parameterextraction method)

Parameter extraction method Code defining how to extract

performance criteria values fromsimulation results (simulation-basedevaluation methods only)

Synthesis method∗m Code defining how to synthesize the IP

block, that is, transform performancecriteria requirements to design variablevalues Can be procedure- or

optimization based

Constraint distribution method∗c Code defining how to transform IP block

parameters to specifications at a lowerhierarchical level

contain gain (the single functional specification), bandwidth, power supplyrejection ratio, offset, etc They have two distinct roles, related to the state ofthe IP block in the design process

• As block parameters when the IP block is a component of a largerblock, higher up in the hierarchy, in the process of being designed Inthis 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 andwill 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

Lower structural hierarchical level

Error function calculation

1-Step optimization Design variables, physical parameters

(w i ∀i ∈ {0,n − 1}) and normalized squared differences subject to

speci-fication type (constraint, cost, condition, etc.):

• Through a direct procedure definition, if the design problem has cient constraints to enable the definition of an explicit solution

suffi-• Through an iterative optimization algorithm If the optimization cess cannot, as is usually the case, be described directly in the languageused to describe the IP block, then a communication model must be set

pro-up between the optimizer and the evaluation method A direct munication model gives complete control to the optimization process,while an inverse communication model uses an external process tocontrol data flow and synchronization between optimization and eval-uation The latter model is less efficient but makes it easier to retaintight control over the synthesis process [MAS1991]

com-The synthesis method generates a new set V of 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 thedesign space The design variables must be independent of each other, and

as such represent a subset of IP block parameters (i.e., performance ria, described above) in a structure definition For example, a differentialamplifier design variable subset could be reduced to a single gate length, biasvoltage, and three transistor widths for the current source, matched ampli-fier transistors, and matched current mirror transistors Physical variables

crite-(in the set P, which outputs to the model parameter values in Figure 19.4)

are directly related to design variables according to a mapping method ∗

such that *r:V→P, and serve to parameterize all components in the structure

definition during the IP block evaluation process In the above example, thedesign variable subset would be expanded to explicitly define all componentparameters

The evaluation method∗e, at the left of Figure 19.4, describes the route

from the physical variable values to the performance criteria values such

that *e:P→S, and thus completes the iterative single-level optimization loop.

Evaluation can be achieved in two main ways:

• Through direct code evaluation, such as for active surface areacalculations

• Through simulation (including behavioral simulation) for accurateperformance evaluation (gain, bandwidth, distortion, etc.) If the IP

block is not described in a modeling language that can be understood

by a simulator, then this requires a gateway to a specific simulatorand to a jig (a set of files to describe the environment surrounding the

IP block and the stimuli to be applied in order to extract meaningfulindicators of performance) corresponding to the IP block itself For thesimulator, this requires definition of how the simulation process will

be controlled (part of the aforementioned communication model) Forthe jig, this requires the transmission of physical variables as param-eters, and the extraction of performance criteria from the simulator-specific results file The latter describes the role of the parameterextraction method, which is necessary to define how the design pro-cess moves up the hierarchical levels during bottom-up verificationphases

Once the single-level loop has converged, the constraint distribution method

∗ defines how the design process moves down the hierarchical levels ing top-down design phases, and defines the specifications for the lower

dur-hierarchical structural level n – 1 in Figure 19.4 At the end of the

synthe-sis process at a given hierarchical level, an IP block will be defined by aset of physical variable values, some of which are parameters of an IP sub-block To continue the design process, the IP subblock will become an IPblock to be designed and it is necessary to transform the block parametersinto specifications according to∗c : P k →S k+1(where k represents the struc-tural hierarchy level) This requires a definition of how each specificationwill contribute to the error function ε for the synthesis method in the newblock

19.2.2 UML/XML Implementation

We have incorporated these concepts into an existing in-house AMS/MTsynthesis framework, RuneII A schematic showing the various inputs anddata files is given in Figure 19.5 From the user’s point of view, there aretwo main phases to AMS/MT synthesis: AMS/MT soft-IP definition, whichcan be done via UML, XML, or through a specific GUI (all inputs areinteroperable—the internal database format is XML); and AMS/MT firm-IPsynthesis, which can be run from the GUI or from scenarios

At the system level, in order to enable the satisfactory partitioning ofsystem-level performance constraints among the various digital, software,and AMS/MT blocks in the system architecture, top-down synthesis func-tionality needs to be added to AMS/MT blocks The goal of this approach

is to enable accurate prediction of analog/RF architectural specification ues for block-level synthesis in an optimal top-down approach by makingreasoned architectural choices about the structure to be designed For gen-eral compatibility with system-level design flows, we chose to represent thisaspect with UML UML 2.0, adopted as a standard by Object Management

val-AMS firm IP synthesis AMS soft IP definition

User

Firm IP class

Soft IP java

FIGURE 19.5

UML/XML/GUI use flow in RuneII

Group (OMG) in 2005, consists of graphical∗languages enabling the sion of system requirements, architecture, and design, and is mainly used

expres-in expres-industry for software and high-level system modelexpres-ing The use of UMLfor high-level SoC design in general appears possible and has generatedinterest in several research and industrial groups [RIC2005] For AMS/MTsystems, [CAR2004] demonstrated the feasibility of describing AMS/MTblocks in UML and then translating them to VHDL-AMS, building on otherapproaches to use a generic description to target various design languages[CHA2004] Considerable effort is also being put into the development of

“AMS/MT-aware” object-oriented design languages such as SystemC-AMS[VAC2003] and SysML [VAN2005] These languages can be linked to a UMLapproach (SysML is directly derived from UML, and SystemC as an object-oriented language can be represented in UML also), and as such it should bepossible to map UML-based work to these derived or related languages

In order to develop a UML-based approach to hierarchical AMS/MT thesis, it is necessary to map the AMS/MT IP element requirements given inTable 19.3 to UML concepts UML has many types of diagrams, and manyconcepts that can be expressed in each—many more, in fact, than are actu-ally needed for the specific AMS/MT IP problem Concerning the types ofdiagram, two broad categories are available:

syn-∗A language for textual representation of UML diagrams also exists (OCL—Object straint Language http://www.omg.org/).

Con-• Structural diagram, to express the static relationship between thebuilding blocks of the system We used a class diagram to describethe properties of the AMS/MT IP blocks and the intrinsic relationsbetween them The tenets of this approach and how to generate UML-based synthesizable AMS/MT IP will be described in this section.

• Behavioral diagram, showing the evolution of the system overtimethrough response to requests, or through interaction between the sys-tem components An activity diagram can be used to describe theAMS/MT synthesis process [OCO2006]

To describe class relationships for AMS/MT IP blocks, it is first necessary

to establish a clear separation of a single function definition (entity and

functional-level model for top-down flows) from n related structural

mod-els (for single-level optimization and bottom-up verification) Each tural model contains lower-level components, which should be described byanother function definition It is also necessary to establish functionality andrequirements common to all structural models whatever their function Byrepresenting all this in a single diagram, shown in Figure 19.6a, we are infact modeling a library of system components; not the actual system to bedesigned itself

struc-A class diagram constitutes a static representation of the system Itallows the definition of classes among several fundamental types, the classattributes and operations, and the time-invariant relationships between thevarious classes From the above analysis, we require

• A single, noninstantiable (abstract) class representing common tionality and requirements, in a separate publicly accessible package

func-We called this class topology

• A single class representing the function definition, which inherits fromtopology An alternative solution would be to separate “evaluatable”functionality and “synthesizable” functionality through the use ofinterfaces This is certainly a debatable point, but our view is that itwould tend to overcomplicate the description process Another point

is that one can also be tempted to separate the entity aspect from thebehavioral model aspect, which would then allow the entity class tobecome abstract Again, this also appears to be somewhat overcompli-cated to carry out

• A number of classes representing the structural models, which allinherit from the function definition class Each structural variant iscomposed of a number of components at a lower hierarchical level, rep-resented by a single function definition class for each component withdifferent functionality As the structural variant cannot exist if the com-ponent classes do not exist, this composition relationship is strength-ened to an aggregation relationship

Having established how to separate particular functionality between mon, functional, and structural parts of an AMS/MT hierarchical model,