Hi Duaine and Bryan, 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? Thanks, Per -- Per Bojsen Email: <bojsen@zaiqtech.com> Zaiq Technologies, Inc. WWW: http://www.zaiqtech.com 78 Dragon Ct. Tel: 781 721 8229 Woburn, MA 01801 Fax: 781 932 7488Received on Thu Oct 20 07:43:13 2005
This archive was generated by hypermail 2.1.8 : Thu Oct 20 2005 - 07:43:16 PDT