RE: [sv-bc] defparam problems

Hi, Duth  -

*** SYNTHESIS TOOLS??? ***
Before answering your question, let me pose a question to the synthesis 
vendors: Do synthesis tools permit downward-hierarchical defparams? I was 
under the impression that synthesis tools only permitted simple defparams, 
but I would like to hear it straight from the synthesis vendors themselves.

The only substitution for hierarchical parameter passing today is to 
parameterize all levels of the hierarchy and to pass parameters down thru 
the hierarchy. In the following example, the testbench passes WIDTH and 
DEPTH to the pipeline, which passes WIDTH to the register, which passes 
WIDTH to the dff. Of course the parameter names do not have to match but it 
is a good coding practice.

In this example, you can even change the WIDTH and DEPTH from the command line:
+define+WIDTH="32" +define+DEPTH="6"

// FILE: tb.v
`define WIDTH 16
`define DEPTH 5
module tb;
   parameter  WIDTH=`WIDTH;
   parameter  DEPTH=`DEPTH;
   localparam HEXIT=WIDTH>>2;
   wire [WIDTH-1:0] q;
   reg  [WIDTH-1:0] d;
   reg             clk, rst_n;

   pipeline #(.WIDTH(WIDTH), .DEPTH(DEPTH)) r1 (.q(q), .d(d), .clk(clk), 
.rst_n(rst_n));

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

   initial begin
     $monitor("q=%h  d=%h  clk=%b  rst=%b", q, d, clk, rst_n);
     d = -1;
     rst_n <= 0;
     @(posedge clk);
     @(negedge clk) rst_n = 1;
     @(negedge clk) d={HEXIT{4'ha}};
     @(negedge clk) d={HEXIT{4'hc}};
     @(negedge clk) d={HEXIT{4'h9}};
     @(negedge clk) d={HEXIT{4'h6}};
     repeat(20) @(negedge clk) d=$urandom;
     @(negedge clk)  $finish;
   end
endmodule

// FILE: pipeline.v
module pipeline #(parameter WIDTH=8, DEPTH=4)
   (output [WIDTH-1:0] q,
    input  [WIDTH-1:0] d,
    input              clk, rst_n);

   genvar i;
   wire   [WIDTH-1:0] n [0:DEPTH];

   assign n[0] = d;
   assign q    = n[DEPTH];

   generate
     for (i=0; i<DEPTH; i=i+1) begin:p
       register #(.WIDTH(WIDTH)) r (.q(n[i+1]), .d(n[i]), .clk(clk), 
.rst_n(rst_n));
     end
   endgenerate
endmodule

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

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

// FILE: dff.v
module dff #(parameter WIDTH=1)
   (output reg [WIDTH-1:0] q,
    input      [WIDTH-1:0] d,
    input                  clk, rst_n);

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

I would still like to better understand the methodology that engineers are 
using today that causes them to bypass levels of hierarchy to change 
parameters in lower-level modules. Seems like one would want all of the 
reusable design parameters available at the top-level of the design.

If there is strong desire to downward-pass parameters hierarchically, then 
it is probably time to consider the enhanced named parameter passing that 
we have discussed in earlier email messages, especially if it allows us to 
put another nail in the defparam-coffin   :-)

Regards - Cliff


At 11:05 AM 11/9/2005, Premduth Vidyanandan wrote:
>Hi Cliff,
>
>I agree with everything you have to say here - very valid point.
>
>For most one-instance basis, we ask everyone in our company to use the
>inline parameter passing as well. The only question I have is what the
>replacement method for hierarchical defparam passing is. What I mean by
>this is similar to what Shalom was saying:
>
>If I have a parameter on instance A that is buried under B which is
>buried under C, then I can use the defparam from my TB to change the
>value at instance A by using:
>
>myparam.uut.b.a = ..
>
>Does the inline parameter passing option allow for this?
>
>Is there syntax on how to do this with the inline parameter method?
>
>Thanks
>Duth
>
>
>-----Original Message-----
>From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of
>Clifford E. Cummings
>Sent: Wednesday, November 09, 2005 11:49 AM
>To: sv-bc@eda.org
>Subject: [sv-bc] defparam problems
>
>At 11:14 PM 11/8/2005, Bresticker, Shalom wrote:
> >Almost any language construct can be used well or abused. Such is the
> >case with defparam as well. That is one reason why we have guidelines,
> >to avoid problematic usage while allowing reasonable usage.
>
>Shalom is correct that defparams are not the only Verilog construct with
>
>problems that are properly addressed with coding guidelines. But unlike
>most Verilog constructs, the problem with defparams is that most
>possible
>uses of defparams are problematic, which warrants their deprecation from
>
>the Verilog language.
>
> >In more than 15 years of experience with Verilog, I have never
> >encountered a real-life example of any of these pathological uses of
> >defparams. If others have, it just means that we need a lint tool to
> >check that defparams are not doing weird things.
>
>I have not seen all of the pathological cases, but I have experienced a
>number of them.
>
>- Multiple defparams in the same file - seen it - very confusing until
>you
>find the problem
>
>- defparams can be placed before the instance or after the instance and
>I
>have seen engineers group all the defparams either at the beginning of a
>
>file or at the end of a file, pages away from the instances they modify.
>
>They become difficult to track and debug. Named parameter passing places
>
>the instances and parameters together for easy interpretation (great
>documentation style).
>
>- Until just a few years ago, Synopsys DC did not allow parameter
>redefinition using defparam. Only #(positional) parameter passing was
>recognized. I was most disappointed when Synopsys allowed use of
>defparams.
>
>- Defparams in a separate file - IMO it is a bad idea to control local
>variables from a global file. I have seen local defparams overridden by
>global-file defparams. Very confusing until you find the problem.
>
>- Downward hierarchical parameter manipulation using defparams.
>Reasonable
>under controlled conditions (Shalom has mentioned some) but not
>synthesizable and problematic for RTL designers. Seen it! I believe we
>can
>address this with a downward-only hierarchical-name parameter passing
>enhancement - I could support this.
>
>- Upward hierarchical defparams. Why do this? I would like to see the
>compelling methodology that makes this capability a recommended
>solution.
>IMO changing parent-parameters and parameters in a parallel hierarchy
>using
>upward- and cross-referenced defparams is on the same par as
>self-modifying
>code. I have not seen a compelling reason to do this. Anybody want to
>submit an example for scrutiny?
>
>- I have never seen the circular parameter modifying pathological
>example
>that had in my earlier email, but I did find it interesting that one
>vendor
>iterated through 10 cycles before stopping and warning the user that
>cyclic
>parameters might be present.
>
>In addition, the implementation of defparams has triggered some authors
>to
>make other ill-conceived recommendations to avoid the defparam issues.
>
>Bening & Foster - Principles of Verifiable RTL Design, 2nd Edition, pp.
>146-147
>The authors recommend using `define and in-house preprocessors to avoid
>parameter problems. Some of their reasoning is just plain silly, but we
>get
>to the crux of the problem on page 147, starting with the second bullet:
>
>"Parameters have a higher degree of difficulty than `define in their
>implementation by EDA tool developers. As well as startups, major
>established vendors have differences (bugs?) in their implementation of
>parameters."
>
>"We recommend that you let your competitors spend their time on the
>parameter issues while your project sails on to success without
>parameters."
>
>Quite frankly, all the tool vendors have handled parameters correctly,
>forever. Even simple defparams located next to instances have worked
>well.
>So what could Bening and Foster possibly have seen that would cause this
>
>strong (and silly) recommendation? defparam-abuse!
>
>IEEE 1364-2001 - Section 12.2.1
>
>The first paragraph removed defparam orthogonality - no hierarchical
>defparams from a generate statement, which was the right thing to do.
>
>The third paragraph was a poorly conceived editorial comment that we
>have
>already debated: "The defparam statement is particularly useful for
>grouping all of the parameter value override assignments together in one
>
>module." (IMO - this statement should be removed).
>
>The last paragraph was added to the 1995 standard because vendors were
>giving different results based on placement of multiple defparams (yes
>this
>was happening!): "In the case of multiple defparams for a single
>parameter,
>the parameter takes the value of the last defparam statement encountered
>in
>the source text. When defparams are encountered in multiple source
>files,
>e.g., found by library searching, the defparam from which the parameter
>takes it's value is undefined." (The solution proposed in this
>paragraph??
>- we give up!!)
>
>Brad gave an `include-task example that I have never seen anyone try. I
>would like to know why this methodology is recommended. Even this could
>be
>fixed with hierarchical named-parameter passing. The struct-parameters
>could be addressed (if desired) using the named-parameter passing.
>
>My hatred for defparams and my support for defparam-deprecation stems
>from
>the fact that aside from the simple defparams placed next to the
>instances,
>and Shalom's possible downward defparams for behavioral models, every
>other
>use of defparam either an abuse, obscures the redefinition, or
>contributes
>to difficult debug situations.
>
>If there were no reasonable alternative to defparams, then defparams
>would
>offer value, but the Verilog-2001 named parameter passing enhancement
>all
>but removed the need for a defparam statement. But when the potential
>for
>abuse outweighs the potential for correct usage and good design
>practices,
>it is time to remove the problem. "Death to defparams!!"
>
>Regards - Cliff
>
> >Shalom
>
>----------------------------------------------------
>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

----------------------------------------------------
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