RE: [sv-bc] DataTypes: BNF changes

From: Rich, Dave <Dave_Rich@mentorg.com>
Date: Wed Nov 10 2004 - 14:32:14 PST

Mark,

The datatypes groups voted to disallow <nettype> followed by 'reg' as a
lexical restriction.

This would still allow

typedef reg T;

tri T w;

But I was in favour of

tri <T> w;

for other reasons you mentioned.

Dave

-----Original Message-----
From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Mark
Hartoog
Sent: Wednesday, November 10, 2004 2:21 PM
To: Steven Sharp; btf-dtype@boyd.com; sv-bc@eda.org
Subject: RE: [sv-bc] DataTypes: BNF changes

There are some unfortunate corner cases in the syntax for data types
on wires.

tri reg w1; // declares a net with tri resolution and reg data type.
trireg w2; // declares a net with trireg resolution and default (logic)
            // data type.
trireg reg w3; // declares a net with trireg resolution and reg data
type.

I'm not sure there is anything that can be done about this. I notice at
one time some of the emails were using a template like syntax:

tri<reg> w1;
trireg w2;
trireg<reg> w3;

which is syntactically clearer on this point, but I think has other
problems.
Declarations like:

tri signed [7:0] w1;

are legal v2k, but "signed [7:0]" is now the data type specifier with
default logic data type. We can not force <> here for backwards
compatibility, so it would be funny if

tri <logic signed [7:0]> w1;

putting in the default data type now required <>.

Another alternative would be to outlaw 'reg' data type on wires
and only allow logic. I don't really like that either.

Since wire types tri and trireg are not commonly used, I don't expect
this to be a very serious practical problem, and I guess I would rather
live with this problem then any of the solutions I can think of.

Mark Hartoog
700 E. Middlefield Road
Mountain View, CA 94043
650 584-5404
markh@synopsys.com
Received on Wed Nov 10 14:32:32 2004

This archive was generated by hypermail 2.1.8 : Wed Nov 10 2004 - 14:32:36 PST