Design Verification for SoC 晶片系統之設計驗證

Design Verification for SoC 晶片系統之設計驗證
熊博安國立中正大學資訊工程學系嵌入式系統實驗室

Contents SoC Verification Challenges Verification Methods
Simulation Technologies Static Technologies Formal Technologies Physical Verification and Analysis SoC Verification Methodologies Case Studies

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) > 500K gates Technology: 0.25um and below Not an ASIC !

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

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

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

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 NRE=non-recurring engineering RESPIN

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)

Physical issues verification (DSM)
Interconnects Signal Integrity P/G integrity Substrate coupling Crosstalk Parasitic Extraction Reduced Order Modeling Manufacturability and Reliability Power Estimation

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)

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

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!

Physical issues verification (DSM) Parasitic Extraction
Parasitics play a major role in DSM technologies Need to properly extract their value and model

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

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!

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?

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

Design Productivity Gap
Gates / Chip Design Productivity Gap Gates / Hour 1990 1995 2000

SoC Design/Verification Gap
System-on-Chip Test Complexity Simulation Performance Simulator Performance Verification Gap Design Complexity (FFs) Source: Cadence

Verification Methods Simulation Technologies Static Technologies
Formal Technologies Physical Verification and Analysis

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

Hardware Simulation Event-driven  very slow
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 C o m b. S t a e L g i c clock

Simulation: Perfomance vs Abstraction
Cycle-based Simulator Event-driven Simulator Abstraction SPICE .001x 1x 10x Performance and Capacity

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)

Rapid Prototyping Systems
Algorithm Source Code Object Firmware Design Behavior RTL GATE Hardware Design In Circuit Emulator(ICE) Integration Test

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

Embedded ICE Macrocell
2 EmbeddedICE Macrocell EmbeddedICE Macrocell ARM Core ARM7TDMI Control 1 Data Addr Traditional boundary scan Data bus scan chain TAP 5 pin JTAG Interface Source: ARM

Embedded ICE in ARM7TDMI Core
EmbeddedICE Interface ASIC EmbeddedICE macrocell Debug Host ARM Source: ARM

Debugging environment for CPU core
Create by using standard LSI , FPGA & G/A Target system Bread board for emulator In-Circuit Emulator Source: NECEL

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

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

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

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

Compiled Code Simulation
App code Compile to host processor Bus functional model Hardware Simulator I/O transactions Bus Events 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

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

ISS Example Example Simulator: Microtec XRAY Sim™
Fast: 100,000 instructions/sec Software debug: source code debugging, register and memory views Source-level debug Register view Memory view

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 V851 in C - Model Timing Wrapper Verilog Interface RAM ROM Soft ICE (for emulation & debugging) Verilog User Logic

Testing Verification environment Definition of a testbench
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

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

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

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

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

The rate of bug detection
bugs source : “Verification Methodology Manual For Code Coverage In HDL Designs” by Dempster and Stuart

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

Untested code line will be highlighted
Analysis Results Verification Navigator (TransEDA) Untested code line will be highlighted

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

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

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 designer’s head It must be easy to capture assertions

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 don’t want to learn a new language Assertion checker libraries provide a lot of leverage

Complete ABV Flow Assertions Simulation Formal Verification RTL Design
Automatic RTL Checks 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

IP Verification with Checkers
test IP 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

SoC Integration with Checkers
IP custom interface logic decode test 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

Hardware-Software Co-Simulation
Processor Model Hardware High Model & Memory Low Only I/O cycles Most of the bus cycles are Instruction or Data fetches High Activity instructions for each I/O bus cycle Low Activity Only during processor I/O cycles

Hardware-Software Co-Simulation: Implementation
Application Program (Assembly) ISS Processor model Host memory Bus functional Memory HDL model Memory & Signal Synchronization

Seamless CVE™: Comprehensive System Wide Analysis & Debug
Logic Simulator XRAY™ Sim Seamless CVE™ Memory Image Server Synchronization & Optimization Source: Mentor Graphics

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

Mixed Signal Simulation

Static Technologies Inspection and Lint Checking
Static Timing Analysis

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, …

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

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

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

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

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

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

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

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

Increased Simulation Loads

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!

Verification Tasks for SoC

Property Checking v/s Equivalence Checking

Model (Property) Checking
Algorithmic method of verifying correctness of (finite state) concurrent systems against temporal logic specifications A practical approach to formal verification

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

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

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

Comparing Verification Options

Comparing HW/SW Coverification Options

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

SoC Verification Methodology
System-Level Verification SoC Hardware RTL Verification SoC Software Verification Netlist Verification Physical Verification Device Test

Verification Approaches
Top-Down Verification Bottom-Up Verification Platform-Based Verification System Interface-Driven Verification

Top-Down SoC Verification

Bottom-Up SoC Verification
Components, blocks, units Memory map, internal interconnect Basic functionality, external interconnect System level

Platform-Based SoC Verification
Derivative Design Interconnect Verification between: SoC Platform Newly added IPs

System Interface-driven SoC Verification
Besides Design-Under-Test, all others are interface models

System-on-Chip Design and Validation Flow
ALGORITHMIC CO-VALIDATION Cores MPU, MCU,DSP DFT & TEST GENERATION CPU CORE ROM/ RAM Periph. PCI/ MPEG SYSTEM SPEC HARD CORES SOFT S/W TASKS ON UDL MAPPING / PARTITIONING IMPLEMENTATION H/W SYNTHESIS PROTOTYPE VERIFICATION FULL TIMING MODELS FULL TIMING VERIFICATION CYCLE BASED - ISS - HDL ARCHITECTURAL C-MODELS, HDL- ESTIMATORS - TIMING - POWER ASIC INTEGRATION BUS ARCHITECTURE ASIC PROTOTYPE Peripherals Interface Multimedia Telecom/ Networking Co- proc. VALIDATION

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

Verification of Cores in High Level Design Flow
user constraints: resource, performance, etc. Behavioral Functional RTL Structural RTL Hardware Sharing Delay / Power/ Testability VHDL Specs. CFG DFG Scheduler (cycle-by-cycle behavior) RT -Level Compiler Scheduled VHDL (contr + DP) RT-Level Optimization Test Bench Generation Estimators Optimized RTL Mapping, Physical Synthesis Verification - using Test Bench - Formal

Integration of Cores: Verification of Interfaces
CPU DMA Peripheral Peripheral External Bus Interface AHB Bridge APB ROM RAM Peripheral Peripheral Ext Access (Test) High Speed Low power Source: ARM AMBA: Advanced Microprocessor Bus Architecture

Device Test To check if devices are manufactured defect-free
Focus on structure of chip Wire connections Gate truth tables Not functionality

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!

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

Case Studies ALCATEL Image Compression System VisorVoice Product
“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

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

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

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

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 °C Space environment: total dose –10k rad, SEU - Single Event Upset – changing content of FF’s or memory Power budget: 6W/channel Size/weight: to be minimized

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

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

DCT Unit DCT Calculation 25 Mpixels/sec 
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

Huffman Unit Quantification Run length encode DCT coefficients
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

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

SoC System Architecture

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

Initial System

SOC Design After 0.35 µm was rated, an SoC version was implemented
Example of value of internal IP reuse

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

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

System Verification Alternatives
Simulation Emulation FPGA prototypes

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

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

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 hours of simulation time

VisorVoice - Informal Product Description

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

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

VisorVoice Performance
Record a meeting, record notes A typical meeting: minutes Recording notes: 2 minutes each, 60 maximum Speech quality: has to be good enough

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

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

VisorVoice Requirements

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

VisorVoice Functional Diagram

VisorVoice User Interface

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

Functional Architecture

IP Selection GUI RISC Processor
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

IP Selection AMBA Bus Visor Interface 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

IP Selection A/D, D/A, Amplifiers, etc. VisorVoice Codec
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 Visor’s microphone and module-mounted speaker

IP Selection Compression/Decompression Function Equalization Filter
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 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

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

VisorVoice Architecture

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

Behavioral/Algorithmic Model

Requirements & Results
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

Software Development Model

C-languange Models for IP blocks Host Software IP ARM7TDMI simulation model Results Tested VisorVoice/ARM host software

HW Development Model

VHDL models for hardware blocks Test Generator software Results Tested Hardware IP blocks for VisorVoice

Cosimulation Model

C models for ARM software VHDL models for hardware blocks Results Verified VisorVoice system level design

References System-on-a-Chip Verification Methodology and Techniques
Prakash Rashinkar, Peter Paterson, Leena Singh, Kluwer Academic Publishers, 2001 Prof. Chien-Nan Liu’s slides on SoC Verification, NCU, Taiwan

Design Verification for SoC 晶片系統之設計驗證

Similar presentations

Presentation on theme: "Design Verification for SoC 晶片系統之設計驗證"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Design Verification for SoC 晶片系統之設計驗證

Similar presentations

Presentation on theme: "Design Verification for SoC 晶片系統之設計驗證"— Presentation transcript:

Similar presentations

About project

Feedback