ISSUE 634

Edit Proposal  Edit Class, Environment, or Release
Number 634
Notify-List
Category errata
Synopsis 3.11.1: When is a parameter not a parameter?
State proposal
Class errata-simple
Arrival-DateNov 16 2004
Originator Shalom.Bresticker@freescale.com (Behavioral Task Force)
Release 2001c: 3.11.1
Environment
Description

3.11.1 describes how parameters can be declared either
"as a set of module_items or in the module declaration in the module_parameter_port_list".

Then it says,
"If any param_assignments appear in a module_parameter_port_list, then any param_assignments that appear in the module become local parameters and shall not be overridden by any method."

Similarly, 12.2 says,
"There are two different ways that parameters can be defined.
The first is the module_parameter_port_list (see 12.1), and
the second is as a module_item (see 3.11). A module declaration can contain parameter definitions of either or both types, or no parameter definitions."

This is confusing.
It means you write 'parameter' and get 'localparam'.
It would be better to say that parameters can be declared
either entirely in the module header or entirely within the
module body, but not a mixture of both.
We do the same with port declarations.

So the proposal is to change in 12.2 FROM

"A module declaration can contain parameter definitions of either or both types, or no parameter definitions."

AND in 3.11.1 FROM

"If any param_assignments appear in a module_parameter_port_list, then any param_assignments that appear in the module become local parameters and shall not be overridden by any method."

BOTH TO

"A module declaration may contain parameter definitions of
either type (or no parameter definitions), but not of both
types together in the same module declaration. However, local
parameter declarations shall be permitted as module_items within
the module declaration body in any case."

(Thanks to Brad for help.)

Fix
NEW PROPOSAL (2004-11-18):


In 3.11.1, DELETE the sentence:

"If any param_assignments appear in a module_parameter_port_list, then any param_assignments that appear in the module become local
parameters and shall not be overridden by any method."


ADD to the end of 12.2.2.1
("Parameter value assignment by ordered list"):

"If the module declaration contains parameter declarations
in a module_parameter_port_list and additional parameter
declarations as module_items within the module body, then
the order of the assignments in the module instance
parameter value assignment by ordered list shall be the
order of the module_parameter_port_list parameter
declarations followed by the order of the
module_item parameter declarations.

Example:

mod_a #(parameter A=0, B=1) (q) ;
parameter C=2;
input q ;
parameter D=3;
endmodule

module mod_b ;
wire q;
mod_a #(5,6,7,8) mod_a(q); //assigns 5 to parameter A, 6 to B, 7 to C, 8 to D
endmodule"
Audit-Trail

Fix replaced by Shalom.Bresticker@freescale.com on Tue Nov 16 00:11:38 2004

Change in 12.2 FROM

"A module declaration can contain parameter definitions of either or both types, or no parameter definitions."

AND in 3.11.1 FROM

"If any param_assignments appear in a module_parameter_port_list, then any param_assignments that appear in the module become local
parameters and shall not be overridden by any method."

BOTH TO

"A module declaration may contain parameter definitions of
either type (or no parameter definitions), but not of both
types together in the same module declaration. However, local
parameter declarations shall be permitted as module_items within
the module declaration body in any case."



From: "Brad Pierce" <Brad.Pierce@synopsys.com>
To: <etf-bugs@boyd.com>
Cc:
Subject: Re: errata/634: 3.11.1: When is a parameter not a parameter
Date: Tue, 16 Nov 2004 18:33:54 -0800

Shalom,

How would this proposed language impact the question in

http://www.boyd.com/1364_btf/report/full_pr/217.html

of whether parameters declared in named blocks are overridable
when the V2K-style #() notation is used in the module header?

-- Brad


-----Original Message-----
From: owner-etf@boyd.com [mailto:owner-etf@boyd.com]On Behalf Of
Shalom.Bresticker@freescale.com
Sent: Tuesday, November 16, 2004 12:04 AM
To: etf-bugs@boyd.com
Subject: errata/634: 3.11.1: When is a parameter not a parameter


>Number: 634
>Notify-List:
>Category: errata
>Originator: Shalom.Bresticker@freescale.com (Behavioral Task Force)
>Environment:
>Description:


3.11.1 describes how parameters can be declared either
"as a set of module_items or in the module declaration in the
module_parameter_port_list".

Then it says,
"If any param_assignments appear in a module_parameter_port_list, then any
param_assignments that appear in the module become local parameters and
shall not be overridden by any method."

Similarly, 12.2 says,
"There are two different ways that parameters can be defined.
The first is the module_parameter_port_list (see 12.1), and
the second is as a module_item (see 3.11). A module declaration can contain
parameter definitions of either or both types, or no parameter definitions."

This is confusing.
It means you write 'parameter' and get 'localparam'.
It would be better to say that parameters can be declared
either entirely in the module header or entirely within the
module body, but not a mixture of both.
We do the same with port declarations.

So the proposal is to change in 12.2 FROM

"A module declaration can contain parameter definitions of either or both
types, or no parameter definitions."

AND in 3.11.1 FROM

"If any param_assignments appear in a module_parameter_port_list, then any
param_assignments that appear in the module become local parameters and
shall not be overridden by any method."

BOTH TO

"A module declaration may contain parameter definitions of
either type (or no parameter definitions), but not of both
types together in the same module declaration. However, local
parameter declarations shall be permitted as module_items within
the module declaration body in any case."

(Thanks to Brad for help.)

From: Steven Sharp <sharp@cadence.com>
To: etf-bugs@boyd.com, Brad.Pierce@synopsys.com
Cc:
Subject: Re: errata/634: 3.11.1: When is a parameter not a parameter
Date: Tue, 16 Nov 2004 23:33:27 -0500 (EST)

I must say that I thought the rule about parameters becoming localparams
when there is an ANSI-C style parameter header was weird when I first
came across it. I immediately tested our implementation and found that
we had correctly implemented this rule. I would not have been surprised
if we had not.

I don't know how many users are using parameter declarations both places
(and how many of those know that the ones inside the module are local
parameters), but Neil is right about the potential for backward compatibility
issues.

In response to Brad's question, I tested our implementation and determined
that this rule is only being applied to parameters at the module level.
Parameters inside nested scopes are not being treated as localparams. I
don't know how other implementations are treating it, but this is one data
point.

Steven Sharp
sharp@cadence.com

From: Bineet SRIVASTAVA <bineet.srivastava@st.com>
To: "'Steven Sharp'" <sharp@cadence.com>, <etf-bugs@boyd.com>
Cc: "Bineet SRIVASTAVA" <bineet.srivastava@st.com>
Subject: RE: errata/634: 3.11.1: When is a parameter not a parameter
Date: Wed, 17 Nov 2004 11:03:17 +0530

I fully agree with steven for the rule regarding parameters becoming
localparams when there is an ANSI-C style parameter header.

think, it can be resolved as
* Allow parameter override for parameter declarations as a part of module
declaration
* Allow both(mixed) kind of parameter definitions as part of module
declaration (extension to shalom's point); comma separated; in line with
ANSI style port declarations.

Any thoughts??
bineet srivastava


A module declaration may contain parameter definitions of
> either type (or no parameter definitions), but not of both
> types together in the same module declaration
-----Original Message-----
From: owner-etf@boyd.com [mailto:owner-etf@boyd.com] On Behalf Of Steven
Sharp
Sent: Wednesday, November 17, 2004 10:00 AM
To: etf-bugs@boyd.com
Subject: Re: errata/634: 3.11.1: When is a parameter not a parameter


The following reply was made to PR errata/634; it has been noted by GNATS.

From: Steven Sharp <sharp@cadence.com>
To: etf-bugs@boyd.com, Brad.Pierce@synopsys.com
Cc:
Subject: Re: errata/634: 3.11.1: When is a parameter not a parameter
Date: Tue, 16 Nov 2004 23:33:27 -0500 (EST)

I must say that I thought the rule about parameters becoming localparams
when there is an ANSI-C style parameter header was weird when I first came
across it. I immediately tested our implementation and found that we had
correctly implemented this rule. I would not have been surprised if we had
not.

I don't know how many users are using parameter declarations both places
(and how many of those know that the ones inside the module are local
parameters), but Neil is right about the potential for backward
compatibility issues.

In response to Brad's question, I tested our implementation and determined
that this rule is only being applied to parameters at the module level.
Parameters inside nested scopes are not being treated as localparams. I
don't know how other implementations are treating it, but this is one data
point.

Steven Sharp
sharp@cadence.com




From: Shalom.Bresticker@freescale.com
To: Neil Korpusik <Neil.Korpusik@Sun.COM>
Cc: etf-bugs@boyd.com
Subject: Re: errata/634: PROPOSAL - 3.11.1: When is a parameter not a parameter
Date: Wed, 17 Nov 2004 23:26:28 +0200 (IST)

I agree that it may be a concern.

Shalom


On Tue, 16 Nov 2004, Neil Korpusik wrote:

> Doesn't this proposal create an issue of backward compatibility?
> Existing functionality appears to be getting removed.

--
Shalom Bresticker Shalom.Bresticker @freescale.com
Design & Verification Methodology Tel: +972 9 9522268
Freescale Semiconductor Israel, Ltd. Fax: +972 9 9522890
POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 5441478

[ ]Freescale Internal Use Only [ ]Freescale Confidential Proprietary

From: Shalom.Bresticker@freescale.com
To: Brad Pierce <Brad.Pierce@synopsys.com>
Cc: etf-bugs@boyd.com
Subject: Re: errata/634: 3.11.1: When is a parameter not a parameter
Date: Wed, 17 Nov 2004 23:32:23 +0200 (IST)

I don't know.
Maybe we should go the other route, of making them overridable, at least by name.

Shalom


On Tue, 16 Nov 2004, Brad Pierce wrote:

> The following reply was made to PR errata/634; it has been noted by GNATS.
>
> From: "Brad Pierce" <Brad.Pierce@synopsys.com>
> To: <etf-bugs@boyd.com>
> Cc:
> Subject: Re: errata/634: 3.11.1: When is a parameter not a parameter
> Date: Tue, 16 Nov 2004 18:33:54 -0800
>
> Shalom,
>
> How would this proposed language impact the question in
>
> http://www.boyd.com/1364_btf/report/full_pr/217.html
>
> of whether parameters declared in named blocks are overridable
> when the V2K-style #() notation is used in the module header?
>
> -- Brad
>
>
> -----Original Message-----
> From: owner-etf@boyd.com [mailto:owner-etf@boyd.com]On Behalf Of
> Shalom.Bresticker@freescale.com
> Sent: Tuesday, November 16, 2004 12:04 AM
> To: etf-bugs@boyd.com
> Subject: errata/634: 3.11.1: When is a parameter not a parameter
>
>
> >Number: 634
> >Notify-List:
> >Category: errata
> >Originator: Shalom.Bresticker@freescale.com (Behavioral Task Force)
> >Environment:
> >Description:
>
>
> 3.11.1 describes how parameters can be declared either
> "as a set of module_items or in the module declaration in the
> module_parameter_port_list".
>
> Then it says,
> "If any param_assignments appear in a module_parameter_port_list, then any
> param_assignments that appear in the module become local parameters and
> shall not be overridden by any method."
>
> Similarly, 12.2 says,
> "There are two different ways that parameters can be defined.
> The first is the module_parameter_port_list (see 12.1), and
> the second is as a module_item (see 3.11). A module declaration can contain
> parameter definitions of either or both types, or no parameter definitions."
>
> This is confusing.
> It means you write 'parameter' and get 'localparam'.
> It would be better to say that parameters can be declared
> either entirely in the module header or entirely within the
> module body, but not a mixture of both.
> We do the same with port declarations.
>
> So the proposal is to change in 12.2 FROM
>
> "A module declaration can contain parameter definitions of either or both
> types, or no parameter definitions."
>
> AND in 3.11.1 FROM
>
> "If any param_assignments appear in a module_parameter_port_list, then any
> param_assignments that appear in the module become local parameters and
> shall not be overridden by any method."
>
> BOTH TO
>
> "A module declaration may contain parameter definitions of
> either type (or no parameter definitions), but not of both
> types together in the same module declaration. However, local
> parameter declarations shall be permitted as module_items within
> the module declaration body in any case."
>
> (Thanks to Brad for help.)
>
>

--
Shalom Bresticker Shalom.Bresticker @freescale.com
Design & Verification Methodology Tel: +972 9 9522268
Freescale Semiconductor Israel, Ltd. Fax: +972 9 9522890
POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 5441478

[ ]Freescale Internal Use Only [ ]Freescale Confidential Proprietary


Fix replaced by Shalom.Bresticker@freescale.com on Wed Nov 17 23:38:21 2004
NEW PROPOSAL (2004-11-18):


In 3.11.1, DELETE the sentence:

"If any param_assignments appear in a module_parameter_port_list, then any param_assignments that appear in the module become local
parameters and shall not be overridden by any method."


ADD to the end of 12.2.2.1
("Parameter value assignment by ordered list"):

"If the module declaration contains parameter declarations
in a module_parameter_port_list and additional parameter
declarations as module_items within the module body, then
the order of the assignments in the module instance
parameter value assignment by ordered list shall be the
order of the module_parameter_port_list parameter
declarations followed by the order of the
module_item parameter declarations.

Example:

mod_a #(parameter A=0, B=1) (q) ;
parameter C=2;
input q ;
parameter D=3;
endmodule

module mod_b ;
wire q;
mod_a #(5,6,7,8) mod_a(q); //assigns 5 to parameter A, 6 to B, 7 to C, 8 to D
endmodule"


Unformatted



Hosted by Boyd Technology