E
espen.tallaksen@bitvis.no
Guest
AXI4-lite, AXI4-stream, Avalon MM, Avalon Stream, SBI, SPI, I2C, UART, GPIO, GMII and RGMII are all free, open source BFMs and VVCs from UVVM. These interface handling procedures and models are all implemented in standard VHDL and can be used with normal VHDL 2008 compatible simulators like Modelsim, Questa, Riviera Pro, Active HDL and GHDL.
UVVM also has a significant number of support VIP available as free open source. This includes Clock generator, Scoreboard, Queue, Watchdog and Error Injection - in additon of course to the Utility Library with lots of testbench infrastructure support procedures like check_value, check_stable, await_value, await_change, random, clock_generator, block_flag, await_barrier, etc...
UVVM has interface models for all the interfaces above, and more are coming.. So what is an interface model? In UVVM that could be either BFMs (Bus Functional Models) or VVCs (Verification Components). A BFM in UVVM is just a set of procedures allowing simple commands like 'axilite_write(<address>, <data>
' to be executed from a test sequencer/driver. Calling this procedure results in a complete axilite access being handled by the procedure, with all the signal wiggling required to write the given data to the given address location. These high level commands (or transactions) allow all interfaces of the DUT to be accessed in a very simple and understandable manner, making it easy even for SW and HW designers to write good tests. The procedure will also log the access so you get a good overview of what is happening during the simulation. A check-procedure like 'axilite_check(<address>, <expected-data>' will even give you a mismatch report if the actual data from the AXI4-lite interface does not match your expected data.
The VVCs basically provide the same functionality as the BFM, and a VVC does in fact use a BFM to handle the actual interface access. The main advantage of using VVCs is that this allows us to access any number of interfaces simultaneously, whereas a procedure is basically blocking the process calling the procedure - until the procedure is finished - after completing the interface access. Other advantages of VVCs are queuing of commands, structured handling of split transactions, better interface control (e.g. between accesses), and the possibility to add more functionality. VVCs are excellent for reuse.
We recommend to use BFMs when you don't need to check simultaneous action on multiple interfaces, as using BFMs and the Utility Library is dead simple (according to feedback). Thus we also recommend anyone starting with UVVM to first start using the Utility Library and BFMs. For more complex design challenges, VVCs are recommended. Writing test sequences for VVCs is in fact as simple as writing test sequences using BFMs only.
You can find links to Gitbub download, UVVM forum and more info under https://uvvm.org/
NOTE: We recommnend new users to start with UVVM light, which includes the utility library and all the BFMs: https://github.com/UVVM/UVVM_Light
UVVM also has a significant number of support VIP available as free open source. This includes Clock generator, Scoreboard, Queue, Watchdog and Error Injection - in additon of course to the Utility Library with lots of testbench infrastructure support procedures like check_value, check_stable, await_value, await_change, random, clock_generator, block_flag, await_barrier, etc...
UVVM has interface models for all the interfaces above, and more are coming.. So what is an interface model? In UVVM that could be either BFMs (Bus Functional Models) or VVCs (Verification Components). A BFM in UVVM is just a set of procedures allowing simple commands like 'axilite_write(<address>, <data>
' to be executed from a test sequencer/driver. Calling this procedure results in a complete axilite access being handled by the procedure, with all the signal wiggling required to write the given data to the given address location. These high level commands (or transactions) allow all interfaces of the DUT to be accessed in a very simple and understandable manner, making it easy even for SW and HW designers to write good tests. The procedure will also log the access so you get a good overview of what is happening during the simulation. A check-procedure like 'axilite_check(<address>, <expected-data>' will even give you a mismatch report if the actual data from the AXI4-lite interface does not match your expected data.The VVCs basically provide the same functionality as the BFM, and a VVC does in fact use a BFM to handle the actual interface access. The main advantage of using VVCs is that this allows us to access any number of interfaces simultaneously, whereas a procedure is basically blocking the process calling the procedure - until the procedure is finished - after completing the interface access. Other advantages of VVCs are queuing of commands, structured handling of split transactions, better interface control (e.g. between accesses), and the possibility to add more functionality. VVCs are excellent for reuse.
We recommend to use BFMs when you don't need to check simultaneous action on multiple interfaces, as using BFMs and the Utility Library is dead simple (according to feedback). Thus we also recommend anyone starting with UVVM to first start using the Utility Library and BFMs. For more complex design challenges, VVCs are recommended. Writing test sequences for VVCs is in fact as simple as writing test sequences using BFMs only.
You can find links to Gitbub download, UVVM forum and more info under https://uvvm.org/
NOTE: We recommnend new users to start with UVVM light, which includes the utility library and all the BFMs: https://github.com/UVVM/UVVM_Light