Lecture 9RAS 1

Platform-based SoC Design

Res Saleh

University of British Columbia

Dept. of ECEres@ece.ubc.ca

Lecture 9RAS 2

Evolution from ASICs to Platform-Based Design

• For SoC’s, Platform-Based Design is the next logical evolution in Design Reuse.

• In TDD, Reuse in ASIC design is of Cell-level Libraries

• In BBD, Reuse in hierarchical design is of major IP Blocks (e.g., digital blocks built out of standard cells)

• In PBD, Reuse is of Collections of IP blocks organized into HW-SW arachitectures: also known as Integration Platforms

Lecture 9RAS 3

Why Platforms?

• Any given space has a limited number of good solutions to its basic problems

• A platform captures the good solutions to the important design challenges in that application space

• A platform reuses a set of Hardware/Software architectures

In general, a platform is an abstraction that covers a number of possible refinements into a lower level.

For every platform, there is a view that is used to map the upper layers of abstraction into the platform and a view that is used to define the class of lower level abstractions implied by the platform.

Lecture 9RAS 4

SoC Platform Design Components

SoC Verification FlowRapid Prototype forEnd-Customer Evaluation

SoC Derivative DesignMethodologies

System-level performanceevaluation environmentHW/SW Co-synthesisSoC IC Design Flows

ApplicationSpace

Methodology / Flows:

Foundation Block

MEM

FPGACPU Processor(s), RTOS(es)

and SW architecture

*IP can be hardware (digitalor analog) or software.IP can be hard, soft or

‘firm’ (HW), source orobject (SW)

Scaleablebus, test, power, IO,clock, timing architectures

+ Reference Design

Foundry-SpecificPre-Qualification

Foundry Targeting Flow

Programmable IP

SW IP

Hardware IP

Pre-Qualified/VerifiedFoundation-IP*

Lecture 9RAS 5

Bluetooth Platform

ARM 7TDM I

DAP I/F

RADIOI/F

SPEEC HI/F

SHAREDM EM O RY

CO NTRO LLER

LM C

B RIDG E

POW ER &CLO CK

CO NTR O LDM A

SM C

PLLCLO CKS

SHAREDM EM O RY

TIC

DEC O DER

ARBITER

AHB APB

ADC

text ACI USBUARTUARTTIM ERSPICG PIOW ATCHDO G

Soft IPHard IP

Soft IP

Hard IPHard IP

Hard IP

On-chip BusBBC

Lecture 9RAS 6

Buses for SoC Platforms

Have to standardize buses to allow relatively quick connections of IP blocks in an SoC.

Some common buses are:• AMBA (ARM)

• CoreConnect (IBM)

• OCP-IP (VSIA Standard)

• SoC-it (MIPS)

Lecture 9RAS 7

On-chip Buses

• Embedded processors cores need to communicate with memory and I/O devices

• Want to be able to add various IP blocks seamlessly

• Communication is typically done using on-chip buses– Shared communication link between IP blocks

• Two main types of buses

– Relatively short CPU-memory bus for high-speed access

– Relatively long I/O bus for various I/O devices in the system operating at different speeds, typically slower than CPU-memory operations

– Could combine buses to reduce overhead, but speed differences usually require separate buses with a connecting bridge

Lecture 9RAS 8

AMBA Bus Architecture

Lecture 9RAS 9

How AMBA AHB Works

This diagram illustrates the structure required to implement an AMBA AHB design with three masters and four slaves.

Decides who gets priority

With multiple Masters

Enables a specific

Path from Slave to Master

Lecture 9RAS 10

Set Top Box Platform Requirements

• Cable Modem compliant• Digital Video Broadcast compliant• MPEG-2 Video and AC-3 Audio Decoding• NTSC/PAL/SECAM TV Encoder• RAM and Hard Disk Interfaces• Graphics Accelerator for gaming, internet content, etc.• High Speed Interfaces: USB 2.0 and 10/100 Ethernet• UART, IR, V.90 Modem, SmartCard and GPIO

• Need suitable embedded microprocessor to support a variety of applications such as gaming and web browsing

Lecture 9RAS 11

MIPS in Set-Top Box Designs

Processor Usage for Set-Top Box Designs

MIPS27%

Sti15%microSPARC

12%PowerPC

9%

SH8%

x865%

ARM4%

other20%

Lecture 9RAS 12

Set Top Box Platform

MIPS

Core

Lecture 9RAS 13

1st Key Trend

• 100M logic gates in 90nm = Logic of 1000 ARM7’s

• Number embedded processors in SoC rising:– ST: recordable DVD 5

– Hughes: set-top box 7

– Agere: Wireless base station 8

– ST: HDTV platform 8

– Latest mobile handsets 10– NEC: Image processor 128

– In-house NPU >150

• New area of Research on MP-SoC (multiprocessor SoC)

– architecture, interconnection, software programming, power

Lecture 9RAS 14

STm8000 Multiprocessor for Multimedia Applications

H/W InterconnectProcessor

STm8000

MPEG2video

decoder

DRAM

Displaysubsystem

STbus

DVdecoder

2D graphics (blitter)

Video pre-processor

DMA engine

ProcessorST220 (audio)

Processor ST220 (audio)

Processor SH4

(host)

I/O:uarts, I2C, PWM,

capture timers, MAFE,PIO, etc…

EMILMIVideo Input

InterfaceUSB HDDI

Encode accelerator

Processor ST220 (video)

Flash �4 Processors

Lecture 9RAS 15

2nd Key Trend:

• Embedded SW content in SoC is increasing significantly • eSW: Current application complexity

– Set-top box: >1 million lines of code– Digital audio processing: >1 million lines of code– Recordable DVD: Over 100 person-years effort– Hard-disk drive: Over 100 person-years effort

• In multimedia systems– SW cost (licenses) 6X larger than H/W chip cost– eSW uses 50% to 80% of design resources

eSW now an essential part of SoC productsHW/SW co-design, co-verification issues are importantsoftware programmers must program in parallel, use parallel compilers, debuggers, etc.

Lecture 9RAS 16

Conf. Proc.

MP-SoC Platform Example

NetworkNetwork--onon--ChipChip HS I/O

Specializedco-processors

ExternalRAM

DataPlane

DataPlane

PCI-X

Host Processor

HS I/O

FPGACo-proc.

I/OMemI/O

FPGAFPGA FPGAH/W PEeFPGA

H/W PEeSoG

. . .eFPGAeFPGA

Conf. Proc. eMem

eFPGA

Proc. ElementProc. ElementArray 1Array 1

eMemcoproc

eFPGA eFPGA

H/W

Soft logic

Mem

Processor

eDRAMeSRAM

Proc. ElementProc. ElementArray NArray N

Lecture 9RAS 17

Network-on-Chip Topologies

Lecture 9RAS 18

Trend of Verification Effort in the Design

• Verification portion of design increases to anywhere from 50 to 80% of total development effort for the design.

Code Verify (30 ~ 40%)Synthesis P&R

Code Verify (50 ~ 80%) Synthesis P&R

1996

300K gates

2000

1M SoC

Verification methodology manual, 2000-

TransEDA

Lecture 9RAS 19

Percentage of Total Flaws

• About 50% of flaws are functional flaws.

– Need verification method to fix logical & functional flaws

����������������� ������� ��������

Clocking

5%

Race

5%

Power

4%

Other

9%

Logical/

Functional

45%

Slow Path

13%

Noise

12%

Yield

7%

Race 5%

Lecture 9RAS 20

Bug Fixing Cost in Time

• Cost of fixing a bug/problem increases as design progresses.

– Need verification method at early design stage

Behavioral

Design

RTL

Design

Gate Level

Design

Device

Production

Cost ofFixing

a Problem

110

100

1000

Lecture 9RAS 21

Verify Early and Often

• Use code coverage tools– Aim for 100% statement and path coverage

• Bottom-up verification (divide & conquer)– Rigorous testing of sub-blocks before they are integrated– Return to sub-blocks tests if necessary to achieve 100%

coverage• Use industry standard tools and methodology

– Provides interoperability between testbenches for all IP – Random test generation and functional coverage

• Set of verification tests– Compliance testing to verify basic functions comply to specs– Focused testing to verify full functionality– Corner/Adversarial testing to try to break the design– Random testing to complete coverage

Lecture 9RAS 22

Overview of Verification Methodologies

Simulation

HardwareAcceleratedSimulation

Emulation

FormalVerification

Semi-formalVerification

���������

����� �

���� �����

���� ���

���������

����� �

���� �����

���� ���

���������

����� �

���� �����

���� ���

���������

����� �

���� �����

���� ���

������������������������ �������

���������������������

Transaction-based

Lecture 9RAS 23

Speed Comparison

0 kHz

SoftwareSimulation

10 kHz

1MHz

Hardware-AcceleratedSimulation(1/2 blocks)

Hardware emulation

(entiresystem)

100kHz

500KHz

100Hz

100 kHz

Speed (Cycles/sec, log scale)

10MHz 1~10MHz

PrototypingSemi-formal(Assertion-

based verification)

50-70Hz

Lecture 9RAS 24

Design Complexity

Depends on the components on the board

1M~5M gatesPrototyping

Limited to about 500 flip-flops due to state explosion

< 10K gatesFormal verification

Depends on the number of FPGA’s in the architecture

1M~16M gatesEmulation/Hardware-accelerated simulation

CPU time is the issueVirtually unlimitedSimulation/Semi-formal verification

CommentsGate count

Lecture 9RAS 25

HW-SW Co-Verification

– HW-SW co-simulation

– ISS

– RTOS simulator

HW/SWPartitioning

HWDevelopment

SWDevelopment

HW refinement

SoftwareVerification

FunctionalVerification

Co-Verification

SW refinement(RTOS

mapping)

HW-SW

– High-level synthesis– Testbench automation– IP accelerator

SystemSpec.

SystemDesign

HW/SW

HW IP

SW IP

Lecture 9RAS 26

Language Evolution for SoC Design

• New languages are developed to fill the productivity gap.

Verilog

VHDL

C

C++

JAVA

AssemblySystemC

SystemVerilogVera

TestBuilder

����������������������������������������

��� ���������������� ���������������� ���������������� �������������

����������������������������������������

��� ���������� ���������� ���������� �������

����������������������������������������

��� ��������������� ��������������� ��������������� ������������

Schematic

���� ������� ���������

Lecture 9RAS 27

SystemC

• SystemC is a modeling platform consisting of

– A set of C++ class library,

– Including a simulation kernel that supports hardware modeling concepts at the system level, behavioral level and register transfer level.

• SystemC enables us to effectively create – A cycle-accurate model of

• Software algorithm,

• Hardware architecture, and

• Interfaces of System-on-a-Chip.

• Program in SystemC can be – An executable specification of the system.

Lecture 9RAS 28

while(true) {

inst = fetch( pc );

opcode=decode(inst);

switch( opcode ){

…

case ADD:

…

break;

}

}

Instruction Set Simulator (ISS)

• An ISS simulates the instructions with/without timing considerations

• Some vendors provide an ISS for the processor core

• Code simply grabs the opcode and executes an associated set of statements in C

• Connection to hardware is carried out through BFMs

Main loop of interpretive ISS

Lecture 9RAS 29

Bus Functional Models (BFM)

• When designing an SoC, you may not have all the blocks ready at the same time, for example, custom blocks.

• However, verification must proceed. We can’t delay the schedule just because one or two pieces are missing.

• Use Bus Functional Model (BFM) in place of actual IP• A BFM, usually coded in C and linked into the RTL through a

PLI, is a behavioral model of the missing block. When its inputsare stimulated, it produces the same response as the real block.

• Serves as a placeholder until the real block is ready. Sometimes encrypted BFMs are delivered by IP vendors rather than RTL or layout views to protect their designs.

Lecture 9RAS 30

Core model

ISS

Cycle-Accurate Bus Modeling

• For more accurate modeling

– Build a cycle-accurate system model in C or SystemC

– Replace blocks with a cycle-accurate BFMs

Memory

IP

IP

Cycle-accurate Bus model

AccuratePerformanceEstimation

...

...

Behaviormodel

------

------

------

transaction

BFM BFM BFM

RTLmodel

Lecture 9RAS 31

Summary of SoC/DSM Design Course

ST20ST20

MPEG2 MPEG2 VideoVideo

Dolby Dolby AC3AC3

FEIFEI

LinkLink

2 x 3 DAC2 x 3 DAC

Denc

Denc

Time-to-market:Rapidly changing

Consumer markets.

Expanding markets in wireless, automotive,

multilmedia, networks

Deep submicron effects:Power, Wire delays, Crosstalk

Electromigration, IR drop, AntennaSubthreshold and gate leakageMask complexity (OPC, PSM)

PVT variations

Complex systems:Digital/Analog IPs

MP-SoC

Network-on-Chip

Multithreaded SW

HW/SW Co-designand Co-verificationSystem Validation