Re: [sv-ec] wait_order

From: Steven Sharp <sharp_at_.....>
Date: Sat Sep 08 2007 - 06:55:23 PDT
>From: "danielm" <danielm@aldec.com.pl>

>After reading LRM "14.6. Event sequencing: wait_order()." I'm not sure if
>events listed in wait_order should be triggered in different time slots,
>different slot regions, or it is enough to trigger them in single region in
>propoer order to unblock wait_order stmt? Below I'm attaching an example
>describing my doubts. Any answers will be appreciated.
> 
>Asume wait order like in below code:
>    initial wait_order (a,b,c);
> 
>Which from below initial process will cause that above wait order will pass.

I would expect that enough time must pass between them for the waiting
process to wake up and adjust its state.  In other words, if 

	initial @a @b @c ;
	
is not guaranteed to complete, then I would not expect wait_order to
be guaranteed to complete successfully either.  Based on this assumption,
my answers to your examples are as follows:

>a)
>    initial begin
>    #1;
>     ->a;
>     ->b;
>     ->c;
>    end

This would not be guaranteed to complete.  In fact, since implementations
typically continue executing a process until it suspends itself, I would
expect this to fail reliably in most implementations.  All 3 events would
occur before the wait_order responded to the first one.

>b)
>    initial begin
>    #1;
>     ->a;
>    end
>   always @a ->b;
>   always @b -> c;

This would not be guaranteed to complete.  I would expect the behavior
to vary greatly between implementations, since there is a race between
the always blocks and the wait_order responding.

>c)
>    initial begin
>    #1;
>     ->a;
>     #0 ->b;
>     ->>c;
>end

This would be guaranteed to complete.  Both the #0 and the nonblocking
trigger guarantee that the wait_order will execute before the next
event occurs.

>d)
>    initial begin
>     #1 ->a;
>     #1 ->b;
>     #1 ->c;
>    end

This would be guaranteed to complete, of course.

Steven Sharp
sharp@cadence.com


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Sat Sep 8 07:58:32 2007

This archive was generated by hypermail 2.1.8 : Sat Sep 08 2007 - 07:58:47 PDT