[sv-ec] Re: Scheduling cycle

Gordon Vreugdenhil wrote:

> I just chatted with some people here about the idea of the
> Reactive-NBA region that was discussed today.  This actually
> opens a chance to more deeply normalize behavior.  In particular,
> the hole that is presented by the example in 17.5 could likely
> be (mostly) filled without too much trouble.
> 
> Basic thoughts:
>   1) program nba's and cont assigns should be scheduled into
>      the Reactive NBA region (as discussed in the meeting)
>   2) a call to a non-program function or task should delay
>      the thread to the Reactive NBA region before AND after
>      the enable

Hmmm - an implication of this is that even "pure" routines
would end up being intermingled with reactive nba assignments.
This may be overly conservative in protecting against design
activity.  The only other thing that might break that "tie"
would be to make the reactive region truly a sub-system for
reactive-reactive scheduling only.  That would at least
isolate the "first order" effects of the impure assignments
from the "second order" effects of other dependent events.

Gord




>   3) program ports should likely have writes deferred via
>      a conceptual cont assign (and thus fall into case 1)
> 
> 
> The problem with the current scheduling of non-program tasks
> and functions is that observability is compromised and, given
> the overall cycle, other non-program events, nbas, etc. can
> "sneak in" between program-program deltas.
> 
> If such calls are always delayed, you get clean program-program
> event semantics and better observability.  The "cost" is the
> unconditional "reactive" delta.  For functions and tasks that
> don't have side-effects, there should be no change in behavior from
> what would currently happen.  For impure routines, program
> code is guaranteed to reach "semi-stability" before any design
> activity occurs.  Design activity is likely also more consistent since
> all pending activity happens as the same time.  A further note on
> this is that all scheduling decisions remain static so there
> shouldn't be any serious implementation issues for anyone; we do
> end up with some additional reactive deltas but I think that the
> stronger stability guarantees warrant the cost.
> 
> Anyway, please give this some thought.
> 
> Gord.

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