Shabtay’s take 04/28 - Requires resolution but Tharas who requested support for 4 values has not showed up for quite some times…

Russ says this is still needed for compatibility. Changing from 4 to 2 states is still necessary. Nothing in the working doc yet.

Support for multi-valued logic types. This issue was originally a part of IM201, but has been split off as a separate issue. This discussion will include support for Verilog 4 valued logic as well as VHDL 9 valued logic type.

4 state versus 2 state issues. Russ would like to have a 4 state that could be used as 4 state if in sim, but converted to 2 state for Emulation. C side written in SC_LogicVal - when using Emulation mapped to 2 state.

Per - In VHDL would like to add std_logic, ulogic bit and bit_vector. Need an unresolved 2 state type. Per would accept just std_ulogic. On SW side limited to 4 state support. Cannot go beyond this.

Agreeing on SV types with the addition of 4-state across the interface, but can deprecate for emulation.

Proposal - There is no requirement that the 4 state is honored by the implementer. Not decided.

Russ> I want to add a clarification to this IM (Function arg data type subset ) Specifically, about my request for 4-state (svLogicVecVal type) support in SCEMI 2.0 brought up in the last face-to-face meeting. What I had in mind was the ability to code up the software side (and the DPI function formal arg types on the SV side), using the 4-state types (svLogicVecVal on the C side, "reg" or "integer" on the SV side). In pure simulation, users could run with full 4-state support. The IFLC process, however, would map "X" and "Z" types into some TBD 2-state representation (or, optionally, if an emulator implementation provided 4 state, no mapping would be required).

Per>> I see two cases:

1) Imported functions

2) Exported functions/tasks

Per>> In case 1 no mapping is needed. Either the emulator/simulator supports 4-state and just passes them as is, or it only supports 2-state, but again, it can pass them as is; the user would just never see values except 0 and 1.

Per>> In case 2 mapping would have to be done when the user is passing X or Z to the HDL side if the target does not support 4-state. Several choices present themselves here:

1) Issue an error if X or Z is passed.

2) Issue a warning and map X/Z.

3) Silently map X/Z.

Per>> Platforms that do support X/Z would pass them unchanged of course. As we talked about at the meeting there many opportunities for incompatibilities between different implementations, and there certainly enough rope for the user to shoot themselves in the foot, as they say ;-)

<<End Per

Russ> I don't think the end result is much different than that of the various vendor implementations that exist currently for running SCEMI 1.1 testbenches in a pure simulation mode -- although there is no specification for this (a weakness of SCEMI 1.1). Some of these implementations could pass 4-state info across the interface in pure simulation; some could do the 2-state mapping for both cases (simulation and emulation). The same issues of possible simulation / emulation mismatch would continue if 4-state semantics were defined in SCEMI 2.0. This is an opportunity to catalog and define them, instead of just ignoring them.

<End Russ

Shabtay>

SCE-MI 2.0 spec should only support conveying 2 state values (1/0) through the interface and treat X and Z states as undefined.

This implies that we leave it to the implementers to define what level of enforcement should be applied when X and Z values are passed to the SCE-MI API. Users could build their own lint checkers or use what EDA vendor choose to provide to check/lint the code. The above also implies that SCE-MI 2.0 should not support 4 states to 2 states coercion and should not implement different coercions for simulation vs. emulation. Defining X and Z as undefined also imply that that SCE-MI 2.0 implementation should not be forced to report X and Z states as errors or warnings.

<< End Shabtay

>Per

There are only to reasonable ways we can go on the 4-state logic value issue:

1) Only 2-state logic value types are supported. Any use of 4-state

logic types or any other types not supported by the SCE-MI DPI

subset is an error.

2) 4-state logic value types are supported in the following limited

sense: 0 and 1 values are passed in either direction on changed;

any attempt to pass X or Z in either direction is an error. 4-state

logic values are not coerced to 2-state logic values.

It should be pretty straightforward to define the SystemVerilog types such that most of the above error cases become compile time errors on the C side. Since the infrastructure linker does not process the C side it is not the infrastructure linker's job to report these errors.

<End Per

>Ramesh

We would propose that 4 state be supported in the SCE-MI 2.0Interface.

Four valued System Verilog data types, reg, logic, and integer should be treated as four valued at the DPI interface.

The C side mapping would be to svLogic, svLogicVec32, svLogicPackedArrRef.

>>JohnS

One minor point of clarification just so I understand fully what you are saying. When you say support both svLogicVec32 and svLogicPackedArrRef are you referring to both the old deprecated "DPI" and the newer "DPI-C" usage respectively ?

These are redundant functionalities and I would strongly recommend against saying SCE-MI 2 should support the old deprecated usage. This would impact 2 state support as well, i.e. svBitVec32 vs. svBitPackedArrRef and I really don't think we want to go down that road.

>>>Ramesh

I agree with your suggestion. We should limit SCE-MI 2 usage to DPI-C usage, and so i should be precise and say

The C side mapping would be to svLogic, svLogicVecVal, svLogicVecVal* .

<<<End Ramesh

<<End JohnS

e.g.,

/* (a chunk of) packed logic array */

typedef struct { unsigned int c; unsigned int d;} svLogicVec32;

The encoding would follow the SV definition:

c d Value

0 0 0

0 1 1

1 0 z

1 1 x

[the above is the same as "old" Verilog's aval/bval encoding]

The implementor has the choice of

a) coercing to two state by dropping 'c'

b) warning and coercing

c) generate error and stop; the error can be at compile time

if an implementation disallows reg, logic, and integer in

the relevant function interface.

Most synthesis and emulation platforms accept reg, integer and coerce to two state. The proposed approach for SCE-MI is consistent with that approach.

JohnS>>

As for your 4-state recommendations I think I'm hearing you say that if an acceleration vendor supports 4 state, that SCE-MI 2 should not prevent it right ?

>>>Ramesh

Yes. Here is my general comment on 4 state support:

4 state support in SCE-MI 2 allows more flexibility;

a user doesn't have to use it if he doesn't want to;

if a user does use it, his usage is explicit and visible to the tool;

it is straight forward for the tool to coerce 2 state behavior.

<<<End Ramesh

As you know 4-state was not supported in SCE-MI 1.

Do you see this as a major limitation to SCE-MI 1 ?

>>>Ramesh

SCE-MI 1 was perhaps viewed as very emulator centric and 4 state was not particularly relevant.

SCE-MI 2 perhaps has an oppurtunity to be used as a standard way of interfacing C/C++ testbench artifacts to simulation, acceleration, and emulation. So, allowing for 4 state would enable the standard to be used more widely.

<<<End Ramesh

Can you you modify your proposal to suggest how SCE-MI 2 should handle the case when an acceleration vendor does not support 4 state, i.e., gracefully accommodate both scenarios:

1. The accel vendor supports it

2. The accel vendor does not support it

>>>Ramesh

The assumption is a user who cares to represent the interface in 4 state will use the 4 state types of reg/integer/logic.

Say the user has a reg [31:0] mybus, that is mapped to svLogicVecVal mybus on the C side.

Scenario 1: Vendor supports 4 state

If the vendor supports 4 state mybus.c may be populated with non zero values; i.e., z/x encoding has 'c' bit at '1'. This works in either direction.

Scenario 2: Vendor does not support 4 state

Going from HDL to C:

mybus.c would be zero all the time; the HDL will populate mybus.d with the 2 state value.

Going from C to HDL:

mybus.c and mybus.d would be populated; the HDL will consume mybus.d only.

The above implicitly means, z will be coerced to 0, and x will be coerced to 1.

It is recommended that the tool produce nothing OR warnings OR errors when non-zero mybus.c values are present; the user can pick what he wants to see.

<<<End Ramesh

<<End JohnS

If desired VHDL subtype X01Z can be supported with the same encoding as SV logic/reg.

<End Ramesh

Russ>

BRCM has not submitted a detailed proposal regarding 4-state support though we raised the issue several weeks ago. Our expressed desire is simple: to be able to use models written for 4-state simulation in a 2-state only SCEMI environment without having to rewrite lots of code.

I think that that is as simple as saying we'd like the SCEMI (C side) data types svLogic and svLogicVecVal and the (SV side) data types integer and reg at least to pass through a SCEMI preprocessor or IFLC (or whatever you want to call it) without triggering some kind of abort or error.

There is no issue with coercion or mapping of 4state to 2state going from HDL -> C, because the HDL side doesn't generate 4state when represented in an emulator. If a present or future hardware accelerator does generate 4state, then that particular technology could claim support for this beyond SCEMI but I don't believe the spec should indicate that's a SCEMI compliant mode of operation.

Going from C-> HDL is dicier. There probably needs to be a simple mapping of 'X' and 'Z' to '0' and '1' and an option to generate a warning message (not a requirement). The simulation/emulation mismatch issues, in my opinion, would be more than offset by no need to go through models and change all the svLogic types to svBit. But it's a tradeoff, and I'm not 100% convinced about it.

I agree with John that we should support P1800 DPI only.

<End Russ\

>Shabtay

When I made my recommendation for supporting only 2 states, I did not take into consideration that some emulation vendors would choose to offer 4 state emulators/accelerators. But given Ramesh's (From Tharas) feedback, I suggest modifying our original proposal to accommodate Ramesh (and others) as follows.

1. SCE-MI 2.0 would support conveying 4 state values from the HW side to the SW side. This will allow the SW side to monitor X and Z (if the HW side is capable of producing the X and Z values of course). 2 state emulators/accelerators will only produce 2 state values.

2. SCE-MI 2.0 would support conveying only 2 state values from the SW side to the HW side. Passing other values such as X and Z will be considered 'undefined' meaning it is up to the implementation to determine what to do in this case. Passing X and Z will thus NOT be considered an error.

The value that we see with this revised proposal over what I have proposed originally at the meeting is:

a. Supports 4 state value emulators/accelerators.

b. Runs in compatible (congruent) mode on standard SystemVerilog simulators that support DPI. Allows conveying 4 state values to 4 state hw/SW engines that support 4 state values according to DPI data type mapping.

c. Allows vendors to offer users any option they wish for handling transfer of X and Z from the SW side to the HW side in acceleration mode. For example, 2 sates vendors can support coercion of X and Z values to 0 and 1 w/o breaking congruency as congruency is only defined within the definition of SCE-MI 2.0 spec (above). Vendors could also provide the user a 'configuration switch' that defines how the infrastructure would treat X and Z (coercion; to what values, error, support it, etc).

d. Portability of SCE-MI 2.0 transactors is guaranteed and the results in simulation mode and acceleration mode will be the same within the scope of the SCE-MI 2.0 spec.

<End Shabtay

>Per

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.
>>Russ

That's right. What I asked for is support of 4-state data types on both the SV and C sides. That is to say: a requirement to parse 4-state syntax like "logic" and "integer" without aborting due to an error. Within that I favor a coercion (user settable) of (Z,X) types into 2-state values with the compiler issuing or logging a warning. But the data type support I believe is much more important.

<<Russ
 
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.
>>JasonR

This proposal assumes the following two things:

1) The purpose of having a hardware platform that supports 4-States is to monitor X's or Z's in the DUT coming from the hardware side.

>>>Per

That seems reasonable enough.

<<<Per

2) A transactor developer or modeler would not need the ability to send X's or Z's from a BFM proxy to a BFM.

>>>Per

I would certainly argue that doing this is a bad practice. This is why I'd like to make this an error.

>>>>JasonR

If assumption (2) is false, then this proposal will not work.

>>>>>Per

Right. But even if we fully support 4-state as an option, transactors that actually rely on transporting X or Z values would only work on implementations that do support the full 4-state behavior.

>>>>>>JasonR

I agree.

<<<<<<JasonR

<<<<<Per

<<<<JasonR

<<<Per

The revised proposal from Cadence is to allow 4-state TYPES in one direction, from HW->SW, and 2-state TYPES from SW->HW. Therefore, if a vendor supports 4-state values in HW, these values are allowed to be monitored by the SW side. If the vendor does not support 4-state values, the SW side monitors the 2-state value that is in HW.

>>Per

Ok, but this does not give Russ what he wants as I assume you are aware. Russ wants the 4-state types to be supported in both directions. This is to support IP vendors and other users that uses these types without forcing them to rewrite their C sides for SCE-MI. The usage of the 4-state types does not imply that X and Z values are passed.

For your proposal to be compatible with what Russ is asking for you need to modify it to state that 4-state *types* are supported in both directions, but only 0 and 1 can be passed from the SW side to the HW side. Do you agree?

>>>JasonR

Russ, can you confirm that you want the ability to send X's or Z's from SW->HW? If this is the case, then my proposal will not work.

>>>>Russ

I don't want the ability to send X's or Z's in any direction. I just want the

IFLC or compiler or whatever you call it to not reject 4-state data types.

I also don't think (but with less fervency) that sending X's or Z's should cause a run time error.

>>>>>Per

I'd like to understand why you do not want this to be an error.

>>>>>>Russ

I can see a situation where there'd be a simulation model -- used mostly for simulation -- which needs to be ported (hopefully we can deprecate that work "port") to emulation/hw acceleration.

Say this model is sending and receiving 4-state values ('X's and 'Z's) in many places.

To port to emulation, since SCEMI 2.0 allows the DPI 4-state data types to be used, is an exercise in going through the application code and either commenting out, changing, or ifdef-ing around the offending code that sends 'X's and 'Z's.

(Let's confine this case to the C->HDL half of the problem for now).

So, the poor sap responsible for effecting the changes runs the code through the

IFLC, then emulates, and gets 200 warnings before the sim crashes due to coerced values causing aberrant behavior.

Upon looking at the warnings, it is noticed that 190 of them are for 4-state writes to sections of the DUT that are "turned off" for this particular simulation.

Thus, only a few sections of code needed to be changed: the rest can send coerced values all day long to the quiescent part of the DUT and it will not affect the whole simulation and the expected result.

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?

>>>>>>>Per

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.

>>>>>>>Russ

Yep, these are conflicting concerns. My inclination is to lean towards forcing portability over other factors, so this is an exception to these inclinations.

<<<<<<<<Russ

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)?

>>>>>>>>Russ

I don't know. Within our (BRCM) verification environment, we do have simulation-only transactors that do communicate 4-state values with their C proxies. I think the most common usage is to set 'Z' values to some transactor that interfaces to a bus. Of course, this could easily be done by some 2-state command that causes the hw transactor to drive the 'Z' value.

<<<<<<<<Russ

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.

>>>>>>>>Russ

Me too. I'm just concerned about getting a consensus for requiring the generation of warnings/errors. This seems to be a sticking point and I don't think it's worth spending a lot of time on it. Any product
that didn't issue these warnings/errors would probably be barraged with customer complaints and it would be a "bug report"/"feature request" in short order.

In an ideal world, a product would have settable levels: coercion, warning issuance, error generation could be controlled by the user. Default would be coercion and a warning issuance.

<<<<<<<<Russ

<<<<<<<Per

<<<<<<Russ

<<<<<Per

I'd rather have a warning generated and the data coerced to 1's or 0's. Leaving it as "undefined behavior" is acceptable as long as that's not universally interpreted by all SCEMI 2.0 vendors as allowing a run time error to occur.

>>>>>Per

So you are actually asking for some definition within the `undefined

behavior' :-)

<<<<<Per

<<<<Russ

>>>>Per

I think you were missing the point of what Russ was asking for. Russ was not asking for support for transporting X and Z in any direction. He was asking for the 4-state value *types* to be allowed by SCE-MI both on the hardware side and software side. This is to make it easier for IP vendors and users who are used to using 4 state types on the hardware side to port their models to SCE-MI 2.0. They would not have to rewrite their code to use 2 state types.

>>>>>JasonR

My thoughts were: (a) if the modeler does not intend to send X or Z values from SW->HW, and (b) we agree that it is bad practice to send X or Z from SW->HW, then why not force the modeler to only use 2-state types in that direction? This was an attempt at finding a "happy medium".

<<<<<JasonR

<<<<Per

<<<JasonR

<<Per

>>>Per

Shabtay said that usage of 4-state values X and Z and 4-state types in the SW->HW direction is left as undefined behavior in SCE-MI. Are you now contradicting him?

>>>>JasonR

In this proposal, there would be no need for undefined behavior if only 2-state types are allowed in the SW->HW direction.

>>>>>Per

I am still confused. Did you actually present another modification to Shabtay's 4-state support proposal? Shabtay specifically mentioned the point about the undefined behavior being part of the standard. You seem to be supporting to make usage of 4-state types or at least X and Z in the SW to HW direction errors. Is this true? The phrase `allowed' makes me think so. So what is Cadence's proposal now?

>>>>>JasonR

Sorry for the confusion. After re-reading Shabtay's email in it's entirety, yes, this was a modification. Since we've gotten responses that users want to see 4-state types in both directions, our proposal remains what is written in Shabtay's email.

<<<<<JasonR

<<<<<Per

<<<<JasonR

<<<Per

Allowing only 2-state types to be passed from HW->SW removes the need for coercing 4-state values into 2-state values, and promotes a better modeling style.

>>>Per

That's true, but Russ will not be satisfied.

<<<Per

>>>JohnS

I think this was a typo - you mean SW->HW here right ?

>>>>JasonR

Yes, this is a typo. Thanks for catching it.

<<<<JasonR

<<<JohnS

This approach would be fairly simple to enforce:

export "DPI-C" function callme;

function void callme;

input logic [31:0] badarg; // This would be an error

input bit [31:0] goodarg; // This would be OK

output logic [31:0] goodarg1; // This would be OK

output bit [31:0] goodarg2: // This would be OK

begin

end

endfunction

>>>JohnS

What if we said that 'badarg' is not an error but just a forced coercion to 2-state ?

>>>>JasonR

I'm ok with that.

<<<<JasonR

I think this is in line with what Per, in his response to your e-mail, said would satisfy Russ's requirements.

I think it would also still accomplish the goal of removing ambiguity of "undefined" behavior which I think you are trying to do. For portability reasons, I'm not comfortable with "undefined" behavior either and I think it is worth removing any possibility of it.

I guess the only hole I see in this revised version of your proposal is that if X or Z values are passed from HW by a simulator that supports 4-state, the C-models may behave differently than the same models running on a simulator that only supports 2-state. But this may be OK.

>>>>JasonR

If HW passes a value that is X/Z for a platform that supports 4-state, but passes 0/1 for a platform that only supports 2-state, neither is wrong. Both pass the current value that is in HW. It is up to the user to develop a model that does not require seeing X or Z values coming from hardware. In my opinion, it is good practice to do this anyway.

<<<<JasonR

In former case a C model might flag errors, or warnings for undefined's it sees and in the later case, the same C model would not see X or Z values and therefore happily process the 0's and 1's that it does see.

I guess in that sense the model would be portable, just behavior would be different right?

>>>>JasonR

Yes, the model should be portable even though behavior may be different. It would be the users' responsibility to ensure portability by not writing a model that relies on seeing unknowns.

<<<<JasonR

<<<JohnS

With this proposal, there is no "undefined" case, since 'logic' data types are only supported as outputs in exported DPI functions, and as inputs in imported DPI functions.

>>>Per

Shabtay said that usage of 4-state values X and Z and 4-state types in the SW->HW direction is left as undefined behavior in SCE-MI. Are you now contradicting him?

<<<Per

<<End JasonR
 
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.

<End Per

Duaine + Bryan Proposal>

Summary

- The user selects the preferred mode at run time based on a description of the implementation capabilities.

- Allow the implementation to support a number of different modes

2-state mode only (strict) – report error if X/Z passed to emulator

This is the minimum supported mode and the default mode.

2-state mode with selectable coercion

User specifies coercion mapping (X = 0/1; Z=0/1)

User specifies if warning is issued for X/Z in this mode or not

4-state mode (no coercion)

- Allow the user to query the implementation capabilities at initialization time.

- Allow the user to select the preferred mode of implementation operation after the query.

- Allow the user to select the preferred mode of TB.

- Selecting an unsupported mode results in an error.

- Question: Do we allow an implementation to support only two-state types at run time?

New Calls

- Update SCEMIInit, to take an argument, or add a new call SCEMICapabilities.

SCEMIInit(struct SCEMICapabilities *e); or

SCEMIQueryCapabilities(struct SCEMICapabilities *e);

- The SCEMICapabilities structure has one member, StateSupport, an enumerated type.

- Add SCEMISelectCapabilities(const SCEMICapabilities *e,int XValue, int YValue);

This selcets mode and coercion.

Usage example pseudocode:

SCEMIInit(SCEMICapabilities &e);

if( e.StateSupport == FullFourState) {

request full four state;

set TB mode to four state;

} else if (e.StateSupport == FourStateTypesWithCoercion) {

Specify coercion X/Z to (0,1)

set TB mode to two state;

} else if (e.StateSupport == TwoStateStrict) {

set TB mode to strict two state

} else if (e.StateSupport == TwoStateTypesOnly ) {

Set TB mode to two state only mode

} else {

/* this should have been detected at compile time - ie. 2 state minimum is required */

throw("compiled against the wrong library");

}

Note: As per your modification, at run time, the emulator is queried at init for its capabilities (hidden to user in middleware/rendezvous)

- if the user mode selected fits within the capability of the emulator -> accepted

- if the user mode selected does not meet the emulator’s capability -> error @ init time

Example:

- Emulator capable of 2-state, with or without coercion

Case 1:

- User selects: 4-state (no coercion)

- Emulator will report error

Case 2:

- User selects: 2-state (coercion), mapping X=0, Z=1, no warning

- Emulator accepts and runs without warning

<End Duaine + Bryan

>Per

Thanks for your comprehensive proposal. At first blush this looks pretty complicated but also seems to allow most of the different behaviors people have been proposing/requesting. I'd like to see this described firmly in terms of what is mandated and what is optional to implement. I can deduce that more or less from the text, but it would still be nice to have a firm description. For instance, start out describing the mandated features and then follow with the different options.

Some specific questions/suggestions:

> 2-state mode only (strict) – report error if X/Z passed to emulator

> This is the minimum supported mode and the default mode.

I like that you made this the default mode. This will make it require a conscious action by the user to get into potential non-portable territory. This is obviously a mandated feature and the lowest common denominator.

> 2-state mode with selectable coercion

> User specifies coercion mapping (X = 0/1; Z=0/1)

> User specifies if warning is issued for X/Z in this mode or not

This is optional, I presume. Is this to be considered an atomic feature? That is, if an implementation choses to implement this, it must implement *all* of it, right? I like the user specified coercion mapping. Should we specify a default mapping in case the user does not care? Should we speficy a default warning option, e.g., warn by default, allow the user to turn warnings off?

> 4-state mode (no coercion)

Another obviously optional feature. I presume this requires 4-state support on the HW side. Dumb question I guess, given the no coercion clause . . .

> - Allow the user to query the implementation capabilities at

> initialization time.

> - Allow the user to select the preferred mode of implementation

> operation after the query.

> - Allow the user to select the preferred mode of TB.

The selection methods you've proposed are runtime methods. Does it make sense to specify compile/link time options as well, i.e., mechanisms that allow the user to essentially select the default behavior at compile/link time?

> - Selecting an unsupported mode results in an error.

Fatal error, good.

> - Question: Do we allow an implementation to support only

> two-state types at run time?

Good question. What about at compile time?

> - Update SCEMIInit, to take an argument, or add a new call

> SCEMICapabilities.

> SCEMIInit(struct SCEMICapabilities *e);

Assuming you are talking about the C API here, we would have to change the name to SCEMIInitCapabilities() for instance, since we cannot overload the original SCEMIInit(), and we can't change it without breaking backwards compatibility.

In any event, your example seemed to indicate that SCEMIInit() would return with the supported capabilities in the SCEMICapabilities structure. In the example, an enumerated type was used to encode the current selected mode. Then the code went off to set the TB mode. By `TB mode' I assume you were referring to the mode of the SCE-MI application code such that SCE-MI models and other code would adapt to whether 4-state, 2-state, etc. was being used, right?

In the query/select model, I assume the query method would return a set of supported modes, not just a value of an enumerated type. On possibility is that each mode is a bit in a vector or simply a boolean flag in the structure. Or were you envisioning the modes to be hierarchical, e.g., if you support full 4-state, then you have to support 2-state with coercion and strict 2-state (well that's required since it is the default mode)?

I like your proposal. The more I look at it, the simpler it appears. But we have definitely crossed into new territory by allowing optional behavior and compliant but non-portable models . . . So we would need some text to explain these points, do you agree?