The Art and Science of Integrated Systems Design

Luca P. Carloni†, Fernando De Bernardinis†§,Alberto L. Sangiovanni-Vincentelli†, and Marco Sgroi†

†University of California at Berkeley,Berkeley, CA 94720-1772

§Dipartimento di Ingegneria dell’InformazioneUniversit̀a di Pisa, Italy

www-cad.eecs.berkeley.edu/∼{lcarloni,fdb,alberto,sgroi}

Abstract

The design of next-generation integrated systems re-quires that “Art”, a mix of knowledge, experience, intu-ition and creativeness, be supported by “Science”, i.e.,design methodologies that provide rigorous foundationsand guarantee correctness either by construction or by aset of powerful synthesis and verification tools. We presentplatform-based design as the overarching principle to de-velop a class of methodologies that satisfy in part the re-quirements set above. A platform is an abstraction layerthat hides the details of several possible implementationrefinements of the underlying layers. We discuss the im-portance of carefully defining the platform layers and for-mally deriving the transitions from one platform to thenext, including the role of top-down constraint propaga-tion and bottom-up performance estimation. Finally, wepresent examples of these concepts at different key articu-lation points of the design process: system platforms andimplementation platforms including analog design, thuscovering the entire spectrum of design from conceptionand algorithms to final SoC implementation.

1. Introduction

Time-to-market pressure, design complexity and costof ownership for masks are driving the electronics in-dustry towards more disciplined design styles that favordesign re-use and correct-the-first-time implementations.However, traditional computer-aided design (CAD) toolflows come short of providing proper support to reachthese goals mainly because they are built as juxtapositionof independently-conceived stages. Each stage manipu-lates a representation of the final design by applying cer-tain transformations on it before the next stage takes over.The exchange of information between stages is basedon standard data formats, where functional specification,structural information and performance-related annotationare intertwined. These data formats are autonomously in-terpreted by the tools at each stage. The tools have dif-ferent purposes (functional manipulation, structural trans-formation, performance optimization) and, based on their

interpretation of the current status of the design, take de-cisions that have global effects and that are difficult toreverse. As a consequence, several time-consuming it-erations between subsequent stages of the design floware often necessary. For instance, due to the increas-ing impact of second-order physical effect in deep submi-crometer (DSM) technologies (0.13µ and below), design-ers are forced to iterate many times between hardware-description language (HDL) specification and layout, be-cause logic synthesis uses statistical delay models whichbadly estimate the impact of post-layout wire load capac-itance and the netlist lack of structure prevents manual in-tervention on the layout. Furthermore, HDLs allow poorcontrol on physical design and the output of logic syn-thesis is not robust with respect to small variations in theHDL specification. The general problem is that the designflow does not provide formal methods to propagate (andrefine) design constraints from the first stages of the pro-cess, where the specs are set, down to the last stages wherethe final implementation is derived. Similarly, there is lackof formal methods to uniformally feed the first stages withthose technology and performance parameters that are im-posed by the adoption of a given process technology andthe choice of a specific library of pre-design components.The ultimate consequence is that designers struggle in:

• orienting themselves among the various design rep-resentation,

• understanding the combined behavior of the tools,and

• tracking the evolution oftheir design.

Naturally, as they must spend time coping with these is-sues, designers encounter increasing difficulties in lever-aging their knowledge, experience, intuition, and creative-ness.

We argue that now more than ever the art of inte-grated system design needs to be supported by science,i.e., design methodologies that offer rigorous foundationsto build a design flow that guarantees correctness of thedesign by construction or features powerful verification

25

ESSCIRC 2002

and synthesis tools. In particular, the creation of an eco-nomically feasible electronic design flow requires a struc-tured methodology thattheoretically limits the space ofexploration, yet still achieves superior results in the fixedtime constraints of the design. This approach has beenvery powerful in design for both integrated circuits andcomputer programs. For computer programs, the use ofhigh-level programming languages has replaced for themost part assembly languages; for integrated circuits, reg-ular structures such as gate arrays and standard cells havereplaced transistors as a basic building block.

In addition to the obvious pressure towards increas-ingly shorter time-to-market, there is a new phenomenonthat is taking place in the electronics industry and that hasto be addressed by design methodologies. The complex-ity of electronic designs and the number of technologiesthat must be mastered to bring to market winning productshave forced electronic companies to focus on their corecompetence. Product specification, intellectual property(IP) creation, design assembly and manufacturing are, forthe most part, no longer taking place in the same organi-zation. Over the last decade, we have been assisting to thedisaggregation of the electronic industryfrom a vertically-oriented model into a horizontally-oriented one. In thissituation, integration of the supply chain has become a se-rious problem. In particular, the hand-off points in the de-sign chain from one company to another are at risk. If theyare not defined clearly and with no ambiguity, then costlyre-designs are the likely result. The most critical hand-offpoints in the design chain are between system, subsystemand IC companies on one hand, and between IC designand manufacturing. For this reason, we call these pointsarticulation pointsto stress their importance in the overalldesign process.

Finally, the cost of mask ownership and “custom” de-signs together with the need of maintaining flexibility upto the last moment to be able to accommodate engineeringand specification changes, has caused a decrease in num-ber of design starts that is increasingly noticeable. ASICsolutions are less and less appealing for system companiesand application-specific ICs are not always economicallyfeasible for semiconductor companies. Hence, semicon-ductor companies that manufacture anddesign silicon willincreasingly design standardized chips, capable of serv-ing a range of applications via reconfigurable hardwareand software, thus spreading the multimillion-dollar costof a design across a range of applications. The boundariesbetween semiconductor companies and system companieshave to be even more clearly defined than in the previouscase. In fact, semiconductor companies need to minimizerisks when designing these standardized chips. Hencethey need to have a fairly complete characterization of theapplication spaces they wish to address with their prod-ucts with the associated constraints in terms of affordablecosts and performance levels. By the same token, systemcompanies need to have an accurate characterization of thecapabilities of the chips in terms of performance such as

Transistor ModelCapacity Load

1970’s

Gate Level Model Capacity Load

1980’s

RTL

SDF Wire Load

1990’s

IP Block Performance Inter IP Communication Performance Models

RTL SW

Year 2000 +

abst

ract

cluster

abst

ract

cluster

abst

ract

cluster

abst

ract

cluster

Figure 1. A brief history of abstraction in design(Source: F. Schirrmeister).

power consumption, size and timing, as well as“Applica-tion Program Interfaces” (APIs)that allow the mappingof their application into the chip at a fairly abstract level.APIs must then support a number of tools to ease the pos-sibly automatic generation of the personalization of theprogrammable components of the chips.

Platform-Based Designis a methodology that has beenindicated as an effective method to cope with the difficul-ties we exposed above [7]. To place this methodology ina historical perspective, it is useful to see it as the resultof a natural progression in the quest for higher level ofabstractions illustrated in Figure 1. Since the term “plat-form” has been used in several ways by the various seg-ments of the electronic industry, we believe there is a sub-stantial need of defining precisely this term and the ac-companying methodology in an extended framework sothat it can be used to support both traditional ASIC de-sign flows and design flows that extensively use softwareand reconfigurable hardware to implement system func-tionality. For us, aplatform represents a layer in thedesign flow for which the underlying, subsequent design-flow steps are abstracted. Thus a design from conceptionto implementation can be seen in our framework as a setof platforms (abstraction layers) and of methods to trans-form the design from one platform to the next. Platform-based design provides a rigorous foundation to designre-use,correct-by-constructionassembly of pre-designedand pre-characterized components (versus full-custom de-sign methods), design flexibility (through an extended useof reconfigurable and programmable modules) and effi-cient compilation from specifications to implementations.At the same time, it allows us to trade-off various compo-nents of manufacturing, NRE and design costs while sac-rificing as little as possible potential design performance.

In this paper, we first summarize (Section 2) the mo-tivations and principles for platform-based design. Ourgoal is to define what these characteristics are so that acommon understanding can be built and a precise refer-ence can be given to the electronic system and circuit de-

26

Upper Layer of Abstraction

Lower Layer of Abstraction

Perfo

rman

ceA

nn

otatio

n C

on

stra

ints

Pro

pag

atio

n

Figure 2. Interactions Between Abstraction Layers.

sign community. The rest of the paper is about the useof this principle in system design and in silicon imple-mentation. We begin in Section 3, with the description ofPlatforms that are of great importance to define the hand-off of design from system conception to system imple-mentation, the ones that have received most of the atten-tion in the past few years. For pure system design, weselected network design as an important example of ap-plication (Section 4). For silicon implementation, we be-lieve that analog components will have an increasing im-portance in determining the overall design time and ef-fort. For this reason, we will show in Section 5 how toapply the basic principles of platforms to the analog do-main to make the design of System-on-Chip (SoC) easierand based on a uniform methodology. This part is quitenovel since most of the work on platforms has taken placeat the architecture/micro-architecture boundaries.

2. Platform-Based Design

The basic tenets of platform-based design are:

• The identification of design as ameeting-in-the-middle process, where successive refinements ofspecifications meet with abstractions of potential im-plementations.

• The identification of precisely defined layers wherethe refinement and abstraction processes take place.Each layer supports a design stage providing anopaque abstraction of lower layers that allows ac-curate performance estimations. This informationis incorporated in appropriate parameters that anno-tate design choices at the present layer of abstrac-tion. These layers of abstraction are calledplatformsto stress their role in the design process and their so-lidity.

In general, a platform is a library of components thatcan be assembled to generate a design at that level of ab-straction. This library not only contains “computational”blocks that carry out the appropriate computation but also“communication” components that are used to intercon-

nect the functional components. Each element of the li-brary has a characterization in terms of performance pa-rameters together with the functionality it can support. Forevery platform level, there is a set of methods used to mapthe upper layers of abstraction into the platform and a setof methods used to estimate performances of lower levelabstractions. As illustrated in Figure 2, themeeting-in-the-middle processis the combination of two efforts:

• top-down: map an instance of the top platform intoan instance of the lower platform and propagate con-straints;

• bottom-up: build a platform by defining thelibrarythat characterizes it and a performance abstraction(e.g., number of literals for tech. independent opti-mization, area and propagation delay for a cell in astandard cell library).

A platform instanceis a set of architecture compo-nents that are selected from the library and whose param-eters are set. From a historical perspective and the newlyformed concepts stated above, we can state that the gen-eral definition of a platform is an abstraction layer in thedesign flow that facilitates a number of possible refine-ments into a subsequent abstraction layer in the designflow. Often the combination of two consecutive layersand their “filling” can be interpreted as a unique abstrac-tion layer with an “upper” view, the top abstraction layer,and a “lower” view, the bottom layer. Every pair of plat-forms, along with the tools and methods that are used tomap the upper layer of abstraction into the lower level, isa platform stack. Note that we can allow a platform stackto include several sub-stacks if we wish to span a largenumber of abstractions.

Platforms should be defined to eliminate large loop it-erations for affordable designs: they should restrict de-sign space via new forms of regularity and structure thatsurrender some design potential for lower cost and first-pass success. The library of function and communicationcomponents is the design space we can explore at the ap-propriate level of abstraction. Establishing the number,location and components of intermediate platforms is theessence of platform-based design. In fact, designs withdifferent requirements and specification may use differ-ent intermediate platforms, hence different layers of regu-larity and design-space constraints. A critical step of theplatform-based design process is the definition of interme-diate platforms to supportpredictability, that enables theabstraction of implementation detail to facilitate higher-level optimization, andverifiability, i.e. the ability toformally ensure correctness. On the other hand, whendesign-time and product volume permit it, it may be use-ful to skip intermediate platforms. This is equivalent toenlarge the design space and, therefore, can potentiallyproduce a superior design. However, even if a “large-step-across-platform flow” can be adopted, there is still a bene-fit, from an evaluation standpoint, in having a lower-boundon the optimality of the feasible design as the one that can

27

be provided by a more constrained and predictable flow.Naturally, the larger the step across platforms, the moredifficult is predicting performance, optimizing at systemlevel, and providing a tight lower bound. In fact, the de-sign space for this approach may actually be smaller thanthe one obtained with smaller steps because it becomesharder to explore meaningful design alternatives and therestriction on search impedes complete design space ex-ploration. Ultimately, predictions/abstractions may be soinaccurate that design optimizations are misguided andthe lower bounds are incorrect.

It is important to emphasize that the Platform-BasedDesign paradigm applies to all levels of design. Whileit is rather easy to grasp the notion of a programmablehardware platform, the concept is completely general andshould be exploited through the entire design flow to solvethe design problem. In the following sections, we willshow that platforms can be applied to low levels of ab-straction such as analog components, where flexibilityis minimal and performance is the main focus, as wellas to very high levels of abstraction such as networks,where platforms have to provide connectivity and ser-vices. Looking at the involved platforms, in the formercase platforms abstract hardware to provide (physical) im-plementation, while in the latter communication servicesabstract software layers (protocol) to provide global con-nectivity.

3. Platforms at the SystemDefinition-Implementation ArticulationPoint

As we mentioned above, the key to the application ofthe design principle is the careful definition of the plat-form layers. Platforms can be defined at several point ofthe design process. Some levels of abstraction are moreimportant than others in the overall design trade-off space.In particular, the articulation point between system defini-tion and implementation is a critical one for design qualityand time. Indeed, the very notion of platform-based de-sign originated at this point (see [1, 3, 4, 5]). In studyingthis articulation point (see [7] for full details), we have dis-covered that at this level there are indeed two distinct plat-forms that form the “system platform stack” that need tobe defined together with the methods and tools necessaryto link the two: an “architecture” platform and an “API”platform. The API platform is used for system design-ers to use the “services” that a (micro-)architecture offersthem. In the world of Personal Computers, this conceptis well known and is the key to the development of ap-plication software on different hardware that share somecommonality allowing the definition of a unique API.

3.1. (Micro-) Architecture Platforms

Integrated circuits used for embedded systems willmost likely be developed as an instance of a particular(micro-) architecture platform. That is, rather than be-

ing assembled from a collection of independently devel-oped blocks of silicon functionalities, they will be derivedfrom a specificfamily of micro-architectures, possibly ori-ented toward a particular class of problems, that can beextended or reduced by the system developer. The ele-ments of this family are a sort of “hardware denominator”that could be shared across multiple applications. Hence,an architecture platform is a family of micro-architecturesthat share some commonality, the library of componentsthat are used to define the micro-architecture. Every ele-ment of the family can be obtained quickly by personaliz-ing an appropriate set of parameters that control the micro-architecture. Often the family may have additional con-straints on the components of the library that can or shouldbe used. For example, a particular micro-architecture plat-form may be characterized by the same programmableprocessor and the same interconnection scheme, while theperipherals and the memories of a particular implemen-tation may be selected from the pre-designed library ofcomponents depending on the particular application. De-pending on the implementation platform that is chosen,each element of the family may still need to go through thestandard manufacturing process including mask making.This approach then conjugates the need of saving designtime with the optimization of the element of the familyfor the application at hand. Although it does not solve themask cost issue directly, it should be noted that the maskcost problem is primarily due to generating multiple masksets for multiple design spins, which is addressed by thearchitecture platform methodology.

The less constrained the platform, the more freedom adesigner has in selecting an instance and the more poten-tial there is for optimization, if time permits. However,more constraints mean stronger standards and easier addi-tion of components to the library that defines the architec-ture platform (as with PC platforms). Note that the basicconcept is similar to the cell-based design layout style,where regularity and the re-use of library elements allowsfaster design time at the expense of some optimality. Thetrade-off between design time and design “quality” needsto be kept in mind. The economics of the design problemhave to dictate the choice of design style. The higher thegranularity of the library, the more leverage we have inshortening the design time. Given that the elements of thelibrary are re-used, there is a strong incentive to optimizethem. In fact, we argue that the “macro-cells” should bedesigned with great care and attention to area and perfor-mance. It makes also sense to offer a variation of cellswith the same functionality but with implementations thatdiffer in performance, area and power dissipation. Ar-chitecture platforms are, in general, characterized by (butnot limited to) the presence of programmable components.That means that each of the platform instances that can bederived from the architecture platform maintains enoughflexibility to support an application space that guaranteesthe production volumes required for economically viablemanufacturing.

28

The library that defines the architecture platform mayalso contain re-configurable components. Reconfigura-bility comes in two flavors. Run-time reconfigurability,where FPGA blocks can be customized by the user with-out the need of changing mask set, thus saving both designcost and fabrication cost. Design-time reconfigurability,where the silicon is still application-specific; in this case,only design time is reduced.

An architecture platform instanceis derived from anarchitecture platform by choosing a set of componentsfrom the architecture platform library and/or by settingparameters of re-configurable components of the library.The flexibility, or the capability of supporting differentapplications, of a platform instance is guaranteed by pro-grammable components. Programmability will ultimatelybe of various forms. One is software programmabil-ity to indicate the presence of a microprocessor, DSP orany other software programmable component. Another ishardware programmability to indicate the presence of re-configurable logic blocks such as FPGAs, whereby logicfunction can be changed by software tools without re-quiring a custom set of masks. Some of the new archi-tecture and/or implementation platforms being offered onthe market mix the two into a single chip. For exam-ple, Triscend, Altera and Xilinx are offering FPGA fabricswith embedded hard processors. Software programmabil-ity yields a more flexible solution, since modifying soft-ware is, in general, faster and cheaper than modifyingFPGA personalities. On the other hand, logic functionsmapped on FPGAs execute orders of magnitude faster andwith much less power than the corresponding implemen-tation as a software program. Thus, the trade-off here isbetween flexibility and performance.

3.2. API PlatformThe concept of architecture platform by itself is not

enough to achieve the level of application software re-use we require. The architecture platform has to be ab-stracted at a level where the application software “sees”a high-level interface to the hardware that we call Appli-cation Programm Interface (API) or Programmers Model.A software layer is used to perform this abstraction. Thislayer wraps the essential parts of the architecture platform:

• the programmable cores and the memory subsystemvia a Real Time Operating System (RTOS),

• the I/O subsystem via the Device Drivers, and

• the network connection via the network communica-tion subsystem.

In our framework, the API or Programmers Model is aunique abstract representation of the architecture platformvia the software layer. With an API so defined, the appli-cation software can be re-used for every platform instance.Indeed the Programmers Model (API) is a platform itselfthat we can call the API platform. Of course, the higherthe abstraction level at which a platform is defined, the

PlatformDesign-SpaceExport

PlatformMapping

Architectural Space

Application SpaceApplication Instance

Platform Instance

SystemPlatform

Figure 3. System Platform Stack.

more instances it contains. For example, to share sourcecode, we need to have the same operating system but notnecessarily the same instruction set, while to share bi-nary code, we need to add the architectural constraintsthat force to use the same ISA, thus greatly restricting therange of architectural choices.

The RTOS is responsible for the scheduling of theavailable computing resources and of the communicationbetween them and the memory subsystem. Note that inseveral embedded system applications, the available com-puting resources consist of a single microprocessor. Inothers, such as wireless handsets, the combination of aRISC microprocessor or controller and DSP has been usedwidely in 2G, now for 2.5G and 3G, and beyond. In set-top boxes, a RISC for control and a media processor havealso been used. In general, we can imagine a multiple corearchitecture platform where the RTOS schedules softwareprocesses across different computing engines.

3.3. System Platform StackThe basic idea of system platform-stack is captured in

Figure 3. The vertex of the two cones represents the com-bination of the API or Programmers’ Model and the archi-tecture platform. A system designer maps its applicationinto the abstract representation that “includes” a familyof architectures that can be chosen to optimize cost, effi-ciency, energy consumption and flexibility. The mappingof the application into the actual architecture in the fam-ily specified by the Programmers’ Model or API can becarried out, at least in part, automatically if a set of ap-propriate software tools (e.g., software synthesis, RTOSsynthesis, device-driver synthesis) is available. It is clearthat the synthesis tools have to be aware of the architecturefeatures as well as of the API. This set of tools makes useof the software layer to go from the API platform to thearchitecture platform. Note that the system platform effec-tively decouples the application development process (theupper triangle) from the architecture implementation pro-cess (the lower triangle). Note also that, once we use theabstract definition of “API” as described above, we mayobtain extreme cases such as traditional PC platforms onone side and full hardware implementation on the other.

29

Of course, the programmer model for a full custom hard-ware solution is trivial since there is a one-to-one map be-tween functions to be implemented and physical blocksthat implement them. In this latter case, platform-baseddesign amount to adding to traditional design methodolo-gies some higher level of abstractions.

4. Network Platforms

One of the most challenging problems in the design ofdistributed systems is the choice of the resources, suchas physical links and protocols, that support the commu-nication among the system components while satisfying agiven set of constraints on cost and performances. To sim-plify the problem, designers usually decompose the prob-lem into a stack of distinct protocol layers following theOSI layering principle. Each protocol layer together withthe lower layers defines a platform providing services toits users, i.e., the upper layers and, at the topmost of thestack, the application-level components. Identifying fromthe communication requirements of the application thenumber and type of protocol layers requires finding a goodcompromise between optimality (minimize the number oflayers) and design manageability (maximize the numberof intermediate steps), that is the problem of platform-based design as defined in Section 2. Furthermore, explor-ing the design space to determine the functionality of eachprotocol layer and its implementation requires the use oftools and methodologies that allow to evaluate the perfor-mances and guarantee the satisfaction of constraints aftereach step. For these reasons, we believe that the Platform-Based Design principles and methodology outlined in theprevious section can be very effective in protocol design.In this section, first, we formalize the concept of NetworkPlatform. Second, we outline a methodology for selecting,composing and refining network platforms [8].

4.1. Definitions

A Network Platform (NP)is a set of resources thatare composed together to form a Network Platform In-stance (NPI) and provideCommunication Services (CS)to a group of interacting system components (NPI users).Hence, the behaviors and the performances of an NPI aredefined in terms of the type and the quality of the CS itis capable to provide. The structure of an NPI is definedby a set of nodes and links connecting them. Ports inter-face nodes with links or with the external environment ofan NPI. We formalize the behaviors of an NPI using theevent as a communication primitive that models either asend or a receive action of an NPI component. An event isassociated with a message and identified by the type andthe value of the message and by tags specifying attributessuch as ordering or time of the corresponding action. Abehavior of an NPI component, is defined by a totally or-dered sequences = (e1, e2...en) of eventsei observedat its input and output ports. The set of behaviors of an

NPI can be obtained by intersecting the behaviors of theindividual components.

A Network Platform Instance is a tupleNPI = (L,N,P, S), where

• L = {L1, L2, ...LNl} is a set of directed links,

• N = {N1, N2, ....NNn} is a set of nodes,

• P = {P1, P2, ...PNp} is a set of ports. A portPi isa triple (Ni, Li,±), whereNi ∈ N is a node,Li ∈L∪E is either a link or the environmentE and+(−)identifies an input (output) port.

• S is a set of behaviors, each identified by a totallyordered sequence of events observed at the portsPi ∈P .

The services provided by an NPI are called Commu-nication Services (CS) and allow users to exchange mes-sages between NPI input and output ports. Properties ofa CS (commonly called quality of service or QoS) are,for example, the correctness and the delay of the messagetransfer. Formally, a Communication Service (CS) is a

tuple (Pin

, Pout

, M,E, h, g, <t, t), wherePin ⊆ P in

is a non-empty set of NPI input ports,Pout ⊆ P out is

a non-empty set of NPI output ports,M is a non-emptyset of messages,E is a non-empty set of events,h is a

mappingh : E → (Pin ∪ P

out) that associates each

event with a port,g is a mappingg : E → M associ-ating each event with a message,<t is a total order onthe events inE, t is a mappingt : E → T associatingeach event with its timestamp. A CS is defined in terms ofthe number of ports, that determine, for example, if it is aunicast, multicast or broadcast CS, the setM of messagesrepresenting the exchanged information, the setE includ-ing the events that are associated with the messages inMand model the instances of the send and receive methodsinvocations. The CS concept is useful to express the cor-relation among events, and explicit, for example, if twoevents belong to the same user or are associated with thesame message. To facilitate the design task it is key toprovide a user with an abstraction that hides the detailsof the internal components of the NPI and describes onlythe behavior which is observable at the ports interfacingthe NPI with the environment. This abstraction is an Ap-plication Programming Interface (API) and consists of aset of methods that can be invoked by external users toaccess the services provided by the NPI. An API layer isdefined by a set of CS and the methods available to accessthem. Using CS allows to express much more compactlythe behavior of an NPI.

4.2. Quality of ServiceNPIs can be classified according to the number, the

type, the quality and the cost of the CS they offer. Number,type and quality of the supported CS define the capabili-ties of the NPI. To describe effectively the properties of aCS, it is convenient to export a set of QoS parameters such

30

as error rate, latency, throughput, jitter. To quantify suchparameters, we use event annotations and compare valueand timestamps of the events in CS. For example one cancompare the values of pairs of input and output events as-sociated with the same message to measure the error rate,or compare the timestamp of events observed at the sameport to compute the jitter. We label events with indexesj

andi, so thatej,i ∈ e(Pin∪P

out),M indicates the event car-

rying thei-th message and observed at thej-th port, anddefine the main QoS parameters as follows:

• Delay: The communication delay of a message isgiven by the difference between the timestamps ofthe input and output events carrying that message.Assuming that thei-th message is transferred frominput portj1 to output portj2, the delay∆i of thei-thmessage, the average delay∆Av and the peak delay∆Peak are defined respectively as∆i = t(ej2,i) −t(ej1,i),∆Av =

∑|M |i=1

t(ej2,i)−t(ej1,i)|M | ,∆Peak =

maxi{t(ej2,i)− t(ej1,i)}.

• Throughput: The throughput is given by the numberof output events in an interval(t0, t1), i.e. the cardi-

nality of the setΘ = {ei ∈ E|h(ei) ∈ Pout

, t(ei) ∈(t0, t1)}.

• Error rate: The message error rate (MER) is givenby the ratio between the number of lost or cor-rupted output events and the total number of in-put events. Given1 LostM = {ei ∈ E|h(ei) ∈P

in,¬∃ej ∈ E s.t. h(ej) ∈ P

outg(ej) = g(ei)},

CorrM = {ei ∈ E|h(ei) ∈ Pin

,∃ej ∈ E s.t.

h(ej) ∈ Pout

, g(ej) = g(ei), v(ej) 6= v(ei)} and

InM = {ei ∈ E|h(ei) ∈ Pin}, the message error

rateMER = |LostM |+|CorrM ||InM |

2.

Using the above definitions, the following types of CScan be defined:

• Unicast vs. Broadcast CS:a CS is unicast if ev-ery message is transferred to at most one output port,broadcast if messages are transferred to all outputports.

• Lossless vs. Lossy CS:a CS is lossless ifMER =0, otherwise is called lossy.

• In-order vs. Out-of-order CS: in-order communi-cation services ensure that the order of messages atthe input ports is maintained at the output ports, i.e.∀mi,mj ∈ M(mi 6= mj)ein,i < ein,j ⇒ eout,i <eout,j

• Synchronous vs. Asynchronous CS:in syn-chronous CS the communication delay is negli-gible and the input and output events carrying

1v(ei) gives the value of the message carried by eventei.2MER can be converted to Packet and Bit Error Rate, if the encoding

of the messages is known.

the same message have the same timestamp, i.e.∀mi,mj ∈ M(mi 6= mj), t(ein

i ) = t(eouti )

4.3. Examples of Network Platforms

A wire and two end nodes define an elementary type ofNPI that provides in-order and lossy CS due to the noisein the wire. A bounded FIFO channel is an NPI providingasynchronous and in-order CS. It offers lossy (when over-flows) or lossless CS depending on the arrival pattern ofthe input events. If the protocol at the end nodes includes ablocking write mechanism, it can provide lossless CS for alarger set of input patterns. More complex NPIs can be de-signed selecting protocols and physical media or reusingexisting NPIs as building blocks. If the type and the qual-ity of the services that a given NPI provides do not satisfythe communication requirements, additional protocol lay-ers can be introduced to derive another NPI offering moresophisticated services. For example, if a physical link de-signed to transmit messages between one pair of users isto be shared by multiple pairs of communicating users,one must introduce a MAC protocol that schedules trans-missions and avoids collisions. The components of theextended NPI are the physical link initially given and theMAC protocol. Figure 4 shows three examples of NPIs:a reliable one-hop NPI that supports lossless communica-tion among components (in the figure labeled as A and B)directly connected by a single hop link, a multi-hop NPIfor communication between end nodes (C and D in thefigure) that are connected by a path composed of multiplenodes and links, and a reliable end-to-end NPI for losslesscommunication between end users (E and F).

4.4. Design of Network Platforms

The starting point of the design of an NPI is the set ofbehaviors of the interacting system components that de-fine an abstract NPI and a set of constraints on the qualityof the CS that the fully implemented NPI must provide.The procedure we propose is based on the concept ofsuc-cessive refinement: successive because it usually consistsof a sequence of steps and refinement because at each stepthe communication is specified at a greater level of detailand at a finer granularity in time, space or data types. Therefinement of an NPI consists of defining a more detailedNPI′ by replacing one or more components in the originalNPI with a set of components or NPIs. A correct refine-ment procedure generates an NPI′ that provides CS equiv-alent to those offered by the original NPI with respect tothe constraints defined at the upper level. For example, anNPI consisting of a direct link between end nodes can berefined into an NPI′ where intermediate nodes are used asrepeaters (multi-hop network). The refinement is correctif the end-to-end delay of the multi-hop network is withinthe delay constraints satisfied by the direct link. A typi-cal communication refinement step requires to define boththe structure of the refined NPI′, i.e. its components andtopology, and the behavior of these components, i.e. theprotocols deployed at each node. One or more NP com-

31

Figure 4. Examples of NPIs

ponents (or predefined NPIs) are selected from a libraryand composed to create CS of higher quality. Two typesof compositions are possible. One type consists of choos-ing a NPI and extending it with a protocol layer to createCS at a higher level of abstraction (vertical composition).The other type is based on the concatenation of NPIs (andtherefore of their CS) using an intermediate object calledadapter (or gateway) that maps sequences of events be-tween the ports being connected (horizontal composition).

5. Analog Platforms

Analog components are required in every system thatinterfaces with the physical world to acquire signals, and,hence, they are needed in any System-On-a-Chip (SOC)implementation. In addition, even when analog solutionscould be replaced by digital ones from a pure functionalpoint of view (for example, radio links), performance re-quirements may be so tight that the digital approach is outof the question.

Analog design has been traditionally the most difficultdiscipline of IC design. This difficulty stems from theeffects that physical implementations have on the func-tionality of analog circuits. In the digital case, function-ality depends on discrete sequences of discrete (binary)signals. Not so in the analog case, where continuous se-quences (waveforms) of continuous values encode the in-formation we need to manipulate and use. For this rea-son, any second order physical effect may have a signifi-cant impact on the function and performance of an analogcircuit. Hence, the design of analog components has tra-ditionally pivoted around low-level “clever tricks” (art orblack magic?) that involve transistor layout and parameterselection, thus making virtually impossible to use higherlevels of abstraction. At this juncture of the evolution ofIC design where complexity and time-to-market reign, webelieve there is a need to develop more abstract designtechniques that can encapsulate some of the art of analogdesign into a methodology that could shorten design timewithout compromising the quality of the solutions. Ac-tually, given that traditional analog design is carried out

at the transistor level, design space exploration is quitelimited because of the time needed to evaluate alternativesolutions with circuit simulators.

We believe that platform-based design can provide thenecessary insight to develop a methodology for analogcomponents that takes into consideration system levelspecifications and can choose among a set of possible so-lutions including digital approaches wherever it is feasibleto do so. Today, system-level analog design is a designprocess dominated by heuristics. Given a set of specifi-cations/requirements that describes the system to be real-ized, the selection of a feasible (let alone optimal) imple-mentation architecture comes mainly out of experience.Usually, what is achieved is just a feasible point at thesystem level, while optimality is sought locally at the cir-cuit level. The reason for this is the difficulty in the analogworld of knowing whether something is realizable withoutactually attempting to design the circuit. The number ofeffects to consider and their complex interrelations makethis problem approachable only through the experience ofpast designs.

5.1. Definitions

We define anAnalog Platform(AP) as a library of ana-log components and interconnect. Each components is aparameterized block with parameters varying over a con-tinuous space. An AP is characterized by an input (param-eter) space and an output (performance) space. The inputspaceI defines the region of the architectural space thatis captured by the components of the Analog Platform.For example, in a Low Noise Amplifier (LNA) we maydefineI as{Win, Lin, Ibias}, where the first two quanti-ties are related to the input transistor andIbias is the biascurrent. Each quantity spans a given interval of values.The LNA component is itself a platform and representsonly the implementations defined byI, thus constrainingthe architecture space. A platform instance defines spe-cific values for{W ∗

in, L∗in, I∗bias}, i.e. the actual circuit

to be considered. The output spaceO defines the perfor-mance parameters that are needed in order to evaluate (themapping of a behavior on) the platform (performance an-notation). Continuing with the LNA example,O may bedefined as{Gain, Power, Noise}. For each platform be-ing considered, anevaluate() method mapsI into O.Mathematically, we can consider such a method to be afunctionφ(·) : I → O. The functionφ(·) can be definedin different ways, depending on the level of abstraction ofthe current platform, spanning from circuit simulations tocircuit equations.

A key concept of Analog Platforms is that onlyO hasto be exported at the current level of abstraction (platformopaqueness), because the functionφ(·) andI are not nec-essary to evaluate the performances of mapped behaviors.Because of this, Analog Platforms are also suitable can-didates to protect sensitive data when exporting IPs. Plat-form performances can be represented through mathemat-ical relations,P(Gain, Power, Noise) = 1, which are sat-

32

isfied only by thosen-tuples of performance figures thatare actually obtainable with the current platform. In thisway it is possible to capture all the interrelations amongthe different performance figures and annotate behavioralmodels consequently.

In order to allow hierarchical exploitation of platforminstances, three operations have to be defined and imple-mented in terms ofPs:

• abstraction - given a platform relationP(Gain,Power, Noise, IP3, SR) = 1 we may want to derivean abstracted view of the platform (virtual platform)that only relates a subset of performance figures, e.g.P ′(Gain, Power, Noise) = 1 ⇔ ∃IP3∗, SR∗ s.t.P(Gain,Power, Noise, IP3∗, SR∗) = 1. This oper-ation is needed every time we use models at higherlevels of abstraction.

• composition - given two platformsA and B andsome interface parametersλ (e.g. the output loadfor A/input load for B), we may want to derivePAB(x, y) = 1 ⇔ ∃λ s.t. PA(x, λ) = 1 andPB(y, λ) = 1. PAB represents the set of compati-ble performances of the compositionA → B.

• merge - given n platforms for the same functional-ity, a super-set platform can be defined byor-ing therespectiveP ’s after moving to a common level of ab-straction. Pmerge = 1 ⇔ ∃i s.t. Pi = 1. Intu-itively, this means considering the union of the per-formance space of individual platforms. For exam-ple, if each platform models a different topology fora given circuit functionality, a platform instance willdefine both the topology and the circuit to be refined,thus intrinsically performing architecture selection.

The generation of platform performancesPs is in gen-eral accomplished through samplingφ(·) over the inputspaceI. This is because in the general caseφ(·) is acomplex non-linear function, and no explicit representa-tion for it might be available (in order to provide an accu-rate characterizations,φ(·) may be implicitly defined bycircuit simulation). The goal is to get a smooth contin-uous representation of the performance relationP. Thisconstitutes the bottom-up phase for building a platformslibrary and is the crucial step for achieving accurate per-formance annotations. The characterization of a platformover its input space is exponentially complex with thedimensionality ofI. Also, the characterization processgenerates large amounts of data that need to be effec-tively represented. The first problem requires some hintsfrom the analog designer to limit the dimensionality ofI, i.e. which “knobs” are most meaningful for definingthe platform and which constraints on the value of eachparameter can be exploited to prune the characterizationspace. Design of experiments techniques may also be usedto achieve optimal accuracy/complexity tradeoffs. Evenso, large numbers of multi-dimensional samples may be

Figure 5. Projections of a 7-dimensional P for an LNA.

generated, on the order of thousands to hundreds thou-sands. As Figure 5 illustrates, an effective way of repre-senting the information provided by these simulations isto use machine learning techniques, in particular SupportVector Machines (SVMs). SVMs make possible to storeonly a small portion of the original results (typically 10%or lower) while providing multidimensional interpolationthat enables the extrapolation of performance figures outof the available data based on some continuity assump-tions.

5.2. Analog Platform Stack

An Analog Platform Stack contains several layers ofabstraction with the appropriate representation at eachlevel. In the analog world, finding a model for a plat-form is a complex matter. Behavioral models allowfast simulations thus enabling more extensive explo-rations/optimizations. Furthermore, they are tailored for aspecific platform to include at the behavioral level specificidiosyncrasies of the platform. By constraining modelsto reflect platform performances, i.e. constraining modelparameters to satisfy the platformP, a mapping of func-tionality onto architecture is achieved.

Analog Platform Stacks provide hierarchies of behav-ioral models at different levels of abstraction to reflect therefinement process typical of top-down flows. In orderto promote design space exploration, all the models arederived from root models characterized by functionalityfamilies (see Figure 6). For example, we can have LNA,mixer and PLL families, which in turn generate trees ofmodels at different levels of abstraction. The nodes ofthese trees represent higher-level platforms and the leavesimplementation platforms. By exploiting the abstractionand merge operations defined above, all platforms in agiven family can be included in a tree originating fromthe same root model (the most abstract platform). Therefinement process proceeds selecting branches in the treeand, therefore, more detailed platforms, transforming con-

33

Figure 6. Sample model hierarchy for LNAs.

straints from a more abstract platform to a more detailedplatform (exactly as described in the digital case). Themapping process ends with the selection of a platform in-stance of a particular platform.

Platforms require to explicitly model communication.Communication is a main actor in Analog Platforms, witheven more emphasis than in the digital case. In fact, inter-actions between communication and computation in ana-log blocks are much more involved than for digital blocks.We can consider the communication between two blocksas well as the respective behaviors to be the fixed-point so-lution of the composition of the blocks. Because of this,orthogonalization becomes harder for detailed platformsand communication has to be modeled together with be-havior. Therefore, the semantics of the component fam-ilies requires to specify the allowed block interconnec-tions. In this sense, the communication at the output ofan LNA is modeled with respect to the mixer that is sup-posed to follow the LNA. At the most detailed level, thismeans that a given LNA can work with some mixers andnot with others. Of course, different domains of appli-cation may require different composability characteristicsamong the component families.

Analog Platforms can be hierarchically composed togenerate new Analog platforms at higher level of abstrac-tion. PLLs provide examples of hierarchical compositionsince their complexity allows them to be considered assystemsper se. The result of the composition is a newAnalog Platform that needs to be endowed with a set ofbehavioral models. The process of deriving new platformsis the same as deriving platform for circuits (fractal na-ture of design), whereφ(·) now refers to the compositionof APs in place of simple circuits. Therefore hierarchi-cal composition provides a more general way to generatemore abstract platforms other than the abstraction/mergeoperations previously defined.

5.3. Design of Analog Platforms

Up to now, analog system level design has been car-ried out only through experience and trial and error. APsenable systematic, high-level design exploration. The re-finement and mapping processes available with APs allowtop-down flows to evaluate system level trade-offs with re-spect to the performance space of the analog platform (P).The process that maps constraints from one platform to thenext proceeds until a platform implementation instance isselected, i.e. the specifications for all blocks have been de-fined. From here on, it is up to the IP provider to generatean implementation with the required performances or upto designers to size the schematic and generate the layout.The novelty of the approach consists in the fact that theuse ofPs guarantees by construction that the set of spec-ifications generated is feasible, thus drastically reducingthe number of iterations required to get feasible specifica-tions and achieving optimal points over larger parameterspaces.

If we focus on a wireless transceiver as an example, atthe most abstract level (largest design space) its function-ality is transferring information between two points us-ing a shared, nonideal channel. The channel models boththe physical channel and the effects deriving from hard-ware limitations (analog and digital) in terms of noise,linearity, gain, numerical accuracy and so on. An opti-mal transceiver implementation maximizes some functionof the Bit Error Rate over a set of constraints and spec-ification scenarios. A global optimum in the transceiverimplementation implies optimum decomposition betweenanalog and digital functionalities, optimum transceiverarchitecture, optimum block topology and finally opti-mum circuit design. It is then evident that optimalityrequires much more than optimal circuit synthesis (thatdeals only with local optima). Furthermore, optimizationsat the circuit level may be outperformed by different cir-cuits/topologies implementing the same block functional-ity. To really optimize a design, exploration is a must.By exploiting Analog Platforms, system trade-offs can beevaluated over much larger design spaces and optimal par-titions of constraints can be derived for each individualplatform. The bottom-up nature of the platform charac-terization guarantees that the required performances areachievable, and APs can actually provide means of auto-matically generating the requested platform instance.

Analog Platforms also separate the design of individ-ual blocks from system design, thus allowing more ef-fective explorations and optimizations at higher levels ofabstraction where the design space is much larger. Theintroduction of the platform concept enables the integra-tion of heterogeneous IPs, and does not put any constrainon analog designers for developing new circuit solutionsfor sensitive blocks. In this sense, APs may be exploitedas a fast evaluation method for new solutions, generatingcoarse performance regions at first to evaluate the basicperformances of a new solution at the system level, and,then, refining both the architecture and the functionality

34

Mapping

Performance Eval./System Optimization

PLL

Behavioral Models

Int. IP’sExt. IP’s

Analog Platforms

New IP’s

BehaviorRefinement

PlatformRefinement

P

Figure 7. Analog design flow exploiting Analog Plat-forms.

to take full advantage of the new solution (if convenient).This process can be pictorially represented by the classicY chart that is essentially the same as in the digital case(Figure 7).

Hierarchical platforms allow to progressively refine thesystem while maintaining accurate performance estima-tions in the process. This is a major obstacle in top-down methodologies that do not leverage the “meeting-in-the-middle” approach of platform based design. Wecan actually consider the platform performance relationP as a more sophisticated version of the flexibility func-tion that was at the heart of the refinement process of themethodology proposed in [2]. Accurate platform evalu-ation methods are the key to the use of behavioral mod-els for evaluating trade-offs at the analog/digital boundary,where fast and reliable methods are needed to determinewhich functionalities should be mapped on analog plat-forms and which on digital platforms. Taken one step fur-ther, even protocol and network topologies could be evalu-ated in a unified platform environment, leading to ahard-ware/software/analogco-design paradigm for embeddedsystems.

In the digital implementation platform domain, FPGAshave played an important role in providing flexibility withfast design time. In the analog domain, while several at-tempts have been made in the past, this level of recon-figurability has not been reached due to the difficultiesin obtaining satisfactory analog designs by programminginterconnects and functionalities of homogeneous build-ing blocks. Field Programmable Analog Arrays [6] area new attempt at this reconfigurable Analog Platform.FPAAs provide a software configurable switched capac-itor array that can be programmed on the fly by micro-controllers in the platform. In this way, they provide ananalog platform that is analogous to FPGAs in the digitalworld. From this abstraction level, implementing a func-tionality with digital signal processing (FPGA) or ana-log processing (FPAA) becomes subject to system leveloptimization while exposing the same abstract interface.

Moreover, while the array already provides a basic plat-form level, a platform stack can be built by exploiting thesoftware tools that allow mapping complex functionali-ties (filters, amplifiers, triggers and so on) directly on thearray. The top level platform, then, provides an API tomap and configure analog functionalities, exposing ana-log hardware at the software level. By exploiting this ab-straction, not only design exploration is greatly simplified,but new synergies between higher layers and analog com-ponents can be leveraged to further increase the flexibil-ity/reconfigurability and optimize the system.

6. Conclusions

We have defined platform-based design as an all-encompassing intellectual framework in which scientificresearch, design tool development, and design practicescan be embedded and justified. A platform is an ab-straction layer that hides the details of the several pos-sible implementation refinements of the underlying layer.Platform-based design allows us to trade-off various com-ponents of manufacturing, NRE and design costs whilesacrificing as little as possible potential design perfor-mance. We presented examples of these concepts at differ-ent key articulation points of the design process, includingnetwork platforms, implementation platforms, and analogplatforms.

The platform-based methodology is supported by theMetropolis framework, a federation of integrated analy-sis, verification and synthesis tools supported by a rigor-ous mathematical theory of metamodels and agents. Thisframework will be available soon through the standardchannels for software distribution handled by the Depart-ment of EECS, University of California at Berkeley.

7. Acknowledgments

We gratefully acknowledge the support of the Gigas-cale Silicon Research Center (GSRC) that funded most ofthe work described here. Alberto Sangiovanni-Vincentelliwould like to thank Alberto Ferrari, Luciano Lavagno,Richard Newton, Jan Rabaey, Henry Chang, Grant Mar-tin, Frank Schirrmeister and Kurt Keutzer for their manyhours of discussion about platform-based design. LarryPileggi has contributed substantially in defining SiliconImplementation Platforms. We also thank the member ofthe DOP center of the University of California at Berke-ley for their support and for the atmosphere they cre-ated for our work. The Berkeley Wireless Research Cen-ter and our industrial partners, (in particular: BMW, Ca-dence, Intel, Magneti Marelli, and ST Microelectronics)have contributed with designs and continuous feedbackto make this approach more solid. Felice Balarin, JerryBurch, Roberto Passerone, Yoshi Watanabe and the Ca-dence Berkeley Labs team have been invaluable in con-tributing to the theory of metamodels and the Metropolisframework.

35

[1] F. Balarin, M. Chiodo, P. Giusto, H. Hsieh, A. Ju-recska, L. Lavagno, C. Passerone, A. Sangiovanni-Vincentelli, E. Sentovich, K. Suzuki, and B. Tabbara.Hardware-Software Co-Design of Embedded Systems: ThePOLIS Approach, . Kluwer Academic Publishers,Boston/Dordrecht/London, 1997.

[2] H. Chang, E. Charbon, U. Choudhury, A. Demir, E. Felt,E. Liu, E. Malavasi, A. Sangiovanni-Vincentelli, and I. Vas-siliou. A Top-Down, Constraint-Driven Design Methodol-ogy for Analog Integrated Circuits. Kluwer Academic Pub-lishers, Boston/Dordrecht/London, 1996.

[3] H. Chang, L. Cooke, M. Hunt, G. Martin, A. McNelly,and L. Todd. Surviving the SOC Revolution: A Guide toPlatform Based Design,. Kluwer Academic Publishers,Boston/Dordrecht/London, 1999.

[4] A. Ferrari and A. L. Sangiovanni-Vincentelli. System De-sign: Traditional Concepts and New Paradigms. InProc.Intl. Conf. on Computer Design, pages 1–12, Oct. 1999.

[5] K. Keutzer, S. Malik, A. R. Newton, J. Rabaey, andA. Sangiovanni-Vincentelli. System level design: Orthog-onalization of concerns and platform-based design.IEEETransactions on Computer-Aided Design of Integrated Cir-cuits and Systems, 19(12), December 2000.

[6] I. Macbeth. Programmable Analog Systems: the MissingLink. In EDA Vision (www.edavision.com), July 2001.

[7] A. L. Sangiovanni-Vincentelli. Defining Platform-Based Design. In EEDesign. Available athttp://www.eedesign.com/story/OEG20020204S0062),Feb. 2002.

[8] A. L. Sangiovanni-Vincentelli and M. Sgroi. Ser-vice based Model and Methodology for NetworkPlatforms. Technical Report available at www-cad.eecs.berkeley.edu/s̃groi/techreports, June 2002.

36