Post on 14-Jan-2016
description
Design Verification for SoC 晶片系統之設計驗證
熊博安國立中正大學資訊工程學系嵌入式系統實驗室
hpa@computer.orghttp://www.cs.ccu.edu.tw/~pahsiung/
http://embedded.cs.ccu.edu.tw/
2
Contents SoC Verification Challenges Verification Methods
Simulation Technologies Static Technologies Formal Technologies Physical Verification and Analysis
SoC Verification Methodologies Case Studies
3
What is a System-on-Chip? An SoC contains:
Portable / reusable IP
Embedded CPU Embedded Memory Real World Interfac
es (USB, PCI, Ethernet)
Software (both on-chip and off)
Mixed-signal Blocks Programmable HW
(FPGAs) > 500K gates
Technology: 0.25um and below
Not an ASIC !
4
Challenges for System-on-Chip Industry
“ ... the industry is just beginning to fathom the scope of the challenges confronting those who integrate blocks of reusable IP on large chips. Most of the participants summed up the toughest challenge in one word: verification.”
Source: EE Times (Jan. 20, 1997)Report on Design Reuse and IP Core WorkshopOrganized by DARPA, EDA Industry Council,
NIST
5
System-on-Chip Verification Challenges Verification goals
functionality, timing, performance, power, physical
Design complexity MPUs, MCUs, DSPs, AMS IPs, ESW, cloc
k/power distribution, test structures, interface, telecom, multimedia
6
System-on-Chip Verification Challenges Diversity of blocks (IPs/Cores)
different vendors soft, firm, hard digital, analog, synchronous,
asynchronous different modeling and description
languages - C, Verilog, VHDL software, firmware, hardware
Different phases in system design flow
specification validation, algorithmic, architectural, hw/sw, full timing, prototype
7
Finding/fixing bugs costs in the verification process
Time to fix a bug
Block
Module
System
Design integration stage
• Increase in chip NREs make respins an unaffordable proposition• Average ASIC NRE ~$122,000• SoC NREs range from $300,000 to $1,000,000 NRE=non-recurring engineering
RESPIN
8
Challenges in DSM technology for SoC Timing Closure
Sensitive to interconnect delays
Large Capacity Hierarchical design and design reuse
Physical Properties Signal integrity
(crosstalk, IR drop, power/ground bounce) Design integrity
(electron migration, hot electron, wire self-heating)
9
Physical issues verification (DSM)
Interconnects Signal Integrity
P/G integrity Substrate coupling Crosstalk
Parasitic Extraction Reduced Order
Modeling Manufacturability and
Reliability Power Estimation
10
Physical issues verification (DSM)Interconnects
Scaling technology They get longer and longer Increasing complexity New materials for low resistivity
Inductance and capacitance become more relevant
Larger and larger impact on the design
Need to model them and include them in the design choices
(gate-centric to interconnect-centric paradigm)
11
Physical issues verification (DSM)P/G and Substrate
Analog and Digital blocks may share supply network and substrate
Can I just plug them together on the same chip? Will it work?
The switching activity of digital blocks injects noise current that may “kill” analog sensitive blocks
Digital IP
Analog
12
Physical issues verification (DSM)Crosstalk
In DSM technologies, coupling capacitance dominates interlayer capacitance
there is a “bridge” between interconnects on the same layer….they interfere with each other!
13
Physical issues verification (DSM)Parasitic Extraction
Parasitics play a major role in DSM technologies
Need to properly extract their value and model
14
Physical issues verification (DSM)Reduced Order Modeling
Increasing complexity bigger and more complex models E.g. supply grid, parasitics…
Need to find a “reduced” model so that Still good representation Manageable size
15
Physical issues verification (DSM)Manufacturability
Design a chip Send it to fabrication ……. Did I account for the fabrication
process variations? How many of my chips will work?
Just one? All? Most of them? How good is my chips performance?
Design and verification need to account for process variations!
16
Physical issues verification (DSM)Reliability
Design a chip Send it to fabrication ……. Did I test my design for
different kinds of stress? Is it going to work even
in the worst case? Can I sell it both in
Alaska and Louisiana?
17
Physical issues verification (DSM)Power Estimation
Advent of portable and high-density circuits power dissipation of VLSI circuits becomes a critical concern
Accurate and efficient power estimation techniques are required
18
Design Productivity Gap
Design Productivity
Gap
Gates / Chip
Gates / Hour
1990
1995
2000
19
SoC Design/Verification Gap
SimulatorPerformance
TestComplexity
VerificationGap
Design Complexity (FFs)
Sim
ula
tio
n P
erfo
rman
ce
Source: Cadence
System-on-Chip
20
Verification Methods
Simulation Technologies
Static Technologies
Formal Technologies
Physical Verification and Analysis
21
Simulation Technologies Event-driven Simulators Cycle-based Simulators Rapid Prototyping Systems Emulation Systems Speeding up Simulators (C, BFM, ISS,…) Testing & Coverage-driven Verification Assertion-based Verification HW/SW Cosimulation AMS Modeling and Simulation
22
Hardware Simulation Event-driven
compiled code native compiled code (directly producing optimized
object code) very slow+ asynchronous circuits, timing verification, initialize to known state
Cycle-based+ faster (3-10x than NCC) synchronous design, no timing
verification, cannot handle x,z states
CCoommb.b.
SSttaattee
SSttaattee
LLooggiicc
clockclock
23
Simulation: Perfomance vs Abstraction
.001x
SPICE
Event-drivenSimulator
Cycle-basedSimulator
1x 10xPerformance and Capacity
Abs
trac
tion
24
Validating System-on-Chip by Simulation Need for both cycle-based and event-driven
asynchronous interfaces verification of initialization verification of buses, timing
Need for mixed VHDL/Verilog simulators IP from various vendors models in different languages
SoC verification not possible by current simulation tools
Growing gap between amount of verification desired and amount that can be done
1 million times more simulation load than chip in 1990 (Synopsys)
25
AlgorithmSourceCode
ObjectCode
Firmware Design
Behavior RTL GATE
Hardware Design
In CircuitEmulator(ICE)
Integration Test
Rapid Prototyping Systems
26
Emulation Systems Emulation: Imitation of all or parts of the target system by
another system, the target system performance achieved primarily by hardware implementation
In-Circuit Emulator (ICE): A box of hardware that can emulate the processor in the target system. The ICE can execute code in the target system’s memory or a code that is downloaded to emulator.
ICE also can be fabricated as silicon within the processor-core: provides interface between a source level debugger and a processor embedded within an ASIC
Provides real-time emulation Supports functions such as breakpoint setting, single step execution,
trace display and performance analysis Provide C-source debugger Examples: EmbeddedICE macrocell in ARM SY7TDM1, NEC 850
family of processors, LSI Logic
27
Embedded ICE Macrocell
ARM7TDMI
EmbeddedICEMacrocell
Data Addr
Control
TAP
2
0
1
EmbedEmbeddededICEdICEMacrocellMacrocell
Data busData busscan chainscan chain
5 5 pin JTAGpin JTAGInterfaceInterface
TraditionalTraditionalboundary scanboundary scan
ARM CoreARM Core
Source: ARM
28
Embedded ICE in ARM7TDMI Core
Debug Host ARM
EmbeddedICE macrocell
ASIC
EmbeddedICE Interface
Source: ARM
29
Create by usingstandard LSI , FPGA
& G/A
IE-784000-RIN CIRCUIT EMULATOR
Target systemBread board for emulator
In-Circuit Emulator
Debugging environment for CPU core
Source: NECEL
30
Enhancing Simulation Speed Using Simulation Models
Hardware model Behavioral model in C Bus-functional model (BFM) Instruction-Set simulation (ISS)
model instruction accurate cycle accurate
Full-timing gate-level model encrypted to protect IP
31
Hardware Model
Use the actual physical device to model its own behavior during simulation
Advantages: accuracy, full device functionality, including any undocumented behavior
Disadvantages: delivers 1 to 10 instructions/sec, cost
Example Logic Modeling (Synopsys) Hardware Models
32
Behavioral Model Behavior of the core modeled in C Example: Memory models from Denali
30-70% of system chip area is memory => power, latency, area of chip
In typical simulation, conventional models consume as much as 90% of workstation memory
C models of DRAM, SRAM, Flash, PROM, SDRAM, EEPROM, FIFO
RAMBUS, Configurable Cache parameterizable models, common interface to all simulators allows adaptive dynamic allocation, memory specific
debugging
33
Bus Functional Model (BFM) Idea is to remove the application code and the target
processor from the hardware simulation environment Performance gains by using host processor’s capabilities instea
d of simulating same operation happening on target processor Varying degrees of use of host processor leads to different
models Bus functional model
only models the interface circuitry (bus), no internal functionality usually driven by commands: read, write, interrupt, … bus-transaction commands converted into a timed sequence of
signal transitions: fed as events to traditional hardware simulator Bus functional model emulates “transactions”:
Read/Write Cycles (single/burst transfers) Interrupts
34
Compiled Code Simulation
App codeCompile to
host processorBus functional
modelHardwareSimulator
I/Otransactions
BusEvents
Host code not equal to Target code Low-level debugging not possible
E.g. observing processor internal registers
Measurements may be inaccurate E.g. cycle counts
35
Instruction Set Simulation (ISS)
Full functional accuracy of the processor as viewed from pins Operations of CPU modeled at the register/instruction level
registers as program variables instructions as program functions which operate on register values
Data path that connects the registers are abstracted out Allows both high-level and assembly code to be debugged Instruction Accurate
accurate at instruction boundaries only correct bus operations, and total number of cycles, but no
guarantee of state of CPU at each clock cycle; inaccuracy due to bus contention
Cycle Accurate guarantees the state of the CPU at every clock cycle guarantees exact bus behavior slower than instruction-accurate, but faster than full behavioral
model Source: LSI Logic, Mentor Graphics
36
ISS Example Example Example SimulatorSimulator: Microtec XRAY Sim™: Microtec XRAY Sim™ Fast: 100,000 instructions/sec Software debug: source code
debugging, register and memory views
Source-level debugRegister view Memory view
37
NEC provides the following simulation models:
Behavioral C model: used in early design stage, for functional verification, fastest execution
RTL model with timing wrapper: for accurate timing and function verification
Verilog gate-level model: for final design verification, very slow
V851in
C - Model
Timing Wrapper
Verilog Interface
RAM
ROM
Soft ICE(for emulation & debugging)
Verilog
UserLogic
Example of Simulation Models
38
Testing Verification environment
Commonly referred as testbench Definition of a testbench
A verification environment containing a set of components [such as bus functional models (BFMs), bus monitors, memory modules] and the interconnect of such components with the design under-verification (DUV)
Verification (test) suites (stimuli, patterns, vectors) Test signals and the expected response under gi
ven testbenches
39
Testbench Design Auto or semi-auto stimulus generator is pre
ferred Automatic response checking is highly rec
ommended May be designed with the following techniq
ues Testbench in HDL Testbench in programming language interface
(PLI) Waveform-based Transaction-based Specification-based
40
Types of Verification Tests Random testing
Try to create scenarios that engineers do not anticipate
Functional testing User-provided functional patterns
Compliances testing Corner case testing Real code testing (application SW)
Avoid misunderstanding the specification
41
Types of Verification Tests Regression testing
Ensure that fixing a bug will not introduce other bugs
Regression test system should be automated
Add new tests Check results and generate report Distribute simulation over multiple
computer Time-consuming process when
verification suites become large
42
Coverage-driven Verification Coverage reports can indicate how much of
the design has been exercised Point out what areas need additional
verification Optimize regression suite runs
Redundancy removal (to minimize the test suites)
Minimizes the use of simulation resources Quantitative sign-off (the end of verification
process) criterion Verify more but simulate less
43
The rate of bug detection
source : “Verification Methodology Manual For Code Coverage In HDL Designs” by Dempster and Stuart
bugs
44
Coverage Analysis Dedicated tools are required besides the simulator Several commercial tools for measuring Verilog and
VHDL code coverage are available VCS (Synopsys) NC-Sim (Cadence) Verification navigator (TransEDA)
Basic idea is to monitor the actions during simulation
Require supports from the simulator PLI (programming language interface) VCD (value change dump) files
45
Analysis Results
Verification Navigator (TransEDA)
Untested code line will be highlighted
46
Assertion-Based Verification Assertion-based verification (ABV) solutions are gai
ning in popularity Assertions are statements of designer assumptions or des
ign intent Assertions should be inherently reusable
These supplement, not replace, traditional simulation tests
Design and verification engineer knowledge is leveraged Both design observability and design controllability can b
e improved Assertions enable formal verification
47
Assertions Assertions can capture interface and bus rules
In ABV, protocol monitors are written using assertions Each individual protocol rule is captured by an assertion,
usually temporal (multi-cycle) in nature Example: Signal A should assert between 3 and 5 cycles af
ter signal B, but only if signal C is deasserted Internal assertions capture design intent
Example: this FIFO should never receive a write when it is already full
Example: this state machine variable should always be encoded as one-hot
These improve observability in simulation but still rely on tests for stimulus
48
Assertion Checkers Checkers check the assertion conditions
Checker “fire” on indications of bugs (e.g., FIFO write when full)
Improve observability but still rely on tests for stimulus Certain types of checkers can be inferred directly fr
om the RTL code Example: Arithmetic overflow on a computation Example: Proper synchronization across an asynchronous
clock domain boundary The most valuable assertion checkers come from i
nformation in the designer’s head It must be easy to capture assertions
49
Assertion CaptureCheckers can be written in many ways
In a testbench language (C, C++, e, Vera, etc.) Directly in RTL (Verilog or VHDL) With RTL assertion constructs (VHDL, SystemVerilog) Using assertion libraries (OVL) In a formal property language (PSL, Sugar, ForSpec, etc.) Embedded in RTL with pseudo-comments (used by
0-In and several other EDA vendors) Assertion capture should be as easy as possible
Designers don’t want to learn a new language Assertion checker libraries provide a lot of leverage
50
Complete ABV Flow
AutomaticRTL Checks
AssertionCompiler
Standard VerilogSimulator
Standard VerilogSimulator
CoverageReports
CoverageReportsTestbenchTestbench
AssertionLibrary
AssertionLibrary
RTL DesignRTL Design
Assertions
Simulation
FormalVerification
Static FormalVerification
Dynamic FormalVerification
Formal ModelCompiler
FormalMetrics
FormalMetrics
51
testtest
testtest
testtest
testtest
testtest
testtest
Directed Tests
IP Verification with Checkers
Use checkers during interface IP creation Saturate RTL code with checkers Use checkers on interfaces as trip-wires Report illegal inputs and scenarios not handled
Deliver IP with assertion checkers included
Application Interface
checker
Verification Environment
IP
testtest
testtest
testtest
testtest
testtest
testtest
Directed Tests
Standard Interface
52
testtest
testtest
testtest
testtest
System Regression
custominterface
logic
decode
RAM
ctl1
CPU
on-chip bus
IP
checker
SoC Integration with Checkers
Checkers accelerate SoC integration Ensure that standard protocol is never violated Detect illegal inputs or invalid assumptions by user Improve observability in SoC simulation Speed up bug discovery and diagnosis
StandardInterconnect
53
Hardware-Software Co-Simulation
Most of the bus cycles are Instruction or Data fetches
• High Activity
• 700-1000 instructions for each I/O bus cycle
• Low Activity
• Only during processor I/O cycles
ProcessorModel
HardwareHigh Processor
Model &Memory
HardwareLow
OnlyI/O
cycles
54
Hardware-Software Co-Simulation: Implementation
ApplicationProgram
(Assembly)
ISSProcessor
model
Hostmemory
Busfunctional
model
Memorymodel
HDL model
Memory & SignalSynchronization
55
Seamless CVE™: Comprehensive System Wide Analysis & Debug
Logic SimulatorXRAY™ Sim Seamless CVE™
Memory ImageServer
Synchronization& Optimization
Source: Mentor Graphics
56
Analog Behavior Modeling A mathematical model written in Hardware
Description Language Emulate circuit block functionality by sensi
ng and responding to circuit conditions Available Analog/Mixed-Signal HDL:
Verilog-A VHDL-A Verilog-AMS VHDL-AMS
57
Mixed Signal Simulation
58
Static Technologies
Inspection and Lint Checking Static Timing Analysis
59
Inspection & Lint Checking For designers, finding bugs by careful inspe
ction is often faster than that by simulation Inspection process
Design (specification, architecture) review Code (implementation) review
Line-by-line fashion At the sub-block level
Lint-liked tools can help spot defects without simulation Nova ExploreRTL, VN-Check, ProVerilog, …
60
HDL Linter Fast static RTL code checker
Preprocessor of the synthesizer RTL purification (RTL DRC)
Syntax, semantics, simulation Check for built-in or user-specified rules
Testability checks Reusability checks ……
Shorten design cycle Avoid error code that increases design iterations
61
Static Timing Analysis (STA) STA is a method for determining if a circuit meets ti
ming constraints (setup, hold, delay) without having to simulate
No input patterns are required 100% coverage if applicable
Challenging: multiple sources
Reference :Synopsys
62
Formal Technologies
Formal Verification: An analytic way of proving a system correct no simulation triggers, stimuli, inputs no test-benches, test-vectors, test-cases
Deductive Reasoning (theorem proving)
Model Checking Equivalence Checking
Formal Verification Methods
63
Theorem Proving
Uses axioms, rules to prove system correctness
No guarantee that it will terminate
Difficult, time consuming: for critical applications only
Not fully automatic
64
Model Checking
Automatic technique to prove correctness of concurrent systems: Digital circuits Communication protocols Real-time systems Embedded systems Control-oriented systems
Explicit algorithms for verification
65
Equivalence Checking
Checks if two circuits are equivalent Register-Transfer Level (RTL) Gate Level
Reports differences between the two Used after:
clock tree synthesis scan chain insertion manual modifications
66
Why Formal Verification? Simulation and test cannot handle all
possible cases (only some possible ones) Simulation and test can prove the
presence of bugs, rather than their absence
Formal verification conducts exhaustive exploration of all possible behaviors If verified correct, all behaviors are verified If verified incorrect, a counter-example
(proof) is presented
67
Why Formal Verification Now?
SoC has a high system complexity Simulation and test are taking
unacceptable amounts of time More time and efforts devoted to
verification (40% ~ 70%) than design Need automated verification methods
for integration into design process
68
Increased Simulation Loads
69
Why Formal Verification Now?
Examples of undetected errors Ariane 5 rocket explosion, 1996
Exception occurred when converting 64-bit floating number to a 16-bit integer!
Pentium FDIV bug Multiplier table not fully verified!
70
71
Verification Tasks for SoC
72
Property Checking v/s Equivalence Checking
73
Model (Property) Checking
Algorithmic method of verifying correctness
of (finite state) concurrent systems
against temporal logic specifications
A practical approach to formal verification
74
Model Checking
What is necessary for Model Checking?
A mathematically precise model of the system
A language to state system properties
A method to check if the system satisfies the given properties
75
Formal Verification Issues State-space explosion!!! Cannot handle large systems!
For control-oriented behavior of small modules
For interface-centric verification Constrained for feasible verification
Supplementary to simulation Counterexample simulation trace
76
Physical Verification & AnalysisIssues for physical verification: Timing Signal Integrity Crosstalk IR drop Electro-migration Power analysis Process antenna effects Phase shift mask Optical proximity correction
77
Comparing Verification Options
78
Comparing HW/SW Coverification Options
79
Which is the fastest option? Event-based simulation
Best for asynchronous small designs Cycle-based simulation
Best for medium-sized designs Formal verification
Best for control-oriented designs Emulation
Best for large capacity designs Rapid Prototype
Best for software development
80
SoC Verification Methodology
System-Level Verification SoC Hardware RTL Verification SoC Software Verification Netlist Verification Physical Verification Device Test
81
SoC Verification Methodology
82
Verification Approaches
Top-Down Verification
Bottom-Up Verification
Platform-Based Verification
System Interface-Driven Verification
83
Top-Down SoC Verificationverifi
catio
n
84
Bottom-Up SoC Verification
verifi
catio
n
Components, blocks, units
Memory map, internal interconnectBasic functionality, external interconnectSystem level
85
Platform-Based SoC Verification
Derivative Design
Interconnect Verification between:
SoC Platform Newly added I
Ps
86
System Interface-driven SoC Verification
Besides Design-Under-Test, all others are interface
models
87
ALGORITHMICCO-VALIDATION
CoresMPU, MCU,DSP
DFT & TESTGENERATION
DFT & TESTGENERATION
CPUCORE
ROM/RAM Periph. PCI/
MPEG
SYSTEM SPEC
HARDCORES
SOFTCORES
S/WTASKSCPU
TASKSONUDL
MAPPING / PARTITIONING
S/W IMPLEMENTATION
H/WSYNTHESIS
PROTOTYPEVERIFICATION
UDL FULLTIMINGMODELS
FULLTIMING
VERIFICATION
CYCLE BASED
- ISS- HDL
ARCHITECTURALCO-VALIDATION
C-MODELS,HDL-MODELS
ESTIMATORS- TIMING- POWER
ASICINTEGRATION
BUSARCHITECTURE
ASIC PROTOTYPE
PeripheralsInterfaceMultimediaTelecom/Networking
Co-proc.
VALIDATION
System-on-Chip Design and Validation Flow
88
DebuggerEmulator
Instruction SetSimulator
Co-Simulator
Embedded Software Implementation and Validation
Software Tasks
Software Implementation
Mapping tasks to CPUs
Multitask Scheduling - Priority selection
Multiprocessor Integration - Protocols - Shared Memory
CompilerAssembler
Linker
RTOS
Estimators - Performance - Power
H /W
89
Verification of Cores in High Level Design Flow
Compiler ScheduledVHDL
HardwareSharing
Delay / Power/ Testability
Estimators
RT-Level(contr + DP)
RT-LevelOptimization
OptimizedRTL
Functional RTL Structural RTL
VHDLSpecs.
Behavioral
Mapping,PhysicalSynthesis
CFGDFG
Scheduler(cycle-by-cycle
behavior)
user constraints:
resource, performance, etc.
Test BenchGeneration
Verification - using Test Bench - Formal
90
Peripheral
Ext AccessExt Access(Test)(Test)
High SpeedHigh Speed Low powerLow power
Peripheral
Peripheral
ExternalExternalBusBus
InterfaceInterfaceBridgeBridge
CPUCPU
ROMROMRAMRAM
DMADMA
PeripheralPeripheral
AAHHBB APBAPB
Integration of Cores: Verification of Interfaces
Source: ARM
AMBA: Advanced Microprocessor Bus ArchitectureAMBA: Advanced Microprocessor Bus Architecture
91
Device Test
To check if devices are manufactured defect-free
Focus on structure of chip Wire connections Gate truth tables Not functionality
92
Device Test
Challenges in SoC device test: Test Vectors: Enormous! Core Forms: soft, firm, hard, diff tests Cores: logic, mem, AMS, … Accessibility: very difficult / expensive!
93
Device Test Strategies Logic BIST (Built-In-Self-Test)
Stimulus generators embedded Response verifiers embedded
Memory BIST On-chip address generator Data generator Read/write controller (mem test algorithm)
Mixed-Signal BIST For AMS cores: ADC, DAC, PLL
Scan Chain Timing and Structural compliance ATPG tools generate manufacturing tests automatically
IEEE P1500 SECT (next time!)
94
Case Studies
ALCATEL Image Compression System “Designing an Image Compression Syste
m for a Space Application, Using an IP Based Approach,” Jean Marie Garigue, Emmanuel Liegeon, Sophie Di Santo, Louis Baguena, IP Based Design Conference, 2000.
VisorVoice Product
95
ALCATEL Image Compression System Design and implement an image
compression subsystem for an observation satellite
Observation Satellite Payload Image sensors Image compression system Storage (solid state recorder) Transmitter
96
Top Level Requirements Accept image data from the space craft
image acquisition unit Compress the image data Send compressed data to the image
transmission system or on board compressed image storage system
Develop a complete solution compact enough to be integrated with the Solid State Recorder Requires an SoC implementation of the
compression system
97
Refined Requirements Accept rough digital video data from
the sensors through serial transceivers Compress the image with a rate
ranging from 1.2 to 40 Use a JPEG based compression
algorithm Optimize the image quality Transmit the data to the solid state
recorder and transmitter at a fixed but programmable rate
98
Specifications 8 video channels 10 bits/pixel Input: 25 Mpixels/sec – on a serial interface Video line size: up to 16k pixels Output: 25 Mbytes/sec maximum Temperature range: -55°C +125°C Space environment: total dose –10k rad, SEU - Singl
e Event Upset – changing content of FF’s or memory
Power budget: 6W/channel Size/weight: to be minimized
99
Constraints
Must meet European Space Agency standards
Must meet ALCATEL standards Time constraint: final product in 18
months Cost constraint: fixed amount not
to be exceeded
100
Input Interface Unit Serial Data Link
25 Mpixels/sec hardware implementation
Requires conversion from analog to CMOS signals and reformatting
Analog mixed signal block implementation Decision
Implement only the data rearrangement subsystem on the chip
101
DCT Unit
DCT Calculation Converts a waveform (input pixels of a block) into its fre
quency components Weighting operation allows different quantification factor
s for each of the DCT coefficients 25 Mpixels/sec
hardware implementation
102
Huffman Unit
Quantification Calculation requires a complex series of operation
s software implementation Run length encode DCT coefficients Huffman encoding - table lookup Packing
25 Mpixels/sec rate hardware implementation
103
Regulation Unit
Principal - Alcatel patented algorithm Status of the regulation buffer is monitored Quantification factor is calculated as a comp
lex function of the level of the buffer and the distribution of the DCT coefficients
The distribution is obtained by constructing a histogram of the coefficients
25 Mpixel Rate hardware implementation
104
SoC System Architecture
105
Initial Design
At time of initial design required using 0.5 µm technology and special design techniques The system could not be implemented as
a SoC – a multichip version was implemented
106
Initial System
107
SOC Design
After 0.35 µm was rated, an SoC version was implemented Example of value of internal IP reuse
108
SoC Verification Methodology Step One
Complete system was modeled in ‘C’ Algorithms were “tuned”
Compression – to include the quantification factor Regulation – to be based on a patented ALCATEL
algorithm System performance was checked using a set of
“reference” images Enabled system designers to gain
concurrence of the “customer” on a set of reference images
109
SoC Verification Methodology - continued
Step 2 Each function checked against the
corresponding intermediate results of the ‘C’ model
Step 3 Complete system was checked
against the ‘C’ model
110
System Verification Alternatives
Simulation Emulation FPGA prototypes
111
Verification Individual functions were simulated Simulation of entire system to proces
s an image (6 Mpixels) – estimate: 1000 hours Hence, an alternate emulation based app
roach was adopted Based on a CELARO machine
Can emulate 4M gates - enabled the complete SoC to be mapped into the emulator
112
Emulation SoC was mapped after synthesis
ALCATEL developed a translation of the ASIC library to the CELARO library
Enabled checking not only behavior but also physical implementation after synthesis
Behavioral VHDL models of the memories and microcontroller (DSP) were implemented in the workstation
113
Emulation Result
Emulation enabled fast system gate level verification 1 hour 40 minutes for processing 6M Pixel
s by a 1.1M gate chip at the gate level vs. 1000 hours of simulation time
114
VisorVoice - Informal ProductDescription
115
VisorVoice A device that lets us:
Record digital messages Replay the messages Download / upload the
messages to and from a desktop computer
Interoperates with a handheld PDA
116
VisorVoice Functionality What does the VisorVoice need to do?
Record a message Play previously recorded message Delete a message Inserts into Visor Expansion slot Hot-Sync with PC
117
VisorVoice Performance Record a meeting,
record notes A typical meeting: 6
0 - 120 minutes Recording notes: 2
minutes each, 60 maximum
Speech quality: has to be good enough
118
VisorVoice Performance Battery operated, p
ortable Battery has to last a
minimum of 120 minutes
May want longer battery life to permit playing back messages
When battery fails, the messages should not be lost
119
Can We Do It for $50?
VisorVoice target price: $50 Medium volume Performance is moderate (speech recordi
ng) Complexity is low
Canonical SoC + speech input/output + Visor interface
120
VisorVoice Requirements
121
VisorVoice Functional States What states can VisorVoice be in?
Powered off Stopped - not doing anything (play or record) Playing - playback of voice recordings Recording - capturing a new recording Paused – playback/recording temporarily stoppe
d Volume adjust - changing volume up/down Equalizer - changing settings Message Management, Seek - save, restore, delete,
and find messages
122
VisorVoice Functional Diagram
123
VisorVoice User Interface
124
Play/Record Input Controls Icon buttons – no value settings
Play – Starts playback of selected message Record – Creates new message with default
name and starts recording Pause – Stops playback or record operation
and holds position Step back – Moves playback selection
backward to previous start of message Step forward – Moves playback selection
forward to next start of message
125
Functional Architecture
126
IP Selection GUI
Custom software to be designed and implemented to run on the Visor
PalmOS Development toolsets available (commercial & open source)
Springboard Functions provided in a library by Handspring
RISC Processor Chose the ARM7TDMI processor core
Available from ARM Ltd ISP and VHDL models available
127
IP Selection
AMBA Bus Also available from ARM Ltd
AMBA Development Kit VHDL models of components included
Visor Interface Custom interface to be designed as part
of the SoC implementation VHDL model developed
128
IP Selection A/D, D/A, Amplifiers, etc.
IP search resulted in a single IP block solution from Chipidea
A 14 bit codec Only model available was in a proprietary langua
ge Developed MatLab and VHDL models
VisorVoice Codec ChipIdea voice codec CI7075oa includes:
14-bit linear A-to-D and D-to-A conversion Decimation and interpolation filtering Microphone and speaker interfacing that works with th
e Visor’s microphone and module-mounted speaker
129
IP Selection Compression/Decompression Function
IP search revealed public domain software IP available
Used G.726 ADPCM (ITU Standard) 16 Kbps encoding (32:1 ratio)
Decision – implement these functions in software on the ARM processor.
Equalization Filter Design Decision – implemented as a programm
able hardware FIR filter with coefficients downloaded by the ARM as a function of the band settings set by the user via the Visor GUI
130
Additional Design Decisions
The CODEC and the Visor interface requirements were relatively low speed, hence the decision to interface these units to the Advanced Peripheral Bus (APB)
Required APB-to-AHB bridge provided by ARM
131
VisorVoice Architecture
132
Design Platform Four Models on a common platform
“C”-level Behavioral Model Software Development Model Hardware Development Model Co-Verification model
Common Platform (Mentor tools) Seamless – Coverification Modelsim – Hardware X-Ray – host processor software C-Bridge – behavior C-language Model
133
Behavioral/Algorithmic Model
134
Requirements & Results Requirements C models
Gen.c, Show.c: generate/save pcm code file words
control.c : Emulates visor interface from x-ray window
decfilt.c, fir.c: Compression/Decompression mem.c: Store and receive compressed data
Results Verified performance of operation flows C models of system components to use in softwar
e development environment
135
Software Development Model
136
Requirements & Results
Requirements C-languange Models for IP blocks Host Software IP ARM7TDMI simulation model
Results Tested VisorVoice/ARM host software
137
HW Development Model
138
Requirements & Results
Requirements VHDL models for hardware blocks Test Generator software
Results Tested Hardware IP blocks for VisorVoice
139
Cosimulation Model
140
Requirements & Results
Requirements C models for ARM software VHDL models for hardware blocks
Results Verified VisorVoice system level design
141
References System-on-a-Chip Verificat
ion Methodology and TechniquesPrakash Rashinkar, Peter Paterson, Leena Singh,Kluwer Academic Publishers, 2001
Prof. Chien-Nan Liu’s slides on SoC Verification, NCU, Taiwan