Hi Arpad, Q'ABOVE(E) is an implicit boolean signal. The wait is waiting on this signal to change and it is only sensitive to this signal. As you described it, there would be an event on this signal going from false to true. because Q is 0 and E goes from 1 to -1. The LRM defines it: Q'ABOVE(E) Kind: Signal. Prefix: Any scalar quantity denoted by the static name Q. Parameter: An expression of the same type as Q. Any quantity appearing in the expression must be denoted by a static name. Result Type: Type BOOLEAN. Result: TRUE if Q - E is sufficiently larger than 0.0, FALSE if Q - E is sufficiently smaller than 0.0, Q'ABOVE(E)'DELAYED otherwise. I believe the Result definition is meant to imply that if Q - E is not sufficiently different from 0, the signal does not change value. There is no event. Hope that helps. Regards, John Muranyi, Arpad wrote: > Hello Everyone, > > Sorry if this forum in not the right place to ask this question, but I > am not > sure where else I could ask it. Does the LRM specify how simulators > should > handle the following wait statement: > > TestAbove : process is > begin > Count <= Count + 1; > wait on SomeRealQuantity'above(SomeRealSignal); > end process TestAbove; > > when there is another process that can change the value of > SomeRealSignal? > > For example, let's assume that when this process stops on the wait > statement, > the value of SomeRealSignal is 1.0 and the value of SomeRealQuantity is > 0.0, > therefore the 'above returns a FALSE. For simplicity, let's also assume > that > the quantity SomeRealQuantity is not changing. Some time later another > process decides to change the value of SomeRealSignal to -1.0. Is this > change supposed to cause the 'above statement change to TRUE and get the > waiting process out of wait, or should it remain false until the > quantity > goes below and above the signal's new value? In other words, is the > 'above > attribute supposed to act on both its argument and quantity in "real > time", > or only on the quantity? > > If you haven't guessed it yet, the reason I am asking this is because > two > different vendor's tools give me different results because of this. > > Thanks, > > Arpad > ======================================================================== > == > >Received on Thu Aug 24 16:30:53 2006
This archive was generated by hypermail 2.1.8 : Thu Aug 24 2006 - 16:31:07 PDT