🚀 go-pugleaf

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