RE: [sv-bc] Local parameters in parameter-port-list (Mantis 1134)

From: Rich, Dave <Dave_Rich_at_.....>
Date: Tue Aug 21 2007 - 10:27:59 PDT
Jonathan,

I see no difference between this and in the handling of port directions.
If you specify a port direction, all declarations that follow retain
that direction until another direction is specified. Same for types. So
what's different about parameter/localparam? 

Dave


-----Original Message-----
From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org] On
Behalf Of Jonathan Bromley
Sent: Tuesday, August 21, 2007 8:22 AM
To: sv-bc@server.eda-stds.org
Subject: RE: [sv-bc] Local parameters in parameter-port-list (Mantis
1134)

hi BC,

The minutes of your meeting of 23 July say the following about 1134:

   Consensus that localparams be skipped when dealing with
   override by position.  This is the same as non-ANSI-style
   parameter usage currently enabled and relaxes requirement
   in the current proposal that they appear at the end of the list.
   Update wording and BNF accordingly.

This can be achieved rather easily by deleting all my proposed
BNF changes and instead making this change:

parameter_port_declaration ::=
    parameter_declaration
  | local_parameter_declaration           // added branch
  | data_type list_of_param_assignments
  | *type* list_of_type_assignments

provided the changes in Mantis 979 are also implemented.

However, I think this has an unfortunate side-effect.
Consider

  module foo
   #(
      parameter P = 3,
      localparam L = P+1,
      type T = logic [P:0],
      T PT = 5
    ) ...

Would you say that T is a localparam or a parameter?
What about PT?  And what would users think?
(For what it's worth, I think that both T and PT 
are localparams, but I think users might be very 
surprised to find they can't override T.)

This is precisely the confusion I was trying to avoid by 
requiring all localparams to be at the end of the list.

If you're OK with it, then I'll go ahead and update the
proposal; the new proposal will state as a prerequisite
that the changes of Mantis 979 be implemented.
-- 
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24
1AW, UK
Tel: +44 (0)1425 471223                   Email:
jonathan.bromley@doulos.com
Fax: +44 (0)1425 471573                           Web:
http://www.doulos.com

The contents of this message may contain personal views which 
are not the views of Doulos Ltd., unless specifically stated.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.



-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Tue Aug 21 10:28:17 2007

This archive was generated by hypermail 2.1.8 : Tue Aug 21 2007 - 10:28:38 PDT