RE: [sv-ac] usage of .triggered on a sequence

Manisha,
 
For regular events (which also have a .triggered method) the situation is fairly clear: 
E.triggered becomes true (value 1'b1 of type bit) when the event is emitted, and becomes
false at the end of the timestep, that is, on exit from the Postponed region.  User code
has no access to that, so it is completely safe for user code (and PLI) to assume that
E.triggered remains true throughout the timeslot and is false at the beginning of the
next timeslot, whenever that next timeslot may be.
 
I would imagine that the behaviour of SEQ.triggered should be analogous.  Certainly,
I have written code that relies on such behaviour, and it *seems* to work :-)
 
Since <anything>.triggered is just an expression of type bit, there is presumably no 
difficulty in waiting for or testing its inverse.  The semantics of wait(!E.triggered) are 
a little bizarre,  though...  continue execution without delay if E.triggered is false, 
otherwise wait until simulation time advances...  

	Currently LRM only has examples where .triggered property is checked for its positive value. E.g.
	  wait (s0.triggered) or if (s0.triggered)
	 
	Is it allowed to check for the negative value of .triggered ? E.g.
	  wait (s0.triggered == 0) or  if (s0.triggered == 0)
	 
	It is clear in the LRM when the value of .triggered becomes 1 (in Observe region) but there is no clarity on when it becomes 0 (i.e. in which region ?).
	 
	If checking for value 0 is allowed, when should a wait statement should unblock ?

 
Regards
 
Jonathan Bromley
 

-- 
This message has been scanned for viruses and 
dangerous content by MailScanner <http://www.mailscanner.info/> , and is 
believed to be clean. 

-- This message has been scanned for viruses anddangerous content by MailScanner, and isbelieved to be clean.