Shabtay’s take 04/28 - Dependency on IM212

Committee states it is still active

How does the Mentor proposal plan to address error/warning/info handling in the DPI subset of SCE-MI 2.0? Are we continuing to use the SCE-MI 1.1 error/info reporting mechanism? If not, what new mechanisms are we planning to use?

JohnS>

I see no reason to discontinue use of SCE-MI I error/info reporting. I don't see a conflict between this and DPI.

Per>

So, are you saying we can use SCE-MI 1 error/info reporting for errors and warnings that occur in the DPI portion of SCE-MI 2? DPI and/or SystemVerilog does not have its own mechanism that we need to support?

>>JohnS

johnS:

SystemVerilog does not have an explicit mechanism. They leave error handling up to the vendor's internal mechanism. Native DPI implementations can make use of this.

>>>Per

Ok, good. We should then define that SCE-MI DPI implementations use the SCE-MI error and info handling mechanism. Although, this yet again raises incompatibility issues between regular DPI and SCE-MI DPI at least with respect to the whole environment.

<<<End Per

If a vendor supports SCE-MI on the C side, the user will have the option to register an error handler via this mechanism.

But their DPI model code should not have to change either way.

>>>Per

Here you are talking about the transactors and supporting code but not the whole environment, right? Obviously, a standard non-SCE-MI-aware DPI application would not have calls to SCE-MI API function such as the functions to register error and info handlers . . .

<<<End Per

<<End JohnS

So what do you think of the proposal to use SCE-MI 1 error and/or info handlers to tweak the default behavior of 4-state logic values?

Say the standard mandates sending X and Z is an error, either fatal or non-fatal. We could further spec it such that the user would be able to put an error or info handler (depending on the severity of the error) in place that would ignore the error and allow the simulation/emulation to continue. This would satisfy Russ' wish of being able to bring up 4-state-full environments in SCE-MI 2 quickly and at the same time satisfy my wish of being able to detect portability problems related to 4-state use.

>>JohnS

I would defer this discussion until we've had a chance to evaluate Duaine's and Bryan's proposal for 4-state handling.

<<End JohnS

<End Per

<End JohnS

From Meeting Minutes 10/27

Do not make error handling part of the standard for 2.0 possibly. But other API’s do have error handlers. Maybe a compliant implementation must have a call sce-mi error handler, but it is up to vendor what he does with it.