html5-img
1 / 81

Verification and debugging of hardware designs utilizing C-based high- level design descriptions

Verification and debugging of hardware designs utilizing C-based high- level design descriptions. Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo. System level design flow. Typical design flow used in industry

suki
Télécharger la présentation

Verification and debugging of hardware designs utilizing C-based high- level design descriptions

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Verification and debugging of hardware designs utilizing C-based high- level design descriptions Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo

  2. System level design flow Typical design flow used in industry Mostly C language based design descriptions for embedded system and SoC designs conception Function-SeparatedDescription ComponentLibraries HW3 HW1 SW HW2 Ideas Design as aMeeting Point Functional decomposition StructuralDecomposition Components High Level / Transactional C/TLM High Level Synthesis Automatic / Manual ArchitecturalExploration Performance Analysis HW/SW partitioning RTL to RTLOptimization RTL C/HL RTL Synthesis

  3. (Electric) System level design tools: Elegant HW？ HW？ A B C D SW？ SW？ D ? A ? B ? A C C ? Processor model Device driver Interface circuits B D A C SW HW Protocol Protocol B D HW SW Static/model checking, Equivalence checking Traditional design starts here… System level design Software implementation design SystemC/SpecC Algorithm design HW/SW partitioning Communication network design Interface design Hardware implementation design (RTL) JAXA: Japanese space exploration agency Elegant tool has actually been used for space satellites Joint development by JAXA, Toshiba, NEC, Fujitsu, UC Irvine, and U. of Tokyo (formal verification) Help assigning functions onto components 3

  4. Outline • Overviews of our verification research activities regarding to C-based high-level design descriptions • Based on Extended System Dependence Graph (ExSDG) • Equivalence checking as well as static/model checking with ExSDG • Post-silicon verification method through mapping chip traces with ExSDG • Verification/debugging methods for large arithmetic circuits • Automatic generation of on-chip bus protocol transducers

  5. System Dependence Graph • Sufficient representation since verification methods for net-list are applicable to SDG • Problems • Existing SDGs are too complicated (# nodes/edges are huge) • Not directly corresponding to abstract syntax trees main int i = 1; main(){ int a = 0; int b = 0; a = a + i; if(a == 1) b = a++; } int a int b int i Dependency Analysis i = 1; b = 0; a = 0; a = a + i; if(a==1) Control dependence a++ Data dependence b = a++; Declaration dependence System Dependence Graph (SDG)

  6. Module par{ a.main(); b.main(); c.main();} port Sub Module 1 Sub Module 2 a b c bit a[3:0]; bit b[3]; b a a[2:0]@b[1] ・・・ wait(a); ・・・ ・・・ ・・・ notify(b); ・・・ ・・・ ・・・ notify(a); ・・・ wait(b); ・・・ ・・・ Extended Syntaxes in ExSDG from C buffered bit[1] a; a = 1; waitfor(1); waitfor(1); a = 0; waitfor(1); Hierarchical Structure clk a Concurrency Timed Behavior Bit Vector Synchronization

  7. Translation Flow to ExSDG Untimed Behavior Level: ・ No notion of time ・ For software design or behavior specification SystemC Design Complex or redundant syntaxes are removed ex) switch statement AST (UBL) System Level / Behavior Level SpecC Design Simplifi- cation System- Verilog Design AST (TBL) ExSDG Verilog Design Timed Behavior Level: ・ Including timing specification ・ For design with timing estimation AST (RTL) RTL VHDL Design Register Transfer Level: ・ Cycle accurate ・ For hardware design

  8. Three Design Stages module TEST( int in1, int out1, event e) { Proc p1(); Proc p2(); void main(){ par{ p1.main(); p2.main(); } wait(e); } }; module TEST( int in1, int out1 event e){ Proc p1(); Proc p2(); void main(){ par{ p1.main(); p2.main(); } waitfor(1); wait(e); } }; module TEST( wire int in1, wire int out1){ buffered int a; void init(){ out1 = a; } void run_one_cycle(){ a = in1; } main(){} }; Untimed Behavior Level: ・ Concurrency and Synchronization ・ Times expressions and buffered/wire variables are prohibited Timed Behavior Level: ・ Untimed Behavior Level + Timed expressions ・ buffered/wire variables are prohibited Register Transfer Level: ・ par and wait/notify are prohibited ・ init(): Wire connections are declared ・ run_one_cycle(): Executed per clock

  9. Edges in ExSDG • Control Flow Edge • Data Dependence Edge • Control Dependence Edge • Declaration Dependence Edge • Parameter In/Out • Summary Edge (Interprocedural Dependence Edge) • Parallel Edge • Communication Edge • Port Reference Edge

  10. Concurrent and Synchronization Dependence int x, y; event e1,e2; void main(void){ y = 0; x = 5; par{ func1(); func2(); } } void func1(){ y = x; notify(e1); wait(e2); x = y; } void func2(){ wait(e1); y++; y = y * y; notify(e2); } Process 2 Process 1 par notify(e1); wait(e1); func1(); func2(); wait(e2); notify(e2); end Communcation Edge Parallel Edge

  11. Hierarchical Dependence module M1(int in, int out, event e1){ void main(void){ wait(e1); out = in * in; } }; module M2(int in int out event e1){ void main(void){ out = in + in; notify(e1); } }; module M3(int inout){ int w1; event e1; M1 m1(w1, inout, e1); M2 m2(inout, w1, e1); void main(void){ par{ m1.main(); m2.main(); } } }; int M::in; int M1::out; event M1::e1; int M3::w1; event M3::e1; int M3::inout; int M2::in; int M2::out; event M2::e1; Port Reference Edge

  12. Experimental Results • Compared with a SpecC SDG generation method using CodeSurfer • Performed on a PC with Xeon 3.2GB and 2GB memory SDG Generation Time Num. of Nodes and Edges in IDCT Example

  13. Outline • Overviews of our verification research activities regarding to C-based high-level design descriptions • Based on Extended System Dependence Graph (ExSDG) • Equivalence checking as well as static/model checking with ExSDG • Post-silicon verification method through mapping chip traces with ExSDG • Verification/debugging methods for large arithmetic circuits • Automatic generation of on-chip bus protocol transducers

  14. From the viewpoint of verification Keep entire descriptions as correct as possible Static/Model checking each description Equivalence checking between two descriptions Besides simulation, formal methods should be applied Algorithmic design description Design optimization Many steps of manual refinement Sequential Equivalence Checking High level synthesizable description Static/ Model checking Design optimization High level synthesis Many steps of manual refinement Register Transfer Level description Design optimization

  15. Basic Procedure • Symbolic simulation • Generates a set of equations from designs • Every variable/operation is an uninterpreted symbol • Every expression is a formula of symbols • Equivalence Class (EqvClass) • A class containing all equivalent expressions/variables • Generated during symbolic simulation based on • Assignment statement • Substitution with equivalent expressions/variables • Solving with SMT solvers • If generated equations have to be solved to prove the desired equivalence, we use SMT solvers to interpret arithmetics • Public ones and our own solves

  16. Example a = v1; b = v2; add1 = a + b; add2 = v1 + v2; Description 1 Description 2 E1 (a, v1) E2 (b, v2) E3 (add1, a+b) E4 (add2, v1+v2) E1 (a, v1) E2 (b, v2) E3’ (add1, a+b, add2, v1+v2) 4 EqvClasses are generatedfrom 4 assignments E3 and E4 can be merged bysubstituting awith v1, b with v2

  17. Representing Symbolic Expressions: Maximally Shared Graph x0=a+b; if x0<0 then x1 = -x0; y1 = y0; else x1 = x0; y1 = y0+x0; assert(0<=y1);

  18. Linear-sized representation Mathematically equivalent to standard logical representation Advantages Structure explicit[flow of data in the graphcorresponds to flow of data in the program] Simple slicing No structural redundancies Not functionally canonical Practical trade-off Maximally Shared Graph

  19. Problem and Our Approach • Symbolic simulation cannot be applied to a whole large designs • Because of the path explosion problem • Approach: Localizing the areas that are symbolically simulated utilizing differences : difference return a; return a; return a; return a;

  20. Equivalence Checking Flow Seq.desc1 Seq.desc2 Extension of the Area and decision of itsinputs/outputs Identification of diff. No Eqv Is there any diff. left? Verification “Equivalent” Not eqv Yes No Reach to primaryinputs/outputs? Decision of initial verification area and its inputs/outputs Yes Eqv Not eqv Verification “Not equivalent”

  21. Verification Area and its Input/Output • Verification area: A set of statements • Input variables • Used in the area, and assigned outside • Output variables • Assigned in the area, and used outside • Verification problem for the area • Are all pairs of output variables with the same name are equivalent? • Using proved equivalences of the input variables

  22. Example a0 = in1;b0 = a0 + in2;c0 = 0;a1 = b0 + in3;out0 = a1 * c0; a0 = in1;b0 = a0 + in2;c0 = 0;a1 = b0 + 2 * in3;out0 = a1 * c0; • Initial verification • Input … b0, in3 • Output … a1 • Result … Equivalence cannot be proved Diff (※) in1, in2, in3 are theprimary inputs of boththe descriptions Forward extension from a1

  23. Example a0 = in1;b0 = a0 + in2;c0 = 0;a1 = b0 + in3;out0 = a1 * c0; a0 = in1;b0 = a0 + in2;c0 = 0;a1 = b0 + 2 * in3;out0 = a1 * c0; • 2nd verification • Input … b0, c0, in3 • Output … out0 • Result … Equivalence cannot be proved Diff (※) in1, in2, in3 are theprimary inputs of boththe descriptions Backward extensions from all inputs (forward extension cannot be applied any more)

  24. Example a0 = in1;b0 = a0 + in2;c0 = 0;a1 = b0 + in3;out0 = a1 * c0; a0 = in1;b0 = a0 + in2;c0 = 0;a1 = b0 + 2 * in3;out0 = a1 * c0; • 3rd verification • Input … a0, in2, c0 (= 0), in3 • Output … out0 • Result … Equivalent (due to c0 = 0) Diff (※) in1, in2, in3 are theprimary inputs of boththe descriptions Though the different part are not equivalent, the primary output is equivalent

  25. Implementation • FLEC: An Framework for Verification, Debugging Support, and Static Checking • Several engines developed by ourselves • Symbolic simulator, difference extraction, input pattern generation, static deadlock checker, slicing, … • Dependence graph-based internal representation of system-level designs • A number of APIs are provided to help development of engines • ExSDG (Extended System Dependence Graph) • Designs are represented in form of ExSDG in FLEC • Frontend from SpecC to ExSDG is already developed

  26. FLEC Structure SpecCDesign2(.sc) SpecCDesign1(.sc) Equivalencechecked Verification procedure (Applied Method & Order) ExSDG Generation Eqv. Spec ExSDG(.fls) Eqv. Classes ExSDG(.fls) Result Control Control Diff Extraction Rule-basedEngine SMT solvers SymbolicSimulator SequentializingParallel Behaviors

  27. Sequential equivalence checking Definition of equivalence Intension of designers, management of differences For efficient checking: Identification of matching states Bounded equivalence checking between matching states Identification of equivalent internal points Use of SMT solvers

  28. Transactions : State View Encapsulates one or more units of computation for the design being verified Self-contained since it brings the machine back to a synchronizing state SL transaction SLM Refinement mapping RTL RTL transaction

  29. Mem ADDR DATA RD WR Mem Cache ADDR DATA Cache ctl OUT Transaction : Memory • Design 1 transaction : a single memory read/write occuring in a single cycle • Design 2 transaction: single memory read/write (potentially) happening over multiple cycles RD WR Design 1 OUT Design 2

  30. Transaction-Based Equivalence Checking The states in RTL that correspond to states in system-level model (SLM), are referred to as synchronizing states Based on this, definitions of equivalence are generated manually The total equivalence is based on inductions on synchronizing states or Refinement mapping Sequential counterexample Transient states Complete Verification SLM RTL

  31. Equivalence Specification Equivalence is specified by (Port, Throughput, Latency, Condition) behavior Adder3(in int in1, out int out1) { void main() { int tmp; while(1) { tmp = in1; waitfor(1); tmp = tmp + in1; waitfor(1); tmp = tmp + in1; waitfor(1); out1 = tmp; waitfor(1); } } }; behavior Adder1(in int in1, in int in2, in int in3, out int out1) { void main() { out1 = in1 + in2 + in3; } }; behavior Adder2(in int in1, in int in2, in int in3, out int out1) { void main() { int tmp; while(1) { tmp = in1 + in2; waitfor(5); tmp = tmp + in3; waitfor(5); out1 = tmp; } } }; (in1, 1, 0, TRUE) (in2, 1, 0, TRUE) (in3, 1, 0, TRUE) (out1, 1, 0, TRUE) (in1, 10, 0, TRUE) (in2, 10, 0, TRUE) (in3, 10, 5, TRUE) (out1, 10, 10, TRUE) (in1, 4, 0, TRUE)(in1, 4, 1, TRUE) (in1, 4, 2, TRUE) (out1, 4, 3, TRUE)

  32. Sequentialization Concurrent behaviors are sequentialized If st1 and st2 running concurrently are “write-write” or “read-write” relation, check the following properties: P1: always T(st1) > T(st2) P2: always T(st1) < T(st2) T(s) … execution time of a statement s The checks are based on ILP Is there any assignment satisfying P1 (P2) ? With the timing constraints generated from SpecC designs Can besequentialized

  33. Sequentialization a = 10;b = 10;c = a + b; x = 20;y = 20;z = x + y; a = 10;wait e;c = a + x; x = 10;a = 10;c = a + x; x = 20;notify e;y = 20;z = x + y; x = 20;y = 20;z = x + y; No dependence Synchronized Not synchronized always x=10  x=20? Result: NOalways x=20  x=10? Result: NOCannot be sequentialized!! always x=20  c=a+x? Result: YESalways x=a+x  x=20? Result: NOCan be sequentialized!! No check is needed a = 10;b = 10;c = a + b;x = 20;y = 20;z = x + y; a = 10;x = 20;y = 20;z = x + y;c = a + x;

  34. For HW/SW co-design Software part SW (FSMD) Identify Synch. points Abstraction on Comm. Transform to FSMD RTL C HW (FSMD) Recude # states Sequentialization Model checking HW+SW (FSMD) Equivalence checking

  35. Case Study 1: MPEG4 • Difference between designs • Constant propagation, constant folding, common sub-expression elimination in IDCT function • Design size • About 6300 lines in SpecC • About 50k nodes and 36k edges in ExSDG • ExSDG generation time: 780 sec

  36. Case Study 2: Elevator Controller • Difference between designs • Speculative code motion in control paths • Design size • About 3300 lines in SpecC • About 20k nodes and 20k edges in ExSDG • ExSDG generation time: 178 sec

  37. Rule-based Equivalence Checking Checks the equivalence between two high-level (e.g. SpecC) design descriptions • Assuming the equivalences of variables, equivalence rules are applied in a bottom-up manner • Equivalence rules are defined in terms of static dependence relations and control flows • Verification result is either "equivalent" or "cannot prove the equivalence" • It cannot prove that they are not equivalent • Equivalence rules are heuristically picked up

  38. Equivalence Rules (1/3) Rule 1: Expression • Checks the equivalence considering the commutative, associative, distributive laws d * (b * a + c) d * a * b + c * d Original design Modified design + * + d Distributive law * * c * d d c * a b Commutative law b a

  39. Equivalence Rules (2/3) Rule 2: Assignment • The variable in LHS is equivalent to RHS until the variable is re-assigned { int c = a - b; return c;} { return a - b;} Original design Introducing an intermediate variable return return = Rule 2 c ー ー c Rule 1 b a b a

  40. Equivalence Rules (3/3) Rule 3: Sequential composition • Execution order can be changed unless it destroys the data dependence relations {L2:d = a + c; L1:c = a + b; L3: e = b + c;} {L1:c = a + b; L3: e = b + c;L2:d = a + c; } {L1:c = a + b; L2:d = a + c; L3: e = b + c;} Swapping L2 and L3 Swapping L1 and L2 Original design seq seq seq L2 L1 L3 L1 L3 L2 L1 L2 L3

  41. Rule 3 Internal equivalences Rule 1 Rule 2 Example: Bottom-Up Application of Rules { c = a - b; f = d + e;} { f = e + d; c = a - b;} Original design Modified design seq seq = = = = ー c f + f + c ー b a e d d e b a

  42. A Known Issue of Rule-based Checking How can we find internal equivalences? • Our initial method finds them by "name" • That is, all variables with the same name are identified to be equivalent • This approach fails the equivalence checking when variable names change • Typically, variable names are changed through design transformations • If variables in different places have the same name, the result may be false positive

  43. Examples of Checking Failure Though following examples are all equivalent, name-based equivalence checker fails int ex2(int b, int a) { return b - a;} int ex1(int a, int b) { return a - b;} Swapping the variable names Original design int ex4(int a, int b) { int c = a - b; return c;} int ex3(int c, int d) { return c - d;} Modifying the variable names Introducing an intermediate variable

  44. Identifying Potential Internal Equivalences • Perform a random simulation, then identify a set of variables having the same signature (i.e. sequence of simulated values) • Well-known technique in RTL verification • In RTL, the values of registers are uniquely known at every cycle • However, there is no concept of "cycle" in behavioral-level design descriptions • The concept of "a variable with context" is introduced e=(255,-1155,715)f=(-185,1147,709) e = a - b;f = a + b; {e, y}{f, x} a=(35,-4,712)b=(-220,1151,-3) Design 1 Simulation x = b + a;y = a - b; x=(-185,1147,709)y=(255,-1155,715) Potential Internal Equivalences Random Pattern Signatures Design 2

  45. Internal Equivalences at Behavioral Level Definition of a cycle • A period of the execution from accepting an input pattern to generating a set of outputvalues • Internal variables must be assigned once in a cycle • Designs are in static single assignment (SSA) form • The concept of "a variable with context" is introduced for multiple instantiations of modules and function calls A variable with context • Context: a runtime path information from the top-level module to the current function • Guaranteed to be assigned only once in a cycle

  46. Method Based on Potential Internal Equivalences Issue: Potential internal equivalences may include false equivalences • False equivalences may lead to false positive results • Non-equivalent variables may be identified as equivalent • Equivalent variables are always identified as equivalent • True equivalences are included in potential equivalences Solution: Explores all possible subsets of internal equivalences when applying the rules • Still practical since each set of internal equivalences is typically small

  47. Implementation Implemented in C++ on top of our system-level verification framework FLEC • Given a SpecC design description as an input, ExSDG representation is generated by parser and dependence analyzer • Potential internal equivalence identifier • Generates SpecC description from ExSDG representation as well as a random input pattern generator module • Compiles the random simulator using SpecC reference compiler • Rule-based equivalence checker • Each rule is implemented as a callback function • Given two nodes in ExSDGs, the equivalence between two sub-trees are checked

  48. Case Study: A Practical Design Example: Two IDCT designs before and after parallelization • Column & row processes are parallelized • Existing method failed checking since it could not find the correspondences between variables • Proposed method checked the equivalence • 10 cycles of random simulation • Runtime: ~3 seconds • Mainly compilation and execution time of simulator

  49. Outline • Overviews of our verification research activities regarding to C-based high-level design descriptions • Based on Extended System Dependence Graph (ExSDG) • Equivalence checking as well as static/model checking with ExSDG • Post-silicon verification method through mapping chip traces with ExSDG • Verification/debugging methods for large arithmetic circuits • Automatic generation of on-chip bus protocol transducers

  50. Debug Hardware master bus slave m_request opb_grant m_select … … s_dbus opb_dbus initiator channel target s_xferack opb_xferack put(req) get(req) true/false true/false … put(res) get(res) true/false true/false • Event Extractor • Extract basic required information • Transaction type (read/write) • Start of transaction • End of transaction • Initial and target address of transaction • Trace Buffer • Store extracted transactions in a compact form

More Related