7.6 VHDL: TM fill from Random Generator

TestBencher Pro provides functions for randomly posting master transaction calls to a transaction manager's queue, based on the probabilities specified in a weightings table for that transaction manager. The input data for these randomly selected transactions is randomly generated when a transaction is popped from the queue and executed. The randomly generated input values are constrained by the constraint settings for each input variable. This feature is currently only supported in VHDL.

Post Random Transaction Types:

Calls to PostRandomTransactionType will randomly generate one of the master transaction types of the specified TLM and add this transaction to the TLM's transaction manager queue. In converting a directed test bench project into a constrained-random test bench (where transactions are randomly applied to the model under test), you will remove most of the apply calls to master transactors and replace them with PostRandomTransactionType calls. The apply calls to slave transactors will probably remain the same.

Below is an example of code that was put into a sequencer process to generate random transactions:

Post_random_tasaction_code

•Notice that the we started and stopped the clock using regular Apply calls. The clock generator is a slave transaction, so it is not eligible to be randomly generated by the Test Generator.

•The PostRandomTransactionType call puts one randomly chosen transaction into the Transaction Manager's Queue.

•There is a loop around the PostRandomTransactionType call so it will execute and put 5 transactions in the queue.

•There is also a wait call that will force the simulation to continue to run until all the transactions have occurred and the queue is empty (both the read and the write transactions in this example take 300ns to complete, so 5 of these transactions will complete in 1500ns).

Constrain the Random Input Data:

Each time a random transaction is executed, the input arguments for the transaction will be randomly generated, taking into account any constraint definitions for the transactor's input variables.

•Double click on the Class Library List under the Transaction-Level Model branch of the project to open the Classes for Library dialog.

constrain_open_classes_dlg

constraint_classes_dlg

•Select a particular diagram in the Class Definitions tab and then press the Constraints button to view and edit the constraints. Each transactor diagram has its own set of input variables.

•Variables default to the entire legal range for their data types. Here we have edited the range for the delay values.

constrain_constraints_dlg

Setup up the Weightings Table:

A weightings table defines the relative probabilities for the next transaction type based on the type of the most recently posted transaction call. The default weightings table is set inside the $InitializeDiagramTaskCall macro at the top of the Sequencer Process. This default table gives a uniform weighting to all master transactions (each transactor has the same probability that it will execute after any other master transactor). The default table sets the probability of the initialization state to zero (the initialization state is not a transactor type, it just represents the initial state of the TLM before any transactor has been randomly generated).

weight_auto_table

•To change the the weightings, copy the entire SetTransactorWeightings line from inside the above macro, and paste it below the macro. You can then edit this line to have your table values overwrite the default table during simulation.

•The ProjectNameUniformWeighting term needs to be replaced with a state matrix, where the rows represent the last randomly generated master transactor type and the columns define the weighting for the next transactor type. The first row/column is reserved for the reset or starting state of the TLM. The order of the master transactions is the same as they appear in the Transaction Diagrams folder in the Project window.

Weight_set_transactor_weightings

•The table can be typed in or copied from the package file that defines the default weightings table. To copy the table, double click on the tb_ProjectName_Parameters file located in the Associated Files folder of the Transaction-Level Model to view the code.

•Search for UniformWeighting in the package file and copy/paste the table as an argument to a SetTransactorWeightings call in the sequencer.

Weight_find_table

Weight_copy_table

•A zero in the weightings table indicates that a specific transaction will never follow another. The higher the number, the more likely a transaction will follow. The table will accept values from 0 to max integer. Here we made it just as likely that a read will follow a write or vise-a-versa by using 1 in all the spaces that do not involve the initialization state. Filling the last column with 2's would make it twice as likely to generate tbreads than tbwrites. The first column should always contain zeros, because it means that the test bench should not randomly enter the test bench initialization state.