Towards RTL Test Generation from System C TLM

Towards RTL Test Generation from System. C TLM Specifications Mingsong Chen, Prabhat Mishra Computer & Information Science & Engineering University of Florida, USA Dhrubajyoti Kalita Intel Corporation Folsom, CA, USA

Outline l Introduction l Related Work l RTL Test Generation using TLM-level Specification l Case Study l Conclusion 2

Motivation l So. C complexity and time-to-market constraint requires design at higher level of abstraction. l System. C TLM (transaction-level modeling) based design methodologies reduce the cost of design and validation. u Very promising for early exploration, hardware- software co-design, and platform-based design and verification. l Limitations of current approaches. u The presence of multiple design levels raises an important question Ø How to maintain consistency between so many abstraction levels? u The amount of reuse between levels is limited Ø How to use TLM level tests for RTL level validation? 3

Related Work l Existing approaches can be broadly classified into three categories u Validation of TLM models using test generation. u Validation of TLM models using assertions. u Reuse of TLM-level assertions and testbenches for RTL validation. l The existing approaches cannot fully reuse the TLM level validation effort due to lack of: u A golden reference model, a comprehensive coverage metric, and an automatic method to translate TLM level tests to RTL level. 4

A Top-Down Framework SOC Specification Verify TLM (System. C TLM) Properties Formal Model (Transition Coverage) (CPN Representation) Test Generation Verify Specification Test Translation Three important steps 1. Formal Representation of TLM Specification - Colored Petri-net 2. Coverage Based TLM Testcase Generation - Transition Coverage 3. Translation of TLM Tests into RTL Rests Using Rules - Initialization, Reset, Name & Expression, Delay, … Implementation (RTL) 5

Outline l Introduction l Related Work l RTL Test Generation using TLM-level Specification u Formal Modeling of TLM Specifications u TLM-level Test Generation u Translation of TLM tests into RTL tests l Case Study l Conclusion 6

Petri-Nets 7

Petri-Nets 8

Petri-Nets 9

Conflict in Petri-Nets 10

Colored Petri-Net (CPN) l An extension of Petri-net which allows the use of tokens to carry data values. u CPN integrate the control description and data manipulation u CPN offers hierarchical description. u CPN can be extended with a time concept. l Three System. C constructs modeled by CPN Statement i Condition 2 Condition 1 Statement i+1 Condition 2 Condition 1 Statement i+1 Sequence Statement i+1 Selection Statement i+2 Iteration 11

TLM to CPN Transformation Steps l Mapping: Identified the CPN representation for each TLM construct. u The constructs include modules, channels, functions, statements etc. l Composition: A complex TLM specification is partitioned into simple constructs and the corresponding CPN representations are composed to produce the final CPN model. u A design consists of modules, channels and transactions. u Each module contains several statements. u Each statement may consist of simple ones 12

CPN model: ‘for’ Statement 13

TLM Test Generation l Model checking is used to enable directed test generation based on transition coverage. u Generate the model of the design (from CPN) u Generate one property for each transition u Apply the design and the negated property to the model checker that produces a counter example Ø Convert the counter-example into a TLM level test Decode never stalled An Example Generate test to stall a Decode unit Processor Model Checker Opcode Dest Src 1 Src 2 NOP ADD R 3 R 1 R 2 SUB R 4 R 3 R 2 14

Rule-based Transformation l Requires knowledge of RTL I/O constraints l Converts abstract TLM-level tests to RTL tests u TLM tests may or may not have notion of time Ø Causal dependencies are converted into time steps Ø Appropriate delays must be inserted between steps. u TLM tests do not have any reset Ø A template for ‘reset sequence’ is added u Name (or expression) conversion Ø For example, “pkt to_chan” should be “data[0: 1]” l One set of rules is required for a design u In practice, may need one set of rules for each cluster of similar tests. 15

Outline l Introduction l Related Work l RTL Test Generation using TLM-level Specification u Formal Modeling of TLM Specifications u TLM-level Test Generation u Translation of TLM tests into RTL tests l Case Study l Conclusion 16

A Case Study l Applied our methodology on various TLM designs including a router. l We use the router example in our case study. u TLM specification of the router u CPN model of the router u Test generation based on transition coverage Ø Used SMV model checker Ø Challenges in test generation u Rule-based transformation of TLM-level tests u Validation of router RTL implementation Ø Errors in RTL implementation Ø Quality of the generated tests 17

TLM Architecture of the Router The specification consists of 8 files, 400 lines of code, 9 functions, 5 classes. 18

CPN Model of the Router // Packet description in TLM Class Packet { public: sc_unit<2> to_chan; sc_unit<6> payload_sz; sc_unit<8> payload[63]; sc_unit<8> parity; }; 19

Test Generation based on Transition Coverage l The list of transitions and their actions Transitions Description t 1 input. peek(). to_chan t 2 Calculate packet_time, rcv_delay_time and packet_gap_time t 3 fork t 4 receive_complete_event. notify(packet_time + packet_gap_time, SC_NS); t 5 transmit_complete_event. notify(packet_time + rcv_delay_time, SC_NS) t 6 input. nb_get(tmp_packet) t 7 join t 8, t 9, t 10, t 11 chan. X. nb_put(tmp_packet); slave. X. get_packet. ok_to_get(); X=0, 1, 2, 3 l For each transition generate one property Property for ‘t 9’: assert G((pkt. to_chan = 1) F(slave 1. received. Pkt = pkt)) u Negated version: assert F((pkt. to_chan = 1) & G (slave 1. received. Pkt ~= pkt)) u l Apply negated property to the router model using SMV u Generated counterexample can be converted into a test Ø P to_chan=1; P payload_sz=1; P payload[0]=1; P parity = 5; 20

RTL Design of the Router data channel 0 vld_chan_0 read_enb_0 packet_valid err suspend clock DUT 7 6 5 4 3 2 1 0 channel 1 vld_chan_1 read_enb_1 channel 2 vld_chan_2 read_enb_2 Input/Output Specification length addr Header data[N] P A Y L O A D parity Parity data[0] data[1] ……. Packet Structure 21

Rule-based Transformation l The following transformations are used u Add initialization read_enb_0 = 0; read_enb_1 = 0; read_enb_2 = 0; packet_valid = 0; u Add reset sequence reset = 0; #5 reset = 1; #20 reset = 0; u Add packet_valid assignments u Add delays of #10 (clock period) for each step Ø Initial one requires half clock period (align on falling edge) Ø Last one requires n clocks, n is the number of data items u Perform transformation of name/expressions 22

Transformation of a TLM Test RTL Testcase read_enb_0 = 0; read_enb_1 = 0; read_enb_2 = 0; packet_valid = 0; TLM Testcase p->to_chan=1; p->payload_sz=2; p->payload[0]=1; p->payload[1]=2; p->parity=10; Data Composition reset = 0; #5 reset = 1; #20 reset = 0; #5 packet_valid = 1; data = 8'b 00001001; #10 data = 8'b 00000010; #10 packet_valid = 0; data= 8'b 00001010; #10 read_enb_1=1; #40 read_enb_1=0; $finish; Initialization Reset Sequence Use of half clock Name Transformation Use of four clocks 23

Results l Generated 11 testcases u 9 based on transition coverage, 1 overflow and 1 asynchronous read test. u Found two errors and one inconsistency Ø If queue is empty and read signal is enabled, queue becomes full Ø If destination channel is 3 (which does not exist), the packet is sent to channel 0. Ø The overflow in TLM level is 16 packets whereas the overflow in RTL level is 16 bytes. l RTL coverage u Source (statement) coverage – 99. 4% Ø Unreachable code that handles channel 3. u Path coverage – 66. 7% u Condition coverage – 85. 1% Ø Condition for some if statements (with missing else) is always true v e. g. , addr_vld, data_out_vld etc. are false only during initialization. u FSM (both state and transition) coverage – 100% u Toggle coverage – 100% 24

Conclusion l Presented a top-down RTL test generation approach using TLM-level specification u Formal modeling of TLM specification u Automated TLM test generation u Conversion of TLM tests into RTL tests l Advantages u The validation effort can be reused. u The RTL tests can be ready before the RTL implementation. l Future works u Apply on large examples 25

Questions ? Thank you! 26