Open side-bar Menu
 Real Talk
Shiva Borzin, Technial Marketing Manager
Shiva Borzin, Technial Marketing Manager
Shiva has 20 years of experience in Applications and Product Engineering roles in the Semiconductor and EDA industries. Her EDA experience covers physical synthesis, static timing analysis, SDC constraints, and functional verification. In her Technical Marketing role at Real Intent, she brings … More »

Ascent Lint Rule of the Month: DEFPARAM

May 23rd, 2013 by Shiva Borzin, Technial Marketing Manager

This month we are going to look at the use of the  parameter statement in Verilog, which is used to define a constant local to a module.  References to a parameter are made by using its name.  A parameter can be redefined on an instance-by-instance basis in two different ways: parameter redefinition in the instantiation itself, or by using a defparam statement.

 Use of the defparam statement can easily cause confusion and trouble in the following ways:

·         Hierarchically changing the parameters of a module which may not be visible at the level of the affected module

·         Placing the statement in a separate file from the instance being modified

·         Using multiple statements in the same file to change the parameters of an instance

·         Using multiple statements in multiple different files to change the parameters of an instance

To avoid unintended constant redefinitions, some companies disallow the use of defparam statements in their design flows.   In the following example, the value of the parameter top.SIZE is changed at the very bottom level of hierarchy and may easily be missed. The designer may think that the SIZE and WIDTH parameters are still set to 8 as opposed to 4.

module top (q, d, clk, rst);

  parameter SIZE = 8;

  output [SIZE-1:0] q;

  input [SIZE-1:0] d;

  input  clk, rst;

  myregb # (SIZE) r1 (.q(q), .d(d), .clk(clk), .rst(rst));



module myregb (q, d, clk, rst);

  parameter  WIDTH = 8;

  output [WIDTH-1:0] q;

  input [WIDTH-1:0] d;

  input  clk, rst;

  dff # (WIDTH) myflop (.q(q), .d(d), .clk(clk), .rst(rst));



module dff (q, d, clk, rst);

  parameter C = 1;

  output [C-1:0] q;

  input [C-1:0] d;

  input clk, rst;

  reg [ C-1:0] q;

  defparam top.SIZE = 4;

  always @ (posedge clk or posedge rst)

        if (rst) q <= 0;

        else    q<= d;


The Ascent Lint rule DEFPARAM catches the use of defparam statements in Verilog designs so they can be removed. The question remains what is the best way to redefine the value of a parameter that does not cause confusion for designers and waste precious debug time.

Instead of using defparam statements to redefine the value of a parameter, designers are advised to use the named parameter redefinition method introduced in Verilog-2001.   This is a superior method over the positional parameter assignment list introduced in Verilog-1995.    Ascent Lint rule POS_PARAM_LIST catches the cases where positional parameter redefinition is used.  In the above example, the following instantiations use the positional parameter assignment method and will cause two violations if the rule POS_PARAM_LIST is enabled:

  myregb # (SIZE) r1 (.q(q), .d(d), .clk(clk), .rst(rst));

  dff # (WIDTH) myflop (.q(q), .d(d), .clk(clk), .rst(rst));

 To increase clarity of the design and prevent design bugs, the instantiations should use named parameter assignment as:

  myregb # (.WIDTH(SIZE)) r1 (.q(q), .d(d), .clk(clk), .rst(rst));

  dff # (.C(WIDTH)) myflop (.q(q), .d(d), .clk(clk), .rst(rst));

Ascent Lint offers other parameter related rules.  For more information, please leave me a comment or contact Real Intent at

 *Note: The defparam statement has been depreciated, meaning that it may be removed from the Verilog language in a future revision of the Verilog LRM.

References: Clifford E. Cummings, New Verilog-2001 Techniques for Creating Parameterized Models.

Related posts:

Leave a Reply

Your email address will not be published. Required fields are marked *


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

CST Webinar Series

Internet Business Systems © 2016 Internet Business Systems, Inc.
595 Millich Dr., Suite 216, Campbell, CA 95008
+1 (408)-337-6870 — Contact Us, or visit our other sites:
TechJobsCafe - Technical Jobs and Resumes EDACafe - Electronic Design Automation GISCafe - Geographical Information Services  MCADCafe - Mechanical Design and Engineering ShareCG - Share Computer Graphic (CG) Animation, 3D Art and 3D Models
  Privacy Policy