Search code examples
system-veriloguartspi

Bus Functional Models (System Verilog)


I'm looking to design a bus functional model for SPI and UART bus. First, I want to understand if my perception of a bus functional model is correct.

It is supposed to simulate bus transactions, without worrying about the underlying implementation specifics.

For instance, If I were to build a BFM for an SPI bus, the design should be able to simulate transactions on the SPI acting as a master based on some protocol for example reading instructions from a file and then showing them on a simulator accordingly,

For example a generic data transfer instruction, like send_write(0x0c, 0x0f), that sends data byte 0c to the slave address 0f, should drive the Chip Select line low and send the data bits accordingly on the clock edge based on the SPI mode, is my understanding of BFM correct in this case?

Now what I don't understand this is, how is it helpful? Where in between the DUT and the TestBench does a BFM sit, and how does it help a system designer.

I also want to know if there are any reference BFMs that have been built and tested that are available to study,

I'd appreciate if someone could help me with an example, preferably in System Verilog.


Solution

  • So had to research a lot on this so I thought I would answer, but here's an idea of what it is,

    Think of a Bus Functional Model(BFM) that simulates transactions of a bus, like READ and WRITE, reducing the overhead of a testbench of taking care of the timing analysis for the same. There are a lot more interpretations of a BFM, BFMs typically reduce the job of a testbench by making it more data focused.

    Okay that was a high-level answer, let's dig a little deeper,

    Think of BFM as a block that sits within the testbench block as a whole, when the test bench needs to perform a task, for instance, wants to write at a particular address, it asks the BFM to write at that address, the BFM, which is a black box to the test-bench does the transaction whilst taking care of the timing. It can be driven by a file that could be loaded by the test-bench or it could be a bunch of tasks that the test-bench uses to do the transactions.

    The Design Under Test's(DUTs) response to the BFM transacts is of interest to the tester for the design. One may argue that the BFM may change based on DUT, which is what distinguishes a better BFM per say.

    If the BFM could have a configuration vector that could be loaded to initialize and behave according to the DUT specifications, then it becomes portable to helping test other designs.

    Further the BFM, may be defined as abstract virtual functions(in SV), that could have further concrete implementations based on the DUT.

    virtual class apb_bfm;
    pure virtual task writeData(int unsigned addr, int unsigned data);
    pure virtual task readData (int unsigned addr, output int unsigned data);
    pure virtual task initializeSignals();
    endclass
    

    The above BFM abstraction is for the APB Master, that does the tasks mentioned, the low level details of each of these must be encapsulated by interfaces and clocking blocks in order to have sanity of the clocks as well as abstract interface types. I have referenced a book in the section, which describes beautifully how to architect test benches and design Transaction Level Models(TLMs). Reading this will give you a good understanding of how to design one.

    Also this paper on abstract BFMs gives a good idea on how BFMs should be modeled for a good design. The APB example is derived off that.

    The following image on how a BFM could be placed in the test framework was what I could gather from Bergeron's book.

    An implementation of how a BFM could sit in between the test-bench and the Design Under Test

    Hopefully that gives a basic understanding of what BFMs are. Of course writing one and getting it to work is difficult but this basic knowledge would allow you to have a high level picture of it.

    Book Reference: Bergeron, J. (n.d.). Writing TestBenches in System Verilog. Springer.