Kazi ECE 6811

ECE 681ECE 681VLSI Design VLSI Design AutomationAutomationKhurram Kazi*Khurram Kazi*

Lecture 9Lecture 9

Thanks to Automation press Thanks to Automation press THE button outcomes the THE button outcomes the Chip !!! Reality or MythChip !!! Reality or Myth

*(lecture material was also provided by Omid Roshan-Afshar)*(lecture material was also provided by Omid Roshan-Afshar)

Kazi ECE 681 2

Traditional way of verifying Traditional way of verifying complex ASICs poses limitationscomplex ASICs poses limitations

• Using HDL based testbenches to fully verify the functionality of the ASIC require a great deal of effort and TIME in developing test cases

• This in turn challenges and questions the productivity and quality of the verification efforts

• This method requires selection of numerous parameters manually to cover most of the test cases

Kazi ECE 681 3

Productivity IssueProductivity Issue

• Writing and maintaining HDL based verification testbenches and directed tests (100s of test cases) has become quite tedious

• 10s of thousands line of verification code need to be developed to ensure a high level of confidence in the correctness of the design

• Specification changes have a high toll on verification efforts

• This all translates into delay in schedules

Kazi ECE 681 4

What are the requirements imposed on What are the requirements imposed on improving verification effortsimproving verification efforts

• Test development must be easy to write

• The verification environment must be created and maintained efficiently

• Automation can achieved in verifying what has been tested

• Should be able to write tests for unidentifiable boundary conditions

Kazi ECE 681 5

Specman Elite Verification Specman Elite Verification System**System**

• Easily capture your design specifications to set up an accurate and appropriate verification environment

• Quickly and effectively create as many tests as you need

• Create self-checking modules that include protocols checking

• Accurately identify when your verification cycle is complete

** Taken from Verisity’s SpecElite Tutorial

Kazi ECE 681 6

Three enabling technologies that can Three enabling technologies that can drastically improve productivity**drastically improve productivity**

• Constraint-driven test generation — you control automatic test generation by capturing constraints from the interface specifications and the functional test plan. Capturing the constraints is easy and straightforward.

• Data and temporal checking — you can quickly create self-checking modules that ensure data correctness and temporal conformance. For data checking you can use a reference model or a rule-based approach.

• Functional coverage analysis — because you can measure the progress of your verification effort against a functional test plan, you avoid creating redundant tests that waste simulation cycles.

Kazi ECE 681 7

Depiction of Design Depiction of Design Verification Environment** Verification Environment**

Kazi ECE 681 8

Steps taken in implementing Steps taken in implementing Verification platformVerification platform

• Data Abstraction• Driving and Sampling the DUT• Generating Constraint-Driven Tests• Defining coverage points• Writing corner case tests• Data and temporal checks

Kazi ECE 681 9

Basic Syntax of Basic Syntax of ee

Purpose Syntax

Code delimitation <‘‘>

Inline comments -- VHDL Style// Verilog Style

Cod block {… ; …. ; …. ; };

Names . Start with letter. Include any letters, numbers and underscore

Hierarchy path (between structs and their members)

. (dot)

Kazi ECE 681 10

Basic Syntax of Basic Syntax of ee

struct my_struct {

};

The e language is case-sensitive

•Both for predefined syntax keywords and user-defined names.

struct is keywrod. All syntax keywords are lower case

struct MY_STRUCT {

};The name my_struct is different than name MY_STRUCT

Kazi ECE 681 11

Basic Syntax of Basic Syntax of ee

This is comment

<‘

Code starts here

‘>

This is comment also

<‘

Additional e code

‘>

All e code must be between the code delimiters.

Everything else is viewed as comments by Specman

Must be the first character on the line

Kazi ECE 681 12

Syntax HierarchySyntax Hierarchy<‘

struct transaction {

address : unit (bits: 16);

data: byte;

print_addr_zero() is {

if (address == 0) then {

print address;

address = address + 1;

};

};

};

‘>

Statements

Struct members

Actions

Expression

Name Literals (in dark blue)

Kazi ECE 681 13

Specman Elite’s Predefined Scalar Types

•Type Name Function Default Size for Packing Default Value

•int Represents numeric data, both negative

and non-negative integers. 32 bits 0

•uint Represents unsigned numeric data,

non-negative integers only. 32 bits 0

•bit An unsigned integer in the range 0–1. 1 bit 0

•byte An unsigned integer in the range 0–255. 8 bits 0

•time An integer in the range 0–263-1. 64 bits 0

•bool Represents truth (logical) values,

TRUE(1) and FALSE (0), 1 bit FALSE (0)

•String String of ASCII characters

•List Resizable, ordered array

Kazi ECE 681 14

Example of sample Code for Example of sample Code for SONET applicationsSONET applications

Omid Roshan-Afshar will be covering details of e by going over sample test generation e code for SONET.

We will have a hands on demo lab on Saturday Oct 26, at 10:30 A.M

Try to use his sample provided code and hook it up to your SONET framer