TestBencher Pro: Basic Tutorial

This tutorial will generate a test bench to test an SRAM model. Please note that completing this tutorial will require a full version license or a 2 week evaluation license. To obtain a 30 day evaluation license, complete the form under Help > Request License, or contact our sales department. The figure below shows a block diagram of the test bench that will be created around the SRAM. This tutorial goes through the following steps:

Create a project for the test bench. This project will ultimately contain a timing diagram file for each bus transaction modeled, a top-level test bench template file that controls the sequencing of the bus transactions, and a file containing the SRAM model under test.
Create the timing diagram that describes the reset cycle bus transaction.
Create the timing diagram that describes the write cycle bus transaction.
Copy and modify the write cycle timing diagram to create the timing diagram for the read cycle bus transaction.
Modify the top-level template file used to generate the top-level component of the test bench. Subroutine calls will control the execution order of the timing diagram transactions.
(Optional) Enable TestBencher's external simulator integration.
Generate a top-level test bench and examine the resulting source code.
(Optional) Simulate the model and test bench, if a simulator is available. (Note for Verilog Users: TestBencher includes a Verilog simulator that can be used to perform this step. See Help > VeriLogger Getting Starting for more details on using the internal Verilog simulator.) The simulation will demonstrate what happens when a sample triggers on a false condition.

Schematic of circuit that the tutorial test bench will exercise

This tutorial does not cover any of TestBencher Pro.s drawing features or the language independent bus format. These features are covered in the first five tutorials (Basic Drawing and Timing Analysis, Interactive HDL Simulation, Waveform Generation and Bus Tutorial, Advanced Parameter Techniques, and Advanced HDL Stimulus Generation). If you are new to SynaptiCAD.s timing diagram editing environment then you should work through the tutorials listed above first. This tutorial only discusses how to create multi-diagram self-testing test benches.

In this tutorial, a file will sometimes be referred to as <filename>.<language extension>. This means that the name of the file will be different depending on the language used:

For Verilog users, the name of the file would be <filename>.v
For VHDL users, the name of the file would be <filename>.vhd
For OpenVera users, the name of the file would be <filename>.vr

This tutorial uses three timing diagrams: tbreset.tim, tbwrite.tim and tbread.tim. Two versions of the SRAM model under test (MUT) are provided in files named tbsram.v (for use with Verilog and OpenVera) and tbsram.vhd (for use with VHDL and OpenVera). TestBencher uses a top-level template file named tbench.<language extension>. This file will be copied to the project, then modified to include the timing transactions and MUT instantiation.

1) Create a Project

TestBencher Pro uses a project to save the options and organize the files that will be used to generate the test bench. In this section the project will be created, and then the Model Under Test (MUT) file will be added to the project.

1.1 Use the New Project Wizard to create a project

The New Project Wizard can help to quickly set up the basic project files and settings. The wizard is further discussed in Section 2.2 of the TestBencher Pro User's Manual.

To run the New Project Wizard:

Select the Project > New Project menu option. This will launch the New Project Wizard dialog.
Unix users: Make sure that you have read/write access to the directory specified in the Project Directory edit box. If you do not, enter a directory to which you have read/write access into the Project Directory edit box.
Enter sramtest in the Project Name edit box. Notice that sramtest (the name of the project) is appended to the default Project Directory string as it is typed in. This will cause the project files to be placed in the subdirectory shown.
Select the project language from the Project Language dropdown list.
Click the Next button to move to the second page of the New Project Wizard.
Make sure that the Original Template edit box contains the file named tbench with the extension appropriate for the language being worked with.
Change the name of the New Template to sramTbench.<language extension>. TestBencher will use this file to generate the top-level module of the test bench. The generation of this file will be discussed further in Section 7 of this tutorial.
Type CLK into the Default Clock dropdown, and make sure the Edge dropdown is set to neg. Selecting a default clock causes the test bench to be cycle-based; if no clock is specified, the test bench will be event-based.

Make sure that the Create Default Clock Generator box is checked. This will cause TestBencher to create a timing diagram called CLK_generator.tim that will drive the CLK signal.

Note: The global clock signal will have the default clock settings. To modify the global clock signal, open the <clock>_generator.tim diagram, where <clock> is the name of the global clock, and modify the clock signal there.

OpenVera users should verify that the Generate Test Top checkbox is checked.
Click the Finish button to close the New Project Wizard. This causes a new project to be created.

TestBencher has generated a new timing diagram named sramtest_templateDiagram.tim. This Template Diagram is the timing diagram template for the project. New diagrams that are created for this project will use the properties of the Template Diagram and will contain the same signals, waveforms, and parameters as the Template Diagram. Currently the CLK signal is the only signal in this diagram.

1.2 Verify Simulation Mode

The Simulation properties affect when and how TestBencher will perform simulations. During the initial design phase the interactive simulation features should be turned off. This can be accomplished by setting the following options on the Simulation button bar at the top of the application window.

To set the Simulation State and Simulation Mode:

Verify that the Simulate > Simulate Diagram With Project menu option is not checked.
Make sure that the Simulation Mode is set to Debug Run. (Click the Simulation Mode button if Auto Run is the currently selected mode.)

1.3 Add the MUT to the Project

The first file added to the project will be the Model Under Test (the MUT). Once the MUT is added to the project and parsed, signal properties will be set and the MUT will be instantiated automatically. The MUT for this tutorial is the SRAM model contained in tbsram.<language extension>.

To add the MUT to the project:

Right-click the User Source Files folder in the Project window to bring up the User Source Files context menu.
Select the Add File(s) to User Source File Folder... menu option. This will open the Add Files... dialog.
Select the file to use as the MUT from the files in the Examples sub-directory of the installation directory:
- Verilog or OpenVera/Verilog users should select the file tbsram.v.
- VHDL or OpenVera/VHDL users should select the file tbsram.vhd.
Click the Open button to close the Add File(s) dialog and add the file to the User Source Files folder in the Project window.

1.4 Extract Port Information From the MUT Into the Template Diagram

The next step is to build the source files, set the MUT, and modify the Template Diagram file so that it includes the port information of the MUT. Building the MUT will cause the source files that have been added to the project to be parsed and built. The MUT component will be set during the following steps so that it can be instantiated correctly during the top-level template file generation.

To build the MUT and extract port information to the Template Diagram:

Verify that the sramtest_templateDiagram.tim is open in the Diagram window. If it is not, double-click the file name in the Template Diagram folder to open the Template Diagram.

Click the yellow build button. This will build the MUT and cause the dialog shown below to open. It is asking if the MUT port information should be placed in a new diagram. Click No to insert the signals into the Template Diagram.

Note: When the MUT is compiled, TestBencher extracts the port information from it. By default, TestBencher will place signals that match the MUT ports into the active diagram. This information will be used in both the read and write transactions, so TestBencher should place these signals into the Template Diagram. This means that all of the new diagrams that are created while this project is open will start with the default clock and the SRAM port signals.

Notice that <<<tbsram>>> is now present in the Project window under the heading Currently Simulated Model. The three angle brackets indicate that <<<tbsram>>> is the Model Under Test. Expanding this tree will display all the models in the tbsram file.

Note: If <<<tbsram>>> was not generated as the MUT, then change the simulation preferences by choosing the Options > Diagram Simulation Preferences menu. Check the Auto-create test bench and tree check box. Rebuild the MUT (see step 2 above) to see the expanded project tree.

Save the project by selecting the Project > Save Project menu option.

1.5 Modify the Template Diagram

The Template Diagram now contains all of the SRAM port signals, plus a gray Watch signal that corresponds to DBUS. The Watch signal is present because TestBencher automatically generates a Watch signal for any signals in the MUT with a direction of input, inout, or persistent inout, and DBUS is an inout signal. The Watch signal will not be used in any of the transactions in this project, so it can be deleted.

To delete the Watch signal from the Template Diagram:

Click on the gray DBUS signal name to select the signal.
Press the delete key. This will remove the DBUS signal from the diagram.

The three signals CSB, WRB, and ABUS need to have shared output as their direction, so that they can be driven from all of the transactions. Shared output means that the signal can be driven by more than one transaction. It also means that the signal is an output of the test bench, and thus an input to the MUT.

To set the direction of CSB, WRB, and ABUS:

Select the CSB, WRB, and ABUS signals.
Right-click on one of the selected signal names (CSB, WRB, or ABUS) to open the Diagram context menu.
Select Edit Selected Signal(s)... to open the Signal Properties dialog.

Note that the Name edit box in the Signal Properties dialog is grayed out. This is because multiple signals are being edited. Any changes to the property settings will affect all of the selected signals.
Select shared output from the Direction drop down box.
Click the OK button. The three signals are now set to shared output.

Now that the Template Diagram has been modified, it must be saved.

To save the Template Diagram:

Click in the title bar of the Diagram window to make it the active window.
Click the diskette icon to save the contents of the current window.

The Project window should now contain:

The Currently Simulated Model (currently the MUT), <<<tbsram>>>.
The Component Model, which is the top-level template file sramTbench.<language extension>.
One timing diagram, CLK_generator.tim. The associated source file for the clock generator, CLK_generator.<language extension>, is in the Project window but currently hidden.
One Template Diagram, sramtest_templateDiagram.tim.
The MUT source file, tbsram.<language extension>.

Next the diagrams representing the timing transactions for the MUT will be created and added to the project.

2) Create the Reset Cycle Timing Diagram

Before any operations can be performed on the SRAM, its control signals (CSB and WRB) need to be reset. The reset cycle will drive the two control signals to a high state.

2.1 Draw the Timing Diagram for the Reset Cycle

This section explains how to create the timing diagram that represents the reset cycle transaction.

Select the File > New Timing Diagram... menu option.

Note: The new diagram contains all of the signals that were in the Template Diagram. This includes the global clock CLK and the four signals extracted from the MUT.

Select the ABUS and DBUS signals by clicking on them.

Press the delete key to delete the selected signals.

Note: Since this is the reset diagram, we will not need to read any data from the SRAM. Therefore, we will not need the ABUS and DBUS signals.

Draw the following waveforms:

(The completed version of this diagram can be found in the Examples sub-directory of the installation directory as tbreset.tim)

For more information on drawing waveforms, please refer to the Basic Drawing and Timing Analysis Tutorial.

2.2 Add an End Diagram Marker

Now an End Diagram Marker will be added to indicate exactly where the timing diagram ends.

Click on the Marker button on the button bar.
Click on the second falling edge of the CLK signal (at 150 ns) to select it. Then right-click to draw a marker that is attached to the edge.
Double-click on the marker line or label to open the Edit Time Marker dialog box.
Select a Marker Type of End Diagram from the drop down list box. The End Diagram marker will force the transaction to end at the third falling edge of the CLK signal.
Click OK to close the Edit Time Marker dialog.

2.3 Save Timing Diagram and Add to Project

In order for TestBencher to use the reset cycle timing diagram in the test bench, it must first be saved and added to the project.

To save the diagram and add it to the project:

Right-click in the Label window of the Diagram window to open the Diagram context menu.
Select Add Diagram to Transaction Diagram Folder. Since the current diagram is unsaved, this will open the Save As dialog.
Type tbreset in the File Name edit box.
Click Save to save the file under the new name.

The diagram tbreset.tim should now be listed in the Transaction Diagrams folder in the Project window.

3) Create the Write Cycle Timing Diagram

TestBencher Pro uses timing diagrams that represent reusable bus transactions to generate the test bench. This tutorial will use two timing diagrams, tbread.tim and tbwrite.tim, to represent the read and write cycles used in testing the memory module. First, the write cycle diagram will be created. Then this diagram will be used as a basis for creating the read cycle diagram. Variables will be used in the diagrams so that values can be passed into the address and data buses.

3.1 Draw the Timing Diagram for the Write Cycle

This section explains how to create the timing diagram that represents the write cycle transaction.

Select the File > New Timing Diagram... menu option.

Note: The new diagram contains all of the signals that were in the Template Diagram. This includes the global clock CLK and the four signals extracted from the MUT.

Draw the following waveforms:

(The completed version of this diagram can be found in the Examples sub-directory of the installation directory as tbwrite.tim)

For more information on drawing waveforms, please refer to the Basic Drawing and Timing Analysis Tutorial.

3.2 Add Parameterized State Values

The next step is to add state variables to the timing diagram so that values for the address and data buses may be passed into the test bench transaction. Parameterized state values, called state variables, are passed into the transaction call in the top-level template file, and are used to provide state values during transaction execution. The write cycle diagram will have a state variable for the value on the address bus, and a state variable for the value on the data bus. When the top-level template file is modified, values will be passed into the state variables.

To add the address and data state variables to the diagram:

Click on the valid segment in the center of ABUS to select the segment. The selected segment will have a green box drawn around it.
Click on the HEX button on the button bar. This will open the Edit Bus State dialog.

Type $$addr into the Virtual edit box. The "$$" in front of the variable name indicates that this is a state variable.

Note: If the "$$" is missing, TestBencher Pro will assume that this is the value of the address rather than a variable that will assume a value at a later time.

Double-click on the valid segment in the center of DBUS to move the focus of the Edit Bus State dialog to the new segment.
Type $$data in the Virtual edit box
Click OK to close the Edit Bus State dialog. The two edited segments will display the state variables.

3.3 Add an End Diagram Marker

Now an End Diagram Marker will be added to indicate exactly where the timing diagram ends.

Click on the Marker button on the button bar.
Click on the third falling edge of the CLK signal (at 250 ns) to select it. Then right-click to draw a marker that is attached to the edge.
Double-click on the marker line or label to open the Edit Time Marker dialog box.
Select a Marker Type of End Diagram from the drop down list box. The End Diagram marker will force the transaction to end at the third falling edge of the CLK signal.
Click OK to close the Edit Time Marker dialog.

3.4 Save Timing Diagram and Add to Project

In order for TestBencher to use the write cycle timing diagram in the test bench, it must first be saved and added to the project.

To save the diagram and add it to the project:

Right-click in the Label window of the Diagram window to open the Diagram context menu.
Select Add Diagram to Transaction Diagram Folder. Since the current diagram is unsaved, this will open the Save As dialog.
Type tbwrite in the File Name edit box.
Click Save to save the file under the new name.

The diagram tbwrite.tim should now be listed in the Transaction Diagrams folder in the Project window.

4) Create the Read Cycle Timing Diagram

To create the read cycle diagram, tbwrite.tim will be copied and modified. A sample will then be placed in the diagram to verify that the correct data is read.

4.1 Create the Initial Read Diagram and Add It to the Project

Since the signals for the read diagram are so similar to the write diagram, a modified copy of tbwrite.tim can be used to create the read diagram.

To create the read cycle timing diagram and add it to the project:

Right-click in the Label window of the Diagram window to open the Diagram context menu.
Select the Save As... menu option to open the Save As dialog.
Type tbread in the File Name edit box.
Click Save to save the file under the new name.
Right-click in the Label window of the Diagram window to open the Diagram context menu.
Select Add Diagram to Transaction Diagram Folder. This will add tbread to the Transaction Diagrams folder in the Project window.

4.2 Edit the Signals

One of the signals for the read diagram is different from its counterpart in the write diagram. Specifically, the WRB signal should remain high for the duration of the transaction, since it indicates a write transaction by going low.

To make the WRB signal remain high during the transaction:

Select the center segment of the WRB signal.
Press the delete key. This will remove the low segment from the signal.

4.3 Clearing the Driven flag for input segments of an inout (bi-directional) signal

The signal DBUS has a direction of inout. By default all of the signal segments on DBUS have a direction of output, so the direction of the segments in the write cycle diagram did not need to be set. The read cycle will need the valid segment of DBUS to be an input segment to read the value of that segment.

To set the direction of the segments in DBUS:

Double-click on the first segment of the waveform for DBUS. This will open the Edit Bus State dialog. Position the dialog so that both the waveform for DBUS and the dialog are visible.

Notice that the Driven (Export to source code) checkbox is checked. This means that this signal segment will be driven by the read diagram during the transaction. This segment needs to be exported as a signal assignment, so leave it checked.

Note: If the Driven checkbox is grayed out, then DBUS is not set to inout. To change the direction of the signal, double-click on the signal name to open the Signal Properties dialog, and select inout from the Direction dropdown.

Click the Next button to move to the next segment of DBUS. Notice that the green selection box moved to the next segment.
Uncheck the Driven (Export to source code) checkbox. This will indicate that the selected valid segment is an input segment that will be driven by the model under test. Notice that the color of the segment has changed to blue, because the segment is now an input segment.
Click the Next button to move to the last segment of DBUS. Notice that the valid section has turned blue, and that the green selection box moved to the last segment in the signal.
Make sure that the Driven (Export to source code) checkbox is checked.
Click OK to close the Edit Bus State dialog. The segments of DBUS should now be colored black-blue-black.

4.4 Adding a Sample to Verify Data

Next a sample will be added to the timing diagram. Samples compare the actual state value of an input signal to the expected state value, and conditionally react to the results of the comparison.

To add a sample:

Click on the Sample button on the button bar.
Click on the first falling edge of CSB to select the edge. This edge is now the trigger event that sets off the sample.
Right-click on the dollar signs inside the blue valid segment on DBUS. This adds a sample parameter named SAMPLE0, which is triggered by the first falling edge of CSB.

Notice that the sample occurs at the same time as the first falling CLK edge after the trigger event. This is because in a cycle-based diagram, everything is assumed to be clocked from the global clock signal - in this case, CLK. The sample is assumed to occur at the closest negative edge of CLK (the first negative edge). However, because the DBUS signal will not read the value from the MUT until the CSB signal is low at the same negative clock edge, there is a "race" to see whether the DBUS signal will read the value or be sampled first. To avoid this "race condition," the sample should occur after the first negative clock edge.

To change the properties of the sample:

Double-click on the sample name SAMPLE0 in the drawing window. This will open the Sample Properties dialog.
Enter 2 in the Min and Max edit boxes. This will sample the DBUS signal at the second negative clock edge after the trigger.
Click the Apply button to apply the new properties.

The diagram should now look like this:

Now that the sample has been drawn, it will generate HDL code in the test bench.

To determine the type of code that SAMPLE0 will generate:

Click the HDL Code button in the bottom left hand corner of the Sample Properties dialog to open the Code Generation Options dialog. Samples generate if-then-else code in a test bench.
Select Sample state doesn.t match from the If condition dropdown. This means that the test bench will compare the actual value on the data bus with the value in $$data at the sample time during simulation.
Select Display Message from the Then Action dropdown. This means that if the values don.t match, a message will be displayed during the simulation.
Click the Warning radio button below the Then action dropdown. These radio buttons allow a severity level to be defined for the message that is displayed.
Select Do nothing for the Else Action. If the value on the data bus matches the value of $$data, then the circuit is working properly and no action should be taken.
Click OK to close the Code Generation Options dialog.
Click OK to close the Sample Properties dialog.
Save the timing diagram by selecting File > Save Timing Diagram from the main TestBencher menu.

5) Modify the Top-Level Template File

In this section the top-level template file that will be used to generate the test bench will be modified. The template file has all of the code that TestBencher needs to generate a test bench except the information specific to the model. The Apply statements that will control the sequencing of the timing transactions will be added here, so that the model is stimulated properly.

Apply statements will represent the sequence in which the transactions will be carried out. Each Apply statement is representative of one timing transaction. Entering the Apply statements in the top-level template file will define the order of execution of the timing transactions.

5.1 Adding the Global Clock Transaction

The global clock transaction should be the first transaction added to the diagram.

To apply the global clock transaction:

Double-click on the Component Model, sramTbench.<language extension>, in the Project window, to open the file in an editor window.
Scroll down in the sramTbench.<language extension> editor window until you find the comment block that has this line:
- Add apply calls for global clock diagram after this comment block:
  
  This comment is almost at the very end of the file.
Click in the sramTbench.<language extension> editor window below this comment so that the blinking cursor is in the place where the apply statement should be added.
Right-click in the editor window to bring up the Editor context menu. Select Insert Diagram Calls to open the Insert Diagram Subroutine Call dialog.
Select the Loop Forever and Concurrent Apply radio buttons. This will cause the clock generator to run for the duration of the simulation, and to run at the same time as the other transactions.

Click the Apply_CLK_generator; statement to select it.

Note: In OpenVera, this statement is tb_CLK_generator.Execute();.

Click the Insert button. This will add an Apply statement for the CLK_generator transaction to the top-level template file. Note that the Apply statement (Execute for OpenVera users) has looping and nowait appended to it. These are the result of selecting the Loop Forever and Concurrent Apply options.

5.2Adding the Reset, Write, and Read Transactions

Next the reset, read, and write cycle transactions will be added to the top-level template file. First the reset transaction will be called. Next the write transaction will be called once, and then the read transaction will be called twice.

To apply the reset, read, and write cycle timing transactions:

Scroll down in the editor window until you find the comment block that has this line:
- Add apply calls for timing diagram transactions after this comment block:
- This comment is just below the Apply_CLK_generator statement.
Click in the sramTbench.<language extension> editor window below this comment so that the blinking cursor is in the place where the apply statements should be added.
In the Insert Diagram Subroutine Call dialog, select the Run Once and Wait for Completion radio buttons. This will cause the transactions to run one time each, and run one at a time.
Select the Apply_tbreset() (or tb_tbreset.Execute(); in OpenVera).statement by clicking on it.
Click the Insert button. This will add an Apply statement for the tbreset transaction to the top-level template file.

Select the Apply_tbwrite( addr , data ); statement by clicking on it.

Note: VHDL diagram calls will have two extra parameters - tb_Control and tb_InstancePath. OpenVera diagram calls will be Execute statements (e.g. tb_tbwrite.Execute( addr, data ); ).

Click the Insert button to add an Apply statement for the tbwrite transaction to the top-level template file.
Next, select the Apply statement for tbread and click the Insert button twice to add two tbread statements to the top-level template file.

5.3 Adding an Abort Transaction for the Global Clock

Finally, an Abort transaction must be added to stop the global clock from running (otherwise the simulation would never end). This Abort call should be the last transaction in the top-level template file.

To add an Abort transaction to stop the global clock:

Select the End/Abort Transaction radio button.
Double-click on the CLK_generator statement. This will cause an Abort transaction to be inserted into the top-level template.
Click the Close button to close the Insert Diagram Subroutine Call dialog.

Look at the sramTbench.<language extension> editor window. The Apply statements have been added in the order that they were selected. Notice that there are currently no values for the addr and data variables in the tbwrite and tbread Apply statements. Those values will be entered next.

5.4 Providing Values for Variables in Timing Transactions

The tbwrite and tbread transactions have parameterized state values. These values are passed to the transaction in the Apply statements.

To provide values for the tbwrite and tbread transactions:

Click in the sramTbench.<language extension> editor window and move the cursor to the Apply statements. Each Apply statement appears twice in the editor window, once as a comment and once as a line of code. The comment serves a reminder of the order of the parameters.

Next edit the Apply code lines and replace the state variable names with actual variables that will be passed into the timing diagrams.

Note: Existing code is in italics.

For Verilog type:

Apply_tbwrite('hF0, 'hAE);

Apply_tbread('hF0, 'hAE);

Apply_tbread('hF0, 'hEE);

For VHDL type:

Apply_tbwrite(tb_Control, tb_InstancePath, x"F0", x"AE");

Apply_tbread(tb_Control, tb_InstancePath, x"F0", x"AE");

Apply_tbread(tb_Control, tb_InstancePath, x"F0", x"EE");

Note: Some VHDL 87 compilers will not automatically convert the hex value to a vector string. These values can be type-cast as unsigned to force the conversion.

For OpenVera type:

tb_tbwrite.ExecuteOnce('hF0, 'hAE);

tb_tbread.ExecuteOnce('hF0, 'hAE);

tb_tbread.ExecuteOnce('hF0, 'hEE);

Notice that the tbwrite diagram call statement represents writing the hex value AE to memory cell F0. The tbread diagram calls will then read the value from the same memory cell. The data values provided in the tbread diagram calls will be used to compare with the actual value. The first call to tbread will expect to find a value of hex AE in the address F0. The second call to tbread will expect to find the hex value EE instead. This will cause the sample to report a warning during the second execution of tbread.
Save the top-level template file by right-clicking in the editor window and selecting Save from the Editor context menu.

6) External Simulator Integration (Optional)

The External Simulator Integration feature can be used to automate the use of external simulators such as ModelSim or VCS. It will auto-build the project library and launch the simulator with the test bench already loaded. As a reminder, TestBencher does provide a Verilog simulator, but ModelSim can be used with both dialects of VHDL or with Verilog, and VCS can be used with OpenVera.

To enable External Simulator Integration:

Select the Options > External Program Settings menu option. This will open the External Program Settings dialog.
Check the Enable External Simulator Integration checkbox. This will disable TestBencher's Verilog simulator.
Enter the path to the ModelSim or VCS executable files in the Executable Path edit box. This should be the directory that contains the ModelSim or VCS executable files.
ModelSim users: Select the type of operating system that the ModelSim executable resides on from the Target OS combo box. This will determine the type of script generated to launch ModelSim. When ModelSim is launched using this script the project will be automatically loaded.
If you want TestBencher to automatically launch the simulation, check the Launch Simulation on Run Simulation check box. TestBencher will use a script to launch the simulation. Note that this function is only available if the simulator is running on the same computer as TestBencher.
Click OK to close the External Program Settings dialog and enable the External Simulator Integration feature.

7) Generate and Examine the Test Bench

At this point all the timing diagrams have been created, and the top-level template file that describes the sequencing of the transactions in the test bench has been edited. Now the test bench will be generated from the diagram and MUT files.

To generate the test bench:

Click on the Make TB button in the main TestBencher window. This will use the top-level template file to generate the code for the test bench.

Note: When the test bench has been generated, a dialog will pop up that says "Finished generating test bench. Please check waveperl.log for errors." Close this dialog by clicking OK, and check the waveperl.log tab in the Report window to see if TestBencher encountered any errors during the test bench generation.

Notice that the editor window was updated when the test bench was generated. The file now contains the source code for the top-level module of the test bench. You can scroll through this code to examine each section of the test bench as it is discussed.

6.1 The Test Bench Module

The test bench module contains the signal definitions for all of the transaction diagrams, the MUT instantiation, and component instantiations for all of the transaction diagrams.

Note: If the sramTbench.<language extension> editor window is not open, open it by double-clicking on the file name in the Project window.

The test bench module is located near the beginning of the file. The name of the module is automatically generated from the name of the project and the name of the top-level template file. In this case, the name is sramtest_sramTbench. Depending on the language used, it will be either a module (Verilog), an entity (VHDL), or a class (OpenVera).

Examining the comments of the test bench code will show which segments were produced from the top-level template file. Expansion macros were used to generate the top-level module. Every macro in the top-level template file begins with a '$' and is related to one of the commented code blocks in the generated test bench. The comments in the test bench show which macro created each block of code.

This module also contains the instantiations of the timing transactions, a sequencer that controls the ordering of the transactions, and several code segments that drive the test bench.

The instantiations of the timing transactions are handled by a code segment produced by the macro "ComponentInstantiationsForAllDiagrams." In this case, the four transactions being instantiated are CLK_generator, tbreset, tbread, and tbwrite.

Note for OpenVera users: The instantiations of the timing transactions are instantiations of the diagram class. They are named tb_sramtest, where sramtest is the diagram name. The tb_ indicates that the instantiation is at the top level of the module.

8) Simulate the Test Bench and View Results

This section will describe the processes necessary to simulate the test bench.

TestBencher Pro has a Verilog simulator built-in. To use this simulator, follow the instructions in section 8.1. To use TestBencher's External Simulator Integration feature, follow the instructions in section 8.2. To use a third-party simulator, follow the instructions in section 8.3. Section 8.4 contains information on the data generated by the simulation.

8.1 Simulating the Project with TestBencher's Built in Verilog Simulator

Since TestBencher Pro contains a full Verilog simulator, a Verilog simulation can be run quickly:

Click the yellow test bench compile button. This will cause several signals to be added to the timing diagram. (TestBencher will ask if a new diagram should be used. Click Yes.) These signals monitor various portions of the test bench.

Note: Examine the signal names of the test bench signals in the diagram. The signal names are generated based upon the level within the test bench that they are monitoring. For instance, sramtest_sram_tbench.tbread_status represents the diagram status signal for tbread. This is what the test bench 'sees' from it's side of the port. The most important top-level signals are sramtest_sram_tbench.CBS, sramtest_sram_tbench.WRB, sramtest_sram_tbench.ABUS[7:0], and sramtest_sram_tbench.DBUS[7:0].

Click on the green simulation run button to simulate the project.

8.2 Simulating using the External Simulator Integration Feature

If you are using the External Simulator Integration feature, click the green simulation run button to automatically launch the simulator and build the project libraries. See Section 2.7 of the TestBencher manual (or on-line help) for more information about external simulator integration.

8.3 Simulating with Other Third Party Simulators

The following files are necessary to simulate the project with any third-party simulator:

The HDL file for the MUT (the original model code). For this tutorial either tbsram.v or tbsram.vhd is the MUT file.
One source code file for each timing transaction. These files are named after the timing diagram names. For this tutorial these files are CLK_generator.<language extension>, tbreset.<language extension>, tbwrite.<language extension>, and tbread.<language extension>.
One top-level source code test bench file (this is the expanded top-level template file). For this tutorial it is named sramTbench.<language extension>.
Any additional files that must be included in the working directory.
- Verilog users will need syncad.v from the top-level TestBencher directory.
- VHDL users will need wavelib.vhd and syncad.vhd from the top-level TestBencher directory, plus a project-specific package file called tb_sramtest_tasks.vhd. This file is located in the project directory.
- OpenVera users will need syncad.vrh from the top-level TestBencher directory, plus three project-specific package files called sramtest.if.vrh, sramtest.test_top.v, and tb_sramtest_tasks.vr. These files are located in the project directory.

Note to OpenVera users: When working with a project which contains any user-defined classes, you will also need the package file tb_sramtest_user_classes.vr, where sramtest is the project name. This file will be located in the project directory.

If the simulator is not already running, please launch it at this time. Create a project in the simulator and add the files listed above to the project. These files will be located in the Project directory or in the top-level TestBencher directory.

You will want to be able to view the output of the simulation. If the simulator will automatically create a file for this purpose, simulate the project and allow the file to be created. If not, then create a waveform file and add the signals from the top-level testbench to the file. Then simulate the project.

8.4 View Results

View the simulation waveforms, and notice the following events:

The CLK_generator transaction executes continuously.
The tbreset transaction is executed.
The tbwrite transaction is executed, writing data to the SRAM.
The tbread transaction is executed twice, the first time reading the expected value from the SRAM, and the second time reading an unexpected value.
The unexpected value during the second execution of tbread causes a warning to be asserted and also writes a warning message to the simulation log file.

9) Summary

Congratulations! You have now completed the introduction tutorial for TestBencher Pro. The next TestBencher Pro tutorial discusses the use of a global clock, a sweepable delay and a continuous setup checker. For more information regarding the features available with TestBencher (such as adding library files to a diagram, using markers to create loops in a diagram, and advanced uses for other diagram components) please see the online manual for TestBencher, available through the Help > TestBench Generation Help menu option.

Additional example files can be found in the Examples sub- directory of the installation directory. Many of these files contain text in the timing diagram(s) that specifies what the timing diagram demonstrates. In addition, there is a readme.txt file in the Examples directory that specifies the contents of each subdirectory of the Examples directory.