RE: 4 State Logic Proposals

Hi Russ,

> So you see where a fatal error generated from every 4-state write to the HDL
> side would
> get in the way of getting this case up and running?

Yes, you do have some good and valid points.  I am still worried about
the portability issues.  I see two conflicting concerns here:

  1) Your pragmatic concern about allowing the implementation to be
     lenient regarding X and Z to ease porting of 4-state-full models
     and environments.

  2) My concern about having the implementation detect non-portable
     models by flagging X and Z usage as errors.

It seems reasonable to find a way to accommodate both concerns.  But
first, I'd like to understand one key point in your example.  Your
example assumes the model is sending and receiving X and Z.  The
receiving part we can ignore as the implementation will either run
on a 2-state engine in which case X and Z will never be sent by
the HDL side and thus never received by the C side.  So that leaves
sending X and Z.  My question is, how common do you think such
models are (models that actually send X and/or Z to the HDL side)?

Let me now address the question of accommodating both concerns
above from a couple of different angles.  First one might argue that
the relaxing of X and Z usage considered errors to warnings could be
something an implementation could add as an enhancement to the
standard somewhat akin to how GCC has defined a number of non-standard
improvements to C.  GCC has options that enable/disable the various
language extensions.  Similarly, a SCE-MI implementation could provide
non-standard extensions such as treating certain errors more leniently.

Next, still assuming the standard says sending X and Z is an error,
the application could modify this behavior by installing an error
handler that would see this error and instead of aborting would allow
the simulation/emulation to continue.  This probably makes more 
sense if we define sending X and Z as a non-fatal error rather
than a fatal error.  The reason is that we have currently defined
fatal errors as non-recoverable.  Non-fatal errors are recoverable
and we could define the coercion of X and Z to 0 and 1 as the recovery.
All this assumes that we are continuing to use the SCE-MI error and
warning infrastructure for errors/warnings related to the DPI
subset of SCE-MI 2.0.  I do not remember if this topic has been
brought up before.  I will send a separate email to raise this issue.

Anyway, I still believe it is important that the standard specifies
some mandatory diagnostic upon sending X and Z.  Whether it needs
to be a fatal error, non-fatal error, or a warning, I do not care
much.  I want to be able to detect non-portable constructs at
compile time and/or run time as much as possible and sending X and
Z is easy to check for, so we should do it.  Perhaps we need to
define two operating modes: Strict compliance where portability
is guaranteed if the models run without errors/warnings and relaxed
compliance where the models can take advantage of optional extensions
such as sending X and Z.

Per