Professional Documents
Culture Documents
Advanced Specman Ovm
Advanced Specman Ovm
Version 5.2
TM
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 Verisitys 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.
Contents
Lab 1 Lab 2 Lab 3 Lab 4 Lab 5 Lab 6 Lab 7 Lab 8 Lab 9 Lab 10 Lab 11 Lab 12 Lab 13 Lab 14
Opening Specview and Using the Online Help . . . . . . . . . . . 1 Using Specman Elite Commands . . . . . . . . . . . . . . . . . . . . . 5 Structs, Lists, and Methods . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Generation and Constraints . . . . . . . . . . . . . . . . . . . . . . . . 13 Extending the Verification Environment . . . . . . . . . . . . . . . 17 when Inheritance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Using extend for Writing Tests . . . . . . . . . . . . . . . . . . . . . . Events, TCMs, and Units. . . . . . . . . . . . . . . . . . . . . . . . . . . Running Specman Elite with a Simulator . . . . . . . . . . . . . . On-the-Fly Generation and Packing . . . . . . . . . . . . . . . . . . Collecting Output Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . Scoreboard Data Checking . . . . . . . . . . . . . . . . . . . . . . . . . Temporal Events and Checking . . . . . . . . . . . . . . . . . . . . . Stimulus and State Machine Coverage . . . . . . . . . . . . . . . . 21 25 27 31 33 35 37 39
Lab 1
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 e Language Reference Specman Elite Command Reference Specman Elite Usage and Concepts Guide Detailed information on the e programming language used to model parts of the test environment and to create tests Detailed information about the commands you can use to control the Specman Elite tool Detailed information about using the Specman Elite tool and integrating the Specman Elite system with other software tools or C models Detailed information about the Specman Elite generator and how to use it Release notes for the current version of Specman Elite
Specman Elite Generation Guide Specman Elite Release Notes Installation Guide eReuse Methodology (eRM) Verification Advisor Index
Installation guide for the current version of Specman Elite Detailed information about maximizing reusability of verification code written in e. Recommended verification methodology Index for all of the above except the Verification Advisor, which has its own separate index
Launch specview. Use the online help, including the Verification Advisor.
Lab 1
Lab Instructions
Your working directory for lab 1 is sbt_lib/sbt_lab01/e. 1. 2. Change directory to sbt_lib/sbt_lab01/e. Launch specview by typing the command:
specview &
Contents Includes Search and Browsing Tips, Specman Elite Manuals, e Reuse
Methodology (eRM), and the Verification Advisor.
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 Verisitys 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
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. After completing this lab, you will be able to:
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.
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
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 specviews 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.
to load an e file.
The Select a File dialog box appears. 6. 7. Select the file template.e and click OK. 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. 9. Click the Restore button to restore Specman to its original state.
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;
Lab 2
11. Execute init.ecom from the Specman> prompt by preceding it with the @ symbol.
Specman> @init
Lab 3
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. located and the fields of any other struct using hierarchical referencing.
When a method is executed, it can manipulate the fields of the struct in which it is currently 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. After completing this lab, you will be able to:
Lab Instructions
Your working directory is sbt_lib/sbt_lab03/e. 1. 2. 3. Open the existing e file called sbt_packet.e and create a struct sbt_packet_s according to the SBT Spec. Add all required fields to the struct. 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
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 objects definition from its instance in a file such as sbt_env.e. Note Make sure you import your sbt_packet.e file first.
5. 6.
In specview, click Load and load your sbt_env.e file. Read and correct the syntax errors. Continue using the specview Reload button until you load your e code successfully. Click the Modules button Click the Test button to view the currently loaded modules. to start the generator.
7. 8. 9.
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.
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; };
10
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
11
12
Lab 4
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 items 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. 2. Change directory to sbt_lib/sbt_lab04, and close any open specview windows. 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.
13
Lab 4
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. 6. 7. 8. Add a constraint that takes into account that the SBT has only three port addresses (equal to 0, 1, and 2). 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. Load the sbt_env.e file and generate the list of packets using the test command. 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. b. On the specview Test menu, choose Test with Random Seed. Click Sys to display the new list.
The two lists should be random and different but obeying your constraints.
If time permits:
1. 2. Add an 8-bit UID (unique identification) field uid to the sbt_packet. 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. 4. 5. 6. Reload the sbt_env.e file. Issue the test command to generate the list of packets. Click Sys and examine the generated packets. Make sure that the first byte of the payload data equals the UID. Add an additional coverage item to the packet_cov coverage group:
item payload_size;
14
Lab 4
7. 8.
Reload and click on test. Review the packet coverage by clicking on the coverage gui button. Exit specview.
15
16
Lab 5
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. After completing this lab, you will be able to:
Lab Instructions
Your working directory is sbt_lib/sbt_lab05. 1. 2. Change directory to labs/sbt_lab05, and close any open specview windows. Add the following new fields and constraints to the sbt_packet for controlling whether the packet has good or bad parity. a. b. c. Add a field to control good or bad parity, and use a soft constraint to set the default as good parity (packet_kind). 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. 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. 4. Load the sbt_env.e file. Issue the test command to generate the list of packets.
17
Lab 5
5. 6. 7.
Click Sys and examine the generated packets. 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. Exit specview.
18
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). After completing this lab, you will be able to:
Lab Instructions
Your working directory is labs/lab6. 1. 2. 3. 4. 5. 6. 7. 8. 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.) Create an enumerated type for the packet version. Create a new packet_version field that is of the enumerated type created in step 2. Use extend and when syntax to add the appropriate VERSION_II sbt_packet subtype fields and constraints. Edit the sbt_env.e file to import the new sbt_packet_vii.e. Reload the sbt_env.e file. Issue the test command to generate the list of packets. Click Sys and examine the generated packets. 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.
19
20
Lab 7
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. After completing this lab, you will be able to:
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:
3.
21
Lab 7
4. 5.
Create a test1.e file that imports the sbt_top.e file. Remember to use package relative names. 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. 7. 8. 9.
Load the test1.e file. Issue the test command to generate the list of packets. Click Sys and examine the generated packets. 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
22
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. 14. Issue the test command to generate the list of packets. 15. Examine the range of generated packets using either the coverage or data browsers. 16. Exit specview.
23
24
Lab 8
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. After completing this lab, you will be able to:
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. 2. Change the directory to sbt_lib/sbt_lab8, and close any open specview windows. 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).
25
Lab 8
c.
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.
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.
Edit the file called sbt_env.e as follows: a. b. In the sbt_env_u unit, add an instance of the SBT input bfm. Constrain the hdl_path() of the instance to ~/top.
4.
5.
Create a new test file called test3.e that will: a. b. import the sbt_top.e file extend the sbt_driver unit to constrain no_of_pkts to 10
6. 7.
Start specview and load test3.e. Then, correct syntax errors and continue to reload your code until it loads without errors. Exit specview.
26
Lab 9
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. After completing this lab, you will be able to:
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. 2. 3. Change to the sbt_lib/sbt_lab09/e directory and invoke specview. Load the sbt_top.e file. Create an HDL stubs file by issuing the following Specman Elite command at the Specman> prompt.
27
Lab 9
4. 5. 6.
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. Quit specview so that you can run specview linked to the HDL simulator. 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. 8. In specview, load the file test3.e. View events in the waveform window by issuing the following Specman Elite commands after loading the e files:
Specman> set wave viewer
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.
28
Specman Elite Basic Training Labs
Lab 9
9.
10. Set a breakpoint in the gen_and_drive() TCM as follows. a. b. c. d. e. Click the Modules button to view the currently loaded modules. Select the sbt_input_bfm.e file, and click on the Source button to open the Source window. Select the line where the for loop begins in the gen_and_drive() TCM Click the Break button to set a breakpoint. 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. b. c. d. Click the Step button to step through your code one line at a time. Select the no_of_pkts field and click the Print button to see the current value. Click the Cont button to continue. 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.
29
30
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.
After completing this lab, you will be able to:
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. 1. 2. Change directory to sbt_lib/sbt_lab10, and close any open specview windows. 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 packets 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.
31
Lab 10
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.
Exit specview.
32
Use a unit to model a receiver Collect the data coming out of the DUT Use the unpack() method
Lab Instructions
Your working directory is sbt_lib/sbt_lab11. 1. 2. Change directory to sbt_lib/sbt_lab11, and close any open specview windows. 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. 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. After unpacking the packet, an event called pkt_received emitted.
b. c.
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. 4. Modify sbt_top.e to import the sbt_output_bfm.e file. Modify the sbt_env.e file as follows.
33
Lab 11
a. b. c. d.
extend the sbt_env unit with a field that is a list of sbt_receiver unit instances. Constrain the list size to three instances. Constrain the port_no field for each unit to be equal to the index of the receiver in the list. Because each receiver is at the same level of hierarchy in the DUT, constrain each receivers hdl_path() to be equal to ~/top.
Tip For more information, search the online help for list of unit instance. 5. 6. Create a working directory in sbt_lib/sbt_lab11 and cd into it. See steps 3 to 8 of Lab 9. a. b. c. d. e. 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. In specview, load the file ../tests/test3.e and issue the test command. Set source line breakpoints as required to debug your TCMs. Run the simulator. Debug the source code.
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.
34
Every input has a matching output Every output has a matching input
After completing this lab, you will be able to:
Create a unit for the scoreboard packet data checker Use the predefined dut_error() method Use the predefined deep_compare_physical() method
Lab Instructions
Your working directory is sbt_lib/sbt_lab12. 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. b. c. Create a field of expected packets exp_packets that is a do-not-generate list of sbt_packet. In add_packet(), add the input parameter packet_in to exp_packets list. 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.
35
Lab 12
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. 3. 4. Edit the file sbt_env.e to import the new file sbt_scoreboard.e. Create a working directory in sbt_lab12, and cd into it. See steps 3 to 8 of Lab 9. a. b. c. d. e. 5. At the UNIX prompt, execute the script that starts Specman Elite with the simulator. In specview, load the file ../tests/test3.e and issue the test command. Set source line breakpoints as required to debug your TCMs. Run the simulator. Debug the source code.
Exit specview.
36
Capture temporal behavior using events. Check that the SBT DUT obeys input and output protocol rules by using expect struct
members.
Lab Instructions
Your working directory is sbt_lib/sbt_lab13. 1. 2. Change directory to sbt_lib/sbt_lab13/e, and close any open specview windows. 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.
37
Lab 13
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. 4. 5.
Edit the file sbt_top.e to import the new file sbt_checker.e. Create a working subdirectory in sbt_lab13 and cd into it See steps 3 to 8 of Lab 9. a. b. c. At the UNIX prompt, execute the script that starts Specman Elite with the simulator. In specview, load the file ../tests/test3.e and issue the test command. 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.
38
Write coverage groups for input stimulus Write coverage groups for DUT state machines
Lab Instructions
Your working directory is sbt_lib/sbt_lab14. 1. 2. Change directory to sbt_lib/lab14/e, and close any open specview windows. 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. 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. b. Create a new coverage group based on the event sbt_sm. Use the coverage group text option to name this group SBT State Machine. 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.
3.
Note The enum values must be in the same order as the HDL enum, as shown in the Spec.
39
Lab 14
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. As in steps 3 and 7 of Lab 9, create a subdirectory named working in sbt_lab14 and cd into it. a. b. c. 7. At the UNIX prompt, execute the script that starts Specman Elite with the simulator. In specview, load the file ../tests/test3.e and issue the test command. Run the simulator. to examine the
6.
Wait for the simulation to end. Then click the Coverage button coverage. The Coverage window opens.
8.
In the Coverage window, examine the coverage items. a. b. c. Click the Holes button Click the Full button to see only the coverage holes. to see covered items only
Click the All button to see holes and the covered items.
40
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. b. c. Select the item packet_kind and click Add to add it to the list of items to be crossed. Select the item addr and click Add to add it to the list of items to be crossed. Click OK to see the cross coverage of packet_kind and addr.
41
42
Lab Instructions
Read this lab from start to finish before beginning. Your working directory is sbt_lib/sbt_lab15. 1. 2. Change directory to sbt_lib/sbt_lab15/e, and close any open specview windows. 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.
43
Lab 15
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 sbt_packet sbt_packet sbt_packet sbt_driver sbt_driver sbt_reciever Field Name packet_kind addr len no_of_pkts delay rcv_delay Purpose Good or bad parity packet Address of output port Payload size (in bytes) Number of packets to drive Delay before driving new packet Delay before reading from output port
4.
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. Exit specview.
6.
44