4 State Logic Proposals

Hi,

at the last meeting we managed to agree that we should support
something more than the 2 state logic types in the function
based interface.  We did not settle on what `more' means.  It is
my understanding that Russ' original request was based on the
desire to allow the 4 state logic types to be used such that
the effort of porting transactors to the SCE-MI subset of DPI
is reduced.  Russ, correct me if I'm wrong here, but I believe
you never asked for hardware support of 4-state logic nor the
ability to transport X and Z values across the interface.

Let me try to summarize the proposals for what `more' should
mean in order of increasing amount of `more':

1) My own proposal was to make it an error to pass X and Z in either
direction.  The main reason for this is to make it harder for users
to inadvertently write non-portable SCE-MI transactors and environments.

2) Shabtay's recently updated proposal allows 4 state values
to be transported from the emulator/simulator side to the
software side if the emulator/simulator is 4 state capable.
However, only 2 state values are supported in the other
direction.  It is not clear if this means that the 4 state
logic types can be used in this direction or not.  In any event,
attempting to pass 4 state values X and Z leads to undefined
behavior.

3) Ramesh' proposal is to make 4 state value support optional.  The
implementation may choose to implement 4 state value support.  The
(optional) behavior of 4 state values will be fully specified
by the standard.  In either case, the implementation will support
the use of the 4 state logic types.  If only 2 state value support
is implemented, the standard will specify common sense coercion
rules.  In one email Ramesh said `it is recommended that the tool
produce nothing OR warnings OR errors' when X and Z are passed in
the case where only 2 state value support is implemented.  It is
not clear if Ramesh was intending for the standard to explicitly
state this or just ot leave it undefined whether errors or warnings
should be issued in this case.

What we face if we go beyond something like (1) above is that we
definitely no longer have equivalency between portability of
transactors and environments and compliancy of the same.  It will
now be possible to write compliant models/transactors/environments
that are not portable.  If we decide to go down this path we
definitely need some discussion of portability in the spec.

I am not comfortable with Shabtay's proposal for two main reasons:

  2a) It arbitrarily specifies full 4-state support in one direction
      but not the other.  This does not make much sense to me.  If
      we go through the trouble of specifying 4-state support in the
      HW to SW direction, why not SW to HW as well?  Specifying
      4-state support in both directions does not add much complexity
      as it is easy to describe.  And, since it only makes sense for
      a 4-state engine, it does not add any burden to those
      implementors that target 2-state engines.

  2b) The idea of specifying some behavior as undefined solely to
      provide an escape hatch for implementing an extension to the
      standard.  I much prefer to use errors and perhaps warnings to
      flag excursions beyond compliant behavior.  This does not
      preclude an implementation from providing extensions.  For
      instance, an implementation can provide a non-compliant extension
      activated by some user setting that turns off the errors and
      warnings and adds the extension behavior, e.g., 4-state support.
      If we only specify undefined behavior the user can inadvertently
      write models that rely on a particular implementation's
      undefined behavior.  Standard mandated errors or warnings will
      clearly flag this on all compliant implementations.

If we are to go with 4-state support beyond my proposal in (1) I
prefer that we specify the support as optional and fully define it
in both directions, much like Ramesh' proposal.  We should also add
some mechanism to query the level of support at init time as proposed
by Duaine.  Further, I'd really like it if the standard would mandate
a mode that flags as errors any use of features that render models
non-portable such as usage of X and Z.

Per