Interesting.  It's been a long time since I've waded through the LRM,
but I assume that this works because i is a constant parameter, and
the alias expression is therefore static.

I'm curious, though: couldn't you have just said:
    alias ss: bit is s(i);
then
    wait on ss;
or am I missing something?

One other question: there's a section of the LRM that's always bothered
me, and I think it applies here.  In the note in 2.1.1, it states:

    Attributes of an actual are never passed into a subprogram:
    references to an attribute of a formal parameter are legal only if
    that formal has such an attribute, and such references retrieve
    the value of the attribute associated with the formal.

Would this preclude one from using, say, 'last_event in the above
example (assuming that the above is indeed legal)?  It seems to me
that you'd be getting 'last_event of the formal (whatever that is
defined as) rather than the actual signal.

All I've ever wanted to do was use s(i)'event or s(i)'active; I don't
mind waiting on the entire composite if I can find out which element
triggered the wait.  I've asked about it on here a number of times
over the years, but never really got a good answer (ie, one that I
could understand :-).
--
John A. Breen         | I teleported home one night with Ron & Sid & Meg.

                      |                            - Douglas Adams

: >I bet you have and some of you know how to do it:
: >
: >  procedure wait_on_element(signal s: bit_vector; i: integer) is
: >  alias ss: bit_vector(s'low - i + 10000 to s'high - i + 10000) is s;
: >  begin
: >          wait on ss(10000);
: >  end wait_on_element;
: >
: Interesting.  It's been a long time since I've waded through the LRM,
: but I assume that this works because i is a constant parameter, and
: the alias expression is therefore static.

: I'm curious, though: couldn't you have just said:
:     alias ss: bit is s(i);
: then
:     wait on ss;
: or am I missing something?

That should work just fine....

: One other question: there's a section of the LRM that's always bothered
: me, and I think it applies here.  In the note in 2.1.1, it states:

:     Attributes of an actual are never passed into a subprogram:
:     references to an attribute of a formal parameter are legal only if
:     that formal has such an attribute, and such references retrieve
:     the value of the attribute associated with the formal.

: Would this preclude one from using, say, 'last_event in the above
: example (assuming that the above is indeed legal)?  It seems to me
: that you'd be getting 'last_event of the formal (whatever that is
: defined as) rather than the actual signal.

This paragraph is meant to imply that formal parameters passed by value don't
also get the attributes of the actual.  However, signals are passed by
reference, so in effect the reference to the formal is substituted with a
reference to the actual, so it works....

--P

--

Menchini & Associates|                           |prove their worth by
2 Davis Dr./POB 13036|    voice: 919-990-9506    |hitting back."
RTP, NC  27709-3036  |    fax:   919-990-9507    |         -- Piet Hein

The actual parameter for `i' is a simple variable, you might have tried
to put the procedure call in a loop.

        This is illegal. The object being aliased must be static.

        This implies "user-defined", or else you wouldn't have been able
to use _any_ attributes of formal parameters.

        'last_event works fine as well. It is so nice to declare a big
RAM and to run a loop asking for 'last_event of each byte! :-)

        No problems with 'event or 'active either, as they're not signals.
Try it, you'll like it. :-)

        I wonder whether VHDL committee knows about such a backdoor in the
language. It looks like every effort has been made to prohibit waits
and implicits on non-static constructs.

        Leo