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

Slides:



Advertisements
Similar presentations
Object Oriented Analysis And Design-IT0207 iiI Semester
Advertisements

Computer Architecture
Data Dependencies Describes the normal situation that the data that instructions use depend upon the data created by other instructions, or data is stored.
Computer Organization and Architecture
Chapter 2Test Specification Process. n Device Specification Sheet – Purpose n Design Specification – Determine functionality of design n Test List Generation.
The 8085 Microprocessor Architecture
1 Software Engineering Lecture 11 Software Testing.
Computer Organization and Architecture
1 Lecture-2 CSIT-120 Spring 2001 Revision of Lecture-1 Introducing Computer Architecture The FOUR Main Elements Fetch-Execute Cycle A Look Under the Hood.
1 Foundations of Software Design Lecture 3: How Computers Work Marti Hearst Fall 2002.
1 HW/SW Partitioning Embedded Systems Design. 2 Hardware/Software Codesign “Exploration of the system design space formed by combinations of hardware.
System-Level Verification –a Comparison of Approach Ray Turner Rapid Systems Prototyping, IEEE International Workshop on.
1 Lecture-2 CS-120 Fall 2000 Revision of Lecture-1 Introducing Computer Architecture The FOUR Main Elements Fetch-Execute Cycle A Look Under the Hood.
Principle of Functional Verification Chapter 1~3 Presenter : Fu-Ching Yang.
Pipelining By Toan Nguyen.
Group 5 Alain J. Percial Paula A. Ortiz Francis X. Ruiz.
SDR Test bench Architecture WINLAB – Rutgers University Date : October Authors : Prasanthi Maddala,
CS4311 Spring 2011 Unit Testing Dr. Guoqiang Hu Department of Computer Science UTEP.
Introduction CS 3358 Data Structures. What is Computer Science? Computer Science is the study of algorithms, including their  Formal and mathematical.
Testing Basics of Testing Presented by: Vijay.C.G – Glister Tech.
Introduction CS 3358 Data Structures. What is Computer Science? Computer Science is the study of algorithms, including their  Formal and mathematical.
Developing software and hardware in parallel Vladimir Rubanov ISP RAS.
Processor Architecture
ALU (Continued) Computer Architecture (Fall 2006).
IT3002 Computer Architecture
2016/2/ “Formal verification of a public-domain DDR2 controller design”, VLSI Design Author: Abhishek Datta, Vigyan Singhal Speaker: Chia-Wei.
 Software Testing Software Testing  Characteristics of Testable Software Characteristics of Testable Software  A Testing Life Cycle A Testing Life.
Lab 4 HW/SW Compression and Decompression of Captured Image
Software Testing.
Coupling and Cohesion Rajni Bhalla.
4.
The 8085 Microprocessor Architecture
Computing Systems Organization
William Stallings Computer Organization and Architecture 8th Edition
Quality Assurance: Early Work Items
Multilevel Memories (Improving performance using alittle “cash”)
The 8085 Microprocessor Architecture
Introduction of microprocessor
William Stallings Computer Organization and Architecture 7th Edition
Object oriented system development life cycle
Cache Memory Presentation I
Chapter 15 Control Unit Operation
An Introduction to Microprocessor Architecture using intel 8085 as a classic processor
Yogesh Mahajan, Sharad Malik Princeton University
Software Development Cycle
Drinking from the Firehose Decode in the Mill™ CPU Architecture
Introduction to cosynthesis Rabi Mahapatra CSCE617
Superscalar Processors & VLIW Processors
Lecture 09:Software Testing
Programming Fundamentals (750113) Ch1. Problem Solving
Static Testing Static testing refers to testing that takes place without Execution - examining and reviewing it. Dynamic Testing Dynamic testing is what.
William Stallings Computer Organization and Architecture 7th Edition
Chapter 5: Computer Systems Organization
* From AMD 1996 Publication #18522 Revision E
Test Case Test case Describes an input Description and an expected output Description. Test case ID Section 1: Before execution Section 2: After execution.
L9 - Verification Strategies
The 8085 Microprocessor Architecture
Computer Architecture
A Trusted Safety Verifier for Process Controller Code
Delivery, Forwarding, and Routing of IP Packets
Control unit extension for data hazards
Understanding the TigerSHARC ALU pipeline
Control unit extension for data hazards
Software Development Cycle
Chapter 11 Processor Structure and function
COMPUTER ORGANIZATION AND ARCHITECTURE
The Programmable Peripheral Interface (8255A)
Presentation transcript:

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