jab0396@cec2.wustl.edu (John A. Breen) (04/15/91)
I've just started using ports of mode BUFFER in a model, and there are
a few things that aren't making sense. Consider the following
architecture:
Architecture A1 of E1 Is
Signal s1: Bit_Vector(1 to 2);
Component Driver
Port(b1, b2: Buffer Bit);
End Component;
Begin
D1: Driver
Port Map(s1(1), s1(2));
End A1;
Is this model legal? When I analyze it (using Vantage), it complains
that s1 has more than one source, apparently counting the two ports as
separate sources of s1 as a whole (and an actual of a Buffer port may have
at most one source). LRM Sec. 4.3.1.2 indicates that, for a resolved
signal at least, the two ports would "together constitute one source of
the signal." What is the rule for unresolved signals (note that, if
the two ports do constitute one source, there is no need for s1 to be
resolved, since there are no other sources).
While we're on the subject, why can't actuals of buffer ports have
more than one source (and please don't say "Because!")? I had
previously assumed that a buffer port would act as, well, a buffer,
isolating the signal value inside the component from the effects of
external drivers (as opposed to an INOUT port, where the internal value
would be the same as the effective external value). Given that the
actual only has one source, how does a BUFFER port differ from an
INOUT port?
-----
John A. Breen | johnb@hobbes.mdc.com
McDonnell Douglas Missile Systems Co. | jab0396@cec1.wustl.edu (forwarded ^)
Tel: (314)234-4341ward@rtpark.rtp.semi.harris.com (04/17/91)
Posted for Paul Menchini. Please reply to addresses below. ================================================================================ Regarding John Breen's (johnb@hobbes.mdc.com) posting <1991Apr15.152209.29446@cec1.wustl.edu> to COMP.LANG.VHDL, > Architecture A1 of E1 Is > Signal s1: Bit_Vector(1 to 2); > > Component Driver > Port(b1, b2: Buffer Bit); > End Component; > Begin > D1: Driver > Port Map(s1(1), s1(2)); > End A1; > Is this model legal? When I analyze it (using Vantage), it complains > that s1 has more than one source, apparently counting the two ports as > separate sources of s1 as a whole (and an actual of a Buffer port may have > at most one source). LRM Sec. 4.3.1.2 indicates that, for a resolved > signal at least, the two ports would "together constitute one source of > the signal." What is the rule for unresolved signals (note that, if > the two ports do constitute one source, there is no need for s1 to be > resolved, since there are no other sources). Yes it is. The two ports constitute one source not because the signal is (or is not) resolved, but because each element is driven by a different port. > While we're on the subject, why can't actuals of buffer ports have > more than one source (and please don't say "Because!")? I had > previously assumed that a buffer port would act as, well, a buffer, > isolating the signal value inside the component from the effects of > external drivers (as opposed to an INOUT port, where the internal value > would be the same as the effective external value). Given that the > actual only has one source, how does a BUFFER port differ from an > INOUT port? Because (sorry, but I couldn't resist) buffer ports are allowed to be read as well as written AND you're guaranteed that the value you read (i.e., the effective value of the associated signal) is the same as the value you've driven (i.e., the driving value). The only way to guarantee this is to ensure that the signal have but one source. If the actual has but one source, then a buffer port associated with the actual has semantics that differ in no way from the semantics of an inout port associated with the same actual. It's just that the buffer GUARANTEES the single-source condition even if the actual is a resolved signal. (Rumor has it that buffer ports were originally included to model TTL open- collector devices.) A common use for buffer ports is to model inverting and non-inverting outputs of a device. If Q is a buffer port, then QB <= not Q; is a convenient way of having the inverting output track the non-inverting output. Note that this method is illegal if Q is an out port and clearly dangerous if Q is an inout. I hope that you're aware that VHDL is up for restandardization (to be completed by the end of 1992)--otherwise we (the restandardization committee) haven't been doing our jobs. During this restandardization we are considering a number of language modifications. One of these is a way to access the current value of a driver for a signal. If this mechanism is provided, then another way to provide an inverting output that tracks a non-inverting output is by QB <= <driving value of> Q; the intent is to allow this access even to output ports. Note that this mechanism implies a buffer MUST be inserted if the description is synthesized--the use of a buffer port doesn't. --Paul J. Menchini Corporate Strategic Staff CAD Language Systems, Inc. Internet: mench@clsi.com mench%clsi.com@uunet.uu.net (if "mench@clsi.com" doesn't work) menchin@elmo.el.wpafb.af.mil uucp: ...!uunet!clsi!mench US Mail: CAD Language Systems, Inc. P.O. Box 13036 Research Triangle Park, NC 27709-3036 USA Voice: +1 919-361-1913 FAX: +1 919-361-2642 "If an undetectable error occurs, the processor continues as if no error had occurred." -- IBM S/360 Principles of Operation "The base type of a type mark is, by definition, the base type of the type or subtype denoted by the type mark." -- IEEE Std. 1076-1987
jab0396@cec1.wustl.edu (John A. Breen) (04/20/91)
In article <1991Apr17.093251.500@rtpark.rtp.semi.harris.com> ward@rtpark.rtp.semi.harris.com writes: >Posted for Paul Menchini. Please reply to addresses below. [I'm forwarding a copy of this to Mr. Menchini, but I didn't want to break the News thread]. >[T]he [buffer] signal [must] have but one source. > >(Rumor has it that buffer ports were originally included to model TTL open- >collector devices.) Unfortunately, I don't see how buffer ports help here. The main reason for having open collector devices is so that you can tie multiple sources together. However, buffer ports won't let you do this. > >Internet: mench@clsi.com > mench%clsi.com@uunet.uu.net (if "mench@clsi.com" doesn't work) > menchin@elmo.el.wpafb.af.mil >uucp: ...!uunet!clsi!mench ----- John A. Breen | johnb@hobbes.mdc.com McDonnell Douglas Missile Systems Co. | jab0396@cec1.wustl.edu (forwarded ^) Tel: (314)234-4341