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

Hi Brian:
Sorry, i did recieve Duaine's proposal e-mail; i was looking for it under the wrong heading/folder. 
We went from '4 State Logic' to '4 State Action' :-)

Brian Bailey wrote:
> 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