Re: [sv-ec] event variables


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