SoC & ASIC Design at Ericsson
SOC & ASIC DESIGN
AT ERICSSON
Björn Fjellborg
Ericsson AB
Kista
THIS LECTURE
› Mobile networks and HW infrastructure
› Systemization and System design
› Design challenges
› SoC/ASIC design flow
SoC & ASIC Design at Ericsson | © Ericsson AB 2016 | Page 2
© Ericsson AB 2016
1
SoC & ASIC Design at Ericsson
Mobile Networks and
HW Infrastructure
A MOBILE NETWORK
LTE
RAN
GSM, WCDMA, LTE
Radio Base Stations
SoC & ASIC Design at Ericsson | © Ericsson AB 2016 | Page 4
© Ericsson AB 2016
2
SoC & ASIC Design at Ericsson
ERICSSON RADIO BASE STATIONS
The most visible
part of a base
station are
usually the
antennas (and
antenna mast)
INDOOR
Cabinets come in
different sizes, for
different capacity
The cabinet
housing the HW
and SW is located
at a sealed off
area below the
antenna mast or
inside a nearby
building
SMALL
INDOOR
RADIO
DOT
OUTDOOR
SoC & ASIC Design at Ericsson | © Ericsson AB 2016 | Page 5
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 PBGA package
SoC & ASIC Design at Ericsson | © Ericsson AB 2016 | Page 7
© Ericsson AB 2016
3
SoC & ASIC Design at Ericsson
Systemization and
System Design
THE CELLULAR ROADMAP
10G
Bits/s
5G
1G
100M
4G
10M
See next page
for abbreviations
1M
100k
eHSPA
("Turbo 3G")
Video
streaming/
download
HSPA
3G
LTE
Mobile WiMAX
Evolved 3G
2G
Online video,
audio, radio
Video telephony/
UMTS/WCDMA
conference
WiMAX Data streaming,
Online
Web access
gaming,
Virtual
EDGE
Audio streaming/
worlds
download
Location/positioning
services
SMS
GSM
1990
1995
2000
2005
Smart grid
Augmented reality
Smart home
SW downloads
Cloud
services,
storage
App updates
Social
networking
Email
Voice
Ultra HD
HDTV
High speed data
and web access
HSCSD
2.5G
Interactive data
GPRS
MMS
10k
Connected
vehicles
LTE-A
4G
Connected
wearables
Web feeds/
RSS
2010
2015
2020
SoC & ASIC Design at Ericsson | © Ericsson AB 2016 | Page 11
© Ericsson AB 2016
4
SoC & ASIC Design at Ericsson
ABBREVIATIONS
›
›
›
›
›
›
›
›
›
›
›
›
›
›
›
›
EDGE
eHSPA
GPRS
GSM
HDTV
HSCSD
HSPA
LTE
LTE-A
MMS
RSS
SMS
UHDTV
UMTS
WCDMA
WiMAX
Enhanced Data rates for GSM Evolution
Evolved HSPA
General Packet Radio Service
Global System for Mobile communications
High Definition TV
High-Speed Circuit-Switched Data
High-Speed Packet Access
Long Term Evolution
Long Term Evolution Advanced
Multimedia Messaging Service
Really Simple Syndication
Short Messaging Service
Ultra High Definition TV
Universal Mobile Telecommunications System
Wideband Code Division Multiple Access
Worldwide Interoperability for Microwave Access
SoC & ASIC Design at Ericsson | © Ericsson AB 2016 | Page 12
MOBILE TRAFFIC DEVELOPMENT
SoC & ASIC Design at Ericsson | © Ericsson AB 2016 | Page 13
© Ericsson AB 2016
5
SoC & ASIC Design at Ericsson
SIGNAL PROCESSING
REQUIREMENTS
Bits/s OPS (for signal processing)
10G
10T
1G
1T
Per component
100M
10M
100G
Increased
integration
10G
Per user
1M
100k
10k
1G
100M
Application complexity
Air interface complexity
10M
1990
1995
2000
2005
2010
2015
2020
SoC & ASIC Design at Ericsson | © Ericsson AB 2016 | Page 15
SYSTEM LEVEL(S)
Ericsson terminology:
Base station
Radio network
Network system
LTE
RAN
Node system
Board + SW package
ASIC + SW module
Node subsystem
Ring bus interconnect
Common
Memory
Control
10 G
asterix
asterix
asterix
Accelerator
numerobis
numerobis
Accelerator
obelix
obelix
obelix
Accelerator
10 G
SoC
JTAG
DSP core + SW routines
pyradonis
pyradonis
pyradonis
Accelerator
matrix
matrix
matrix
matrix
matrix
Accelerator
Debug
I2C
GPIO
MDIO
Accelerator
Cache Control
phoenix 4
phoenix 4
phoenix 4
phoenix 4
phoenix 4
phoenix 4
phoenix
4
phoenix 4
phoenix 4
phoenix 4
phoenix 4
phoenix 4
phoenix 4
phoenix
4
Accelerator
Accelerator
Semaphores
squix
squix
squix
Accelerator
DSPC
65 DSP
cores
picanmix
Accelerator
DSPC
phoenix 4
phoenix 4
phoenix 4
phoenix 4
phoenix 4
phoenix 4
phoenix
Accelerator
obelix
obelix
Accelerator
4
DSPC
Accelerator
CPU
DMA
BusC
DMA
SoC subsystem
Common
Mem
32 MB
DDR3 DDR3
SoC & ASIC Design at Ericsson | © Ericsson AB 2016 | Page 16
© Ericsson AB 2016
6
SoC & ASIC Design at Ericsson
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 (hazardous substances, recycling)
SoC & ASIC Design at Ericsson | © Ericsson AB 2016 | Page 17
SYSTEM IMPLEMENTATION CHOICES
Node system
SW modules
In-house re-use
In-house development
External purchase
Node subsystem
FPGA
ASIC
HW components
IP* block
DSP/CPU
SoC
Hardwired logic
DSP/CPU core
SoC subsystem
HW accelerator
ALU/FPU/...
* IP = Intellectual Property, design block from another source
SoC & ASIC Design at Ericsson | © Ericsson AB 2016 | Page 18
© Ericsson AB 2016
7
SoC & ASIC Design at Ericsson
HW/SW TRADE-OFFS
› System design is in many cases a trade-off between HW
and SW solutions to best meet the systemization
single
set of
requirements:
function functions
Better
HW
Performance
Worse
HW
Flexibility
Power
SW
SW
SW
HW
› The same trade-off applies to
HW
SW
Cost
SW
HW
single
set of
function functions
– ASIC/FPGA vs DSP/CPU
– Hardwired logic vs DSP/CPU cores
SoC & ASIC Design at Ericsson | © Ericsson AB 2016 | Page 19
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)
SoC & ASIC Design at Ericsson | © Ericsson AB 2016 | Page 20
© Ericsson AB 2016
8
SoC & ASIC Design at Ericsson
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 | © Ericsson AB 2016 | Page 21
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)!
SoC & ASIC Design at Ericsson | © Ericsson AB 2016 | Page 22
© Ericsson AB 2016
9
SoC & ASIC Design at Ericsson
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
SoC & ASIC Design at Ericsson | © Ericsson AB 2016 | Page 23
HW VS SW COST
FURTHER 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)
Tailored parallel HW
Computational
graph:
Parallel concurrency
Pipelined concurrency
DSP
DSP
DSP
DSP
General DSP cores
(larger HW cost for
same performance)
SoC & ASIC Design at Ericsson | © Ericsson AB 2016 | Page 24
© Ericsson AB 2016
10
SoC & ASIC Design at Ericsson
HW VS SW COST
HW COST/PERFORMANCE TRADE-OFF
› Often many alternatives for tailoring HW for a function:
– Fast but expensive (parallel HW)
– Slow but cheap (sequential HW)
Cost
Performance
SoC & ASIC Design at Ericsson | © Ericsson AB 2016 | Page 25
HW/SW TRADE-OFFS SUMMARY
Cost
› Finding the best HW/SW trade-off is a multi-dimensional
optimization problem!
Feasible solution space:
Satisfies all constraints
Performance
SoC & ASIC Design at Ericsson | © Ericsson AB 2016 | Page 26
© Ericsson AB 2016
11
SoC & ASIC Design at Ericsson
SYSTEM DESIGN TOOLS AND MODELS
› Signal processing algorithms are designed and analyzed
in Matlab
– Functionality and performance
– Based on GSM/WCDMA/LTE standards
Node subsystem
› 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 ways
SoC
– Spreadsheets for cost, power, capacity
– High-level architectural models for performance
(transaction level models in SystemC)
› SW Virtual Platforms
– High-level functional models for SW development
(transaction level models in SystemC)
SoC & ASIC Design at Ericsson | © Ericsson AB 2016 | Page 27
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 | © Ericsson AB 2016 | Page 28
© Ericsson AB 2016
12
SoC & ASIC Design at Ericsson
RA-DEM ARCHITECTURE
First 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
SoC & ASIC Design at Ericsson | © Ericsson AB 2016 | Page 29
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, resystemization 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 | © Ericsson AB 2016 | Page 30
© Ericsson AB 2016
13
SoC & ASIC Design at Ericsson
RA-DEM SYSTEM DESIGN
PERFORMANCE TRADE-OFF
HW
166M
2.2G
184M
46M 55.6G 19G
SW
588M 588M 1.6G
588M 118M
40M
1.8k
184M
8.8G
36M
2.22M
3.6k
3.6k
3.6k
• Determine the
subfunctions' peak
performance*
requirement (in
OPS)
• Subfunctions that
exceed one DSP
core's performance
(350 MOPS)

HW (to avoid splitting
over several DSPs)
14.4M
3.1G
34.6M
736M
736M
477M
477M
477M
477M
3.1G
6.2G
* A function that requires 10 MOPS
and has to finish in 0.1 s has a peak
performance of 10/0.1 = 100 MOPS
SoC & ASIC Design at Ericsson | © Ericsson AB 2016 | Page 31
RA-DEM SYSTEM DESIGN
FLEXIBILITY TRADE-OFF
HW
166M
2.2G
184M
46M 55.6G 19G
SW
588M 588M 1.6G
588M 118M
40M
1.8k
?
?
184M
8.8G
36M
2.22M
3.6k
3.6k
3.6k
• Determine the
subfunctions'
flexibility
requirement
(upgradable or not)
• Subfunctions that
must be upgradable

SW
• Conflicting trade-offs
may occur!
14.4M
3.1G
34.6M
736M
736M
477M
477M
477M
477M
3.1G
6.2G
SoC & ASIC Design at Ericsson | © Ericsson AB 2016 | Page 32
© Ericsson AB 2016
14
SoC & ASIC Design at Ericsson
RA-DEM SYSTEM DESIGN
CONCURRENCY TRADE-OFF
• Determine which
subfunctions that are
inherently
concurrent
HW
166M
2.2G
184M
46M 55.6G 19G
SW
588M 588M 1.6G
588M 118M
40M
1.8k
?
?
184M
8.8G
36M
2.22M
3.6k
3.6k
3.6k
• Subfunctions with
high degree of
concurrency and
reasonably high
performance
requirement

HW
14.4M
3.1G
34.6M
736M
736M
477M
477M
477M
477M
3.1G
6.2G
SoC & ASIC Design at Ericsson | © Ericsson AB 2016 | Page 33
RA-DEM SYSTEM DESIGN
HW COST TRADE-OFF
• Cost of HW
implementation =
area of tailored HW
HW
166M
2.2G
184M
46M 55.6G 19G
SW
588M 588M 1.6G
588M 118M
45|
35|
30| 20|
457+10 168+10 34+2 11+2
8.8G
36M
3|
10+3
2.22M
3.6k
3.6k
4|
0+3
5|
1+3
1.8k
?
?
184M
40M
5|
0+2
3.6k
• Express as % of a DSP
core's area:
5|
0+2
Tailored HW area|
DSP area + interconnect
14.4M
3.1G
3.1G
34.6M
736M
• Cost of SW (DSP core)
implementation =
(load requirement/DSP
performance)
· DSP core area
+ extra interconnect
736M
477M
477M
477M
477M
5|
10+10
6.2G
• Subfunctions with
lower HW cost

HW, the rest

SW
SoC & ASIC Design at Ericsson | © Ericsson AB 2016 | Page 34
© Ericsson AB 2016
15
SoC & ASIC Design at Ericsson
RA-DEM SYSTEM DESIGN
RESOLVING CONFLICTS
HW
166M
166M
72M
› The
›SWHow important is the
2.2G
2.2G conflict is caused
588M
by the requirement on
flexibility?
1.6G
40M
1.8k
46M
118M
184M
47M
184M
55.6G 19G 588M
588M 588M
588M588M
588M
40M
1.8k
1.6G
294M 118M
flexibility
–46M
everything
– If worth the extra cost (4.22
?
??
184M points to a HW
else
resp 1.43 cores)
184M
45|
35|
30| 20|
5|

solution
457+10 168+10 34+2 11+2
0+2
3.6k
SW, otherwise HW
36M vs
2.22M
3.6k
3.6k
› Cost for
HW
1.8k
8.8G 4.32M
1.66M
1.8k
36M
2.22M
3.6k
3.6k
3.6k
› Or, re-systemize:
DSP core:
– 0.45 vs
3| 4.67 5|cores
4|
14.4M 0+3
10+3
1+3
– 0.35 vs 1.78 cores 14.4M
3.6M
3.1G
3.1G
34.6M
4.32M
34.6M
736M
92M
736M
5|
0+2
736M
736M
92M
477M
477M
59.6M
5|
10+10
6.2G
59.6M
477M
477M
– Can the flexibility
requirement be isolated to
part of the subfunction?

477M Split into sub-subfunctions
477M
59.6M
and map to HW resp SW
– Can we use SWconfigurable HW?
59.6M
477M
477M
SoC & ASIC Design at Ericsson | © Ericsson AB 2016 | Page 35
Design Challenges
for SoCs
© Ericsson AB 2016
16
SoC & ASIC Design at Ericsson
RBS SIGNAL PROCESSING ASICS
1995-2015 – SIZES
Memory
5G
4 billion
transistors
Transistors
2G
1G
500 M
200 M
Logic
100 M
50 M
20 M
10 M
2 million
transistors
5M
SoC & ASIC Design at Ericsson | © Ericsson AB 2016 | Page 37
TECHNOLOGIES AND CHALLENGES
5G
Transistors
Sum of all!
Variation
2G
1G
500 M
Signal
integrity
50 M
20 M
10 M
5M
Wire
delay
16 nm
65 nm
Soft errors
100 M
28 nm
40 nm
45 nm
Leakage
power
200 M
+Reliability
90 nm
130 nm
130 nm
180 nm
Visible light: 400-700 nm
Si atom diameter: 0.2 nm
Si atom
250 nm
800 nm
16 nm feature
½ wavelength of 400 nm light
SoC & ASIC Design at Ericsson | © Ericsson AB 2016 | Page 38
© Ericsson AB 2016
17
SoC & ASIC Design at Ericsson
WIRE DELAY, CROSSTALK, SOFT
ERRORS
› Wire delay dominates over logic delay at ≤ 350 nm
– 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 ≤ 180 nm
– 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 ≤ 130 nm
– Solution: Error correction coding of memory content
– m
SoC & ASIC Design at Ericsson | © Ericsson AB 2016 | Page 39
LEAKAGE POWER
› Leakage current (transistor turn-off current) is a major
Conventional
power reduction
contributor to power dissipation at ≤ 90 nm
methods apply
to dynamic power
Typical
power
budget
Power dissipation
100%
80%
60%
40%
Dynamic
20%
Leakage
0%
Technology
› Power is a limiting factor for design also for stationary
equipment (i.e., not battery operated)
– Cooling
– Energy consumption
SoC & ASIC Design at Ericsson | © Ericsson AB 2016 | Page 40
© Ericsson AB 2016
18
SoC & ASIC Design at Ericsson
Mean Number of Dopant Atoms
PROCESS VARIATION AT THE ATOMIC
SCALE
10000
Random dopant fluctuation:
Number of dopant atoms
1000
100
10
1000
500
250
130
65
32
› Parameter variation increases
with decreasing geometry:
–
–
–
–
–
Dopant
Instrumentation
Mask precision
Lithography
Variations between fabs and
batches
› Timing characteristics vary
significantly from chip to chip
Technology Node (nm)
SoC & ASIC Design at Ericsson | © Ericsson AB 2016 | Page 41
RELIABILITY AT 16 NM AND BELOW
› Increased risk of device failure after years of operation, due
to the small geometry making the device more sensitive to:
– Electromigration: Can cause opens in
wires due to gradual displacement
of metal ions caused by high current
density
– Electrostatic discharge: Can cause shorts; increased risk due to
small margin between operating voltage and breakdown voltage
– Thermal heating: High current density leads to local heating which
can lead to defects such as cracks (due to heat expansion)
› Hard to completely eliminate, but effects can be reduced by
proper physical design and geometry of transistors and
wires
SoC & ASIC Design at Ericsson | © Ericsson AB 2016 | Page 42
© Ericsson AB 2016
19
SoC & ASIC Design at Ericsson
WHY ASIC?
› 95 % of the functionality on a radio base station receiver
board is signal processing
› Developing an ASIC takes 1-1.5 year and costs several
10 MSEK
› Buying a high-performance DSP costs 2000 SEK and it is
available off the shelf
› So why do we keep making ASICs?
SoC & ASIC Design at Ericsson | © Ericsson AB 2016 | Page 43
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 (100-1000 SEK)
› Cons:
– Expensive to introduce (high
development cost)
– Available after 1-2 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-3000
SEK)
SoC & ASIC Design at Ericsson | © Ericsson AB 2016 | Page 44
© Ericsson AB 2016
20
SoC & ASIC Design at Ericsson
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 to medium performance
Si process (high Vt transistors)
 Low current leakage
 Low to 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 (1001000 W)
SoC & ASIC Design at Ericsson | © Ericsson AB 2016 | Page 45
SoC/ASIC Design Flow
© Ericsson AB 2016
21
SoC & ASIC Design at Ericsson
FROM IDEA  COMPONENT ...
E
ROP1011503
R1A
SoC & ASIC Design at Ericsson | © Ericsson AB 2016 | Page 47
... LIKE THIS?
Great! Let's go
hack some
code!
Hey! I've got
this marvelous
idea!
Building practice?
Signal integrity?
Power budget? Product structure?
Geez... Imagine
life without VHDL...
Vendor negotiations?
Interfaces?
Supply agreement? Patents?
Product plans? Software?
O&M?
System integration?
Producibility?
Price models?
Market
window?
Soft errors?
System verification? Reliability?
Debug?
Test? Firmware?
Type approval?
E
Export control?
Thermal design?
Your ASIC vendor
Board?
ROP1011503
R1A
Invoice
$ 1,000,000
Environmental protection restrictions?
Documentation? Version control?
SoC & ASIC Design at Ericsson | © Ericsson AB 2016 | Page 48
© Ericsson AB 2016
22
SoC & ASIC Design at Ericsson
MAIN STEPS
Technology study
Structuring
HW modeling & design
SW modeling & design
ASIC technology mapping
SW implementation
ASIC prototype manufacturing
SW verification
ASIC prototype verification
SoC & ASIC Design at Ericsson | © Ericsson AB 2016 | Page 49
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
Hey! I've got
this marvelous
idea!
Great! Let's go
hack some
code!
› Create a high level description of the system architecture
(text and graphics)
› Provide a decision base for project launch decision
SoC & ASIC Design at Ericsson | © Ericsson AB 2016 | Page 50
© Ericsson AB 2016
23
SoC & ASIC Design at Ericsson
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 | © Ericsson AB 2016 | Page 51
TYPICAL ASIC DESIGN FLOW
Specification
Coding
Front-end
IP (macros)
Processor cores
BIST & TAPC
RAMs
PLL
Synthesis
Design &
verification of
Floorplanning
- function
Back-end
Place & Route
- timing
- power
Production
Ericsson
ASIC vendor
Prototypes
SoC & ASIC Design at Ericsson | © Ericsson AB 2016 | Page 52
© Ericsson AB 2016
24
SoC & ASIC Design at Ericsson
ASIC DEVELOPMENT ACTIVITIES
Block development
ASIC chip development
Specification
Specification
Verification planning
Verification planning
Define TLM test cases
Build TLM testbench
TLM modeling
Define properties
TLM simulation
Define RTL test cases
Debug - Correct
TLM integration
Verification management
Define TLM test cases
Build TLM testbench
TLM simulation (run SW)
Debug - Correct
RTL modeling
Build RTL testbench
RTL design rule check
Formal property check
ASIC realization
(by ASIC vendor)
RTL integration
Verification management
RTL simulation
Define RTL test cases
Build RTL testbench
RTL simulation
Debug - Correct
Debug - Correct
Connectivity check (formal)
Build emulation
Constraints (re-)definition
testbench
Logic synthesis
Design planning
Define emulation
DFT insertion
test cases
Equivalence check
Emulation (with SW)
Continued verification (simulation, formal)
Debug – Correct/work around
Build regression test suite
Several
deliveries
3 rounds of
deliveries
DFT implementation
Continued verification
(simulation, emulation)
Static timing analysis
Gate level simulation
Place & Route
Debug – Correct/work
around
Debug – Correct (ECO)
Design rule check
Build regression
test suite
Prototype verification
Timing back-annotation
Floorplanning
Parasitic extraction
Chip manufacturing
Debug – Work around
SoC & ASIC Design at Ericsson | © Ericsson AB 2016 | Page 53
BLOCK DEVELOPMENT
Block development
ASIC chip development
Specification
Specification
Verification planning
Verification planning
Define TLM test cases
Build TLM testbench
TLM modeling
Define properties
TLM simulation
Define RTL test cases
Debug - Correct
TLM integration
Verification management
Define TLM test cases
Build TLM testbench
TLM simulation (run SW)
Debug - Correct
RTL modeling
Build RTL testbench
RTL design rule check
Formal property check
ASIC realization
(by ASIC vendor)
RTL integration
Verification management
RTL simulation
Debug - Correct
Continued verification (simulation, formal)
Debug – Correct/work around
Build regression test suite
Several
deliveries
Define RTL test cases
Build RTL testbench
RTL simulation
Debug - Correct
Connectivity check (formal)
Build emulation
Constraints (re-)definition
testbench
Logic synthesis
Design planning
Define emulation
DFT insertion
test cases
3 rounds of
deliveries
Emulation (with SW)
Equivalence check
Continued verification
(simulation, emulation)
Static timing analysis
Floorplanning
Gate level simulation
Place & Route
Debug – Correct/work
around
Build regression
test suite
Prototype verification
Debug – Correct (ECO)
Timing back-annotation
DFT implementation
Design rule check
Parasitic extraction
Chip manufacturing
Debug – Work around
SoC & ASIC Design at Ericsson | © Ericsson AB 2016 | Page 54
© Ericsson AB 2016
25
SoC & ASIC Design at Ericsson
SPECIFICATION
› Each function block has a Design
Specification
– There are also
Interface Descriptions,
Verification Specifications,
Verification Reports
+ a number of other documents
› Example of
content:
SoC & ASIC Design at Ericsson | © Ericsson AB 2016 | Page 55
VERIFICATION PLANNING
Define how to reach verification goals within available
time and resources:
1. Analyze the design requirements to identify features
2. Analyze the features’ characteristics: typical and
extreme data/conditions
3. Set verification goals
–
Include all types of coverage
4. Design tests to achieve verification goals
5. Plan resources for verification (personnel, computers,
licenses)
6. Commence verification
SoC & ASIC Design at Ericsson | © Ericsson AB 2016 | Page 56
© Ericsson AB 2016
26
SoC & ASIC Design at Ericsson
VERIFICATION
FEATURES AND COVERAGE
Three different verification features
› Features of a design
For example, functional
coverage might track whether
the verification process has:
– Operations to perform
– Data to process
– Protocols to follow
•
› Verification goals
– Cover x % of typical cases
– Cover y % of corner cases
– Cover z % of interactions
between features
•
•
› Verification complete when cover
goals reached (and bugs
attended to)
•
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)
Interacting features
SoC & ASIC Design at Ericsson | © Ericsson AB 2016 | Page 57
TRANSACTION LEVEL MODELING
(TLM)
› Model functionality at a
struct sender: sc_module {
high level
sc_out<pkt> pkt_out;
› Communication modeled
sc_in<sc_int<4> > source_id;
as transactions
sc_in_clk CLK;
SC_CTOR(sender)
› Use SystemC and TLM-2
{ SC_CTHREAD(entry, CLK.pos()); }
standard
– Timing can be added
void entry();
};
› Simulates fast (10-1000 x
faster than RTL)
void sender:: entry() {
pkt pkt_data;
while(true) {
// Data generation code ...
pkt_out.write(pkt_data);
wait();
}
› Example SystemC code:
– Communication modeled
as function calls
}
SoC & ASIC Design at Ericsson | © Ericsson AB 2016 | Page 58
© Ericsson AB 2016
27
SoC & ASIC Design at Ericsson
REGISTER TRANSFER LEVEL (RTL)
MODELING
Signal assignments:
› Model functionality and
implementation at HW
level
› Communication modeled Entity with ports:
as signaling
› Use VHDL, Verilog,
SystemVerilog
rcmh_read_req
rcmh_write_req
rcmh_address
rcmh_wmask_req
rcmh_wmask
rcmh_wdata
– Clock-based timing
› Example VHDL code
(excerpts) for a serial
interface:
<=
<=
<=
<=
<=
<=
not sr_data(65)
when req_trigger_d1 =
sr_data(65)
when req_trigger_d1 =
sr_data(63 downto 32) when req_trigger_d1 =
sr_data(64)
when req_trigger_d1 =
sr_data(31 downto 16) when req_trigger_d1 =
sr_data(15 downto 0) when req_trigger_d1 =
'1'
'1'
'1'
'1'
'1'
'1'
else
and
else
and
and
and
'0';
sr_data(64) = '0'
(others => '0');
sr_data(65) = '1'
sr_data(65) = '1'
sr_data(65) = '1'
else '0';
else '0';
else (others => '0');
else (others => '0');
FSM controller (part):
rc_ctrl_fsm : process (state_rs, sr_data(65),
sr_data(64), req_trigger_d1, rcmh_ack,
rcmh_rresult, rc_domain_clear_s)
begin -- process rc_ctrl_fsm
nextstate_rs
<= state_rs;
entity serdes_rif is
read_data_valid <= '0';
port (
case state_rs is
clk
: in std_logic;
when idle_e =>
reset_n : in std_logic;
if rc_domain_clear_s = '0' then
cif_hss_strb
: in std_logic;
if req_trigger_d1 = '1' then
cif_hss_data
: in std_logic_vector(cif_di_width_c downto 0);
if sr_data(65) = '1' then
cif_hss_ack_strb : in std_logic;
nextstate_rs <= wait_acknowledge_w_e;
cif_hss_data_out : out std_logic_vector(cif_do_width_c downto 0);
else
cif_hss_req
: out std_logic;
nextstate_rs <= wait_acknowledge_r_e;
cif_hss_halt
: out std_logic;
end if;
rc_clk
: in std_logic;
end if;
rc_reset_b
: in std_logic;
end if;
rcmh_address
: out std_logic_vector(31 downto 0);
when wait_acknowledge_w_e =>
rcmh_wdata
: out std_logic_vector(15 downto 0);
if rc_domain_clear_s = '0' then
rcmh_wmask
: out std_logic_vector(15 downto 0);
if rcmh_ack = '1' then
rcmh_write_req : out std_logic;
read_data_valid <= '1';
rcmh_wmask_req : out std_logic;
nextstate_rs
<= idle_e;
rcmh_read_req : out std_logic;
end if;
rcmh_ack
: in std_logic;
else
rcmh_rresult
: in std_logic;
nextstate_rs <= idle_e;
rcmh_rdata
: in std_logic_vector(15 downto 0)
end if;
);
when wait_acknowledge_r_e =>
end serdes_rif;
if rc_domain_clear_s = '0' then
if rcmh_ack = '1' then
nextstate_rs <= wait_read_data_e;
end if;
else
nextstate_rs <= idle_e;
end if;
when wait_read_data_e =>
if rc_domain_clear_s = '0' then
if rcmh_rresult = '1' then
read_data_valid <= '1';
nextstate_rs
<= idle_e;
end if;
else
nextstate_rs <= idle_e;
end if;
when others => nextstate_rs <= idle_e;
end case;
end process rc_ctrl_fsm;
+ about 400 additional code lines
of declarations, synchronization
processes, meta-stability handling,
etc
SoC & ASIC Design at Ericsson | © Ericsson AB 2016 | Page 59
SYSTEM PERFORMANCE ANALYSIS
SystemC TLM-2 model (system or sub-system level)
Shared
memory
HW
block
HW
block
Traffic
gen.
DSP
core
Traffic
gen.
IO
Traffic
gen.
Communication Infrastructure
CCI* information exchange:
Registers
Performance analysis
Debug
Internal state
Transaction logging
etc
*CCI = Configuration, Control & Inspection
Latency
Contention
Throughput
Utilization (time, memory)
Bandwidth
Transaction tracing
SoC & ASIC Design at Ericsson | © Ericsson AB 2016 | Page 60
© Ericsson AB 2016
28
SoC & ASIC Design at Ericsson
DEFINE PROPERTIES
› Properties are used for
three purposes:
– Assertions: Define
conditional expected
events and sequences
(what you want to test)
– Assumptions: Constraints
(what states the design can
have)
– Covers: Check that certain
states are reached (can be
prerequisites for tests)
Example assertion: Check
that a bus request is followed
by an acknowledge 1-3 cycles
after the request
SystemVerilog code
SoC & ASIC Design at Ericsson | © Ericsson AB 2016 | Page 61
BUILDING THE RTL TEST BENCH
› Create test benches to verify functional behavior and RTL
implementation
› Feature based verification
› High-level hardware verification language (HVL) with
declarative constructs for compactness
– e, SystemVerilog
› Stimuli generation
– Specify data format rather than exact content
– Random data generators with constraints
› Checkers verify stimuli/response relationship
– Basis for functional coverage analysis
SoC & ASIC Design at Ericsson | © Ericsson AB 2016 | Page 62
© Ericsson AB 2016
29
SoC & ASIC Design at Ericsson
BUILDING THE RTL TEST BENCH
CONSTRAINED RANDOM TESTING
› Instead of specifying which variable values to test, specify
constraints for the interesting ranges
› Auto generate random values within the constraints
Y
Constraint {X}
SystemVerilog code:
Constraint {Y}
ymax
class CRT_example;
rand shortint X;
rand shortint Y;
constraint x1
{X inside {[xmin:xmax]};}
constraint y1
{Y inside {[ymin:ymax]};}
endclass: CRT_example
ymin
xmin
xmax X
SoC & ASIC Design at Ericsson | © Ericsson AB 2016 | Page 63
RTL DESIGN RULE CHECK
› Designability = Ability to design
› Rule check: Find design patterns that
may cause problems in the design
flow
– Static check of HDL code
› Typically several hundred rules
› 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
SoC & ASIC Design at Ericsson | © Ericsson AB 2016 | Page 64
© Ericsson AB 2016
30
SoC & ASIC Design at Ericsson
RTL VERIFICATION AND DEBUG
› First verify assertions by
formal property check
– Mathematical proof that a
behavior always/never occurs
› Then simulate what’s left
– Mathematical computations
– Performance
› Debug is typically
waveform based
SoC & ASIC Design at Ericsson | © Ericsson AB 2016 | Page 65
VERIFICATION MANAGEMENT
› Collect results from all dispatched jobs
– Failures (design errors)
– Coverage
› Track progress of test suite
A session = a sequence of tests
P – Passed
F – Failed
R – Running
W – Waiting
O – Other
SoC & ASIC Design at Ericsson | © Ericsson AB 2016 | Page 66
© Ericsson AB 2016
31
SoC & ASIC Design at Ericsson
ASIC CHIP (TOP-LEVEL)
DEVELOPMENT
Block development
ASIC chip development
Specification
Specification
Verification planning
Verification planning
Define TLM test cases
Build TLM testbench
TLM modeling
Define properties
TLM simulation
Define RTL test cases
Debug - Correct
TLM integration
Verification management
Define TLM test cases
Build TLM testbench
TLM simulation (run SW)
Debug - Correct
RTL modeling
Build RTL testbench
RTL design rule check
Formal property check
ASIC realization
(by ASIC vendor)
RTL integration
Verification management
RTL simulation
Debug - Correct
Continued verification (simulation, formal)
Debug – Correct/work around
Build regression test suite
Several
deliveries
Define RTL test cases
Build RTL testbench
RTL simulation
Debug - Correct
Connectivity check (formal)
Build emulation
Constraints (re-)definition
testbench
Logic synthesis
Design planning
Define emulation
DFT insertion
test cases
Equivalence check
Emulation (with SW)
3 rounds of
deliveries
DFT implementation
Continued verification
(simulation, emulation)
Static timing analysis
Gate level simulation
Place & Route
Debug – Correct/work
around
Debug – Correct (ECO)
Design rule check
Build regression
test suite
Prototype verification
Timing back-annotation
Floorplanning
Parasitic extraction
Chip manufacturing
Debug – Work around
SoC & ASIC Design at Ericsson | © Ericsson AB 2016 | Page 67
EMULATION
› RTL or gate level verification
› Acceleration: Replace design in simulation (keep
simulated test bench)
› In Circuit Emulation: Replace circuit on board with model
in emulator; connect emulator to board
› Emulates design with configurable hardware arrays
(FPGAs or custom developed)
– Extremely fast, ~1 M cycles/s
› Requires long test cases for efficient use
– Random or real data streams,
application SW
SoC & ASIC Design at Ericsson | © Ericsson AB 2016 | Page 68
© Ericsson AB 2016
32
SoC & ASIC Design at Ericsson
HW/SW CO-VERIFICATION
EXAMPLE
› Typical signal processing architecture:
DSP SW
Control SW
ASIC
DSP
DSP
DSP
CPU
Logic & RAM
EPROM
SoC & ASIC Design at Ericsson | © Ericsson AB 2016 | Page 69
HW/SW
CO-VERIFICATION
SW
HW
Test DSP SW
DSP SW
ASIC HW
Step 1
Simulator
ASIC integration
Step 2
DSP model
HW SW
Step 3
Control SW
DSP SW
host environment
Control SW
host environment
DSP SW
verification
Control SW
verification
Simulator + C
SW target
environment
ASIC/DSP SW
co-verification
Emulator
SW integration
IP models
(CPUs etc)
HW/SW co-verification
SoC & ASIC Design at Ericsson | © Ericsson AB 2016 | Page 70
© Ericsson AB 2016
33
SoC & ASIC Design at Ericsson
SYNTHESIS AND DESIGN PLANNING
› Map RTL to optimized gate level netlist
– Needs cell library for target
technology
› Work towards goals
– Typically minimized area or power
› Find result within constraints
– Typically timing or power
› Synthesis result depends on physical
layout
Synthesis
Area
Timing
– Layout affects timing constraints
Layout
› Physical layout depends on synthesis
– Synthesis determines size of blocks
› Good result requires interaction synthesis –
design planning (= preliminary layout)
SoC & ASIC Design at Ericsson | © Ericsson AB 2016 | Page 71
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
Equivalent?
– Reference design logically
implies* compared design
– No test bench, no test vectors
– Verifies complete design
*
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.
SoC & ASIC Design at Ericsson | © Ericsson AB 2016 | Page 72
© Ericsson AB 2016
34
SoC & ASIC Design at Ericsson
STATIC TIMING ANALYSIS
› Verify timing
› Gate level
› Estimated or back-annotated timing from layout
› 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
Timing path for worst case (setup check)
max_path time
d
ck
setup time min_path time
SoC & ASIC Design at Ericsson | © Ericsson AB 2016 | Page 73
BACK-END DESIGN & VERIFICATION
Typically at least
3 deliveries
to ASIC vendor
RTL
Equivalence
checker
Constraints
Back-end design &
verification team
Synthesis
=
Preliminary netlist
Equivalence
checker
Increasing
precision
Floorplanning
Test insertion
NHO netlist
Equivalence
checker
Place & Route
Test insertion
Sign-off netlist
SDF
Static Timing
Analyzer
Simulator
SDF
Static Timing
Analyzer
Simulator
Ericsson
SIGN-OFF!
ASIC vendor
SoC & ASIC Design at Ericsson | © Ericsson AB 2016 | Page 74
© Ericsson AB 2016
35
SoC & ASIC Design at Ericsson
PROTOTYPE VERIFICATION
› Establish that ASIC prototypes
meet specifications:
–
–
–
–
–
› Tested in lab environment:
– production board or test board
functionality at full speed
interaction between blocks
I/O pad connectivity
timing on interfaces
electrical characteristics
Simulation
test vectors
CPU SW
Logic analyzer
Oscilloscope
Data generator
DSP SW
BGA adapter
CPU debugger
RISCWatch/Green Hills Probe
DSP core debugger
E
ROP1011503
R1A
Other components
Ericsson inhouse
SoC & ASIC Design at Ericsson | © Ericsson AB 2016 | Page 75
ASIC DESIGN FLOW – OVERVIEW
TLM design entry
Verification planning
Performance analysis
TLM simulation
Verification environment
design & entry
RTL power analysis
RTL design entry
Testbench qualification
Architectural exploration
CDC check
Switching
frequencies
SW
Rule check
Formal verification
RTL simulation
Debug
Test coverage
Design planning
Logic synthesis
Static timing analysis
Equivalence check
Gate level
power analysis
Gate simulation
Verification run
management
Acceleration
Reference models
Test vectors
Timing & Loads
ASIC vendor back-end
& manufacture
Gate emulation
Design activity
Verification activity
Prototype verification
SoC & ASIC Design at Ericsson | © Ericsson AB 2016 | Page 76
© Ericsson AB 2016
36
SoC & ASIC Design at Ericsson
LOGIC DESIGN FLOW
Design
Design
Netlist
exploration
rules
verification
Timing Power
RTL
Synthesis
Simulation
VHDL/
(System)Verilog
Switching
SAIF
Constraints
TLM
SystemC
RTL power
analysis
TCL
Design
rules
Timing
model
Floorplan data
DEF/MW
DB
Power
model
DB
Architectural
exploration
Rule check
Equivalence
Design
planning
check
Verification
setup
SVF
Analysis
database
Logic
synthesis
DRC
reports
Simulation
Gate level
power
analysis
Netlist
Verilog
Parasitics
Performance
reports
Static
Timing
Analysis
Reports
- area
- timing
- power
- DRC
Power
reports
Timing
SDF
ASIC vendor
back-end
SoC & ASIC Design at Ericsson | © Ericsson AB 2016 | Page 77
RTL FUNCTIONAL
VERIFICATION FLOW
HW/SW co-verification
Target debug
Requirements
Ref. model
(alg. parts)
Verification
IP
C++
eVC/UVC
RTL code
Testbench
Properties
VHDL/
(System)Verilog
e/
SystemVerilog
SVA
Testbench
qualification
DSP SW
Verification
management
Verification
planning
Directed tests
Constrained
random tests
Assertions
Modify/
Extend
Emulation
Board
environment
Acceleration
OK
Simulation
OK
Formal
verification
Verification
run
management
Test coverage OK
Code coverage
Functional
coverage
Assertion
coverage
SoC & ASIC Design at Ericsson | © Ericsson AB 2016 | Page 78
© Ericsson AB 2016
37
SoC & ASIC Design at Ericsson
LANGUAGES
Block development
ASIC chip development
Specification
Specification
Verification planning
Verification planning
Define TLM test cases
SystemC/C++
Build TLM testbench
SVA,properties
PSL
Define
Define RTL test cases
SystemVerilog,
e
TLM modeling
SystemC
SystemC/C++
Build TLM testbench
Debug - Correct
Debug - Correct
VHDL
Formal property check
Verification management
Define TLM test cases
TLM integration
TLM simulation (run SW)
TLM simulation
RTL modeling
Build RTL testbench
RTL design rule check
ASIC realization
(by ASIC vendor)
Define RTL test cases
SystemVerilog,
e
Build RTL testbench
RTL integration
Verification management
RTL simulation
Debug - Correct
Continued verification (simulation, formal)
Debug – Correct/work around
Build regression test suite
Several
deliveries
RTL simulation
Debug - Correct
Connectivity check (formal)
Build emulation
Constraints (re-)definition
testbench
Logic synthesis
Design planning
Define emulation
DFT insertion
test cases
Verilog
Equivalence check
Emulation (with SW)
3 rounds of
deliveries
DFT implementation
Continued verification
(simulation, emulation)
Static timing analysis
Gate level simulation
Place & Route
Debug – Correct/work
around
Debug – Correct (ECO)
Design rule check
Build regression
test suite
Prototype verification
Floorplanning
Timing back-annotation
Parasitic extraction
Chip manufacturing
Debug – Work around
SoC & ASIC Design at Ericsson | © Ericsson AB 2016 | Page 79
AFTER PROTOTYPE VERIFICATION
Design & verification
ASIC prototype verification
Board
Board verification
Subsystem SW
Subsystem verification
Other
subsystems
Design & verification
Design & verification
Design & verification
System verification
Design & verification
System
SW
Mechanics
Type approval
Sales & marketing
SoC & ASIC Design at Ericsson | © Ericsson AB 2016 | Page 80
© Ericsson AB 2016
38
SoC & ASIC Design at Ericsson
WANT TO PARTICIPATE?
› Do you want to:
– Contribute to the world-wide expansion of mobile communications?
– Use the absolutely latest microelectronics technology?
– Be part of a world class ASIC design team, working in a global
environment?
– Work at the world leading telecommunications company?
› Look for job opportunities and thesis works at
www.ericsson.com/careers !
SoC & ASIC Design at Ericsson | © Ericsson AB 2016 | Page 81
SoC & ASIC Design at Ericsson | © Ericsson AB 2016 | Page 83
© Ericsson AB 2016
39