Subject: RE: [sv-ec] event variables
From: Francoise Martinolle (fm@cadence.com)
Date: Fri Mar 14 2003 - 09:36:21 PST
Mehdi,
thanks for the background information on the use of these new events in
classes.
I still think it is a mistake to NOT differentiate them syntactically from
regular
Verilog events.
If these new events are really handles to synchronization queue elements, then
they should be declared as such.
example:
handle event e1;
handle event e2;
now the assignment e1 = e2 is more obvious on what is being done.
I also simplifies the task for the systemVerilog compiler in determining
whether or not
you are waiting on a static event or a handle to syncrhonization queue.
It is also clear for the user that these are pointers and he must be
careful about not leaving
them dangling.
If I rewrite one of the examples:
the task in the class can wait on a synchronization handle,
while the always block in the module waits on the named event e.
Because we syntactically differentiate between named events and handles to
event, it will be
easier for the SV compiler generate code.
class foo;
handle event b = null; // this does not create an event but a pointer
to a synchronization queue.
this pointer is initialized to null
function new( ref event _b ); b = _b; endfunction // this function
assigns the event handle of the class
foo
to the synchronization handle passed by
reference.
task waitonevent (ref event _b) // this task waits on the event pointed
to by the handle to occur
@_b;
$display ("success");
endtask
endclass;
module m
typedef handle class foo foo_p; // a handle type to a class;
foo_p fooc1;
event e;
initial
fooc1 = new (ref e); //create an instance of class foo and pass a handle to
event e.
endinitial
always @e //This always waits on event e
endalways
2. Example on page 2 would be rewritten as:
event done;
handle event done_too = new(done); // initialize the "done_too"handle to a
handle to the named event "done".
task trigger( event ev );
-> ev;
endtask
...
fork
@ done_too; // wait for done through done_too, implicit dereferencing of
done_too
#1 trigger( done ); // trigger done through task trigger
join
When handle to events are assigned the NULL value, they can be reclaimed by SV.
Francoise
'
At 04:13 AM 3/14/2003 -0800, Mehdi Mohtashemi wrote:
>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 - 09:38:01 PST