Re: [sv-bc] SV-BC Issue 24

Mark,

There are 2 cases to consider:
  - vectors types: regular vectors, packed struct, packed unions, packed arrays

  - composite types: unpacked structs, unpacked arrays, unpacked unions
  
 This leaves out enumeration types ( I would like to put this one in the
 vector category but I cannot because enumeration types are strongly
 typed in SV). For variable assignments, I think that a explicit cast is
 required if the value assigned does not belong to the set of values defined
 for the enumeration type. Therefore the SV enumeration types may belong to
 the composite category and require a legal value for that type to be assigned
 or the presence of an explicit cast.
 
 Verilog 2001 only had a few simple types for a parameter: integer, real,
  realtime, time and vectors of logic. Parameters could be declared of these
  types and their initial or override value was basically converted to the type
  of the parameter, just like it would have happened if it had been a regular
   reg assignment.
  I think we need to preserve the same rule for my first category of vector
  types.
 
 As far as the composite types are concerned, I don't think we should allow
  conversion to the target type, we should require that the expression be of the
 composite type, otherwise it is a type check error. The analogy to make is that
 we don't allow a variable assignment of a struct type to have a value which is
  not of that exact struct type.
  For instance if we have:
  parameter real p [1:3] = {0.0, 0.1, 0.2};
  The RHS expression is an array aggregate of size 3, which matches the
  array size declaration of the parameter.
  parameter real p [1:3] = {0.0, 0.1};
  In this last example, the parameter declaration has a type check error, the
  array aggregate does not match the size of the parameter array.
  
  Francoise
      '
 
 
  
  
    What I think we should specify is that if a type is provided in the
parameter
declaration then the value provided should be converted
>X-Authentication-Warning: server.eda.org: majordom set sender to
owner-sv-bc@eda.org using -f
>From: "Mark Hartoog" <Mark.Hartoog@synopsys.com>
>To: "Sv-Bc" <sv-bc@eda.org>
>Subject: [sv-bc] SV-BC Issue 24
>Date: Sun, 9 May 2004 17:38:18 -0700
>MIME-Version: 1.0
>Content-Transfer-Encoding: 7bit
>X-Priority: 3 (Normal)
>X-MSMail-Priority: Normal
>Importance: Normal
>X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
>X-pstn-levels: (S:99.90000/99.90000 R:95.9108 P:95.9108 M:98.8113 C:78.1961 )
>X-Received: By mailgate2.Cadence.COM as RAA11181 at Sun May 9 17:40:30 2004
>
>IEEE 1364 says the following in section 12.2 on overriding parameter
>values:
>
><quote>
>A parameter declaration with no type or range specification shall
>default to the type and range of the final override value assigned
>to the parameter.
>
>A parameter with a range specification, but with no type specification,
>shall be the range of the parameter declaration and shall be unsigned.
>An override value shall be converted to the type and range of the
>parameter.
>
>A parameter with a type specification, but with no range specification,
>shall be of the type specified. An override value shall be converted to
>the type of the parameter. A signed parameter shall default to the range
>of the final override value assigned to the parameter.
>
>A parameter with a signed type specification and with a range specification
>shall be a signed, and shall be the range of its declaration. An override
>value shall be converted to the type and range of the parameter.
></quote>
>
>This uses the term "converted to the type and range" which I assume
>means that the value is cast to the type of the parameter.
>
>I think we should suggest to the IEEE to clarify this a bit for System
>Verilog, but I don't see a need for any significant changes. Parameter
>values are cast to the type of the parameter.
>
>
>Mark Hartoog
>700 E. Middlefield Road
>Mountain View, CA 94043
>650 584-5404
>markh@synopsys.com
Received on Mon May 10 07:34:54 2004