RE: [sv-bc] $bits question

I like where your thoughts are going here, Greg.

Having the "=" in what really is a parameterized typedef makes it look
too much like the familiar parameter assignment; and with all the new
data keywords, and the introduction of typedef, as Steve points out, it
could _really_ look like a parameter assignment!!

Removing the "=" and using "typedef" instead of "type" removes that
un-useful familiarity; and in truth shifts the familiarity to remind one
of the typedef, which is quite apt.

Perhaps, noting your last comment, it is too late to make such a change?


Michael McNamara
mcnamara@cadence.com
408-914-6808 work
408-348-7025 cell


-----Original Message-----
From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Greg
Jaxon
Sent: Monday, January 23, 2006 10:52 AM
To: Steven Sharp
Cc: sv-bc@eda.org
Subject: Re: [sv-bc] $bits question

Steven Sharp wrote:
> ... I don't think that the data type declaration syntax
> belongs anywhere but in a declaration (typedef or object declaration).
In
> other contexts, the syntax is ambiguous.  For example:
> 
> typedef logic [N-1:0] T1;
> typedef logic T2 [N-1:0];
> 
> parameter type p = logic [N-1:0];
> 
> It is clear what types T1 and T2 represent, because the position of
the
> name in the declaration syntax disambiguates them.  But it is not
clear
> what type p is supposed to represent.  Is it similar to T1 or T2?  And
> putting type() around it doesn't help.
> 
> Steven Sharp
> sharp@cadence.com
> 


Steven,

    So would you favor eliminating the assignment "=" from the syntax
of parameter type altogether?

parameter type my_type P;   /* was: parameter type P = my_type */

parameter type logic [N-1:0] P1;  /* matches T1 */

parameter type logic P2 [N-1:0];  /* matches T2 */

Notice the similarity, then, between a "parameter type" and a "typedef".
To me this argues for replacing the keyword "type" here and using
"typedef".
The keyword "parameter" becomes just a modifier indicating that this
typedef can be overridden at elaborate-time.

Greg Jaxon

Disclaimer:  The above daydream has nothing to do with anyone's
product plans or LRM proposals - it's simply design speculation.