Testbench partitioning in Verilog

[ned_zeppelin]

I am using Verilog 2001. I have some questions regarding partitioning a testbench into multiple files.

I usually just make a separate testbench for every module, but in this case there are number of modules that all rely on the same clock signals (and each other). Having separate testbenches means having to apply the same changes many places any time a module or signal name is changed.

How can I have one top level testbench that generates the clock signals , instanciates the various modules etc., but use separate files for the various test-cases/stimuli (and simply `include them in the "main" testbench)?

As far as I know, it is not possible to make a global wire/reg, outside of a module? I am used to having .vh files for defines and parameters, but in this case, "global" signals is what I am looking for. Is there a way to do this? Or am I barking up the wrong tree here?

As this is a common verification-scenario, I am really just looking for good advice, so I can begin to structure my testbenches better.

Any good tips?

 

[tariq786]

Why do you want to do this?

Why not have one testbench for all the modules in a design rather than a testbench for each module? Where do you think this could be useful?

Secondly, can you show attach a figure to show what do you really intend to do?

After that i can share my idea with you.

 

[ned_zeppelin]

Well, the reason is to keep the testbench readable and maintainable. It contains 20+ interconnected modules, and would therefore become very large, if all modules should be thoroughly tested in one single file.

My intent is to generate the clocks, instanciate modules etc. in one "main" testbench, and provide test-cases and stimuli in seperate files, instead of having one large file containing everything. I saw this method mentioned in a book ("Advanced FPGA Design: Architecture, Implementation, and Optimization"), but I am not sure how to actually do it (and there wasn't really any examples given in the book).

Here is some simplified code to show you what I am thinking of.

main_tb.v:

[syntax=verilog]module main_tb;
   ////////////////////////////////
   // declare parameters/signals //
   ////////////////////////////////

   /////////////////////////
   // instanciate modules //
   /////////////////////////

   ////////////////////////////////////////////////////////////////////////////////////
   // generate clocks                                                                         //
   ////////////////////////////////////////////////////////////////////////////////////
   
   /////////////////////////
   // test-cases          //
   /////////////////////////
   initial  
     begin: TEST_CASE
		`include "testcase_A.v" // contains testcases/stimuli for module A
		`include "testcase_B.v" // contains testcases/stimuli for module B
		..........
		`include "testcase_whole_system.v" // contains testcases/stimuli for entire system
		
     end // TEST_CASE

endmodule [/syntax]

 

[tariq786]

How can you test individual modules if they are interconnected. I mean if two modules A and B are connected which means some or all of the inputs of B come from A and viceversa, how will you simulate the two separately?

Does that make sense? If you have answer to this, please share with me.

Seniors may also share their opinion.

THanks

 

[ned_zeppelin]

Whenever you have a system of some size, there will be several modules. Some of them may be "deeply" interconnected and others more independent. Regardless, you should always verify the modules seperately (not every counter etc. but every major module) before connecting the whole system, in my opinion. What's the alternative? Connecting everything and spend a month debugging?

Writing a separate testbench for each module, and one for the whole system (which is what i usually do) seems like a waste of time, with a lot of code repetition. Writing one huge testbench seems messy. I am looking for the smart way to do it, I guess.

 

[tariq786]

Lets take a concrete example of AES (Advanced encryption standard core). Here is the document describing the core. Please see Figure 6 on page 9 for the design hierarchy of AES encryption.

https://opencores.org/websvn,filedetails?repname=aes_core&path=/aes_core/trunk/doc/aes.pdf

and here is the RTL design

https://opencores.org/websvn,listin...rtl/verilog/#path_aes_core_trunk_rtl_verilog_

and here is the testbench

https://opencores.org/websvn,filede...aes_core/trunk/bench/verilog/test_bench_top.v


Now please tell me how would you do it differently than the author of the core has done it.

Please let me know if you have any questions.

 

[ned_zeppelin]

Thanks for the reply. Well, the testbench you refer to would be a good test for the whole system. My point however, is that during development of this system, I would want to test the sub-modules (like s_box for example). This makes it easier to explore every module more closely (test its boundaries etc.), and check that it behaves as it should, before connecting it to other modules, making the bugs harder to find. For the AES system that might not be strictly neccessary. But for larger systems, having just one testbench such as this one serves good as a "final test", but is of little use during development of the system.

To illustrate, lets say your system has 40 modules. Many of these are large and complex (several FSMs and complex computational units etc.).

I mean, you can't just design all 40 modules without testing them and see how they behave in the top level testbench. That makes it very difficult to test the boundaries of each module etc.. That is my opinion anyway.

My goal is to be able to reuse these "separate" tests up the hierarchy, in a way. I am however beginning to think I am stuck with having separate testbenches for every major module and one for the top-level module, like I have done in the past.

 

[tariq786]

Dude
The way you have described it is exactly how it is done. You test each complex module individually and then combine with other complex modules which have been already tested.

Seniors can throw some light as well.

 

[ned_zeppelin]

Yeah, I guess so. I was really just trying to make sure there was no better way of doing it . Thanks for your responses.