Re: [sv-bc] Merge problem: T/F formal args - a proposal

From: Greg Jaxon <Greg.Jaxon_at_.....>
Date: Tue Jun 17 2008 - 23:02:10 PDT
Greg Jaxon quoted the 2009 draft 5:
> In 13.3 (and similarly in 13.4):
> 

> ... If the data type is not explicitly declared, then the 
> default data type is logic if it is the first
> argument or if the argument direction is explicitly specified. Otherwise 
> the data type is inherited from the
> previous argument.

Is that last sentence really true?  I don't believe it.

In  ( output logic [15:0] u[2], v ), does "v" have zero or one
unpacked dimensions?  I think it has zero, but if I
include the unpacked dimensions in my notion of data type,
as we did when writing the section on Type Compatibility,
the above sentence literally says "v" has one unpacked dimension,
that it inherited from "u"; can we add another by writing
     ( output logic [15:0] u[2], v[3] )?

I turned to section 7.4.5 hoping for a precedent-setting answer and
found the problem only grows uglier:

> A comma-separated list of array declarations can be specified.
> All arrays in the list shall have the same data type and the same packed array dimensions.
>      bit [7:0] [31:0] foo7 [1:5] [1:10], foo8 [0:255]; // two arrays declared

I usually include "unpacked shape" in my notion of "data type", but now I'm not sure
if _packed_dimensions_ are even included, and I don't know if foo8 has

     - one unpacked dimension  (same packed as foo7, different unpacked)
     - two unpacked dimensions  (so it has the same data type as foo7),
     - three unpacked dimensions (foo7's data type plus another one)

Can we say here instead that:
"All arrays in the list have the same element type and/or packed array dimensions,
  but distinct unpacked array dimensions may be given for each array name.
      bit [7:0] [31:0]   foo7 [1:5] [1:10],     foo8 [0:255]; // two arrays declared
                      // foo7 has 4 dimensions, foo8 has just three"
?

Greg


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Tue Jun 17 23:02:46 2008

This archive was generated by hypermail 2.1.8 : Tue Jun 17 2008 - 23:03:18 PDT