TestBencher uses a weighting table to specify the probability that a particular transaction type will be posted, based on the type of the previous randomly generated transaction type. The default table is set inside the $InitializeDiagramTaskCall macro at the top of the Sequencer Process. This default table gives uniform weighting to all master transactions so that each 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 BFM before any transactor has been randomly generated, so the first column should always contain zeros).
Change the Weighting Function:
•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 tb_ok variable is an automatically generated variable that you can use to capture the return value of TestBencher function calls that return a Boolean value. •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 BFM. The order of the master transactions is the same as they appear in the Transaction Diagrams folder in the Project window. |
•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 Component Model to view the code. •Search for UniformWeighting in the package file and copy/paste the table as an argument to a SetTransactorWeighings call in the sequencer. |
|
•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. |