SoC & ASIC Design at Ericsson
SOC & ASIC DESIGN
AT ERICSSON
Björn Fjellborg
Ericsson AB, Radio Hardware Design
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 2014 | Page 2
© Ericsson AB 2014
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 2014 | Page 4
© Ericsson AB 2014
2
SoC & ASIC Design at Ericsson
ERICSSON RADIO BASE STATION
›
›
›
›
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
3202 Indoor
› MCPA fan
SoC & ASIC Design at Ericsson | © Ericsson AB 2014 | Page 5
AN LTE (4G) SIGNAL PROCESSING
ASIC
RBS 6201
›
›
›
›
›
›
›
›
›
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 2014 | Page 7
© Ericsson AB 2014
3
SoC & ASIC Design at Ericsson
Systemization and
System Design
THE CELLULAR ROADMAP
10G
Bits/s
5G
1G
4G
eHSPA
Evolved 3G
10M
("Turbo 3G")
See next page
for abbreviations
1M
HSPA
3G
10k
2G
Email
Voice
WAP
SMS
GSM
1990
1995
Video
streaming/
download
2000
Online video,
audio, radio
Smart grid
Augmented reality
Smart home
SW downloads
Cloud
services,
storage
App updates
Social
networking
Push to talk/
walkie-talkie
Location/positioning Web feeds/
RSS
services
2005
UHDTV
HDTV
High speed data
and web access
Video telephony/
UMTS/WCDMA
conference
WiMAX Data streaming,
Online
Web access
gaming,
Virtual
EDGE
Audio streaming/
worlds
download
HSCSD
2.5G
Interactive data
GPRS
MMS
100k
LTE
Mobile WiMAX
Internet of Things
Networked Society
100M
Connected
vehicles
LTE-A
4G
2010
Connected
wearables
2015
2020
SoC & ASIC Design at Ericsson | © Ericsson AB 2014 | Page 11
© Ericsson AB 2014
4
SoC & ASIC Design at Ericsson
ABBREVIATIONS
›
›
›
›
›
›
›
›
›
›
›
›
›
›
›
›
›
EDGE
eHSPA
GPRS
GSM
HDTV
HSCSD
HSPA
LTE
LTE-A
MMS
RSS
SMS
UHDTV
UMTS
WAP
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
Wireless Application Protocol
Wideband Code Division Multiple Access
Worldwide Interoperability for Microwave Access
SoC & ASIC Design at Ericsson | © Ericsson AB 2014 | Page 12
MOBILE TRAFFIC DEVELOPMENT
SoC & ASIC Design at Ericsson | © Ericsson AB 2014 | Page 13
© Ericsson AB 2014
5
SoC & ASIC Design at Ericsson
THE CELLULAR ROADMAP
10G
Bits/s
5G
1G
4G
Evolved 3G
("Turbo 3G")
10M
HSPA
LTE
Mobile WiMAX
eHSPA
Video
streaming/
download
Online video,
audio, radio
Video telephony/
conference
Online
Web access
gaming,
Virtual
Audio streaming/
worlds
download
10k
Email
2G
Voice
SMS
GSM
1990
1995
2005
Smart home
Cloud
services,
storage
App updates
Social
networking
Push to talk/
walkie-talkie
WAP
Location/positioning Web feeds/
RSS
services
2000
Augmented reality
SW downloads
HSCSD EDGE
2.5G
Interactive data
GPRS
MMS
100k
Smart grid
High speed data
and web access
UMTS/WCDMA
3G WiMAX
Data streaming,
1M
UHDTV
HDTV
Internet of Things
Networked Society
100M
Connected
vehicles
LTE-A
4G
2010
Connected
wearables
2015
2020
SoC & ASIC Design at Ericsson | © Ericsson AB 2014 | Page 14
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
1990
1G
100M
Application complexity
Air interface complexity
10M
1995
2000
2005
2010
2015
2020
SoC & ASIC Design at Ericsson | © Ericsson AB 2014 | Page 15
© Ericsson AB 2014
6
SoC & ASIC Design at Ericsson
SYSTEM LEVEL(S)
Ericsson terminology:
Radio network
Base station
Network system
Node system
Board + SW package
Node subsystem
ASIC + SW module
SoC
DSP core + SW routines
SoC subsystem
SoC & ASIC Design at Ericsson | © Ericsson AB 2014 | Page 16
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 2014 | Page 17
© Ericsson AB 2014
7
SoC & ASIC Design at Ericsson
SYSTEM IMPLEMENTATION CHOICES
Node system
SW modules
In-house re-use
In-house development
External purchase
Node subsystem
FPGA
ASIC
HW components
DSP/CPU
SoC
IP* block
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 2014 | Page 18
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
› The same trade-off applies to
HW
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 2014 | Page 19
© Ericsson AB 2014
8
SoC & ASIC Design at Ericsson
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 2014 | Page 20
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 2014 | Page 21
© Ericsson AB 2014
9
SoC & ASIC Design at Ericsson
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 2014 | Page 22
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 2014 | Page 23
© Ericsson AB 2014
10
SoC & ASIC Design at Ericsson
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:
DSP
Parallel concurrency
Pipelined concurrency
DSP
DSP
DSP
General DSP cores
(larger HW cost for
same performance)
SoC & ASIC Design at Ericsson | © Ericsson AB 2014 | Page 24
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 2014 | Page 25
© Ericsson AB 2014
11
SoC & ASIC Design at Ericsson
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 2014 | Page 26
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 2014 | Page 27
© Ericsson AB 2014
12
SoC & ASIC Design at Ericsson
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 2014 | Page 28
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 2014 | Page 29
© Ericsson AB 2014
13
SoC & ASIC Design at Ericsson
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 2014 | Page 30
RA-DEM SYSTEM DESIGN
PERFORMANCE TRADE-OFF
HW
72M
2.2G
184M
SW
46M 55.6G 19G 588M 588M 588M
294M 47M
40M
1.8k
184M
8.8G 4.32M
1.66M
1.8k
1.8k
3.6k
• Determine the
subfunctions'
performance
requirement (in
OPS)
• Subfunctions that
exceed one DSP
core's performance
(350 MOPS)
⇒
HW (to avoid splitting
over several DSPs)
3.6M
3.1G
4.32M
92M
92M
59.6M
59.6M
59.6M
59.6M
3.1G
6.2G
SoC & ASIC Design at Ericsson | © Ericsson AB 2014 | Page 31
© Ericsson AB 2014
14
SoC & ASIC Design at Ericsson
RA-DEM SYSTEM DESIGN
FLEXIBILITY TRADE-OFF
HW
72M
2.2G
184M
SW
46M 55.6G 19G 588M 588M 588M
294M 47M
40M
1.8k
?
184M
8.8G 4.32M
1.66M
1.8k
1.8k
3.6k
• Determine the
subfunctions'
flexibility
requirement
(upgradable or not)
• Subfunctions that
must be upgradable
⇒
SW
• Conflicting trade-offs
may occur!
3.6M
3.1G
4.32M
92M
92M
59.6M
59.6M
59.6M
59.6M
3.1G
6.2G
SoC & ASIC Design at Ericsson | © Ericsson AB 2014 | Page 32
RA-DEM SYSTEM DESIGN
LOAD TRADE-OFF
72M
2.2G
SW
588M
1.6G
184M
184M
• Determine the
subfunctions' peak
performance
(OPS/max latency)
HW
166M
46M
46M 55.6G 19G 588M 588M 588M
118M
294M 47M
?
184M
184M
40M
40M
1.8k
1.8k
?
3.6k
36M
8.8G 4.32M
2.22M
1.66M
3.6k
1.8k
3.6k
1.8k
3.6k
14.4M
3.6M
3.1G
34.6M
4.32M
736M
92M
736M
92M
477M
59.6M
477M
59.6M
59.6M
477M
59.6M
477M
–
(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!
3.1G
6.2G
SoC & ASIC Design at Ericsson | © Ericsson AB 2014 | Page 33
© Ericsson AB 2014
15
SoC & ASIC Design at Ericsson
RA-DEM SYSTEM DESIGN
CONCURRENCY TRADE-OFF
72M
2.2G
SW
588M
1.6G
184M
184M
• Determine which
subfunctions that are
inherently
concurrent
HW
166M
46M
46M 55.6G 19G 588M 588M 588M
118M
294M 47M
184M
184M
40M
40M
1.8k
1.8k
?
?
3.6k
36M
8.8G 4.32M
2.22M
1.66M
3.6k
1.8k
3.6k
1.8k
3.6k
14.4M
• Subfunctions with
high degree of
concurrency and
reasonably high
performance
requirement
⇒
HW
3.6M
3.1G
34.6M
4.32M
736M
92M
736M
92M
477M
59.6M
477M
59.6M
59.6M
477M
59.6M
477M
3.1G
6.2G
SoC & ASIC Design at Ericsson | © Ericsson AB 2014 | Page 34
RA-DEM SYSTEM DESIGN
HW COST TRADE-OFF
72M
2.2G
SW
588M
1.6G
184M
184M
46M
46M 55.6G 19G 588M 588M 588M
118M
294M 47M
40M
40M
45|
35|
30| 20|
457+10 168+10 34+2 11+2
3|
10+3
2.22M
1.66M
5|
1+3
3.6k
1.8k
4|
14.4M 0+3
1.8k
1.8k
?
?
184M
184M
36M
8.8G 4.32M
• Cost of HW
implementation =
area of tailored HW
HW
166M
3.6k
1.8k
5|
0+2
3.6k
3.6k
• Express as % of a DSP
core's area:
5|
0+2
Tailored HW area|
DSP area + interconnect
3.6M
3.1G
3.1G
34.6M
4.32M
736M
92M
• Cost of SW (DSP core)
implementation =
(load requirement/DSP
performance)
· DSP core area
+ extra interconnect
736M
92M
477M
59.6M
477M
59.6M
59.6M
477M
59.6M
477M
5|
10+10
6.2G
• Subfunctions with
lower HW cost
⇒
HW, the rest
⇒
SW
SoC & ASIC Design at Ericsson | © Ericsson AB 2014 | Page 35
© Ericsson AB 2014
16
SoC & ASIC Design at Ericsson
RA-DEM SYSTEM DESIGN
RESOLVING CONFLICTS
HW
166M
72M
› The
›SWHow important is the
2.2G conflict is caused
588M
by the requirement on
1.6G
flexibility?
46M
40M
1.8k
184M
118M
184M
55.6G 19G 588M 588M 588M
294M 47M
40M
1.8k
flexibility
–46M
everything
– If worth the extra cost (4.22
?
?
184M points to a HW solution
else
resp 1.43 cores)
184M
45|
35|
30| 20|
5|
⇒
457+10
168+10
34+2
11+2
0+2
› Cost for HW vs
3.6k
SW,
otherwise HW
36M
2.22M
3.6k
3.6k
DSP core:
1.8k
8.8G 4.32M
1.66M
1.8k
3.6k
›
Or,
re-systemize:
– 0.45 vs 4.67 cores
3| 1.785|cores
– 0.35 vs
10+3
1+3
4|
14.4M 0+3
5|
0+2
3.6M
3.1G
3.1G
34.6M
4.32M
736M
92M
736M
92M
477M
59.6M
5|
10+10
6.2G
59.6M
477M
– Can the flexibility
requirement be isolated to
part of the subfunction?
⇒
477M Split into sub-subfunctions
59.6M
and map to HW resp SW
– Can we use SWconfigurable HW?
59.6M
477M
SoC & ASIC Design at Ericsson | © Ericsson AB 2014 | Page 36
Design Challenges
for SoCs
© Ericsson AB 2014
17
SoC & ASIC Design at Ericsson
5G
Transistors
3 billion
transistors
2G
1G
Memory
RBS SIGNAL PROCESSING ASICS
1995-2013 – SIZES
500 M
200 M
Logic
100 M
50 M
20 M
10 M
2 million
transistors
5M
1995
1998
2004
2001
2007
2010
2013
SoC & ASIC Design at Ericsson | © Ericsson AB 2014 | Page 38
TECHNOLOGIES AND CHALLENGES
5G
Transistors
Sum of all!
2G
32 nm
Variation
1G
500 M
Leakage
power
200 M
65 nm
Soft errors
Signal
integrity
100 M
Wire
delay
50 M
0.18 µm
20 M
0.13 µm
90 nm
0.13 µm
0.25 µm
10 M
5M
40 nm
45 nm
0.8 µm
1995
1998
2001
2004
2007
2010
2013
SoC & ASIC Design at Ericsson | © Ericsson AB 2014 | Page 39
© Ericsson AB 2014
18
SoC & ASIC Design at Ericsson
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 | © Ericsson AB 2014 | Page 40
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 2014 | Page 41
© Ericsson AB 2014
19
SoC & ASIC Design at Ericsson
Mean Number of Dopant Atoms
PROCESS VARIATION AT THE ATOMIC
SCALE
10000
Random dopant fluctuation:
Number of dopant atoms
› Parameter variation increases
with decreasing geometry:
–
–
–
–
–
1000
100
10
1000
500
250
130
65
32
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 2014 | Page 42
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 2014 | Page 43
© Ericsson AB 2014
20
SoC & ASIC Design at Ericsson
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 2014 | Page 44
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 2014 | Page 45
© Ericsson AB 2014
21
SoC & ASIC Design at Ericsson
SoC/ASIC Design Flow
FROM IDEA ⇒ COMPONENT ...
E
ROP1011503
R1A
SoC & ASIC Design at Ericsson | © Ericsson AB 2014 | Page 47
© Ericsson AB 2014
22
SoC & ASIC Design at Ericsson
... 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?
Reliability?
System verification?
Debug?
Test? Firmware?
Your ASIC vendor
Type approval?
Invoice
Export control?
Thermal design?
E
Board?
ROP1011503
R1A
$ 1,000,000
Environmental protection restrictions?
Documentation? Version control?
SoC & ASIC Design at Ericsson | © Ericsson AB 2014 | Page 48
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 2014 | Page 49
© Ericsson AB 2014
23
SoC & ASIC Design at Ericsson
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 2014 | Page 50
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 2014 | Page 51
© Ericsson AB 2014
24
SoC & ASIC Design at Ericsson
TYPICAL ASIC DESIGN FLOW
Specification
Coding
Front-end
Synthesis
Design &
IP (macros)
verification of
Processor cores
BIST & TAPC
RAMs
PLL
Floorplanning
- function
Back-end
- timing
- power
Place & Route
Production
Ericsson
Prototypes
ASIC vendor
SoC & ASIC Design at Ericsson | © Ericsson AB 2014 | Page 52
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
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
Define RTL test cases
Build RTL testbench
RTL simulation
Debug - Correct
Verification management
RTL simulation
Debug - Correct
Verification management
Continued verification (simulation, formal)
Debug – Correct/work around
Build regression test suite
Several
deliveries
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
DFT implementation
Continued verification
(simulation, emulation)
Static timing analysis
Floorplanning
Gate level simulation
Place & Route
Debug – Correct/work
around
Debug – Correct (ECO)
Design rule check
Build regression
test suite
Prototype verification
Timing back-annotation
Parasitic extraction
Chip manufacturing
Debug – Work around
SoC & ASIC Design at Ericsson | © Ericsson AB 2014 | Page 53
© Ericsson AB 2014
25
SoC & ASIC Design at Ericsson
BLOCK DEVELOPMENT
Block development
ASIC chip development
Specification
Specification
Verification planning
Verification planning
Define TLM test cases
Build TLM testbench
TLM modeling
TLM integration
Define TLM test cases
Build TLM testbench
Define properties
TLM simulation
TLM simulation (run SW)
Define RTL test cases
Debug - Correct
Debug - Correct
RTL modeling
Build RTL testbench
RTL design rule check
Formal property check
RTL integration
ASIC realization
(by ASIC vendor)
Define RTL test cases
Build RTL testbench
RTL simulation
Debug - Correct
Verification management
RTL simulation
Debug - Correct
Verification management
Connectivity check (formal)
Build emulation
Constraints (re-)definition
testbench
Logic synthesis
Design planning
Define emulation
DFT insertion
test cases
Continued verification (simulation, formal)
Debug – Correct/work around
Build regression test suite
Several
deliveries
≥3 rounds of
deliveries
Emulation (with SW)
Equivalence check
DFT implementation
Continued verification
(simulation, emulation)
Static timing analysis
Floorplanning
Debug – Correct/work
around
Build regression
test suite
Prototype verification
Gate level simulation
Place & Route
Debug – Correct (ECO)
Design rule check
Timing back-annotation
Parasitic extraction
Chip manufacturing
Debug – Work around
SoC & ASIC Design at Ericsson | © Ericsson AB 2014 | Page 54
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 2014 | Page 55
© Ericsson AB 2014
26
SoC & ASIC Design at Ericsson
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 2014 | Page 56
VERIFICATION
FEATURES AND COVERAGE
Three different verification features
› Features of a design
– 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)
For example, functional
coverage might track whether
the verification process has:
•
•
•
•
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 2014 | Page 57
© Ericsson AB 2014
27
SoC & ASIC Design at Ericsson
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
void entry();
– Timing can be added
};
› 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 2014 | Page 58
REGISTER TRANSFER LEVEL (RTL)
MODELING
Signal assignments:
rcmh_read_req
rcmh_write_req
rcmh_address
rcmh_wmask_req
rcmh_wmask
rcmh_wdata
<=
<=
<=
<=
<=
<=
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 =
› Model functionality and
implementation at HW
level
› Communication modeled Entity with ports:
as signaling
› Use VHDL, Verilog,
SystemVerilog
– Clock-based timing
› Example VHDL code
(excerpts) for a serial
interface:
'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 2014 | Page 59
© Ericsson AB 2014
28
SoC & ASIC Design at Ericsson
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 2014 | Page 60
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 2014 | Page 61
© Ericsson AB 2014
29
SoC & ASIC Design at Ericsson
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 2014 | Page 62
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 2014 | Page 63
© Ericsson AB 2014
30
SoC & ASIC Design at Ericsson
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 2014 | Page 64
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 2014 | Page 65
© Ericsson AB 2014
31
SoC & ASIC Design at Ericsson
VERIFICATION MANAGEMENT
› Collect results from all dispatched jobs
– Failures (design errors)
– Coverage
› Track progress of test suite
P – Passed
F – Failed
R – Running
W – Waiting
O – Other
A session = a sequence of tests
SoC & ASIC Design at Ericsson | © Ericsson AB 2014 | Page 66
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
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
Define RTL test cases
Build RTL testbench
RTL simulation
Debug - Correct
Verification management
RTL simulation
Debug - Correct
Verification management
Continued verification (simulation, formal)
Debug – Correct/work around
Build regression test suite
Several
deliveries
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
DFT implementation
Continued verification
(simulation, emulation)
Static timing analysis
Floorplanning
Gate level simulation
Place & Route
Debug – Correct/work
around
Debug – Correct (ECO)
Design rule check
Build regression
test suite
Prototype verification
Timing back-annotation
Parasitic extraction
Chip manufacturing
Debug – Work around
SoC & ASIC Design at Ericsson | © Ericsson AB 2014 | Page 67
© Ericsson AB 2014
32
SoC & ASIC Design at Ericsson
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 2014 | Page 68
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 2014 | Page 69
© Ericsson AB 2014
33
SoC & ASIC Design at Ericsson
HW/SW
CO-VERIFICATION
SW
HW
Test DSP SW
DSP SW
ASIC HW
Step 1
Control SW
DSP SW
host environment
Simulator
DSP SW
verification
Control SW
verification
Simulator + C
SW target
environment
ASIC integration
Step 2
DSP model
Control SW
host environment
ASIC/DSP SW
co-verification
HW SW
Step 3
SW integration
IP models
(CPUs etc)
Emulator
HW/SW co-verification
SoC & ASIC Design at Ericsson | © Ericsson AB 2014 | Page 70
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
Timing
– Layout affects timing constraints
Area
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 2014 | Page 71
© Ericsson AB 2014
34
SoC & ASIC Design at Ericsson
EQUIVALENCE CHECK
› Checks functional equivalence of
two designs
– RTL - gate (before and after
synthesis)
– Gate - gate (before and after
netlist modification)
– (RTL - RTL)
Equivalent?
› Formal methods
– 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 2014 | Page 72
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 2014 | Page 73
© Ericsson AB 2014
35
SoC & ASIC Design at Ericsson
BACK-END DESIGN & VERIFICATION
Typically at least
3 deliveries
to ASIC vendor
Constraints
RTL
Equivalence
checker
Back-end design &
verification team
Synthesis
=
Preliminary netlist
Floorplanning
Test insertion
Equivalence
checker
Increasing
precision
Simulator
NHO netlist
Place & Route
Test insertion
Equivalence
checker
Static Timing
Analyzer
SDF
Static Timing
Analyzer
SDF
Simulator
Sign-off netlist
Ericsson
ASIC vendor
SIGN-OFF!
SoC & ASIC Design at Ericsson | © Ericsson AB 2014 | Page 74
PROTOTYPE VERIFICATION
› Establish that ASIC prototypes
meet specifications:
–
–
–
–
–
functionality at full speed
interaction between blocks
I/O pad connectivity
timing on interfaces
electrical characteristics
Simulation
test vectors
CPU SW
› Tested in lab environment:
– production board or test board
Logic analyzer
Oscilloscope
Data generator
DSP SW
BGA adapter
CPU debugger
RISCWatch/Green Hills Probe
DSP core debugger
E
ROP1011503
R1A
Ericsson inhouse
Other components
SoC & ASIC Design at Ericsson | © Ericsson AB 2014 | Page 75
© Ericsson AB 2014
36
SoC & ASIC Design at Ericsson
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
Verification run
management
RTL simulation
Debug
Test coverage
Design planning
Logic synthesis
Static timing analysis
Equivalence check
Gate level
power analysis
Gate simulation
Timing & Loads
ASIC vendor back-end
& manufacture
Acceleration
Reference models
Test vectors
Gate emulation
Design activity
Verification activity
Prototype verification
SoC & ASIC Design at Ericsson | © Ericsson AB 2014 | Page 76
LOGIC DESIGN FLOW
Design
Design
Netlist
exploration
rules
verification
Timing Power
RTL
Synthesis
Simulation
VHDL/
(System)Verilog
Switching
SAIF
Constraints
RTL power
analysis
TCL
TLM
SystemC
Design
rules
Timing
model
Floorplan data
DEF/MW
DB
Power
model
DB
Architectural
exploration
Rule check
Equivalence
check
Design
planning
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 2014 | Page 77
© Ericsson AB 2014
37
SoC & ASIC Design at Ericsson
RTL FUNCTIONAL
VERIFICATION FLOW
HW/SW co-verification
DSP SW
Requirements
Ref. model
(alg. parts)
Verification
IP
C++
eVC/UVC
RTL code
Testbench
Properties
VHDL/
(System)Verilog
e/
SystemVerilog
SVA
Testbench
qualification
Target debug
Verification
management
Verification
planning
Directed tests
Constrained
random tests
Assertions
Modify/
Extend
Emulation
Board
environment
Formal
verification
Verification
run
management
Test coverage OK
Code coverage
Functional
coverage
Assertion
coverage
Simulation
Acceleration
OK
OK
SoC & ASIC Design at Ericsson | © Ericsson AB 2014 | Page 78
LANGUAGES
ASIC chip development
Block 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
Define TLM test cases
SystemC/C++
Build TLM testbench
TLM integration
TLM simulation (run SW)
TLM simulation
Debug - Correct
Debug - Correct
RTL modeling
Build RTL testbench
RTL design rule check
ASIC realization
(by ASIC vendor)
VHDL
Formal property check
RTL integration
Define RTL test cases
SystemVerilog,
e
Build RTL testbench
RTL simulation
Debug - Correct
Verification management
RTL simulation
Debug - Correct
Verification management
Continued verification (simulation, formal)
Debug – Correct/work around
Build regression test suite
Several
deliveries
Connectivity check (formal)
Build emulation
Constraints (re-)definition
testbench
Logic synthesis
Design planning
Define emulation
DFT insertion
test cases
Verilog
≥3 rounds of
deliveries
Emulation (with SW)
Equivalence check
DFT implementation
Continued verification
(simulation, emulation)
Static timing analysis
Floorplanning
Gate level simulation
Place & Route
Debug – Correct/work
around
Debug – Correct (ECO)
Design rule check
Build regression
test suite
Prototype verification
Timing back-annotation
Parasitic extraction
Chip manufacturing
Debug – Work around
SoC & ASIC Design at Ericsson | © Ericsson AB 2014 | Page 79
© Ericsson AB 2014
38
SoC & ASIC Design at Ericsson
AFTER PROTOTYPE VERIFICATION
Design & verification
ASIC prototype verification
Board
Board verification
Subsystem SW
Subsystem verification
Other
subsystems
Design & verification
Design & verification
Design & verification
Design & verification
System
SW
Mechanics
System verification
Type approval
Sales & marketing
SoC & ASIC Design at Ericsson | © Ericsson AB 2014 | Page 80
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?
– Work at the #1 telecommunications company?
› Look for thesis works at www.ericsson.com/careers !
SoC & ASIC Design at Ericsson | © Ericsson AB 2014 | Page 81
© Ericsson AB 2014
39
SoC & ASIC Design at Ericsson
SoC & ASIC Design at Ericsson | © Ericsson AB 2014 | Page 83
© Ericsson AB 2014
40