Introduction to System on Chip

Introduction
• Technological Advances
▫ today’s chip can contains 100M transistors .
▫ transistor gate lengths are now in term of nano meters .
▫ approximately every 18 months the number of transistors on
a chip doubles – Moore’s law .
• The Consequences
▫ components connected on a Printed Circuit Board can now
be integrated onto single chip .
▫ hence the development of System-On-Chip design .
What is Soc
• SoCs are having a similar effect as ASICs, except
the scale is larger.
• The promise of an efficient “mix-and-match”
approach to product development, enabled at a
new level of design abstraction, holds the
potential to dramatically reduce the time, costs
and resources required to introduce new
products at consumer-market pace.
What is SoC ?
People A:
The VLSI manufacturing technology advances has made possible to put
millions of transistors on a single die. It enables designers to put systems-
on-a-chip that move everything from the board onto the chip eventually.
People B:
SoC is a high performance microprocessor, since we can program and
give instruction to the uP to do whatever you want to do.
People C:
SoC is the efforts to integrate heterogeneous or different types of silicon
IPs on to the same chip, like memory, uP, random logics, and analog
circuitry.

All of the above are partially right, but not very accurate!!!
 What is SoC ?
SoC not only chip, but more on “system”.
SoC = Chip + Software + Integration
The SoC chip includes:
Embedded processor
ASIC Logics and analog circuitry
Embedded memory
The SoC Software includes:
OS, compiler, simulator, firmware, driver, protocol stackIntegrated
development environment (debugger, linker, ICE)Application interface
(C/C++, assembly)
The SoC Integration includes :
The whole system solution
Manufacture consultant
Technical Supporting
What is SoC ?
 7

SoC
• (System On a Chip) The electronics for a
complete, working product contained on a single
chip
• Complex functionalities that previously required
heterogeneous components to be connected on a
PCB, are integrated within one single silicon
chip
 8

SoC: Evolution
• Technologies implementing embedded systems
evolved from micro-controllers and discrete
components to fully integrated SoCs
• Reason: advances in silicon process technology
enabling a complete system to be designed into
one or few integrated devices
▫ Space and Power reductions
▫ Increased Performance
Evolution of Microelectronics: the SoC Paradigm
Silicon Process Technology
•􀂃 0.13μm CMOS
•􀂃 ~100 millions of devices, 3 GHz internal Clock
 Paradigm Shift in SoC Design

System on a Chip

System on a board
 Evolutionary Problems
Emerging new technologies:
– Greater complexity
– Increased performance
– Higher density
– Lower power dissipation

􀂃 Key Challenges
– Improve productivity
– HW/SW codesign
– Integration of analog & RF IPs
– Improved DFT

􀂃 Evolutionary techniques:
- IP (Intellectual Property) based design
- Platform-based design
System on Chip interconnection

• Design reuse is facilitated if “standard”

internal connection buses are used .
• All cores connect to the bus via a standard
interface .
• Any-to-any connections easy but …
▫ Not all connections are necessary .
▫ Global clocking scheme .
▫ Power consumption .
• Standardization is being addressed by the
Virtual Socket Interface Alliance (VSIA)
System on Chip interconnection
• AMBA (Advanced Microcontroller Bus
Architecture) is a collection of buses from ARM
for satisfying a range of different criteria.
• APB (Advanced Peripheral Bus): simple strobed-
access bus with minimal interface complexity.
Suitable for hosting peripherals.
• ASB (Advanced System Bus): a multimaster
synchronous system bus.
• AHB (Advanced High Performance Bus): a high-
throughput synchronous system backbone. Burst
transfers and split transactions.
 The Benefits
• There are several benefits in integrating a large
digital system into a single integrated circuit .
• These include
– Lower cost per gate .
– Lower power consumption .
– Faster circuit operation .
– More reliable implementation .
– Smaller physical size .
– Greater design security .
 17

Features of SoC
Typically SoC incorporates
▫ A programmable processor
▫ On-chip memory
▫ Accelerated Functional Units (e.g., Digital
Encryption Standard block, MPEG2 decoder)
▫ Peripheral devices
Often mixed technology designs integrating
▫ Analog, RF Components
▫ Micro-electro-Mechanical Systems (MEMS)
▫ Optical input/output
 20

SoC Design
Time and design effort required to integrate
different types of components on a chip: a
bottleneck for SoC evolution
Design reuse to reduce time to market
▫ Use of parts from previous designs
▫ Making use of parts designed by third parties
Hardware and Software component model!
▫ All for PROVEN and tested solutions, avoiding re-
design and re-verification of real-time hardware
and real-time software
 21

SoC Design Flow (traditional)

 22

SoC Design Cycle

Requirements capture Sign-off

Global testing
(Initial) specification

Architectural division Integration

IP component
reuse Component design
/ programming Component testing

libraries

Implementation
 23

Simulation models
Sometimes physical prototypes, sometimes software
approximation of desired system
• Very helpful for:
▫ Tuning the specification (runs faster than full implementation)
▫ Predicting the system’s behavior and suggesting tests
▫ Performing crude early analysis of performance and
dimensioning
• But:
▫ No relation guaranteed between simulation and
further implementation
▫ Not meant for code production
▫ Formalisms: Matlab/Simulink, SystemC/C++,…
 24

SoC Design Abstractions

• ESL Design
▫ User functional level description
▫ C/C++, SystemC + TLM, Simulink, Matlab, UML.
• RTL Design
▫ Converts user specification into register level
description.
▫ Describes exact behavior of the chip, with I/O cxns.
▫ Verilog, VHDL, SystemC(!)
• Physical Design
▫ Takes the RTL + library of available logic gates
▫ Defines places for gates + wires them
 25

IP-based Design
• Intellectual Property Cores
▫ Parameterized components with standard interfaces facilitating
high level synthesis
• Cores available in three forms
▫ Hard
 Black-box in optimized layout form and encrypted simulation
model. Example: microprocessors
▫ Firm
 Synthesized netlist which can be simulated and changed if
needed
▫ Soft
 Register transfer level (RTL) HDLs; user is responsible for
synthesis and layout
 26

Platforms
• Embedded Applications built using
▫ Common architectural blocks and
▫ Customized application specific components
• Common architectures
▫ Processor, memory, peripherals, bus structures
• Common architectures and supporting
technologies (IP libraries and tools) together
called as platforms or platform-based designs
• Latest trend in the Embedded Systems
 27

Platform-based SoC
• Platform-based SoCs are systems embedded on a
chip that contain
▫ IP blocks like embedded CPU, embedded memory,
▫ Real-world interfaces (e.g., PCI, USB),
▫ Mixed signal blocks and
▫ Software components
 Device drivers, real-time operating systems and
application code
 28

Classes of Platforms

1. Full Application Platforms

▫ Platforms that let derivative product designers
create applications on top of hardware-software
architectures
 A set of hardware modules
 Example: Complex dual processor architecture
with hierarchical bus system tailored to a specific
product’s requirements
 A layer of firmware and driver software
 Examples: Philips’ Nexperia, TI’s OMAP
 29
Classes of Platforms (2)
2. Processor Centric Platforms
▫ Typically centered on specific processors
▫ Key software services like real-time OS kernel made
available through libraries
▫ Examples: ARM Micropack, ST Microelectronics ST100
3. Communication Centric Platforms
▫ Communication fabric optimized for specific
application
▫ Fabrics often bundled with specific processors
▫ Examples: ARM AMBA, IBM CoreConnect bus
architecture
 30

Classes of Platforms (3)

4. Configurable (Programmable) platforms
▫ Programmable logic added to the platform allows
consumers to customize using both hardware and
software
▫ Field programmable gate array (FPGA) added to
hard-coded processor centric platforms
▫ Examples: Altera Excalibur platform with ARM
cores, Xilinx Vertex II Pro
 Migration from ASICs to SoCs

ASICs are logic chips designed by end customers to perform a specific

function for a desired application.
ASIC vendors supply libraries for each technology they provide. In
most cases, these libraries contain predesigned and preverified logic
circuits.

ASIC technologies are:

 gate array
 standard cell
 full custom
 Migration from ASICs to SoCs
In the mid-1990s, ASIC technology evolved from a chip-set
philosophy to an embedded-cores-based system-on-a-chip concept.

An SoC is an IC designed by stitching

together multiple stand-alone VLSI
designs to provide full functionality for
an application.
An SoC compose of predesigned
models of complex functions known
as cores (terms such as intellectual
property block, virtual components,
and macros) that serve a variety of
applications.
 Three forms of SoC design
The scenario for SoC design is characterized by three forms:

1. ASIC vendor design: This refers to the design in which all the
components in the chip are designed as well as fabricated by
an ASIC vendor.
2. Integrated design: This refers to the design by an ASIC vendor
in which all components are not designed by that vendor. It
implies the use of cores obtained from some other source
such as a core/IP vendor or a foundry.
3. Desktop design: This refers to the design by a fabless
company that uses cores which for the most part have been
obtained from other source such as IP companies, EDA
companies, design services companies, or a foundry.
 SoC Design Challenges
Why does it take longer to design SOCs compared to traditional ASICs?

We must examine factors influencing the degree of difficulty and

Turn Around Time (TAT) (the time taken from gate-level netlist to
metal mask-ready stage) for designing ASICs and SOCs.
For an ASIC, the following factors influence TAT:
• Frequency of the design
• Number of clock domains
• Number of gates
• Density
• Number of blocks and sub-blocks

The key factor that influences TAT for SOCs is system integration (integrating
different silicon IPs on the same IC).
 SoC Design Challenges

Levarage Internal Bandwidth vs External Bandwidth

 SoCs vs. ASICs
 SoC is not just a large ASIC
 Architectural approach involving significant design reuse
 Addresses the cost and time-to-market problems

 SoC methodology is an incremental step over ASIC methodology

 SoC design is significantly more complex

 Need cross-domain optimizations

 IP reuse and Platform-based design increase
productivity, but not enough
 Even with extensive IP reuse, many of the ASICs
design problems remain, plus many more ...
 Productivity increase far from closing design gap
From ASICs to SoCs
Technology vs. Productivity vs. Complexity
 System on Chip benefits
Typical approach : With SoC
Define requirements Define requirements
Design with off-the shelf chips Design with off-the shelf cores
- at 0.5 year mark : first prototypes - at 0.5 year mark : first prototypes
- 1 year : ship with low margins/loss - 1 year : ship with high margin and
start ASIC integration market share

- 2 years : ASIC-based prototypes

- 2.5 years : ship, make profits (with
competition) Now : collection of cores

Proc IP cores
Up to now : collection of chips mem
mem
Ip- USB CPU DSP USB
CPU Sec hub hub

Typical : $70 Typical : $10 Ip- X

Sec Co-
DSP X Proc
 Typical applications of SoC
An SoC is a system on an IC that integrates software and hardware
Intellectual Property (IP) using more than one design methodology for the
purpose of defining the funcionality and behavior of the proposed system.
The designed system
is application specific. microprocessor, media processor,
GPS controllers, cellular phones,
GSM phones, smart pager ASICs,
digital television, video games,
Typical applications of SoC: PC-on-a-chip
 consumer devicecs,
 networking,
 communications, and
 other segments of the electronics industry.
A common set of problems facing everyone who
is designing complex chips
• Time-to-market pressures demand rapid development.
• Quality of results (performance, area, power) - key to market success.
• Increasing chip complexity makes verification more difficult.
• Deep submicron issues make timing closure more difficult.
• The development team has different levels and areas of expertise, and
is often scattered throughout the world.
• Design team members may have worked on similar designs in the past,
but cannot reuse these designs because the design flow, tools, and
guidelines have changed.
• SoC designs include embedded processor cores, and thus a significant
software component, which leads to additional methodology, process,
and organizational challenges.

Reusing macros (called “cores”, or IP) that have already been

designed and verified helps to address all of the problems above.
 Design for Reuse
To overcome the design gap, design reuse - the use of pre-
designed and pre-verified cores, or reuse of the existing designs
becomes a vital concept in design methodology.
An effective block-based design methodology requires an
extensive library of reusable blocks, or macros, and it is based
on the following principles:
 The macro must be extremely easy to integrate into the
overall chip design.
 The macro must be so robust that the integrator has to
perform essentially no functional verification of internals of the
macro.
The challenge for designers is not whether to adopt reuse,
but how to employ it effectively.
 Design for Reuse

To be fully reusable, the hardware macro must be:

• Designed to solve a general problem – easily configurable to fit
different applications.

• Designed for use in multiple technologies – For soft macros, this

mean that the synthesis scripts must produce satisfactory quality of results with a
variety of libraries. For hard macros, this means having an effective porting strategy
for mapping the macro onto new technologies.

• Designed for simulation with a variety of simulators – Good

design reuse practices dictate that both a Verilog and VHDL version of each model
and verification testbench should be available, and they should work with all the
major commercial simulators.

• Designed with standards-based interfaces – Unique or custom

interfaces should be used only if no standards-based interface exists.
 Design for Reuse – cont.

To be fully reusable, the hardware macro must be:

• Verified independently of the chip in which it will be used –
Often, macros are designed and only partially tested before being integrated into
a chip for verification. Reusable designs must have full, stand-alone testbenches
and verification suites that afford very high levels of test coverage.

• Verified to a high level of confidence – This usually means very

rigorous verification as well as building a physical prototype that is tested in an
actual system running real software.

• Fully documented in terms of appropriate applications and

restrictions – In particular, valid configurations and parameter values must be
documented. Any restrictions on configurations or parameter values must be
clearly stated. Interfacing requirements and restrictions on how the macro can be
used must be documented.
 Trade-offs among soft, firm, and hard cores

Soft
core
Resusability
portability
flexibility
Firm
core

Hard
core

Predictability, performance, time to market

 System on Chip cores
• One solution to the design productivity gap is
to make ASIC designs more standardized by
reusing segments of previously manufactured
chips.
• These segments are known as “blocks”,
“macros”, “cores” or “cells”.
• The blocks can either be developed in-house or
licensed from an IP company.
• Cores are the basic building blocks .
 System on Chip cores
• Soft Macro
– Reusable synthesizable RTL or netlist of generic library elements
– User of the core is responsible for the implementation and layout
• Firm Macro
– Structurally and topologically optimized for performance and area
through floor planning and placement
– Exist as synthesized code or as a netlist of generic library elements
• Hard Macro
– Reusable blocks optimized for performance, power, size and mapped to
a specific process technology
– Exist as fully placed and routed netlist and as a fixed layout such as in
GDSII format .
 System on Chip cores
• Locating the required cores and associated
contract discussions can be a lengthy process
– Identification of IP vendors
– Evaluation criteria
– Comparative evaluation exercise
– Choice of core
– Contract negotiations
• Reuse restrictions
• Costs: license, royalty, tool costs
– Core integration, simulation and verification
 Comparison of Different cores

IP Format Representation Optimization Technology Reusability

Hard GDSII Very High Technology Low

Dependent
Soft RTL Low Technology Very High
Independent
Firm Target Netlist High Technology High
Generic
Examples of IPs
IP Reuse and IP-Based SoC Design
 What is MPSoC

MPSoC is a system-on-chip that contains multiple instruction-set

processors (CPUs).

The typical MPSoC is a heterogeneous multiprocessor: there

may be
several different types of processing elements (PEs), the memory
system may be heterogeneously distributed around the machine,
and the interconnection network between the PEs and the memory
may also be heterogeneous.

MPSoCs often require

large amounts of memory. The device may
have embedded memory on-chip as well as relying on off-chip
commodity memory.
 The design process of SoCs
SoC designs are made possible by deep submicron technology. This
technology presents a whole set of design challenges including:
 interconnect delays,
 clock and power distribution, and
 the placement and routing of millions of gates.

These physical design problems can have a significant impact on

the functional design of SoCs and on the design process itself.

The first step in system design is specifying the required functionality.

The second step is to transform the system funcionality into an
architecture which define the system implementation by specifying the
number and types of components and connections between them.
 Define Hardware-Software Codesign

Hardware-Software Codesign is the concurrent and co-operative

design of hardware and software components of a system.

The SoC design process is a hardware-software codesign in

which design productivity is achived by design reuse.

The design process is the set of design tasks that transform an abstract
specification model into an architectural model.
SoC Co-design Flow
 Design Proces

A canonical or generic
form of an SoC design

These chips have:

• one (several) processors
• large amounts of memory
• bus-based architectures
• peripherals
• coprocessors
• and I/O channels
 Waterfall vs.
Spiral Design Flow

The traditional model for ASIC

development is often called a
waterfall model.

The project transitions from phase

to phase in a step function, never
returning to the activities of the
previous phase.
 Waterfall vs. Spiral Design Flow
As complexity increases, geometry shrinks, and time-to-market
pressures continue to escalate, chip designers are moving from
the old waterfall model to the newer spiral development model.
In the spiral model, the design team works on multiple aspects of
the design simultaneously, incrementally improving in each area
as the design converges on completion.

The spiral SoC design flow is characterized by:

 Parallel, concurrent development of hardware and software
 Parallel verification and synthesis of modules
 Floorplanning and place-and-route included in the synthesis
process
 Modules developed only if a pre-designed hard or soft macro
is not available
 Planned iteration throughout
Waterfall vs.
Spiral Design
Flow

Spiral SoC Design Flow

Goal: Maintain parallel

interacting design flow
 Top-Down vs. Bottom-Up

The classic top-down design process can be viewed as a recursive routine

that begins with specification and decomposition, and ends with integration
and verification:
 Write complete specifications for the system or subsystem being designed.
 Refine its architecture and algorithms, including software design and
hardware/software cosimulation if necessary.
 Decompose the architecture into well-defined macros.
 Design or select macros; this is where the recursion occurs.
 Integrate macros into the top level; verify functionality and timing.
 Deliver the subsystem/system to the next higher level of integration; at the
top level, this is tapeout.
 Verify all aspects of the design (functionality, timing, etc.).
 Top-Down vs. Bottom-Up

A top-down methodology assumes that the lowest level

blocks specified can, in fact, be designed and built. If it turns
out that a block is not feasible to design, the whole
specification process has to be repeated.
For this reason, real world design teams usually use a
mixture of top-down and bottom-up methodologies, building
critical low-level blocks while they refine the system and
block specifications.
Libraries of reusable hard and soft macros clearly facilitate
this process by providing a source of pre-verified blocks,
proving that at least some parts of the design can be
designed and fabricated in the target technology and perform
to specification.
 Design processes in flow diagrams
The first part of the design process consists of recursively developing,
verifying, and refining a set of specifications until they are detailed
enough to allow RTL coding to begin.

The specifications must completely describe all the interfaces between

the design and its environment, including:
 Hardware – Functionality; External interfaces to other hardware (pins,
buses, and how to use them); Interface to SW (register definitions); Timing;
Performance; Physical design issues such as area and power
 Software – Functionality; Timing; Performance; Interface to HW SW
structure, kernel

Type of of specifications:
 Formal specifications – the desired characteristics of the design are
defined independently of any implementation.
 Executable specifications – are typically an abstract model for the
hardware and/or software being specified, and currently more useful for
describing functional behavior in most design situations.
 The System Design
Process
Determining the optimal architecture
(cost and performance) involves a
set of complex decisions, such as:
• What goes in software and what
goes in hardware
• What processor(s) to use, and how
many
• What bus architecture is required
to achieve the required system
performance
• What memory architecture to use
to reach an appropriate balance
between power, area, and speed.

Solution: modeling of several

alternative architectures
 ASIC Typical Design Steps
Typical ASIC design
can take up to two
Top Level Design years to complete
Unit Block Design
Unit Block Verification
Integration and Synthesis
Trial Netlists
Timing Convergence
& Verification

System Level Verification

Fabrication

DVT Prep

DVT
6 12 12 4 14 ?? 5 8 Time in Weeks

48 Time to Mask order

61
 SoC Typical Design Steps
• With increasing Complexity
Top Level Design
of IC’s and decreasing
Unit Block Design
Geometry, IC Vendor steps
Unit Block Verification of Placement, Layout and
Integration and Synthesis Fabrication are unlikely to
Trial Netlists be greatly reduced.
Timing Convergence
& Verification • In fact there is a greater
System Level Verification risk that Timing
Convergence steps will
Fabrication
involve more iteration.
DVT Prep

DVT • Need to reduce time before

4 4 2 14 5 4 Vendor Steps.
Time in Weeks
24 Time to Mask order • Need to consider Layout
33
issues up-front.
 SoC Typical Design Steps
• SoC Architecture already defined.
Top Level Design Flexible to scale in frequency and
Unit Block Design complexity.
Unit Block Verification Allows new IP cores, new technology
Integration and Synthesis to be integrated.
Trial Netlists
• Separate the design of the reusable
Timing Convergence
& Verification IP from the design of the SoC.
Build the SoC from library of tested IP.
System Level Verification

Fabrication • Unit design consists only of any

additional core features or wrapping
DVT Prep
new IP to enable integration.
DVT
4 4 2 14 5 4 • Reusable IP purchased from external
Time in Weeks sources, developed from in-house
24 Time to Mask order designs or designed as separate
project off critical SoC development
path.
 Design Methodology
A Front-End ASIC Design Flow
 Design Methodology
A Back-End Design Flow or Generic Physical Flow.
ASIC Methodology
SOC Methodology
SOC Methodology Evolving ...
How to Design an SOC
How to Design an SOC
How to Design an SOC
How to Design an SOC
How to Design an SOC
 System on Chip - Testing
• SOCs are complex designs combining logic, memory and
mixed-signal circuits in a single IC

I/O pads
Main SOC testing challenges
CPU Self-test
core control • Core level test: Embedded cores are
User-defined logic

Memory DSP
tested as a part of the system
I/O pads
I/O pads

array core
• Test access: Due to absence of physical
Legacy Interface access to the core peripheries, electronic
core control
access mechanism required
IP hard Embedded
core DRAM • SOC level test: SOC test is a single
composite test including individual core,
1149.1 TAP controller
and UDL test and test scheduling

Test data volume for core-based SOC designs is very high.

• New techniques are required to reduce testing time, test cost, and
the memory requirements of the automatic test equipment (ATE)
 Verification

Today about 70% of design

cost and effort is spent on
verification.
Verification teams are often
almost twice as large as
the RTL designers at
companies developing ICs.
Traditionally, chip design
verification focuses on
simulation.
However, new verification
techniques are emerging.
 Design for Integration
A key issue in SOC design is integration of silicon IPs (cores).
Integration of IPs directly affects the complexity of SOC designs and also
influences verification of the SOC.
Verification is faster and easier if the SOC interconnect is simple and
unified (use an on-chip communication system or intelligent on-chip bus).

There is no standard for OCBs; they are chosen almost exclusively by the
specific application for which they will be used and by the designer's preference.

Two main types of OCBs (on-chip bus) and their characteristics

OCB Speed Bandwidth Arbitration Example

System High High Complex ARM AHB

Peripheral Low Low Simple PCI Bus

 A Typical Gateway SoC Architecture
An example of typical gateway VoIP (Voice over Internet Protocol)
system-on-a-chip diagram.
A gateway VoIP SoC is a device used for functions such as vocoders,
echo cancellation, data/fax modems, and VoIP protocols.
 A Traditional SOC Architecture (bus-based)

In a typical SOC, there

are complex data flows
and multiple cores such
as CPUs, DSPs, DMA,
and peripherals.

Therefore,
resource sharing
becomes an issue,
communication between
IPs becomes very
complicated.
 82

Multi-processor SoC (MPSoC)

• Full application platform
• Multiple processors
▫ CPUs, DSPs, etc.
▫ Hardwired blocks
▫ Mixed-signal
• Custom memory system
• Lots of software
 83

Philips Nexperia

• Also a full application platform

• Multimedia applications: set-top box, etc.
• 2 CPUs, 3 busses, several accelerators, I/O
devices.
 84

Philips Nexperia
 85

TI OMAP
• Targets
communications 2D/3D Imaging &
ARM11 TMS320C55x Graphics Video
, multimedia. + VFP DSP Accelerator Accelerator
(IVA)

• Multiprocessor
with DSP, RISC L3 Interconnect

L4 Interconnect
LCD

Peripherals
I/F Memory Internal
Security

Camera
Video Controller SRAM
I/F
Out

OMAP2420
 86

ST Nomadik
• Targets mobile multimedia.
• A multiprocessor-of-multiprocessors.
 87

Open Multimedia
Applications Platform
 88

OMAP
• OMAP Application processor has a dual-core
architecture: ARM9 + TMS320C55
• OMAP design chain includes
▫ Software IPs: OMAP supports several
RTOS’s to suit different applications
▫ Application and Middleware: Ported
applications and middleware like MPEG-
4 decoding and audio playback
 89

Design Chain for OMAP

 90

OMAP Hardware Architecture

 91

OMAP Hardware Architecture

• ARM RISC core is well suited for control code
(OS, User Interface, OS applications)
• DSP best suited for signal processing
applications like video, speech processing, audio
• Power efficient because signal processing task on
DSP consumes much less power than on ARM
 92

Example Application
• Video-conferencing
▫ C55x DSP can process in real-time full video
conferencing application (audio and video at 15
images/sec) using only 40% of the available
computational capability
 Can manage other applications concurrently
▫ ARM processor can handle OS operations and
other OS applications (may be Word, Excel, etc.)
▫ Less power consumption on the whole
 93

Peripherals
• Includes numerous interfaces to connect
peripherals or external devices from either the
DSP or GPP
• Some interfaces
▫ Camera and Display interface
 Serial unidirectional compact camera port, 8-bit
parallel interface, 8/16 bit bi-directional display
interface, OMAP internal LCD controller
▫ Several Serial interfaces
 SPI, McBSP, I2C, USB, UART
 94

Software Architecture
• Defines an interface scheme that allows GPP to
be the system master
▫ Called the DSP/BIOS Bridge
• DSP/BIOS Bridge provides communications
between GPP tasks and DSP tasks
• High level application developers use a set of
DLLs and drivers
 95

OMAP2
• Includes multiple engines executing multiple tasks
• An ARM 11 based microprocessor runs the OS and
performs supervisory control
• DSP core focuses on audio codecs, echo cancellation and
noise suppression
• 3D graphics engine enables sophisticated graphics
rendering
• Video/imaging accelerator handles streaming MPEG4
video and mega-pixel resolution camera
• Digital baseband processor implements network
communications as a cellular modem handling voice and
data
 96

OMAP 2 Architecture
 97

OMAP2
All blocks operate simultaneously
▫ No degradation in quality of any service
▫ Devices remain highly responsive
To conserve power each of these subsystems can
be shut down when not used
SoC suited for implementation of Smart Phone
 98

Digital Media Processor

Functionalities expected in a portable media
system
▫ Live preview: Capture, process, display
▫ Live video capture: Compresses
▫ Live image capture: Compresses
▫ Live audio capture: Compresses
▫ Video decode/playback
▫ Still image decode/display
▫ Audio decode/playback
▫ Photo printing
Several of these modes operate concurrently
 99

DM 310 Media Processor

• Four subsystems: imaging/video, DSP, coprocessor,
ARM core
• Imaging/Video system: CCD controller, preview engine,
onscreen display, video encoder
• DSP: TMS32054X operating at 72MHz (Max.) performs
bulk of audio/image/video processing operations
• Co-processors: SIMD engine (8 or 16 bit), Quantization,
Variable length coder working concurrently
• ARM Core: manages system level tasks, controls all
components on chip except DSP and its co-processor
 100

TMS320DM310 Architecture
 101

Application: Still Camera Engine

102
 103

Configurable SoC
• Consisting of
▫ Processor
▫ Memory
▫ On-chip reconfigurable hardware parts for
customization to application
• Towards application specific programmable
products
 104

FPGA-based RC
• Programmable fabric that can be dynamically
reconfigured
• Mapping to FPGA
▫ Only the time consuming computations are
mapped
▫ Computation expressed in HDL
• Structure
▫ FPGA + Memory
 105

Programmable Platforms
• Several
products
incorporate
microprocessor
and FPGA on
one chip
 106

Triscent A7 SoC

CSL:
performs
basic
combinational
and
sequential
logic functions
 107

Configurable processors
• Configurability:
▫ Processor parameters (cache size,
registers, etc.)
▫ Instructions
• Result:
▫ HDL model for processor.
▫ Software development environment.
 The Drawbacks
• The principle drawbacks of SoC design are
associated with the design pressures imposed
on today’s engineers , such as :

– Time-to-market demands .
– Exponential fabrication cost .
– Increased system complexity .
– Increased verification requirements .
 Major SoC Applications
• Speech Signal Processing .
• Image and Video Signal Processing .
• Information Technologies
▫ PC interface (USB, PCI,PCI-Express, IDE,..etc)
Computer peripheries (printer control, LCD monitor
controller, DVD controller,.etc) .
• Data Communication
▫ Wireline Communication: 10/100 Based-T, xDSL,
Gigabit Ethernet,.. Etc
▫ Wireless communication: BlueTooth, WLAN,
2G/3G/4G, WiMax, UWB, …,etc