Number | 52
|
Category | errata
|
Synopsis | : 5.6.6 Port connections
|
State | closed
|
Class | duplicate
|
Arrival-Date | Oct 16 2001
|
Originator | Shalom Bresticker <Shalom.Bresticker@motorola.com>
|
Release | 2001b
|
Environment |
|
Description |
This is a multi-part message in MIME format. --------------5545FAE29C952F2B12BA2901 Content-Type: multipart/alternative; boundary="------------E840969C7C9400A04D72BCAF" --------------E840969C7C9400A04D72BCAF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit -- ************************************************************************** Shalom Bresticker Shalom.Bresticker@motorola.com Motorola Semiconductor Israel, Ltd. Tel #: +972 9 9522268 P.O.B. 2208, Herzlia 46120, ISRAEL Fax #: +972 9 9522890 ************************************************************************** --------------E840969C7C9400A04D72BCAF Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit <!doctype html public "-//w3c//dtd html 4.0 transitional//en"> -- ************************************************************************** Shalom Bresticker Shalom.Bresticker@motorola.com Motorola Semiconductor Israel, Ltd. Tel #: +972 9 9522268 P.O.B. 2208, Herzlia 46120, ISRAEL Fax #: +972 9 9522890 ************************************************************************** --------------E840969C7C9400A04D72BCAF-- --------------5545FAE29C952F2B12BA2901 Received: from m-il06-r4.mot.com ([129.188.137.196]) by zil05exm01.sps.mot.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2654.52) id 4JW8KSFK; Mon, 15 Oct 2001 15:51:03 +0200 Received: from zil05exm01.sps.mot.com by m-il06-r4.mot.com with ESMTP for Shalom.Bresticker@motorola.com; Mon, 15 Oct 2001 08:51:01 -0500 Received: from motorola.com (eagle.msil.sps.mot.com [223.131.95.41]) by zil05exm01.sps.mot.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2654.52) id 4JW8KSF1; Mon, 15 Oct 2001 15:50:58 +0200 Return-Path: <Shalom_Bresticker-R50386@email.mot.com> Sender: shalom@m-il06-r4.mot.com Message-Id: <3BCAE9C2.86BF0361@motorola.com> Date: Mon, 15 Oct 2001 15:50:58 +0200 From: Shalom Bresticker <Shalom_Bresticker-R50386@email.mot.com> Organization: Motorola Semiconductor Israel, Ltd. (MSIL) X-Mailer: Mozilla 4.73 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: btf@boyd.com Subject: Re: 1364: 5.6.6 Port connections References: <3BCAE93D.6C09523D@motorola.com> Content-Type: multipart/mixed; boundary="------------B580F83CAC864757FA0B55AE" X-Mozilla-Status2: 00000000 This is a multi-part message in MIME format. --------------B580F83CAC864757FA0B55AE Content-Type: multipart/alternative; boundary="------------AEF92324A216ED6FA4B30319" --------------AEF92324A216ED6FA4B30319 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sorry, wrong example. The right example is attached. Shalom Bresticker wrote: I have a question: 5.6.6 says that "Ports connect processes through implicit continuous assignment statements or implicit bidirectional connections ... Ports can always be represented as declared objects connected as follows: If an input port, then a continuous assignment from an outside expression to a local (input) net ..." Regarding strengths of continuous assignments, 6.1.4 says, at the end, "If drive strength is not specified, it shall default to (strong1, strong0)." If I put these two sections together, it implies that an input port will always be strong. However, we know and see that this is not so. That is, if I drive a net weakly and connect it to an input port of another module, that input port will also have a weak strength. I attach an example. Explanations ? -- ************************************************************************ ** Shalom Bresticker Shalom.Bresticker@motorola.com Motorola Semiconductor Israel, Ltd. Tel #: +972 9 9522268 P.O.B. 2208, Herzlia 46120, ISRAEL Fax #: +972 9 9522890 ************************************************************************ ** --------------AEF92324A216ED6FA4B30319 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit <!doctype html public "-//w3c//dtd html 4.0 transitional//en"> Sorry, wrong example. The right example is attached. Shalom Bresticker wrote:
5.6.6 says that
Regarding strengths of continuous assignments, 6.1.4 says, at the end,
If I put these two sections together, it implies that an input port
However, we know and see that this is not so.
I attach an example.
Explanations ? -- ************************************************************************** Shalom Bresticker Shalom.Bresticker@motorola.com Motorola Semiconductor Israel, Ltd. Tel #: +972 9 9522268 P.O.B. 2208, Herzlia 46120, ISRAEL Fax #: +972 9 9522890 ************************************************************************** --------------AEF92324A216ED6FA4B30319-- --------------B580F83CAC864757FA0B55AE Content-Type: text/plain; charset=us-ascii; name="qq.v" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="qq.v" module qq ; wire rr ; assign (weak1, weak0) rr = 1'b1 ; pp pp (rr ) ; endmodule module pp ( rr ) ; input rr ; initial #10 $display ("%v", rr ) ; endmodule --------------B580F83CAC864757FA0B55AE-- --------------5545FAE29C952F2B12BA2901 Received: from il06exr02.mot.com ([129.188.137.132]) by zil05exm01.sps.mot.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2654.52) id 4JW8KSMW; Mon, 15 Oct 2001 16:12:39 +0200 Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by il06exr02.mot.com (8.11.6/8.11.6) with ESMTP id f9FECaj18951 for <Shalom.Bresticker@motorola.com>; Mon, 15 Oct 2001 09:12:36 -0500 Received: [from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id HAA29207 for <Shalom.Bresticker@motorola.com>; Mon, 15 Oct 2001 07:12:36 -0700 (MST)] Received: [from wisbech.cl.cam.ac.uk (mta1.cl.cam.ac.uk [128.232.0.15]) by motgate4.mot.com (motgate4 2.1) with ESMTP id HAA04467 for <Shalom.Bresticker@motorola.com>; Mon, 15 Oct 2001 07:12:34 -0700 (MST)] Received: from scoter.cl.cam.ac.uk ([128.232.0.69] helo=cl.cam.ac.uk ident=djs1002) by wisbech.cl.cam.ac.uk with esmtp (Exim 3.092 #1) id 15t8Tp-0004UZ-00; Mon, 15 Oct 2001 15:12:33 +0100 X-Mailer: exmh version 2.3+CL 01/14/2001 with version: MH 6.8.4 #17[UCI] To: Shalom Bresticker <Shalom.Bresticker@motorola.com> cc: <btf@boyd.com>, <Daryl.Stewart@cl.cam.ac.uk> Subject: Re: 1364: 5.6.6 Port connections In-reply-to: Your message of "Mon, 15 Oct 2001 15:50:58 +0200." <3BCAE9C2.86BF0361@motorola.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 15 Oct 2001 15:12:32 +0100 From: Daryl Stewart <Daryl.Stewart@cl.cam.ac.uk> Message-Id: <E15t8Tp-0004UZ-00@wisbech.cl.cam.ac.uk> X-Mozilla-Status2: 00000000 I haven't done much work with wire strengths but I think the answer has something to do with "Port Collapsing". The (antique) verilog LRM (Nov 91) has a section (12.4.6) explaining that "Wherever it is possible, some tools collapse port connections during processing -- that is, the two items become one entity." This was omitted from IEEE standards for some reason, but is still observable. It would seem that in your example, since the port is a simple connection between two similar wires they can be collapsed to one, instead of being represented by a continuous assignment as the new standard claims. I have a draft description of an analysis of port connections at http://www.cl.cam.ac.uk/users/djs1002/verilog.project/papers/combining_signals. ps.gz which hilights some other consequences of port collapsing such as allowing assignments to the "wrong" side of a directional port... I did the work while ignorant of port collapsing, which was brought to my attention by Michael McNamara (I think) It's a pretty old paper - a newer description is in my thesis, currently being examined... There's a similarly old paper about wires which is relevant to errata 48 if you're interested: http://www.cl.cam.ac.uk/users/djs1002/verilog.project/papers/combining_signals. ps.gz cheers Daryl > Shalom Bresticker wrote: > > > I have a question: > > > > 5.6.6 says that > > "Ports connect processes through implicit continuous assignment statements or implicit bidirectional connections ... > > Ports can always be represented as declared objects connected as follows: > > If an input port, then a continuous assignment from an outside expression to a local (input) net ..." > > > > Regarding strengths of continuous assignments, 6.1.4 says, at the end, > > "If drive strength is not specified, it shall default to (strong1, strong0)." > > > > If I put these two sections together, it implies that an input port will always be strong. > > > > However, we know and see that this is not so. > > That is, if I drive a net weakly and connect it to an input port of another module, > > that input port will also have a weak strength. > > > > I attach an example. > > > > Explanations ? > > --------------B580F83CAC864757FA0B55AE > Content-Type: text/plain; charset=us-ascii; > name="qq.v" > Content-Transfer-Encoding: 7bit > Content-Disposition: inline; > filename="qq.v" > > module qq ; > > wire rr ; > > assign (weak1, weak0) rr = 1'b1 ; > > pp pp (rr ) ; > > endmodule > > > module pp ( rr ) ; > input rr ; > > initial #10 $display ("%v", rr ) ; > > endmodule > > --------------B580F83CAC864757FA0B55AE-- > --------------5545FAE29C952F2B12BA2901 Received: from m-il06-r4.mot.com ([129.188.137.196]) by zil05exb01.sps.mot.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2654.52) id 4JWZ36GV; Mon, 15 Oct 2001 16:19:14 +0200 Received: from zil05exm01.sps.mot.com by m-il06-r4.mot.com with ESMTP for Shalom.Bresticker@motorola.com; Mon, 15 Oct 2001 09:19:11 -0500 Received: from motorola.com (eagle.msil.sps.mot.com [223.131.95.41]) by zil05exm01.sps.mot.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2654.52) id 4JW8KS35; Mon, 15 Oct 2001 16:19:08 +0200 Return-Path: <Shalom_Bresticker-R50386@email.mot.com> Sender: shalom@m-il06-r4.mot.com Message-Id: <3BCAF05C.FADFC777@motorola.com> Date: Mon, 15 Oct 2001 16:19:08 +0200 From: Shalom Bresticker <Shalom_Bresticker-R50386@email.mot.com> Organization: Motorola Semiconductor Israel, Ltd. (MSIL) X-Mailer: Mozilla 4.73 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Daryl Stewart <Daryl.Stewart@cl.cam.ac.uk> CC: btf@boyd.com Subject: Re: 1364: 5.6.6 Port connections References: <E15t8Tp-0004UZ-00@wisbech.cl.cam.ac.uk> Content-Type: multipart/alternative; boundary="------------0DDBF433C9E57D255B67F3B0" X-Mozilla-Status2: 00000000 --------------0DDBF433C9E57D255B67F3B0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Yes, port collapsing is obviously what really happens. It saves the simulator a lot of time and memory. My problem is that it seems to contradict what we wrote in 5.6.6, which does not mention port collapsing. Collapsing is still mentioned in 12.3.10, I see, which I have not read in detail. I fear 5.6.6 is inconsistent with 12.3.10. Thanks for the references. I think I remember your old paper. I think I even read it, although I did not have time to consider it in detail. Shalom Daryl Stewart wrote: I haven't done much work with wire strengths but I think the answer has something to do with "Port Collapsing". The (antique) verilog LRM (Nov 91) has a section (12.4.6) explaining that "Wherever it is possible, some tools collapse port connections during processing -- that is, the two items become one entity." This was omitted from IEEE standards for some reason, but is still observable. It would seem that in your example, since the port is a simple connection between two similar wires they can be collapsed to one, instead of being represented by a continuous assignment as the new standard claims. I have a draft description of an analysis of port connections at http://www.cl.cam.ac.uk/users/djs1002/verilog.project/papers/combining_s ignals <http://www.cl.cam.ac.uk/users/djs1002/verilog.project/papers/combining_ signals> . ps.gz which hilights some other consequences of port collapsing such as allowing assignments to the "wrong" side of a directional port... I did the work while ignorant of port collapsing, which was brought to my attention by Michael McNamara (I think) It's a pretty old paper - a newer description is in my thesis, currently being examined... There's a similarly old paper about wires which is relevant to errata 48 if you're interested: http://www.cl.cam.ac.uk/users/djs1002/verilog.project/papers/combining_s ignals <http://www.cl.cam.ac.uk/users/djs1002/verilog.project/papers/combining_ signals> . ps.gz cheers Daryl > Shalom Bresticker wrote: > > > I have a question: > > > > 5.6.6 says that > > "Ports connect processes through implicit continuous assignment statements or implicit bidirectional connections ... > > Ports can always be represented as declared objects connected as follows: > > If an input port, then a continuous assignment from an outside expression to a local (input) net ..." > > > > Regarding strengths of continuous assignments, 6.1.4 says, at the end, > > "If drive strength is not specified, it shall default to (strong1, strong0)." > > > > If I put these two sections together, it implies that an input port will always be strong. > > > > However, we know and see that this is not so. > > That is, if I drive a net weakly and connect it to an input port of another module, > > that input port will also have a weak strength. > > > > I attach an example. > > > > Explanations ? > > --------------B580F83CAC864757FA0B55AE > Content-Type: text/plain; charset=us-ascii; > name="qq.v" > Content-Transfer-Encoding: 7bit > Content-Disposition: inline; > filename="qq.v" > > module qq ; > > wire rr ; > > assign (weak1, weak0) rr = 1'b1 ; > > pp pp (rr ) ; > > endmodule > > > module pp ( rr ) ; > input rr ; > > initial #10 $display ("%v", rr ) ; > > endmodule > > --------------B580F83CAC864757FA0B55AE-- > -- ************************************************************************ ** Shalom Bresticker Shalom.Bresticker@motorola.com Motorola Semiconductor Israel, Ltd. Tel #: +972 9 9522268 P.O.B. 2208, Herzlia 46120, ISRAEL Fax #: +972 9 9522890 ************************************************************************ ** --------------0DDBF433C9E57D255B67F3B0 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit <!doctype html public "-//w3c//dtd html 4.0 transitional//en"> Yes, port collapsing is obviously what really happens. It saves the simulator a lot of time and memory. My problem is that it seems to contradict what we wrote in 5.6.6,
I fear 5.6.6 is inconsistent with 12.3.10.
Thanks for the references.
Shalom
Daryl Stewart wrote:
The (antique) verilog LRM (Nov 91) has a section (12.4.6) explaining
I have a draft description of an analysis of port connections at
There's a similarly old paper about wires which is relevant to errata
cheers
> Shalom Bresticker wrote:
-- ************************************************************************** Shalom Bresticker Shalom.Bresticker@motorola.com Motorola Semiconductor Israel, Ltd. Tel #: +972 9 9522268 P.O.B. 2208, Herzlia 46120, ISRAEL Fax #: +972 9 9522890 ************************************************************************** --------------0DDBF433C9E57D255B67F3B0-- --------------5545FAE29C952F2B12BA2901 Received: from il06exr02.mot.com ([129.188.137.132]) by zil05exb01.sps.mot.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2654.52) id 4JWZ362Z; Mon, 15 Oct 2001 16:33:39 +0200 Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by il06exr02.mot.com (8.11.6/8.11.6) with ESMTP id f9FEXaj01507 for <Shalom.Bresticker@motorola.com>; Mon, 15 Oct 2001 09:33:36 -0500 Received: [from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id HAA07627 for <Shalom.Bresticker@motorola.com>; Mon, 15 Oct 2001 07:33:36 -0700 (MST)] Received: [from wisbech.cl.cam.ac.uk (mta1.cl.cam.ac.uk [128.232.0.15]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id HAA27771 for <Shalom.Bresticker@motorola.com>; Mon, 15 Oct 2001 07:33:18 -0700 (MST)] Received: from scoter.cl.cam.ac.uk ([128.232.0.69] helo=cl.cam.ac.uk ident=djs1002) by wisbech.cl.cam.ac.uk with esmtp (Exim 3.092 #1) id 15t8nt-0004qV-00; Mon, 15 Oct 2001 15:33:17 +0100 X-Mailer: exmh version 2.3+CL 01/14/2001 with version: MH 6.8.4 #17[UCI] To: Shalom Bresticker <Shalom.Bresticker@motorola.com> cc: Daryl Stewart <Daryl.Stewart@cl.cam.ac.uk>, <btf@boyd.com>, <Daryl.Stewart@cl.cam.ac.uk> Subject: Re: 1364: 5.6.6 Port connections In-reply-to: Your message of "Mon, 15 Oct 2001 16:19:08 +0200." <3BCAF05C.FADFC777@motorola.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 15 Oct 2001 15:33:17 +0100 From: Daryl Stewart <Daryl.Stewart@cl.cam.ac.uk> Message-Id: <E15t8nt-0004qV-00@wisbech.cl.cam.ac.uk> X-Mozilla-Status2: 00000000 I agree with your concerns. I agree that 5.6.6 is contradictory wrt 12.3.10 12.3.9.2 Rule 2 is also contradictory in its use of the mandatory "shall": "Each port connection shall be a continuous assignment of source to sink where one connected item shall be a signal source and the other shall be a signal sink. The assignment shall be a continuous assignment from source to sink for input or output ports." I had completely missed the line in 12.3.10! Perhaps a reference to it in 5.6.6? Notice also that if the continuous assignment description is fiddled about by errata 48 then it affects port connections because of the distinctions between net and driver delays it introduces... That's one of the reasons I did the work I mentioned before... cheers Daryl > > --------------0DDBF433C9E57D255B67F3B0 > Content-Type: text/plain; charset=us-ascii > Content-Transfer-Encoding: 7bit > > Yes, port collapsing is obviously what really happens. > It saves the simulator a lot of time and memory. > > My problem is that it seems to contradict what we wrote in 5.6.6, > which does not mention port collapsing. > Collapsing is still mentioned in 12.3.10, I see, which I have not read in detail. > > I fear 5.6.6 is inconsistent with 12.3.10. > > Thanks for the references. > I think I remember your old paper. I think I even read it, although I did not have > time to consider it in detail. > > Shalom > > > Daryl Stewart wrote: > > > I haven't done much work with wire strengths but I think the answer has > > something to do with "Port Collapsing". > > > > The (antique) verilog LRM (Nov 91) has a section (12.4.6) explaining that > > "Wherever it is possible, some tools collapse port connections during > > processing -- that is, the two items become one entity." > > This was omitted from IEEE standards for some reason, but is still observable. > > It would seem that in your example, since the port is a simple connection > > between two similar wires they can be collapsed to one, instead of being > > represented by a continuous assignment as the new standard claims. > > > > I have a draft description of an analysis of port connections at > > http://www.cl.cam.ac.uk/users/djs1002/verilog.project/papers/combining_signals. > > ps.gz > > which hilights some other consequences of port collapsing such as allowing > > assignments to the "wrong" side of a directional port... > > I did the work while ignorant of port collapsing, which was brought to my > > attention by Michael McNamara (I think) > > It's a pretty old paper - a newer description is in my thesis, currently being > > examined... > > > > There's a similarly old paper about wires which is relevant to errata 48 if > > you're interested: > > http://www.cl.cam.ac.uk/users/djs1002/verilog.project/papers/combining_signals. > > ps.gz > > > > cheers > > Daryl > > > > > Shalom Bresticker wrote: > > > > > > > I have a question: > > > > > > > > 5.6.6 says that > > > > "Ports connect processes through implicit continuous assignment statements or implicit bidirectional connections ... > > > > Ports can always be represented as declared objects connected as follows: > > > > If an input port, then a continuous assignment from an outside expression to a local (input) net ..." > > > > > > > > Regarding strengths of continuous assignments, 6.1.4 says, at the end, > > > > "If drive strength is not specified, it shall default to (strong1, strong0)." > > > > > > > > If I put these two sections together, it implies that an input port will always be strong. > > > > > > > > However, we know and see that this is not so. > > > > That is, if I drive a net weakly and connect it to an input port of another module, > > > > that input port will also have a weak strength. > > > > > > > > I attach an example. > > > > > > > > Explanations ? > > > > > > --------------B580F83CAC864757FA0B55AE > > > Content-Type: text/plain; charset=us-ascii; > > > name="qq.v" > > > Content-Transfer-Encoding: 7bit > > > Content-Disposition: inline; > > > filename="qq.v" > > > > > > module qq ; > > > > > > wire rr ; > > > > > > assign (weak1, weak0) rr = 1'b1 ; > > > > > > pp pp (rr ) ; > > > > > > endmodule > > > > > > > > > module pp ( rr ) ; > > > input rr ; > > > > > > initial #10 $display ("%v", rr ) ; > > > > > > endmodule > > > > > > --------------B580F83CAC864757FA0B55AE-- > > > > > -- > ************************************************************************** > Shalom Bresticker Shalom.Bresticker@motorola.com > Motorola Semiconductor Israel, Ltd. Tel #: +972 9 9522268 > P.O.B. 2208, Herzlia 46120, ISRAEL Fax #: +972 9 9522890 > ************************************************************************** > --------------5545FAE29C952F2B12BA2901 Received: from az33exr04.mot.com ([10.64.251.234]) by zil05exm01.sps.mot.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2654.52) id 4JW8K4TN; Mon, 15 Oct 2001 22:25:18 +0200 Received: from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by az33exr04.mot.com (8.11.6/8.11.6) with ESMTP id f9FKNBl24354 for <Shalom.Bresticker@motorola.com>; Mon, 15 Oct 2001 13:23:11 -0700 Received: [from motgate.mot.com (motgate.mot.com [129.188.136.100]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id NAA28353 for <Shalom.Bresticker@motorola.com>; Mon, 15 Oct 2001 13:25:16 -0700 (MST)] Received: [from mailgate2.Cadence.COM (mailgate2.Cadence.COM [158.140.2.31]) by motgate.mot.com (motgate 2.1) with ESMTP id NAA15821 for <Shalom.Bresticker@motorola.com>; Mon, 15 Oct 2001 13:25:16 -0700 (MST)] Received: from mailhub.Cadence.COM (mailhub.Cadence.COM [158.140.128.33]) by mailgate2.Cadence.COM (8.9.3/8.9.3) with ESMTP id NAA09835; Mon, 15 Oct 2001 13:25:14 -0700 (PDT) Received: from quicksand.Cadence.COM (quicksand [158.140.102.180]) by mailhub.Cadence.COM (8.10.1/8.8.5) with ESMTP id f9FKPDK19378; Mon, 15 Oct 2001 13:25:13 -0700 (PDT) Received: from quicksand (quicksand [158.140.102.180]) by quicksand.Cadence.COM (8.9.3+Sun/8.9.1) with SMTP id QAA25348; Mon, 15 Oct 2001 16:25:06 -0400 (EDT) Message-Id: <200110152025.QAA25348@quicksand.Cadence.COM> Date: Mon, 15 Oct 2001 16:25:06 -0400 (EDT) From: Steven Sharp <sharp@cadence.com> Reply-To: Steven Sharp <sharp@cadence.com> Subject: Re: 1364: 5.6.6 Port connections To: <btf@boyd.com>, Shalom Bresticker <Shalom.Bresticker@motorola.com> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: WFDFLtIp67OobRYrj8l94Q== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc X-Received: By mailgate2.Cadence.COM as NAA09835 at Mon Oct 15 13:25:14 2001 X-Mozilla-Status2: 00000000 Short answer: the standard is wrong. The 1995 standard was supposed to match XL, but does not describe port collapsing. Note that port collapsing is done at the discretion of the tool. Whether it is done is affected by too many complex and tool-specific factors to be specified in a standard. Perhaps this is why it was omitted. It would have been better to have specified that collapsing is allowed. The standard does make a sort of reference to collapsing. It states that if a port direction has been declared with a direction that does not match the actual direction, it may be coerced to inout. If it is not coerced, a warning must be issued. Coercing to inout is the effective result of port collapsing. This is actually a poor attempt to describe port collapsing. This is in section 12.3.6 in the 1995 standard. Steven Sharp sharp@cadence.com --------------5545FAE29C952F2B12BA2901-- |
Fix |
|
Audit-Trail |
State-Changed-From-To: open->closed State-Changed-By: admin State-Changed-When: Mon Aug 5 09:39:15 2002 State-Changed-Why: duplicated by 54 |
Unformatted |
|
Hosted by Boyd Technology