Sunday, November 12, 2006

What are BFMs?

History: Reference: http://www.simpod.com/registered/powerpc-bfm.pdf
The BFM came into existence when FPGAs and ASICs started to interface to other chips for
which a complete, full-functional model was too complex or not available. Engineers realized
that the behavior of devices was less important and what really counts is what happens on the
pins of a chip. A bus functional model is a model that provides a task or procedural interface
to specify certain bus operations for a defined bus protocol. For microprocessors these
transactions usually take the form of read and write operations on the bus. Bus functional
models are easy to use and provide good performance. Unfortunately, BFM accuracy is only
as good as the engineer who wrote it and the data book used to write it. The challenge facing
new projects is where to get bus models and how to guarantee they are accurate.
New methods for model creation are needed that can provide all the benefits of the BFM
without the accuracy problems and the increasing model creation times. (Ref1)
The choice of what kinds of models to use for design verification depends on the skill set and
experience of the engineers involved. Many engineers prefer to write the tests in C and run them
on the target microprocessor. This results in a set of system diagnostics that can then be run on
the final product in the lab. Other engineers who are not familiar with C or assembly language
and do not want to understand how to initialize a microprocessor tend to use bus functional
models to verify system operation. Ease of use and good performance make bus models
attractive for testbench development for ASIC and board simulation. As bus protocols get more
and more complex new techniques for bus model creation and validation are required. One
solution to this problem is to use a hardware modeler to provide the functionality and features of a
bus model. Using a hardware model as a bus model provides the best accuracy, takes the least
time to develop, and has many other uses including full-functional models and HW/SW coverification.
Reference: http://www.simpod.com/registered/powerpc-bfm.pdf

"V) High Level Verification
Reference: http://www.deepchip.com/posts/bsnug00.html

e Reuse Methodology (eRM) Developer Manual
This really takes a very good example and explains the role of BFM is the verification evironment.
4 Typical eVC Architecture
4.1 Basic eVC Architecture
4.1.1 DUT and eVC
4.1.1 DUT and eVC
BFM
Bus Functional Model-- a unit instance that interacts with the DUT and both drives and samples the DUT signals.
Monitor
A unit instance that passively monitors (samples) the DUT signals and supplies interpretation of the monitored activity to the other components of the agent. Monitors can emit events when they notice interesting things happening in the DUT or on the DUT interface. They can also check for correct behavior or collect coverage.
In Figure 4-2, notice that the BFMs have bidirectional arrows to the DUT. This signifies the fact that they can both drive and sample DUT signals. Monitors have unidirectional arrows pointing from the DUT to them. This signifies that they can only sample data from the DUT. Monitors cannot drive DUT signals.

In the XSerial protocol, the XSerial eVC could have two agents-- an RX agent and a TX agent-- where the RX agent is significantly more simple than the TX agent. If the flow control mechanism involves a high level of interaction between the two directions, implement a single-agent eVC to model the flow control mechanism efficiently. The single agent covers both the TX and RX directions. The single agent contains all of the monitors, BFMs, and sequence drivers required for both directions.
4.1.1.1 Diagram Language
file:///opt/specman_5.1/components/sn/docs/online_help/wwhelp/wwhimpl/js/html/wwhelp.htm
5.1 Introduction to SequencesSequences let you define streams of data items sent to a DUT (or streams of actions performed on a DUT interface). You can also use sequences to generate static lists of data items with no connection to a DUT interface.
Sequence Driver
A unit that serves as the mediator between the sequences and the verification environment. The generated items are passed from the sequence to the sequence driver and the sequence driver acts upon them one by one, typically passing them to some kind of BFM (Bus Functional Model). Of course, the sequence driver can be rather empty and, instead of driving items into the DUT, simply place them on a list.
To complete the picture:
* A TCM does the actual driving of items into a specific DUT channel.
* The TCM resides in a BFM unit.
* For the purpose of driving data into the DUT, the sequence driver interacts only with the BFM.
The sequence driver and the BFM work as a pair, where the sequence driver serves as the interface upwards towards the sequences so that the sequences can always see a standard interface to the DUT. The BFM serves as the interface downwards to the DUT, letting you write sequences in any way you find appropriate.
At first, it might seem unnecessary to separate the sequence driver and the BFM. The importance of this separation becomes clear when implementing virtual sequences (see "Using Virtual Sequences").
The execution flow for generation of items and driving them into the DUT is as follows:
* The sequence driver launches the main TCM of a sequence (called body()), which in turn launches the main TCM of any subsequences. (See "Defining the Behavior of Sequences".)
* Sequences generate items on the fly (as part of the execution of their body() TCM).
* Each generated item is passed to the sequence driver, which in turn passes it to the BFM.
file:///opt/specman_5.1/components/sn/docs/online_help/wwhelp/wwhimpl/js/html/wwhelp.htm
Verilog examples of real BFMs.
http://www.gateslinger.com/chiphead/snug99_vbfm.pdf
BFM and reuse:
http://www.us.design-reuse.com/articles/article5164.html
Examples:
Course on web:
http://webcourse.cs.technion.ac.il/236605/Spring2006/
Exercises:
http://webcourse.cs.technion.ac.il/236605/Spring2006/hw/WCFiles/HW2.PDF
Books:
Misc:
Personal experience:

No comments: