RE: [sv-bc] DataTypes: BNF changes

I take it from reading the minutes that the restriction is that net type
and 'reg' are not allowed next to each other, but if a drive strength or
charge strength appears in between, then it is legal. For example these
would all be legal:

tri (large) reg w;
typedef reg REG;
tri REG w;

but this would be illegal:

tri reg w;

Is this correct?

> -----Original Message-----
> From: Steven Sharp [mailto:sharp@cadence.com]
> Sent: Wednesday, November 10, 2004 3:42 PM
> To: Dave_Rich@mentorg.com; Mark.Hartoog@synopsys.COM; sharp@cadence.com;
> btf-dtype@boyd.com; sv-bc@eda.org
> Subject: RE: [sv-bc] DataTypes: BNF changes
>
>
>
> >> The datatypes groups voted to disallow <nettype> followed by 'reg' as a
> >> lexical restriction.
> >
> >I cannot find this restriction anyplace in the proposed BNF, chapter 4 or 5
> >changes to the LRM.
> >
> >Is it an oversight that this was left out?
> >
> >How exactly was this restriction formulated?
>
> I was asked to check with Brad Pierce about where it should appear, since
> the BNF was one possibility. Brad expressed the opinion that it should
> appear in the text instead. The best place would probably be the new
> sub-section in section 5 on nets. It would be nice if the syntax boxes
> were broken up so that the syntax for variable declarations appeared in
> the sub-section on variables, and the syntax for net declarations appeared
> in the sub-section on nets. Then the syntax would be right there and the
> restriction could appear in the text after it.
>
> The restriction is supposed to be against having the net_type token
> immediately followed by the "reg" token. An alternate restriction that
> the group considered was just disallowing "tri" followed by "reg". Enough
> people felt that constructs like "wire reg" were also confusing, that once
> the restriction was made, it might as well be broadened.
>
> While this combination could have been prevented grammatically, it would
> have required some hideously messy changes in the BNF. It was deemed
> easier to express it as a separate lexical restriction against having
> this sequence of tokens. It isn't pretty, but nobody came up with a
> suggestion that people liked better.
>
> Steven Sharp
> sharp@cadence.com
Received on Wed Nov 10 16:12:14 2004