soc & asic design at ericsson - idatdts01/lectures/10/lec10.pdf · soc & asic design at...

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


Ericsson AB 2010 2


Mobile networks and HW infrastructure


A mobile network

LTE

RAN

GSM, WCDMA, LTE Radio Base Stations


Ericsson AB 2010 3


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


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


Ericsson AB 2010 4


Systemizationand

System design


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


Ericsson AB 2010 5


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


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


Ericsson AB 2010 6


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


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)


Ericsson AB 2010 7


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


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


Ericsson AB 2010 8


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)


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


Ericsson AB 2010 9


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)!


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


Ericsson AB 2010 10


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)


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


Ericsson AB 2010 11


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


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


Ericsson AB 2010 12


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


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– ...


Ericsson AB 2010 13


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


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)


Ericsson AB 2010 14


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


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!

?


Ericsson AB 2010 15


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


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


Ericsson AB 2010 16


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


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


Ericsson AB 2010 17


SoC/ASIC design flow


From idea ⇒ component ...

EROP1011503 ROP1011503

R1AR1A


Ericsson AB 2010 18


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?


Main steps

Technology study

Structuring

HW modeling & design

ASIC technology mapping

ASIC prototype manufacturing

ASIC prototype verification

SW modeling & design

SW implementation

SW verification


Ericsson AB 2010 19


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!


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


Ericsson AB 2010 20


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


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


Ericsson AB 2010 21


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


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


Ericsson AB 2010 22


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)


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


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


Ericsson AB 2010 23


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


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


Ericsson AB 2010 24


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


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


Ericsson AB 2010 25


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


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


Ericsson AB 2010 26


Functional coverage

� Coverage presentation example (Specman Elite):


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


Ericsson AB 2010 27


Functional verification methods

� Basic methods:– Directed tests

– Constrained Random Testing

– Coverage Driven Verification

– Assertion Based Verification


Functional verificationDirected tests

Directed tests- Create tests manually- Cover as much as possibleof test space

Test spaceTest space


Ericsson AB 2010 28



Functional verificationConstrained Random Testing

Constrained Random Testing- Create tests automatically from starting points




Functional verificationCoverage Driven Verification

Coverage Driven Verification- Perform repeated Constrained Random Testing runs to reach functional coverage goals






Ericsson AB 2010 29


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



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


Ericsson AB 2010 30


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


HW/SW co-verificationExample

� Typical signal processing architecture:

ASIC

CPUDSP DSP DSP

Logic & RAM

EPROM

DSP SW Control SW


Ericsson AB 2010 31



SWHW

ASIC HW

Test DSP SW

ModelSim

ASIC integration

DSP SW

host environment

DSP SWverification

Emulator


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


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


Ericsson AB 2010 32


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


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


Ericsson AB 2010 33


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


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


Ericsson AB 2010 34


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?


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


Ericsson AB 2010 35



� 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


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






Ericsson AB 2010 36


Design challengesfor SoCs


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


Ericsson AB 2010 37


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


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


Ericsson AB 2010 38


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


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


Ericsson AB 2010 39


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?


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)


Ericsson AB 2010 40


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)


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...)


Ericsson AB 2010 41


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 !


soc & asic design at ericsson - idatdts01/lectures/10/lec10.pdf · soc & asic design at...

Documents