Bus functional models (BFM)

Bus functional model(BFM) is a model of physical interfaces of the DUT. Presents all the bus level scenario that DUT can experience on the attached bus. BFMs on one side provide the logical interface for the high level transactions interface to test bench components and on another side connect to the physical interface of the DUT.

Typically the BFM by itself will not generate any stimulus. It has to be directed by the tests or test bench to do so. BFM is implemented adhering to the layered functionality proposed by the specification. Application can also be a layer in the BFM in some of the cases. There are cases where multiple application layer can be supported on single lower layer protocol stacks. Lower layers will be mostly application agnostic.

BFM on their transmit side support ability to cover both the legal and illegal space. By default, BFM should behave such that on its transmit side it should be able of produce any scenario within the legal bounds of the specification. When directed it should be able to do error injection on the transmit side to verify the error handling behavior of the DUT. Although default operation should be constrained random but all the randomizations within BFM should be controllable by the user.

On the receive side BFM will check if the DUT behavior is in compliance with the specification. Except for the receive side error injection the default behavior will be in strict adherence to requirement specification. Any deviation from the requirements specification from the DUT’s transmit side will be flagged as error.

BFM Interface

BFM should provide interface for implementing the stimulus generation and response checking at bus transaction level.

• Stimulus generation features
  • Configuration to control the layer’s programmable variables
  • Data and Control transactions at various layers level
  • Error injection at all layers
• Response checking features
  • Protocol checks at all layers
  • Callbacks at all layers for doing functional coverage and scoreboarding
  • Events for test bench and layer synchronisation
  • Statistics of various events
• Clean logging for ease of the debugging

Minimize providing redundant interfaces. That is two types of interfaces for doing the same functionality. Its maintenance nightmare.

BFM Architecture

Every layer should be kept separate. It should not be mixed with other layers.

Data and control interfaces should be kept separate. The data and control interface for both the transmit and receive path should be kept separate.

Data interface is implemented through the data transaction.  Data transaction will help generate the transaction level data traffic covering the characteristics defined by the specification.

Control interface is implemented through a control event transaction.  For example, a low power entry or exit request is a control event. It’s possible that data and control interface concurrency may be desired by the specification. BFM design should be able to support that. Concurrent and asynchronous control event support should be well thought out in advance. For example some interface may support issuing a protocol reset in the middle of the traffic.

Every layer should be cleanly divided into transmit path and receive path. The synchronization between the transmit and receive path can be established through a shared state object. A global configuration object should contain the programmable variables of the layer accessible by both the transmit and receive path.

Three major paths that should be cleanly divided in all the layers of the BFM are:

• Data transaction handling separated out for transmit and receive. Transmit covering the spectrum defined by the specification and on receive side implementing strict checks for adherence to the specification
• Control event transaction for supporting synchronous, asynchronous and concurrent  control events of the bus
• Error injection implementation consisting of both the transmit and receive side error injection

Beyond these general rules, the requirements for the BFM architecture should be driven by the verification plan containing test plan, coverage plan and checks plan. BFM should be able to meet the requirements of the verification plan.

BFM development

The BFM feature development order should also tie in with the milestones planned for the project execution. This does not mean do a partial BFM architecture. BFM although can be implemented as driven by milestones but the architecture should be thought out completely supporting all the requirements of the verification plan.

Its best to build the complete skeleton made up of abstract classes. These can be populated based on the feature being implemented. This ensures that as new features added BFM does look patchy. Its still looks as one clean monolithic structure.  

BFM verification

Early BFM functionality verification, in some cases can be done by connecting BFMs back to back.  This is fine. Key trap to watch out is false positive pass conditions. For example CRC implementation may be incorrect but as both transmit and receive side implementation is done by single engineer it may still flag it as pass.

BFMs play a major role in achieving the desired functional verification quality by capturing the specification knowledge in executable form. Now the similar concept can be applied to functional coverage as well by making intent executable in specification to functional coverage generation.