soc & asic design at ericsson - idatdts01/lectures/10/lec10.pdf · soc & asic design at...
TRANSCRIPT
SoC & ASIC design at Ericsson 2010-02-25
Ericsson AB 2010 1
SoC & ASIC design at Ericsson
Björn Fjellborg
Ericsson AB, Radio Hardware Design
Kista
© Ericsson AB 2010 SoC & ASIC design at Ericsson 2010-02-252
This lecture
� Mobile networks and HW infrastructure
� Systemization and System design
� SoC/ASIC design flow
� Design challenges
SoC & ASIC design at Ericsson 2010-02-25
Ericsson AB 2010 2
© Ericsson AB 2010 SoC & ASIC design at Ericsson 2010-02-253
Mobile networks and HW infrastructure
© Ericsson AB 2010 SoC & ASIC design at Ericsson 2010-02-254
A mobile network
LTE
RAN
GSM, WCDMA, LTE Radio Base Stations
SoC & ASIC design at Ericsson 2010-02-25
Ericsson AB 2010 3
© Ericsson AB 2010 SoC & ASIC design at Ericsson 2010-02-255
Ericsson Radio Base Station
3202 Indoor
� Connection field
� Capacitor Unit: CU
� BB subrack fan
� Baseband subrack– Baseband processing: RAX and
TXB– Transmission connection: ETB– Timing unit: TUB– Main processor: GPB– ATM switch: SCB– BBIFB
� RF subrack fan
� RF subrack– Transceiver: TRXB– Antenna interface: AIUB– ATM switch: SCB– RFIFB
� AMP subrack– MCPA
� MCPA fan
© Ericsson AB 2010 SoC & ASIC design at Ericsson 2010-02-257
An LTE (4G) Signal Processing ASIC
� Uplink signal processing
� 36 DSP cores
� 1 CPU core
� 29 M gates logic
� 65 Mbit SRAM
� 520 M transistors
� 12 W power dissipation
� 65 nm CMOS std cell
� 675 ball flip chip PBGApackage
RBS 6201
ROP1011510 ROP1011510
R1AR1A
E
SoC & ASIC design at Ericsson 2010-02-25
Ericsson AB 2010 4
© Ericsson AB 2010 SoC & ASIC design at Ericsson 2010-02-2510
Systemizationand
System design
© Ericsson AB 2010 SoC & ASIC design at Ericsson 2010-02-2511
Evolved 3GEvolved 3G("Turbo 3G")("Turbo 3G")
GPRS
HSCSD EDGE
2.5G2.5G
GSM
2G2G
UMTS/WCDMAWiMAX
3G3G
The cellular roadmap
SMS
Audio streaming/download
HDTV,video streaming
Voice
1990 2000 2005 20101995
10k
100k
10M
1M
100M
Bits/s
Email WAP
MMS
Interactive data
eHSPA
4G4G1G
Onlinegaming,Virtual worlds
Data streaming,Web access
Video telephony/conference
Broadcast servicesTV, radio
Push to talk/walkie-talkie
Video streaming/download
4G 4G
HSPA, MBMSSee next page
for abbreviations
See next page
for abbreviations
High speed data and web access
Web feeds/RSS
Location/positioningservices
LTE
LTE-AMobile WiMAX
SoC & ASIC design at Ericsson 2010-02-25
Ericsson AB 2010 5
© Ericsson AB 2010 SoC & ASIC design at Ericsson 2010-02-2512
Abbreviations
EDGE Enhanced Data rates for GSM EvolutioneHSPA Evolved HSPAGPRS General Packet Radio Service GSM Global System for Mobile communicationsHSCSD High-Speed Circuit-Switched DataHSDPA High-Speed Downlink Packet AccessHSPA High-Speed Packet Access (= HSDPA + HSUPA)HSUPA High-Speed Uplink Packet AccessLTE Long Term EvolutionLTE-A Long Term Evolution AdvancedMBMS Multimedia Broadcast Multicast ServiceMMS Multimedia Messaging ServiceRSS Really Simple SyndicationSMS Short Messaging ServiceUMTS Universal Mobile Telecommunications SystemWAP Wireless Application Protocol WCDMA Wideband Code Division Multiple AccessWiMAX Worldwide Interoperability for Microwave Access
© Ericsson AB 2010 SoC & ASIC design at Ericsson 2010-02-2514
Signal processing requirements
Per user
Per component
Increased integration
Increased integration
OPS (for signal processing)
100G
10G
1G
100M
10M
1T
Application complexityAir interface complexity
Bits/s
10k
100k
10M
1M
100M
1G
1990 2000 2005 20101995
SoC & ASIC design at Ericsson 2010-02-25
Ericsson AB 2010 6
© Ericsson AB 2010 SoC & ASIC design at Ericsson 2010-02-2515
System level(s)Radio network Base station
Board + SW package
ASIC + SW module
DSP core + SW routines
Ericsson terminology:
Node system
SoC subsystem
SoC
Node subsystem
Network system
© Ericsson AB 2010 SoC & ASIC design at Ericsson 2010-02-2516
Systemization purpose
� Find the most cost-efficient combination of HW components and SW modules that meets requirements on:
– Performance (traffic capacity, latency)
– Cost
– Size (weight, height, footprint – physical area on ground/board/silicon or memory size)
– Power consumption
– Flexibility (for capacity expansion, functionality upgrade)
– Environmental protection (substances, recycling)
SoC & ASIC design at Ericsson 2010-02-25
Ericsson AB 2010 7
© Ericsson AB 2010 SoC & ASIC design at Ericsson 2010-02-2517
System implementation choices
In-house developmentIn-house re-use External purchase
ASIC DSP/CPU
Hardwired logicIP* block
HW accelerator ALU/FPU/...
Node system
SoC subsystem
DSP/CPU core
SoC
FPGA
Node subsystem
External purchase
SW
In-house dev.
SW
In-house re-use
SW
HW components
SW modules
* IP = Intellectual Property, design block from another source
© Ericsson AB 2010 SoC & ASIC design at Ericsson 2010-02-2518
HW/SW trade-offs
� System design is in many cases a trade-off between HW and SW solutions to best meet the systemization requirements:
� The same trade-off applies to– ASIC/FPGA vs DSP/CPU
– Hardwired logic vs DSP/CPU cores
Performance CostPower Flexibility
Better
Worse
HW
SW
HW
SW HW
SW
SW
HW
single function
single function
set of functions
set of functions
SW
HW
SoC & ASIC design at Ericsson 2010-02-25
Ericsson AB 2010 8
© Ericsson AB 2010 SoC & ASIC design at Ericsson 2010-02-2519
HW vs SW performance
� HW has higher performance than SW because:– HW tailored to a specific functionality requires fewer gates
than a general instruction execution engine⇒
Higher capacity/gate
– Tailored HW can exploit parallelism to a higher degree than a DSP/CPU
⇒
Lower latency (faster execution of complex functions)
© Ericsson AB 2010 SoC & ASIC design at Ericsson 2010-02-2520
HW vs SW power
� HW has lower power dissipation than SW because:– Tailored HW uses few transistor switches/function (HW
optimized for the specific function) ⇒
Low energy/function step
– SW that runs on an instruction execution engine induces many transistor switches/function (several SW instructions to load, decode, and execute)
⇒
High energy/function step
SoC & ASIC design at Ericsson 2010-02-25
Ericsson AB 2010 9
© Ericsson AB 2010 SoC & ASIC design at Ericsson 2010-02-2521
HW vs SW flexibility
� SW has higher flexibility than HW because:– Correcting errors in SW requires no new HW
⇒
Faster correction at customer site
– Upgrading functionality in SW may require more memory but no new HW
⇒
No HW production cost for upgrading, say, 100 000 customer sites (provided enough memory was designed in)
– Note: Functionality upgrades in SW do not necessarily get to customer faster than HW upgrades, because development and verification times are comparable to those of HW (for complex systems)!
© Ericsson AB 2010 SoC & ASIC design at Ericsson 2010-02-2522
HW vs SW cost� HW has lower cost than SW when:
– The functionality can be implemented on a tailored piece of HW that is cheaper/smaller than a general purpose DSP/CPU
� A set of functions may have lower SW cost (a DSP/CPU):– Re-uses the same HW (instruction execution engine) for
multiple functions
– HW tailored to each function
⇒ Cost = Σ tailored HW blocks > 1 DSP/CPU
– Note: Some re-use may be possible also for tailored HW
� This can be called resource-based allocationCost
Functionsa b c d e f g h
HW aHW b
HW c
HW d
HW eHW f
HW gHW h
1 DSP/CPU Growth rate depends on HW re-use between functions
SoC & ASIC design at Ericsson 2010-02-25
Ericsson AB 2010 10
© Ericsson AB 2010 SoC & ASIC design at Ericsson 2010-02-2523
HW vs SW costFurther considerations
� Load-based allocation:– Continuously running function: Use HW (gives fully utilized HW)
– Sequence of functions creating an even load: Use SW (share the DSP/CPU HW with other functions)
� But: If peak performance >> medium load, dedicated HW may be better than multiple DSP/CPUs:
Cost
Time
Fn 1
Fn 2Fn3 Fn 4 Fn 2
Fn3 Fn 4 Fn 2
Fn3 Fn 4
Fn3
Fn3
Fn3 SW
HW
Cost
Time
Fn 1Fn 2
Fn3
Fn 4 Fn 2
Fn3
Fn 4 Fn 2
Fn3
Fn 4
Fn3
Fn3
Fn3
SWHW
# D
SP
/CP
U
1
2
3
HW (tailored HW instead of 2 extra DSPs)
© Ericsson AB 2010 SoC & ASIC design at Ericsson 2010-02-2524
HW vs SW costFurther considerations
� Concurrency-based allocation:– Has inherent concurrency: Use HW (utilize HW concurrency)
� May require a large number of DSP/CPUs to obtain same performance
� Typical for filter functions
– Has inherent sequentiality: Use SW (no speed-up with tailored HW)
DSP
DSP
DSP
DSP
Computational graph:
Tailored parallel HW
General DSP cores(larger HW cost for same performance)Parallel concurrency
Pipelined concurrency
SoC & ASIC design at Ericsson 2010-02-25
Ericsson AB 2010 11
© Ericsson AB 2010 SoC & ASIC design at Ericsson 2010-02-2525
HW vs SW costHW cost/performance trade-offs
� Often many alternatives for tailoring HW for a function:– Fast but expensive (parallel HW)
– Slow but cheap (sequential HW)
Cost
Performance
Sequential
HWParallel
© Ericsson AB 2010 SoC & ASIC design at Ericsson 2010-02-2526
HW/SW trade-offs summary
� Finding the best HW/SW trade-off is a multi-dimensional optimization problem!
Cost
Performance
Pow
er
Flexibilit
y
Feasible solution space:
Satisfies all constraints
SoC & ASIC design at Ericsson 2010-02-25
Ericsson AB 2010 12
© Ericsson AB 2010 SoC & ASIC design at Ericsson 2010-02-2527
System design tools and models
� Signal processing algorithms are designed and analyzed in Matlab
– Functionality and performance
– Based on GSM/WCDMA/LTE standards
� The signal chain is modelled at algorithmic level in C/C++
– Includes model of the air (radio channel mobile device – base station)
– Constitutes a reference model for HW and SW implementation
� Systemization alternatives are evaluated in various ad hoc ways
– Spreadsheets for cost, power, capacity
– High-level architectural models for performance
Node subsystem
SoC
© Ericsson AB 2010 SoC & ASIC design at Ericsson 2010-02-2528
Example: Random Access & Demodulation (RA-DEM)WCDMA Uplink Baseband Antenna Near Signal Processing
� A result from node subsystem systemization for baseband is that HW support for Random Access and Demodulation is needed in the receiver chain (for WCDMA receivers).
� A RA-DEM detects and correlates all reflections of coded signals into one signal per transmitter
� A RA-DEM performs a number of functions:– Preamble detect– Message search– Rake finger despread
� The RA-DEM functions imply a number of operations:– Code match filtering– Interference estimation– Coherent and non-coherent accumulation– Interpolation– Squaring– ...
SoC & ASIC design at Ericsson 2010-02-25
Ericsson AB 2010 13
© Ericsson AB 2010 SoC & ASIC design at Ericsson 2010-02-2529
RA-DEM architectureFirst SoC/SoC subsystem systemization*: • Node subsystem
systemization has resulted in a RA-DEM algorithm, given requirements at that level
• SoC systemization has defined subfunctions (boxes in the picture)
• All subfunctions are performed inside the SoC ASIC
• System design task: For each box, decide whether to use
- hardwired logic
- SW (DSP core)* Subfunctions are anonymized for confidentiality reasons
© Ericsson AB 2010 SoC & ASIC design at Ericsson 2010-02-2530
RA-DEM design goal
� Main goal: Minimize cost
� Constraints: – Performance (can be determined with high precision per
subfunction from the algorithm and max input data rate)
– Power (total for the SoC; if the SoC power budget does not hold, re-systemization has to be done on the SoC or even the node subsystem level)
– Flexibility (flexibility requirements are limited to those subfunctions that have to change in case of future upgrades)
SoC & ASIC design at Ericsson 2010-02-25
Ericsson AB 2010 14
© Ericsson AB 2010 SoC & ASIC design at Ericsson 2010-02-2531
RA-DEM system designPerformance trade-off
HW
SW
• Determine the subfunctions' performance requirement (in OPS)
• Subfunctions that exceed one DSP core's performance (350 MOPS) ⇒
HW (to avoid splitting over several DSPs)
2.2G72M
184M 46M 55.6G 19G 588M 588M 294M 47M 40M 1.8k
184M
8.8G 4.32M 1.66M 1.8k 1.8k 3.6k
6.2G
3.1G4.32M 92M
3.6M
92M
59.6M 59.6M
3.1G
59.6M 59.6M
588M
© Ericsson AB 2010 SoC & ASIC design at Ericsson 2010-02-2532
2.2G72M
184M 46M 55.6G 19G 588M 588M 294M 47M 40M 1.8k
184M
8.8G 4.32M 1.66M 1.8k 1.8k 3.6k
6.2G
3.1G4.32M 92M
3.6M
92M
59.6M 59.6M
3.1G
59.6M 59.6M
588M
72M2.2G
184M 46M 55.6G 19G 588M 47M294M 40M 1.8k
184M
8.8G 4.32M 1.66M 1.8k 1.8k 3.6k
6.2G
3.1G4.32M 92M
3.6M
92M
59.6M 59.6M
3.1G
59.6M 59.6M
588M 588M
RA-DEM system designFlexibility trade-off
HW
SW
• Determine the subfunctions' flexibility requirement(upgradable or not)
• Subfunctions that must be upgradable ⇒
SW
• Conflicting trade-offs may occur!
?
SoC & ASIC design at Ericsson 2010-02-25
Ericsson AB 2010 15
© Ericsson AB 2010 SoC & ASIC design at Ericsson 2010-02-2533
294M588M 588M 588M184M 46M 47M
1.8k
72M2.2G
55.6G 19G 40M 1.8k
184M
8.8G 4.32M 1.66M 1.8k 3.6k
6.2G
3.1G4.32M 92M
3.6M
92M
59.6M 59.6M
3.1G
59.6M 59.6M
RA-DEM system designLoad trade-off
HW
SW
• Determine the subfunctions' peak performance(OPS/max latency)
–(A function that requires 10 MOPS and has to finish in 0.1 s has a peak performance of 10/0.1 = 100 MOPS)
• Subfunctions that exceed one DSP core's performance (350 MOPS) ⇒
HW
• New conflicts may occur!
? ?
184M 46M
166M
1.6G 588M118M 40M 1.8k
184M
36M 2.22M 3.6k 3.6k
3.6k
34.6M 736M
14.4M
736M
477M 477M
477M 477M
© Ericsson AB 2010 SoC & ASIC design at Ericsson 2010-02-2534
184M 46M 47M
1.8k
72M2.2G
55.6G 19G 588M 294M 40M 1.8k
184M
8.8G 4.32M 1.66M 1.8k 3.6k
6.2G
3.1G4.32M 92M
3.6M
92M
59.6M 59.6M
3.1G
59.6M 59.6M
588M 588M
RA-DEM system designConcurrency trade-off
HW
SW
• Determine which subfunctions that are inherently concurrent
• Subfunctions with high degree of concurrency andreasonably high performance requirement ⇒
HW
? ?
184M 46M
166M
1.6G 588M118M 40M 1.8k
184M
36M 2.22M 3.6k 3.6k
3.6k
34.6M 736M
14.4M
736M
477M 477M
477M 477M
184M 46M
166M
1.6G 588M118M 40M 1.8k
184M
36M 2.22M 3.6k 3.6k
3.6k
34.6M 736M
14.4M
736M
477M 477M
477M 477M
SoC & ASIC design at Ericsson 2010-02-25
Ericsson AB 2010 16
© Ericsson AB 2010 SoC & ASIC design at Ericsson 2010-02-2535
184M 46M 47M
1.8k
72M2.2G
55.6G 19G 588M 294M 40M 1.8k
184M
8.8G 4.32M 1.66M 1.8k 3.6k
6.2G
3.1G4.32M 92M
3.6M
92M
59.6M 59.6M
3.1G
59.6M 59.6M
588M 588M
RA-DEM system designHW cost trade-off
HW
SW
• Cost of HW implementation = area of tailored HW
• Cost of SW (DSP core) implementation = (load requirement/DSP performance) · DSP core area + extra interconnect
• Express as % of a DSP core's area:Tailored HW area|DSP area + interconnect
• Subfunctions with lower HW cost ⇒
HW, the rest⇒
SW
? ?
184M 46M
166M
1.6G 588M118M 40M 1.8k
184M
36M 2.22M 3.6k 3.6k
3.6k
34.6M 736M
14.4M
736M
477M 477M
477M 477M
5|10+10
3|10+3
5|1+3
4|0+3
5|0+2
30|34+2
20|11+2
5|0+2
45|457+10
35|168+10
© Ericsson AB 2010 SoC & ASIC design at Ericsson 2010-02-2536
184M 46M 47M
1.8k
72M2.2G
55.6G 19G 588M 294M 40M 1.8k
184M
8.8G 4.32M 1.66M 1.8k 3.6k
6.2G
3.1G4.32M 92M
3.6M
92M
59.6M 59.6M
3.1G
59.6M 59.6M
588M 588M
RA-DEM system designResolving conflicting requirements
HW
SW
? ?
184M 46M
166M
1.6G 588M118M 40M 1.8k
184M
36M 2.22M 3.6k 3.6k
3.6k
34.6M 736M
14.4M
736M
477M 477M
477M 477M
5|10+10
3|10+3
5|1+3
4|0+3
5|0+2
30|34+2
20|11+2
5|0+2
45|457+10
35|168+10
294M588M
? ?
1.6G 588M
45|457+10
35|168+10
� How important is the flexibility?
– If worth the extra cost (4.22 resp 1.43 cores)⇒
SW, otherwise HW
� Or, re-systemize:– Can the flexibility
requirement be isolated to part of the subfunction?⇒
Split into sub-subfunctions and map to HW resp SW
– Can we use SW-configurable HW?
� The conflict is caused by the requirement on flexibility – everything else points to a HW solution
� Cost for HW vs DSP core:
– 0.45 vs 4.67 cores
– 0.35 vs 1.78 cores
SoC & ASIC design at Ericsson 2010-02-25
Ericsson AB 2010 17
© Ericsson AB 2010 SoC & ASIC design at Ericsson 2010-02-2537
SoC/ASIC design flow
© Ericsson AB 2010 SoC & ASIC design at Ericsson 2010-02-2538
From idea ⇒ component ...
EROP1011503 ROP1011503
R1AR1A
SoC & ASIC design at Ericsson 2010-02-25
Ericsson AB 2010 18
© Ericsson AB 2010 SoC & ASIC design at Ericsson 2010-02-2539
EROP1011503 ROP1011503
R1AR1A
... like this?
Hey! I've got this marvelous
idea!
Great! Let's go hack some
code!
Geez... Imagine life without VHDL...
Your ASIC vendor
Invoice
$ 1,000,000
Product plans?
Market window?
Software?
Firmware?
O&M?
Board?
System integration?
System verification?
Type approval?
Export control?
Thermal design?
Environmental protection restrictions?
Price models?
Supply agreement?
Test?
Patents?
Product structure?
Vendor negotiations?
Documentation? Version control?
Interfaces?
Debug?
Reliability?
Signal integrity?Power budget?
Producibility?
Building practice?
Soft errors?
© Ericsson AB 2010 SoC & ASIC design at Ericsson 2010-02-2540
Main steps
Technology study
Structuring
HW modeling & design
ASIC technology mapping
ASIC prototype manufacturing
ASIC prototype verification
SW modeling & design
SW implementation
SW verification
SoC & ASIC design at Ericsson 2010-02-25
Ericsson AB 2010 19
© Ericsson AB 2010 SoC & ASIC design at Ericsson 2010-02-2541
Technology study
� Analyze functional and performance requirements
� Analyze technological possibilities
� Investigate different technical solutions, consider:– standards
– production costs
– life cycle costs
– reliability
– environment
– legal directives
� Create a high level description of the system architecture (text and graphics)
� Provide a decision base for project launch decision
Hey! I've got this marvelous
idea!
Great! Let's go hack some
code!
© Ericsson AB 2010 SoC & ASIC design at Ericsson 2010-02-2542
Structuring
� Partition into HW and SW
� Define HW/SW interface
� Partition into functional blocks
� Create behavioral models to evaluate critical functionality (Matlab, C, VHDL)
� Select IPs, IOs and memories, consider re-use of previous designs
� Select ASIC technology and vendor
� Choose package
� Investigate patent opportunities
� Specify system testability and diagnostics in production, field, and repair
� Choose test strategy: scan test, memory test, boundary scan, logic BIST
SoC & ASIC design at Ericsson 2010-02-25
Ericsson AB 2010 20
© Ericsson AB 2010 SoC & ASIC design at Ericsson 2010-02-2543
Typical ASIC design flow
Processor coresRAMsPLL
Processor coresBIST & TAPCRAMRAM redundancy
RTL coding
Specification
Synthesis
Place & Route
Production
Prototypes
Hard macros/IP
Floorplanning
Ericsson
ASIC vendor
Soft macros/IP Front-end
Back-end
Design &
verification of
- function
- timing
- power
© Ericsson AB 2010 SoC & ASIC design at Ericsson 2010-02-2544
Design & Verification - Flow & Tools
Logic synthesis
Static timing analysis
ASIC vendor back-end& manufacture
Prototype verification
Gate simulation
Timing & Loads
IUS/NCSim
Design Compiler
IUS/NCSim
PrimeTime Conformal
Board
Equivalence check
Test coverage
Specman
Gate emulation
Palladium II
Actual tools used
depend on project
and ASIC vendor
Actual tools used
depend on project
and ASIC vendor
Design planning
First Encounter
Power analysis
PrimeTime PX
Design activity
Verification activity
Rule check
Design entrySpyGlass
QuestaSim
QuestaSim
RTL Compiler
QuestaSim
Acceleration
Palladium II
Test vectors
SW
RTL simulationFormal verificationSwitchingfrequencies
IFV
SoC & ASIC design at Ericsson 2010-02-25
Ericsson AB 2010 21
© Ericsson AB 2010 SoC & ASIC design at Ericsson 2010-02-2545
Logic Design
Rule check SpyGlass
Design planning
First
Encounter
Logic synthesisDesign
Compiler
Test insertion
DFT
Compiler
Equivalencecheck
Conformal
SimulationNCSim
PlacementDEF
Parasitics
DatabaseDDC
SwitchingSAIF
TimingSDF
SimulationNCSim
ConstraintsTCL
Reports- area- timing(- power)
DRC reports
ASIC vendor
back-end
RTLVHDL/
(System)-
VerilogSynthesisDesign
rules
Netlist
verificationTiming
Design
For Test
Block
Subsys/Block
Top/Subsys
Top/Subsys
Top/Subsys
Power analysis
PrimeTime PX
Static Timing
AnalysisPrimeTime
Power model
DB
Timing model
DB
Design rules
Power
NetlistVerilog
© Ericsson AB 2010 SoC & ASIC design at Ericsson 2010-02-2546
HW/SW coHW/SW co--verificationverification
Verification managementVerification managementFunctional VerificationFlow
AccelerationPalladium II
SimulationNCSim/
Specman
RTL codeVHDL/
SystemVerilog
Testbenche
DSP SW
Require-ments
Verification planning
ePlanner
Verification managementeManager
Modify/Extend
constrained random tests
directed tests
Code coverage
Functional coverage
OK OK
EmulationPalladium II
Target debug
Board environment
Verification IP
eVC
Ref. model (alg. parts)
C++
Formalverification
IFV
SoC & ASIC design at Ericsson 2010-02-25
Ericsson AB 2010 22
© Ericsson AB 2010 SoC & ASIC design at Ericsson 2010-02-2547
What should be verified?
System characteristics
Tools & transformations
Design & implementation
– Validate specification (block & chip functionality)
– Performance
– Power dissipation
– Function implementation (block & chip level)
– I/O timing
– Internal timing
– Electrical characteristics
– Signal integrity
– Manufacturing process
– Correct transformations (by synthesis tools etc)
© Ericsson AB 2010 SoC & ASIC design at Ericsson 2010-02-2548
Verification activities & methods
RTL coding
Specification
Synthesis
Place & Route
Production
Prototypes
Floorplanning
RTL block verification
RTL chip level verification
HW/SW co-verification
Back-end functional verification
Back-end timing verification
DFT & production test
Prototype verification
Simulation
Test bench authoringFunctional & code coverage
Emulation, application SW
Equivalence check,simulation
Static timing analysis,simulation
Scan, ATPG, at-speed test
DSM analysis
SW test, logic analysis
Layout verification
Activity Method
Design
flow
Designability Rule check
Formal verification
SoC & ASIC design at Ericsson 2010-02-25
Ericsson AB 2010 23
© Ericsson AB 2010 SoC & ASIC design at Ericsson 2010-02-2549
Simulation
� RTL– Verify functional behavior
– Cycle-true
� Gate level– Verify timing behavior
– Verify functional behavior of some logic (scan chains, asynchronous logic)
– Estimated or back-annotated timing
� Languages: VHDL, SystemVerilog, Verilog
� Currently used: Cadence Incisive Unified Simulator/NCSim
© Ericsson AB 2010 SoC & ASIC design at Ericsson 2010-02-2550
Emulation
� RTL or gate level functional verification
� Emulates design with configurable hardware arrays (FPGAs or similar)
– Extremely fast, ~1 M cycles/s
� Requires long test cases for efficient use– Random or real data streams,
application SW
� Currently used: Cadence Palladium II
SoC & ASIC design at Ericsson 2010-02-25
Ericsson AB 2010 24
© Ericsson AB 2010 SoC & ASIC design at Ericsson 2010-02-2551
Formal Verification
� Replaces RTL simulation with formal proof tools– No testbench code
– 100 % verification coverage
� Property specification languages:– SVA (SystemVerilog Assertions)
– PSL (Property Specification Language)
� Currently used: Cadence Incisive Formal Verifier
© Ericsson AB 2010 SoC & ASIC design at Ericsson 2010-02-2552
Functional verification coverage
� Basic methods for quality assessment of functional verification:
– Code coverage
– Functional coverage
� Measures how much of the design that has been verified
SoC & ASIC design at Ericsson 2010-02-25
Ericsson AB 2010 25
© Ericsson AB 2010 SoC & ASIC design at Ericsson 2010-02-2553
Code coverage
� Analyze test benches for test effectiveness– statement coverage ("Have all statements been executed?")
– branch coverage ("All conditional branches?")
– condition coverage ("All values in conditional tests?")
– path coverage ("All execution paths through the code?")
� Currently used: Cadence Incisive Unified Simulator/NCSim
© Ericsson AB 2010 SoC & ASIC design at Ericsson 2010-02-2554
Functional coverageFeature based verification
� Features of a design– Operations to perform
– Data to process
– Protocols to follow
� Determine the characteristics of the features
– Typical data/conditions
– Extreme (corner case) data/conditions
– Interactions with other features
� Test according to characteristics– A few typical cases
– All corner cases, or a larger fraction if not a "difficult" corner
– Interactions split into typical and corner cases as well
• Filled and emptied every FIFO in the design
• Transmitted all packet types across a particular channel of the design
• Transmitted packets across all channels in the design
• Transmitted all packet types across all channels (cross-coverage)
For example, functional coverage might track whether the verification process has:
Three different verification features
Interacting features
SoC & ASIC design at Ericsson 2010-02-25
Ericsson AB 2010 26
© Ericsson AB 2010 SoC & ASIC design at Ericsson 2010-02-2555
Functional coverage
� Coverage presentation example (Specman Elite):
© Ericsson AB 2010 SoC & ASIC design at Ericsson 2010-02-2556
Test bench authoringFor functional coverage
� Create test benches to verify functional behavior
� Feature based verification
� High-level hardware verification language (HVL) withdeclarative constructs for compactness
� Stimuli generation– Specify data format rather than exact content
– Random data generators with constraints
� Checkers verify stimuli/response relationship– Basis for functional coverage analysis
� HVL languages: e, SystemVerilog
� Currently used: Cadence Specman Elite
SoC & ASIC design at Ericsson 2010-02-25
Ericsson AB 2010 27
© Ericsson AB 2010 SoC & ASIC design at Ericsson 2010-02-2557
Functional verification methods
� Basic methods:– Directed tests
– Constrained Random Testing
– Coverage Driven Verification
– Assertion Based Verification
© Ericsson AB 2010 SoC & ASIC design at Ericsson 2010-02-2558
Functional verificationDirected tests
Directed tests- Create tests manually- Cover as much as possibleof test space
Test spaceTest space
SoC & ASIC design at Ericsson 2010-02-25
Ericsson AB 2010 28
© Ericsson AB 2010 SoC & ASIC design at Ericsson 2010-02-2559
Directed tests- Create tests manually- Cover as much as possibleof test space
Functional verificationConstrained Random Testing
Constrained Random Testing- Create tests automatically from starting points
Test spaceTest space
Directed tests- Create tests manually- Cover as much as possibleof test space
© Ericsson AB 2010 SoC & ASIC design at Ericsson 2010-02-2560
Functional verificationCoverage Driven Verification
Coverage Driven Verification- Perform repeated Constrained Random Testing runs to reach functional coverage goals
Test spaceTest space
Constrained Random Testing- Create tests automatically from starting points
Directed tests- Create tests manually- Cover as much as possibleof test space
Constrained Random Testing- Create tests automatically from starting points
SoC & ASIC design at Ericsson 2010-02-25
Ericsson AB 2010 29
© Ericsson AB 2010 SoC & ASIC design at Ericsson 2010-02-2561
Functional verificationAssertion Based Verification
Formal ABV- Assertions express properties to verify- Properties are proved/disproved- Replaces testcase stimuli and response code with property expressions
Simulation-based ABV- Assertions express properties to verify- Properties are tested by simulation- Replaces testcase response code- Use with CRT and CDV
Test spaceTest space
© Ericsson AB 2010 SoC & ASIC design at Ericsson 2010-02-2562
Functional verificationAssertions
� Assertions are defined as conditional expected events
� Assertions are also called checkers
SystemVerilog code(alt: e)
SystemVerilog code(alt: e)
Example: Check that a bus request is followed by an acknowledge 1-3 cycles after the request
Example: Check that a bus request is followed by an acknowledge 1-3 cycles after the request
SoC & ASIC design at Ericsson 2010-02-25
Ericsson AB 2010 30
© Ericsson AB 2010 SoC & ASIC design at Ericsson 2010-02-2563
HW/SW co-verificationPurpose
� Ensure circuit functions as intended in its environment (at clock cycle level)
– External interfaces operate as intended, match other components
– SW design has correct assumptions about HW and vice versa
– HW/SW architecture supports intended performance
� Ensure early that SW functions properly– Prepare the way for sub-system verification
© Ericsson AB 2010 SoC & ASIC design at Ericsson 2010-02-2564
HW/SW co-verificationExample
� Typical signal processing architecture:
ASIC
CPUDSP DSP DSP
Logic & RAM
EPROM
DSP SW Control SW
SoC & ASIC design at Ericsson 2010-02-25
Ericsson AB 2010 31
© Ericsson AB 2010 SoC & ASIC design at Ericsson 2010-02-2565
HW/SW co-verification
SWHW
ASIC HW
Test DSP SW
ModelSim
ASIC integration
DSP SW
host environment
DSP SWverification
Emulator
HW/SW co-verification
HW SW
ModelSim + C
ASIC/DSP SW co-verification
Step 1
SW target
environment
SW integration
Control SWhost environment
Control SWverification
DSP SW
Control SW
IP models(CPUs etc)
DSP modelStep 2
Step 3
© Ericsson AB 2010 SoC & ASIC design at Ericsson 2010-02-2566
Designability - Rule Check
� Designability = Ability to design
� Rule check: Find design patterns that may cause problems in the design flow
– Static check of HDL code
� Rule examples:– Avoid latches (incomplete HDL conditions may cause
unintentional latches)– Memory inputs should be observable (for test)– Use specified identifier suffixes, e.g. ”_n” for active low– One file per HDL design unit (entity/module etc)– Use fixed indentation– Use IEEE Numeric_std packages
� Typically several hundred rules
SoC & ASIC design at Ericsson 2010-02-25
Ericsson AB 2010 32
© Ericsson AB 2010 SoC & ASIC design at Ericsson 2010-02-2567
Verification management
Define verification
goals
Plan verification
to reach goals
Perform verification
Verifi-cation goals
reached?
Extend tests
Done
Begin &Yes
No
Define test cases
Create testbench
Run tests Errors found?BeginNo
DebugMake
corrections to design
Modify test cases
Testssufficient?
Yes
No
Yes
Done
© Ericsson AB 2010 SoC & ASIC design at Ericsson 2010-02-2568
Verification management tools
� Cadence eManager
� Collect results from all dispatched jobs– Failures (design errors)
– Coverage
� Track progress of test suite
A session = a sequence of testsA session = a sequence of tests
P – Passed
F – Failed
R – Running
W – Waiting
O – Other
P – Passed
F – Failed
R – Running
W – Waiting
O – Other
SoC & ASIC design at Ericsson 2010-02-25
Ericsson AB 2010 33
© Ericsson AB 2010 SoC & ASIC design at Ericsson 2010-02-2569
Back-end functional verification
RTL
NHO netlist
Sign-off netlist
Synthesis
=
Back-end design &verification team
Equivalence
checker
Equivalencechecker
Functional Functional verification of verification of target debugger target debugger
& logic BIST& logic BIST
Preliminary netlist
Functional Functional equivalenceequivalence
FloorplanningTest insertion
Place & RouteTest insertion
Hard macros
Equivalence
checker
SDF
Simulator
SDF
SimulatorEricsson
ASIC vendor
Typically at least3 deliveries to ASIC vendor
Typically at least3 deliveries to ASIC vendor
© Ericsson AB 2010 SoC & ASIC design at Ericsson 2010-02-2570
Back-end timing verification
=
Back-end design &verification team
Timing verification of Timing verification of ““STASTA--hardhard”” logiclogic
Hard macros
Constraints
Timing Timing verification of verification of synchronous synchronous
logiclogic
Simulator
SDFStatic Timing
Analyzer
Simulator
SDF Static Timing
Analyzer
RTL
NHO netlist
Sign-off netlist
Synthesis
Preliminary netlist
FloorplanningTest insertion
Place & RouteTest insertion
Ericsson
ASIC vendor
SoC & ASIC design at Ericsson 2010-02-25
Ericsson AB 2010 34
© Ericsson AB 2010 SoC & ASIC design at Ericsson 2010-02-2571
Equivalence check
� Checks functional equivalence of two designs
– RTL - gate (before and after synthesis)
– Gate - gate (before and after netlist modification)
– (RTL - RTL)
� Formal methods– Reference design logically
implies* compared design
– No test bench, no test vectors
– Verifies complete design
� Currently used: Cadence Conformal
* Implication (⇒) means that all reference functionality is present in the compared design, but the compared design may have additional functions not present in the reference design.
Equivalent?
© Ericsson AB 2010 SoC & ASIC design at Ericsson 2010-02-2572
Static timing analysis� Verify timing
� Gate level
� Estimated or back-annotated timing
� Calculate delay along all clock and data paths– Check for setup and hold violations, delays, pulse widths
– Locate critical paths
– Analysis for worst case, best case, on-chip variation
� Synopsys PrimeTime
Timing path for worst case (setup check)
setup time
d
ckmin_path time
max_path time
SoC & ASIC design at Ericsson 2010-02-25
Ericsson AB 2010 35
© Ericsson AB 2010 SoC & ASIC design at Ericsson 2010-02-2573
Prototype verification
� Establish that ASIC prototypes meet specifications:– timing on interfaces
– functionally at full speed
– power dissipation
– electrical characteristics
� Tested in lab environment:
BGA adapter
CPUsystem
Logic analyzerOscilloscope
Data generator
CPU debuggerRISCWatch
EEROP1011503 ROP1011503
R1AR1A
© Ericsson AB 2010 SoC & ASIC design at Ericsson 2010-02-2574
After prototype verification
ASIC prototype verification
Board verification
Subsystem verification
System verification
Type approval
Sales & marketing
Board
Subsystem SW
Other subsystems System
SWMechanics
Design & verification
Design & verification
Design & verification
Design & verification
Design & verification
SoC & ASIC design at Ericsson 2010-02-25
Ericsson AB 2010 36
© Ericsson AB 2010 SoC & ASIC design at Ericsson 2010-02-2575
Design challengesfor SoCs
© Ericsson AB 2010 SoC & ASIC design at Ericsson 2010-02-2576
RBS Signal Processing ASICs 1995-2010
Transistors
II
IIIIV
V
5 M
500 M
50 M
10 M
20 M
100 M
200 MVI
VII
I
Logic:Logic:
1 G
1995 1998 2001 20072004 2010
IXVIII
Year
SoC & ASIC design at Ericsson 2010-02-25
Ericsson AB 2010 37
© Ericsson AB 2010 SoC & ASIC design at Ericsson 2010-02-2577
Technologies and challengesTransistors
II
IIIIV
V
5 M
500 M
50 M
10 M
20 M
100 M
200 MVI
VII
I
Year
1 G
1995 1998 2001 20072004 2010
IXVIII
Signalintegrity
Soft errors
Leakagepower
Variation
Wiredelay
Sum of all!
0.8 µm
0.25 µm
0.18 µm0.13 µm
0.13 µm90 nm
65 nm
45 nm40 nm
© Ericsson AB 2010 SoC & ASIC design at Ericsson 2010-02-2578
Wire delay, crosstalk, soft errors
� Wire delay dominates over logic delay at ≤ 0.35 µm– Solution: New delay models for timing analysis,
interconnect-driven design
� Signal integrity, e.g. crosstalk (capacitive coupling between parallel wires) that cause excessive delays and false pulses, at ≤ 0.18 µm
– Solution: New design rules (wire spacing) and analysis methods
� Soft errors (charged particles hit the silicon with enough energy to change the logic state) at ≤ 0.13 µm
– Solution: Error correction coding of memory content
SoC & ASIC design at Ericsson 2010-02-25
Ericsson AB 2010 38
© Ericsson AB 2010 SoC & ASIC design at Ericsson 2010-02-2579
Leakage power
� Leakage current (transistor turn-off current) is a major contributor to power dissipation at ≤ 90 nm
� Power is becoming a limiting factor for design also for stationary equipment (i.e., not battery operated)
Typical power budget
0%
20%
40%
60%
80%
100%
0.25
u
0.18
u
0.13
u
90nm
65nm
45nm
Technology
Po
wer
dis
sip
ati
on
Dynamic
Leakage
Conventionalpower reductionmethods applyto dynamic power
© Ericsson AB 2010 SoC & ASIC design at Ericsson 2010-02-2580
Process variation at the atomic scale
� Parameter variation increases with decreasing geometry:
– Dopant– Instrumentation– Mask precision– Lithography– Variations between fabs
and batches
� Timing characteristics vary significantly from chip to chip
10
100
1000
10000
1000 500 250 130 65 32
Technology Node (nm)
Mean
Nu
mb
er
of
Do
pan
tA
tom
s
Random dopant fluctuation:Number of dopant atoms
SoC & ASIC design at Ericsson 2010-02-25
Ericsson AB 2010 39
© Ericsson AB 2010 SoC & ASIC design at Ericsson 2010-02-2581
Why ASIC?
� 95 % of the functionality on a receiver board is signal processing
� Developing an ASIC in 45 nm takes 1 year and costs several 10 MSEK
� Buying a high-performance DSP costs 1000 SEK and it is available off the shelf
� So why do we keep making ASICs?
© Ericsson AB 2010 SoC & ASIC design at Ericsson 2010-02-2582
ASIC vs DSP
� ASICs are:– Custom made– Tailored to the application
� Pros:– High functionality/transistor
(tailored HW)– Few transistor switches/function
(optimized HW; low energy)– Low component price (50-500
SEK)
� Cons:– Expensive to introduce (high
development cost)– Available after 1 year
development– Not upgradable for new
functionality
� DSPs are:– Commodity products– Used for general applications
� Pros:– Cheap to introduce– Available at once (but SW will
likely take at least 1 year to develop...)
– Upgradable for new functionality (through SW)
� Cons:– Less functionality/transistor
(general SW)– Many transistor switches/function
(several SW instructions to load, decode, and execute; high energy)
– High component price (500-2000 SEK)
SoC & ASIC design at Ericsson 2010-02-25
Ericsson AB 2010 40
© Ericsson AB 2010 SoC & ASIC design at Ericsson 2010-02-2583
ASIC vs DSP performance
� A 100 GOPS ASIC:– Uses massive parallelism
(1000's of parallel threads in concurrent HW)
– Can run at moderate frequency (100 MHz-1 GHz)⇒ Use low-medium performance Si process (high Vt
transistors)⇒ Low current leakage⇒ Low-medium power dissipation (5-50 W)
� A 100 GOPS DSP:– Uses moderate parallelism
(pipelining, co-processors)
– Must run at high frequency (2-20 GHz)⇒ Use high performance Si process (low Vt transistors)⇒ High current leakage⇒ High power dissipation (100-1000 W)
© Ericsson AB 2010 SoC & ASIC design at Ericsson 2010-02-2584
ASIC vs DSP shortcomings and remedies� ASIC:
– Not upgradable for new functionality⇒ Implement base functionality with multiple DSP cores (multiple to keep power down)
– Long development time⇒ Not longer than for DSP SW!
– Expensive development⇒ Yes, but component cost lower than for a DSP
� DSP:– Many transistor switches/function
(several SW instructions)
– Uses moderate parallelism (pipelining, co-processors)⇒ Implement HW accelerators for specific signal processing functions(⇒ Becomes less generic...)
SoC & ASIC design at Ericsson 2010-02-25
Ericsson AB 2010 41
© Ericsson AB 2010 SoC & ASIC design at Ericsson 2010-02-2585
Want to participate?
� Do you want to:– Contribute to a world-wide rollout of 4G mobile communications?
– Use the absolutely latest microelectronics technology?
– Be part of a world class ASIC design team?
– Work with the #1 telecommunications company?
� Apply for a graduate job at www.ericsson.com/careers !
© Ericsson AB 2010 SoC & ASIC design at Ericsson 2010-02-2587