Schema Execution Sequence

Each module's root schema is executed in a continuous loop by the module's firmware. A brief explanation of the processing sequence for the root schema iteration follows.

1) Hardware operators readings are cached at the start of each compute loop to provide consistent values to all operators during the execution.  This includes local and module scope variables. These values are the result of the previous schema execution.

2) For Chameleon, the backplane is sampled for an update to all input information required from other modules in the node. This read gathers global variables and network inputs.  

3) Schema execution starts in the root schema

4) Within a level of a schema, operators whose output is connected to an input on another operator are computed in order of dependency.  For example, if there is a chain of operators from left to right whose output goes to the input of the operator to its right, the operator to the far left will execute first and down the chain to the right. In Figure 6.1, the variable doubling, A, will always execute before the squaring, B.  

Figure 6.1. Dependency Based Execution

You may be inclined to view the execution order as left to right, and while sometimes that may be case because inputs tend to be on the left and outputs on the right, another way to think of the order is as a dependency tree.

 

Execution for a path within a schema begins at the base of the tree, and culminates at its top.  The display depends on B, which depends on A, which depends on AIn.  Therefore, the order of execution is AIn, A, B then display.  Each dependency tree is performed in its entirety on every compute cycle, so you need not be concerned with how many schema loop iterations it takes to propogate from input to output.

5) Operators / groups of operators that are not inter-dependent (i.e., they have no defined connections) will execute in an indeterminate order. Although the execution order is indeterminate, it remains fixed once the schema has been processed in Design Pad (i.e., the execution order will be the same at every cycle). The process is akin to a multi-threaded operating system that makes a computing device with a single processor appear like a parallel computing environment.  

6) Note: It is not guaranteed that all operators within a group of connected operators will all execute back to back.  This means that the compute order from groups of unconnected operators may interleave with one another (but as stated above it is guaranteed that a dependent operator connected to another's input will always compute before.)  

While A always precedes B, the execution order above could be A, E, F, B, G or E, F, G, A, B, C (or many other combinations) for the first execution cycle, but the execution order is always by dependent sequence and is always the same after the initial execution cycle.

7) Input/output pairs of variable operators with the same name and scope in the same schema create a virtual link that does affect order of execution.  This only applies to variables on the same schema 'level' (i.e. variables of same name/scope in different levels of sub-schemas or different Chameleon modules do not have this virtual link from an execution order standpoint).  When determining schema execution order, Design Pad views such virtually connected variables as though they were connected with actual wires in the schema.  Each of the wire segements in the above figures could be replaced with variables and the execution order would be unchanged no matter where or how they were placed within the schema page.

8) Function block sub-schemas are like any other operator where input/output connections will determine the order and an unconnected function block will execute in an indeterminate (but consistent) order.  When a function block is computed its execution starts at step #4 above and iterates down all branches of the sub-schema tree.  Note that the sub-schema will compute to conclusion (i.e. steps 1 to 9) before returning to running the higher level "calling" schema.  

9) Active states within state machine(s) within a particular level of schema are computed last.  Within a sub-schema in a particular active state, order of operation starts at step #4 and continues through #9 and recurses down any sub-schemas contained in the state's schema.  After all the state machines (within a particular level) are computed, then the transitions for the next compute loop are evaluated and the 'next' active states are set.  Note that it is not guaranteed that state machines will execute in the same order from one compute cycle to the next (again this is similar to a multi-threaded OS).  

10) For Chameleon nodes, an update to the backplane is written for all output information sent to other modules in the node.  

11) All updates to hardware outputs on the device/module are written (steps D and H above)