Bus functional models (BFM)

Bus Functional Models (BFM) in UVM (Independent Verification Methodology)

What is BFM?

A Bus Functional Model (BFM) is a key component in digital verification, representing the physical interface of the Device Under Test (DUT). It simulates the interactions between the DUT and the bus system, ensuring that the DUT can handle all bus-level scenarios it might encounter in a real-world system. BFMs provide an abstracted interface to communicate with the DUT, enabling verification at the transaction level.

Role of BFMs

1. Interface Representation: BFMs model the physical interface of the DUT, presenting both transmit and receive paths for the DUT to interact with the bus. They help in simulating real-world bus interactions, ensuring the DUT behaves according to the specification under various conditions.
2. Layered Functionality: BFMs adhere to a layered approach in their design, in line with the protocol specification. The model typically does not generate stimuli by itself; it is directed by the testbench or specific test cases. Higher layers, such as application-level transactions, may also be included within the BFM, and sometimes multiple application layers can be supported over a single lower-level protocol stack.
3. Stimulus Generation: BFMs are usually passive, meaning they don’t inherently generate stimuli. They rely on test scenarios or testbenches to trigger stimulus generation. However, they are capable of covering both legal and illegal bus transaction spaces. For instance, a BFM will by default cover all valid transaction scenarios but can also inject errors when instructed to verify error handling by the DUT.
4. Error Injection: BFMs are designed to support error injection. While the default operation is to ensure compliance with the specification, directed error injections are used to verify the DUT’s error handling mechanisms. This helps ensure robustness and fault tolerance in the DUT’s implementation.

BFM Interface and Features

The BFM provides an interface to manage stimulus generation and response checking at the transaction level. Key features include:

• Stimulus Generation:
  • Configurable variables for the BFM layers.
  • Data and control transactions for various protocol layers.
  • Error injection across all layers of the BFM model.
• Response Checking:
  • Protocol compliance checks across all layers.
  • Callbacks for functional coverage and scoreboarding.
  • Event handling for synchronization and testbench interaction.
  • Detailed statistics on events, with comprehensive logging for ease of debugging.

The BFM interface should be streamlined, avoiding redundant interfaces that may lead to maintenance challenges.

BFM Architecture

A well-organized BFM architecture is essential for scalability and reusability. Key principles include:

1. Separation of Layers: Each functional layer in the BFM should be kept separate to avoid complexity and mixing of concerns. This modular approach ensures clarity in managing different types of transactions, such as data and control interfaces.
2. Data and Control Interfaces:
   • Data Interface: Handles data transaction traffic, ensuring conformance to the protocol’s data traffic specifications.
   • Control Interface: Manages control event transactions like power management requests, protocol resets, etc. These may need to be executed concurrently with data traffic in some systems, and the BFM must support such concurrency.
3. Transmit and Receive Paths:
   • Transmit Path: The path that initiates bus transactions, with error injection capability.
   • Receive Path: The path that monitors the received transactions for compliance with the specification. Any deviations from the expected behavior are flagged as errors.
4. Error Injection: Both transmit and receive paths must be capable of handling error injections to verify the DUT’s ability to handle erroneous conditions correctly.

Development and Verification of BFMs

1. BFM Development:
   • The BFM development should align with the project milestones, ensuring that the model is implemented in stages but with full functionality.
   • Skeleton Implementation: It’s recommended to first create an abstract skeleton of the BFM, which can then be populated with specific functionality as the project progresses. This ensures the BFM remains cohesive and well-structured as features are added.
2. Early Verification:
   • BFM verification can be performed early by connecting BFMs back-to-back. However, care should be taken to avoid false positives. For example, if both transmit and receive paths are implemented by the same engineer, mistakes like incorrect CRC implementations might go unnoticed, falsely passing the verification.
3. Independent Verification Methodology (IVM):
   • In IVM, the BFM’s role is to abstract the physical bus interactions, ensuring that both positive and negative scenarios are tested. It must integrate well within a broader test environment that includes different testbenches, coverage models, and verification plans.
   • IVM focuses on ensuring that the DUT’s behavior can be verified independently from the implementation environment, using BFMs to simulate realistic conditions that the DUT will face.

Conclusion

The Bus Functional Model (BFM) plays a crucial role in ensuring the proper functionality of the DUT in complex digital systems. It abstracts the physical bus interface, facilitates error injection, and ensures compliance with the protocol specification. The use of BFMs in IVM enhances the reliability and accuracy of the verification process by ensuring that all bus interactions are thoroughly tested. Proper architecture and structured development are essential to building robust BFMs that can support complex verification plans.