Hi,
I read the BFM section on the UVM Cookbok but I’m still confused about the difference between a driver and BFM.
Driver should already be wiggling the pins of the DUT. So why is there a need of a BFM?
Is BFM an additional task that will modify the signals of the driver before giving to the DUT?
Thank you.
Regards,
Reuben
In reply to Reuben:
Hello Reuben ,
Driver doesn’t always wiggle the pins of the DUT. Sometimes you need to delegate all the timed behavior in the Driver to the interface (BFM), and keep the driver untimed and on the TLM level. That approach is very necessary for Co-emulations , if you read the Co-emulations section in the cookbook you will understand the benefits of that.
Also , if you pushed the timing behavior and wiggling the bins to the BFM , you will need only to change the BFM tasks if the timing behavior of the protocol changed , that would be much easier than doing that in the drivers and monitors.
BR,
-Kamal
In reply to Reuben:
The answer to your question is very subjective. I think they are used to describe concepts that sometimes overlap.
In generic electronic terms, a driver is a component that manipulates values on a bus. In UVM terminology, a driver is a component that translates a high-level transaction into a lower lower level, or a set of lower-level transactions. Whether those lower-level transactions are actually pin-wiggles or intermediate transactions to another interface is up to the design of the interface. The main purpose of a driver is to provide stimulus to a bus.
A Bus Functional Model is usually refers to a subset or stand-in for a complete model that may be used to drive and respond to the pin-wiggles on a bus. A BFM usually does not generate stimulus itself, but has an API that can be called to generate stimulus to the bus.
So one could say that a driver could be a component of a BFM, or that a driver could communicate with a BFM. It really depends on your point of view.