Re: [sv-bc] Re: Ballot Issue 228: SystemVerilog should include 2-value net datatypes

Steven,

Regarding the uwire-only possibility and --

   "Note that we could allow this limited solution initially, and then
go back and allow a more general case later."

Sounds like an option to seriously consider.  Some possible worries --

How many of the decisions about the general case would need to be made
anyway even in the uwire-only case to ensure forward compatibility?

Also, what's your guess about the practical usability difference between
uwire-only and a general solution?  Would a uwire-only restriction
significantly get in the way of what most users would want to do with
their complexly-typed nets?

-- Brad

-----Original Message-----
From: Steven Sharp [mailto:sharp@cadence.com] 
Sent: Wednesday, May 17, 2006 3:40 PM
To: Brad.Pierce@synopsys.COM; sv-bc@eda.org; Dave_Rich@mentor.com
Subject: RE: [sv-bc] Re: Ballot Issue 228: SystemVerilog should include
2-value net datatypes

The main issue is how to handle resolution of multiple drivers on a
2-state net.  A related issue is how to handle connection of a 2-state
net to a 4-state net through a port.

I can see a number of possible solutions:

1. Avoid the issue by only allowing 2-state nets of net type uwire.
Since
   these can only have a single driver, there is no need for resolution.
   There is still an issue with the driver on a 4-state uwire connected
   through a port to a 2-state uwire.  What values would be read from
   the 2-state uwire?  This could be illegal.  It could be treated like
   the port was a continuous assignment from the 4-state side to the
2-state
   side, which would map the values to 2-state, though uwire normally
   requires port-collapsing so it can guarantee the single-driver rule.
   The 4-state could win during collapsing, making both sides 4-state.
   Or the 4-state value driven onto the uwire could be mapped to 2-state
   when read through a 2-state uwire.  But if we are willing to do this
   kind of mapping, one of the later solutions may be better.  Note that
   we could allow this limited solution initially, and then go back and
   allow a more general case later.
   
2. Be a little more general and allow wor and wand nets also, but no
drive
   strengths on the drivers.  The resolution functions would be wire-OR
   and wire-AND, which produce 2-state results for 2-state inputs.  The
   issues with connecting 2-state and 4-state nets through ports would
be
   much the same as above.
   
3. Perform the resolution using 4-state resolution functions, producing
   4-state results.  Map the 4-state value to 2-state when read through
   a 2-state net, at least in some circumstances.  There would be some
   further decisions to be made.  
   
   Would driving a value onto a 2-state net convert the value to 2-state
   first and drive that, so 4-state values only resulted from
resolution?
   Or would the full 4-state value be driven onto the net, including x
and
   z, with mapping only done during reading?  If you want the driver to
be
   able to stop driving, it needs to be able to drive a z, even if the
net
   is supposedly 2-state.
   
   In what contexts would the value be converted to 2-state when read?
   Using the value in an expression in procedural code should presumably
   map it to 2-state.  But connecting the value to the input of a switch
   primitive should presumably pass the full 4-state value through.  The
   RHS of a continuous assignment needs special consideration.  This
seems
   like an expression, and therefore seems like it should be mapped.
But
   port connections are defined to use continuous assignments.  If you
want
   driver resolution to be done properly, you need to pass the 4-state
value
   through ports.  Another way of putting this is that you want to get
   pretty much the same result if you use a continuous assignment for
the
   port as if you collapse the port.  You could have a special case for
   port connections that are potentially collapsible (i.e. qualify as
   net_lvalues), and have those read 4-state, while more complex port
   expressions read 2-state.  That is rather ugly though.
   
   This is close to what Dave described.  I don't agree that you have to
   regard reading a 4-state net as mapping a 120-state value into a
4-state
   value on the read to be able to do this though.  You can regard
reading
   a 4-state net as reading the 4-state value of the net, and ignoring
the
   separate attached strength, while still mapping a 4-state value to
   2-state when reading the 2-state value of the net.  Viewing both as a
   mapping has a nice consistency, but I don't think that is necessary
to
   be able to do the mapping for 2-state.
   
   I do agree that there are some valuable parallels between the two
   situations.  Note that the cases I mentioned above where you want to
   pass 4-state values (switch primitives and collapsed port
connections)
   are ones where you also pass strength information.  But the LRM
allows
   connections not to be collapsed, and to be treated as continuous
   assignments instead.  When this is done, strength information is not
   passed.  This allows users to tell whether the port collapsed or not,
   and may not work as desired if it doesn't, but doesn't seem to cause
   too much trouble.  On the other hand, if an implementation could
decide
   whether to pass 4-state information or 2-state information, depending
   on whether it collapsed the port or not, I think that would cause a
lot
   more trouble.

   There are other cases where decisions would need to be made.  For
   example, what about non-switch primitives, and timing checks and
   path delays?  Should those map the values to 2-state or not?  The
   need to make all these additional decisions is the main obstacle to
   this approach.

Steven Sharp
sharp@cadence.com