Subject: Re: [sv-ec] event variables
From: Arturo Salz (Arturo.Salz@synopsys.com)
Date: Fri Mar 14 2003 - 10:52:57 PST
Francoise,
My comments in blue.
Arturo
----- Original Message -----
From: Francoise Martinolle
To: Mehdi Mohtashemi ; sv-ec@eda.org
Sent: Friday, March 14, 2003 9:36 AM
Subject: RE: [sv-ec] event variables
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.
Yes. easier for the compiler, but more difficult for the users.
It is also clear for the user that these are pointers and he must be careful about not leaving
them dangling.
No. They are not pointers. They are references to queues. The distinction is that they do
not need to be dereferenced or their address taken.
Also, yur proposal would imply that I can no longer do:
event e;
handle event pe = e; // or ref e (if Jay gets his way).
Since even this simple assignment, the sensitivity list of pe can become dynanic.
But, you need to look no further than the following example to create a dynamic
sensitivity list.
event ev;
task goo( int k );
repeat( k )
fork
@ ev;
join_none
endtask
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 - 10:52:14 PST