Post on 23-May-2018
PMCU Lecture 3
1
Lecture 3RAS 1
Platform-based SoC Design
Res SalehUniversity of British Columbia
Dept. of ECEres@ece.ubc.ca
Lecture 3RAS 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
PMCU Lecture 3
2
Lecture 3RAS 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 3RAS 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)
*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*
PMCU Lecture 3
3
Lecture 3RAS 5
Case Study: Mixed-Signal Platform Design
• Bluetooth Wireless SoC Platform
• Bluetooth is the marketing name for a short range wireless standard
• Initially promoted by Ericsson, IBM, Intel, Nokia and Toshiba.
CustomerSpecific IP
ARM7TDMI
DMAController
InterruptController
MemoryController
Off-chipFlash
Off Chip SRAM
AMBA I/F
TIC
UART
Timers
GPIO
Watchdog
Bluetooth Core
CVSDCodec
LinkController
DataRAM
ProgRAM
Bridge
AHB
APBUARTTest
Module
GPIOTest
Module
RadioTest
Module
CodecModel
Other IP
Bluetooth SoC Platform
Bluetooth SOC Verification Environment
Other IPTest
Module
Lecture 3RAS 6
Bluetooth Basics
• Addresses wireless personal area networking (WPAN)• Designed for:
– Short range (10m – 100m)– Low power (1mW to 10mW)– Low cost (<$5)– Support both voice and data communications
PMCU Lecture 3
4
Lecture 3RAS 7
Wireless Standards Comparison
Bluetooth HomeRF 802.11bFrequency Band 2.4GHz 2.4GHz 2.4GHz
Technology Frequency Hopping Spread Spectrum
Frequency Hopping Spread Spectrum
Direct Sequence Spread Spectrum
Performance 720Kbps 1.6Mbps 11Mbps
Range 10 meters 50 meters 100 meters
Power Very Low Medium Medium
Relative Cost Low/ Very Low Medium/Low Medium
Target Applications Wireless DataWireless Voice
Personal Networks
Wireless DataWireless Voice
Wireless Data
Fixed N/W Support PPP, Ethernet n/a Ethernet
Key Features Very Low PowerVoice and Data
RoamingLow Cost
Good noise immunity
Voice and DataModerate Cost
Good Performance
Promoters 2000+ <50 ~100
Regional Support Worldwide US US/Asia
Shipping Now Now Now
Technology
Lecture 3RAS 8
Bluetooth Chip
RFBasebandcontroller
Link Manager
Host
HW HW SW
PMCU Lecture 3
5
Lecture 3RAS 9
Bluetooth Protocol Stack
Host Controller Interface
RF (radio and antenna)
Aud
io
(SC
O)
Con
trol
Aud
io(S
CO
)
Cont
rol
L2CAP
BasebandLink Manager
Transport Interface
ApplicationRFCOMM SDP
Data (ACL)
Data (ACL)Hos
tBl
ueto
oth
Mod
ule
Transport Bus
Digital Hardware
Analog/RF Hardware
Embedded Software
Running on processor�
e.g., PC, printer,
PDA, cellphone, etc.
Lecture 3RAS 10
Bluetooth Chip
• Link Manager– Manages creation, configuration and termination of Bluetooth
device to device links.– Manages the data flow between the L2CAP (Logical Link
Control and Adaptation Protocol) and baseband through the established channel.
• SCO (Synchronous Connection Oriented) – voice• ACL (Asynchronous Connection Less) - data
• Baseband Controller– Performs all DSP operations
• RF– Radio and antenna to transmit and receive data
PMCU Lecture 3
6
Lecture 3RAS 11
Modulation Scheme
• Operates in 2.402-2.4835 GHz range (uses the ISM band)• Employs FHSS (Frequency Hopped Spread Spectrum) technique
with 79 channels– The transmission hops through 79 different frequencies in a
pseudo-random manner.– Channels spaced 1MHz apart.– Each packet is transmitted on one frequency
• The modulation technique in Bluetooth is GFSK (Gaussian Frequency Shift Keying) => 1Mbps. (actual 721 kbps)– Employing different modulation technique could increase link
speed but would also increase complexity of device.
Lecture 3RAS 12
Bluetooth Transmission Protocol
fk+2
625 µsSlot 3
fk+3
Frame 2
Slot4
t
Frequency hops from Slot to Slot to SlotFrames define matched Master / Slave Slot transmissions
fk+1
Frame 1
Slot2
Complete packet transmission occurs during a Slot
Master
Slave1
fk
625 µsSlot 1
PMCU Lecture 3
7
Lecture 3RAS 13
Multi-Slave Transmission
Master
Slave1
fk fk+1 fk+2
t
fk+3 fk+4 fk+5
• The Bluetooth master interleaves traffic between multiple simultaneously active slaves
• Each Master can support up to 7 simultaneously active slaves
Slave2
Lecture 3RAS 14
Multi-Slot Framing
Frame
fk+3
Slot4
t
• To increase bandwidth Bluetooth can aggregate multiple slots in one direction of the transmission (i.e. asymmetric transmission)
• Eliminates turnaround time and reduces packet overhead• Note that frequency DOES NOT change during the multi-slot transmission
• Bluetooth supports 1/1, 3/1, and 5/1 framing (example above is 3/1)• 5/1 framing supports up to 721Kbps, Bluetooth’s maximum capacity
Master
Slave1
fk
625 µsSlot 1 Slot2
fk
Slot 3
fk
PMCU Lecture 3
8
Lecture 3RAS 15
0
10
20
30
40
50
60
70
80
0 10 20 30 40 50 60 70 80 90 100
0
10
20
30
40
50
60
70
80
Piconet A Contention
Total Transmission Slots: 100 Transmission Slots Hit: 0 Transmission Efficiency: ~100%Active Piconets: 1
Each Bluetooth Piconet Randomly Changes Frequency Slot by Slot
Lecture 3RAS 16
Bluetooth Platform
• CMC’s purchase from a third-party for the System-on-ChipResearch Network (SoCRN) includes:– Bluetooth Soft Reference Platform (BSRP)
• A core architecture
– Baseband controller (BBC)• Link management controller
– BlueSoft (Software protocol stack)
PMCU Lecture 3
9
Lecture 3RAS 17
Bluetooth Platform
ARM 7TDM I
DAP I/F
RAD IOI/F
SPE EC HI/F
SH AR EDM EM O RY
CO N TRO LLE R
LM C
BR ID G E
P O WE R &CLO C K
CO N TRO LD M A
S M C
P LLCLO C K S
SH ARE DM EM O R Y
TIC
DE CO D ER
AR BITER
AH B APB
AD C
te xt AC I US BUAR TU ARTTIM E RSPICG PIOW ATC H
D O G
Soft IPHard IP
Soft IP
Hard IPHard IP
Hard IP
On-chip BusBBC
Lecture 3RAS 18
Baseband Controller (BBC)
Radio Interface(RIF)
Serial Data Path(SDP)
EncryptionDecription
PayloadWhitening
PayloadCRC
Header + HEC Header FEC Tx and Rx DataPaths
Symbol TimingRecovery
(STR)
HeaderWhitening
Payload FEC
PISO/SIPO+
Shared RAMClient Interface
Shared Memory Arbiter(SMC)
Channel Controller(CHC)
Timing Chain(TIM)
Clock andPower
Management
Speech Processor Module(SPM)
LMC Sequencer(LMC)
Tx BitStream
RxSampleStream
RadioControl I/F
SynthProg I/F
PCM PortHost Data
Access Port
ProcessorData
Access Port
DualShared
RAMPort
SystemSignal
Interface
Radio Controller(RFC)
Microcode Sequencer(SEQ)
RegisterBank
InterruptController
PMCU Lecture 3
10
Lecture 3RAS 19
Platform deliverables
• From Vendor– Complete RTL in
VHDL/Verilog HDL– Simulation test-benches
and scripts– Synthesis scripts– Example Application
Executable– Documents include
specifications, Application/Implementation Notes
• Additional IP requirements – ARM7TDMI– AMBA bus interfacing– PLL– ADC/DAC– Oscillator– Memory Blocks– RF Block for front-end
implementation
Lecture 3RAS 20
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)
PMCU Lecture 3
11
Lecture 3RAS 21
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 3RAS 22
AMBA Bus Architecture
(current) (legacy) (current)
PMCU Lecture 3
12
Lecture 3RAS 23
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 3RAS 24
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
PMCU Lecture 3
13
Lecture 3RAS 25
MIPS in Set-Top Box Designs
Processor Usage for Set-Top Box Designs
MIPS27%
Sti15%microSPARC
12%PowerPC
9%
SH8%
x865%
ARM4%
other20%
Lecture 3RAS 26
Set Top Box Platform
MIPS
Core
PMCU Lecture 3
14
Lecture 3RAS 27
1st Key Trend
• ASIC/ASSP ratio: 80/20 in 2000, 50/50 now– In-house ASIC design is down– Replaced by off-the-shelf, programmable ASSP
• Current 130nm, 90nm SoC’s: 10M$ ~100M$ design cost• 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
Lecture 3RAS 28
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
PMCU Lecture 3
15
Lecture 3RAS 29
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 importantapplication-driven verification essential but time-consuming
Lecture 3RAS 30
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
PMCU Lecture 3
16
Lecture 3RAS 31
Network-on-Chip Topologies
Lecture 3RAS 32
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
PMCU Lecture 3
17
Lecture 3RAS 33
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 3RAS 34
Bug Fixing Cost in Time
• Cost of fixing a bug/problem increases as design progresses.– Need verification method at early design stage
BehavioralDesign
RTLDesign
Gate LevelDesign
DeviceProduction
Cost ofFixing
a Problem
1
10
100
1000
PMCU Lecture 3
18
Lecture 3RAS 35
SoC Economic Trends: Mask NRE
– For Bluetooth, the $5 ASP with 20% profit margin (i.e., $1) requires that we sell over 2M parts just to break even
– This does not include other sources of design NRE
Source: Dataquest
Lecture 3RAS 36
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
PMCU Lecture 3
19
Lecture 3RAS 37
Overview of Verification Methodologies
Simulation
HardwareAcceleratedSimulation
Emulation
FormalVerification
Semi-formalVerification
���������
����� �
���� �����
���� ���
���������
����� �
���� �����
���� ���
���������
����� �
���� �����
���� ���
���������
����� �
���� �����
���� ���
������������������������ �������
���������������������
Transaction-based
Lecture 3RAS 38
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
PMCU Lecture 3
20
Lecture 3RAS 39
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 3RAS 40
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
PMCU Lecture 3
21
Lecture 3RAS 41
Language Evolution for SoC Design
• New languages are developed to fill the productivity gap.
Verilog
VHDL
C
C++
JAVA
AssemblySystemC
SystemVerilogVera
TestBuilder
����������������������������������������
��� ���������������� ���������������� ���������������� �������������
����������������������������������������
��� ���������� ���������� ���������� �������
����������������������������������������
��� ��������������� ��������������� ��������������� ������������
Schematic
���� ������� ���������
Lecture 3RAS 42
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.
PMCU Lecture 3
22
Lecture 3RAS 43
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 3RAS 44
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.
PMCU Lecture 3
23
Lecture 3RAS 45
Core modelCore model
ISSISS
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
MemoryMemory
IPIP
IPIP
Cycle-accurate Bus modelCycle-accurate Bus model
AccuratePerformanceEstimation
...
...
Behaviormodel
------
------
------
transaction
BFMBFM BFMBFM BFMBFM
RTLmodel
Lecture 3RAS 46
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:Time-to-market:Rapidly changing
Consumer markets.
Expanding markets in wireless, automotive,
multilmedia, networks
Rapidly changing
Consumer markets.
Expanding markets in wireless, automotive,
multilmedia, networks
Deep submicron effects:Deep submicron effects:Wire delays, crosstalk
Electromigration, IR dropSubthreshold and gate leakageMask complexity (OPC, PSM)
PVT variations
Wire delays, crosstalkElectromigration, IR drop
Subthreshold and gate leakageMask complexity (OPC, PSM)
PVT variations
Complex systems:Complex systems:Power ReductionHW/SW Co-designand Co-verificationSystem ValidationDigital/Analog IPsNetwork-on-Chip
Power ReductionHW/SW Co-designand Co-verificationSystem ValidationDigital/Analog IPsNetwork-on-Chip