From: Daryl Stewart (Daryl.Stewart@cl.cam.ac.uk)
Date: Mon Oct 15 2001 - 07:33:17 PDT
Precedence: bulk
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
> **************************************************************************
>
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:54:47 PDT
and
sponsored by Boyd Technology, Inc.