Re: [sv-bc] E-mail Vote: Respond by 8am PDT, Monday, October 29 - 1573

Shalom,

I do appreciate that the intent is to clarify this.  I think that objections
might go away if the language was softened.  The proposed change to "shall"
is a big problem for sure.  On top of that, the "locality" of the
cause for the coercion is not correctly described.

So, the proposal shouldn't try to enumerate all situations that
cause coercion.  Rather it should give an example scenario under
which coercion would be expected *if* an implementation did coercion
at all.  Such a clarification would likely be acceptable.

You would have to be careful not to imply that coercion is *required*
in order to write to an input or read from an output.  You have
to talk separately about the fact that collapsing ignores
directions and thus allows reads/writes to the collapsed net.  That
is not the same as coercing a port and if the two concepts become
tied together while trying to clarify the read/write rules, you'll
continue to get objections.

Gord.



Bresticker, Shalom wrote:
> Hi,
> 
> Since I took on the issue, and Yulik filed it after discussions with me,
> let me clarify.
> 
> I have had no intention of changing any behavior, just of clarification
> of existing behavior.
> 
> The phrase "input used as output" and its converse are ambiguous and
> have been often misinterpreted. The question of whether or not it is
> legal to assign to an input and what happens if you do so has also been
> repeatedly asked.
> 
> Users will welcome any clarification of these subjects.
> 
> Regards,
> Shalom
> 
>> -----Original Message-----
>> From: Gordon Vreugdenhil [mailto:gordonv@model.com] 
>> Sent: Monday, October 29, 2007 4:50 PM
>> To: Bresticker, Shalom
>> Cc: sv-bc@server.eda.org
>> Subject: Re: [sv-bc] E-mail Vote: Respond by 8am PDT, Monday, 
>> October 29 - 1573
>>
>>
>>
>> Brad Pierce wrote:
>>> Forcing port collapsing would not be backward compatible.
>>>
>>>> If there is
>>>> a desire to force implementations to coerce ports when 
>> possible, then 
>>>> there should be text saying that port collapsing must be done 
>>>> whenever possible (and clarifying some of the cases where 
>> it may not 
>>>> be clear whether it is possible).
>>
>> I think this exchange is at the core of all the objections.  
>> 1364 allows either port coercion and collapsing in 
>> implementations for historical reasons.  The assumption is 
>> that the two are "equivalent".  That is not the case.  There 
>> are various cases that Steven and I have raised where that 
>> assumption breaks down.  Any change to require either 
>> approach will cause serious objections from various vendors.
>>
>> Although I appreciate the desire to have a tighter LRM in 
>> this area, I just don't think it is feasible.  Given the time 
>> remaining, I would suggest that we not spend further effort on this.
>>
>> Gord.
>> --
>> --------------------------------------------------------------------
>> Gordon Vreugdenhil                                503-685-0808
>> Model Technology (Mentor Graphics)                gordonv@model.com
>>
> ---------------------------------------------------------------------
> Intel Israel (74) Limited
> 
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.

-- 
--------------------------------------------------------------------
Gordon Vreugdenhil                                503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.