RE: [sv-bc] DataTypes: The wone net type

The history of the wone net type proposal is something like the following.

SystemVerilog added the capability of driving a variable with a continuous
assignment. This allowed a variable of a new datatype as the "sink" side
of a port connection, to partially compensate for the lack of nets of the
new datatypes. It also allowed some convenience in other situations.

Variables don't have the mechanisms that nets have for resolution of
multiple drivers, but just hold the last value written. For this reason,
SystemVerilog restricted variables to be driven by a single continuous
assignment, or written by procedural assignments, but not both. To
avoid incorrect (un-hardware-like) behavior, the tools enforced this
restriction.

Some SystemVerilog users started regarding this limitation on variables
as a beneficial thing. As a side effect of enforcing this restriction,
the tools enforced a company design rule forbidding multiple drivers
for a signal (assuming only variables were used). This was considered
to be very valuable.

There are a couple of issues with this. Since this was apparently more
of a side-effect than a designed feature, it doesn't do a perfect job
of enforcing the design rule. It works well if a signal is represented
by a variable everywhere, but leaves holes in the checking if it is
attached to older Verilog modules that use nets. And if someone wants
to use a net instead of a variable (perhaps to get timing capabilities),
they have no way of asking for this rule to be enforced.

The "wone" net type was designed to fix these problems. It allows
explicit specification of a single-driver net. And with proper
definition of the net type domination rules, it can be enforced even
when connected to older Verilog modules using older net types.

Steven Sharp
sharp@cadence.com
Received on Thu Oct 28 15:45:56 2004