Re: connecting constant to inout port

From: Steven Sharp (sharp@cadence.com)
Date: Thu Oct 21 2004 - 12:46:49 PDT

  • Next message: Shalom.Bresticker@freescale.com: "Re: connecting constant to inout port"

    >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

    This archive was generated by hypermail 2.1.4 : Thu Oct 21 2004 - 12:36:51 PDT and
    sponsored by Boyd Technology, Inc.