Can OSVVM Verification Component be used in VUnit based testbench?

[Hassan]

OSVVM offers many verification components. If the user testbench is VHDL VUnit based and uses VUnit libraries for a lot of testbench features but wants to use OSVVM verification components (e.g for AXI4), is that possible? If so, what will happen to all the TCL scripts that come with the OSVVM?

[Jim Lewis]

Short answer is yes. OSVVM VC (including AXI4) use items from the other OSVVM libraries, so you will need to compile those. To compile OSVVM, I recommend using the the OSVVM-Scripts. Then in VUnit you can map the OSVVM libraries.

OSVVM VC report errors against the OSVVM AlertLogPkg. You will either want to use the OSVVM AlertLogPkg in your test cases or get the errors from OSVVM and report them in VUnits test reporting utility.

If you don’t start out using OSVVM’s AlertLogPkg and scripting, eventually you may want to try using them as with them you get OSVVM’s reporting. For details on this see: https://osvvm.github.io/Overview/Osvvm3Reports.html and in particular see

• Build Report: https://synthworks.com/papers/riviera/sim_RunAllTestsWithCov.html
• Requirements Report: https://synthworks.com/papers/riviera/reports/sim_RunAllTestsWithCov_req.html
• Test Report: https://synthworks.com/papers/riviera/reports/Axi4Full/TbAxi4_ManagerMemoryRandomTiming1.html
• HTML Log File: https://synthworks.com/papers/riviera/logs/sim_RunAllTestsWithCov_log.html

To understand the debug help this gives us the following is a series of test cases with errors:

• Build Report: https://osvvm.github.io/_static/questa/sim_OsvvmDemo.html
• Test Report: https://osvvm.github.io/_static/questa/reports/Axi4Full/TbAxi4_DemoErrorMemoryReadWrite1.html
• HTML Log File: https://osvvm.github.io/_static/questa/logs/sim_OsvvmDemo_log.html

[Hassan]

Does OSVVM also provide message passing mechanism like the VUnit does, for creation of BFMs?

[Jim Lewis]

Yes. OSVVM calls this capability our Model Independent Transaction Library. It defines a transaction API and a transaction interface. The transaction interface is a record that is intended to be a superset of the information a transaction will need. The transaction API handles everything a transaction needs to do to send a transaction and receive a response back.

Hence, the only thing a VC developer needs to do is write functionality that retrieves the transaction information from the record, executes the transaction, and puts the results (when appropriate) back into the record. All OSVVM VC do this, so there are a number of examples out there.

There are two great way to come up to speed on OSVVM. First you can read the documentation in OsvvmLibraries/Documentation. It is easiest to reading the README.rst (either in text) or on github rendered like html at: https://github.com/OSVVM/Documentation/tree/main

The other great way to learn OSVVM is to take our class Advanced VHDL Testbenches and Verification, see: https://synthworks.com/vhdl_testbench_verification.htm (class) and https://synthworks.com/public_vhdl_courses.htm#VHDL_Test_Bench_Training (schedule).

We offer sessions in UK through FirstEDA https://firsteda.com/online-vhdl-training/ and our partner PLC2 offers classes in Germany https://plc2.com/training/professional-vhdl-testbenches-and-verification-with-osvvm_pw/

[Hassan]

VUnit has concept of “actor”

constant my_receiver : actor_t := new_actor(“my receiver”);

This is used in message passing. So the “transaction interface” I guess contains the information that we are interested to pass e.g for MM write it would be address and data and transfer type (single vs burst) and maybe something about delay in clock cycles to add. But, how is specific VC identified?

[Jim Lewis]

OSVVM connects the transaction interface (a signal of a record type) directly connects the test sequencer (our examples use the name TestCtrl) to the verification component – each have ports of the same type – AddressBusRecType for MM/address bus type interfaces. All the information is passed in the record data structure – with dedicated fields for things like address, data, and configuration values.

So just like your RTL, a specific signal connects the test sequencer to a specific VC.

Currently for single cycle accesses we do:
Write(Mm1Rec, Addr, X"AA") ;

For bursts we support a number of mechanisms, such as:
WriteBurstVector(Mm1Rec, Addr, (X"AA", X"BB", X"CC", X"DD") ) ;

This is actually a short hand for:

PushBurstVecctor(Mm1Rec.WriteBurstFifo, (X"AA", X"BB", X"CC", X"DD") ) ;
WriteBurst(Mm1Rec, Addr, 4) ; 

OSVVM BurstFifos for AXI4 can be configured to either transfer words (defined by the interface width) or bytes (which are then accumulated into the interface data width).

For more information on OSVVM transactions see the Address_Bus_Model_Independent_Transactions_user_guide.pdf in the OsvvmLibraries/Documentation directory. Alternately you can do a see OsvvmLibraries/AXI4/Axi4/TestCases and search for the word Burst.

[Hassan]

OSVVM can generate a lot of test reports at end of a test, I believe the EndOfTestReports exists for this purpose.

Is this feature compatible with VUnit or does it require specific OSVVM scripts and script commands to be run before those design reports can be created?

Also, when you said “… or get the errors from OSVVM and report them in VUnits test reporting utility.”. How does one get errors from OSVVM and report them in VUnit test reporting utility?

[Jim Lewis]

Currently to get the HTML and JUnit XML reports you must use OSVVM scripting. The problem is that both the scripts and the VHDL code writes to the files.

[Author]

Posts