verilog - In a testbench, is there a way to see the internal declared regswires of a module without having to connect them to po

admin管理员组

文章数量:1345447

Let's say we're trying to write a Verilog/SystemVerilog testbench code named SC_TB for module sample_code. Is there a more practical way of seeing what reg B and wire Cw is doing in testbench, without creating a port for them?

module sample_code(
   input A,
   output Z
);

   reg B;
   wire Cw;

   *stuff happens in this code*
endmodule

///testbench code

module SC_TB();
   reg A;
   wire Z;
   
   sample_code SCInst(
      .A(A),
      .Z(Z)
   );
   initial begin
      A=0
      #x a=value;
   end

   initial begin
      $monitor(A,Z)
   end

Currently, to see what "reg B" and "wire Cw" are doing, I would create ports for them, then include those ports in my testbench code. For the internally declared wires(Cw in the sample_code), I would comment them out, then create an output wire port with a similar name. For internally declared reg(reg B in the sample_code), I would also create an output wire port, then assign the internal reg into that wire port. My code and my testbench code based on the sample_code and SC_TB ends up looking like this.

module sample_code(
   input A,
   output Z,
   output wire Cw,
   output wire Bw
);

   reg B;
   //wire Cw;

   assign Bw = B;

   *stuff happens in this code*
endmodule

///testbench code

module SC_TB();
   reg A;
   wire Z;
   wire Cw;
   wire Bw;
   
   sample_code SCInst(
      .A(A),
      .Z(Z),
      .Cw(Cw),
      .Bw(Bw)
   );

   initial begin
      A=0
      #x a=value;
   end

   initial begin
      $monitor(A,Z,Cw,Bw) //it doesnt have to be "monitor", "$display" or just the timing diagram works.
   end

Let's say we're trying to write a Verilog/SystemVerilog testbench code named SC_TB for module sample_code. Is there a more practical way of seeing what reg B and wire Cw is doing in testbench, without creating a port for them?

module sample_code(
   input A,
   output Z
);

   reg B;
   wire Cw;

   *stuff happens in this code*
endmodule

///testbench code

module SC_TB();
   reg A;
   wire Z;
   
   sample_code SCInst(
      .A(A),
      .Z(Z)
   );
   initial begin
      A=0
      #x a=value;
   end

   initial begin
      $monitor(A,Z)
   end

Currently, to see what "reg B" and "wire Cw" are doing, I would create ports for them, then include those ports in my testbench code. For the internally declared wires(Cw in the sample_code), I would comment them out, then create an output wire port with a similar name. For internally declared reg(reg B in the sample_code), I would also create an output wire port, then assign the internal reg into that wire port. My code and my testbench code based on the sample_code and SC_TB ends up looking like this.

module sample_code(
   input A,
   output Z,
   output wire Cw,
   output wire Bw
);

   reg B;
   //wire Cw;

   assign Bw = B;

   *stuff happens in this code*
endmodule

///testbench code

module SC_TB();
   reg A;
   wire Z;
   wire Cw;
   wire Bw;
   
   sample_code SCInst(
      .A(A),
      .Z(Z),
      .Cw(Cw),
      .Bw(Bw)
   );

   initial begin
      A=0
      #x a=value;
   end

   initial begin
      $monitor(A,Z,Cw,Bw) //it doesnt have to be "monitor", "$display" or just the timing diagram works.
   end

• verilog
• system-verilog
• test-bench
• digital-logic

Share Improve this question Follow edited 2 days ago toolic 62.3k2020 gold badges7979 silver badges128128 bronze badges asked 2 days ago Mister MoronMister Moron 1333 bronze badges New contributor Mister Moron is a new contributor to this site. Take care in asking for clarification, commenting, and answering. Check out our Code of Conduct.

Add a comment  | 

1 Answer 1

Sorted by: Reset to default 0

With the old Verilog standard (IEEE Std 1364), we had one way to avoid adding ports unnecessarily: hierarchical specifiers. For example, in your testbench, you could use:

initial begin
    $monitor(A, Z, SCInst.Cw, SCInst.B);
end

In this code, SCInst.B is a hierarchical specifier which allows you to scope down into the design module to display the value of the internal B signal. This is fine for temporary debugging. Refer to IEEE Std 1800-2023 section 23.6 Hierarchical names.

With the new SystemVerilog standard (IEEE Std 1800), we also have the option to use the bind keyword. This method is prefered over the hierarchical specifiers. Refer to IEEE Std 1800-2023 section 23.11 Binding auxiliary code to scopes or instances. This is a good approach when you want to create a monitor, checker or assertions for internal signals of another module.

本文标签：