transaction assertions in an interface definition language n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Transaction Assertions in an Interface Definition Language PowerPoint Presentation
Download Presentation
Transaction Assertions in an Interface Definition Language

Loading in 2 Seconds...

play fullscreen
1 / 47
johana

Transaction Assertions in an Interface Definition Language - PowerPoint PPT Presentation

192 Views
Download Presentation
Transaction Assertions in an Interface Definition Language
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. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. Transaction Assertionsin an Interface Definition Language Dave Whipp – DesignCon 2008

  2. Who Writes Assertions? • Designers • Bottom Up Assumptions • Verification Engineers • Top-down Intent • Verification Vs Validation

  3. Who Writes Assertions? • Designers • Bottom Up Assumptions • Verification Engineers • Top-down Intent • Architects • The Specification • Top Down Assumptions • Bottom Up Intent

  4. Where to Write Assertions • The RTL • Inline • Bound • The Testbench • Scoreboard • Environment • E.g. Post Process Log file

  5. Where to Write Assertions • The RTL • Inline • Bound • The Testbench • Scoreboard • Environment • Post Process Log files • The Specification • C Models (?)

  6. Where To Write Specification Assertions Functionality Model RTLDesign Performance Model

  7. Where To Write Specification Assertions Functionality Model Structural Model RTLDesign Performance Model

  8. What is a “Structural” model? • A Graph • Nodes • Arcs • Communicating Processes • Processors • Messages (Transactions) • A Netlist • Modules • Interfaces (Wires)

  9. Birth of an IDL • Initially, a language just to define signals Interface a2b clock clk down U valid 1 up U busy 1 down U cmd 24 down U data 32

  10. Evolution of an IDL • Quickly added flow-control protocol abstraction Interface a2b clock clk flow valid_busy down U cmd 24 down U data 32 • From this we can generate: • Testbench components (BFMs: producers, consumers) • Protocol Assertions • …

  11. Multi-Unit Assemblies A B C D E F G a2b b2c c2d d2e e2f f2g A simple pipeline

  12. Multi-Unit Assemblies a2b b2c c2d A B C D E F G d2e e2f f2g Simple rearrangement

  13. Multi-Unit Assemblies a2b b2c c2d A B C D E F G d2e e2f f2g Identify units with similar behaviors

  14. Multi-Unit Assemblies cf2d d2be BE CF D be2cf a2be A cf2g G Extract common behavior into unified components be2cf === b2c + e2f

  15. Reusing Interface Definitions A B C D E F G BE CF D A G How to maximize reuse between these two architectures?

  16. Continued Evolution of an IDL • Separation of packet structure from interface group SOP down U cmd 24 group MOP down U data 32 group EOP down U checksum 32 Interface a2b clock clk flow valid_busy packet SOP, MOP, EOP

  17. Interfaces Vs State • Two approaches to comparing models: • Compare “Architectural State” • Registers/flops within the design whose existence is required by the specification • Compare externally visible behavior • Compare interface traffic • B. F. Skinner?

  18. Comparing Interfaces • Simple “diff” • Normalization (masking, snapping) • Binning (collating, sorting) • Accumulating • In-memory FIFOs + scoreboard • File-based post-processing

  19. Step 1: Capture transactions C-Model tid=A seq=1 tid=A seq=2 tid=A seq=3 tid=B seq=1 tid=B seq=2 tid=B seq=3 RTL 1010 01 1010 10 1011 01 1010 11 1011 10 1011 11 time

  20. Step 2 : Normalize normal A1 A2 A3 B1 B2 B3 C-Model tid=A seq=1 tid=A seq=2 tid=A seq=3 tid=B seq=1 tid=B seq=2 tid=B seq=3 normal A1 A2 B1 A3 B2 B3 RTL 1010 01 1010 10 1011 01 1010 11 1011 10 1011 11 time

  21. Step 3 : Binning normal A1 A2 A3 B1 B2 B3 C-Model tid=A seq=1 tid=A seq=2 tid=A seq=3 tid=B seq=1 tid=B seq=2 tid=B seq=3 bin A1 A2 A3 B1 B2 B3 normal A1 A2 B1 A3 B2 B3 bin A1 A2 B1 A3 B2 B3 RTL 1010 01 1010 10 1011 01 1010 11 1011 10 1011 11

  22. Step 4: Accumulation • Binning may not be enough • Random Memory Access • don’t want to sort on every address • Different Algorithms • end result is same – checksum? • “Spaghetti” Perl scripts often evolve • We need to formalize the definition of interface traffic to compare two different models

  23. Transaction Assertions in YACC valid_interface_traffic: | valid_interface_traffic packet; packet: begin middle end; begin: BEGIN; middle: | middle MIDDLE; end: END

  24. Cycle Level Assertions in SVA clk cmd • sequence packet; (cmd==BEGIN) ##1 (cmd != BEGIN && cmd != END) [*0:$] ##1 cmd == END endsequence • a_well_formed_packet: assert @(posedge clk) cmd == BEGIN |-> sequence (packet) BEG END MID MID

  25. Transaction Level Assertions in SVA clk valid cmd • sequence packet; (cmd==BEGIN) ##1 (cmd != BEGIN && cmd != END) [*0:$] ##1 cmd == END endsequence MID MID BEG END

  26. Transaction Level Assertions in SVA clk valid busy cmd • event sample; • always @(posedge clk) if (valid && ! busy) -> sample • assert @(sample) cmd == BEGIN |-> sequence (packet) MIDDLE MID BEG END

  27. Transaction Level Assertions in SVA clk valid busy cmd • event sample; • always @(posedge clk) if (valid && ! busy) -> sample • assert @(sample) cmd == BEGIN |-> sequence (packet) MIDDLE MID BEG END

  28. The Structural Model • An Interface Definition Language • Define transactions/messages • Associate them with specific physical interfaces • Define connectivity of Modules • Use the definitions • RTL code generators • C-model code generators • Reuse the Definitions • Topology Changes • Implementation Protocols

  29. Towards an ESL Language • During its early years, evolved • from 500 line Perl script • to 6000 line monster • Decision time: • Throw it away (replace with SV?), or • Revamp it • Clean up language definition • Add first-class ESL features • Assertions • Testpoints

  30. Example Renderer Memory

  31. The Traffic group mem_write down U address 16 down U data 1 group sync down U shape 2 enum SQUARE, CIRCLE, TRIANGE, BLANK down U radius 3

  32. Accumulate Memory State group mem_write down U address 16 down U data 1 assign mem[ x = 0 .. 15 ][ y = 0 .. 15 ] = past( data :sample( address == {x,y} ))

  33. Add Predicates group_more mem_write assign is_circle[ r = 0..7 ] = “&&”( [ x = -8 .. 7 ] [ y = -8 .. 7 ] mem[ x+8 ][ y+8 ] == ( x**2 + y**2 <= r**2 ) )

  34. Define the interface interface render2memory clock mem_clk flow valid_busy packet sync, mem_write assert “correct sync shape” sync => sync.shape == CIRCLE => mem_write.is_circle[ sync.radius ] …

  35. Important concepts • Assertion Scoping • Assertion in group checked only when that group valid • “valid” signal • Packet id • Temporal Scoping • “past” function sampled only when its group is valid • Further qualified by “sample” property • Assertions must be true in All models • RTL • C Model • …

  36. Transaction Linkage across Interfaces Request Client Memory Response

  37. A link Assertion module memory equiv client_id 2 in mem_req map client_id = mem_req.src_id out mem_ack[ N=4 ] map client_id = N assert “every req has an ack” [ id = 0 .. 3 ] :enable( client_id == N ) link mem_req -> mem_ack[ id ]

  38. Equivalence Classes • How to identify transaction pairings • Need identifier that it common to each • Equivalence Classes module memory equiv client_id 2 in mem_req map client_id = mem_req.src_id out mem_ack[ N=4 ] map client_id = N

  39. More Interaction Concepts • a2b -> b2c // propagate • (a2x | b2x) -> x2y // merge • a2b -> (b2x | b2y) // branch • (a2x & b2x) -> x2y // join • a2b -> (b2x & b2y) // fork • :in_order( id ) • :thread( id )

  40. Summary • Architects should write assertions • Validated assertions are input to Verification • Assertions must be directly reusable across models • Manual recoding invites errors • Explicitly model the structure that is common to architectural models and to design • Tie assertions to these common points

  41. BACKUP

  42. Summary • Bridging abstractions requires defined traceability • ESL  RTL • ESL  C-Model • Use Transaction Abstraction for ESL • RTL and C-Model share a common shape • Transaction flow defines the equivalence class • Designer Freedoms are defined by ESL • This is a design activity • Verification “trusts” the ESL

  43. Multi-Cycle Interface : RTL traffic Module A Module B 34 1 1 1 0 0 0 key value key value - - 1 1 1 1 1 0 data data data data data - time

  44. Multi-Cycle Interface: structural view Module A Module B 34 struct a2b_iface { struct command { union { struct key { bit valid, bit [7:0] key }, struct value { bit more, bit [7:0] value } } struct datum { bit valid, bit [7:0] data } };

  45. Multi-Cycle Interface : grammar Module A Module B 34 seq command = <key> <value> where $1.valid attr more = $2.more seq commands = <command> ** [0,64] where all( $1[ 0..$-1 ].more ) && ! $1[$].more seq data = <datum> ** [0,128] where all( $1[*].valid ) seq a2b_info = <commands> & <data>

  46. Multi-Cycle Interface: C-model struct Module A Module B 34 struct A2B_info { map<int8,int8> commands; vector<int24> data; };

  47. Equivalence classes for transactions • Every implementation is a deformation of the ESL • RTL • C-Model • We want to know up front how we’ll compare them • Implementation-independent comprehension • “Races” in the transaction graph • are like “holes” in a topology • may be non-deterministic