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

One additional thought on all of this -- any changes in the
scheduling algorithm should be intentional about the resolution
of implicit and explicit design variable updates.  In particular,
if we have an update to a design variable by way of a call
to a function with a side-effect AND have an NBA update to the
same design variable, we need to be sure that we're Ok with
which write wins.  In the "Approach II" algorithm, we
guarantee that the NBA from the program to the design will
occur before any design process that may have been activated
from a side-effect function call.  In Approach I and in the
current algorithm, the side-effect will propagate through
the design before the program NBA is processed.

I can argue on both sides of what might be considered correct
on this although I prefer the consistency of the Approach II
algorithm.  I do think we need to be sure to consider such
issues as we proceed.

Gord.


Vreugdenhil, Gordon wrote:
> 
> Arturo,
> 
> Sorry about that -- I was having a side discussion in
> my office during part of the call and didn't realize
> that you had discussed exactly this situation.
> 
> Well, at least we're all on the same page and have
> the case in writing for those that weren't there.
> 
> 
> I'm not sure how to fix this case without doing the double
> loop as in the algorithm that I wrote up based on
> the discussion.  Have you been able to come up with
> any other alternatives?
> 
> Gord.
> 
> 
> -----Original Message-----
> From: Arturo Salz [mailto:Arturo.Salz@synopsys.com]
> Sent: Sat 4/30/2005 3:09 PM
> To: Vreugdenhil, Gordon; SV_EC List
> Subject: 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
> 
> 

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