White Paper on Platform-based Design

(DRAFT, December 7th, 2001)

Alberto Sangiovanni Vincentelli with Larry Pileggi

1. Introduction
Today, IC technology offers the possibility of integrating so many functions onto a single chip that it is
indeed possible to implement an environment-to-environment system on a single chip. The literature is
rich with papers discussing the System-on-Chip (SoC) opportunities; however, there has not been a wide
market acceptance for this concept. The basic misconception has been attempting to fit the SoC design
methodology to the ASIC design flow that has been in vogue for the last ten years. The economics of SoC
design are simply not appealing in the ASIC framework because of the dramatically increasing cost of SoC
design and manufacturing and the relatively small production volumes.

Creation of an economically feasible SoC design flow requires a structured, top-down methodology that
theoretically limits the space of exploration, yet in doing so achieves superior results in the fixed time
constraints of the design. We propose such a methodology based on defining Platforms at all of the key
articulation points in the SoC design flow. Each platform represents a layer in the design flow for which the
underlying, subsequent design-flow steps are abstracted. By carefully defining the platform layers and
developing new representations and associated transitions from one platform to the next, we believe that an
economically feasible single-pass SoC flow can be realized.

In this document, we define the motivations and principles for Platform-based Design. We believe that the
main thrust of the GSRC research can be summarized in a design methodology that has all the conceptual
characteristics of Platform-based Design. We also believe that the popularity of this concept has led to
confusion as to what this term means and implies. The goal here is to define what these characteristics are
so that a common understanding can be built and a precise reference can be given to our sponsors. We
begin with the prime motivations that spurred the interest in this methodology. Then we will outline the
principles of platform-based design, as it is commonly understood. Finally, we extend the concepts to cover
the entire design process from concept to silicon implementation.

2. Motivation
The platform-based design methodology we have been focusing on is the outgrowth of the SoC debate
where the economics of chip manufacturing and design has been carefully studied. The overall goal of
electronic system design is to balance production costs with development time and cost in view of
performance, functionality and product-volume constraints. Manufacturing cost depends mainly on the
hardware components of the product. Minimizing production cost is the result of a balance between
competing criteria. If we think of an integrated circuit implementation, then the size of the chip is an
important factor in determining production cost. Minimizing the size of the chip implies tailoring the
hardware architecture to the functionality of the product. However, the cost of a state-of-the-art
fabrication facility continues to rise: it is estimated that a new 0.18m high-volume manufacturing
plant costs approximately $2-3B today. NRE (Non-Recurrent Engineering) costs associated with the
design and tooling of complex chips are growing rapidly. The ITRS predicts that while manufacturing
complex System-on-Chip designs will be feasible, at least down to 50nm minimum feature sizes, the
production of practical masks and exposure systems will likely be a major bottleneck for the
development of such chips. That is, the cost of masks will grow even more rapidly for these fine
geometries, adding even more to the up-front NRE for a new design. A single mask set and probe card
cost for a next-generation chip is over $1M for a complex part, up from less than $100K a decade ago
(note: this does not include the design cost). Furthermore, the cost of developing and implementing a
comprehensive test for such complex designs will continue to represent an increasing fraction of a total
design cost unless new approaches are developed.

1
 Goal A. Increasing Mask and manufacturing setup costs are presently biasing the manufacturers
towards parts that have guaranteed high-volume production from a single mask set. This translates to
better response time and higher priorities at times when global manufacturing resources are in short
supply.

Design costs are exponentially rising due to the increased complexity of the products, the challenges
posed by physical effects for deep sub-micron and the limited human resources. Design productivity
according to Sematech is falling behind exponentially with respect to the technology advances. Time-
to-market constraints are also growing at such a fast pace that even if costs were not an issue, it is
becoming plainly impossible to develop complex parts within the constraints. An additional problem is
the lack of skilled work force that could implement future ICs considering the system aspects of the
design and all second order physical effects that will be of primary importance in deep sub micron.

Goal B. The design problems are presently pushing IC and system companies towards designs that
can be assembled quickly from pre-designed and pre-characterized components versus full custom
design methods. This translates to high-priority on design re-use, correct assembly of components, and
fast, efficient compilation from specifications to implementations, correct-by-construction
methodologies and fast/accurate verification1.

Our objective is a design methodology (i.e., Platform-based Design) that can trade-off various
components of manufacturing costs, NRE costs and design productivity at a minimal cost of potential
design performance. We will define our methodology so that it will apply to all levels of abstraction of the
design thereby providing an all-encompassing intellectual framework in which our research can be
embedded and justified.

3. Principles of System-Level Platform-based Design

The concept of platform has been around for years. However, the interpretation of what a platform is has
been, to say the least, confusing. In the IC domain, a platform is considered a flexible integrated circuit
where customization for a particular application is achieved by programming one or more of the
components of the chip. Programming may imply metal customization (Gate arrays), electrical
modification (FPGA personalization) or software to run on a microprocessor or a DSP. We will later define
such examples of flexible integrated circuits as members of a broad family of Silicon Implementation
Platforms.

For the case of software, the platform has been designed as a fixed micro-architecture to minimize mask
making costs but flexible enough to warrant its use for a set of applications so that production volume will
be high over an extended chip lifetime. Micro-controllers designed for automotive applications such as the
Motorola Black Oak PowerPC are examples of this approach. The problem with this approach is the
potential lack of optimization that may make performance too low and size too large. A better approach is
to develop a family of similar chips that differ for one or more components but that are based on the same
microprocessor. For the case of the Black Oak, Motorola indeed developed a family of micro-controllers,
e.g., Silver Oak and Green Oak, that differ for flash memory size and peripherals. Indeed this family and its
common programmatic interface is, in our definition, a platform, more specifically an Architecture
Platform.

In the PC world, PC makers have been able to develop their products quickly and efficiently around a
standard platform that emerged over the years. The architecture standards can be summarized in the
following list:

1
The design time issue can be addressed not only by re-use but also by tools that provide automatic mapping. For
example, if we had the ultimate silicon compiler, an architecture platform could be the entire set of micro-architectures
the silicon compiler can map into.

2
 a. The x86 instruction set architecture (ISA) that makes it possible to re-use the operating
system and the software application at the binary level2;
b. Afullyspecifiedsetofbusses(ISA,USB,PCI)thatmakeitpossibletousethesame
expansionboardsorICsfordifferentproducts3;
c. LegacysupportfortheISAinterruptcontrollerthathandlesthebasicinteractionbetween
softwareandhardware.
d. AfullspecificationofasetofI/Odevices,suchaskeyboard,mouse,audioandvideo
devices.

All PCs should satisfy this set of constraints. If we examine carefully the structure of a PC platform, we
note that it is not the detailed hardware micro-architecture that is standardized, but rather an abstraction
characterized by a set of constraints on the architecture (a through d above). The platform is an
abstraction of a family of (micro)-architectures.

In this case, design time is certainly minimized since the essential components of the architecture are fixed
and the degrees of freedom allow some optimization for performance and cost4.

3.1. Platforms
We believe that the platform paradigm will be an important component of a future electronic system design
methodology. Key to our objective is carefully defining the platform layers.

Integrated circuits used for embedded systems will most likely be developed as an instance of a particular
architecture platform. That is, rather than being assembled from a collection of independently developed
blocks of silicon functionality, they will be derived from a specific family of micro-architectures,
possibly oriented toward a particular class of problems, that can be modified (extended or reduced) by the
system developer.

The elements of this family are a sort of hardware denominator that could be shared across multiple
applications. Hence, the architecture platform concept as a family of micro-architectures that are closely
related is mainly geared towards optimizing design time: every element of the family can be obtained
quickly by personalizing an appropriate set of parameters that control the micro-architecture. For example,
the family may be characterized by the same programmable processor and the same interconnection
scheme, but the peripherals and the memories of a particular implementation may be selected from a pre-
designed library of components depending on the particular application. Depending on the implementation
platform that is chosen more on this to follow -- each element of the family may still need to go through
the standard manufacturing process including mask making. This approach then conjugates the need of
saving design time with the optimization of the element of the family for the application at hand. Although
it does not solve the mask cost issue directly, it should be noted that the mask cost problem is primarily due
to generating multiple mask sets for multiple design spins, which is addressed by the Architecture Platform
methodology. The less constrained the platform, the more freedom a designer has in selecting an instance
and the more potential there is for optimization if time permits. However, more constraints mean stronger
standards and easier addition of components to the library that defines the architecture platform (see the PC
case).

Architecture platforms are, in general, characterized by (but not limited to) the presence of programmable
components so that each of the platform instances that can be derived from the architecture platform
maintains enough flexibility to support an application space that guarantees the production volumes

2
In fact, the MS-DOS operating system can be run on any compatible x86 microprocessor.
3
Note that expansion board re-usability is limited by the technology used.
4
The concept of PC platform actually can be linked to the old Burroughs E-mode mainframe architectural concept,
where the ISA was common across many different implementations over many years. Burroughs E-mode was claimed
to be so effective that programs compiled on the first machines in the early 60s would work (as object code) on the
latest machines in the 80s and 90s.

3
required for economically viable manufacturing. The library that defines the architecture platform may also
contain re-configurable components. 5

3.2. Platform Instance

An architecture platform instance is derived by choosing a set of components from the architecture
platform library and/or by setting parameters of re-configurable components of the library.

The flexibility, i.e., the capability of supporting different applications, of a platform instance is guaranteed
by programmable components. Programmability will ultimately be of various forms, including the two that
exist today: software programmability to indicate the presence of a micro-processor, DSP or any other
software programmable component, or hardware programmability to indicate the presence of
reconfigurable logic blocks such as FPGAs, whereby logic function can be changed by software tools
without requiring a custom set of masks. Some of the new architecture and/or implementation platforms
being offered on the market mix the two into a single chip (for example, Triscend, Altera and Xilinx are
offering FPGA fabrics with embedded hard processors). Software programmability yields a more flexible
solution since modifying software is in general faster and cheaper than modifying FPGA personalities. On
the other hand, logic functions mapped on FPGAs execute orders of magnitude faster and with much less
power than the corresponding implementation as a software program. Thus, the trade-off here is between
flexibility and performance.

3.3. Platform Design Issues

Today the choice of an architecture platform is more an art than a science. Seen from the application
domain, the constraints that determine the architecture platform are often given in terms of performance
and size. For a particular application, we require that, to sustain a set of functions, a CPU should be able
to run at least at a given speed and the memory system should be of at least a given number of bytes. Since
each product is characterized by a different set of functions, the constraints identify different architecture
platforms where applications that are more complex yield stronger architectural constraints. Coming from
the IC manufacturer space, production and design costs imply adding platform constraints and
consequently reducing the number of choices. The intersection of the two sets of constraints defines the
architecture platforms that can be used for the final product. Note that, because of this process, we may
have a platform instance that is over-designed for a given product; that is, the potential of the architecture is
not fully utilized to implement the functionality of that product. Over-design is very common for the PC
platform. In several applications, the over-designed architecture has been a perfect vehicle to deliver new
software products and extend the application space. We believe that some degree of over-design will be
soon accepted in the embedded system community to improve design costs and time-to-market. Hence, the
design of an architecture platform is the result of a trade-off in a complex space that includes:

The size of the application space that can be supported by the architectures belonging to the
architectureplatform.Thisrepresentstheflexibilityoftheplatform;
Thesizeofthearchitecturespacethatsatisfiestheconstraintsembodiedinthearchitectureplatform
definition.Thisrepresentsthedegreesoffreedomthatarchitectureprovidershaveindesigningtheir
hardwareinstances.

Once an architecture platform has been selected, then the design process consists of exploring the
remaining design space with the constraints set by the platform. These constraints cannot only be on the

5
Reconfigurability comes in two flavors:
Run-time reconfigurability, a la Triscend/Xilinx/Altera, where FPGA blocks can be customized by the user
without the need of changing mask set, thus saving both design cost and fabrication cost;
Design-time reconfigurability, a la Tensilica Xtensa, where the silicon is still application-specific; in this case,
only design time is reduced.

4
components themselves but also on their communication mechanism. In fact, particular busses may be a
fixed choice for the communication mechanism (for example, the AMBA bus for the ARM micro-processor
family).

When we march towards implementation by selecting components that satisfy the architectural constraints
defining a platform, we perform a successive refinement process where details are added in a disciplined
way to produce an architecture platform instance.

Architecture platform-based design is neither a top-down nor a bottom-up design methodology. Rather, it is
a meet-in-the-middle approach. In a pure top-down design process, application specification is the
starting point for the design process. The sequence of design decisions drives the designer toward a solution
that minimizes the cost of the architecture. The design process selects the most attractive solution as
defined by a cost function. In a bottom-up approach, a given architecture (instance of the architecture
platform) is designed to support a set of different applications that are often vaguely defined and is, in
general, much based on designer intuition and marketing inputs. In general, IC companies traditionally
followed this approach trying to maximize the number of applications (hence, the production volume) of
their platform instances. The trend is towards defining platforms and platform instances in close
collaboration with system companies thus fully realizing the meet-in-the-middle approach.

Application developers work with an architecture platform by first choosing the architectural elements they
believe are best for their purposes yielding a platform instance. Then, they must map the functionality of
their application onto the platform instance. The mapping process includes hardware/software partitioning.
While performing this step, the designers may decide to move a function from software implementation
running on one of the programmable components to a hardware block. This hardware could be
implemented anywhere from programmable logic to full custom, the representations of which would be
abstracted from the implementation platform. Once the partitioning and the selection of the platform
instance are finalized, the designer develops the final and optimized version of the application software.

Due to the market forces briefly outlined above, most of the implementation is done in software. There is in
fact a very strong trend in system-level design towards software away from hardware implementations.
Indeed, market data indicate that more than 80% of system development efforts are now in software versus
hardware. This implies that an effective platform has to offer a powerful design environment for software to
cope with development costs. In addition, one of the motivations toward standardization of the
programmable components in platforms is software re-use. If the Instruction Set Architecture is kept
constant, then software porting is much easier. However, this mechanism limits the degrees of freedom of
system designers who may have to ignore very performing platforms in favor of older architectures to
maintain software compatibility. Thus, there are two main concerns for an effective platform-based design:

1. Software development environment;

2. A set of tools that insulate the details of the architecture from application software.

This brings us to the definition of an API platform.

3.4. API Platform

The 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 abstracted at a level where the application software
sees a high-level interface to the hardware that we call Application Program Interface (API) or
Programmers Model. A software layer is used to perform this abstraction (see Figure 1). This layer wraps
the essential parts of the architecture platform:

The programmable cores and the memory subsystem via a Real Time Operating System (RTOS),
The I/O subsystem via the Device Drivers, and

5
 The network connection via the network communication subsystem 6.

Application Software Platform API

Software
Software

Architecture Platform Hardware

Input devices Output Devices I O

network

Network Communication
RTOS

Device Drivers

BIOS

Figure 1. Layered software structure

In our conceptual framework, the programming language is the abstraction of the ISA, while the API is the
abstraction of a multiplicity of computational resources (concurrency model provided by the RTOS) and
available peripherals (Device Drivers)7. There are different efforts that try to standardize the API or
Programmers Model.

In our framework, the API or Programmers Model is a unique abstract representation of the architecture
platform via the software layer. With an API so defined, the application software can be re-used for every
platform instance. Indeed the Programmers Model (API) is a platform itself that we can call the API
platform.

Of course, the higher the abstraction level at which a platform is defined, the more instances it contains. For
example, to share source code, we need to have the same operating system but not necessarily the same
instruction set, while to share binary code, we need to add the architectural constraints that force to use the
same ISA, thus greatly restricting the range of architectural choices.

In our framework, the RTOS is responsible for the scheduling of the available computing resources and of
the communication between them and the memory subsystem. Note that in several embedded system
applications, the available computing resources consist of a single microprocessor. In others, such as
wireless handsets, the combination of a RISC microprocessor or controller and DSP has been used widely
in 2G, now for 2.5G and 3G, and beyond. In set-top boxes, a RISC for control and a media processor have
6
In some cases, the entire software layer, including the Device Drivers and the network communication subsystem
is called RTOS.
7
Several languages abstract or embed directly the concurrency model avoiding the RTOS abstraction.

6
 Figure 2. System Platform Stack and Design Flow

Application Space
Application Instance

API Platform
Specification

Arch. Platform
Design-Space
Exploration

Platform Instance
Architectural Space

also been used. In general, we can imagine a multiple core architecture platform where the RTOS
schedules software processes across different computing engines.

There is a battle that is taking place in this domain to establish a standard RTOS for embedded applications.
For example, traditional embedded software vendors such as ISI and WindRiver are now competing with
Microsoft that is trying to enter this domain by offering Windows CE, a stripped down version of the API
of its Windows operating system. In our opinion, if the conceptual framework we offer here is accepted, the
precise definition of the hardware platform and of the API should allow to synthesize automatically and in
an optimal way most of the software layer, a radical departure from the standard models borrowed from the
PC world.

3.5. System Platform-Stack

The basic idea of system platform-stack is captured in Figure 2. The vertex of the two cones represents the
combination of the API or Programmers Model and the architecture platform. A system designer maps its
application into the abstract representation that includes a family of architectures that can be chosen to
optimize cost, efficiency, energy consumption and flexibility. The mapping of the application into the actual
architecture in the family specified by the Programmers Model or API can be carried out, at least in part,
automatically if a set of appropriate software tools (e.g., software synthesis, RTOS synthesis, device-driver
synthesis) is available. It is clear that the synthesis tools have to be aware of the architecture features as
well as of the API. This set of tools makes use of the software layer to go from the API platform to the
architecture platform.

The System Platform-Stack is the combination of two platforms and the tools that map one abstraction
into the other.

The platformstack can be seen as a single layer obtained by gluing together the top platform and the
bottom platform whereby the upper view is the API platform and the lower view is the collection of
components that comprise the architecture platform.

In the design space, there is an obvious trade-off between the level of abstraction of the Programmers
Model and the number and diversity of the platform instances covered. The more abstract the

7
 System
Platform-Stack

Programmers Model the richer is the set of platform instances, but the more difficult it is to choose the
optimal architecture platform instance and map automatically into it. Hence, we envision a number of
system platform-stacks that will be handled with somewhat different abstractions and tools. For example,
traditional platforms that include a small number of standard components such as microprocessors and
DSPs have an API that is simpler to handle than that for reconfigurable architectures 8.

Generalizing our thinking process, we view design as primarily a process of providing abstraction views.
That is, an API platform is a pre-defined layer of abstraction above some more complex device or system
that can be used to design at a higher level. Suppose our low level machine is a micro-controller with some
peripheral devices and some programmable logic. A high-level language compiler, a small RTOS and a
logic synthesis tool for the programmable logic, along with models of the fixed peripherals, might provide
the link between the API platform and this machine architecture.

Following this model, we see that a structural view of the design is abstracted into the API model that
provides the basis for the design process that rests upon this layer of abstraction. To choose the right
architecture platform we need to export at the API level an execution model of the architecture platform
that estimates the performance of the lower level architecture platform. This model may include size, power
consumption and timing; variables that are associated to the lower level abstraction (from the
implementation platform) and that cannot be computed at the API level. On the other hand, we can pass
constraints from higher levels of abstraction down to lower levels to continue the refinement process
satisfying the original design constraints. Together with constraints and estimates, we may also use cost
functions to select among feasible solutions.

In summary, the system platformstack is a comprehensive model that includes the view of platforms from
both the application and the implementation point of views. It is the vertex of the two cones in Figure 2.
Note that the system platform effectively decouples the application development process (the upper
triangle) from the architecture implementation process (the lower triangle). Note also that, once we use the
abstract definition of API as described above, we may obtain extreme cases such as traditional PC
platforms on one side and full hardware implementation on the other. Of course, the programmer model for
a full custom hardware solution is trivial since there is a one-to-one map between functions to be
implemented and physical blocks that implement them. In this latter case, platform-based design amount to
adding to traditional design methodologies some higher level of abstractions. Re-usability is of course
almost not existent.

4. Platform-Based Design: the Overarching Conceptual View

From a historical perspective and the newly formed descriptions stated above, we can state that the general
definition of a platform is an abstraction layer in the design flow that facilitates a number of possible
refinements into a subsequent abstraction layer (platform) in the design flow. Between every pair of
platforms, there is a platform stack that is used to map the upper layer of abstraction into the lower level
one.

If we imagine the entire design as a succession of abstraction layers, then the overall design is like a mille
feuilles, where if we take two successive layers we have the filling that keeps together the two layers (see
Figure 3).

8
There are also mixed-level platforms (e.g., C and assembler, or RTOS and direct register read/write). They may be
non-ideal from the viewpoint of abstraction, but they are still used and should be mentioned. In the absence of good
mapping tools, they may be the only option. Another way of viewing them is the ability of mixing blocks designed
using various platform layers in the same design.

8
 Platform stack { Platform

Mapping Tools

Platform

43

Figure 3. Platforms, Mapping Tools and Platform Layers

The combination in Figure 3 is similar to the system platform stack where the filling is the set of tools that
are used to map the upper layer into the lower one. In this view, the combination has an upper view (in the
case of the system layer, the API) and a lower one (in the case of the system layer, the library of
components that form the architecture platform). Note that we can allow a platform-stack to include several
sub-stacks if we wish to span a large number of abstractions. This will largely depend on the capabilities of
the tools and the outcome of some of our research. We emphasize again that the upper view, the lower view
and the tools that map the two platforms are the important constituents of the platform-stack. The larger the
span, the more difficult it will be to map effectively the two, but the greater the potential9 for design
optimization and exploration.

Various forms of platform-based design have been used for system-level design for many years, and our
intention is to formally define the key principles of platform-based design that will serve as a framework
for our system-level GSRC research. An essential aspect to creating an effective architecture platform layer
is accurately abstracting the models and details from the silicon fabrics and the manufacturing realities.
Moreover, along with accurate circuit-level abstractions there are numerous design and manufacturing
challenges that could also be served by a platform-based design framework for the silicon implementation
layers.

5. Silicon Implementation Platform Stack

TheSiliconImplementationPlatform(SIP)Stackofthedesignflowtakesalloforcomponentsofthe
architectureplatformandmapsthemtoaphysicalimplementation.Inthiscasewecanidentifyasetof
abstractionsthatarerelatedbymappingmethodsinthesameveinthatwefollowedabove.Inaddition,we
can also export to the physical implementation problem the view of platform stack to include the

9
Importantly, most of this potential is unrealized due to the complex and sometimes unrealistic nature of the design
and verification processes for a single-pass design flow. Our research is toward restricting the space of exploration as
little as possible, but while enabling a reliable single-pass process.

9
combinationoftwoplatformsandoftheintermediatelevelsofabstractionwiththetransformationsand
toolsneededtogofromoneabstractiontothenext.

The platform stack from architecture to actual physical implementation is called the Silicon
ImplementationPlatform(SIP)Stack.

ThetoplevelviewoftheSIPstackistheplatformarchitectureview,asshowninFigure4.Theviewfrom
beneaththearchitectureplatformisanetlistofabstractviewsofcomputationalblocksandinterconnect
structures. The next platform, or subsequent level of abstraction towards implementation, can vary
somewhatbasedontheunderlyingtechnologiesthatareabstracted.

Architecture

Architecture Platform
Instance

Silicon Implementation
Platform Stack

Silicom Implementation
Platform Instance

Silicon Implementation

Figure4.SiliconImplementationPlatformStack.

Forexample,thelayoutoftheblocksandoftheinterconnectionsamongblocksaffectsalltheperformance
parameterssuchassize,timingandpowerconsumption.Theconstraintsfromthearchitectureplatform,
thatweregeneratedbasedonimplementationlayerabstractions,areusedtodeterminewhetheraparticular
layoutofthearchitectureplatforminstancecanbeused.Insomecasesafloorplanviewwouldbeusedto
exportupwardtheparametersrelatedtovariouscomponents,includinginterconnect.Inthiscase,thefloor
planisitselfaplatform(thefloorplanplatform)inourconceptualframework.Inothercases,including
those which result from creation of new implementation platforms and silicon implementation
methodologiesaspartofourGSRCresearch,thesiliconimplementationplatformstackcanbeasingle
multifacetedlayer,asshowninFigure4.Similarly,thefloorplanplatformcanbedirectlyincorporatedas
partofthearchitectureplatform.Moreresearchremainstobedoneonthistopic.

Theconceptofimplementationplatformisstronglyrelatedtotheconceptofregulardesignanddesignre
use. Based on extensive reuse, floorplan platforms represent blocks and associated interconnection
patternsthatareselectedfromalibraryofpredesignedcomponents.Thesecomponentsmaybedescribed
atthedetailedphysicalleveloratahigherlevelofabstractionwherenewabstractionsareusedtorepresent
thedetailsofthemanufacturingprocessandisolationfromthecomplexmanufacturinginterface.More
generally,thearchitecturecomponentscanbemappedtoregularblocksoflogicthataresynthesizedinto
geometricallyandphysicallyregular,oftenprogrammableand/orreconfigurable,fabrics.Importantly,these
fabrics that lieintheSIP stackincorporate accurate abstractionsfrom themanufacturing interface. In
addition,themyriadofcomponentsandinstanceswhichlieintheSIPstackarebasedonregularstructures

10
thatfacilitate:correctbyassemblydesign,easeofverification,constructionofreliablecomponentsfrom
widelyfluctuatingparameters,andmanufactureofhighyieldingreliablesiliconICs.

Itshouldbenotedthatthisdesignprocessfromsystemconceptiontoimplementationcouldalsostopat
otherplatformabstractionswheretheactualimplementationisfullyinstantiated.Any design style (or at
least the most meaningful design styles) can be restructured and reorganized to fit within a platform-based
concept. Itcanspanallthewayfromacustomizedsolutiontoafullyprogrammablestandardpart.Of
course, in the case we do not leverage reuse and flexibility via novel regular structures, there is no
differencefromtraditionaldesignflows.Theimportantpointhereisthatthisapproachdoescapturereuse
andflexibilitybutitisitselfflexibleenoughtomixandmatchdesignstylestoaccommodateawide
spectrumofapplicationsandimplementationplatforms.

The final stack on the path to implementation and manufacture is the mask set and the recipes for
manufacturing.Thetechnologyfilesarethecharacterizationofthe manufacturinginterfaceplatform
usedtogeneratethemostaccurateperformanceandcostparameters,asshowninFigure5.

Silicon Implementation

Manufacturing Interface
Platform Stack

Manufacturing Interface

Figure5.

IntheSIPstack,theabstractviewsexportedaboveandbelowarefairlywellunderstoodsincetheyhave
beenpartoftheASICdesignflowinuseforyears.Fordeepsubmicrontechnologiesthough,theaccuracy
oftheseapproximationsisindiscussionsincetheactuallayoutofthewiretransistorpatternaffectsthe
performanceparametersinsuchasubstantialwaythatthedecompositionintologicsynthesisanddetailed
layoutcreatestimingclosureproblems.Inaddition,whatwereconsideredphysicalsecondordereffects
(e.g.,crosstalk,powerdistribution,etc.)afewyearsagoarenowveryimportantfortheperformanceofthe
designandmusthandledviaregulardesignstructuresthatfacilitatecorrectbyconstructionassemblyand
accurateabstractiontothehigherplatformlayers.Clearly,estimation,characterization,costfunctionsand
constraint passing are all essential components in the design flow when we consider the final
implementationofthearchitectureplatforminstance.

11
Forthemanufacturinginterface,whatwasonceaprocesstakenforgranted,itisnowacriticalstepin
controllingandpredictingcost,performanceandreliability.Modelsofthemanufacturingrealitiesmustbe
accuratelyabstractedtotheimplementationplatform,whichrequiresnewinstantiationsofgeometrical
regularity.Thislowestlayerofregularityprovidesafoundationforsubsequentlayersofimplementation
regularity.

6. Network Platforms
The Platform-based design paradigm can be applied to the design of large-scale distributed systems such as
communication networks. To implement these systems the functionality is mapped onto a Network
Platform (NP) that consists of a set of processing and storage elements (nodes) and physical media
(channels) carrying the synchronization and data messages exchanged by nodes. Nodes and channels are
the architecture resources in the NP library and are identified by parameters like processing power and
storage size (nodes) and bandwidth, delay, error rate (channels).

The task of choosing an NP requires selecting from the NP library an appropriate set of resources and a
network topology that defines how channels connect nodes. A broad range of options of physical channels
(e.g. cable, wireless link, fiber) and network topologies (mesh, star, ring) are usually available.
Therefore, the design space to explore is quite large.

Moreover, choosing an NP is especially challenging for distributed networks due to the inherently lossy
nature of the physical channels that connect nodes at distant locations. In these cases, when reliable
communication is required, it is necessary to introduce additional resources (such as
request/acknowledgment protocols) to overcome the effects of noise and interference. Introducing protocols
requires adding processing power and memory units at the communicating nodes; as a result, the protocol
components often dominate the implementation cost function and the design effort. Therefore, in selecting
an NP, it is essential to balance the cost of all the different components and tradeoff between the use of
complex protocols and that of more reliable (and more expensive) channels.

Channels can be defined at different levels of abstraction. Physical channels, such as coaxial cables or
optical fibers, merely transport bits, while more abstract logical channels (e.g. ATM virtual circuit), that
consist of a physical channel and a set of protocol functions, may provide more sophisticated
communication services, such as in-order and reliable packet delivery.

Communication is usually described in terms of a stack of layers, where each layer defines an abstraction
level and, hence, a Network Platform. The description of an NP is usually given in terms of a set of
interface function primitives that the applications running on it can use. This set of primitives defines the
Network API Platform and allows hiding the application designer many lower layer details. Primitives
typically present in an NAPI Platform are: confirmed/unconfirmed data push, data request,
reliable/unreliable send/receive, broadcast/multicast send

For example, consider the multicast-send primitive. It is a useful abstraction and is invoked when the
application requires one node to address a group of nodes having a common attribute. The underlying
software layer translates the symbolic address identifying the destination nodes and automatically sends a
copy of the packet to all the destinations relieving the application programmer from the task to call multiple
one-destination send.

7. Conclusions
Themainmotivationthathaspromptedustodeveloptheseconceptswasdesignreuseandregularityto
thefullestextentduetotheeconomicsofbuildingfutureelectronicssystems.Wedefinedaplatformasa
layer ofabstractionwithtwoviews: theupperview istheabstraction ofthedesignbelowsothat an
applicationcouldbedevelopedontheabstractionwithoutreferringtotheunderlyinglayers,andthelower

12
viewisthesetofrulesthatallowonetoclassifyasetofcomponentsaspartoftheplatform.Inthis
framework,thecomponentsofaplatformareingeneralpartiallyorcompletelypredesignedandtheupper
viewisusedtodecoupletheapplicationfromtheimplementationoftheplatform.Whilethisconcepthas
beenusedforyearsinthePCdomain,itsgeneralizationisnovel.Itsuseinindustryisnowacceptedand
relatesmostlytoarchitectureplatformsandtheApplicationProgrammerInterface(API)abstractionasthe
upperviewoftheplatform.However,becauseofthedefinitionweuse,itispossibleanddesirableto
extendtheplatformconcepttocoverallstepsofdesignfromconceptiontoimplementation.Thetoolsand
methodsusedtomaptheupperandlowerviewsofaplatformstackarethegluethatkeepstheplatforms
together.Hence,wecanimagineaplatformstackthatspansseverallevelsofabstractionofadesign.Tobe
abletochooseefficientlytheinstancesoftheplatformweneedtodealwiththeconstraintpropagation
processinthetopdownaspectofthedesign,whileweneedanannotationmechanism(estimation)thatcan
beassociatedtothetoplevelsofabstractiontocapturelowerlevel details.Thesemechanismsarean
essentialpartofplatformbaseddesign.

At the architecture platform level, flexibility is an essential property. We expect that programmable
componentswilltakethelionsshareofthecomputingpowerofaplatform,sothatelectronicdesignwill
beincreasinglydependentonsoftware.TheleadingplatformstodaysuchasPhilipsNexperiaformulti
mediaandTIOMAPforcellularphonesareallbasedonprogrammablecomponents:amicroprocessor
(MIPS) with a VLIW processor for Nexperia and a microprocessor (ARM) with a DSP for OMAP.
However, there is a strong interest in developing an approach that can take into considerations re
configurableprocessorsandlogic,anintermediateplatformbetweenafixedprocessoroneandanASIC.
ThisinvestigationrepresentsacorepartofourGSRCresearch.

13