Chapter 8
AutoCode Sim Cdelay Scheduler
8-12
ni.com
These transition diagrams, together with the diagrams in Chapter 4,
Managing and Scheduling Applications
, of the
AutoCode User Guide
,
define the behavior of tasks under the Sim with Cdelay scheduler. They
encompass all of the changes to the default scheduler outside the scheduler
pipeline, and embody the new output posting, enable, and retriggering
policies. Together with the new pipeline configuration, these diagrams
provide you with enough information to completely implement the new
scheduler.
Implementing the Sim Cdelay AutoCode Scheduler
The new scheduler can largely be implemented as a new template. In the
new template, the large-scale layout of the scheduler is determined by the
new pipeline configuration, and the variable manipulations inside each
scheduler stage are determined by the STDs for the various task types.
Implementation Details
Some of the implementation details are as follows:
•
When a task attempts to write to a DataStore, the write must only be
allowed to go through if no task of higher priority has written to that
same location on the current scheduler cycle. In the default AutoCode
scheduler, this is enforced by ordering the posting of outputs to post
from least priority task first and the highest priority task last, thereby
obviating the need for active checks. With the new scheduler, however,
you have two separate output posting stages. As a result, it is necessary
to develop an active protection mechanism whereby the priority of a
writer to a DataStore register is stored, and later used in a guard. This
will be discussed in depth in the
•
The output posting policy for all periodic tasks changes from ANC to
ATR in the transition to the new scheduler. Thereby, the periods of
periodic tasks should be stored in the template parameter
OUTPUTCOUNT_LI
. In the default scheduler, this vector is zero except
for ATR triggered tasks. The timing requirements also can be obtained
from
SCHEDULINGCOUNT_LI
, as they are for the (ANC) periodic tasks
in the default scheduler, but this is not good design.
•
Under the new scheduler, free-running periodic tasks have a blocked
state used only during start-up so they can be initialized to have timer
values of zero without causing meaningless outputs to be posted.
Under the default scheduler, there is no blocked state for free-running
periodic tasks; thus, the template parameter
INITIALTASKSTATE_LS
must be altered.
