Design Verification for SoC ????????? - PowerPoint PPT Presentation

Loading...

PPT – Design Verification for SoC ????????? PowerPoint presentation | free to download - id: 6bb904-ZDBlO



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Design Verification for SoC ?????????

Description:

Design Verification for SoC hpa_at_computer.org http://www.cs.ccu.edu ... – PowerPoint PPT presentation

Number of Views:37
Avg rating:3.0/5.0
Slides: 142
Provided by: PaoAnn8
Learn more at: http://www.cs.ccu.edu.tw
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Design Verification for SoC ?????????


1
Design Verification for SoC ?????????
  • ??? ???????????? ????????
  • hpa_at_computer.org http//www.cs.ccu.edu.tw/pahsiun
    g/ 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 Interfaces (USB, PCI, Ethernet)
  • Software (both on-chip and off)
  • Mixed-signal Blocks
  • Programmable HW (FPGAs)
  • gt 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 Workshop
  • Organized 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, clock/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
System
Time to fix a bug
Module
Block
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 NREnon-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) Manufacturabili
ty
  • 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
Gates / Chip
Design Productivity Gap
Gates / Hour
1990
1995
2000
19
SoC Design/Verification Gap
System-on-Chip
Test Complexity
Simulation Performance
Simulator Performance
Verification Gap
Design Complexity (FFs)
Source Cadence
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

clock
23
Simulation Perfomance vs Abstraction
Cycle-based Simulator
Event-driven Simulator
Abstraction
SPICE
Performance and Capacity
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
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 systems
    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
2
EmbeddedICE Macrocell
EmbeddedICE Macrocell
ARM Core
0
ARM7TDMI
Control
1
Data
Addr
Traditional boundary scan
Data bus scan chain
TAP
5 pin JTAG Interface
Source ARM
28
Embedded ICE in ARM7TDMI Core
EmbeddedICE Interface
ASIC
EmbeddedICE macrocell
Debug Host
ARM
Source ARM
29
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 gt 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 processors
    capabilities instead 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
  • 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 Simulator Microtec XRAY Sim
  • Fast 100,000 instructions/sec
  • Software debug source code debugging, register
    and memory views

37
Example of Simulation Models
  • 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

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
    given testbenches

39
Testbench Design
  • Auto or semi-auto stimulus generator is preferred
  • Automatic response checking is highly recommended
  • May be designed with the following techniques
  • 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
bugs
  • source Verification Methodology Manual For
    Code Coverage In HDL Designs by Dempster and
    Stuart

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
    gaining in popularity
  • Assertions are statements of designer assumptions
    or design 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 be 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 after 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 from 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
    information in the designers head
  • It must be easy to capture assertions

49
Assertion Capture
  • Checkers 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 dont want to learn a new language
  • Assertion checker libraries provide a lot of
    leverage

50
Complete ABV Flow
Automatic RTL Checks
RTL Design
Assertions
Assertion Library
Assertion Compiler
Testbench
Standard Verilog Simulator
Coverage Reports
Simulation
Formal Model Compiler
Formal Verification
Formal Metrics
Static Formal Verification
Dynamic Formal Verification
51
IP Verification with Checkers
test
test
test
test
test
test
checker
test
test
test
test
test
test
Directed Tests
Directed Tests
Verification Environment
Standard Interface
Application Interface
  • 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

52
SoC Integration with Checkers
custom interface logic
IP
Standard Interconnect
on-chip bus
ctl1
CPU
RAM
System Regression
checker
  • 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

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

54
Hardware-Software Co-Simulation Implementation
55
Seamless CVE Comprehensive System Wide Analysis
Debug
Source Mentor Graphics
56
Analog Behavior Modeling
  • A mathematical model written in Hardware
    Description Language
  • Emulate circuit block functionality by sensing
    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 inspection
    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 timing 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
(No Transcript)
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 Analysis
  • Issues 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 Verification
verification
84
Bottom-Up SoC Verification
verification
Components, blocks, units
Memory map, internal interconnect
Basic functionality, external interconnect
System level
85
Platform-Based SoC Verification
Derivative Design
  • Interconnect Verification between
  • SoC Platform
  • Newly added IPs

86
System Interface-driven SoC Verification
Besides Design-Under-Test, all others are
interface models
87
System-on-Chip Design and Validation Flow
88
Embedded Software Implementation and Validation
Software Tasks
Estimators - Performance - Power
Instruction Set Simulator
Mapping tasks to CPUs
Compiler Assembler Linker
Multitask Scheduling - Priority selection
Co-Simulator
H /W
Multiprocessor Integration - Protocols -
Shared Memory
Debugger Emulator
RTOS
Software Implementation
89
Verification of Cores in High Level Design Flow
user constraints
resource, performance, etc.
Functional RTL
Structural RTL
Behavioral
Hardware Sharing Delay / Power/ Testability
RT
-Level
VHDL Specs.
CFG DFG
Scheduler (cycle-by-cycle behavior)
Compiler
Scheduled VHDL
(contr DP)
RT-Level Optimization
Test Bench Generation
Estimators
Mapping, Physical Synthesis
Verification - using Test Bench - Formal
90
Integration of Cores Verification of Interfaces


CPU
DMA
Peripheral
Peripheral
External Bus Interface
AHB
APB
Bridge


ROM RAM
Peripheral
Peripheral
Ext Access (Test)
High Speed
Low power
Source ARM
AMBA 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 System 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 -55C 125C
  • Space environment total dose 10k rad, SEU -
    Single Event Upset changing content of FFs 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 frequency components
  • Weighting operation allows different
    quantification factors for each of the DCT
    coefficients
  • 25 Mpixels/sec ?
  • hardware implementation

102
Huffman Unit
  • Quantification
  • Calculation requires a complex series of
    operations ?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 complex
    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 process an image
    (6 Mpixels) estimate 1000 hours
  • Hence, an alternate emulation based approach 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 Pixels by a
    1.1M gate chip at the gate level vs. 1000 hours
    of simulation time

114
VisorVoice - Informal Product Description
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 60 - 120 minutes
  • Recording notes 2 minutes each, 60 maximum
  • Speech quality has to be good enough

118
VisorVoice Performance
  • Battery operated, portable
  • 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 recording)
  • 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 stopped
  • 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
    language
  • 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 the Visors 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 (321 ratio)
  • Decision implement these functions in software
    on the ARM processor.
  • Equalization Filter
  • Design Decision implemented as a programmable
    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 software
    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 Verification Methodology and
    Techniques
  • Prakash Rashinkar, Peter Paterson, Leena Singh,
  • Kluwer Academic Publishers, 2001
  • Prof. Chien-Nan Lius slides on SoC Verification,
    NCU, Taiwan
About PowerShow.com