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

>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
sharp@cadence.com
Received on Wed Nov 17 17:54:31 2004