fifo testbench example
For any verification, the minimum requirement are BFM to drive stimulus (e.g. Fifo write) and monitor (e.g. Fifo read) to capture the output. Next, optionally, you can choose several approach to check the integrity of the output. Probably the most widely use approach is the score boarding method along with a reference model to predict the expected output. However, this approach is typically not cycle-accurate, only transaction-accurate, but depending on your testplan, this may good enough.
There are no precise definition of testbench. Some people, like myself, consider everything else beside the DUT to be the testbench (e.g. reference model and BFMs) and the testcase to be the entity that uses the testbench to execute the test. This is similar to what you see in the lab. For example, you have the board (DUT) and you use the testbench which include traffic generator (Ixia or SmartBit), signal generator (oscilloscope), and monitors (oscilloscope or LED/LCD display) to test the board.
For your particular problem, you would need a BFM driver to write into the FIFO and a BFM monitor to read the data out. For the BFM driver, you would assert WREN and DATA at the same cycle, but only if the FIFO full is not asserted. For the BFM monitor, you would assert RDEN only if the FIFO empty is false, and depending on your FIFO timing, capture the data the same cycle or the next.
For the reference model, it is straight forward for the normal situation. What goes in comes out, without any changes. So it's simple to predict the expected result. Every time you write to the FIFO, store the same write data in a queue, for example, inside your reference model. Every time you read from the FIFO, compare the read data with the expected data in that queue. They should match.
- Hung