SoC Verification ( 晶片系統驗證 ) Pao-Ann Hsiung ( 熊博安 ) hpa@computer.org pahsiung/...

SoC Verification (晶片系統驗證 )

Pao-Ann Hsiung (熊博安 )hpa@computer.org http://www.cs.ccu.

edu.tw/~pahsiung/嵌入式系統實驗室

國立中正大學資訊工程學系

Pao-Ann Hsiung, CSIE, National Chung Cheng University2

Contents Introduction 3 ~ 26 Formal Verification 27 ~ 38

Model Checking 39 ~ 73 Equivalence Checking 74 ~ 83

Verification Tools 84 ~ 86 Verification Example:

Industrial Embedded SoC 87 ~ 98 Conclusion & Future Work 99 ~ 100

Introduction

M O O R E’ S L A W

Process Technology 0.25 um 0.18 um 0.15 um

1998 1999 2001

Silicon Complexity 1 M Gates 2~5 M Gates 5~10 M Gates

Deep Sub-Micron (DSM) Technology

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

Introduction

Design Productivity

Gates / Chip

Gates / Hour

Introduction

Time-to-Market (TTM) Trends

IntroductionMultiple Design

Disciplines: Digital HW

Embedded SW

Analog/Mixed Signal (AMS) Blocks

Bus Architectures

Clock / Power Distributions

Test Structures

Introduction

SoC Verification v/s Design Gap

Verification Options

Simulation Technologies

Static Technologies

Formal Technologies

Physical Verification and Analysis

Simulation Technologies Event-based Simulators Cycle-based Simulators Transaction-based Simulators Code Coverage HW/SW Co-verification Emulation Systems Rapid Prototyping Systems Hardware Accelerators AMS Simulation

Static Technologies

Lint Checking Syntactical correctness Identifies simple errors

Static Timing Verification Setup, hold, delay timing

requirements Challenging: multiple sources

Formal Techniques Theorem Proving Techniques

Proof-based Not fully automatic

Formal Model Checking Model-based Automatic

Formal Equivalence Checking Reference design modified design RTL-RTL, RTL-Gate, Gate-Gate

implementations No timing verification

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

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

SoC Verification Methodology

Verification Approaches

Top-Down Verification

Bottom-Up Verification

Platform-Based Verification

System Interface-Driven Verification

Top-Down SoC Verificationverifi

Bottom-Up SoC Verification

verifi

Components, blocks, units

Memory map, internal interconnectBasic functionality, external interconnectSystem level

Platform Based SoC Verification

Derivative Design

Interconnect Verification between:

SoC Platform Newly added I

System Interface-driven SoC Verification

Besides Design-Under-Test, all others are interface

models

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

Formal Verification

What is 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 a

pplications only

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

Model Checking

Formal model of the system Finite State Machine (FSM)

Desired behavior expressed as a set of properties (specifications) Computation Tree Logic (CTL)

Method to check properties against system Efficient FSM traversals

Formal Models of System

Any mathematically precise model that can be represented as a state transition system Finite State Machines Petri Nets (Timed) Automata Statecharts

State Transition System

M(S, R, L)

S = {s1, s2, s3}

R = transition relation

L = {a, b, c}

Kripke Structure

表達能力 v/s 驗證複雜度找平衡點 !

表達能力簡單

PSPACEEXPTIME

EXPSPACE

Undecidablenonelementary

表達能力豐富

驗證問題複雜度

語言的表達能力

Formal Model v/s Verification

Property Specification Languages

Linear Temporal Logic (LTL)

Computation Tree Logic (CTL) Timed Computation Tree Logic

(TCTL) 7 ms

CTL – Computation Tree Logic Path quantifiers

A (for all computation paths) E (for some computation path)

Temporal operators X (next time, next state) F (eventually, finally) G (always, globally) U (until) R (release, dual of U)

CTL Formulas

Temporal logic formulas are evaluated with respect to a state in the model

State Formulas Apply to a specific state

Path Formulas Apply to all states along a specific path

Basic CTL Formulas M, s |= E X (f )

Exists a next state of s, for which f holds

M, s |= A X (f ) For all next states of s, f is true

Basic CTL Formulas

M, s |= E G (f ) Exists a path from s, along which f holds i

n every state

M, s |= A G (f ) For all paths from s, f holds in every state,

i.e., globallys

Basic CTL Formulas

M, s |= E F (f ) Exists a path from s, which eventually co

ntains a state in which f holds

M, s |= A F (f ) For all paths from s, eventually there is a

state in which f holds

Basic CTL Formulas

M, s |= f U g Exists a path from s, which contains a

state in which g holds and in all previous states f holds

E F (f ) = E (true U f ) A F (f ) = A (true U f )

Basic CTL Formulas

Full set of operators Boolean: , , , Temporal: E, A, X, F, G, U, R

Minimal set of operators (to express any CTL formula) Boolean: , Temporal: E, X, U

Typical CTL Formulas E F ( start ready )

Eventually a state is reached where start holds and ready does not hold

A G ( req A F ack ) Any time request occurs, it will be eventu

ally acknowledged A G ( E F restart )

From any state it is possible to get to the restart state

TCTL (Timed CTL)

A G ( req A F 7 ack )

Time Constraint: Subscript “~ c ” is added to CTL formul

as ~ {<, , =, , >} c is an integer

TCTL Example

命中z=50ms

z:=0; 修正

監控x<500msz50ms

x:=0; z:=0 x 、 z 是實數值系統時鐘。

x、 z在系統開始時，被設為零。

z 在每次監控週期，被設為零。

M, 監控 |= E F<300 ( 命中 )

Model Checking – Problem

Given: a structure M (S, R, L) and a temporal logic formula f,

find a set of states that satisfy f .

{s S : M, s |= f }

Model Checking – Explicit Algorithm Label each state s with the set label(s )

= { sub-formulas of f, which hold in s } i = 0; label(s ) = L (s ) i = i + 1; process formulas with (i -1) nes

ted CTL operators. Add processed formulas to label(s ).

Continue until closure. Result: M, s |= f iff f label(s )

Explicit Model Checking

E F (g h)

T1 = states in which g & h are true

T2 = complement of T1

T3 = predecessor states of T2

Traffic Light Controller

Farm Road

City Road

S = Sensor

T = Timer

R1 Y2 Y1 R2

C’ + T’

C’ + T

C T’

Kripke Structure

Traffic Light ControllerG1 R2

G1 R2 Y1 R2

State Graph

G1 R2 Y1 R2

R1 G2R1 Y2

R1 G2Y1 R2

R1 Y2 R1 G2

Traffic Light Controller

Model Checking Tasks Safety Condition

No green lights on both roads at the same time

A G (G1 G2) Fairness Condition

Eventually one road has green light

E F (G1 G2)

Traffic Light Controller – Checking Safety Condition

A G (G1 G2) E F ( G1 G2)

S(G1 G2) = S(G1) S(G2) = {1} {3} =

S(EF(G1 G2) = S(EF(G1 G2) =

= {1, 2, 3, 4} Safety condition is

R1 Y2 Y1 R2

C’ + T’

C’ + T

C T’Kripke Structure

Traffic Light Controller –Checking Fairness Condition

E F (G1 G2) E(true U (G1 G2))

S(G1 G2) = S(G1) S(G2) = {1} {3} = {1, 3}

S(EF(G1 G2)) = {1, 2, 3, 4}(going backward from {1, 3}, find predecessors)

Fairness condition satisfied!

Symbolic Model Checking

Symbolic Operates on “sets of states” rather tha

n individual states Use BDD for efficient representation

Represent Kripke structures Manipulate Boolean formulas

Binary Decision Diagram (BDD) BDD: A canonical form of

representation for Boolean formulas. Motivation:

Too much space redundancy in traditional representations

BDD is more compact than truth tables, conjunctive normal form, disjunctive normal form, binary decision trees, etc.

Ordered BDD has a canonical form BDD operations are efficient

BDD v/s Binary Decision Trees

Binary Decision TreeBDD

Order: a1 < b1 < a2 < b2

2-bit Comparator

Ordered BDD (OBDD) Since OBDDs are canonical, it is easy to:

check equivalence = check BDD isomorphism check satisfiability = check BDD isomorphism

with OBDD(0) Size of OBDD depends critically on

VARIABLE ORDERING !!! 2-bit comparator example:

Change variable order to: a1 < a2 < b1 < b2

11 vertices instead of 8 for a1 < b1 < a2 < b2

OBDD (Variable Ordering)

a1 < a2 < b1 < b2

In general, for n-bit comparator:

a1 < b1 < …< an < bn

gives 3n + 2 vertices

a1 < …< an < b1<…< bn

gives 3 2n 1 vertices

BDD: Application to Verification

Equivalence of combinational circuits Canonicity property of BDDs:

If F and G are equivalent, their BDDs are identical (for the same variable ordering)

F=a’bc + abc + ab’c

0 1G=ac + bc

BDD: Application to Verification

Functional Test Generation SAT, Boolean satisfiability an

alysis Test for H=1 (0):

find a path in BDD to terminal 1 (0)

The path, expressed in function variables, gives a satisfying solution (test vector)

abab’c

Model Checking Issues

Completeness Model checking is effective for a

given property Impossible to guarantee that the

specification covers all properties the system should satisfy

Writing the specification – responsibility of the user

Negative Results

Incorrect model

Incorrect specification (false negative)

Failure to complete the check (too large)

Capacity State-space explosion occurs for

complex systems So, what is the use of Model

Checking for SoC? Use model checking as a

complementary technique, in addition to simulation, testing, emulation, etc.

Equivalence Checking Compares an implementation to an

existing RTL or gate-level description for functional equivalence RTL vs. synthesized gate-level implementation Gate-level design vs. revised gate-level design

Uses BDDs, a canonical representation of logic functions BDDs can grow exponentially with number of

inputs Depends on variable ordering

Features: No vectors or testbench required Capacity to handle large design Eliminates gate-level simulation Reduce time-to-market

Equivalence Checkers were used in: RTL-to-RTL RTL-to-Netlist Netlist-Netlist: some optimizations in Net

list like: CTS-inserted netlist Scan-chain-inserted netlist Post-layout netlist …….

Equivalence Checking Two circuits are functionally

equivalent if they exhibit the same behavior

Combinational Circuits For all possible input values

Sequential Circuits For all possible input

sequences

Combinational Equivalence Checking

Functional Approach Transform output functions into BDD 2 circuits are equivalent if their BDDs are i

dentical Structural Approach

Identify structurally similar internal points Prove internal points (cut-points) equivale

Functional Equivalence

BDDs of output functions must be identical (using the same variable ordering) for functional equivalence

If BDDs are too large Cannot construct BDD, memory problem Use partitioned BDD method

Decompose circuit into smaller pieces Represent each piece as a BDD Check equivalence of internal points

Functional Decomposition

Decompose each function into functional blocks Represent each block as a

BDD Define cut-points (z) Verify equivalence of blocks

at cut-points starting at primary inputs

Cut-Points Resolution

All pairs of cut-points are equivalent F G

If intermediate functions f2, g2 are not equivalent, functions F and G may still be equivalent (FALSE NEGATIVE)

How to check False Negative? XOR (F, G) BDD for F G

Structural Equivalence Given 2 circuits, each with its own struct

ure Identify “similar” internal points, cut sets Exploit internal equivalences

False negative problem may arise F G, but differ structurally Verification algorithm declares F, G differ’

nt Implication Techniques Learning Techniques

Sequential Equivalence Checking

Represent each sequential circuit as an FSM Verify if two FSMs are equivalent

Approaches: Reduction to combinational circuit Isomorphism of state graphs Symbolic FSM traversal of product machi

Formal Verification Tools

Model Checkers Equivalence Checkers

Academic Research Tools Commercial Verification Tools

Formal Tools Semi-Formal Tools

Academic ToolsTools Institutes

SMV CMU

MOCHA, VIS, HyTech UC Berkeley

STeP Stanford

SGM CCU & SinicaRED Academia SinicaUPPAAL Uppsala & Aalborg Univ

sKRONOS Verimag

Commercial Tools

Tools Companies

Formal Check Cadence

Formal Model Checker Avant!Formality SynopsysFormal Pro Mentor Graphics

Black Tie, Conformal LEC

Verplex Systems

Example:Formal Verification of SoC

Industrial Embedded SoC Product Korea Samsung Electronics S3C2400X ARM920T processor 16 function modules (IPs)

Reused IPs: UART, I2S, … Newly Designed IPs: bus controllers, DMA,... Newly Bought IPs: USB host controller

S3C2400X SoC

Formal Verification Methodology for SoC

Model CheckerCadence SMV (Symbolic Model Verifier) Many success stories!!! Supports SMVL and Verilog (with vl2smv) Problem size reduction:

scalarset data type for symmetric reduction ordset data type for induction subclass structure for case-splitting layer structure for compositional assume-gu

arantee verification

Modeling Problems

SMV supports only 1 implicit clock Issues in modeling in SMVL:

Multiple clocks Gated clocks Unsynchronized clocks Synchronization logic

General Strategy forModule Verification

1) Define what to verify for a module.

2) Construct the environment required for verifying each property.

3) Transform each property to CTL.

4) Check coverage of CTL properties over RTL code

Vacuous Property Checking

A G ( p A X (q) ) If p does not occur, we cannot check A

X(q) at all. Model Checker says it is verified as tru

e. We should check if p occurs at least o

nce, i.e., A G (~p) is false!

Fairness Constraint

The correctness of a module depends not only on environment, but also some specific behavior of the environment

This specific behavior is modeled as fairness constraints (input restrictions)

Also called assumptions in assume-guarantee reasoning

Reduction of Address Bus and Data Bus

Traditional approach: Abstraction:

32-bit wide bus 1-bit or 2-bits wide

Not used in SoC, because full data bus and partial address bus are used to access CRs (configuration registers)

Reduction of Address Bus and Data Bus

Different approach: Divide verification task into 2 parts:

CR accessing logic Normal operation logic

2 different environments 2 different property groups

Modules Verified

Modules CTL properties

State variables

Time (min)

AHB arbiter

27, 38 90, 80 50

Bridge 61 50 5

DMA 67 100 440

USB (mw)Host (mr)

102+4+536+4+2

N/A 9h, 43h2h, 6h

Discussions on Example

Incremental design and verification

Early stage of design: helps find real design errors

Later stage of design: helps find model and property errors

Design and verification time reduced

Conclusions Formal verification of SoC is

definitely required! But, it should be used in conjunction

with other verification techniques. Capacity of formal verification must

be enlarged for its wide-spread adoption

Techniques required: Design abstraction Verification partitioning

Future Work

Automatic abstraction & partitioning Assume-Guarantee Reasoning (AGR)

Incorporation of assertion languages: Verplex’s OVL Intel’s ForSpec etc.

IP = Verilog + OVL + AGR Hierarchical verification of SoC based

on OVL + AGR

Language Wars!!!

SoC Verification ( 晶片系統驗證 ) Pao-Ann Hsiung ( 熊博安 ) hpa@computer.org pahsiung/...

Documents

Transcript of SoC Verification ( 晶片系統驗證 ) Pao-Ann Hsiung ( 熊博安 ) hpa@computer.org pahsiung/...

1 The Application Layer Mail 李嘉銘 分散系統實驗室 成功大學電機系.

ADAS系統檢測技術 盲點警示系統 及緊急煞車輔助系統(AEBS)€¦ · adas系統檢測技術-盲點警示系統 (bsw)及緊急煞車輔助系統(aebs) 實車測試實驗室陳昱伸

空調淨化系統及其驗證 · 2019. 7. 26. · 空調淨化系統簡介 •空調淨化系統（HVAC系統）全稱為採暖通風與空 氣調節系統（Heating ventilation

系統樹・系統仮説の可視化 と系統仮説間の統計的比較 · 系統樹・系統仮説の可視化 と系統仮説間の統計的比較 田辺晶史 実習編. 演習

系統暨網路管理實驗室 Systems & Network Management Lab

Civil-NET 雙星 eGPS 雲端服務系統 校正系統驗證

系統樹・系統仮説の可視化と系統仮説間の統計的比較 実習編

基本課程設計 - web.ee.nthu.edu.twweb.ee.nthu.edu.tw/var/file/175/1175/img/1275/699845700.pdf · 邏輯設計實驗、嵌入式系統與實驗、 電動機械實驗、固態電子實驗、

3.1 第 2 章 系統結構 n 作業系統的服務 n 使用者作業系統介面 n 系統呼叫 (System Calls) n 系統呼叫的類型 n 系統程式 (System Programs) n 系統結構

苗栗縣英語聽寫會考命題 暨線上測驗系統

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

資科系 ( 所 ) 網站系統 老師資料維護系統

[嵌入式系統] MCS-51 實驗 - 使用 IAR (3)

無線系統實驗室 Wireless System Lab (ED900/913B)

智慧型圖書館管理系統平台 建置經驗分享163.23.171.1/lib/1051/1051210poster.pdf · 四、方法 建置rfid無線射頻辨識系統 國立北斗家商～智慧型圖書館管理系統平台建置經驗分享

系統簡介 系統說明 權責機關 系統功能架構

系統樹・系統仮説の可視化と系統仮説間の統計的比較 講義編

ISO - · PDF file第二十章 iso9000簡介 20-2 iso 9000 的起源 iso 9000 系統架構 1963 年美軍規格 mil-q9858a 品質系統 mil-l4520b 檢驗系統 1969年

TQC 測驗系統考試流程說明

&UHDWLQJ VLJQL¿FDQW UHVXOWV - taftw.org.t · 26 領域Fields 次領域Sub-Fields 家數 mber 管理系統 驗證機構 Management System Certification Bodies 品質管理系統(QMS)、環境管理系統(EMS)、資訊安全管理系統(ISMS)、

1 The Application Layer Mail 李嘉銘分散系統實驗室成功大學電機系.

ADAS系統檢測技術盲點警示系統及緊急煞車輔助系統(AEBS)€¦ · adas系統檢測技術-盲點警示系統 (bsw)及緊急煞車輔助系統(aebs) 實車測試實驗室陳昱伸

空調淨化系統及其驗證 · 2019. 7. 26. · 空調淨化系統簡介 •空調淨化系統（HVAC系統）全稱為採暖通風與空氣調節系統（Heating ventilation

系統樹・系統仮説の可視化と系統仮説間の統計的比較 · 系統樹・系統仮説の可視化と系統仮説間の統計的比較田辺晶史実習編. 演習

Civil-NET 雙星 eGPS 雲端服務系統校正系統驗證

系統樹・系統仮説の可視化と系統仮説間の統計的比較実習編

基本課程設計 - web.ee.nthu.edu.twweb.ee.nthu.edu.tw/var/file/175/1175/img/1275/699845700.pdf · 邏輯設計實驗、嵌入式系統與實驗、電動機械實驗、固態電子實驗、

3.1 第 2 章系統結構 n 作業系統的服務 n 使用者作業系統介面 n 系統呼叫 (System Calls) n 系統呼叫的類型 n 系統程式 (System Programs) n 系統結構

苗栗縣英語聽寫會考命題暨線上測驗系統

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

資科系 ( 所 ) 網站系統老師資料維護系統

智慧型圖書館管理系統平台建置經驗分享163.23.171.1/lib/1051/1051210poster.pdf · 四、方法建置rfid無線射頻辨識系統國立北斗家商～智慧型圖書館管理系統平台建置經驗分享

系統簡介系統說明權責機關系統功能架構

系統樹・系統仮説の可視化と系統仮説間の統計的比較講義編

&UHDWLQJ VLJQL¿FDQW UHVXOWV - taftw.org.t · 26 領域Fields 次領域Sub-Fields 家數 mber 管理系統驗證機構 Management System Certification Bodies 品質管理系統(QMS)、環境管理系統(EMS)、資訊安全管理系統(ISMS)、