Reply To: Writing a Test Plan, Identifying Transactions, and Documenting BFMs/MIT

[Jim Lewis]

Implementing Transactions
The behavior of a transaction can either be implemented in a verification component (VC) or in the subprogram body (as SendCmd above suggests). Note the acronym BFM means bus functional model and can refer to either a VC or subprogram body. BFM means the model implements only the interface behavior and not internal behavior (such as of a UART board part).

OSVVM created a library of transactions called Model Independent Transactions (MIT). In that library we defined two classes of interfaces: Address Bus (also called Memory Mapped) and Stream. Address Bus transactions are for devices like Axi4Manager, Avalon, Wishbone. Stream transactions are for devices such as UART, xMII, or AxiStream.

When you can use the OSVVM MIT library, writing a verification component takes no more effort than writing a procedure. We call this approach then our “Faster than Lite” approach. This allows us to write a simple blocking verification component to get our testing started and then expand the capability of the VC over time as we need more advanced features.

Hence, it is also our intent to expand the capability of the currently defined classes of transactions and add additional classes of transactions – as needed.