RE: [sv-bc] Mantis 1573

But the LRM *already* says that if coercion is not done, a warning
*shall* be issued.
 
Shalom


________________________________

	From: Vreugdenhil, Gordon [mailto:gordon_vreugdenhil@mentor.com]

	Sent: Saturday, December 15, 2007 10:10 PM
	To: Bresticker, Shalom
	Cc: sv-bc
	Subject: RE: [sv-bc] Mantis 1573
	
	


	I'm not opposed to not mentioning collapsing -- I am
	opposed to saying that one "shall" report a port direction
	waring if the implementation doesn't coerce.  As long
	as no one claims that a collapsing (non-coercing)
	implementation is required to warn, I am fine. 
	
	My basic concern is that either collapsing or coercion
	is fine; attaching a *required* warning to be absence
	of coercion is objectionable only if someone would
	then claim that a collapsing implementation must warn.
	
	I agree with Steven that "it can be thought of as"
	a result of collapsing.
	
	Gord.
	
	-----Original Message-----
	From: Bresticker, Shalom [mailto:shalom.bresticker@intel.com]
	Sent: Sat 12/15/2007 10:36 AM
	To: Vreugdenhil, Gordon
	Cc: sv-bc
	Subject: 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.
	
	
	

---------------------------------------------------------------------
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.