Re: connecting constant to inout port

From: Shalom.Bresticker@freescale.com
Date: Thu Oct 21 2004 - 13:44:56 PDT

  • Next message: Shalom.Bresticker@freescale.com: "Re: enhancement/547: define size zero replication constant"

    Actually, I agree, which is why I said that I am not proposing any actual
    change.

    Thanks,
    Shalom

    On Thu, 21 Oct 2004, Steven Sharp wrote:

    >
    > >Strictly, according to the LRM, it is indeed illegal.
    > >Should it be?
    > >
    > >I'm not proposing we actually change the standard on this point,
    > >but I'd like to hear a theoretical answer.
    >
    > I suppose it depends on what theory you use :-)
    >
    > 12.3.9.2 essentially states that output and inout ports of modules can
    > only be connected to structural net expressions (though it spells out
    > the restrictions instead of just reusing that term).
    >
    > The theory is presumably that an inout port is an input port *and* an
    > output port, so it must satisfy the restrictions on both. If you have
    > indicated that you want the port to be able to drive the thing you
    > have connected, then you better connect something that can be driven.
    >
    > The section also says that a connection to an inout port is equivalent
    > to a nonstrength reducing transistor connection. A bidirectional tran
    > primitive does not allow constants to be connected to the terminals.
    > In practice, I don't know that this treatment as a tran is actually
    > used by any implementation. It is actually a roundabout way of trying
    > to describe the behavior of a collapsed port, which is presumably how
    > everyone really implements inout ports. And port collapsing is only
    > possible with nets on both sides. So the two ways that an implementation
    > is allowed to treat an inout port both require a structural net expression.
    >
    > Now you can argue that with real hardware, you can tie an inout port
    > to a supply as long as you never actually drive it. But you can make
    > the same argument for an output port (though clearly it wouldn't be as
    > useful). And there are inevitably differences between the real world
    > and the models for it. For example, a constant and a supply net do
    > not behave the same way in the language, even if you think of them
    > as being the same thing in hardware.
    >
    > If you relaxed the rules on inout ports to allow anything that is legal
    > on an input *or* output port, then you would get into other problems.
    > A constant may be fine, since you can't access its value to see whether
    > it got driven from inside. But what about a reg? If you allow a reg
    > to be connected and treat it like an input port connection, then the
    > reg won't be affected by any value driven from inside, even though you
    > declared the port as inout. It would behave completely unlike real
    > hardware, and could easily result in a serious bug.
    >
    > If you wanted to avoid that, you would have to invent a new set of
    > restrictions for inout ports. They would have to be based on what you
    > thought users would "expect", which could vary from user to user. You
    > really want to prevent anything that they might expect to behave like
    > an inout port but doesn't, while allowing anything they expect to behave
    > like an input port. I think the existing simpler and more conservative
    > rule is safer.
    >
    > Steven Sharp
    > sharp@cadence.com
    > 

    -- 
Shalom Bresticker                        Shalom.Bresticker @freescale.com
Design & Verification Methodology                    Tel: +972 9  9522268
Freescale Semiconductor Israel, Ltd.                 Fax: +972 9  9522890
POB 2208, Herzlia 46120, ISRAEL                     Cell: +972 50 5441478
  
[ ]Freescale Internal Use Only      [ ]Freescale Confidential Proprietary

    This archive was generated by hypermail 2.1.4 : Thu Oct 21 2004 - 13:34:41 PDT and
    sponsored by Boyd Technology, Inc.