SECTION VI Real-Time and Embedded Systems

sanatoriumdrumΗλεκτρονική - Συσκευές

25 Νοε 2013 (πριν από 3 χρόνια και 9 μήνες)

88 εμφανίσεις

SECTION VI






Real
-
Time and Embedded Systems

System
-
on
-
Chip and Network
-
on
-
Chip Design

Chapter 11







System
-
on
-
a
-
Chip and Design

Grant Martin

Cadence
Berkeley Labs

Introduction


“System
-
on
-
Chip” is a phrase that has been much bandied about in recent y
ears

[
1
]
.

It is more than a design style, more than
an approach to the design of application
-
specific integrated circuits (ASICs), more than a methodology. Rather, System
-
on
-
Chip
(SoC) represents a major revolution in IC design
-

a revolution enabled
by the advances
in process technology allowing the integration of all or most of the major components
and subsystems of an electronic product onto a single chip, or integrated chipset.
[
2
]

This
revolution in design has been embraced by many designers of c
omplex chips, as the
performance, power consumption, cost and size advantages of using the highest level of
integration made available have proven to be extremely important for many designs.

In
fact, the design and use of SoCs is arguably one of the key

problems in designing real
-
time embedded systems.


The move to SoC began sometime in the mid
-
1990’s. At this point,
the leading
CMOS
-
based semiconductor process technologies of 0.35 and 0.25 microns were
sufficiently capable of allowing the integration
of many of the major components of a
second generation wireless handset or a digital set
-
top box onto a single chip. The
digital baseband functions of a cellphone
-

a Digital Signal Processor (DSP), hardware
support for voice encoding and decoding, and
a RISC processor
-

could all be placed onto
a single die. Although such a baseband SoC was far from the complete cellphone
electronics
-

there were major components such as the RF transceiver, the analogue
power control, analogue baseband, and passives w
hich were not integrated
-

the
evolutionary path with each new process generation, to integrate more and more onto a
single die, was clear. Today’s chipset would become tomorrow’s chip. The problems
of integrating hybrid technologies involved in making

up a complete electronic system
would be solved.

Thus, eventually, SoC could encompass design components drawn
from the standard and more adventurous domains of digital, analogue, RF, reconfigurable
logic, sensors, actuators, optical, chemical, micr
o
-
electronic mechanical systems, and
even biological and nanotechnology.


With this viewpoint, of continued process evolution leading to
ever
-
increasing
levels of integration into ever
-
more
-
complex SoC devices, the issue of an SoC being a
single
chip

at an
y particular point in time is somewhat moot. Rather, the word “system”
in System
-
on
-
Chip is more important than “chip”. What is most important about an
SoC whether packaged as a single chip, or integrated chipset, or System
-
in
-
Package (SiP)
or System
-
on
-
Package (SoP) is that it is designed as an integrated
system
, making design
tradeoffs across the processing domains and across the individual chip and package
boundaries.

System
-
on
-
a
-
Chip


Let’s define a System
-
on
-
a
-
Chip design (
SoC
)
as a complex
integr
ated circuit, or
integrated chipset,
which

combines

the major functional elements
or subsystems
of a
complete end
-
product into a single
entity
.

These days, all interesting SoC designs
include
at least one programmable processor
, and very often a combin
ation of at least one
RISC control processor and one DSP. They also include on
-
chip communications
structures
-

processor bus(es), peripheral bus(es) and perhaps a high
-
speed system bus.
A hierarchy of
on
-
chip memory

units, and links to off
-
chip mem
ory are important
especially for SoC processors (cache, main memories, very often separate instruction and
data caches are included). For most signal processing applications, some degree of
hardware
-
based

accelerating function
al

units are provided, offe
ring higher performance
and lower energy consumption. For interfacing to the external, real world, SoCs
include a number of peripheral processing blocks, and due to the analogue nature of the
real world, this may include analogue components as well as
digital interfaces (for
example, to system buses at a higher packaging level). Although there is much
interesting research in incorporating MEMS
-
based sensors and actuators, and in SoC
applications incorporating chemical processing (lab
-
on
-
a
-
chip), th
ese are, with rare
exceptions, research topics only. However, future SoCs of a commercial nature may
include such subsystems, as well as optical communications interfaces.


Figure 1 illustrates what a typical SoC might contain for consumer applications.

MicroProcessor
RAM
DMA
Flash
MPEG
Decode
DSP
Video I/F
Audio
CODEC
Bus Bridge
PCI
USB
Disk Controller
PLL
Test
System
Bus
100 base
-
T
ICache
DCache
RAM
Flash
ICache
DCache
External
Memory Access
Peripheral
Bus
MicroProcessor
RAM
DMA
Flash
MPEG
Decode
DSP
Video I/F
Audio
CODEC
Bus Bridge
PCI
USB
Disk Controller
PLL
Test
System
Bus
100 base
-
T
ICache
DCache
RAM
Flash
ICache
DCache
External
Memory Access
Peripheral
Bus

Figure
1
: A typical System
-
on
-
a
-
Chip device for consumer applications


One key
point about SoC which is often forgotten for those approaching them
from a hardware
-
oriented perspective is that all interesting
SoC designs encomp
ass both
hardware and software components

-

i.e., programmable processors, real
-
time operating
systems, and other aspects of hardware
-
dependent software such as peripheral device
drivers, as well as middleware stacks for particular application domains, and

possibly
optimized assembly code for DSPs. Thus, the design and use of SoCs cannot remain a
hardware
-
only concern
-

it involves aspects of system
-
level design and engineering,
hardware
-
software tradeoff and partitioning decisions, and software archite
cture, design
and implementation.

System
-
on
-
a
-
Programmable
-
Chip


Recently, attention has begun to
expand in the SoC world from SoC
implementations using custom, ASIC or application
-
specific standard part (ASSP) design
approaches, to include the design and
use of complex reconfigurable logic parts with
embedded processors and other application oriented blocks of intellectual property.

These complex FPGAs (Field
-
Programmable Gate Arrays) are offered by sever
al vendors,
including Xilinx (Vi
rtex
-
II PRO

Platf
orm FPGA
) and Altera (SOPC), but are referred to
by several names: highly programmable SoCs,
System
-
on
-
a
-
programmable
-
chip,
embedded FPGAs.
The key idea
behind this approach to SoC is to combine large
amounts of reconfigurable logic with embedded
RISC
processors (either custom laid
-
out,
‘hardened’ blocks, or synthesizable processor cores), in order to allow very flexible and
tailorable
combinations of hardware and software processing to be applied to a particular
design problem. Algorithms which con
sist of significant amounts of control logic, plus
significant quantities of dataflow processing, can be partitioned into the control RISC
processor (for example, in Xilinx Virtex
-
II PRO, a PowerPC processor) and
reconfigurable logic offering hardware acce
leration. Although the resulting combination
does not offer
the highest performance, lowest energy consumption, or lowest cost, in
comparison with custom IC or ASIC/ASSP implementations of the same functionality, it
does offer tremendous flexibility in mo
difying the design in the field and avoiding
expensive Non
-
Recurring Engineering (NRE) charges in the

design. Thus, new
applications, interfaces and improved algorithms can be downloaded to products working
in the field using this approach.


Products i
n this area also include other processing and interface cores, such as
multiply
-
accumulate (MAC) blocks which are specifically
aimed at DSP
-
type dataflow
signal and image processing applications; and high speed serial interfaces for wired
communications su
ch as SERDES (serializer/de
-
serializer) blocks. In this sense,
system
-
on
-
a
-
programmable
-
chip SoCs are not exactly application
-
specific, but not
completely generic either.


It remains to be seen whether system
-
on
-
a
-
programmable chip SoCs are going to
be
a successful way of delivering high volume consumer applications, or will end up
restricted to the two main applications for high
-
end FPGAs: rapid prototyping of
designs which will be re
-
targeted to ASIC or ASSP implementations; and used in high
-
end, re
latively expensive parts of the communications infrastructure which require in
-
field flexibility and can tolerate the tradeoffs in cost, energy consumption and
performance. Certainly, the use of synthesizable processors on more moderate FPGAs
to realize

SoC style designs is one alternative to the cost issue. Intermediate forms, such
as the use of metal
-
programmable gate
-
array style logic fabrics together with hard
-
core
processor subsystems and other cores, such as is offered in the “Structured ASIC”
o
fferings of LSI Logic (RapidChip) and NEC (Instant Silicon Solutions Platform)
represents an intermediate form of SoC between the full
-
mask ASIC and ASSP approach
and the field
-
programmable gate array approach. Here the tradeoffs are much slower
design c
reation (a few weeks rather than a day or so), higher NRE than FPGA (but much
lower than a full set of masks), and better cost, performance and energy consumption
than FPGA (perhaps 15
-
30% worse than an ASIC approach). Further interesting
compromise or
hybrid style approaches, such as ASIC/ASSP with on
-
chip FPGA regions,
are also emerging to give design teams more choices.

IP Cores


The design of
SoC would not be possible if every design started from scratch. In
fact, the design of SoC depends heavily o
n the reuse of Intellectual Property blocks
-

what are called “IP Cores”.

IP reuse has emerged as a strong trend over the last 8
-
9
years
[
3
]
and has been one key element in closing what the International Technology
Roadmap for Semiconductors

[
4
]

calls th
e “design productivity gap”
-

the different
between the rate of increase of complexity offered by advancing semiconductor process
technology, and the rate of increase in designer productivity offered by advances in
design tools and methodologies.


But reus
e is not just important to offer ways of enhancing designer productivity
-

although it has dramatic impacts on that. It also provides a mechanism for design teams
to create SoC products which span multiple design disciplines and domains. The
availabi
lity of both hard (laid
-
out and characterized) and soft (synthesizable) processor
cores from a number of processor IP vendors allows design teams who would not be able
to design their own processor from scratch to drop them into their designs and thus add
RISC control and DSP functionality to an integrated SoC without having to master the art
of processor design within the team. In this sense, the advantages of IP reuse go beyond
productivity
-

it offers both a large reduction in design risk, and also a wa
y for SoC
designs to be done that would otherwise be infeasible due to the length of time it would
take to acquire expertise and design IP from scratch.


This ability when acquiring and reusing IP cores
-

to acquire, in a
pre
-
packaged

form, design domain e
xpertise outside one’s own design team’s set of core competencies,
is
a key requirement for the evolution of SoC design going forward. SoC up to this point
has concentrated to a large part on integrating digital components together, perhaps with
some ana
logue interface blocks which are treated as black boxes. The hybrid SoCs of
the future, incorporating domains unfamiliar to the integration team, such as RF or
MEMS, requires the concept of “drop
-
in” IP to be extended to these new domains. We
are not

yet at that state
-

considerable evolution in the IP business and the methodologies
of IP creation, qualification, evaluation, integration and verification are required before
we will be able to easily specify and integrate truly heterogeneous sets of dis
parate IP
blocks into a complete hybrid SoC.


However, the same issues existed at the beginning of the SoC revolution in the
digital domain. They have been solved to a large extent, through the creation of
standards for IP creation, evaluation, exchange

and integration
-

primarily for digital IP
blocks but extending also to analogue/mixed
-
signal (AMS) cores. Among the leading
organizations in the identification and creation of such standards has been the Virtual
Socket Interface Alliance (VSIA)

[
5
]
, f
ormed in 1996 and having at its peak membership
more than 200 IP, systems, semiconductor and Electronic Design Automation (EDA)
corporate members. Although often criticized over the years for a lack of formal and
acknowledged adoption of its IP standards
, VSIA has had a more subtle
influence on the
electronics industry. Many companies instituting reuse programmes internally; many IP,
systems and semiconductor companies engaging in IP creation and exchange; and many
design groups have used VSIA IP stand
ards as a key starting point for developing their
own standards and methods for IP
-
based design. In this sense, use of VSIA outputs has
enabled a kind of IP reuse in the IP business.


VSIA, for example, in its early architectural documents of 1996
-
1997,
helped
define the strong industry
-
adopted understanding of what it meant for an IP block to be
considered to be in “hard” or “soft” form. Other important contributions to design
included the widely read system level design model taxonomy created by one
of its
working groups. Its standards, specifications and documents thus represent a very
useful resource for the industry.


Other important issues
for the rise of IP
-
based design and the emergence of a third
party industry in this area (which has taken

much longer to emerge than originally hoped
in the mid
-
1990s) are the business issues surrounding IP evaluation, purchase, delivery
and use. Organisations such as the Virtual Component Exchange (VCX)

[
6
]

emerged to
look at these issues and provide solu
tions. Although still in existence, it is clear that the
vast majority of IP business relationships between firms occurs within a more ad
-
hoc
supplier to customer business framework.

Virtual Components


The VSIA has had a strong influence on the nomencla
ture of the SoC and IP
-
based design industry.
The concept of the “virtual socket”
-

a description of the all the
design interfaces which an IP core must satisfy, and design models and integration
information which must be provided with the IP core
-

requ
ired to allow it to be more
easily integrated or “dropped into” an SoC design
-

comes from the concept of Printed
Circuit Board
(PCB)
design where components are sourced and purchased in pre
-
packaged form and can be dropped into a board design in a standar
dized way.


The dual of the “virtual socket” then becomes the “virtual component”.
Specifically in the VSIA context, but also more generally in the interface, an IP core
represents a design block which
might

be reusable. A virtual component represents

a
design block which is
intended

for reuse, and which has been
developed

and
qualified

to
be highly reusable.
The things that separate IP cores from virtual components are in
general:



Virtual components conform in their development and verification proc
esses to
well
-
established design processes and quality standards.



Virtual components come with design data, models, associated design files,
scripts, characterization information and other deliverables which conform to one
or other well
-
accepted standards
for IP reuse
-

for example, the VSIA deliverables,
or another internal or external set of standards.



Virtual components
in general should have been fabricated at least once, and
characterized post
-
fabrication to ensure that they have validated claims.



Virt
ual components should have been reused at least once by an external design
team, and usage reports and feedback should be available.



Virtual components should have been rated for quality using an industry standard
quality metric such as OpenMORE (originate
d by Synopsys and Mentor Graphics)
or the VSI Quality standard (which has OpenMORE as one of its inputs).


To a large extent, the developments over the last decade in IP reuse have been
focused on defining the standards and processes to turn the ad
-
hoc reu
se of IP cores into a
well
-
understood and reliable process for acquiring and reusing virtual components
-

thus
enhancing the analogy with PCB design.

Platforms and Programmable Platforms


The emphasis in the preceding sections has been on IP (or virtual co
mponent)
reuse on a somewhat ad
-
hoc block by block basis in SoC design. Over the past several
years, however, there has arisen a more integrated approach to the design of complex
SoCs and the reuse of virtual components
-

what has been called “Platform
based design”.
This will be dealt with at much greater length in Chapter 12, “Platform based and
derivative design” by Alberto Sangiovanni
-
Vincentelli. Much more information is
available in the references [
7
,
8
,
9, 10
]. Suffice it here to define pla
tform
-
based design
in the SoC context from one perspective.


We can define platform based d
esign
as a

planned design

method
ology which

reduce
s

the time

and effort

required
,

and risk involved
,

in design
ing and verifying a
complex SoC. This is accomplished

by
extensive

reuse of combinations of hardware and
software IP.
As an alternative

to

IP reuse in a block by block manner, platform
-
based
design
assembles

groups of components into a
reusable platform architecture. This
reusable architecture, together
with libraries of pre
-
verified and pre
-
characterised,
application oriented HW and SW virtual components, is an SoC integration platform.


There are several reasons for the growing popularity of the platform approach in
industrial design. These include th
e increase in design productivity, the reduction in risk,
the ability to utilize pre
-
integrated virtual components from other design domains more
easily, and the ability to reuse SoC architectures created by experts. Industrial platforms
include
s full ap
plication platforms, reconfigurable platforms, and processor
-
centric
platforms [
11
]. Full application platforms, such as Philips Nexperia
and TI OMAP
provide a complete implementation vehicle for specific product domains

[
12
]
.
Processor
-
centric platfor
ms, such as ARM PrimeXsys concentrate on the processor, its
required bus architecture and basic sets of peripherals
, along with RTOS and basic
software drivers
.

Reconfigurable
, or “highly programmable”

platforms such as the
Xilinx Platform FPGA and Alte
ra’s SOPC deliver hardcore processors plus
reconfigurable logic along with associated IP libraries and design tool flows
.

Integration Platforms and SoC Design


The use of SoC integration platforms changes the SoC design process in two
fundamental ways:

1.

The basic platform must be designed,
using whatever ad
-
hoc or formalized design
process for SoC that the platform creators decide on. The next section outlines some of
the basic steps required to build an SoC, whether building a platform or using a bl
ock
-
based more ad
-
hoc integration process. However, when constructing an SoC platform
for reuse in derivative design, it is important to remember that it may not be necessary to
take the whole platform and its associated HW and SW component libraries thr
ough
complete implementation. Enough implementation must be done to allow the platform
and its constituent libraries to be fully characterized and modeled for reuse. It is also
essential that the platform creation phase produce in an archivable and r
etrievable form
all the design files required for the platform and its libraries to be re
-
used in a derivative
design process. This must also include the setup of the appropriate configuration
programs or scripts to allow automatic creation of a configure
d platform during
derivative design.

2.

A design process must be created and qualified for all the
derivative

designs which
will be created based on the SoC integration platform. This must include processes for
retrieving the platform from its archive,

for entering the derivative design configuration
into a platform configurator, the generation of the design files for the derivative, the
generation of the appropriate verification environment(s) for the derivative, the ability for
derivative design teams

to select components from libraries, to modify these components
and validate them within the overall platform context, and, to the extent supported by the
platform, to create new components for their particular application.


Reconfigurable or highly progr
ammable platforms introduce an interesting
addition to the platform based SoC design process
[13
]. Platform FPGAs and SOPC
devices can be thought of as a “meta
-
platform”: a platform for creating platforms.
Design teams can obtain these devices from
companies such as Xilinx and Altera,
containing a basic set of more generic capabilities and IP
-

embedded processors, on
-
chip
buses, special IP blocks such as MACs and SERDES, and a variety of other pre
-
qualified
IP blocks. They can then customize the m
eta
-
platform to their own application space by
adding application domain
-
specific IP libraries. Finally, the combined platform can be
provided to derivative design teams, who can select the basic meta
-
platform and
configure it within the scope intended by

the intermediate platform creation team,
selecting the IP blocks needed for their exact derivative application.


More on platform
-
based design will be found in Chapter 12.

Overview of the SoC Design Process


The most important thing to remember about SoC

design is that it is a multi
-
disciplinary design process, which needs to exercise design processes from across the
spectrum of electronics. Design teams must gain some fluency with all these multiple
disciplines, but the integrative and reuse nature of
SoC design means that they may not
need to become deep experts in all of them. Indeed, avoiding the need for designers to
understand all methodologies, flows and domain
-
specific design techniques is one of the
key reasons for reuse and enablers of product
ivity. Nevertheless, from DFT through
digital and analogue HW design, from verification through system level design, from
embedded SW through IP procurement and integration, from SoC architecture through IC
analysis, a wide variety of knowledge is require
d by the team, if not every designer.


Figure 2 illustrates some of the basic constituents of the SoC design process
.

SoC
Requirements
Analysis
SoC
architecture
Communications
architecture
Choose
Processor(s
)
System
-
Level Design:

HW
-
SW partitioning

System Modelling

Performance Analysis
Acquisition of HW and SW IP
Build Transaction
-
Level
Golden
Testbench
Configure and
Floorplan
SoC
HW
microarchitecture
Define SW architecture
SW Assembly and
Implementation
HW and HW
-
SW
Verification
DFT Architecture
and Implementation
HW IP Assembly and
Implementation
AMS HW
Implementation
Final
SoC
HW Assembly and Verification
Fabrication, Testing, Packaging, Lab Verification with SW
SoC
Requirements
Analysis
SoC
architecture
Communications
architecture
Choose
Processor(s
)
System
-
Level Design:

HW
-
SW partitioning

System Modelling

Performance Analysis
Acquisition of HW and SW IP
Build Transaction
-
Level
Golden
Testbench
Configure and
Floorplan
SoC
HW
microarchitecture
Define SW architecture
SW Assembly and
Implementation
HW and HW
-
SW
Verification
DFT Architecture
and Implementation
HW IP Assembly and
Implementation
AMS HW
Implementation
Final
SoC
HW Assembly and Verification
Fabrication, Testing, Packaging, Lab Verification with SW

Figure
2
: Steps in the SoC Design Process


We will now define each of these steps as illustrated:



SoC require
ments analysis

is the basic step of defining and specifying a
complex SoC, based on the needs of the end product into which it will be
integrated. The primary input into this step is the marketing definition of the end
product and the resulting character
istics of what the SoC should be: both
functional and non
-
functional (e.g cost, size, energy consumption, performance:
latency and throughput, package selection). This process of requirements
analysis must ultimately answer the question: is the produ
ct feasible? Is the
desired SoC feasible to design, and with what effort and in what timeframe?
How much reuse will be possible? Is the SoC design based on legacy designs of
previous generation products (or, in the case of platform
-
based design, to b
e built
based on an existing platform offering)?



SoC architecture
: In this phase the basic structure of the desired SoC is defined.
Vitally important is to decide on the
communications architecture

that will be
used as the backbone of the SoC on
-
chip c
ommunications network.

An
inadequate communications architecture will cripple the SoC and have as big an
impact as the use of an inappropriate processor subsystem. Of course, the choice
of communications architecture is impossible to divorce from ma
king the basic
processor(s) choice

-

e.g., do I use a RISC control processor? Do I have an on
-
board DSP? How many of each? What are the processing demands of my SoC
application? Do I integrate the bare processor core, or use a whole processor
subsys
tem provided by an IP company (most processor IP companies have moved
from offering
just processor cores, to whole processor subsystems including
hierarchical bus fabrics tuned to their particular processor needs)? Do I have
some ideas, based on legacy So
C design in this space, as to how SW and HW
should be partitioned?

What memory hierarchy is appropriate? What are the
sizes, levels, performance requirements and configurations of the embedded
memories most appropriate to the application domain for the
SoC?



System
-
level design

is an important phase of the SoC process
-

but one that is
often done in a relatively ad
-
hoc way.

The whiteboard

and the spreadsheet are
as much used by the SoC architects as more capable toolsets. However, there has
long bee
n use of ad
-
hoc C/C++ based models for the system design phase
-

to
validate basic architectural choices. And designers of complex signal processing
algorithms for voice and image processing have long adopted dataflow models
and associated tools to define

their algorithms, define optimal bit
-
widths and
validate performance whether destined for hardware or software implementation.
A flurry of activity in the last few years on different C/C++ modeling standards
for system architects has consolidated on Sys
temC [
14
]
. The
system

nature of
SoC demands a growing use of system
-
level design modeling and analysis as
these devices grow more complex. The basic processes carried out in this phase
include HW
-
SW partitioning (the allocation of functions to be implem
ented in
dedicated HW blocks, in SW on processors (and the decision of RISC vs. DSP),
or a combination of both, together with decisions on the communications
mechanisms to be used
to interface HW and SW, or HW
-
HW and SW
-
SW). In
addition, the constructio
n of system
-
level models, and the analysis of correct
functioning, performance, and other non
-
functional attributes of the intended SoC
through simulation and other analytical tools, is necessary.

Finally, all additional
IP blocks required which can be so
urced outside, or reused from the design
group’s legacy, must be identified
-

both HW and SW. The remaining new
functions will need to be implemented as part of the overall SoC design process.



After system level design and the identification of the proc
essors and
communications architecture, and other HW or SW IP required for the design, the
group must undertake an
IP acquisition

stage. This can to a large extent be done
at least in part in parallel with other work such as system
-
level design (assuming

early identification of major external IP is made) or building golden transaction
-
level testbench models.
Fortunate design groups will be working in companies
with both a large legacy of existing well
-
crafted IP (rather, ‘virtual components’)
organized

in easy to search databases; or those with access via supplier
agreements to large external IP libraries; or at least those with experience at IP
search, evaluation, purchase and integration. For these lucky groups, the
problems at this stage are greatly

ameliorated. Others with less experience or
infrastructure will need to explore these processes for the first time, hopefully
making use of IP suppliers’ experience with the legal and other processes required.
Here the external standards bodies such a
s VSIA and VCX have done much
useful work that will smooth the path, at least a little.

One key issue in IP
acquisition is to conduct rigorous and thorough incoming inspection of IP to
ensure its completeness and correctness to the greatest extent possibl
e prior to use,
and to resolve any problems with quality early with suppliers
-

long before SoC
integration. Every hour spent on this at this stage will pay back in avoiding much
longer schedule slip later. The IP quality guidelines discussed earlier are

a
foundation level for a quality process at this point.



Build a transaction
-
level golden testbench
: The system model built up during
the system level design stage can form the basis for a more elaborated design
model, using ‘transaction
-
level’ abstracti
ons ‘[
15
], which represents the
underlying HW
-
SW architecture and components in more detail
-

sufficient detail
to act as a functional virtual prototype for the SoC design. This golden model
can be used at this stage to verify the micro
-
architecture of
the design and to
verify detailed design models for HW IP at the Hardware Description Language
(HDL) level within the overall system context. It thus can be reused all the way
down the SoC design and implementation cycle.



Define the SoC
SW Architecture
.

SoC is of course not just about HW

[
16
]
.
As well as often defining the right on
-
chip communications architecture, the
choice of processor(s) and the nature of the application domain have a very heavy
influence on the SW architecture. For example, Real
-
Time Operating System
(RTOS) choice is limited by the processor ports which have been done and by the
application domain (OSEK is an RTOS for automotive systems; Symbian OS for
portable wireless devices; PalmOS for Personal Digital Assistants, etc.).
As
well as the basic RTOS, every SoC peripheral device will need a device driver
-

hopefully based on reuse and configuration of templates; various middleware
application stacks (e.g. telephony, multimedia image processing) are important
parts of the SW ar
chitecture; voice and image encoding and decoding on portable
devices often is based on assembly code IP for DSPs. There is thus a strong
need in defining the SoC to fully elaborate the SW architecture to allow reuse,
easy customization and effective ve
rification of the overall HW
-
SW device.



Configure and Floorplan SoC Microarchitecture
:
At this point we are
beginning to deal with the SoC on a more physical and detailed logical basis. Of
course, during high
-
level architecture and system
-
level design,
the team has been
looking at physical implementation issues (although our design process diagram
shows everything as a waterfall kind of flow, in reality SoC design like all
electronics design is more of an iterative,
incremental

process
-

i.e. more akin t
o
the famous ‘spiral’ model for SW). But before beginning detailed HW design
and integration it is important that there is agreement among the team on the basic
physical floorplan; that all the IP blocks are properly and fully configured; that
the basic
microarchitectures (test, power, clocking, bus, timing) have been fully
defined and configured, and that HW implementation can proceed. In addition,
this process should also generate the downstream verification environments which
will be used throughout t
he implementation processes
-

whether SW simulation
based, emulation based, using rapid prototypes, or other hybrid verification
approaches.



DFT architecture and implementation
: The test architecture is only one of the
key microarchitectures which must
be implemented; it is complicated by IP
legacy and the fact that it is often impossible to impose one Design
-
for
-
Test style
(such as BIST or SCAN) on all IP blocks
. Rather, wrappers or adaptations of
standard test interfaces (such as JTAG ports) may be n
ecessary to fit all IP blocks
together into a coherent test architecture and plan.



AMS HW Implementation
: Most SoCs incorporating analogue/mixed
-
signal
(AMS) blocks use them to interface to the external world. VSIA, among other
groups, has done consider
able work in defining how AMS IP blocks should be
created to allow them to be more easily integrated into mainly digital SoCs (the
“Big D/little a” SoC); and guidelines and rules for such integration. Experiences
with these rules and guidelines and extra

deliverables has been on the whole
promising
-

but they have more impact between internal design groups today than
on the industry as a whole. The “Big A/Big D” mixed
-
signal SoC is still
relatively rare.



HW IP Assembly and Integration
: This design ste
p
is in many ways the most
traditional. Many design groups have experience in assembling design blocks
done by various designers or sub
-
groups in an incremental fashion, into the
agreed on architectures for communications, bussing, clocking, power etc.

The
main difference with SoC is that many of the design blocks may be externally
sourced IP. To avoid difficulties at this stage, the importance of rigorous
qualification of incoming IP and the early definition of the SoC microarchitecture,
to which all
blocks must conform, cannot be overstated.



SW Assembly and Implementation
: Just as with HW, the SW IP, together
with new or modified SW tasks created for the particular SoC under design, must
be assembled together and validated as to conformance to inte
rfaces and expected
operational quality. It is important to verify as much of the SW in its normal
system operating context as possible (see below).



HW and HW
-
SW Verification
: Although represented as a single box on the
diagram, this is perhaps one of
the largest consumers of design time and effort
and the major determinant of final SoC quality.

Vital to effective verification is
the setup of a targeted SoC verification environment, reusing the golden testbench
models created at higher levels of the
design process. In addition, highly
capable, multi
-
language, mixed simulation environments are important (for
example, SystemC models and HDL implementation models need to be mixed in
the verification process and effective links between them are crucial
).
There are
a large number of different verification tools
and techniques [
17
], ranging from
SW
-
based simulation environments, to HW emulators, HW accelerators, and
FPGA and bonded
-
core
-
based rapid prototyping approaches. In addition, formal
techniques

such as equivalence checking, and model/property checking have
enjoyed some successful usage in verifying parts of SoC designs, or the design at
multiple stages in the process. Mixed approaches to HW
-
SW verification range
from incorporating Instruction
Set Simulators (ISSs) of processors in SW
-
based
simulation to linking HW emulation of the HW blocks (compiled from the HDL
code) to SW running natively on a host workstation, linked in an ad
-
hoc fashion
by design teams or using a commercial mixed verificat
ion environment.
Alternatively, HDL models of new HW blocks running in a SW simulator can be
linked to emulation of the rest of the system running in HW
-

a mix of emulation
and use of bonded
-
out processor cores for executing SW.

It is important that

as
much of the system SW be exercised in the context of the whole system as
possible, using the most appropriate verification technology that can get the
design team close to real
-
time execution speed (no more than 100X slower is the
minimum to run signif
icant amounts of software).

The trend to transaction
-
based
modeling of systems, where transactions range in abstraction from untimed
functional communications via message calls, through abstract bus
communications models, through cycle
-
accurate bus functio
nal models, and
finally to cycle and pin
-
accurate transformations of transactions to the fully
detailed interfaces, allows verification to occur at several levels or with mixed
levels of design description. Finally, a new trend in verification is assert
ion
-
based verification, using a variety of input languages (PSL/Sugar, e, Vera, or
regular Verilog and VHDL) to model design properties, which can then be
monitored during simulation, either to ensure that certain properties will be
satisfied, or certain e
rror conditions never occur.

Combinations of formal
property checking and simulation
-
based assertion checking have been created
-

viz. “semi
-
formal verification”. The most important thing to remember about
verification is that armed with a host of t
echniques and tools, it is essential for
design teams to craft a well
-
ordered verification process
which allows them to
definitively answer the question “how do we know that verification is done?” and
thus allow the SoC to be fabricated.



Final SoC HW Assem
bly and Verification
: Often done in parallel or
overlapping “those final few simulation runs” in the verification stage, the final
SoC HW assembly and verification phase includes final place and route of the
chip, any hand
-
modifications required, and fi
nal physical verification (using
design rule checking and layout
-
vs
-
schematic (netlist) tools), as well as important
analysis steps for issues which occur in advanced semiconductor processes such
as IR drop, signal integrity, power network integrity, as we
ll as satisfaction and
design transformation for manufacturabilty (OPC, etc.).



Fabrication, Testing,
Packaging, and Lab Verification
: When an SoC has
been shipped to
fabrication, it would seem time for the design team to relax.
Instead, this is an oppo
rtunity for
additional verification to be carried out
-

especially more verification of system software running in context of the
hardware design
-

and for fixes, either of software, or of the SoC HW on
hopefully no more than one expensive iteration of the

design
-

to be determined
and planned. When the tested packaged parts arrive back for verification in the
lab, the ideal scenario is to load the software into the system and have the SoC
and its system booted up and running software within a few hours.

Interestingly,
the most advanced SoC design teams, with well
-
ordered design methodologies
and processes, are able to achieve this quite regularly.

System
-
Level Design


As we touched on earlier, when describing the overall SoC design flow, system
-
level de
sign and SoC are essentially made for each other. A key aim of IP reuse and of
SoC techniques such as platform
-
based design is to make the “back end” (RTL to GDS II)
design implementation processes easier
-

fast and with low
-
risk; and to shift the major
design phase for SoC up in time and in abstraction level to the system level.

This also
means that the back
-
end tools and flows for SoC designs do not necessarily differ from
those used for complex ASIC, ASSP and custom IC design
-

it is the methodology

of
how they are used, and how blocks are sourced and integrated, that overlays the
underlying design tools and flows, that may differ for SoC. However, the fundamental
nature of IP
-
based design of SoC has a stronger influence on the system level.


It is

at the system level that the vital tasks of deciding on and validating the
basic
system architecture and choice of IP blocks are carried out. In general, this is known as
“design space exploration
”.
As part of this exploration, SoC platform customizat
ion for
a particular derivative is carried out, should the SoC platform approach be used.
Essentially one can think of platform design space exploration (DSE) as being a similar
task to general DSE, except that the scope and boundaries of the exploration

are much
more tightly constrained
-

the basic communications architecture and platform processor
choices may be fixed, and the design team may be restricted to choosing certain
customization parameters and choosing optional IP from a library. Other tas
ks include
HW
-
SW partitioning, usually restricted to decisions about key processing tasks which
might be mapped into either HW or SW form and which have a big impact on system
performance, energy consumption, on
-
chip communications bandwidth consumption, o
r
other key attributes. Of course, in multi
-
processor systems, there are “SW
-
SW”
partitioning or co
-
design issues as well; deciding on the assignment of SW tasks to
various processor options. Again, perhaps 80
-
95% of these decisions can or are made
a

priori
, especially if an SoC is either based on a platform or an evolution of an existing
system; such co
-
design decisions are usually made on a small number of functions which
have critical impact.


Because partitioning, co
-
design and DSE tasks at the sy
stem level involve much
more than HW
-
SW issues, a more appropriate term for this is “function
-
architecture co
-
design” [
18
,
19
]. In this co
-
design model,
systems are described on two equivalent
levels:



The functional intent of the system
-

e.g. a network

of applications, decomposed
into individual sets of functional tasks which may be modeled using a variety of
models of computation (see Chapter 3, “Models of Computation for Embedded
Systems”) such as discrete event, finite state machine
or dataflow.



The
architectural structure of the system
-

the communications architecture, major
IP blocks such as processor(s), memorie(s), and HW blocks, captured or modeled
for example using some kind of IP or platform configurator.

The methodology implied in this approa
ch is then to build explicit mappings between the
functional view of the system and the architectural view, which carry within them the
implicit partitioning that is made for both computation and communications. This hybrid
model can then be simulated, t
he results analysed, and a variety of ancillary models (for
example, cost, power, performance, communications bandwidth consumption, etc.) can
be utilized in order to examine the suitability of the system architecture as a vehicle for
realizing or implemen
ting the end product functionality.


The function
-
architecture co
-
design approach has been implemented and used in
both research and
commercial tools [20
] and forms the foundation of many system
-
level
co
-
design approaches going forward. In addition, it h
as been found extremely suitable as
the best system
-
level design approach for platform
-
based design of SoC [
21
].

Interconnection and communication architectures for systems on chip


This topic is dealt with in more detail in Chapters 13, 14 and 15. Suff
ice it to
say here
that current SoC architectures deal in fairly traditional hierarchies of standard
on
-
chip buses: for example, processor
-
specific buses, high
-
speed system buses and
lower
-
speed peripheral buses, using standards such as ARM’s AMBA and IBM
’s
CoreConnect [
12
]
, and traditional master
-
slave bus approaches
. Recently there has been
a lot of interest in network
-
on
-
chip communications architectures
, based on packet
-
sw

and a number of approaches have been reported in the literature but this remai
ns
primarily a research topic both in universities and industrial research labs.

[
22
]

Computation and memory ar
chitectures for systems on chip



The primary processors used in SoC are embedded RISCs such as ARM
processors, PowerPCs,
MIPS architecture proce
ssors and some of the configurable
processors designed specifically for SoC such as Tensilica and ARC. In addition,
embedded DSPs from traditional suppliers as TI, Motorola, ParthusCeva and others are
also quite common in many consumer applications, fo
r embedded signal processing for
voice and image data. Research groups have looked at compiling
or synthesizing
application
-
specific processors

or co
-
processors

[
23, 24
]

and these have interesting
potential in future SoCs which may incorporate networks

of heterogeneous configurable
processors collaborating to offer large amounts of computational parallelism. This is an
especially interesting prospect given wider use of
reconfigurable logic which opens up
the prospect of dynamic adaptation of SoC to app
lication needs. However, most multi
-
processor SoCs today involve at most 2
-
4 processors of conventional design; the larger
networks are more often found today in the industrial or university lab.


Although several years ago most embedded processors in ear
ly SoCs did not use
cache memory
-
based hierarchies, this has changed significantly over the years, and most
RISC and DSP processors now involve significant amounts of Level 1 Cache memory, as
well as higher level memory units both on and off
-
chip (off
-
chip

flash memory is often
used for embedded software tasks which may be only infrequently required). System
design
tasks and tools must consider the structure, size and configuration of the memory
hierarchy as one of the key SoC configuration decisions tha
t must be made.

IP Integration Quality and C
ertification
Methods and S
tandards


We
have emphasized the
design reuse aspects of SoC and the need for reuse of
both internal and externally sourced IP blocks by design teams creating SoCs. In the
discussion

of the design process above we mentioned issues such as IP quality standards
and the need for incoming inspection and qualification of IP. The issue of IP quality
remains one of the biggest impediments to the use of IP
-
based design for SoC [25].
The

quality standards and metrics available from VSIA and OpenMORE, and their further
enhancement help, but only to a limited extent. The industry could clearly use a formal
certification body or lab for IP quality that would ensure conformance to IP transf
er
requirements and the integration quality of the blocks. Such a certification process
would be of necessity quite complex due to the large number of configurations possible
for many IP blocks and the almost infinite variety of SoC contexts into which t
hey might
be integrated.

Certified IP would begin the deliver the ‘virtual components’ of the
VSIA vision.


In the absence of formal external certification (and such third party labs seem a
long way off, if they ever emerge), design groups must provide
their own certification
processes and real reuse quality metrics,
based on their internal design experiences.
Platform
-
based design methods help due to the advantages of pre
-
qualifying and
characterizing groups of IP blocks and libraries of compatible
do
main
-
specific
components.
Short of independent evaluation and qualification, this is the best that
design groups can do currently.


One key issue to remember is that IP not created for reuse, with all the
deliverables created and validated according to a
well
-
defined set of standards, is
inherently not reusable. The effort required to make a reusable IP block has been
estimated to be 50
-
200% more effort than that required to use it once; however, assuming
the most conservative extra cost involved implie
s positive payback with 3 uses of the IP
block. Planned and systematic IP reuse and investment in those blocks with greatest
SoC use potential gives a high chance of achieving significant productivity soon after
starting a reuse programme. But ad
-
hoc
attempts to reuse existing design blocks not
designed to reuse standards have failed in the past and are unlikely to provide the quality
and productivity desired.

Summary


In this chapter we have defined System
-
on
-
a
-
Chip and surveyed a large number of
the
issues involved in its design. An outline of the important methods and processes
involved in SoC design

define a methodology which can be adopted by design groups
and adapted to their specific requirements. Productivity in SoC design demands high
leve
ls of design reuse and the existence of 3
rd

party and internal IP groups and the chance
to create a library of reusable IP blocks (true virtual components) are all possible for most
design groups today. The wide variety of design disciplines involved in
SoC
mean that
unprecedented collaboration between designers of all backgrounds
-

from systems experts
through embedded software designers through architects through HW designers
-

is
required. But the rewards of SoC justify the effort required to succeed
.

References

1.

Merrill Hunt and Jim Rowson, “Blocking in a system on a chip”, IEEE Spectrum,
November 1996, pp. 35
-
41.

2.

Rochit Rajsuman, System
-
on
-
a
-
Chip Design and Test, Artech House, 2000.

3.

Michael Keating and Pierre Bricaud, Reuse Methodology Manual for Sys
tem
-
on
-
a
-
Chip Designs, Kluwer Academic Publishers, 1998 (First Edition), 1999 (Second
Edition), 2002 (Third Edition).

4.

International Technology Roadmap for Semiconductors (ITRS), 2001 edition.

URL:
http://public.itrs.net/

5.

Virtual Socket Interface Allian
ce, on the web at URL: http://www.vsia.org. This
includes access to its various public documents, including the original Reuse
Architecture document of 1997, as well as more recent documents supporting IP
reuse released to the public domain.

6.

The Virtual
Component Exchange (VCX). Web URL:
http://www.thevcx.com/

7.

Henry Chang, Larry Cooke, Merrill Hunt, Grant Martin, Andrew McNelly, and Lee
Todd, Surviving the SOC Revolution: A Guide to Platform
-
Based Design, Kluwer
Academic Publishers, 1999.

8.

K. Keutzer,
S. Malik, A. R. Newton, J. Rabaey, and A. Sangiovanni
-
Vincentelli,
“System
-
Level Design: Orthogonalization of Concerns and Platform
-
Based Design”,
IEEE Transactions on CAD of ICs and Systems, 19, 12, 1523, December 2000.

9.

Alberto Sangiovanni
-
Vincentelli an
d Grant Martin, “Platform
-
Based Design and
Software Design Methodology for Embedded Systems”, IEEE Design and Test of
Computers, Volume 18, Number 6, November
-
December, 2001, pp. 23
-
33.

10.

IEEE Design and Test

Special Issue on Platform
-
Based Design of SoCs
, N
ovember
-
December 2002, Volume 19, Number 6.

11.

G. Martin and F. Schirrmeister, “A Design Chain for Embedded Systems”, IEEE
Computer, Embedded Systems Column, March 2002, pp. 100
-
103.

12.

Grant Martin and Henry Chang (Editors), Winning the SOC Revolution: Experie
nces
in Real Design, Kluwer Academic Publishers, May 2003.

13.

Patrick Lysaght, “FPGAs as Meta
-
platforms for Embedded Systems”, Proceedings of
the IEEE Conference on Field Programmable Technology, Hong Kong, Dec 2002.

14.

Thorsten Groetker, Stan Liao, Grant Martin

and Stuart Swan, System Design with
SystemC, Kluwer Academic Publishers, May, 2002.

15.

Janick Bergeron, Writing Testbenches, 3rd. Edition, Kluwer Academic Publishers,
2003.

16.

G. Martin, and C. Lennard, Invited CICC paper, “Improving Embedded SW Design
and Inte
gration for SOCs”, Custom Integrated Circuits Conference, May 2000, pp.
101
-
108.

17.

Prakash
Rashinkar, Peter Paterson and Lee
na Singh, System
-
on
-
a
-
Chip Verification :
Methodology and Techniques, K
luwer Academic Publishers, 2001
.

18.

F. Balarin, M. Chiodo, P. Giu
sto, H. Hsieh, A. Jurecska, L. Lavagno, C. Passerone, A.
Sangiovanni
-
Vincentelli, E. Sentovich, K. Suzuki, and B. Tabbara, Hardware
-
Software Co
-
Design of Embedded Systems: The POLIS Approach, Kluwer
Academic Publishers, Dordrecht, The Netherlands, 1997.

19.

S
. Krolikoski, F. Schirrmeister, B. Salefski, J. Rowson and G. Martin, “Methodology
and Technology for Virtual Component Driven Hardware/Software Co
-
Design on the
System Level”, paper 94.1, ISCAS 99, Orlando, Florida, May 30
-
June 2, 1999.

20.

G. Martin and B. S
alefski, “System Level Design for SOC's: A Progress Report
-

Two Years On”, Chapter 25 in: System
-
on
-
Chip Methodologies and Design
Languages, editor Jean Mermet, Kluwer Academic Publishers, 2001, pp. 297
-
306.

21.

G. Martin, “Productivity in VC Reuse: Linkin
g SOC platforms to abstract systems
design methodology”, Chapter 3 in Virtual Component Design and Reuse, edited by
Ralf Seepold and Natividad Martinez Madrid, Kluwer Academic Publishers, 2001, pp.
33
-
46

22.

Axel Jantsch and Hennu Tenhunen (editors), Networks
on Chip, Kluwer Academic
Publishers, 2003.

23.

Vinod Kithail, Shail Aditya, Robert Schreiber, B. Ramakrishna Rau, Darren C.
Cronquist and Mukund Sivaraman, “PICO: Automatically Designing Custom
Computers”, IEEE Computer, September 2002, Volume 35, Number 9, p
p. 39
-
47.

24.

T.J. Callahan, J.R. Hauser, and J. Wawrzynek, “The Garp architecture and C
compiler”, IEEE Computer, April 2000, Volume 33 Issue 4 , April 2000 pp. 62
-
69.

25.

DATE 2002 Proceedings, Session 1A: “How to
Choose Semiconductor IP
?
:
Embedded Processors,

Memory, Software, Hardware”, Proceedings of
DATE 2002,
Paris, March 2002, p
p 14
-
17
.