11.2 VHDL

This section lists the files generated for pure VHDL models. Combination projects using VHDL and the C++ TestBuilder library are covered in the TestBuilder section. Some advanced features like random constrained data generation, and advanced data structures are supported using the combined TestBuilder and VHDL languages. Also several files are generated for top-level projects that are not generated for sub-projects. These files are marked as top-level project only.

Files needed for simulation:

•projectName.vhd - contains top-level module for project. This is the Transaction-Level Model file (the expanded template file).

•One timing transaction file for each timing diagram in the project:

projectName_diagramName.vhd - contains transaction module.

•All of the MUT files listed in the User Source Files folder in the Project window.

•syncad.vhd - (top-level project only) contains package declaration and body that has various types, functions, and procedures defined that are used throughout the generated test bench code.

•wavelib.vhd - (top-level project only) contains register and latch module definitions that are used by timing diagrams with clocked "Simulated" signals. If there are no clocked simulated signals in the entire test bench then this file is not needed. The files in the User HDL Files folder.

•The following files can be accessed from the project tree under Transaction-Level Model > Associated Files.

•tb_control_types.vhd - (top-level project only) contains signal and variable declarations that are used by the apply call procedures throughout the test bench.

•tb_diagram_types.vhd - (top-level project only) contains package that defines enumerated type for diagram types. Each diagram in project hierarchy is given a different value.

•tb_transaction_manager.vhd - (top-level project only) contains entity/architecture for transaction manager (if enabled anywhere within project hierarchy). This transaction manager is instantiated once in each project that has a transaction manager enabled.

•tb_projectName_tasks.vhd - (optional) If using File I/O then this file will be generated and added to the Associated Files folder for the Transaction-Level Model.

•tb_projectName_parameters.vhd - (optional) contains package that encapsulates the parameters that are passed into each diagram. This package is used by the apply calls to communicate data to/from diagrams.

•tb_projectName_user_classes.vhd - (optional) this file contains record type declarations for user defined classes that exist in the project. This file is added to the Associated Files folder for the Transaction-Level Model during test bench generation.

•tb_libraryName_user_classes.vhd - (optional) one file is generated for each imported (Non-default) library in the project hierarchy. All of these library packages are placed in the Associated Files folder for the Transaction-Level Model of the top-level project during test bench generation.

•There also some package files (collectively know as the syncad library) that are used by TestBencher. When a new project is created a lib/verilog directory is created in the project directory that contains various modules that may or may not be used by the project. Currently, these libraries consist of different clock models that are used based on the types of output clocks used in the timing diagrams.

•TestBencher assumes that your VHDL compiler includes pre-written libraries for packages std_logic_1164, std_logic_textio, and std_logic_arith. If you do not have these library files, you will need to acquire them. (SynaptiCAD can provide these files - contact our sales department.) Analyze (compile) these files and run your simulator.

Procedures for Apply Calls, Transaction Manager, and File I/O

The procedures generated for diagram Apply Calls and Transaction Manager calls have similar syntax and parameters. These procedures can be used in the project template file. In VHDL there is a global variable, tb_control, that is used to control the triggering of transactors and this additional parameter must be passed to Apply and Post calls..

Diagram Apply Calls

The diagram apply calls are defined in the tb_projectName_tasks package. These are usually added to the template file using the Insert Diagram Calls dialog (Section 7.1: Template, Sequencer, and Transaction Calls). However you may type in the apply calls by hand. To apply a diagram that is not in the current project, specify the package path when calling the apply call (i.e. work.tb_projectName_tasks.Apply_diagramName(…) ). An alternate method is to add a use clause statement at the top of the Transaction-Level Model that brings in the task package for the project that contains the diagram. If you use the Insert Diagram Calls dialog, this is handled automatically for you.

Each timing diagram generates several apply call procedures:

Master Transaction Apply Calls:

Apply_diagramName ( signal tb_Control : inout tb_Control_Type;

transactorBfmPath : in string;

<parameters> );

Apply_diagramName_nowait ( signal tb_Control : inout tb_Control_Type;

transactorBfmPath : in string;

<parameters> );

Abort_diagramName ( signal tb_Control : inout tb_Control_Type;

transactorBfmPath : in string);

Slave Transaction Apply Calls:

Apply_diagramName_looping ( signal tb_Control : inout tb_Control_Type;

transactorBfmPath : in string;

<parameters> );

Apply_diagramName_looping_nowait( signal tb_Control : inout tb_Control_Type;

transactorBfmPath : in string;

<parameters> );

Abort_diagramName ( signal tb_Control : inout tb_Control_Type;

transactorBfmPath : in string);

Master Transaction Manager Post Calls:

Post_diagramName ( signal tb_Control : inout tb_Control_Type;

queuePath : in string;

transactorBfmPath : in string;

<parameters> );

Post_diagramName_nowait ( signal tb_Control : inout tb_Control_Type;

queuePath : in string;

transactorBfmPath : in string;

<parameters> );

Post_Abort_diagramName ( signal tb_Control : inout tb_Control_Type;

queuePath : in string;

transactorBfmPath : in string );

Slave Transaction Manager Post Calls:

Post_diagramName_looping ( signal tb_Control : inout tb_Control_Type;

queuePath : in string;

transactorBfmPath : in string;

<parameters> );

Post_diagramName_looping_nowait ( signal tb_Control : inout tb_Control_Type;

queuePath : in string;

transactorBfmPath : in string;

<parameters> );

Post_Abort_diagramName ( signal tb_Control : inout tb_Control_Type;

queuePath : in string;

transactorBfmPath : in string );

Call to Randomly Post a Master Transaction to the Transaction Manager Queue:

PostRandomTransactionType (signal tb_Control : inout tb_Control_Type;

transactorBfmPath : in string);

Calls to Read Calls from a File:

See Section 7.5 VHDL: TM fill from File for syntax on the file.

Parameters for Apply Calls and Transaction Manager Procedures

tb_Control - is a global record that contains control signals needed to trigger transactions. Pass this record into the apply or post calls.

transactorBfmPath - the hierarchical path to the project which contains the transactor you wish to apply. You can type in the full instance path or use the generic tb_LocalBfmPath that contains the project instance path for transactors relative to the current entity.

queuePath - path to project that contains the transaction manager queue that you want to post the apply call to. Typically, this will be tb_LocalBfmPath which is a generic available in all project components and diagrams that specifies the full instance path to the current scope. So, tb_LocalBfmPath would be used if you want to post the apply call to the transaction manager that is owned by the project in which you're calling the Post method from.

fileName - the name of the file on disk that contains a list of transactions.

<parameters> - there will be additional parameters to the apply calls based on the type of parameters that exist for your diagram. Note that the “nowait” apply call procedures will NOT contain any parameters that are outputs from the transaction since the apply call will return immediately to the calling process once the diagram starts.

Examples of Apply Calls and Transaction Manager Procedures

•Example 1. Apply diagram contained in local project

Apply_write( tb_Control, tb_LocalBfmPath, x”AB”, x”EF”);

- writes data EF to address AB

•Example 2. Apply diagram in another project by specifying relative instance path to current project

work.tb_master_tasks.Apply_write( tb_Control,

tb_LocalBfmPath & “master0”, x”AB”, x”EF”);

•Example 3. Apply diagram in another project by specifying full instance path from root

Work.tb_master_tasks.Apply_write( tb_Control,

“PCI.master0”, x”AB”, x”EF”);

Transaction Generator

If the Transaction Manager is enabled then the following functions and weighting table will be generated for the project. These are covered in Section 7.6: TM fill from Random Generator.

•The weightings table is a matrix of the master transactions. The order of the transactions is the order in which they appear in the Project window. Copy this out of the generation macro to the code section of the Sequencer process before editing. An example table might look like:

good := SetTransactorWeightings( tb_LocalBfmPath, ((0, 5, 1),

(0, 1, 1),

(0, 1, 1)));

•The SetTransactorWeightings function registers the weightings matrix. You can change the random weightings at any time during the simulation.

•The PostRandomTransactorType function randomly creates a transaction call and hands it to the Transaction Manager to put on the transaction queue. Each time a transaction is created with this function the transaction arguments are randomly generated using the constraint settings for the variables. Usually this function is used inside of a loop. For example:

for i in 0 to 9 loop

PostRandomTransactorType(tb_Control, tb_LocalBfmPath);

end loop;

Accessing Project Level Variables from a Diagram in VHDL

In VHDL, from a diagram, you have access to any variable that is defined in the owning project. To get access to a project level variable, use the following syntax:

work.tb_projectName_parameters.tb_ProjectVariables(

tb_ProjectID ).variableName

Note: tb_ProjectID is an integer variable that is defined in the project. Each project in the hierarchy receives a unique project id during initialization of the simulation.

For example, if you had a project named master and a project level variable named address, you enter something like the following:

work.tb_master_parameters.tb_ProjectVariables( tb_ProjectID ).address

Data Packing in VHDL

The following two functions are generated in the user class package when packing is enabled for a class:

function pack( dataStructure : className ) return std_logic_vector;

function unpack( packed_data : std_logic_vector(packed_size downto 0) )

return className;

className - a variable that is an instance of a user defined class.

packed_size - the sum of all the packed field bit sizes.

When using the packing options in VHDL, you typically will want to create a variable of type std_logic_vector that has a size that matches the total number of bits in all of the packed fields. This variable is then used when packing and unpacking.