[Verilog] Isolate module for testbench when module calls an instance - Possible?

[pigtwo]

Hello all,

I'm wondering if it's possible to testbench a module that calls an instance of another module where the testbench generates the signals of the isolated module also.  That way you can create a testbench for just that one module and not also the one it calls an instance of.  For example imagine the following two modules.

Code: [Select]

module(
   input wire clk,
   output reg num
   );
 
   wreg num_input;

   bottom bottom1(
                           .clk(clk),
                           .num_out(num_input)
                          );

  always @(posedge clk) begin
     num <= num_input + 3;
  end

endmodule


Code: [Select]

module bottom(
   input wire clk,
   output reg num_out
   );

  always @(posedge clk) begin
     num_out <= num_out + 1
  end

endmodule

Now obviously this is a very simple example but it can show my point.  Say I want to write a testbench for module 'top' but I don't want to deal with 'bottom'(imagine bottom involves some work generate it's output that the testbench would have to handle).  Is there anyway that I can isolate 'top' so that I can generate the signals it expects from the 'bottom' instance?

The example I have in real life now is I have an ADC which I've written a testbench for and it's a little cumbersome.  Then I have a module call an instance of this ADC module to get data from it and do some basic processing on the data.  I'd like to test the basic processing of the second module without having to deal with all the stuff associated with the ADC module. 

I kind of doubt this is possible but I thought I'd check.

Thank you!

[Bassman59]

Verilog has the generate statement. You can set a genvar from the test bench, and override it in your ModelSim (or whatever) simulation configuration. use the genvar to enable or disable blocks which include your low-level instance and the always block.

[langwadt]

make a "dummy" adc module that just spits out the data you need

[pigtwo]

@Bassman59 I've never heard of using the generate statement like that but I think I get it.  I'll have to do a little research to fully understand.  Just quickly is the idea to do something like:

Code: [Select]

localparam TB_on = 0;

genvar i;
   if(TB_on) begin
      // Instance and code for verification/simulation
   end else begin
      // Normal instance call here.
   end
endgenerate

@langwadt  I was thinking something like that but the only problem I have is that I need the testbench to generate meaningful data for verification.  This is kind of harder if I have the dummy module outputting data knowing nothing about the testbench and what it's trying to verify.  Maybe the dummy module could have an extra port that just feeds the testbench data to where it needs to go.  I'll have to think about it a little bit more. 

Thanks for the help!

[SiliconWizard]

As langwadt said.

Implement a module as part of your testbench emulating the module you want to exclude (but still need interaction with).

This is often called a 'stub' when dealing with unit testing.

[Bassman59]

@Bassman59 I've never heard of using the generate statement like that but I think I get it.  I'll have to do a little research to fully understand.  Just quickly is the idea to do something like:

Code: [Select]

localparam TB_on = 0;

genvar i;
   if(TB_on) begin
      // Instance and code for verification/simulation
   end else begin
      // Normal instance call here.
   end
endgenerate


That’s basically it.

I don’t know if Verilog has a feature like VHDL’s configurations. A configuration is a mechanism that lets you choose, at elaboration time, which architecture you use for a given entity.

For example, your test bench includes a model of an ADC. A full-up behavioral model of the converter might have a signal of type real for the input voltage and the reference voltage, and it does the “conversion” from volts to an integer with a range specified by the number of bits. And then it takes that conversion result and drives it on the interface that talks to your FPGA.

That’s all well and good, but it’s likely overly complicated, and when verifying your FPGA with this test bench, sometimes it’s easier for you to generate a known data pattern for the integer conversion result, and have that pattern drive the interface.

So you create your model with one entity port list and two architectures, one for the “full” model and one for the simplified model. The test bench instantiates the entity, and it uses a configuration statement to choose which architecture you want to use.

There is a second common use for configurations in test benches. You want to simulate your entire FPGA design, so your test bench instantiates the FPGA top level as well as models of the peripherals it talks to. This is your RTL (bus-functional) simulation. And you can use the exact same test bench to do a timing simulation, using the model generated by your FPGA tools and the SDF file for the timing information. That model has the exact same entity interface as your FPGA, so it can plug right in. Of course the internals of the model are the particular gate-level primitives that you get from the fitter. So to do this you write a configuration for your test bench, and in one configuration you do the RTL and in the other you do the timing model.

It’s all less complicated than my description makes it sound.