RE: 4 State Action Item 10:52pm Tuesday 10/18

Hi Ramesh,
    The email went out 10/18 and was a text attachment to that email. Please
let me know if for some reason you did not receive that. Alternatively,
there is a complete email log on the web site at
www.eda.org/itc/hm/index.html

Best regards
Brian

-----Original Message-----
From: owner-itc@eda.org [mailto:owner-itc@eda.org] On Behalf Of Ramesh
Narayanaswamy
Sent: Thursday, October 20, 2005 9:21 AM
To: bojsen@zaiqtech.com
Cc: itc@eda.org
Subject: Re: 4 State Action Item 10:52pm Tuesday 10/18

Hi Duaine and Bryan:

How does one get access to your proposal ?

I did not recieve an email, nor do i see it under the issues section of the
itc web page.

Per Bojsen wrote:
> 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
> 


-- 
regards,
Ramesh