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

Greg,

Mantis 1465 clarifies the rules in the context of
module/interface/program ANSI style port declarations. It should be the
basis of future rewrites that will clarify non-ANSI style port
declarations, parameter declarations, non-module/interface/program port
and argument declarations (e.g., tasks, functions, sequences,
properties, ...)and data declarations in general.

That proposal has been approved but was too late to enter Draft 5, and
is in Draft 6.
Mantis 2273 covers various extensions of the work begun in 1465. Time
did not allow the further work, but 1465 makes a good start. One reason
that it is not trivial to extend 1465 is that although other similar
contexts, such as those listed above, have rules mostly similar to the
rules in 1465, each has certain differences. For example, in tasks,
default directions are input, whereas in module ports, the default
direction is inout.

1465 clarifies that in the discussed context, 'data type' includes
packed dimensions, but not unpacked dimensions. This is true for task
and function argument declarations as well. The Mantis proposal is not
changing the rules, but rather documenting the de facto rules. As you
and John Havlicek have correctly pointed out, the rules are not always
clear, neither to users nor even to developers. It took me a lot of time
to get the rules straight so that I could write the proposal (which the
developers unanimously agreed to).

It is also true that the term 'data type' is not used consistently
throughout the LRM and therefore 1465 defines the meaning of that term
where used in that proposal but without stating that the term
necessarily has the same meaning when used elsewhere. Thus, the sections
on type compatibility and on array declarations may use the term with a
different meaning in those contexts.

13.3 itself has the following example:
// the resultant declaration of b is input [3:0][7:0] b[3:0]
task mytask4(input [3:0][7:0] a, b[3:0], output [3:0][7:0] y[1:0]);

So, in ( output logic [15:0] u[2], v ),
v inherits logic[15:0] from the previous declaration, and thus has zero
unpacked dimensions.

In ( output logic [15:0] u[2], v[3] ), 
both u and v have one unpacked dimension and one packed dimension.

In
bit [7:0] [31:0] foo7 [1:5] [1:10], foo8 [0:255];,
foo7 has two unpacked dimensions, foo8 has one, and both have identical
packed dimensions.

Regards,
Shalom


> -----Original Message-----
> From: owner-sv-bc@server.eda.org 
> [mailto:owner-sv-bc@server.eda.org] On Behalf Of Greg Jaxon
> Sent: Wednesday, June 18, 2008 9:02 AM
> To: SV_BC List
> Subject: Re: [sv-bc] Merge problem: T/F formal args - a proposal
> 
> 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
---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.


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