Re: [sv-bc] DataTypes: the reg datatype

>The point about wires is that they have many more than four values, and
>these new kind of wires need to connect to rtran gates.
>
>That is why the 2/4 value distinction should be irrelevant. The wires
>should only take on the "shape" and "naming" of the data type, not its
>values. This is one justification for the wire <datatype> syntax in
>Jonathan Bradford's proposal.

I don't believe that it is productive to regard the strength information
on a net as part of the data type value. There are no operations in the
language that are available to the user that can access that information.
All they can do is print it out for debugging purposes (which may provide
a round-about way of accessing the information, but nothing like the
normal reading of the value of an object).

Nor can a user explicitly assign an arbitrary strength-value combination
to a net. All they can do is assign a value, and define the drive strength
of a driver, which then produces a strength-value combination.

It is much more productive to regard the strengths as additional
information provided by a driver to the driver resolution algorithm,
along with the value, to be used in the resolution of the final value.

An implementation may pack the strength together with the value in its
internal representation, but it can still be conceptually viewed as the
separate data value and extra drive strength information annotated on it.
It is this conceptual model that matters in the language definition, not
the details of how the annotation is implemented "under the hood".

Once this conceptual viewpoint is understood, there is no problem with
nets taking on the values of a data type. They aren't just taking on
the "shape" and "naming" of the data type, they actually have that data
type.

They also have additional strength information annotated by the drivers.
There is no problem connecting individual bits of a packed struct to the
terminals of an rtran primitive. Drivers of the struct can drive it with
a value of struct type, and annotate each bit with the necessary strength
information if strength-based resolution is required. The resolution
algorithm can use that strength information to determine the value of the
bits of the resulting net, which still has a value of the struct type.

Making this conceptual shift is important, because a lot of rules in the
LRM are based on data types and compatibility of data types. If the nets
have data types, then the rules apply in a straightforward fashion. If
you insist on trying to regard them as having just the "shape" and "name"
of the data type, then you have to add a lot of extra rules. You have to
have rules that treat nets having the "shape" and "name" of a data type
as if they have the data type. It is a lot easier to just acknowledge that
they have the data type.

This may just be a matter of conceptual models and terminology, but the
whole point of the LRM is to describe the language using conceptual models
and terminology. Using the right choice gives a much more straightforward
description.

Steven Sharp
sharp@cadence.com
Received on Thu Nov 4 14:20:39 2004