From: Shalom Bresticker (Shalom.Bresticker@motorola.com)
Date: Mon Oct 15 2001 - 07:19:08 PDT
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
<p>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.