-----Bounced mail from Gord----- Date: Sat, 15 Dec 2007 12:09:43 -0800 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 =20 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=20 > -----Original Message----- > From: owner-sv-bc@server.eda.org=20 > [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 >=20 > Shalom, this one I will object to. >=20 > You have: > If not coerced to inout, a warning shall be issued. If=20 >coercion does > not occur, the additional assignment to the signal sink=20 >occurs, but > the port direction is preserved and the assignment does=20 not >pass through > the port connection to the signal source. >=20 > This does not allow for a collapsing approach since you have: > "If coercion does not occur..." >=20 > At the very least this must be something like, "If an=20 >implementation neither coerces such a port nor collapses it,=20 the >addiitonal...." >=20 > Gord. >=20 > Bresticker, Shalom wrote: > > I have uploaded yet another version of this. > >=20 > > Shalom > >=20 > >> -----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=20 > this Mantis is=20 > >> to clarify what is meant by "an input(output) used as an=20 > >> output(input)" in its most common form (not PLI or hierarchical=20 > >> reference) and what is the behavior if coercion does not occur. > >> > >> The phrase has very frequently been misunderstood, even by=20 > committee=20 > >> members, and the behavior if coercion does not occur is > >> completely=20 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 > >=20 > --------------------------------------------------------------------- > > Intel Israel (74) Limited > >=20 > > This e-mail and any attachments may contain confidential=20 > material for=20 > > the sole use of the intended recipient(s). Any review or=20 > distribution=20 > > by others is strictly prohibited. If you are not the intended=20 > >recipient, please contact the sender and delete all copies. > >=20 > >=20 > >=20 > >=20 > ---------------------------------------------------------------------- > > -- > >=20 > > Mantis 1573 > >=20 > > P1800-2008/D4, 22.3.3.1 > >=20 > > Clarify input used as output and vice-versa =20 CHANGE =20 > > *22.3.3.1 Port coercion* > >=20 > > A port that is declared as input (output) but used as an output=20 > > (input) or inout may be coerced to inout. If not coerced to=20 > inout, a=20 > > warning shall be issued. > >=20 > >=20=20 > >=20 > > TO > >=20 > > *22.3.3.1 Port coercion* > >=20 > > A port that is declared as input (output) but used as an output=20 > > (input) or inout may be coerced to inout. If not coerced to=20 > inout, a=20 > > warning shall be issued. > >=20 > >=20=20 > >=20 > >=20=20 > >=20 > >=20=20 > >=20 > > CHANGE > >=20 > > *22.3.3.7 Port connections with dissimilar net types (net and port > > collapsing)* > >=20 > > * * > >=20 > > *TO* > >=20 > > *22.3.3.76** Port** connections with dissimilar net types (net > >and=20 port > > collapsing)* > >=20 > >=20=20 > >=20 > >=20=20 > >=20 > > ADD NEW > >=20 > > *22.3.3.7 Port coercion* > >=20 > >=20=20 > >=20 > > When both sides of an input or output port are nets and there is > >an=20 additional assignment to the port connection signal sink other > >than=20 through the port connection (i.e., input port used as an > >output or=20 output port used as an input), the port may be coerced > >to inout. If=20 not coerced to inout, a warning shall be issued. > >If=20 > coercion does not=20 > > occur, the additional assignment to the signal sink occurs, but > > the=20 port direction is preserved and the assignment does not=20 > pass through=20 > > the port connection to the signal source. > >=20 > >=20=20 > >=20 > > Example of an input port used as an output and of an output=20 > port used=20 > > as an input: > >=20 > >=20=20 > >=20 > > *module* top ; > >=20 > > *wire* in1, out1 ; > >=20 > > m m(in1, out1); > >=20 > > *assign* out1 =3D 1'b1; > >=20 > > *endmodule*** > >=20 > >=20=20 > >=20 > >=20=20 > >=20 > > *module* m (in1, out1) ; > >=20 > > *input* in1 ; > >=20 > > *output* out1; // out1 is driven outside the module=20 > and thus used=20 > > as an input > >=20 > > *assign* in1 =3D 1'b0 ; // in1 is driven within the module=20 > and thus used=20 > > as an output > >=20 > > *endmodule*** > >=20 > >=20=20 > >=20 >=20 > -- > -------------------------------------------------------------------- > Gordon Vreugdenhil 503-685-0808 > Model Technology (Mentor Graphics) gordonv@model.com >=20 >=20 > --=20 > This message has been scanned for viruses and dangerous content by >MailScanner, and is believed to be clean. >=20 >=20 --------------------------------------------------------------------- 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. --=20 This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ------_=_NextPart_001_01C83F56.6E7B5212 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; charset=3Diso-8859-= 1"> <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version 6.5.7652.24"> <TITLE>RE: [sv-bc] Mantis 1573</TITLE> </HEAD> <BODY> <!-- Converted from text/plain format --> <BR> <P><FONT SIZE=3D2>I'm not opposed to not mentioning collapsing -- I am<BR> opposed to saying that one "shall" report a port direction<BR> waring if the implementation doesn't coerce. As long<BR> as no one claims that a collapsing (non-coercing)<BR> implementation is required to warn, I am fine. <BR> <BR> My basic concern is that either collapsing or coercion<BR> is fine; attaching a *required* warning to be absence<BR> of coercion is objectionable only if someone would<BR> then claim that a collapsing implementation must warn.<BR> <BR> I agree with Steven that "it can be thought of as"<BR> a result of collapsing.<BR> <BR> Gord.<BR> <BR> -----Original Message-----<BR> From: Bresticker, Shalom [<A HREF=3D"mailto:shalom.bresticker@intel.com">ma= ilto:shalom.bresticker@intel.com</A>]<BR> Sent: Sat 12/15/2007 10:36 AM<BR> To: Vreugdenhil, Gordon<BR> Cc: sv-bc<BR> Subject: RE: [sv-bc] Mantis 1573<BR> <BR> Gord,<BR> <BR> I'm very disappointed that you and Steven seem to have incompatible<BR> positions. You are opposed to not mentioning collapsing in addition to<BR> coercion and he is opposed to mentioning collapsing in the context of<BR> coercion.<BR> <BR> Note that the current LRM text on coercion also does not mention<BR> collapsing in the context of coercion. I don't think my proposed text<BR> changes anything on the relationship between them.<BR> <BR> Since you also said that you don't have a problem with the existing<BR> text, your two positions seem inconsistent to me.<BR> <BR> I understood Steven to mean, among other things, that coercion can be<BR> thought of as a result of collapsing, so that coercion includes<BR> collapsing.<BR> <BR> I don't object to your proposed rewording. I just want you two to find a<BR> mutually acceptable compromise so that it can more easily pass at the<BR> Champions' level as well. Failing that, I'll accept whatever will pass<BR> SV-BC with the fewest objections.<BR> <BR> Regards,<BR> Shalom<BR> <BR> > -----Original Message-----<BR> > From: owner-sv-bc@server.eda.org<BR> > [<A HREF=3D"mailto:owner-sv-bc@server.eda.org">mailto:owner-sv-bc@serv= er.eda.org</A>] On Behalf Of Gordon Vreugdenhil<BR> > Sent: Friday, December 14, 2007 4:58 PM<BR> > To: Bresticker, Shalom<BR> > Cc: sv-bc<BR> > Subject: Re: [sv-bc] Mantis 1573<BR> ><BR> > Shalom, this one I will object to.<BR> ><BR> > You have:<BR> > If not coerced to inout, a warning shall be is= sued. If<BR> > coercion does<BR> > not occur, the additional assignment to the si= gnal sink<BR> > occurs, but<BR> > the port direction is preserved and the assign= ment does<BR> > not pass through<BR> > the port connection to the signal source.<BR> ><BR> > This does not allow for a collapsing approach since you have:<BR> > "If coercion does not occur..."<BR> ><BR> > At the very least this must be something like, "If an<BR> > implementation neither coerces such a port nor collapses it,<BR> > the addiitonal...."<BR> ><BR> > Gord.<BR> ><BR> > Bresticker, Shalom wrote:<BR> > > I have uploaded yet another version of this.<BR> > ><BR> > > Shalom<BR> > ><BR> > >> -----Original Message-----<BR> > >> From: Bresticker, Shalom<BR> > >> Sent: Friday, December 14, 2007 11:34 AM<BR> > >> To: sv-bc<BR> > >> Subject: RE: [sv-bc] Mantis 1573<BR> > >><BR> > >> I want to emphasize again that the original purpose of<BR> > this Mantis is<BR> > >> to clarify what is meant by "an input(output) used as an= <BR> > >> output(input)" in its most common form (not PLI or hiera= rchical<BR> > >> reference) and what is the behavior if coercion does not occu= r.<BR> > >><BR> > >> The phrase has very frequently been misunderstood, even by<BR> > committee<BR> > >> members, and the behavior if coercion does not occur is compl= etely<BR> > >> unspecified by the LRM.<BR> > >><BR> > >> So from the point of view of users, this issue is important.<= BR> > >><BR> > >> I'm going to make another try at wordsmithing this proposal.<= BR> > >><BR> > >> Shalom<BR> > ><BR> > ---------------------------------------------------------------------<= BR> > > Intel Israel (74) Limited<BR> > ><BR> > > This e-mail and any attachments may contain confidential<BR> > material for<BR> > > the sole use of the intended recipient(s). Any review or<BR> > distribution<BR> > > by others is strictly prohibited. If you are not the intended<BR> > > recipient, please contact the sender and delete all copies.<BR> > ><BR> > ><BR> > ><BR> > ><BR> > ----------------------------------------------------------------------= <BR> > > --<BR> > ><BR> > > Mantis 1573<BR> > ><BR> > > P1800-2008/D4, 22.3.3.1<BR> > ><BR> > > Clarify input used as output and vice-versa<BR> > ><BR> > > CHANGE<BR> > ><BR> > > *22.3.3.1 Port coercion*<BR> > ><BR> > > A port that is declared as input (output) but used as an output<B= R> > > (input) or inout may be coerced to inout. If not coerced to<BR> > inout, a<BR> > > warning shall be issued.<BR> > ><BR> > > <BR> > ><BR> > > TO<BR> > ><BR> > > *22.3.3.1 Port coercion*<BR> > ><BR> > > A port that is declared as input (output) but used as an output<B= R> > > (input) or inout may be coerced to inout. If not coerced to<BR> > inout, a<BR> > > warning shall be issued.<BR> > ><BR> > > <BR> > ><BR> > > <BR> > ><BR> > > <BR> > ><BR> > > CHANGE<BR> > ><BR> > > *22.3.3.7 Port connections with dissimilar net types (net and por= t<BR> > > collapsing)*<BR> > ><BR> > > * *<BR> > ><BR> > > *TO*<BR> > ><BR> > > *22.3.3.76** Port** connections with dissimilar net types (net an= d<BR> > > port<BR> > > collapsing)*<BR> > ><BR> > > <BR> > ><BR> > > <BR> > ><BR> > > ADD NEW<BR> > ><BR> > > *22.3.3.7 Port coercion*<BR> > ><BR> > > <BR> > ><BR> > > When both sides of an input or output port are nets and there is = an<BR> > > additional assignment to the port connection signal sink other th= an<BR> > > through the port connection (i.e., input port used as an output o= r<BR> > > output port used as an input), the port may be coerced to inout. = If<BR> > > not coerced to inout, a warning shall be issued. If<BR> > coercion does not<BR> > > occur, the additional assignment to the signal sink occurs, but t= he<BR> > > port direction is preserved and the assignment does not<BR> > pass through<BR> > > the port connection to the signal source.<BR> > ><BR> > > <BR> > ><BR> > > Example of an input port used as an output and of an output<BR> > port used<BR> > > as an input:<BR> > ><BR> > > <BR> > ><BR> > > *module* top ;<BR> > ><BR> > > *wire* in1, out1 ;<BR> > ><BR> > > m m(in1, out1);<BR> > ><BR> > > *assign* out1 =3D 1'b1;<BR> > ><BR> > > *endmodule***<BR> > ><BR> > > <BR> > ><BR> > > <BR> > ><BR> > > *module* m (in1, out1) ;<BR> > ><BR> > > *input* in1 ;<BR> > ><BR> > > *output* out1; // out1 = is driven outside the module<BR> > and thus used<BR> > > as an input<BR> > ><BR> > > *assign* in1 =3D 1'b0 ; // in1 is driven within the module<BR> > and thus used<BR> > > as an output<BR> > ><BR> > > *endmodule***<BR> > ><BR> > > <BR> > ><BR> ><BR> > --<BR> > --------------------------------------------------------------------<B= R> > Gordon Vreugdenhil &nbs= p; &nbs p;&= nbsp; 503-685-0808<BR> > Model Technology (Mentor Graphics) = gordonv@model.com<BR> ><BR> ><BR> > --<BR> > This message has been scanned for viruses and<BR> > dangerous content by MailScanner, and is<BR> > believed to be clean.<BR> ><BR> ><BR> ---------------------------------------------------------------------<BR > Intel Israel (74) Limited<BR> <BR> This e-mail and any attachments may contain confidential material for<BR> the sole use of the intended recipient(s). Any review or distribution<BR> by others is strictly prohibited. If you are not the intended<BR> recipient, please contact the sender and delete all copies.<BR> <BR> <BR> </FONT> </P> </BODY> <br />--=20 <br />This message has been scanned for viruses and <br />dangerous content by <a href=3D"http://www.mailscanner.info/"><b>MailScanner</b></a>, and is <br />believed to be clean. </HTML> ------_=_NextPart_001_01C83F56.6E7B5212-- -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Sat Dec 15 15:03:06 2007
This archive was generated by hypermail 2.1.8 : Sat Dec 15 2007 - 15:03:20 PST