Presenter: Chien-Chih Chen

1. National Sun Yat-sen University Embedded System LaboratoryFunctional Coverage Driven Test Generation for Validation ofPipelined Processors Presenter: Chien-Chih Chen PrabhatMishra, NikilDutt Proceedings of the Design, Automation and Test in Europe Conference and Exhibition (DATE’05)

2. Abstract Functional verification of microprocessors is one of the most complex and expensive tasks in the current system-on-chip design process. A significant bottleneck in the validation of such systems is the lack of a suitable functional coverage metric. This paper presents a functional coverage based test generation technique for pipelined architectures. The proposed methodology makes three important contributions. First, a general graph theoretic model is developed that can capture the structure and behavior (instruction-set) of a wide variety of pipelined processors. Second, we propose a functional fault model that is used to define the functional coverage for pipelined architectures. Finally, test generation procedures are presented that accept the graph model of the architecture as input and generate test programs to detect all the faults in the functional fault model. Our experimental results on two pipelined processor models demonstrate that the number of test programs generated by our approach to obtain a fault coverage is an order of magnitude less than those generated by traditional random or constrained random test generation techniques.

3. Related Works Techniques for generation of directed test programs [1], [4], [9], [11], [12] A tool that generates test program for verifying pipeline behavior in hazards and exceptions [8] Functional verification coverage measurement and analysis [2] A graph-based functional test program generation technique using model checking [10] Functional Coverage Driven Test Generation for Validation ofPipelined Processors

4. What’s the Problem ? • A lack of measurement for the functionality of processor • Ex: if all possible interactions of hazards, stalls and exceptions are tested in a processor pipeline • A large number of test programs • Using randomor constrained random test generation techniques

5. Functional Coverage • Functional coverage is the determination of how much functionality of the design has been exercised by the verification environment. • 100% functional coverage does not mean bug free design. It is one of the criteria for verification completion.

6. Graph Model • For the generation of test programs for validation of pipelined processors

7. Graph Model (Cont.) • Pipeline edge • Transfers operation (instruction) between two units • Data-transfer edge • Transfers data between unit and storage • Pipeline path • A path consists of units and pipeline edges • Ex: {Fetch, Decode, ALU, Write-Back} • Data-transfer path • A path consists of storages and data-transfer edges • Ex: {MemCntrl, L1, L2, Main Memory}

8. Fault Model for Register Read/Write • Faulty if reading of a register will not return the previously written value • VRi : A value written into register Ri and read back • The presence of a fault, output ≠VRi

9. Fault Model for Operation Execution • Faulty if the computation of operation is different from the expected output • An operation “opcodeidest, src1, src2, …” • The presence of a fault, dest ≠ fopcodei(src1, src2, …)

10. Fault Model for Execution Path • Faulty if it produces incorrect result during execution of operation • An operation which activates one pipeline path and one or more data-transfer paths • epopi(execution path for operation opi)= ppi∪DPopi • operation opi • Consists of one opcode (opcodei), m sources (src1, src2, …, srcm), n destinations (dest1, dest2, …, destn) • The presence of a fault, ∃k destk≠ fopcodei(src1, src2, …, srcm)

11. Fault Model for Pipeline Execution • Faulty it produces incorrect results due to execution of multiple operations in the pipeline • Stall set for unit u (SSu) • All possible ways to stall unit u • Exception set for unit u (ESu) • All possible ways causing exception in unit u • MESS: the set of all possible multiple exception scenarios • PIs= StallSet∪ExceptionSet • StallSet= ∪∀uSSu. • ExceptionSet= ∪∀uESu ∪MESS • A sequence of operations opspicauses a interaction pi(pi∈ PIs) • Exist a destination in opspiwill have incorrect value under a fault

12. Coverage Estimation • Register Read/Write • A fault is covered if the register is written first and read later. • Operation Execution • A fault is covered if the operation is performed, and the result of computation is read • Execution Path • A fault is covered if the execution path is activated, and the result of computation is read • Pipeline Execution • A fault if covered if the fault is activated due to execution of multiple operations, and the result of computation is read

13. Experimental Results • Environment setup • Verisity’sSpecman Elite [18] • The description of 91 instructions for the DLX using Verisity’s ‘e’ language • VLIW version of the DLX architecture using Verisity’s‘e’ language

14. VLIW DLX Architecture • Register read/write • 65 registers • 65 * 2 = 130 • Operation execution • 91 operations • 91 * 2 = 182 • Pipeline execution • 17 stalls due to structure hazard • 4 decode unit stalls due to data and control hazards • 4 stalls due to the children of decode unit • 16 stalls due to other units • 17 single exceptions • 136 multiple exceptions • 136*4 + 16*2 + 4*2 + 4*2 + 17*2 = 626

15. Conclusions • 3 Contributions • Graph model can capture the structure and behavior • The proposed functional fault models used in defining the functional coverage • The test generation procedures accept graph model as input and could detect all the faults in the functional fault model • Test sequences generated by the proposed algorithms to obtain a given functional coverage is less than the random or constrained-random test programs.

16. Comment • A concept of functional fault model definition for microprocessor functional verification