Specman - Functional Verification - Lecture Slides, Slides of Computer Science

Download Specman - Functional Verification - Lecture Slides and more Slides Computer Science in PDF only on Docsity!

Specman Notes

Configuration

• On pitteda3 or pitteda

# Verisity user Environment variables (no newlines)

setenv SPECMAN_HOME

$CAD_DIR/verisity/specman_3.3.3/sn_rel3.3.

setenv PATH {SPECMAN_HOME}/${SPECMAN_HOME}/bin/sn_arch.sh:${SPECM AN_HOME}/bin:${PATH}

setenv SPECMAN_DIR $SPECMAN_HOME/${SPECMAN_HOME}/bin/sn_arch.sh

setenv VERISITYLD_LICENSE_FILE

[email protected]

Running

(make sure X and DISPLAY are right)

specview &

e language

• Looks like verilog to me…

• Has support for data types

– With statistical values

– With constraints (hard and soft)

• Stimulus

• Checking

• Events

File Format

• A code segment is enclosed with a begin-code marker <' and

an end-code marker '>.

• Both the begin-code and the end-code markers must be

placed at the beginning of a line (left most), with no other text

on that same line (no code and no comments).

• The following three lines of code form a code segment:

import cpu_test_env;

Several code segments can appear in one file. Each code

segment consists of one or more statements.

Comments

e files begin as a comment which ends when the first begin-code

marker <' is encountered.

Comments within code segments can be marked with double

dashes (--) or double slashes (//):

a = 5; -- This is an inline comment

b = 7; // This is also an inline comment

The end-code '> and the begin-code <' markers can be used in

the middle of code sections, to write several consecutive lines

of comment

Keywords

• all of
• all_values
• and
• as a
• as_a
• assert
• assume
• async
• attribute
• before
• bit
• bits
• bool
• break
• byte

bytes c export case change check that compute computed consume continue cover cross cvl call cvl callback cvl method cycle

default define delay detach do down to dut_error each edges else emit event exec expect extend

fail fall file first of for force from gen global hdl pathname if #ifdef #ifndef in index

Keywords

• int
• is a
• is also
• is c routine
• is empty
• is first
• is inline
• is instance
• is not a
• is not empty
• is only
• is undefined
• item
• keep
• keeping

key like line list of matching me nand new nor not not in now nxor on only

or others pass prev print range ranges release repeat return reverse rise routine select session

soft start state machine step struct string sync sys that then time to transition true try

Syntactic Elements

• Statements Statements are top-level constructs and are valid within the begin-code <' and end-code '> markers. Statements end with a semicolon ‘;’
• Struct members Struct members are second-level constructs and are valid only within a struct definition.
• Actions Actions are third-level constructs and are valid only when associated with a struct member, such as a method or an event.
• Expressions Expressions are lower-level constructs that can be used only within another e construct. The syntax hierarchy roughly corresponds to the level of indentation shown below: statements struct members actions expressions

Statements

• Statements are top-level constructs and are valid

within thebegin-code <' and end-code '> markers.

• Key Statement Types:

• Struct – defines a new data structure
• Type – defines an enumerated/subtype
• Extend – extends a previously defined struct or type
• Define – extends language with new commands, actions,

expressions

• More: import, verilog-x, vhdl-x …
• Order is not critical – but imports must be first (after

macro defines)

Struct Members

• field declaration
  • Defines a data entity that is a member of the enclosing struct and has an explicit data type.
• method declaration
  • Defines an operational procedure that can manipulate the fields of the enclosing struct and access run-time values in the DUT.
• subtype declaration
  • Defines an instance of the parent struct in which specific struct members have particular values or behavior. (e.g., when )
• constraint declaration
  • Influences the distribution of values generated for data entities and the order in which values are generated. (e.g., keep )
• cover age declaration
  • Defines functional test goals and collects data on how well the testing is meeting those goals.
• temporal declaration
  • Defines e event s and their associated actions.(e.g., on, expect, assume )

Fields

[!][%] fiel d: field-name[: typ e: type] [[ min-va l: int .. max-va l: int]]

[((bits | bytes): nu m: int)]

Syntax example:

type NetworkType: [IP=0x0800, ARP=0x8060] (bits: 16);

struct header {

address: uint (bits: 48);

hdr_type: NetworkType;

!counter: int;

Fields

• % Physical Fields
• A field defined as a physical field (with the “%” option) is packed when the

struct is packed.

• Fields that represent data that is to be sent to the HDL device in the

simulator or that are to be used for memories in the simulator or in

Specman Elite, need to be physical fields.

• Nonphysical fields are called virtual fields and are not packed

automatically when the struct is packed, although they can be packed

individually.

• If no range is specified, the width of the field is determined by the field’s

type. For a physical field, if the field’s type does not have a known width,

you must use the (bits | bytes : num) syntax to specify the width.

Actions

• Actions are third-level constructs and are valid only

when associated with a struct member, such as a

method or an event.

struct packet{

event xmit_ready is rise('top.ready');

on xmit_ready {transmit();};

transmit() is {

out("transmitting packet...");