Can OSVVM Verification Component be used in VUnit based testbench?
Why OSVVM™? › Forums › OSVVM › Can OSVVM Verification Component be used in VUnit based testbench?
Tagged: VUnit
- This topic has 7 replies, 2 voices, and was last updated 3 months ago by
Jim Lewis.
-
AuthorPosts
-
May 10, 2024 at 02:06 #2391
Hassan
MemberOSVVM 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?
May 10, 2024 at 19:48 #2395Jim Lewis
MemberShort 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:
May 12, 2024 at 00:03 #2398Hassan
MemberDoes OSVVM also provide message passing mechanism like the VUnit does, for creation of BFMs?
May 12, 2024 at 19:07 #2399Jim Lewis
MemberYes. 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/
May 14, 2024 at 02:24 #2401Hassan
MemberVUnit 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?
May 14, 2024 at 02:59 #2402Jim Lewis
MemberOSVVM 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.
May 22, 2024 at 22:57 #2426Hassan
MemberOSVVM 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?
June 5, 2024 at 22:04 #2472Jim Lewis
MemberCurrently 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.
-
AuthorPosts
- You must be logged in to reply to this topic.