Re: [sv-ec] Scheduling example (surprising semantics)

Gord,

I agree. This is consistent with the conversation that took place
during the meeting. In fact, the example I described during the
meeting to outline the issue to a question asked by Francoise
was remarkably similar to the code segment you wrote.

Our challenge, I believe, is to capture this intent with very minor 
fixes to the existing algorithm while ensuring complete backward 
compatibility. A simple explanation to detail why the changes are
needed will also be extremely helpful.

    Arturo

----- Original Message ----- 
From: "Gordon Vreugdenhil" <gordonv@Model.com>
To: "SV_EC List" <sv-ec@eda.org>
Sent: Saturday, April 30, 2005 10:06 AM
Subject: [sv-ec] Scheduling example (surprising semantics)




In thinking about Friday's meeting, I am becoming more
convinced that one of the new scheduling variants really
is needed.

One of Phil's comments was that an important aspect
of "program" syntax is that module based testbench
code should mostly "just work" in programs.  With
the current scheduling, I think that we are pretty
far from that.

Consider the following:

program thread 1:
    a = 5;     // "a" is a program variable
    b <= 6;    // "b" is a var port to the design
    #0;


program thread 2:
    ...
    @(a) c = b;


If these are module threads, the event on "a" would
activate thread 2.  The #0 would move thread 1 to
the inactive queue.  Thread 2 would activate
and see the old value of b, not the new value (6).

Now, if these are program threads, we would end up
with the change on "b" becoming visible to thread
2 since the event on "a" schedules thread 2 into
the reactive region which won't become active again
until *after* all of the pending NBAs run.

This would be very surprising to users I suspect and
does not involve and of the problematic calls to
design tasks or functions.  Approach I does resolve
this aspect of the issue, but not the next.


Pushing this just a bit further, if we ignore the
state of "b", things are still very surprising.

The #0 on program thread 1 is currently defined to
move the thread onto the inactive queue.  Since
thread 2 gets scheduled onto the reactive queue
after the event "a", the #0 is truly a no-op since
thread 1 is guaranteed to re-activate before
thread 2 moves from reactive to active.  In
fact, the entire interaction between #0 and
program thread events is currently defined to be
completely different than normal module thread
behavior.


Given the relatively simple nature of this situation
and the fairly surprising semantics, I think that
I am definitely leaning towards the fully general
Approach II.  With that approach, I think that the
only odd scenarios involve calls from a program
thread to an impure or blocking module task or
function.  That is a known hole that I don't think
we can easily fill.


Gord.

-- 
--------------------------------------------------------------------
Gordon Vreugdenhil,  Staff Engineer               503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com