Levels of Verification Figure 2.2 p 37 Verification is applied at all different abstraction levels Mostly bottom up, some top down

Designer/Unit Levels Designer Level Unit Level Small enough for a single designer Interfaces are changing frequently May use formal verification Intermediate complexity, many design blocks Interfaces more stable, may be standardized Functions should be contained inside units

Core/Chip Levels Core Level Chip Level Similar to Unit level but designed for reuse Testing and spec requirements are strict Testing process must be demonstrably solid Whole chip, large verification task Fixed interfaces, often standardized

Board and Coverification Levels Board/System Level Hardware/Software Coverification Level Many chips (ASIC, FPGA, Processor) plus software Focus on interactions, assume components are tested Concentrate on interaction between HW/SW Operating system is an issue Overlaps with board/system level

Strategy of Verification Two goals: 1.Drive the inputs with all “interesting” scenarios 2.Detect (and locate) failures Two places to get information from: 1.Outside the design (Black Box) - specification, architecture, standards 2. Inside the design (White Box) - microarchitecture, HDL code

Driving the Black Box Determine scenarios from specification features

Extracting Internal Information 1.There is a stack inside 2.The stack is at least two deep 3.The stack is 8 bits wide 4.Only one entry can be written at a time Design information which we can derive from the spec

Open Design Questions Unspecified details should be listed to direct testing Guess what the designer might have done 1.How deep is the stack? 2.What conditions indicate a full stack? 3.When do the contents become valid? 4.What if read and write happen on same cycle? 5.How long does it take to reset the stack? 6.Do entries get zeroed-out or just marked invalid? 7.What if a read occurs on an empty stack? Make tests to explore these questions

Scenarios based on Questions 1.Writing and not writing 2.All three possible reads 3.Writing and reading at the same time 4.Reading when the stack is empty 5.Writing when the stack is full 6.Read and reset stack together 7.Write and reset stack together 8.Temporal cases - double writes, double reads, etc.

Checking Strategies Four sources of checking data: 1.The inputs and outputs of the design (Black Box) 2.The context of the design (Black/White Box) 3.The microarchitecture rules (White Box) 4.The architecture (Black Box) Need to automate the process of checking results

Input/Output based Checkers Write code to generate the expected outputs based on the inputs as described in spec (reference model) - Reference results are compared to design Reference model must be limited - Not cycle accurate (i.e. timing is not modeled) - Might be only accurate at sample points (i.e. once operation is out of the pipeline) - Might omit tricky features (i.e. skip some addressing modes)

Checkers based on Context The whole design is an instruction decode unit HDL A parses incoming stream into individual instructions HDL B groups instructions to feed to superscalar pipeline “Context” of HDL A, B is known HDL A should catch invalid opcodes, not pass to B HDL B should send instructions only to appropriate pipelines (I.e. no floating pt to fixed pt pipeline)

Microarchitecture Checkers Generate tests to stress the internal components of the design (i.e. if there is a stack, fill it up) Possibilities include: 1.Invalid states/transitions 2.Overrun or underrun in buffers 3.Bad control signal timing 4.Invalid data

Microarchitecture Example Want to check that forwarding paths are correct Microarch Property: RAW hazards should not occur