Re: [sv-bc] Defparam on member of parameter struct

At 10:08 PM 11/7/2005, Matute wrote:
>>Grouping defparams into a separate file is one of the abuses that came into
>>existence with defparams.
>>
>>In my discussions with Shalom, about the only reasonable use for the
>>deprecated defparam is to change parameters hierarchically-down from the
>>current module without the need to pass the parameter through multiple
>>levels, which is what I currently advocate.
>>
>>A future extension to SystemVerilog might permit downward hierarchical
>>named parameter passing, of the form:
>>
>>alu #(.u1.SIZE=8) alu1 (.*);
>>
>>Where u1 is an instance instantiated inside of the alu1 instance of the alu
>>module, and SIZE is a parameter inside of the u1-instantiated module.
>
>The claim in 26.2 that defparams don't provide functionality beyond that
>of instance overrides is inaccurate. Using instance overrides
>
>- One cannot override parameters in a subscope of the instantiated module.

And Shalom has convinced me that there is some value in this capability; 
hence, it may make sense to extend named parameter passing for downward 
parameters.

Matute caught my typo. His correction is appreciated.

>- One cannot override parameters of a top level module.

IMO this is one of the insidious abuses!

Consider the following ugly example (notice the hierarchical defparam in 
the dff module that causes cyclic updates between the modules by updating a 
top-level tb parameter which again gets passed down through the design):

module tb;
   parameter N   =7;
   parameter SIZE=N+1;
   wire [N:0] q;
   reg  [N:0] d;
   reg        clk, rst_n;

   register #(.WIDTH(SIZE)) r1
       (.q(q), .d(d), .clk(clk), .rst_n(rst_n));

   initial begin
     clk <= 0;
     forever #10 clk = ~clk;
   end

   initial $monitor("q=%b  d=%b  clk=%b  rst=%b",
                    q, d, clk, rst_n);

   initial begin
     init_reset;
     repeat (10) @clk;
     @(negedge clk) $finish;
   end

   task init_reset;
     begin
       d = -1;
       rst_n <= 0;
       @(posedge clk);
       @(negedge clk) rst_n = 1;
     end
   endtask
endmodule

module register #(parameter WIDTH=8)
   (output [WIDTH-1:0] q,
    input  [WIDTH-1:0] d,
    input              clk, rst_n);

   dff #(.N(WIDTH)) d1
      (.q(q), .d(d), .clk(clk), .rst_n(rst_n));
endmodule

module dff #(parameter N=1)
   (output reg [N-1:0] q,
    input      [N-1:0] d,
    input              clk, rst_n);

   // dangerous, hierarchical defparam
   defparam tb.N = N+1;

   always @(posedge clk or negedge rst_n)
     if (!rst_n) q <= 0;
     else        q <= d;
endmodule

>There is a typo in the suggested extension above: should use parenthesis
>instead of '=' in the override, so would read alu #(.u1.SIZE(8)) alu1...
>The abovementioned scheme could be extended to address parameters
>in subscopes. In the example below, the override could be foo #(.fun.p(5)) 
>f();

Acknowledged. Thanks for the correction.

>But it is unclear how top level module parameters could be overriden.

IMO - a very bad idea and practice. I would not vote to enhance 
SystemVerilog to permit this capability.

Could you include an example of where this would be valuable? I would like 
to see if there is a better approach to the problem.

>To illustrate the subscope issue condider the following example
>
>module top;
>   foo f();
>   defparam f.fun.p = 5;
>endmodule // top
>
>module foo;
>   function fun;
>      input in;
>      parameter p = 3;
>      $display("In fun, p = ", p);
>   endfunction // fun
>   integer      i;
>   initial i = fun(1'b0);
>endmodule // foo

Easily modified to avoid the defparam as follows:

module top;
   foo #(.p(5)) f();
endmodule

module foo #(parameter p = 3);
   integer i;

   initial i = fun(1'b0);

   function fun;
      input in;
      $display("In fun, p = %0d", p);
   endfunction
endmodule

>This will print
>
>fun has p =           5
>
>    _Matute

Regards - Cliff

----------------------------------------------------
Cliff Cummings - Sunburst Design, Inc.
14314 SW Allen Blvd., PMB 501, Beaverton, OR 97005
Phone: 503-641-8446 / FAX: 503-641-8486
cliffc@sunburst-design.com / www.sunburst-design.com
Expert Verilog, SystemVerilog, Synthesis and Verification Training