Advanced Specman Ovm PDF

TM
SPECMAN ELITE
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
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 i

Lab 1 Opening Specview and Using
the 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:
Specman Elite Detailed information on the e programming language used

e Language Reference to model parts of the test environment and to create tests
Specman Elite Command Detailed information about the commands you can use to
Reference control the Specman Elite tool
Specman Elite Usage and Detailed information about using the Specman Elite tool
Concepts Guide and integrating the Specman Elite system with other
software tools or C models
Specman Elite Detailed information about the Specman Elite generator

Generation Guide and how to use it
Specman Elite Release Release notes for the current version of Specman Elite
Notes
Installation Guide Installation guide for the current version of Specman Elite
eReuse Methodology Detailed information about maximizing reusability of

(eRM) 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
After completing this lab, you will be able to:

• Launch specview.
• Use the online help, including the Verification Advisor.
Specman Elite Basic Training Labs 1

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.
2 Specman Elite Basic Training Labs

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 syntax
and
soft 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.
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
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.

Advanced Specman Ovm PDF

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Advanced Specman Ovm PDF

Hochgeladen von

Copyright:

Verfügbare Formate

TM

Restricted Rights Legend

Destination Control Statement

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

Specman Elite Basic Training Labs i

Specman Elite Detailed information on the e programming language used

Specman Elite Detailed information about the Specman Elite generator

eReuse Methodology Detailed information about maximizing reusability of

Verification Advisor Recommended verification methodology

After completing this lab, you will be able to:

Specman Elite Basic Training Labs 1

1. Change directory to sbt_lib/sbt_lab01/e.

2. Launch specview by typing the command:

Figure 1-1 Specview Main Window

Note You can start Specman Elite in two ways:

• GUI mode – Executable is specview

• Index– Includes a full index.

2 Specman Elite Basic Training Labs

The search results appear in the left frame.

5. Select Defining Structs by clicking on the hyperlink.

7. Exit specview (File > Quit).

Specman Elite Basic Training Labs 3

After completing this lab, you will be able to:

• Use Specman Elite commands at the Specman prompt.

1. Launch specview by typing the command:

2. In specview, click the Config button .

The Specman Elite Configuration Options window appears.

Specman Elite Basic Training Labs 5

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.

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

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

6 Specman Elite Basic Training Labs

12. Exit specview.

Specman Elite Basic Training Labs 7

2. Add all required fields to the struct.

Specman Elite Basic Training Labs 9

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

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:

This generates a new random list of packets.

10 Specman Elite Basic Training Labs

16. Exit specview.

Specman Elite Basic Training Labs 11

• Prevent particular conditions from occurring.

After completing this lab, you will be able to:

• Use the Specman Elite random generator.

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

Tip Use a sized list rather than a constraint.

Note This requires creation of a new enumerated type.

Specman Elite Basic Training Labs 13

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

Specman> show constraints sbt_packet_s.*

10. Run another test with a new seed:

b. Click Sys to display the new list.

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

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

14 Specman Elite Basic Training Labs

Specman Elite Basic Training Labs 15

After completing this lab, you will be able to:

• Extend the verification environment.