[sv-cc] Non-member submissions from last night on types on nets

Hi All,

Last night I got a bunch of bounced SV-CC email from people not on
the reflector. Here is the content:

-------------
Dave Rich writes at Wed Nov 17 15:37:24

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
-------------
Mark Hartoog writes at Wed Nov 17 16:04:57

> 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.
-------------
Kathy McKinley writes at Wed Nov 17 16:25:08

Hi Mark,

We added a paragraph to section 5 to explicitly state that there was
no intent to change the Verilog network semantics in this revision
of SystemVerilog:

     Certain restrictions apply to the data type of a net. A valid data type
     for a net shall be one of the following:

        1) A four-state integral type

        2) An unpacked array or unpacked struct, where each element has
           a valid data type for a net

     The effect of this recursive definition is that a net is comprised
     entirely of four-state bits, and is treated accordingly. 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.

I wish that we had stated this intent in the introduction as well, so
that everyone reviewing the proposal could read the detailed change
suggestions in the right context. Do you think that this sort of
enhancement to the introduction in the next revision would be helpful?
Do you think that section 5 is too late to be stating this intent in
the SystemVerilog LRM, and that it should be placed elsewhere?

Kathy
-------------
Steven Sharp writes at Wed Nov 17 20:54:21

>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.

I would like to point out that those engineers were not just reading the
new LRM language. They were also reading the old LRM language in the
"FROM" section, which used incorrect terminology and was misleading.
They were also contrasting the old and new language, and may have thought
that the change to fix incorrect terminology was intended to change the
language semantics. These problems would not occur with the resulting
changed LRM alone.

However, I agree that the statement "There is no change to the Verilog-2001
semantics related to net resolution at the bit level, the role of strength..."
is not clear enough about the intent.

It could say something more direct, such as "In addition to a signal
value, each bit of a net shall have additional strength information.
When bits of signals combine, the strength and value of the resulting
signal shall be determined as in Verilog-2005."

I know that the terms "signal" and "combine" look strange, but this is
the same terminology used in section 7.10 of the Verilog LRM. We could
use terms like "drivers" and "resolution", but that terminology is not
used in the Verilog LRM. Here is another description without any of
those terms.

"Each bit of the value of a net shall have additional strength information,
which shall affect the resulting value of that bit as in Verilog-2005."

And yes, I know that implementations may not explicitly store strength
information, but the LRM says it is there (if only conceptually).

Steven Sharp
-------------
Steven Sharp writes at Thu Nov 18 00:14:15

Gord,

I am not sure how we can respond to your feedback in any meaningful way.
A sense of unease about the possibility that there is a better approach
is not something we can address. There is always that possibility, and
all we can do is put reasonable effort into avoiding it.

This proposal may be new to you, so that you haven't had enough time to
fully consider it. But you should be aware that the initial concept was
proposed over a year and a half ago to IEEE 1364. It started active
discussion and development under 1364 about a year ago. Some very
capable and knowledgeable people have devoted a lot of time to the design
and review of the approach. Cadence has a prototype implementation.
I'm not sure what you would consider being "a bit more careful."

With regard to two-state types, there have been several possible
approaches proposed, none of which are incompatible with this proposal.
There simply wasn't enough time to reach consensus on them within the
P1800 group, and make sure that sufficient effort had been put into
getting it right. Organizational issues have prevented considering this
proposal under P1800 until recently.

If you can point out any specific flaws in the proposal, or suggest any
alternatives that would work better overall, we would be glad to consider
them.

Steven Sharp
-------------

-- 
Charles Dawson
Senior Engineering Manager
NC-Verilog Team
Cadence Design Systems, Inc.
270 Billerica Road
Chelmsford, MA  01824
(978) 262 - 6273
chas@cadence.com