Traceability: From Transactions to RTL

1. Traceability: From Transactions to RTL Dave Whipp

2. Spice Switches Gates RTL ESL “System” Models volts, ohms, seconds ones, zeros, edges, loads cells clocks, cycles transactions: events, races clouds? Abstraction is not Sloppiness • To use multiple abstractions within a flow we need to know how each description maps to its neighbors

3. From Transactions to RTL • What features are invariant? • Interface Structures? • Interface Traffic? • Architectural State? • End Result?

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

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

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

7. Multi-Unit Assemblies cf2d d2be BE CF D be2cf a2be A cf2g G

8. Comparing “Shapes” A B C D E F G BE CF D A G How do we tell our tools that these are the same thing?

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

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

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

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

13. 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 interface traffic to compare two very different models

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

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

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

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

18. Transaction Assertions in Perl 6 grammar interface { rule valid_traffic { ^^ <packet>* $$ } rule packet { <begin> <middle>* <end> } }

19. ESL Shape A B C D E F G BE CF D A G Topology: defining invariants of shape

20. End-to-End flow definition assert “logical pipeline” chain a2b  b2c  c2d  d2e  e2f  f2g assert “physical pipeline” chain a2be  be2cf.b2c  cf2d  d2be  be2cf.e2f  cf2g

21. Local in-order Properties d2be • Every a2be must appear on be2cf • Every d2be must appear on be2cf • Every be2cf must be a result of a2be or d2be • Within a thread, transactions must remain in-order • threads may be reordered BE be2cf a2be

22. Transaction Interaction Algebra • a2b -> b2c // propagate • (a2x | b2x) -> x2y // merge • a2b -> (b2x | b2y) // branch • (a2x & b2x) -> x2y // join • a2b -> (b2x & b2y) // fork • a2b -> null // eat • null -> a2b // generate • (a2b | null) -> b2c // input must propagate • a2b -> ( b2c | null ) // output must propagate

23. Local in-order Properties d2be module BE equiv tid, thread in a2be in d2be out be2cf assert :out_of_order( thread ) :in_order( tag ) link ( a2be | d2be )  be2cf BE be2cf a2be

24. Local in-order Properties d2be module BE equiv tid, thread in a2be in d2be out be2cf assert :out_of_order( thread ) :in_order( tag ) link a2be  be2cf.b2c link d2be  be2cf.e2f BE be2cf a2be

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

26. BACKUP

27. Interface Grammar grammar bc_ef_iface { rule b2c { … } rule e2f { … } rule be2cf { <b2c> | <e2f> } } struct iface { field tag { enum B2C, E2F } field be2cf [ *tag ] }

28. RTL Verification • Compare Vs reference model • reference model may be “Executable Specification” • architectural state • interface traffic • Internal Assertions • no reference model needed • “design” assertions • “verification” assertions

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

30. 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 } };

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

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

33. Topology

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