With TestBuilder, the parameters for a transaction apply call are placed into an arguments class of type TProjectName_diagramName_Args. Each apply call has an instance of the arguments class named DefaultArgs that can be used to pass information to the apply call. You can also define other instances and pass them into the run method of the apply call. This is useful when using randomization routines.

Files needed for simulation:

Transaction Parameters for Apply Calls

When TestBuilder Integration is enabled, the parameters (e.g., Applied Parameters and State Variables) for the Apply calls are placed into an Arguments class. This class is then used to pass data to and from the apply calls. If no arguments are specified for an apply call then the DefaultArgs member of the apply call class will be used. The DefaultArgs can be accessed and set before running a transaction in this case.

For example, consider a project with a timing diagram called write that has parameters data and addr. To call the transaction and pass in a data value of 0xAE, and an address value of 0xF0 you would use the following calls:

Tvm.Apply_write.DefaultArgs.addr = 0xF0;

Tvm.Apply_write.DefaultArgs.data = 0xAE;

Tvm.Apply_write.run();

Generating Random Values Using TestBuilder

TestBuilder provides the capability of generating random values for variables, class instances, and apply call parameters. Generation of these values is performed in the Sequencer Process of the Transaction-Level Model in the TestBuilder template file. The values that are generated when the randomize method is called will conform to the constraints that are defined for the data members being randomized. See Section 8.8: Constrained Random Number Generation for more information on constraints. To randomize a variable or class instance:

TestBuilder Methods for use with Transaction Manager

The following methods are available for the TestBuilder Transaction Manager. The post diagram calls insert the transaction into the Transaction Manager’s queue. The apply file calls hand an entire file to the transaction manager.

Diagram Method Calls: For each diagram there are three transaction classes (once, looping, and abort). For each of the transaction classes there are two diagram methods are defined: Post and Post_nowait. The post diagram calls insert the transaction into the Transaction Manager’s queue. To call one of these methods from the template file use either the relative diagram name or the instance name of the subproject (ie. tvm.Apply_diagramName_looping.Post(…) or tvm.projectInstanceName.Apply_diagramName_once.Post(…) .

Post ( TransactionManager, <parameters> );

Post_nowait( TransactionManager, <parameters> );

TransactionManager - For each project with a transaction manager enabled, there will be a model called TransactionManager that is instantiated in the Transaction-Level model. If you are posting to the manager in the current project use TransactionManager for this parameter. If you are posting to a subprojects manager use subprojectInstanceName.TransactionManager.

<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.

For example, consider a project with a timing diagram called write that has parameters data and addr. To post a write transaction to run once you would use the following calls:

Tvm.Apply_write.DefaultArgs.addr = 0xF0;

Tvm.Apply_write.DefaultArgs.data = 0xAE;

Tvm.Apply_write.Post( TransactionManager );

Transaction Manager Methods

ApplyFile ( const char* filename ) 

This method sets the file name for which the transaction manager will pull apply calls from. This method is blocking. This method will not return until the last apply call in the file has been placed on the transaction manager’s queue.

ApplyFile_nowait ( const char* filename ) 

This method performs the same actions as ApplyFile except that it is spawned off in another process and returns control to the calling method immediately.

SetApplyCallMode ( TApplyCallMode mode )

Sets the mode of the transaction manager. By default it is set to looping so that transactions are executed when they are available in the queue. TApplyCallMode can be any of the following:

TB_ONCE - If this is set then ApplyNextTransaction() controls when apply calls are taken off of the transaction manager's queue and applied.

TB_LOOPING - run the next transaction from the queue whenever there are apply calls in the queue.

TB_SUSPEND - finish running the current transaction and stop reading apply calls from the queue until the apply call mode is changed or ApplyNextTransaction is called.

ApplyNextTransaction() 

If the apply call mode is set to TB_ONCE then this will cause the next apply call on the queue to be pulled off and run.

Post_ApplyCall ( tbvTaskT* const taskP )

This method is not normally used directly by user written code. It is used within the diagram port methods to post apply calls to the transaction manager. This method could be used directly if you create the tbvTaskT object manually. Each transaction has three corresponding classes defined that derives from tbvTaskT and are named TApply_projectName_diagramName, TApply_projectName_diagramName_looping, TAbort_projectName_diagramName.

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 9.5.