The Bus Functional Model (BFM) was conceived during the early days of hardware/software co-verification. At that time, the software would run on an Instruction Set Simulator (ISS) and hardware would be modeled at the Register Transfer Level (RTL) written in either Verilog of VHDL. There is a fundamental difference in the abstractions presented by these two models. The ISS talks in terms of bus cycles and transactions through a procedural interface, while the hardware interface is at the signal level and logic changes on those signals. In hardware, a bus may contain 10s to 100s of signals that have a protocol running on top of them to decide when a requestor has access to the bus, how the transfer between the requestor and the fulfiller is performed (the requestor is unlikely to know where the object of its request is actually located. This is the function of the address map of the system and other factors such as cache memory) and how to perform a data transfer.
The BFM has two interfaces. On one side is a functional interface that accepts transactions and on the other side is a pin interface that operates the requisite bus protocol. The functionality of the BFM is to bridge those two interfaces.
Over time, BFMs have evolved such that they are used to connect these two interfaces for other types of connections. It has thus become a generic translator between the transaction level and a pin interface. Even more recently, with the introduction of methodologies such as the Universal Verification Methodology (UVM), the name has evolved to become a collection of things, including a driver which operates from the testbench side, driving signals into the hardware, a receiver, that translates things happening on signals within the hardware into higher-level information to be consumed by the testbench, and a protocol monitor that ties the two together.
In general, a BFM is not synthesizable and is written using high-level constructs in the language used for the other verification components, such as SystemVerilog.
When using an emulator or hardware prototyping system, there is a desire to migrate part of the BFM onto the hardware so that the signal level information does not have to cross the interface. This would cause the execution speed of the emulator to slow down and waste the valuable resource. Instead, transactions are sent across the interface, although protocol checking may remain in software, and the protocol conversion performed within the emulator. Standards such as the Accellera Standard Co-Emulation Modeling Interface (SCE-MI) are used to connect the pieces across the emulator/simulator interface.