ISSUE 13

Number 13
Category errata
Synopsis 12.2.2:example of named param passing before its description
State lrmdraft
Class errata-discuss
Arrival-DateAug 12 2001
Originator
Release 2001b: 12.2.2.1, 12.2.2.2
Environment
Description


"8. Named Parameter Association (Section 12.2.2.2)
===========================

The example for named parameter association is given before the
section that describes named parameter association. I suggest that
we remove the code that shows named parameter association in the
example on Pg. 189.

In addition, the section corresponding to named parameter assignment
has no example (at least in the pages faxed to me).

I suggest adding an example that shows the following:

- basic named parameter assignment
- named parameter assignment where the parameter expression is
not specified"
Fix
SEE: Example at the end of section 12.2.2.1 and the
paragraph just before the example.

WAS: "Consider the following example, where the parameters
within module instance mod_a are changed during
instantiation." (and replace the example)

PROPOSED: Consider the following example, where the
parameters within module instances mod_a,
mod_c, and mod_d are changed during
instantiation. 


module tb1;

  wire [9:0] out_a, out_d;
  wire [4:0] out_b, out_c;
  reg  [9:0] in_a, in_d;
  reg  [4:0] in_b, in_c;
  reg        clk;

  // testbench clock & stimulus generation code ...
  
  // Four instances of vdff with parameter value assignment by ordered list

  // mod_a has new parameter values size=10 and delay=15
  // mod_b has default parameters (size=5, delay=1)
  // mod_c has one default size=5 and one new delay=12
  //   Note that in order to change the value of delay,
  //   it is necessary to specify the (default) value of size as well.
  // mod_d has a new parameter value size=10. delay retains its default value

  vdff #(10,15) mod_a (.out(out_a), .in(in_a), .clk(clk));
  vdff          mod_b (.out(out_b), .in(in_b), .clk(clk));
  vdff #( 5,12) mod_c (.out(out_c), .in(in_c), .clk(clk));
  vdff #(10)    mod_d (.out(out_d), .in(in_d), .clk(clk));

endmodule

module vdff (out, in, clk);
  parameter size=5, delay=1;
  output [size-1:0] out;
  input  [size-1:0] in;
  input             clk;
  reg    [size-1:0] out;
  
  always @(posedge clk)
    #delay out = in;

endmodule


SEE: Section 12.2.2.2. Add the following to the end of
section 12.2.2.2



PROPOSED:

Consider the following example, where both parameters of
mod_a and only one parameter of mod_c and
mod_d are changed during instantiation.


module tb2;

  wire [9:0] out_a, out_d;
  wire [4:0] out_b, out_c;
  reg  [9:0] in_a, in_d;
  reg  [4:0] in_b, in_c;
  reg        clk;

  // testbench clock & stimulus generation code ...
  
  // Four instances of vdff with parameter value assignment by name

  // mod_a has new parameter values size=10 and delay=15
  // mod_b has default parameters (size=5, delay=1)
  // mod_c has one default size=5 and one new delay=12
  // mod_d has a new parameter value size=10. delay retains its default value

  vdff #(.size(10),.delay(15)) mod_a (.out(out_a), .in(in_a), .clk(clk));
  vdff                         mod_b (.out(out_b), .in(in_b), .clk(clk));
  vdff #(.delay(12))           mod_c (.out(out_c), .in(in_c), .clk(clk));
  vdff #(.delay( ), .size(10)) mod_d (.out(out_d), .in(in_d), .clk(clk));

endmodule


module vdff #(parameter size=5, delay=1)
  (output reg [size-1:0] out,
   input      [size-1:0] in,
   input                 clk);

  always @(posedge clk)
    #delay out = in;

endmodule


It shall be legal to instantiate modules using different
types of parameter redefinition in the same top-level
module. Consider the following example, where the parameters
of mod_a are changed using parameter redefinition by
ordered list and the second parameter of mod_c is
changed using parameter redefinition by name during
instantiation.


module tb3;
  // declarations & code ...

  // legal mixture of instance with positional parameters and 
  // another instance with named parameters

  vdff #(10, 15)     mod_a (.out(out_a), .in(in_a), .clk(clk));
  vdff               mod_b (.out(out_b), .in(in_b), .clk(clk));
  vdff #(.delay(12)) mod_c (.out(out_c), .in(in_c), .clk(clk));

endmodule


It shall be illegal to instantiate any module using a
mixture of parameter redefinitions by order and by name as
shown in the instantiation of mod_a below.


  // mod_a instance with ILLEGAL mixture of parameter assignments
  vdff #(10, .delay(15)) mod_a (.out(out_a), .in(in_a), .clk(clk));


Audit-Trail

From: Shalom Bresticker <Shalom.Bresticker@motorola.com>
To: btf-bugs@boyd.com
Cc:
Subject: Re: errata/13: 12.2.2: bad documentation
Date: Thu, 14 Nov 2002 15:18:06 +0200

>Category: errata
>Confidential: no
>Originator: Shalom Bresticker <Shalom.Bresticker@motorola.com>
>Release: 2001b
>Class: TBD
>Description:
Section #'s should be 12.2.2.1, 12.2.2.2.

Stephen, please update.

Thanks,
Shalom


From: Shalom Bresticker <Shalom.Bresticker@motorola.com>
To: etf-bugs@boyd.com
Cc:
Subject: Re: errata/13: PROPOSAL - 12.2.2: bad documentation
Date: Thu, 19 Dec 2002 10:28:57 +0200

Comments inside:

etf@boyd.com wrote:

> ISSUE 13 notes that the current example at the end of section 12.2.2.1 shows named parameter passing before it is described (in the next section). I agree that the example should be modified. I also agree that additional examples should be added to section 12.2.2.2. Proposals below (better formatting also in the proposed examples).


>
> SEE: Example at the end of section 12.2.2.1 and the paragraph just before the example.


>
> WAS: Consider the following example, where the parameters within module instance mod_a are changed during instantiation. (and replace the example)


>
> PROPOSED: Consider the following example, where the parameters within module instances mod_a and mod_c are changed during instantiation.

>
> 
module tb1;
 >   wire [9:0] out_a;
 >   wire [4:0] out_b, out_c;
 >   reg  [9:0] in_a;
 >   reg  [4:0] in_b,  in_c;
 >   reg        clk;
 >
 >   // testbench clock & stimulus generation code ...
 >
 >   // Three instances of vdff with positional parameters
 
 A. Here and elsewhere the term "positional" is used. This term is not defined in the standard. The term is "by ordered list". Alternately, change 'assignment by ordered list' in 12.2.2 and 12.2.2.1 to 'assignment by ordered list ("positional assignment")'.
 
 >
 >   // mod_a has new parameter values size=10 and delay=15
 >   // mod_b has default parameters (size=5, delay=1)
 >   // mod_c has one default size=5 and one new delay=12
 
 B. Change the comment to explain that in order to change the second parameter, 'delay', you have to specify the first one, 'size', as well, even though you want it to retain its default value.
 
 >
 >   vdff #(10,15) mod_a (.out(out_a), .in(in_a), .clk(clk));
 >   vdff          mod_b (.out(out_b), .in(in_b), .clk(clk));
 >   vdff #( 5,12) mod_c (.out(out_c), .in(in_c), .clk(clk));
 > endmodule
 
 C. I would like to see one more example, in which only the first parameter is changed "vdff #(10)" and explain that the second retains its default value.
 
 >
 >
 > module vdff (out, in, clk);
 >   parameter size=5, delay=1;
 >   output [size-1:0] out;
 >   input  [size-1:0] in;
 >   input             clk;
 >   reg    [size-1:0] out;
 >
 >   always @(posedge clk)
 >     #delay out = in;
 > endmodule

>
> SEE: Section 12.2.2.2. Add the following to the end of section 12.2.2.2


>
> PROPOSED:

> Consider the following example, where both parameters of mod_a and only the second parameter of mod_c are changed during instantiation.

>
> 
module tb2;
 >   wire [9:0] out_a;
 >   wire [4:0] out_b, out_c;
 >   reg  [9:0] in_a;
 >   reg  [4:0] in_b,  in_c;
 >   reg        clk;
 >
 >   // testbench clock & stimulus generation code ...
 >
 >   // Three instances of vdff with named parameters
 >   // mod_a has new parameter values size=10 and delay=15
 >   // mod_b has default parameters (size=5, delay=1)
 >   // mod_c has one default size=5 and one new delay=12
 >   vdff #(.size(10), .delay(15))
 >                      mod_a (.out(out_a), .in(in_a), .clk(clk));
 >   vdff               mod_b (.out(out_b), .in(in_b), .clk(clk));
 >   vdff #(.delay(12)) mod_c (.out(out_c), .in(in_c), .clk(clk));
 > endmodule
 
 D. I would like to see an example an which the parameters appear out of order: "vdff #(.delay(15), .size(10))"
 and an example in which no value is specified for one of the parameters, ".delay()".
 
 >
 >
 > module vdff #(parameter size=5, delay=1)
 >   (output reg [size-1:0] out,
 >    input      [size-1:0] in,
 >    input                 clk);
 >
 >   always @(posedge clk)
 >     #delay out = in;
 > endmodule

>
> It shall be legal to instantiate modules using different types of parameter redefinition in the same top-level module. Consider the following example, where the parameters of mod_a are changed using positional parameter redefinition and only the second parameter of mod_c is changed using named parameter redefinition during instantiation.

>
> 
module tb3;
 >   // declarations & code ...
 >
 >   // legal mixture of instance with positional parameters and
 >   // another instance with named parameters
 >   vdff #(10, 15)     mod_a (.out(out_a), .in(in_a), .clk(clk));
 >   vdff               mod_b (.out(out_b), .in(in_b), .clk(clk));
 >   vdff #(.delay(12)) mod_c (.out(out_c), .in(in_c), .clk(clk));
 > endmodule

>
> It shall be illegal to instantiate any module using a mixture of positional and named parameter redefinitions as shown in the instantiation of mod_a below.


E. This is actually stated in the last sentence of the first paragraph of 12.2.2.

Shalom

>
>
> 
module tb4;
 >   // declarations & code ...
 >
 >   // mod_a instance with ILLEGAL mixture of both positional and
 >   // named parameters
 >   vdff #(10, .delay(15)) mod_a (.out(out_a), .in(in_a), .clk(clk));
 >   vdff                   mod_b (.out(out_b), .in(in_b), .clk(clk));
 >   vdff #(.delay(12))     mod_c (.out(out_c), .in(in_c), .clk(clk));
 > endmodule

>
> http://boydtechinc.com/cgi-bin/issueproposal.pl?cmd=view&pr=13

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

"The devil is in the details."



From: Shalom.Bresticker@motorola.com
To: etf-bugs@boyd.com
Cc:
Subject: Re: errata/13: PROPOSAL - 12.2.2:example of named param passing
before its descriptioB
Date: Tue, 4 Nov 2003 17:27:36 +0200 (IST)

In implementing the change to Issue #13, I am deleting the following
paragraph at the end of 12.2.2.1. It belongs to the old example and is no
longer relevant to the new example:

"In this example, the name of the module being instantiated is vdff. The
construct #(10,15) assigns values to parameters used in the mod_a instance
of vdff. The parameter size is assigned the value 10 and the parameter
delay is assigned the value 15 for the instance of module vdff called
mod_a. The construct #(.delay(12)) assigns the parameter delay the value
12 in the instance of module vdff called mod_c."

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

Unformatted


Sashi Obilisetty <sashi@dualsoft.com>

Hosted by Boyd Technology