Hi UVM forum.
In some examples I see that verification engineers implements the driving methods in the driver class,
and in other examples I see that the driving methods are being implemented in the interface, and the interface itself includes a pointer the the driver class,usually called “proxy”. this interfaces are usually called BFM.
There is one thing that I dont understand.
if the driving methods are implemented in a class it mean that I can use one of the UVM factory override methods in order to add or change the behavior of the methods, this is of course in case that I have another class that extend the original driver. how can I do it if the driving methods are implemented in the interfaces.
simple example would be override the get_and_drive() method to present wrong protocol behavior.
Hi,
The BFM method is useful for Emulation/FPGA prototyping. Here we need to use Dual Top approach (hdl_top with DUT and BFMs instantiated, hvl_top with the run_test() method call).
If you would like to introduce protocol errors specific to interface rule violation through BFMs, then we can add additional tasks in the BFM which do the protocol violation and have those methods called in the extended Driver or Control the existing driver calls through a configuration object.
Please correct me if i am wrong in understanding the issue.
Thank you.
In reply to nagarjuna_u:
When starting with the UVM it is recommended to deal with agents, containing sequencer, driver and monitor with a configuration object. BFMs are delivered sometimes from FPGA providers for their functional cores. If you use this BFM you do not have to implement your driver. But you do n ot have the sequencer. This limits the flexibility and the power of your testbench. Even getting a BFM it is worth to start with the default UVM environment using sequencer/driver. In most cases you can reuse code pieces from the BFM in your driver.