Advanced Specman Ovm

SPECMAN ELITETM

Basic Training Labs

Version 5.2

Legal Notice

Copyright © 2001-2003 Verisity Design, Inc. All rights reserved.

Trademarks

Verisity, the Verisity logo, eAnalyzer, eCelerator, eRM, Invisible Specman, LicenseE, Pure IP,

Specman, Specman Elite, SureCov, Verification Advisor, Verification Alliance, and

Verification Vault are either trademarks or registered trademarks of Verisity Design, Inc. in the

United States and/or other jurisdictions. All other trademarks are the exclusive property of their

respective owners.

Confidentiality Notice

The contents of this document constitute valuable proprietary and confidential property of

Verisity Design, Inc. No part of this information product may be reproduced, transmitted, or

translated in any form or by any means, electronic, mechanical, manual, optical, or otherwise

without prior written permission from Verisity Design, Inc.

Information in this product is subject to change without notice and does not represent a

commitment on the part of Verisity. The information contained herein is the proprietary and

confidential information of Verisity or its licensors, and is supplied subject to, and may be used

only by Verisity’s customers in accordance with, a written agreement between Verisity and its

customers. Except as may be explicitly set forth in such agreement, Verisity does not make, and

expressly disclaims, any representations or warranties as to the completeness, accuracy, or

usefulness of the information contained in this document. Verisity does not warrant that use of

such information will not infringe any third party rights, nor does Verisity assume any liability

for damages or costs of any kind that may result from use of such information.

Restricted Rights Legend

Use, duplication, or disclosure by the Government is subject to restrictions as set forth in

subparagraphs (c)(1)(ii) of the Rights in Technical Data and Computer Software clause at

DFARS 252.227-7013.

Destination Control Statement

All technical data contained in this product is subject to the export control laws of the United

States of America. Disclosure to nationals of other countries contrary to United States law is

prohibited. It is the reader’s responsibility to determine the applicable regulations and to

comply with them.

Contents

Specman Elite Basic Training Labs i

Lab 1 Opening Specview and Using the Online Help . . . . . . . . . . . 1

Lab 2 Using Specman Elite Commands . . . . . . . . . . . . . . . . . . . . . 5

Lab 3 Structs, Lists, and Methods . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Lab 4 Generation and Constraints . . . . . . . . . . . . . . . . . . . . . . . . 13

Lab 5 Extending the Verification Environment . . . . . . . . . . . . . . . 17

Lab 6 when Inheritance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Lab 7 Using extend for Writing Tests . . . . . . . . . . . . . . . . . . . . . . 21

Lab 8 Events, TCMs, and Units. . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Lab 9 Running Specman Elite with a Simulator . . . . . . . . . . . . . . 27

Lab 10 On-the-Fly Generation and Packing . . . . . . . . . . . . . . . . . . 31

Lab 11 Collecting Output Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Lab 12 Scoreboard Data Checking . . . . . . . . . . . . . . . . . . . . . . . . . 35

Lab 13 Temporal Events and Checking . . . . . . . . . . . . . . . . . . . . . 37

Lab 14 Stimulus and State Machine Coverage . . . . . . . . . . . . . . . . 39

Lab 15 Adding More Coverage and Writing Tests . . . . . . . . . . . . . 43

Specman Elite Basic Training Labs 1

Lab 1 Opening Specview and Usingthe Online Help

Lab Overview

Specview is the graphical user interface of Specman Elite. Generally, it is the most convenient

way to run Specman Elite.

From specview, you can access the online help. Using the online help can greatly reduce the

time required to become efficient in writing e.

Included in the online help are:

After completing this lab, you will be able to:

• Launch specview.

• Use the online help, including the Verification Advisor.

Specman Elite

e Language Reference

Detailed information on the e programming language used

to model parts of the test environment and to create tests

Specman Elite Command

Reference

Detailed information about the commands you can use to

control the Specman Elite tool

Specman Elite Usage and

Concepts Guide

Detailed information about using the Specman Elite tool

and integrating the Specman Elite system with other

software tools or C models

Specman Elite

Generation Guide

Detailed information about the Specman Elite generator

and how to use it

Specman Elite Release

Notes

Release notes for the current version of Specman Elite

Installation Guide Installation guide for the current version of Specman Elite

eReuse Methodology

(eRM)

Detailed information about maximizing reusability of

verification code written in e.

Verification Advisor Recommended verification methodology

Index Index for all of the above except the Verification Advisor,

which has its own separate index

2 Specman Elite Basic Training Labs

Lab 1 Opening Specview and Using the Online Help

Lab Instructions

Your working directory for lab 1 is sbt_lib/sbt_lab01/e.

1. Change directory to sbt_lib/sbt_lab01/e.

2. Launch specview by typing the command:

specview &

specview opens.

Figure 1-1 Specview Main Window

Note You can start Specman Elite in two ways:

• GUI mode – Executable is specview

• ASCII mode – Executable is specman

3. In specview, click the “help” button to display the online help, including the Verification

Advisor.

There are three tabs on the left frame of the help browser:

• Contents– Includes Search and Browsing Tips, Specman Elite Manuals, e Reuse

Methodology (eRM), and the Verification Advisor.

• Index– Includes a full index.

• Search– Includes a Search Engine.


Opening Specview and Using the Online Help Lab 1

4. Click the Search tab, type the following keywords, and click Go to perform a search:

struct statement syntax

The search results appear in the left frame.

Note By adding the word syntax, we narrowed the search to syntax definitions only.

Without the word syntax, you get many more matches.

Specman> help <keywords>

Note You can also access the documentation on Verisity’s website Verification Vault.

5. Select Defining Structs by clicking on the hyperlink.

In the right frame of the help browser, the associated document is displayed. In our

example, we see Section 4.2.1 “struct” in the e Language Reference.

6. Repeat steps 3 and 4 above, using keywords of your own choice.

Tip It is a good idea to leave the help window open so that you can quickly search for

commands, syntax, or methodology as needed.

7. Exit specview (File > Quit).



Lab 2 Using Specman Elite Commands

Lab Overview

Specman Elite automates many of the common tasks involved in building a verification

environment and a test base. This includes writing tests, checking stimulus and timing

protocols, and collecting functional test metrics. This lab introduces the Specman Elite

commands that you can use.


• Use Specman Elite commands at the Specman prompt.

Lab Instructions

Your working directory is sbt_lib/sbt_lab02/e. The arrangement of files and subdirectories

follows the eRM, the e Reuse Methodology. eRM is the recommended methodology for any

development using the e language and Specman Elite. Details of the eRM will be introduced

slowly as side topics in this course.

eRM organizes the code for Specman verification environments into packages and group

packages within libraries. For the basic training course, each lab is a package, e.g. sbt_lab2.

sbt_lib is a library that contains all the labs of the course as packages. eRM requires that each

library contain a LIBRARY_README.txt file, and each package contain a

PACKAGE_README.txt file. At your leisure look at the examples of each of these files in

basic training library.

The directory $SPECMAN_HOME/erm_lib contains many packages illustrating eRM, and is a

library itself. We describe eRM in greater detail in the Advanced Specman Elite Training

Course.

1. Launch specview by typing the command:

specview &

2. In specview, click the Config button .

The Specman Elite Configuration Options window appears.

Note You can configure the various tools and features of Specman Elite on the tabs of the

Specman Elite Configuration Options window.


Lab 2 Using Specman Elite Commands

3. On the Print tab of the Specman Elite Configuration Options window, change the radix for

integer values to HEX and click Apply.

Note For every command executed through specview’s graphical interface, there is an

associated Specman Elite command that can be entered at the Specman> prompt in the

main specview window.

Note You can tell when Specman Elite is ready to receive a new command by the state of

the Ready/Busy status bar in the lower right corner of the main specview window (See the

figure on page 2).

4. At the Specman> prompt in the main specview window, type the following command and

press Enter:

Specman> config print -radix=hex

5. Click the Load button to load an e file.

The Select a File dialog box appears.

6. Select the file template.e and click OK.

7. Click the Reload button to restore Specman Elite and load the same e file again.

Note Reload is normally used after changes to an e file.

8. Click the Restore button to restore Specman to its original state.

9. In the help browser, click on Specman Elite Manuals ->Command Reference and examine

the Specman Elite commands available to you.

Tip Specman Elite commands can be grouped together in a command file (.ecom).

Executing the command file executes in sequence all of the commands contained

within it.

10. Create a file called init.ecom and add the following three lines:

restore;config print -radix=hex;load template.e;

Tip When you use files with a recognized .e* extension (.e, .ecom, .esv, .ecov), you do not

need to add the extension when specifying the file name. In the last line of this sample

init.ecom file, you could also write:

load template;


Using Specman Elite Commands Lab 2

11. Execute init.ecom from the Specman> prompt by preceding it with the @ symbol.

Specman> @init

12. Exit specview.



Lab 3 Structs, Lists, and Methods

Lab Overview

To define data elements we use structs.

• A struct can have fields and methods and other members that will be introduced in later units.

• An e method is an operational procedure containing actions.

• A method can have parameters, local variables, and a return value.

• You can define a method only within a struct, and you must create an instance of the struct

before you can execute the method.

• When a method is executed, it can manipulate the fields of the struct in which it is currently

located and the fields of any other struct using hierarchical referencing.

• Predefined test-phase methods can be extended to call methods in different phases of the

test.

• The top-level struct in Specman Elite is named sys. Your verification environment must be

instantiated as a tree under sys, and it is pregenerated when you issue the Specman Elite

test command.


• Create structs

• Create lists

• Create and execute methods

Lab Instructions

Your working directory is sbt_lib/sbt_lab03/e.

1. Open the existing e file called sbt_packet.e and create a struct sbt_packet_s according to

the SBT Spec.

2. Add all required fields to the struct.

3. Create a method that will calculate the correct parity according to the SBT Spec.

Tip You may need to search the online help for bit concatenation.

To execute the method, it should be called from the predefined post_generate() test-phase

method:


Lab 3 Structs, Lists, and Methods

post_generate() is also {<Call the parity calculation method>};

4. Open the sbt_env.e file and add to sys a field that is a list of sbt_packet_s. eRM

recommends separation of an object’s definition from its instance in a file such as sbt_env.e.

Note Make sure you import your sbt_packet.e file first.

5. In specview, click Load and load your sbt_env.e file.

6. Read and correct the syntax errors. Continue using the specview Reload button until you

load your e code successfully.

7. Click the Modules button to view the currently loaded modules.

8. Click the Test button to start the generator.

9. From the Specman> prompt, print your list of packets:

Specman> print sys.packet-list-name

10. Click the Sys button to view all generated data in sys.

11. Click the blue hyperlink to bring up a window showing your list of packets. Clicking on the

+ symbols in the Data content window will expand the hierarchy.

12. On the specview Test menu , choose Test with Random Seed.

This generates a new random list of packets.

Note Because you started the generator with two different random seeds, the lists are

different.

13. Coverage is a useful tool for concisely displaying information about the generated packets.

The course discusses coverage in detail later. Nevertheless, one would use coverage when

developing a data object. Add the following code into your sbt_packet_s definition. Use the

names for address, length and parity that you used.

event packet_gen;cover packet_gen is {

item addr;item len;item parity;

};


Structs, Lists, and Methods Lab 3

14. Add the following code to the post_generate method after the parity calculation:

emit packet_gen;

15. Reload the environment, click on the test button, and click on the coverage button. This

opens the coverage browser. In the left frame, expand sbt_packet_s.packet_gen. If you click

on addr, len, or data, you will see the range of values for each that were generated. You will

expand and refine this coverage in later labs.

16. Exit specview.

I



Lab 4 Generation and Constraints

Lab Overview

Generation of fields is guided by constraints that you place on the fields.

Constraints are rules that the Specman Elite generator must obey when randomly generating

fields. You can use constraints to:

• Prevent particular conditions from occurring.

• Ensure that specific legal or illegal values are generated.

• Drive the generator toward DUT corner cases.

• Distribute values over a generated item’s range.


• Use the Specman Elite random generator.

• Create constraints to control the generator to create input data.

• Do basic debugging of constraints.

• Use different seeds to create different test scenarios.

Lab Instructions

Your working directory is sbt_lib/sbt_lab04.

1. Change directory to sbt_lib/sbt_lab04, and close any open specview windows.

2. Constrain the size of the data payload list of byte to be equal to the length field.

Tip Use a sized list rather than a constraint.

3. Create a control field called payload_size that can take on a value of SMALL, MEDIUM,

or LARGE.

Note This requires creation of a new enumerated type.

Tip Keep in mind that the default generation order of fields is from top to bottom of the

struct.

Tip When a type is always to be used with a specific struct, it is good coding practice to

keep the type in the same file as that struct. For enumerated types that are not

associated with a particular struct and that are used widely in an environment, create a

separate file, for example sbt_types.e, to contain them.


Lab 4 Generation and Constraints

4. Add a constraint that causes the length field to be based on the value of your new field as

follows:

SMALL: [1..20]MEDIUM: [21..44]LARGE: [45..63]

Tip Make sure that payload_size field is generated before the length field.

5. Add a constraint that takes into account that the SBT has only three port addresses (equal

to 0, 1, and 2).

6. Add a soft constraint to sys in the sbt_env.e file to keep the number of packets in the list

in the range from 10 to 50.

7. Load the sbt_env.e file and generate the list of packets using the test command.

8. To debug your constraints, issue the following command:

Specman> show constraints sbt_packet_s.*

9. Look at the generated packets in sys and make sure that the packets are generated according

to your constraints.

10. Run another test with a new seed:

a. On the specview Test menu, choose Test with Random Seed.

b. Click Sys to display the new list.

The two lists should be random and different but obeying your constraints.

If time permits:

1. Add an 8-bit UID (unique identification) field uid to the sbt_packet.

2. Constrain the payload data so that the first byte always equals the UID.

Tip Make sure that the uid field is generated before the payload data.

3. Reload the sbt_env.e file.

4. Issue the test command to generate the list of packets.

5. Click Sys and examine the generated packets. Make sure that the first byte of the payload

data equals the UID.

6. Add an additional coverage item to the packet_cov coverage group:

item payload_size;


Generation and Constraints Lab 4

7. Reload and click on test. Review the packet coverage by clicking on the coverage gui

button.

8. Exit specview.



Lab 5 Extending the Verification Environment

Lab Overview

We want to give test writers a good interface to the verification environment. Ideally, they

should simply apply constraints to control fields (or knobs) to cause specific behavior. Toward

this end, we add a field to control the generation of valid and invalid parity for our packets.


• Extend the verification environment.

Lab Instructions


1. Change directory to labs/sbt_lab05, and close any open specview windows.

2. Add the following new fields and constraints to the sbt_packet for controlling whether the

packet has good or bad parity.

a. Add a field to control good or bad parity, and use a soft constraint to set the default as

good parity (packet_kind).

b. Add a field, parity_computed, and constrain it to be the output of the parity_calc()

method. This field will always contain the correct parity.

c. Constrain the parity field so that you get:

• When packet_kind == GOOD, the parity field equals the parity_computed field.

• When packet_kind == BAD, the parity field does not equal the parity_computed

field.

Note Order of generation is important. You must generate addr, len, and data before you

can calculate the parity. You also must decide whether you want a packet to have good or

bad parity before you generate the parity field.

Tip You can remove the call of the parity_calc() method from the post_generate() body,

because the parity field is now constrained to the output of parity_calc().

3. Load the sbt_env.e file.



Lab 5 Extending the Verification Environment

5. Click Sys and examine the generated packets.

6. Add an item called packet_kind to the coverage group. Reload, click on test, and review the

additional data shown in coverage by opening the coverage browser.

7. Exit specview.


Lab 6 when Inheritance

Lab Overview

You can use when inheritance to create subtypes of a struct.

Each subtype can have new struct members, such as fields, constraints, and methods.

You can also extend methods in different ways within different when blocks (subtypes).


• Create struct subtypes using when inheritance.

Lab Instructions

Your working directory is labs/lab6.

1. Add a new file called sbt_packet_vii.e that extends the sbt_packet struct to handle the

VERSION_II spec requirements. (See your Basic Training manual slide printouts.)

2. Create an enumerated type for the packet version.

3. Create a new packet_version field that is of the enumerated type created in step 2.

4. Use extend and when syntax to add the appropriate VERSION_II sbt_packet subtype

fields and constraints.

5. Edit the sbt_env.e file to import the new sbt_packet_vii.e.

6. Reload the sbt_env.e file.



Note VERSION_I and VERSION_II packets have a different structure.

9. Extend the existing packet_gen coverage collection by including the following code in

sbt_packet_vii.e:

cover packet_gen is also {item packet_version;

};

10. Reload, test, and use the coverage browser again to see the additional coverage item.



Lab 7 Using extend for Writing Tests

Lab Overview

To write tests in e, you generally only need to extend existing structs within the verification

environment. You do this by applying new constraints to the various fields.

Each test can extend the environment with different constraints that are simply layered on top

of it.


• Use extend for writing test scenarios.

• Redefine SPECMAN_PATH to include a library.

• Create an eRM compliant examples directory containing a configuration file and tests.

Lab Instructions

Your working directory is sbt_lib/sbt_lab07. Creation of tests is a fundamentally different

activity often done by a different group of people than those developing a verification

environment. Consequently, we will create tests in a different subdirectory than the

environment code. One methodology for collecting the test files into a separate area will be

shown in this lab.

eRM requires the use of xxx_top.e files. For example, here, each test file will import the single

file, sbt_top.e, that in turn imports all the files of the environment. Thus the test writer does not

need to know the specific files of the environment.

1. Redefine your SPECMAN_PATH to include the sbt_lib library by executing the shell

command:

• setenv SPECMAN_PATH "path_to_sbt_lib" or

• export SPECMAN_PATH="path_to_sbt_lib"

Tip Suggest one use absolute path references (not relative).

2. In sbt_lib/sbt_lab07/e, create a sbt_top.e file and write import statements for the three files

of the environment. Each import must use a package relative pathname, e.g. import

sbt_lab07/e/sbt_packet.e;

3. Create a new directory tests under sbt_lab07 and cd into it


Lab 7 Using extend for Writing Tests

4. Create a test1.e file that imports the sbt_top.e file. Remember to use package relative

names.

5. In test1.e, extend the sbt_packet and sys structs with the following test constraints:

• Creation of exactly 20 packets:

• 10% SMALL, 20% MEDIUM, and 70% LARGE

• 70% good parity and 30% bad parity

Tip If you are not clear on how to do this, try searching the online help for:

keep soft select syntax

6. Load the test1.e file.



9. In file sbt_packet.e, replace “item len;” with the following code:

item len using ranges {range ([1..20],”SMALL”);range ([21..40],”MEDIUM”);range ([41..63],”LARGE”);

};

10. Reload, test, and observe how the coverage display for packet_gen now shows ranges of

values rather than just integer values.

11. Create a test2.e file that imports the sbt_top.e file and extends the sbt_packet and sys structs

with the following test constraints:

• Creation of 10 packets, all of VERSION_I type.

• Each packet has all data bytes except the first equal to 0xff. (The first byte was

constrained to the UID in Lab 2.)

• First packet has good parity and an address = 0.

• Second packet has bad parity and an address = 1.

• Packets 3 to 10 have either good or bad parity, an address in the range of 0 to 1, and

LARGE payloads.

Tip If you are not clear on how to do this, try searching the online help for:

keep for each syntaxandsoft reset


Using extend for Writing Tests Lab 7

Tip Use the keep for each implicit variable index to constrain packets as follows:

index == 0 => constraint;

12. Restore Specman Elite.

13. Load the test2.e file.


15. Examine the range of generated packets using either the coverage or data browsers.

16. Exit specview.



Lab 8 Events, TCMs, and Units

Lab Overview

It is necessary to model the port which drives the HDL DUT input port in a modular way. We

will use units for this purpose. Within each unit, we will create events that synchronize the e

verification environment with the HDL DUT simulation.

We will use time-consuming methods (TCMs) to drive the stimulus onto the appropriate HDL

signals according to the correct input protocol.


• Use units to model port BFMs (bus functional models).

• Use events to synchronize Specman Elite with events in the HDL simulator.

• Use TCMs.

Lab Instructions

Your working directory is sbt_lib/sbt_lab08. e. Files of the environment are in the subdirectory

e. Test files are in the subdirectory tests.

1. Change the directory to sbt_lib/sbt_lab8, and close any open specview windows.

2. Edit the file sbt_input_bfm.e to modify the SBT driver unit as follows:

a. Add fields:

• Number of packets to be driven (no_of_pkts).

• Current packet field (cur_packet) for the packet currently being driven into the SBT

DUT.

b. Add events:

• Emitted when the HDL signal top.clock falls (clk_fall).

• Emitted by the driving TCM when the TCM starts driving the packet

(packet_started).

• Emitted by the driving TCM when the TCM stops driving the packet

(packet_ended).


Lab 8 Events, TCMs, and Units

c. Add TCMs:

i. drive_packet()– This TCM should:

• Be synchronized with the falling edge of clock.

• Begin by emitting the event packet_started.

• After emitting the packet_started event, print the message “Driving one packet

to the DUT” and the current simulation time.

• End by emitting the event packet_ended.

Tip Use the predefined sys.time to refer to current simulation time.

ii. gen_and_drive()– This TCM should:

• Be synchronized with the falling edge of clock.

• Contain a loop that calls no_of_pkts times the TCM drive_packet(), waiting one

clock cycle before each call.

• Call the predefined stop_run() method at the end.

d. Extend the predefined run() method to start the gen_and_drive() TCM.

3. Edit the file called sbt_env.e as follows:

a. In the sbt_env_u unit, add an instance of the SBT input bfm.

b. Constrain the hdl_path() of the instance to “~/top”.

4. Edit sbt_top.e

a. import the file sbt_input_bfm.e

5. Create a new test file called test3.e that will:

a. import the sbt_top.e file

b. extend the sbt_driver unit to constrain no_of_pkts to 10

6. Start specview and load test3.e. Then, correct syntax errors and continue to reload your

code until it loads without errors.

7. Exit specview.


Lab 9 Running Specman Elite with a Simulator

Lab Overview

It is now time to connect your Specman Elite verification environment to the HDL simulator.

To do so, you must first create a Verilog or VHDL stubs file.

Specman Elite uses the stubs file to interface with the simulator and enable viewing of

Specman Elite objects in the waveform viewer.

You must recreate the stubs file whenever you add any of the following to your e code:

• Verilog statement or unit member

• VHDL code, VHDL function, or VHDL procedure statement or unit member

Note Details of Verilog and VHDL statements will be covered later in this chapter.


• Create an interface between Specman Elite and an HDL simulator.

• Run Specman Elite with a simulator.

Lab Instructions

Your working directory is sbt_lib/sbt_lab09. e files of the environment are in the subdirectory

e. Test files are in the subdirectory tests. Scripts for supporting various simulators are in the

subdirectory sim_scripts.

1. Change to the sbt_lib/sbt_lab09/e directory and invoke specview.

2. Load the sbt_top.e file.

3. Create an HDL stubs file by issuing the following Specman Elite command at the

Specman> prompt.

• For all Verilog simulators creating specman.v in sbt_lib/dut/verilog:

write stub -verilog ../dut/verilog/specman.v

• For NC-VHDL simulators creating specman_nc.vhd:

write stub -ncvhdl ../dut/vhdl/specman_nc.vhd


Lab 9 Running Specman Elite with a Simulator

• For Modelsim VHDL simulators creating specman_qvh.vhd:

write stub -qvh ../dut/vhdl/specman_qvh.vhd

4. Create a working directory under sbt_lib/sbt_lab09 in which simulations will be run and

verification data will be written. Call it working, and cd into it.

5. Quit specview so that you can run specview linked to the HDL simulator.

6. Copy the relevant script (run_simulator_lab#.sh) from the sbt_lib/sim_scripts directory to

the current working directory and execute it at the UNIX prompt.

The linked run of Specman Elite and the HDL simulator starts.

Note simulator = mti_vhdl, mti_verilog, xl_verilog, nc_vhdl, nc_verilog, vcs_verilog

Tip Read the script file to see how you are activating Specman Elite and the simulator

simultaneously. For this lab you should be using a script that has a lab9 in its name.

Note To switch control to Specman Elite, issue the appropriate simulator command:

• ModelSim > sn

• Verilog-XL, VCS > $sn;

• NC-Sim > call sn;

To switch control back to the simulator, click the Specman> prompt at the bottom left

corner of the specview window.

7. In specview, load the file test3.e.

8. View events in the waveform window by issuing the following Specman Elite commands

after loading the e files:

Specman> set wave viewer

Note Replace viewer as follows:

• ModelSim—mti

• Signalscan—signalscan

• Novas—novas

• VirSim—virsim

Specman> wave event sbt_packet.* (wave event struct-name.event-name)

Tip You can also view other Specman Elite struct members (for example, fields) in the

waveform viewer.

For more information, see Chapter 7 “Using a Waveform Viewer” in the Specman Elite

Usage and Concepts Guide.


Running Specman Elite with a Simulator Lab 9

9. In specview, issue test command.

10. Set a breakpoint in the gen_and_drive() TCM as follows.

a. Click the Modules button to view the currently loaded modules.

b. Select the sbt_input_bfm.e file, and click on the Source button to open the Source

window.

c. Select the line where the for loop begins in the gen_and_drive() TCM

d. Click the Break button to set a breakpoint.

e. You can now close the Current Modules and the Source windows by clicking their Close

button.

11. Click the Specman> prompt to switch control back to the simulator and then run the

simulator:

• ModelSim > run -all

• Verilog-XL, VCS > .

• NC-Sim > run;

Specman Elite stops the simulator at the breakpoint and brings up the Source Debug

window so that you can debug your source code.

12. Debug the source code as follows.

a. Click the Step button to step through your code one line at a time.

b. Select the no_of_pkts field and click the Print button to see the current value.

c. Click the Cont button to continue.

d. Select the line with the breakpoint and click the Del Br button to delete the breakpoint.

Tip You can delete all breakpoints by clicking the Del All button.

e. Click the Cont button to continue.

13. In the main specview window, see the TCM message printed 10 times.

14. Exit specview.



Lab 10 On-the-Fly Generation and Packing

Lab Overview

Specman Elite supports two types of generation—pre-run and on-the-fly.

With on-the-fly generation, structs are generated during the run using the gen action.We

recommend on-the-fly generation for stimulus generation for the following reasons:

• The Specman Elite generator can react to the current state of the DUT, because the constraints

can be based on the value of signals inside the DUT.

• It saves memory.


• Generate packets on the fly

• Use packing to convert high-level structs to lists of bits

Lab Instructions

Your working directory is sbt_lib/sbt_lab10. All required e files are in the subdirectory e. All

required scripts are in the subdirectory scripts.


2. Edit the sbt_input_bfm.e file as follows.

a. Add a field called delay of type uint for generating random delays between packets.

Constrain a default range for delay.

b. Modify the TCM gen_and_drive() as follows.

i. Before generating the next packet in the loop, gen the delay and wait the delay

number of falling clocks.

ii. In the loop, use the gen action to generate the cur_packet and call the

drive_packet() method, no_of_pkt times.

iii. When generating the cur_packet, add a constraint that forces the packet’s UID field

to equal the current loop variable index.

c. Modify the TCM drive_packet() to:

i. Pack the cur_packet, using packing.low, into a variable of type list of byte.


Lab 10 On-the-Fly Generation and Packing

ii. Using the SBT DUT Spec, drive each byte from this list on to the HDL bus top.data

with the correct protocol.

• Make sure you tag the physical fields in the sbt_packet_s struct, because only

the physical fields get packed.

• Use the packing.low option.

3. Create a subdirectory called working and cd into it

4. See steps 3 to 8 of Lab 9. Copy the script that starts Specman Elite with your simulator from

the scripts subdirectory to the current working directory and execute it at the UNIX prompt.

a. In specview, load the file ../tests/test3.e and issue the test command.

b. Set source line breakpoints as required to debug your TCMs.

c. Run the simulator.

d. Debug the source code.

5. Exit specview.


Lab 11 Collecting Output Data

Lab Overview

For checking the data coming out of the SBT DUT, we must first create a unit to model a bfm

receiver for each of the three SBT DUT output ports. This bfm interacts with th dut to collect

the packets coming out of the ports.

To check that the correct data has been received on the correct output port, we create a

scoreboard data checker for each output port.


• Use a unit to model a receiver

• Collect the data coming out of the DUT

• Use the unpack() method

Lab Instructions



2. Edit the file sbt_output_bfm.e, which already contains an sbt_output_bfm unit with an

empty TCM called collect_packets(), so that:

a. According to the SBT DUT output protocol spec,once valid data is known to be ready

on the output, the TCM must collect one byte coming out of a port per clock cycle and

add that byte to a list that is initially empty.

b. After collecting all bytes for a complete packet, the unpack() method converts the list

to a packet struct called rcv_packet of type sbt_packet.

c. After unpacking the packet, an event called pkt_received emitted.

Tip Use a while TRUE loop that loops forever to collect the packet bytes.

Tip For modeling the output ports, we define an sbt_output_bfm unit and then create three

instances of it. Therefore, when accessing HDL signals, use computed names (based

on the port_no field).

3. Modify sbt_top.e to import the sbt_output_bfm.e file.

4. Modify the sbt_env.e file as follows.


Lab 11 Collecting Output Data

a. extend the sbt_env unit with a field that is a list of sbt_receiver unit instances.

b. Constrain the list size to three instances.

c. Constrain the port_no field for each unit to be equal to the index of the receiver in the

list.

d. Because each receiver is at the same level of hierarchy in the DUT, constrain each

receiver’s hdl_path() to be equal to “~/top”.

Tip For more information, search the online help for list of unit instance.

5. Create a working directory in sbt_lib/sbt_lab11 and cd into it.

6. See steps 3 to 8 of Lab 9.

a. Copy the script that starts Specman Elite with your simulator from the scripts

subdirectory to the current working directory and execute it at the UNIX prompt.

b. In specview, load the file ../tests/test3.e and issue the test command.

c. Set source line breakpoints as required to debug your TCMs.

d. Run the simulator.

e. Debug the source code.

Tip If you received the following error:

***Error: session.run_tick_max (initial value 10000) has expired without a call to ‘stop_run()’

then you probably forgot to start the collect_packets() TCM from the test-phase run()

method. tick_max is a run configuration parameter that determines the maximum

number of ticks before the test stops. If your receiver does not respond to the DUT

(because the TCM never started), then the DUT, in turn, does not respond to the driver.

This causes the driver to hang, never executing stop_run().

For more information, search the online help for tick_max.

7. Exit specview.


Lab 12 Scoreboard Data Checking

Lab Overview

A basic concern when checking DUT data items is to verify that the output data matches an

expected result according to the rules of how the DUT modifies the input data.

We call this kind of checking scoreboard checking, because it records the expected result of

each input data item and notes when a matching output data item is found.

With scoreboard checking, you can verify that:

• Every input has a matching output

• Every output has a matching input


• Create a unit for the scoreboard packet data checker

• Use the predefined dut_error() method

• Use the predefined deep_compare_physical() method

Lab Instructions


1. Edit the file sbt_scoreboard.e, which already contains an sbt_scoreboard_u unit with two

empty methods called add_packet() and check_packet(), as follows.

a. Create a field of expected packets exp_packets that is a do-not-generate list of

sbt_packet.

b. In add_packet(), add the input parameter packet_in to exp_packets list.

c. check_packet()

i. Use the predefined deep_compare_physical() method for checking that the input

parameter packet_out matches a packet on the list exp_packets.

ii. If the packets match, remove the matching packet from the list. If the packets do

not match, issue a dut_error() with an appropriate message.

Tip For more information, see Chapter 22 “List Pseudo-Methods” in the

Specman Elite e Language Reference.


Lab 12 Scoreboard Data Checking

Note When sending and receiving packets, we must call the add_packet() and

check_packet() methods from the sbt_driver and the sbt_receiver. To do so, we extend the

sbt_input_bfm_u and sbt_output_bfm_u units so that the on struct member calls the

appropriate method when the respective event is emitted.

For more information, search the online help for on event struct member syntax.

Note So that we can reference the scoreboard on the appropriate output port, we add a

backpointer to the sbt_env_u unit in the sbt_input_bfm_u unit using get_enclosing_unit().

2. Edit the file sbt_env.e to import the new file sbt_scoreboard.e.

3. Create a working directory in sbt_lab12, and cd into it.


a. At the UNIX prompt, execute the script that starts Specman Elite with the simulator.


c. Set source line breakpoints as required to debug your TCMs.

d. Run the simulator.

e. Debug the source code.

5. Exit specview.


Lab 13 Temporal Events and Checking

Lab Overview

Temporal expressions are combinations of events and temporal operators that describe time or

protocol behavior.

Temporal expressions define the occurrence of events for synchronizing with signals in the

HDL, suspending execution of a TCM, capturing functional coverage, or checking that

sequences of events occur in accordance with specific protocol rules. We use the expect struct

member to define temporal checks.


• Capture temporal behavior using events.

• Check that the SBT DUT obeys input and output protocol rules by using expect struct

members.

Lab Instructions


1. Change directory to sbt_lib/sbt_lab13/e, and close any open specview windows.

2. Edit the file sbt_checker.e and extend the sbt_input_bfm_u and sbt_output_bfm_u units

with the following protocol checks:

a. expect that the output signal err rises within 1 to 10 cycles after packet ended if a packet

is driven to the SBT with bad parity. To do so:

i. Create an event called bad_parity that occurs when the cur_packet has a

packet_kind of BAD. Use the packet_ended event as the sampling event.

ii. Create an event called err_rise that occurs when the SBT DUT signal err rises.

iii. Use the expect struct member and issue an appropriate dut_error() if check fails.

Tip For more information, search the online help for temporal dictionary.

b. expect that the SBT DUT signal suspend_data_in falls within 100 clock cycles after it

rises. To do so:

Create appropriate events and an expect struct member like the previous check.


Lab 13 Temporal Events and Checking

c. expect that the input signal read_enb_x rises within 30 clock cycles after the SBT DUT

signal vld_chan_x rises for each of the sbt_receiver output ports. To do so:

When creating the appropriate events and expect struct members, use computed names

based on the port_no field of the sbt_receiver.

Tip You can intentionally cause this check to fail if you create a new test that

causes the receiver delay to exceed 30 clock cycles.

3. Edit the file sbt_top.e to import the new file sbt_checker.e.

4. Create a working subdirectory in sbt_lab13 and cd into it




c. View events in the waveform viewer.

Tip You might want to change your test file to check your checkers.

6. Run the simulator.

Write a fourth protocol check for the sbt_output_bfm_u to check that the output DUT

channelx bus is not tri-stated (high-z) when the SBT DUT signal vld_chan_x is asserted

(high) and the input signal read_enb_x is also asserted (high).

Tip See the slide printouts from the Driving Stimulus class for the @z syntax that checks

whether signals are tri-state.

For more information, search the online help for tri-state.

7. Exit specview.


Lab 14 Stimulus and State Machine Coverage

Lab Overview

You created packet coverage as debugging aid to packet generation in earlier labs. In this lab,

we will reuse that code functional coverage to ensure that all input stimulus scenarios were

created, and we will implement new functional coverage to veriify that the SBT DUT state

machine executed each legal state and state transition.


• Write coverage groups for input stimulus

• Write coverage groups for DUT state machines

Lab Instructions


1. Change directory to sbt_lib/lab14/e, and close any open specview windows.

2. Edit sbt_packet.e, find the coverage code and review what you implemented taking into

account the material of the coverage lectures. Remove the post_generate code which emits

the event triggering packet coverage.

3. Edit the file sbt_cover_packet.e. Extend the SBT input_bfm so that when the driver()

method emits the event packet_started, the event cur_packet.packet_gen is also emitted.

Note The change made here is subtle. The original code sampled data whenever a packet

was generated. With this change, we assure that the packets we sample for coverage are

only those that are driven into the device.

4. To edit the file sbt_cover_dut.e to cover the SBT DUT state machine, make the following

modifications to the sbt_cover_dut_u unit. This is a new unit in which an event sbt_sm has

been defined that occurs when the clock signal rises.

a. Create a new coverage group based on the event sbt_sm. Use the coverage group text

option to name this group “SBT State Machine”.

b. Create an enumerated type called fsm_state that has the values for each possible state.

Refer to the SBT DUT spec (see slide printouts) for state names and encoding.

Note The enum values must be in the same order as the HDL enum, as shown in the Spec.


Lab 14 Stimulus and State Machine Coverage

c. Add one coverage item of type fsm_state to cover the HDL signal router1/in_port/state

(the state register in the SBT HDL).

Note Note an sbt_cover_dut_u unit instance is defined in the sbt_cover_dut.e file with and

extension to sbt_env_u. Thus this particular coverage capability is included or excluded in

the environment by the presence or absence of the file.

d. Add a transition coverage item for the state register. Be sure to define the illegal

transitions as listed in the SBT DUT spec.

Tip It is easier to specify illegal transitions as not (legal transitions).

Tip For more information, see “Coverage of State Machines” in the Verification Advisor.

Note The file sbt_top.e has already been edited to import sbt_cover_dut.e and

sbt_cover_packet.e

5. Open and examine the file config.e in the tests area. This file is also imported by test3.e in

this lab. The code in this file modifies the specman default coverage settings. Here the

set_config action enables coverage collection that permits interactive crossing of fields

which you will see shortly.

6. As in steps 3 and 7 of Lab 9, create a subdirectory named working in sbt_lab14 and cd into

it.



c. Run the simulator.

7. Wait for the simulation to end. Then click the Coverage button to examine the

coverage.

The Coverage window opens.

8. In the Coverage window, examine the coverage items.

a. Click the Holes button to see only the coverage holes.

b. Click the Full button to see covered items only

c. Click the All button to see holes and the covered items.


Stimulus and State Machine Coverage Lab 14

9. In the left frame of the Coverage window, click the plus next to session.start_of_test to

expand this predefined coverage group.

Note The seed and test_name are automatically covered.

Note Each coverage group has a grade, and there is an overall grade for the entire test.

10. After reviewing the coverage items, click the Cross button .

The Interactive Coverage window opens for doing post-process cross-coverage.

11. Expand the coverage group of sbt_packet_s and then:

a. Select the item packet_kind and click Add to add it to the list of items to be crossed.

b. Select the item addr and click Add to add it to the list of items to be crossed.

c. Click OK to see the cross coverage of packet_kind and addr.

12. Exit specview.



Lab 15 Adding More Coverage and Writing Tests

Lab Overview

In this lab, we add the remaining coverage groups from our test plan and then write tests aiming

at 100% functional coverage.


• Write a complete verification environment.

Lab Instructions

Read this lab from start to finish before beginning.


1. Change directory to sbt_lib/sbt_lab15/e, and close any open specview windows.

2. Add coverage groups or items for the following test plan requirements:

• SBT DUT issued an error response.

• Each location in each FIFO was written, and each FIFO became full.

Tip The SBT DUT spec (in the slide printouts) specifies that:

• Each output port has a 16-byte FIFO.

• Each FIFO has a FIFO full flag.

• Each FIFO has a WRITE pointer that is incremented every time new data is written

to the FIFO.

3. Create new tests to fill the coverage holes. Give each new test a separate test file (test5,

test6, etc.).

Tip import the sbt_top.e file in each test. Make certain to use the package relative path.

Tip To stress FIFOs, inject large input packets and have the receivers wait a long time

before reading the output packets.


Lab 15 Adding More Coverage and Writing Tests

Tip Keep your tests short (25 packets or less). Use random seeds to get different variations

of the same test.

Specman> test –seed=random

Tip Review the table below for a list of the fields that you might want to constrain.

4. In the coverage window, use the Read button to view cumulative coverage for all tests

that were run. For example, after running test5, you can read in coverage for test3 and test4

as well.

5. Notify the instructor each time you find a bug in the DUT, and he or she will correct the

bug in the DUT for you. Then, after code correction, recompile the HDL and continue

trying to fill the coverage.

6. Exit specview.

Struct/Unit Name Field Name Purpose

sbt_packet packet_kind Good or bad parity packet

sbt_packet addr Address of output port

sbt_packet len Payload size (in bytes)

sbt_driver no_of_pkts Number of packets to drive

sbt_driver delay Delay before driving new packet

sbt_reciever rcv_delay Delay before reading from output port

Documents

Advanced Specman Ovm