Reply To: Dissecting the OSVVM AXI Master BFM

[Jim Lewis]

> From my knowledge, VHDL already contains resolution functions for scenarios where something has multiple drivers. So are new functions required to resolve records with multiple drivers?
VHDL has a resolution function for std_ulogic named resolved. Its non-driving element is ‘Z’. Its default value is ‘U’. If you do not initialize it, then the ‘U’ will be the resolved value. As a result, ports have to be initialized with a ‘Z’. This is a tedious methodology. The foundation work I did on transaction interfaces did it this way.

But then, what do we do for integer, real, time, character, …? If you want to be able to send transaction information through a record, you need more types than std_logic and std_logic_vector.

ResolutionPkg uses maximum resolution. If all vendors properly implemented VHDL-2008, we would not need any resolution functions as internally they just call maximum. For maximum resolution, the non-driving element is type’left. The default value is type’left. Hence, no initializations required. It is the easy path to resolution of inout records without using VHDL-2019 features.

Once vendors implement VHDL-2019 features, we will start using mode views.

> Why is there need to have both blocking and non-blocking function calls?
Why blocking? It is the simplest to implement. Some VC need nothing more than blocking. Hence, OSVVM MIT supports blocking.

Blocking transactions are interface independent. Lets say I have two versions of a design, one that has an AXI subordinate interface and one that has an Avalon interface. Lets say, I create two test harnesses for the two different designs that are mirror images of each other, except one uses the AXI based design and an Axi4Manager VC and the other uses the Avalon based design and an Avalon VC.

If I use blocking transactions to write the tests of the functionality the design, then I can use the test cases with either the AXI4 or Avalon test harness. This is why both VC support the same blocking transaction API. The only test cases that are design specific are the ones that verify that the design is either AXI4 or Avalon interface compliant.

Why non-blocking? AXI4 Full interface can support dispatching write and read addresses on the same cycle. OSVVM supports this by using non-blocking transactions and queueing up a number of transactions in the VC. Non-blocking transactions are required to test the full capability of an interface.

Alot of testing can be done with a blocking interface. Writing a VC that only does blocking transactions is the easiest thing to do. Implementing non-blocking transactions in a VC is a level (or more) harder – AXI4 manager I am thinking of you.

Hence, if a project must develop a VC to verify their design, I recommend that they start by using OSVVM MIT and writing a basic blocking VC. This quickly brings us to the point where we are ready to start functionality testing. With OSVVM MIT the VC developer just has focus on writing the interface behavior in the VC’s TransactionHandler. The complexity of doing this is not any more than writing a procedure.

Later if needed grow the capability of the VC to support any needed non-blocking transactions. For interfaces which support independent actions on different aspects of the interface, non-blocking transactions are likely to be necessary. For other interfaces though, it may not be needed at all.