Subject: RE: [sv-ec] event variables
From: Mehdi Mohtashemi (Mehdi.Mohtashemi@synopsys.com)
Date: Fri Mar 14 2003 - 04:13:40 PST
Franciose,
Your concern about lost synchronization handles, processes blocking
is ofcourse valid, as it is also indicated in the proposal document, the
latest version numbered draft2. In any case care must be taken into
account how the new features are used in testbench and verification
environment, no matter what is used in advanced synchronization mechanism.
However, the new event notion really comes into play in the testbench
environment. As it is stated, the event is not a named lable [or static named
event] rather handles to synchronization 'queue' element, that can be passed
as arguements to methods. Here, the major usage is in the class heirarchy
and layers that involve methods[tasks] that use the new event construct for
further synchronization. For example, in addition to semaphore and mailbox
usage, parallel threads of, say, packet generators and [on the fly] packet
checkers will be able to pass these events as arguements for specific
and finer control hand-shaking mechansims. In this regard, dynamic
allocation and reclaiming is in line with the class/object usage model for
testbench [stimulus/check] in complex environment.
Incidentally, in your example, there will be a need to fork the while(1)
segment in the background, as well as another one for e1 triggering e2.
However, without the new systemverilog event element, it is more
prone to races, and in general will not give the exact semantics of the
merge usage via arguement passing.
- Mehdi
-----Original Message-----
From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org]On Behalf Of
Francoise Martinolle
Sent: Thursday, March 13, 2003 3:14 PM
To: sv-ec@eda.org
Subject: [sv-ec] event variables
I think that creating event variables and allow them to be assigned to other
event variables or even to null is very dangerous: assignments may cause
lost synchronization handles, process which blocks forever without a mean to
start them back up.
By creating event variables, we are changing the meaning of @( event)
In fact you would be waiting on a pointer to that event and you are allowed to
change what this pointer points to.
Allowing this sort of things will cause compiled code generation to not being
able to statically predict the sensitivity of a process waiting on an event
without
doing a deep analysis of the procedural code.
I don't understand the purpose of assigning events variables to another
event variable.
In Arturo's proposal section 12.8.2 (merging events) it seemed to me that the
goal was to create that when an event triggered, another one was
triggered by consequence. If this was the intent of creating these event
variables,
I think this can be coded in Verilog today very easily.
just write a process such as:
while(1) @e2 -> e1;
whenever e2 triggers, e1 triggers. Therefore all processes sensitive to
either e2 or e1
will be executed.
When you want to remove this event trigger sequence, just use a disable
statement on
the named process.
This is much simpler, and can be done in Verilog today.
The advantage is that:
1. we don't create a mix of events and pointers to events and refer
to them syntactically the same way,
2. we don't have process that block because of race condition between the
event
assignment and the process wait,
3. we don't have pointers in our implementation
Francoise
'
This archive was generated by hypermail 2b28 : Fri Mar 14 2003 - 04:13:20 PST