Thank you for acknowledge the solution provided.
I’m glad that your question has been addressed, I now transition this thread to community support.
Best Regards,
Richard Tan
p/s: If any answer from the community or Intel Support are helpful, please feel free to give best answer or rate 4/5 survey.
Paste the information here in case the link is not working in future:
Writing the testbench and the test program.
"Writing a test bench is as much a skill as an art"
Creating a test bench and the test program for your design is possibly the most important aspect of your design effort. It is rightly said that verification is 80% of the time and effort in a chip design endeavor. While this tutorial does not serve to be your guide on the art of writing test cases for your design, it will help you kickstart your verification effort by helping you quickly setup the test environment and provide you with a baseline for your testbench which you can expand on.
Make sure you have setup the verification environment and the project as described in the Verifying your IP page.
If you haven't already, you need to clone the git repository to get the source code. To do this
Type the following command in a terminal
git clone https://github.com/PurdueAtomDev/de2i150.git
NOTE : You do not need to do this if you have already cloned the public repository previously.
Go to the folder demo_using_bfm
cd demo_using_bfm
This folder contains all the relevant files including the testbench, test program, qsys files using the BFMs etc.
The testbench for the demo project is called "tb.sv" and is available in the demo_using_bfm directory. The structure of a test bench in system verilog is slightly different than regular verilog test bench in that the test cases can be modularized in a test program and instantiated in the test bench without having to actually code all the test cases in the test bench itself. This allows greater flexibility and modularity in the verification environment while also making the actual testbench uncluttered.
This tutorial assumes that you have atleast a basic understanding of creating testbenches in verilog/system verilog. An introduction into the art of writing test benches available in here .
We will now look at how to create the test program for the demo design using the BFMs.
Like mentioned before, the test cases are all contained in a test program which surprisingly enough is called "test_program.sv". The test program is instantiated in the test bench. Following are some key things to keep in mind to setup the test program.
Ensure the correct hierarchy name for the variables TB, SLAVE and MASTER with respect to your design. These are defined in the beginning of the file. The hierarchy should look something like `define SLAVE $root.tb.dut.u0.mm_slave_bfm_0. dut is the top level module of the design. Follow the design hierarchy to get the correct name of the BFM module.
Ensure all the constant definitions accurately reflect the configuration of your design. Note that you may not need all of them.
There are essentially 4 Master BFM Macros and 3 Slave BFM Macros that you may need to tinker with. The actual test case basically creates different types of transactions from the Master BFM (Transactions include read, write, with and without Burst). Modify this to suit your own needs and requirements specific to your design.
The Slave thread after being initialized runs in the background and looks for transactions directed towards it.
Structure of the test program
First the following few Macros are initialized. The description of some of these macros are given below.
// master 0
MACRO_CONFIGURE_AND_PUSH_COMMAND_TO_MASTER()
This macro configures the master BFM to obtain a command from the test program and send it to the BFM model.
MACRO_MASTER_RESPONSE_THREAD()
This is the master thread which is an always block which looks for responses from slave(s) based on requests sent by itself to the slave(s).
// slave 0
MACRO_SLAVE_THREAD(0)
This instantiates the slave thread which is again an always block which looks for any service requests from a master. Every time it receives a request from a master it creates a response and delivers it to the master after appropriate integrity checks of the transaction.
The actual test case begins after the above initializations.
After resetting the device the master sends different types of commands (Reads/Writes) on the bus. The Master and Slave threads initialized above then respond and react to each other based on the transactions going on.
Based on your specific use case you will need to modify the above two macros to suit your needs. The templates provided to you will serve as just that - a template. The real usage of the BFMs will require you to modify their functionality after understanding the structure of the templates.
So how do I proceed ?
Take a look at test_program.sv. It might seem overwhelming at first but read through it a few times without getting into the specifics of all the functions. The description above should give you an intuitive feel of the structure of the code. Again, you may need to use only a sub set of all the functions mentioned. For instance, if you are testing the slave interface of your design you may choose to comment out the Slave thread and related macros. Conversely, you can choose to comment out the Master BFM related macros if you are testing the master interface of your design.
Following are some of the important functions that you may use as a guideline to create your test program. These are available in the template test_program provided to you.
master_send_commands( )
Inputs : num_command, trans, burstmode
Functionality : Creates a set of commands (num_command commands) with the transaction and burst types defined by trans and burstmode arguments.
create_command( )
Inputs: trans, burstmode, slave_id
Functionality : Returns a single command based on the transaction and burst settings received as arguments.
queue_command()
Inputs: Command, Master_ID, Slave_ID
Functionality : Queues up commands to the slave queue and master queue from which the master and slave retrieve transactions and process them one by one.
configure_and_push_command_to_master_<master_id>()
Inputs: Command
Functionality : Assigns the command parameters like address, burst_size, latency and other parameters required to assert the relevant Avalon signals. The API used in this are defined in the BFM models for the master. A complete list of all available API calls is described in [1]
get_expected_command_for_slave()
Inputs: command, slave_id
Functionality : Returns the expected command that the Slave BFM should have received from the slave command queue. Use this to compare against the actual command received by the Slave BFM from the Avalon bus as done in the MACRO_SLAVE_THREAD Macro.
verify_command()
Inputs: actual_cmd, expected_cmd
Functionality : Compares the actual command received by a slave from the Avalon bus vs the expected command from the command queue.
create_response()
Inputs: burstcount
Functionality : Used by the Slave BFM to create a response to a request from a Master. Use this to create a random response. You can use this as a template on how to create a response and create a function on your own which creates a meaningful response instead of a random one.
Occasional Contributor
