ISSUE 52

Number 52
Category errata
Synopsis : 5.6.6 Port connections
State closed
Class duplicate
Arrival-DateOct 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:
<blockquote TYPE=CITE>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--

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

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:
<blockquote TYPE=CITE>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

<a href="http://www.cl.cam.ac.uk/users/djs1002/verilog.project/papers/combining_signals">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:

<a href="http://www.cl.cam.ac.uk/users/djs1002/verilog.project/papers/combining_signals">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--


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