ISSUE 211

Number 211
Category errata
Synopsis 3.11.2: localparam behavior not clear
State lrmdraft
Class errata-discuss
Arrival-DateDec 05 2002
Originator sharp@cadence.com
Release 2001b: 3.11.2, 12.2.2.1, 12.2.3
Environment
See #150.
Description
The description of localparams could be interpreted in ways
other than what I believe was intended. It says that they
cannot be modified with defparam or named parameter value
assignment, which seems clear. An attempt presumably should
result in an error. However, it also says that they cannot
be modified with ordered parameter value assignment. This
could interpreted different ways. For example:

module my_mem (addr, data);
parameter addr_width = 16;
localparam mem_size = 1 << addr_width;
parameter data_width = 8;
...
endmodule

module top;
...
my_mem #(12, 16) m(addr,data);
endmodule

I believe that the intent was that this would override
addr_width with 12, skip over addr_size (since it is a
localparam, not a parameter), and override data_width
with 16. However, I don't think the standard is clear
about this. Someone could misinterpret this as an
attempt to override mem_size with 16, which would then
produce an error, just like an attempt to override it in
one of the other ways.
Fix
This comes to update the proposal to #211 according to
Shalom's comments on James's proposal.
However, it is not in a final state.
It still needs to be refined according to Steven Sharp's
comments.


In 12.2.2.1

Add the following to the end of the section:

Local parameters cannot be overridden, therefore, they are not
considered part of the ordered list for parameter value assignment.
In the following example, addr_width will be assigned the value of 12
and data_width will be assigned the value of 16. mem_size will not be
explicitly assigned a value due to the ordered list, but will have
the value 4096 due to its declaration expression.

module my_mem (addr, data);

parameter addr_width = 16;
localparam mem_size = 1 << addr_width;
parameter data_width = 8;
...
endmodule

module top;
...
my_mem #(12, 16) m(addr,data);
endmodule


In 12.2.3

Add the following sentence between the first and second sentences:

However, overriding a parameter, whether by a defparam
statement or in a module instantiation statement,
effectively replaces the parameter definition with
the new expression.

Add the following sentence to the paragraph:

If memory_size is updated due to either a defparam or instantiation
statement, then it will take on that value, regardless of the value
of word_size.
Audit-Trail
From: Shalom Bresticker <Shalom.Bresticker@motorola.com>
To: sharp@cadence.com
Cc: etf-bugs@boyd.com
Subject: Re: errata/211: 3.11.2 localparam behavior not clear
Date: Fri, 06 Dec 2002 12:37:58 +0200

A related issue, I think, is what happens when one parameter
(not a localparam)

is a function of another parameter, as described in 12.2.3, and both
are redefined.

For example,

parameter p = 2 * q ;

and both p and q are redefined.

And another related question is, if a parameter is redefined using both
a defparam and a module instantiation,
which takes precedence?


From: Steven Sharp <sharp@cadence.com>
To: etf-bugs@boyd.com
Cc:
Subject: Re: errata/211: 3.11.2 localparam behavior not clear
Date: Sat, 7 Dec 2002 17:11:36 -0500 (EST)

> A related issue, I think, is what happens when one parameter
> (not a localparam)
>
> is a function of another parameter, as described in 12.2.3, and both
> are redefined.
>
> For example,
>
> parameter p = 2 * q ;
>
> and both p and q are redefined.

Once p is redefined by some means, it is no longer defined to be 2*q,
so it doesn't care what happens to q. I don't see an issue.

> And another related question is, if a parameter is redefined using both
> a defparam and a module instantiation,
> which takes precedence?

Section 12.2 actually covers this. The defparam takes precedence.

Steven Sharp
sharp@cadence.com


From: Shalom.Bresticker@motorola.com
To: Steven Sharp <sharp@cadence.com>
Cc: etf-bugs@boyd.com
Subject: Re: errata/211: 3.11.2 localparam behavior not clear
Date: Sun, 8 Dec 2002 14:41:44 +0200 (IST)

> > A related issue, I think, is what happens when one parameter
> > (not a localparam)
> >
> > is a function of another parameter, as described in 12.2.3, and both
> > are redefined.
> >
> > For example,
> >
> > parameter p = 2 * q ;
> >
> > and both p and q are redefined.
>
> Once p is redefined by some means, it is no longer defined to be 2*q,
> so it doesn't care what happens to q. I don't see an issue.

Logical, but I could also make a reverse argument, so I think it needs to be
explicitly specified.

>
> > And another related question is, if a parameter is redefined using both
> > a defparam and a module instantiation,
> > which takes precedence?
>
> Section 12.2 actually covers this. The defparam takes precedence.

You are correct. My oversight. Thanks.


From: Steven Sharp <sharp@cadence.com>
To: etf-bugs@boyd.com
Cc:
Subject: errata/211: question on Verilog-2001 : localparam
Date: Tue, 29 Apr 2003 17:36:17 -0400 (EDT)

I am forwarding this because it shows that others have also found this unclear.


------------- Begin Forwarded Message -------------

From: Tsung-Min Kuo <tmkuo@cadence.com>
Date: Mon, 28 Apr 2003 18:44:41 -0700 (PDT)
To: sharp@cadence.com
Subject: question on Verilog-2001 : localparam
X-Received: By mailgate.Cadence.COM as SAA25367 at Mon Apr 28 18:44:41 2003

Steve,

This is Tsung-Min Kuo from CVA HDL-ICE team.
I have been assigned to work on Verilog-2001 enhancements for Palladium/HDL-ICE.
Have some questions on Verilog-2001 standard.
Hope you can help me to clarify.

In Sec. 12.2.2.1, it is not clear if localparam is counted in the
ordered list for module instance parameter value assignments.
My guess is not, but could not find any clause in standard to support that.
Is my guess correct?
Has this been stated in standard explicitly?

Thanks for your help.

Best Reagrds,

--- Tsung-Min Kuo

------------- End Forwarded Message -------------


Steven Sharp
sharp@cadence.com


From: Shalom Bresticker <Shalom.Bresticker@motorola.com>
To: etf-bugs@boyd.com
Cc:
Subject: errata/211: 3.11.2: localparam behavior not clear
Date: Thu, 14 Aug 2003 18:07:04 +0300

The following is resent in order to preserve it in the database. Shalom.

Date: Mon, 11 Aug 2003 13:06:34 -0700
From: "Brophy, Dennis"<dennisb@model.com>

In regards to issue 211 we discussed this morning, the implementation of
localparam in ModelSim appears to be consistent with the LRM. It may be that
the
words which appear in the LRM do not match the intent of the team.

In 12.2.2.1, the override of values by an ordered list shall follow the order
of
declaration. When a localparam is sandwiched between two other non-local
parameters, it is not possible to pass in the two parameters since the second
value would be targeted to the localparam by LRM definition.

If the intention was to "skip" a localparam, the LRM needs to be modified.
Otherwise, a compliant implementation should issue an error. That is, the code
shown in 211 should be flagged as an error and I think the LRM is clear on that
point:

12.2.2.1 Parameter value assignment by ordered list

The order of the assignments in the module instance parameter value
assignment by ordered list shall follow the order of declaration of
the parameters within the module. It is not necessary to assign values
to all of the parameters within a module when using this method. However,
it is not possible to skip over a parameter.


Date: Mon, 11 Aug 2003 16:19:09 -0700
From: Michael McNamara<mac@verisity.com>

Section 12.2 talks about overriding parameters. It never mentions
localparams.

The localparam is a new datatype introduced with 1364-2001, defined in
Section 3.11.2.

Section 3.11.2 clearly specifies that the value of localparams can not
be overridden using the specific methods that apply to parameters.

I quote:

3.11.2 Local parameters - localparam

Verilog-HDL localparam - local parameter(s) are identical to
parameters except that they can not directly be modified with the
defparam statement or by the ordered or named parameter value
assignment. Local parameters can be assigned to a constant
expression containing a parameters which can be modified with the
defparam statement or by ordered or named parameter value
assignment. See section 12.1.3 for details.

So I believe the LRM is self consistent in this case, with the
exception that the reference to 12.1.3 in Section 3.11.2 should
instead point to 12.2

I also note (again) that an index and/or a table of contents that went
down two levels (which was contained in the DRAFT 6 which we all
approved) would have helped your team immensely in getting this
correct the first time.


Date: Mon, 11 Aug 2003 17:01:42 -0400 (EDT)
From: Steven Sharp<sharp@cadence.com>

Like Mac, I interpret all of the text about overriding parameters as not
applying to localparams because they are not technically parameters.
There is no need for a special rule about skipping localparams for
overrides, any more than there is a special rule about skipping regs
or nets for overrides; the overrides simply don't apply to any objects
other than parameters, which means that they don't apply to localparams.
This results in skipping them when overriding by position (just as you
would skip any other non-parameter declaration), and producing an error
when overriding by name (just as you would produce an error for any other
attempt to override a name that is not a parameter).

However, this argument is weakened by the practice of using the term
parameter elsewhere to refer to both parameters and localparams. It
would have been too much work to change all the old references to
parameters to say "parameters and localparams". It was a lot easier
to just say that localparams act like parameters except in regard to
overrides.

Unfortunately, the description of that exception can be misinterpreted
as meaning that you can try to override localparams just like parameters,
but it produces an error when you do. Nor are the engineers working
on ModelSim the only ones who have come to this conclusion. The
engineer implementing localparams in NC-Verilog came to this same wrong
conclusion, and I had to correct them. This indicates that the text
needs some clarification.


Date: Mon, 11 Aug 2003 17:21:09 -0700
From: Michael McNamara<mac@verisity.com>

My position is that 3.11.2 holds the precise text needed; it is just
that without an index or table of contents, people don't find this.

One addtion that would help would be text in 12.2 that points to
3.11.2.


Date: Wed, 13 Aug 2003 18:12:00 -0400 (EDT)
From: Steven Sharp<sharp@cadence.com>

There are essentially two questions to be answered for this issue.

1. Is it the consensus of the ETF that the intent of the LRM was for
localparams to be ignored/skipped when doing parameter override by
position?

2. Does the existing LRM text need to be changed to make the intent
clearer?


Date: Wed, 13 Aug 2003 15:31:31 -0700
From: Krishna Garlapati<krishna@synplicity.com>

When implementing this feature into the Verilog compiler here, I came
across this question. With a careful reading of the related sections
on parameters and localparams I thought that the intent of the LRM was
clear. I think its pretty explicit that the LRM wants to treat parameters
and localparms differently and hence localparams should not have any impact
on parameter overrides.

I don't object to make changes in the LRM, but I think the intent
is pretty clear.


From: Shalom Bresticker <Shalom.Bresticker@motorola.com>
To: etf-bugs@boyd.com
Cc:
Subject: Re: errata/211: 3.11.2: localparam behavior not clear
Date: Fri, 15 Aug 2003 10:07:01 +0300

I agree with the interpretation that localparams are not part of the ordered list.

I am surprised, however, at those who claim that the text does not need to be
improved.

Claiming that the text actually says what it intends to say is one thing.

It is another thing entirely to claim that the text is so clear that it is not
liable to be misinterpreted.

The FACT is that more than one person HAS misinterpreted the existing text,
which means that it is NOT clear enough.

Please remember that what is clear to you may not be clear to someone else.

Our goal is not just to produce a text which is correct.

It is also to produce a text which will produce correct understanding among its
readers,
otherwise we have done nothing.

That is the esssence of good documentation.

Shalom

From: "James A. Markevitch" <jam@magic.com>
To: etf-bugs@boyd.com
Cc:
Subject: errata/211: PROPOSAL - 3.11.2: localparam behavior not clear
Date: Sun, 2 Nov 2003 19:50:06 -0800 (PST)

In 3.11.2

Change the reference in the first paragraph from 12.1.3 to 12.2.

In 12.2.2.1

Add the following to the end of the section:

Local parameters cannot be overridden, therefore, they are not
considered part of the ordered list for parameter value assignment.
In the following example, addr_width will be assigned the value of 12
and data_width will be assigned the value of 16. mem_size will not be
explicitly assigned a value due to the ordered list, but will have
the value 4096 due to its declaration expression.

module my_mem (addr, data);
parameter addr_width = 16;
localparam mem_size = 1 << addr_width;
parameter data_width = 8;
...
endmodule

module top;
...
my_mem #(12, 16) m(addr,data);
endmodule

In 12.2.3

Add the following sentence between the first and second sentences:

Overriding a parameter, either due a defparam or instantiation
statement, effectively forces the value of the parameter,
independent of any expression associated with the parameter
declaration.

Add the following sentence to the paragraph:

If memory_size is updated due to either a defparam or instantiation
statement, then it will take on that value, regardless of the value
of word_size.
From: Shalom Bresticker <Shalom.Bresticker@motorola.com>
To: "James A. Markevitch" <jam@magic.com>
Cc: etf-bugs@boyd.com
Subject: Re: errata/211: PROPOSAL - 3.11.2: localparam behavior not clear
Date: Mon, 03 Nov 2003 14:16:47 +0200

The proposal is good.

I would slightly modify it as follows:

> In 3.11.2
>
> Change the reference in the first paragraph from 12.1.3 to 12.2.

Delete this change.
Issue #150 already changed the text to be as follows:

"Verilog HDL localparam - local parameter(s) are identical to parameters except
that they can not directly be modified by defparam statements (see 12.2.1) or
module instance parameter value assignments (see 12.2.2). Local parameters can be
assigned constant expressions containing parameters, which can be modified with
defparam statements or module instance parameter value assignments."

> In 12.2.2.1
>
> Add the following to the end of the section:
>
> Local parameters cannot be overridden, therefore, they are not
> considered part of the ordered list for parameter value assignment.
> In the following example, addr_width will be assigned the value of 12
> and data_width will be assigned the value of 16. mem_size will not be
> explicitly assigned a value due to the ordered list, but will have
> the value 4096 due to its declaration expression.
>
> module my_mem (addr, data);
> parameter addr_width = 16;
> localparam mem_size = 1 << addr_width;
> parameter data_width = 8;
> ...
> endmodule
>
> module top;
> ...
> my_mem #(12, 16) m(addr,data);
> endmodule
>
> In 12.2.3
>
> Add the following sentence between the first and second sentences:
>
> Overriding a parameter, either due a defparam or instantiation
> statement, effectively forces the value of the parameter,
> independent of any expression associated with the parameter
> declaration.

I would reword as follows:

"However, overriding a parameter, whether by a defparam statement or in a module
instantiation statement, effectively forces the parameter to a new value,
regardless of any expression associated with the parameter declaration in the
module definition."

> Add the following sentence to the paragraph:
>
> If memory_size is updated due to either a defparam or instantiation
> statement, then it will take on that value, regardless of the value
> of word_size.

--
Shalom Bresticker Shalom.Bresticker@motorola.com
Design & Reuse Methodology Tel: +972 9 9522268
Motorola Semiconductor Israel, Ltd. Fax: +972 9 9522890
POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 441478



From: Steven Sharp <sharp@cadence.com>
To: etf-bugs@boyd.com, Shalom.Bresticker@motorola.com
Cc:
Subject: Re: errata/211: Re: errata/211: PROPOSAL - 3.11.2: localparam behavior not clear
Date: Mon, 3 Nov 2003 19:12:32 -0500 (EST)

> "However, overriding a parameter, whether by a defparam statement or in a
module
> instantiation statement, effectively forces the parameter to a new value,
> regardless of any expression associated with the parameter declaration in the
> module definition."

Note that it is not just a new value. The new value could be an expression
containing other parameters. Not only is the overridden parameter no longer
dependent on any parameters in its old definition, but it is now dependent on
any parameters in its new definition, if they change values. The old
definition has been completely replaced with the new one.

I'm not sure that the word "force" is a good choice here either, given the
existence of force statements, which are unrelated to this.

Steven Sharp
sharp@cadence.com

From: Shalom Bresticker <Shalom.Bresticker@motorola.com>
To: Steven Sharp <sharp@cadence.com>
Cc: etf-bugs@boyd.com
Subject: Re: errata/211: Re: errata/211: PROPOSAL - 3.11.2: localparam behavior
not clear
Date: Tue, 04 Nov 2003 10:20:10 +0200

I agree completely.
Please suggest further improvements.

Shalom


Steven Sharp wrote:

> > "However, overriding a parameter, whether by a defparam statement or in a
> module
> > instantiation statement, effectively forces the parameter to a new value,
> > regardless of any expression associated with the parameter declaration in the
> > module definition."
>
> Note that it is not just a new value. The new value could be an expression
> containing other parameters. Not only is the overridden parameter no longer
> dependent on any parameters in its old definition, but it is now dependent on
> any parameters in its new definition, if they change values. The old
> definition has been completely replaced with the new one.
>
> I'm not sure that the word "force" is a good choice here either, given the
> existence of force statements, which are unrelated to this.
>
> Steven Sharp
> sharp@cadence.com

--
Shalom Bresticker Shalom.Bresticker@motorola.com
Design & Reuse Methodology Tel: +972 9 9522268
Motorola Semiconductor Israel, Ltd. Fax: +972 9 9522890
POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 441478




Fix replaced by Shalom.Bresticker@motorola.com on Tue Nov 4 02:34:09 2003
This comes to update the proposal to #211 according to
Shalom's comments on James's proposal.
However, it is not in a final state.
It still needs to be refined according to Steven Sharp's
comments.


In 12.2.2.1

Add the following to the end of the section:

Local parameters cannot be overridden, therefore, they are not
considered part of the ordered list for parameter value assignment.
In the following example, addr_width will be assigned the value of 12
and data_width will be assigned the value of 16. mem_size will not be
explicitly assigned a value due to the ordered list, but will have
the value 4096 due to its declaration expression.

module my_mem (addr, data);

parameter addr_width = 16;
localparam mem_size = 1 << addr_width;
parameter data_width = 8;
...
endmodule

module top;
...
my_mem #(12, 16) m(addr,data);
endmodule


In 12.2.3

Add the following sentence between the first and second sentences:

However, overriding a parameter, whether by a defparam statement or in a module
instantiation statement, effectively forces the parameter to a new value,
regardless of any expression associated with the parameter declaration in the
module definition.

Add the following sentence to the paragraph:

If memory_size is updated due to either a defparam or instantiation
statement, then it will take on that value, regardless of the value
of word_size.



Fix replaced by etf@boyd.com on Mon Dec 15 09:58:28 2003
This comes to update the proposal to #211 according to
Shalom's comments on James's proposal.
However, it is not in a final state.
It still needs to be refined according to Steven Sharp's
comments.


In 12.2.2.1

Add the following to the end of the section:

Local parameters cannot be overridden, therefore, they are not
considered part of the ordered list for parameter value assignment.
In the following example, addr_width will be assigned the value of 12
and data_width will be assigned the value of 16. mem_size will not be
explicitly assigned a value due to the ordered list, but will have
the value 4096 due to its declaration expression.

module my_mem (addr, data);

parameter addr_width = 16;
localparam mem_size = 1 << addr_width;
parameter data_width = 8;
...
endmodule

module top;
...
my_mem #(12, 16) m(addr,data);
endmodule


In 12.2.3

Add the following sentence between the first and second sentences:

However, overriding a parameter, whether by a defparam
statement or in a module instantiation statement,
effectively replaces the parameter definition with
the new expression.

Add the following sentence to the paragraph:

If memory_size is updated due to either a defparam or instantiation
statement, then it will take on that value, regardless of the value
of word_size.


Unformatted


Hosted by Boyd Technology