An Approach to Test Programs Generation for Microprocessors Based on Pipeline Hazards Templates Alexander Kamkin and Dmitry Vorobyev Institute for System Programming of RAS

SYRCoSE' June, 2010 Designing and Testing of microprocessors Cost of missed in the chip errors may be very high The most of errors occur in the functionality Verification efforts may reach to 80% of all designing efforts Testing is carried out at all design stages

SYRCoSE’ June, 2010 Control logic and pipeline Control logic is internal functionality responsible for controlling instructions executions Classic pipeline Instruction Fetch Instruction Decode Execute Memory Access WriteBack

SYRCoSE' June, 2010 Complex pipeline situations Clock cycle IF IDEXMAWB IDEXMAWB IDEXMAWB IDEXMAWB IDEXMAWB Instruction I1 I2 I3 I4 I5 Ideal Processing Pipeline processes without any idle

SYRCoSE' June, 2010 Complex pipeline situations Clock cycle IF IDEXMAWB IDEXMAWB IDEXMAWB IDEXMAWB Instruction I1 I2=ADD I3 I4=ADD I5 Structural Hazard The same unit is used in instructions IF IDEXMAWB

SYRCoSE' June, 2010 Complex pipeline situations Clock cycle IF IDEXMAWB IDEXMAWB IDEXMAWB IDEXMAWB IDEXMAWB Instruction I1 I2=ADD I3=SUB(Dep.) I4 I5 Data Hazard Data is used before it is available

SYRCoSE' June, 2010 Complex pipeline situations Clock cycle IF xIF xIDxEXxMAxWB IDEXMAWB IDEXMAWB IDEXMAWB xIDxEXxMAxWB Instruction I1 I2 I3=J I4 I5 Control hazard Branch instruction leads to jump

SYRCoSE' June, 2010 Complex pipeline situations Clock cycle IF xIF xIDxEXxMAxWB IDEXMAWB IDEXMAWB IDEXMAWB IDEXMAWB Instruction I1 I2 I3 I4=SB I5 Exception raises Exception raises when accessing to memory

SYRCoSE' June, 2010 Techniques of the control logic testing Cycle-accurate techniques  High testing coverage  Inexpediency/impossibility of use at early designing stages Template-based techniques  Coverage is unsystematic and difficult for evaluation  Can be used at the different stages

SYRCoSE' June, 2010 Techniques of the control logic testing Cycle-accurate techniques  High testing coverage  Inexpediency/impossibility of use at early designing stages Template-based techniques  Coverage is unsystematic and difficult for evaluation  Can be used at the different stages Our approach  Using of models gives systematic for coverage  Using of the generalized pipeline hazards templates that allows using at different stages Gap in designing process

Foundations of the approach (1) Approach uses formal specifications of microprocessor ISA Structure of the test program Test = { } i=0,n-1, Using test templates to represent test action instead of concrete test actions  Specifying formally test situations  Specifying formally dependencies SYRCoSE' June, 2010

SYRCoSE' June, 2010 Foundations of the approach (2) Test situations describe necessary parameters of testing component Dependencies between instructions  Register dependencies  Address dependencies Test program are generated automatically by combining test situations and test dependencies

SYRCoSE' June, 2010 The suggested approach Highlight “interesting situations” in pipeline functioning Produce generalized specifications (basic templates) for each type of hazard Define parameters for simple test actions Define parameters for composite test actions using operations over basic templates Generate tests using templates

SYRCoSE' June, 2010 Generalized Specifications of Hazards Generalized Templates Parametrized Generalized Templates

SYRCoSE' June, 2010 Generalized Specification of Exceptions $PreInstructions $PostInstructions

SYRCoSE' June, 2010 Generalized Specification of Exceptions $PreInstructions: {dadd} {TLBInvalid} $PostInstructions {daddiu} dadd r25, r30, r7 lb r22, 0(r4) // TLBInvalid=true daddiu r5, r18, How may Basic Template be translated to the test action?

SYRCoSE' June, 2010 Generalized Specification of Data Hazards $PreInstructions $FirstInstruction $InnerInstructions $PostInstructions

SYRCoSE' June, 2010 Generalized Specification of Data Hazards $PreInstructions: {} $FirstInstruction: {madd.s} $InnerInstructions: {add.s} {register: write-write} $PostInstructions: {div.s} madd.s $f18, $f6, $f28, $f10 add.s $f8, $f17, $f3 ceil.l.s $f2, $f18 // Data hazard div.s $f23, $f13, $f24 How may Basic Template be translated to the test action?

SYRCoSE' June, 2010 Test Program Generation Simple test actions  Basic templates of a single situation with parameters describes situation Composite test actions  Operations over Basic Templates define parameters for composite situations

SYRCoSE' June, 2010 Operations for Composite Test Actions Overlapping: T=T H1 |T H2 Shift: T H =T H1 ↓T H2 Concatenation: T=T1→T2 Nesting: T H =T H1 [T]

SYRCoSE' June, 2010 Example of the Operation Using overlapping operation for data hazard and structural hazard: $FirstInstruction1:{add.s, div.s} $FirstInstruction2:{mul.s, div.s} $FirstInstruction = $FirstInstruction1 ∩ $FirstInstruction2 $SecondInstruction = $SecondInstruction1 ∩ $SecondInstruction2 … div.s $f18, $f6, $f28, $f10 add.s $f8, $f17, $f3 div.d $f2, $f18 // Data hazard and Structural hazard div.s $f23, $f13, $f24

SYRCoSE' June, 2010 Case study The approach was applied to verification of two arithmetical coprocessors:  Floating point coprocessor  Complex arithmetic coprocessor

SYRCoSE' June, 2010 Future work Extend approach using accurate-cycled models

SYRCoSE' June, 2010 Thank You! Questions?