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

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

This was my believe also. I was simply passing on the information that
some engineers, who had not been to any of the meetings or had the basic
ideas of this proposal explained to them in advance, got a very different
impression from reading the LRM language in the proposal.

> -----Original Message-----
> From: Rich, Dave [mailto:Dave_Rich@mentorg.com]
>
> 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
Received on Wed Nov 17 16:05:01 2004