ISSUE 54

Number 54
Category errata
Synopsis 5.6.6 Port connections - inaccurate description
State open
Class errata-discuss
Arrival-Date Tue Oct 16 08:50:01 PDT 2001
Originator Shalom.Bresticker@motorola.com
Release 2001b, 5.6.6, 12.3.9.2, 12.3.8
Environment

Description
Date: Mon, 15 Oct 2001 15:50:58 +0200
From: Shalom Bresticker

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 ?


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



Date: Mon, 15 Oct 2001 15:12:32 +0100
From: Daryl Stewart

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



Date: Mon, 15 Oct 2001 16:19:08 +0200
From: Shalom Bresticker
Organization: Motorola Semiconductor Israel, Ltd. (MSIL)

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.


Date: Mon, 15 Oct 2001 15:33:17 +0100
From: Daryl Stewart

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






Date: Mon, 15 Oct 2001 16:25:06 -0400 (EDT)
From: Steven Sharp

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.



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


Fix
No detailed solution yet proposed.
The DB contains all discussion to date.
Audit-Trail

From: "Brad Pierce"
To:
Cc:
Subject: Re: errata/54: 5.6.6 Port connections - inaccurate description
Date: Tue, 26 Nov 2002 14:05:26 -0800

In the last sentence of its first paragraph, section 5.6.6 says --

"Port connection rules require that a value receiver be
a net or a structural net expression."

Are there structural net expressions that are not nets? If not,
we should remove "a net or" here.

According to section 12.3.8,

"Examination of the port connection rules described in 12.3.9
will show that the item receiving the value through the port
(the internal item for inputs, the external item for outputs)
shall be a structural net expression."

No "a net or".

Is it also true that the external item for inouts shall be a
structural net expression? If so, the above parenthetical remark
in 12.3.8 should be modified to

"(the internal item for inputs, the external item for outputs
and inouts)"

-- Brad



From: Steven Sharp
To: etf-bugs@boyd.com, Brad.Pierce@synopsys.com
Cc:
Subject: Re: errata/54: 5.6.6 Port connections - inaccurate description
Date: Tue, 26 Nov 2002 18:51:51 -0500 (EST)

> In the last sentence of its first paragraph, section 5.6.6 says --
>
> "Port connection rules require that a value receiver be
> a net or a structural net expression."
>
> Are there structural net expressions that are not nets? If not,
> we should remove "a net or" here.

I assume that "structural net expressions" refers to nets, constant-index
bit-selects and part-selects of nets, and concatenations of structural net
expressions. So you could remove "a net or", unless one assumes that a
simple net identifier isn't an expression.

> According to section 12.3.8,
>
> "Examination of the port connection rules described in 12.3.9
> will show that the item receiving the value through the port
> (the internal item for inputs, the external item for outputs)
> shall be a structural net expression."
>
> No "a net or".
>
> Is it also true that the external item for inouts shall be a
> structural net expression? If so, the above parenthetical remark
> in 12.3.8 should be modified to
>
> "(the internal item for inputs, the external item for outputs
> and inouts)"

Both the internal and external items for inouts should be structural
net expressions.

Steven Sharp
sharp@cadence.com


From: "Brad Pierce"
To:
Cc:
Subject: Re: errata/54: 5.6.6 Port connections - inaccurate description
Date: Tue, 26 Nov 2002 18:39:14 -0800

In the note at the end of section 12.3.8, the LRM says --

"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 has to be issued."

And after issuing the warning, then what? Unless it's intended
that the message be a fatal error, something more must still
happen. What is the correct behavior if the port is not coerced
to inout?

Moreover, contrary to the note, directions are not really declared
on ports, but instead are declared on the port identifiers within
port expressions. If the port expression is a concatenation, but
the port identifiers within it are declared with mixed directions,
such as half input and half output, what is the direction of the
port?

module m (.p({a,b})) ;
input a;
output b;
not(b,a);
endmodule

To me, it seems like either p is being declared here as an inout
(no coercion involved) or this is an error.

Yet I don't see any place in the standard that speaks to this.
And the function acc_fetch_direction() would return "accMixedIo"
for port p. According to Table 139, there are four kinds of
port direction --

Input only
Output only
Bidirectional (input and output)
A concatenation of input ports and output ports

But I don't see this fourth kind of port direction mentioned
anywhere else in the LRM.

-- Brad



From: Shalom Bresticker
To: etf-bugs@boyd.com
Cc:
Subject: Re: errata/54: 5.6.6 Port connections - inaccurate description
Date: Wed, 27 Nov 2002 08:46:47 +0200

12.3.9.2 says,

"A structural net expression is a port expression whose operands can be the
following:
A scalar net
A vector net
A constant bit-select of a vector net
A part-select of a vector net
A concatenation of structural net expressions"

so "net" is included in "structural net expression".

After we figure out what to do about these problematic "implicit continuous
assignments",
I think 5.6.6 should just refer to 12.3.8-10.

Shalom

> > In the last sentence of its first paragraph, section 5.6.6 says --
> >
> > "Port connection rules require that a value receiver be
> > a net or a structural net expression."
> >
> > Are there structural net expressions that are not nets? If not,
> > we should remove "a net or" here.
>
> I assume that "structural net expressions" refers to nets, constant-index
> bit-selects and part-selects of nets, and concatenations of structural net
> expressions. So you could remove "a net or", unless one assumes that a
> simple net identifier isn't an expression.
>
> > According to section 12.3.8,
> >
> > "Examination of the port connection rules described in 12.3.9
> > will show that the item receiving the value through the port
> > (the internal item for inputs, the external item for outputs)
> > shall be a structural net expression."
> >
> > No "a net or".
> >
> > Is it also true that the external item for inouts shall be a
> > structural net expression? If so, the above parenthetical remark
> > in 12.3.8 should be modified to
> >
> > "(the internal item for inputs, the external item for outputs
> > and inouts)"
>
> Both the internal and external items for inouts should be structural
> net expressions.
>
> Steven Sharp
> sharp@cadence.com
>

--
Shalom Bresticker Shalom.Bresticker@motorola.com
Design & Reuse Methodology Tel: +972 9 9522268
Motorola Semiconductor Israel, Ltd. Fax: +972 9 9522890
POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 441478

"The devil is in the details."




From: Shalom Bresticker
To: etf-bugs@boyd.com
Cc:
Subject: Re: errata/54: 5.6.6 Port connections - inaccurate description
Date: Wed, 27 Nov 2002 08:48:57 +0200

Also see issue #198.

Hosted by Boyd Technology