Chapter 8
AutoCode Sim Cdelay Scheduler
©
National Instruments Corporation
8-7
queue tasks stage for that scheduler invocation has already passed; thus, the
triggered task cannot be queued for execution until 0.7 sec. At the time that
it is queued, it sets its time delay for 0.1 sec. Thus, its output is not posted
until the next
scheduler invocation. In total, two scheduler ticks have thus
passed before the triggered task’s outputs have been posted.
The case of the enabled task is slightly more complicated. In this case, you
care not only about the scheduler pipeline itself but also about the output
posting policy of the task in question. Enabled tasks under the default
AutoCode scheduler are assigned a post on next computation output
paradigm. Now consider the output in Figure 8-1 for the enabled task;
the enable input rises at 0.6 sec. As this corresponds to the post outputs
stage of a scheduler invocation, the queue tasks stage has already occurred.
Therefore, you must wait until 0.7 sec, when you enter the next scheduler
invocation, for the enabled task to be queued for execution.
Now you must bring into play the fact that enabled periodic tasks are
ANC in the default scheduler; results of an invocation of an enabled task
are only posted on the next invocation of that task. At the end of the 0.7 sec
scheduler invocation, the enable input goes low, which means that the
enabled task is not enabled for the 0.8 sec scheduler invocation. Thus, the
task is not invoked again, and it posts no output; however, its enable input
does go high at the
end of this cycle. Finally, at the 0.9 sec scheduler
invocation, the enabled task is invoked again and the cached result from the
last computation is posted. The total observed delay for the enabled task,
from enable going high to output being posted, is thus three scheduler ticks.
In the case of this and the preceding analysis, it might benefit you to refer
to the state transition diagrams (default scheduler) for each type of task in
Chapter 4,
Managing and Scheduling Applications
, of the
AutoCode User
Guide
.
Managing DataStores in the Scheduler
Notice that DataStores in a model do not translate into tasks—they are
handled separately by the scheduler during the output posting phase of the
scheduler pipeline. As there could be multiple attempts to write into a
DataStore during a single scheduler invocation, a constraint that must
always be observed is that a task can write into a DataStore on a particular
scheduler cycle if and only if no task of higher priority has already written
to it. In the default scheduler, this is trivially enforced by ordering the firing
of tasks in the (single) output posting stage so that lower priority tasks fire
first, but the same constraint will become of key importance (and a
potential stumbling point) when it comes time to implement the new
scheduler.
