RE: [sv-bc] Deadline for detailed feedback on Data Types on Nets Proposal

Gord and Mark,

I believe the intent of the data types on nets was not to touch the
underlying strength and resolution system of wires. My interpretation is
that

wire A;
and
wire logic A;

are identical, and logic is currently the data type that is a wire is
implicitly cast to when used in a Boolean expression.

The proposal should not be modifying the way wires work at the bit level
when connected to the port of a module or gate level primitive.

So my suggestion is that

wire bit A;

would keep the values and strengths currently defined by the drivers on
the wire defined by 1364-2001, but it would be cast to a 0 or 1 when
used in an expression.

Dave

-----Original Message-----
From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of
Gordon Vreugdenhil
Sent: Wednesday, November 17, 2004 9:58 PM
To: Mark Hartoog
Cc: Maidment, Matthew R; sv-bc@eda.org; sv-cc@eda.org; sv-ec@eda.org
Subject: Re: [sv-bc] Deadline for detailed feedback on Data Types on
Nets Proposal

Mark, you beat me to it...

This was a concern to me in terms of the overall direction of
the proposal. The strength component of nets (particularly
when talking about non-strong and ambiguous strengths) is a
very deep part of the Verilog model and is particularly
important for model consistency when going from RTL to gate
models. I would have some real questions about semantics
if we started being able to have, for example, a "wire bit w;"
at some point in the future. There doesn't seem to be a very
reasonable model for strengths in such a net. The current
wording, which ensures semantic consistency with ambiguous
strengths and all other pre-existing wire semantics is fine, but
I am a bit bothered by some of the directions since I'm not
sure how future extensions will fit in semantically.

There are relationships between type, strength aspects, and
resolution, but I'm not sure that the direction here captures
those relationships well. Some combinations don't seem to
make much sense (ie. "wire bit") but some others do that
aren't really addressed ("resolved reg logic"). Assuming the
existence of a "resolved reg", I think that there is a
difference between a resolved variable of type "logic" and a
net of type "logic". As one aspect, perhaps one would disallow
a resolved logic variable in some gate or technology related
topologies while allowing a net (which can deal with the
strength aspects).

Verilog has only handled resolution on nets in the past. This
has, I think, lead to some mingling of "net", "resolution" and
"strength" where we need to be a bit more careful about the
relationships and about how factoring the conceptual model in
various ways will impact future directions in this space.

Gord.

Mark Hartoog wrote:

> We have distributed the data types on wires internally for review.
> Some people who are not familiar with this proposal have been confused

> by the language in the proposal.
>
> The specific issue is the difference between "wire" and "wire logic".
> Some people have interpreted the LRM language to mean the "wire" is
> a net that has the Verilog net value system with 120 values, while
> "wire logic" is a new kind of net that only has 4 values.
>
> I don't think this was the intention at all, but some of the LRM
changes
> can apparently be read to mean this. In particular the change to the
> 3.1 introductory section and the diagram in the introduction.
>
> The 3.1 introductory section removed language that talked about the
> Verilog net data type having 0, 1, x, z, and 7 drive strengths giving
> a total of 120 values, and replaces it with language that only talks
> about 4 state values. Although later on in section 5.5 on Nets is says
> "There is no change to the Verilog-2001 semantics related to net
resolution
> at the bit level, the role of strength, or the treatment of the signed

> property across hierarchical boundaries.", the removal of the language

> talking about net strength and the 120 values from I think 3.1 misled
> readers.
>
> I think it would be better if the 3.1 introduction makes clear that
variables
> have only a data type and are therefore 4 value, while nets with data
types
> have the 4 values, plus strength and net type which specify 120 values
> and the resolution functions for multiple drivers. It would also be a
good
> idea to add strength to the diagram to make clear that nets also have
> strength, but variables do not.
>
> Mark Hartoog
> 700 E. Middlefield Road
> Mountain View, CA 94043
> 650 584-5404
> markh@synopsys.com

-- 
--------------------------------------------------------------------
Gordon Vreugdenhil,  Staff Engineer               503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com