RE: [sv-bc] Mantis 1573

Gord,

I'm very disappointed that you and Steven seem to have incompatible
positions. You are opposed to not mentioning collapsing in addition to
coercion and he is opposed to mentioning collapsing in the context of
coercion.

Note that the current LRM text on coercion also does not mention
collapsing in the context of coercion. I don't think my proposed text
changes anything on the relationship between them.

Since you also said that you don't have a problem with the existing
text, your two positions seem inconsistent to me.

I understood Steven to mean, among other things, that coercion can be
thought of as a result of collapsing, so that coercion includes
collapsing.

I don't object to your proposed rewording. I just want you two to find a
mutually acceptable compromise so that it can more easily pass at the
Champions' level as well. Failing that, I'll accept whatever will pass
SV-BC with the fewest objections.

Regards,
Shalom 

> -----Original Message-----
> From: owner-sv-bc@server.eda.org 
> [mailto:owner-sv-bc@server.eda.org] On Behalf Of Gordon Vreugdenhil
> Sent: Friday, December 14, 2007 4:58 PM
> To: Bresticker, Shalom
> Cc: sv-bc
> Subject: Re: [sv-bc] Mantis 1573
> 
> Shalom, this one I will object to.
> 
> You have:
>     If not coerced to inout, a warning shall be issued. If 
> coercion does
>     not occur, the additional assignment to the signal sink 
> occurs, but
>     the port direction is preserved and the assignment does 
> not pass through
>     the port connection to the signal source.
> 
> This does not allow for a collapsing approach since you have:
>     "If coercion does not occur..."
> 
> At the very least this must be something like, "If an 
> implementation neither coerces such a port nor collapses it, 
> the addiitonal...."
> 
> Gord.
> 
> Bresticker, Shalom wrote:
> > I have uploaded yet another version of this.
> > 
> > Shalom
> > 
> >> -----Original Message-----
> >> From: Bresticker, Shalom
> >> Sent: Friday, December 14, 2007 11:34 AM
> >> To: sv-bc
> >> Subject: RE: [sv-bc] Mantis 1573
> >>
> >> I want to emphasize again that the original purpose of 
> this Mantis is 
> >> to clarify what is meant by "an input(output) used as an 
> >> output(input)" in its most common form (not PLI or hierarchical 
> >> reference) and what is the behavior if coercion does not occur.
> >>
> >> The phrase has very frequently been misunderstood, even by 
> committee 
> >> members, and the behavior if coercion does not occur is completely 
> >> unspecified by the LRM.
> >>
> >> So from the point of view of users, this issue is important.
> >>
> >> I'm going to make another try at wordsmithing this proposal.
> >>
> >> Shalom
> > 
> ---------------------------------------------------------------------
> > 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.
> > 
> > 
> > 
> > 
> ----------------------------------------------------------------------
> > --
> > 
> > Mantis 1573
> > 
> > P1800-2008/D4, 22.3.3.1
> > 
> > Clarify input used as output and vice-versa
> > 
> > CHANGE
> > 
> > *22.3.3.1 Port coercion*
> > 
> > A port that is declared as input (output) but used as an output 
> > (input) or inout may be coerced to inout. If not coerced to 
> inout, a 
> > warning shall be issued.
> > 
> >  
> > 
> > TO
> > 
> > *22.3.3.1 Port coercion*
> > 
> > A port that is declared as input (output) but used as an output 
> > (input) or inout may be coerced to inout. If not coerced to 
> inout, a 
> > warning shall be issued.
> > 
> >  
> > 
> >  
> > 
> >  
> > 
> > CHANGE
> > 
> > *22.3.3.7 Port connections with dissimilar net types (net and port
> > collapsing)*
> > 
> > * *
> > 
> > *TO*
> > 
> > *22.3.3.76** Port** connections with dissimilar net types (net and 
> > port
> > collapsing)*
> > 
> >  
> > 
> >  
> > 
> > ADD NEW
> > 
> > *22.3.3.7 Port coercion*
> > 
> >  
> > 
> > When both sides of an input or output port are nets and there is an 
> > additional assignment to the port connection signal sink other than 
> > through the port connection (i.e., input port used as an output or 
> > output port used as an input), the port may be coerced to inout. If 
> > not coerced to inout, a warning shall be issued. If 
> coercion does not 
> > occur, the additional assignment to the signal sink occurs, but the 
> > port direction is preserved and the assignment does not 
> pass through 
> > the port connection to the signal source.
> > 
> >  
> > 
> > Example of an input port used as an output and of an output 
> port used 
> > as an input:
> > 
> >  
> > 
> > *module* top ;
> > 
> > *wire* in1, out1 ;
> > 
> > m m(in1, out1);
> > 
> > *assign* out1 = 1'b1;
> > 
> > *endmodule***
> > 
> >  
> > 
> >  
> > 
> > *module* m (in1, out1) ;
> > 
> > *input* in1 ;
> > 
> > *output* out1;        // out1 is driven outside the module 
> and thus used 
> > as an input
> > 
> > *assign* in1 = 1'b0 ; // in1 is driven within the module 
> and thus used 
> > as an output
> > 
> > *endmodule***
> > 
> >  
> > 
> 
> --
> --------------------------------------------------------------------
> 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.
> 
> 
---------------------------------------------------------------------
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.


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