WARNING: THIS PAGE IS CURRENTLY UNDER CONSTRUCTION. THE CONTENT MIGHT CHANGE EVERY FEW MINUTES!

The Priority-Based Compilation

The priority-based low-level compilation approach uses the established compiling chain for SCCharts until the dependency analysis of the SCG is finished. From this point, either the netlist low-level compilation approach or the priority-based low-level compilation approach can be used. Because of the different approaches, it is possible, that one of the compiler finds a valid schedule for an SCChart, while the other fails.

...

The Priority-Based Compilation

The priority-based low-level compilation approach compiles an SCG enriched by the results of uses the established compiling chain for SCCharts until the dependency analysis to SCL_P, whose basis is the programming language C and which is enriched by the SCL_P macros. Therefore the regions of the SCG are fragmented into threads, whose priority determines the order in which the threads are executed. A thread might change its priority, which results in a context switch. The adiministration of the threads is done by the SCL_P macros. As the calculation of the thread priorities is not trivial, it done stepwise, which should help the user to understand how it is done. This is provided by a KiCo compilation chain, which can be called from the SCCharts editor or from the SCG editor.The image below shows the compilation chain as shown by the SCChart editor:

Image Removed

The target language SCL_P:

SCL_P is a leaner variant of Synchronous C. It also provides a deterministic thread administration for C which is implemented as macros. As the grammar of an SCG is simpler, less macros are required than for Synchronous C. The macros provided to a programmer are shown below.

Each thread is identified by a unique prioID, which acts as identifier and as priority for the scheduling. The prioID can be changed, e.g. if a thread waits for a result from another thread. The threads are scheduled in descending order of their corresponding prioID. SCL_P uses cooperative scheduling.

tickstart(p)

forkn(label1, p1, ...,  labeln, pn)

par

joinn(p1, ...)

prio(p)

pause

tickreturn()

Requirements for a translation to SCL_P:

• Each thread needs at least one unique prioID.
• The first child inherits the prioID of the parent thread
• The parent threads inherits the prioID of the thread, which performs the join afterwards.
• The thread whose exit node has the lowest prioID has to perform the join.
• The thread, which should perform the join is forked last
• A thread can lower it's prioID during a tick, it should only rise its prioIDs just before a pause.

Transformation Steps

The expected input for the compilation chain is an SCG enriched by the results of the depenency analysis. As the compiler does not use any other results from previous compilation steps, any transformation chain, which results in an SCG can be used.The stepwise calculation of the node priorities and the code generation are described in this section.

Requirements for a translation to SCL_P:

• Each thread alway needs to have a unique priority, because the priority is used as a priority for the schedule and additionally, the priority is used as identifier for the thread. Therefore the resulting priority for the schedule is called prioID
• The thread, which is forked first should have the highest prioID, because SCL_P only provides cooperate scheduling and the first thread ist started first (in this case the first thread alsway has the same prioID its the parent thread - because of the calculation below)
• The parent threads inherits the prioID of the thread, which performs the join
• The thread whose exit node has the lowest prioID has to perform the join.
• The thread, which should perform the join is forked last
• A thread can lower it's prioID during a tick, it should only rise its prioIDs just before a pause.

OptimizeSCG:

The OptimizeSCG transformation deletes regions from the SCG, which only consist of an enty and exit node. After the code generation, these regions are transformed to empty threads, which only consist of a label of the SCG is finished. From this point, either the netlist low-level compilation approach or the priority-based low-level compilation approach can be used to generate C code. Because of the different approaches, it is possible, that one of the compiler finds a valid schedule for an SCChart, while the other fails.

General

In contrast to the netlist compiler, this compiler targets only software. It is able to schedule cycles, as long as they only contain transition edges. This restriction is necessary to ensure, that the sequentially constructive model of computation is not violated.

The priority-based low-level compilation approach compiles an SCG enriched by the results of the dependency analysis to SCL_P, whose basis is the programming language C and which is enriched by the SCL_P macros. Therefore the regions of the SCG are fragmented into threads, whose priority determines the order in which the threads are executed. A thread might change its priority, which results in a context switch. The adiministration of the threads is done by the SCL_P macros. As the calculation of the thread priorities is not trivial, it done stepwise, which should help the user to understand how it is done. This is provided by a KiCo compilation chain, which can be called from the SCCharts editor or from the SCG editor.The image below shows the compilation chain as shown by the SCChart editor:

Image Added

The target language SCL_P:

SCL_P is a leaner variant of Synchronous C. It also provides a deterministic thread administration for C which is implemented as macros. As the grammar of an SCG is simpler, less macros are required than for Synchronous C. The macros provided to a programmer are shown below.

Each thread is identified by a unique prioID, which acts as identifier and as priority for the scheduling. The prioID can be changed, e.g. if a thread waits for a result from another thread. The threads are scheduled in descending order of their corresponding prioID. SCL_P uses cooperative scheduling.

tickstart(p)

forkn(label1, p1, ...,  labeln, pn)

par

joinn(p1, ...)

prio(p)

pause

tickreturn()

Requirements for a translation to SCL_P:

• Each thread needs at least one unique prioID.
• The first child inherits the prioID of the parent thread
• The parent threads inherits the prioID of the thread, which performs the join afterwards.
• The thread whose exit node has the lowest prioID has to perform the join.
• The thread, which should perform the join is forked last
• A thread can lower it's prioID during a tick, it should only rise its prioIDs just before a pause.

Transformation Steps

The expected input for the compilation chain is an SCG enriched by the results of the depenency analysis. As the compiler does not use any other results from previous compilation steps, any transformation chain, which results in an SCG can be used.The stepwise calculation of the node priorities and the code generation are described in this section.

Requirements for a translation to SCL_P:

• Each thread alway needs to have a unique priority, because the priority is used as a priority for the schedule and additionally, the priority is used as identifier for the thread. Therefore the resulting priority for the schedule is called prioID
• The thread, which is forked first should have the highest prioID, because SCL_P only provides cooperate scheduling and the first thread ist started first (in this case the first thread alsway has the same prioID its the parent thread - because of the calculation below)
• The parent threads inherits the prioID of the thread, which performs the join
• The thread whose exit node has the lowest prioID has to perform the join.
• The thread, which should perform the join is forked last
• A thread can lower it's prioID during a tick, it should only rise its prioIDs just before a pause.

OptimizeSCG:

The OptimizeSCG transformation deletes regions from the SCG, which only consist of an enty and exit node. After the code generation, these regions are transformed to empty threads, which only consist of a label and are therefore rejected by a later compilation of the resulting SCL_P/C program. However, for real world examples, it is unlikely, that the user models a region without any further functionalty, therefore this step might be removed.

...

This transformation step uses the results from the dependency analysis. It checks, whether a valid schedule for the SCG exists and calculates the node priorities afterwards. Therefore, the strongly connected components of the SCG are calculated, where the nodes of the SCG are the nodes of directed the graph which is connected by dependency and transition edges. Pause edges are ignored. If such a strongly connected component contains a dependency edge, the SCG is not schedulable. Otherwise, the SCG is schedulale and the node priorities, which are crucial for the schedule, can be determined. The priority of a node is the longest path originating from that node, where strongly connected components are considered as a single node and transition edges have weight 0  and dependency edges have weight 1. Again, pause edges are ignored. The theoretical foundation of this transformation step can be found here.

The image shows the resulting node priorities for ABO (blue).

...

The translation from the SCG with prioIDs to SCL_P is straightforward. Assignments and Conditionals are translated to their corresponding C-Code. Labels and gotos are used, if such a node is visited twice. Surface and their corresponding depth nodes are translated to pause statements. If the assigned prioID changes from one node to another, a prio(p) statement added. However, join, fork and entry nodes need more attention. For each fork node it is important to ensure, that the node, which has the highest prioID is translated first and the node which performs the join, which is the node with the lowest prioID assigned to its exit node is translated last. Additionally, for each forkn with n The labels for the threads are the names of the corresponding regions, if they exist and are unique. Otherwise a number is added to the region name or a new label is created. For each forkn with n < 1 a corresponding macro has to be generated. Likewise, a macro needs to be generated, if joinn joins more than one prioID. If another thread has a higher prioID than the exit node of the joining thread, this prioID will be scheduled first and therefore, join does not have to wait for that prioID to finish. However it might happen, that a thread stops because of a pause statement, then the prioID indicated by the corresponding depth node has to be considered by the join. If the prioID of a parallel thread is lower than the prioID of the joining node, it has to be considered as well.

 the prioID of a parallel thread is lower than the prioID of the joining node, it has to be considered as well. Entry nodes hand the corresponding labels of the threads over to the next node, if this is not an exit node or a surface node with a depth node, which results in a prioID switch. This avoids the generation of unnecessary labels.

/*****************************************************************************/
/*                 G E N E R A T E D       C    C O D E                               */
/*****************************************************************************/
/* KIELER - Kiel Integrated Environment for Layout Eclipse RichClient                 */
/*                                                                                    */
/* http://www.informatik.uni-kiel.de/rtsys/kieler/                                    */
/* Copyright 2014 by                                                                  */
/* + Christian-Albrechts-University of Kiel                                           */
/*   + Department of Computer Science                                                 */
/*     + Real-Time and Embedded Systems Group                                         */
/*                                                                                    */
/* This code is provided under the terms of the Eclipse Public License (EPL).         */
/*****************************************************************************/

#define _SC_ID_MAX 2
#include "scl_p.h"
#include "sc.h"                      
                                             
bool A;
bool B;
bool O1;
bool O2;
                                                          
int tick()
{
    tickstart(2);
    O1 = false;
    O2 = false;
    fork1(HandleB,1){
        HandleA:
        if (A){
            label_0:
            B = true;
            O1 = true;
        } else {
            label_1:
            pause;
            if (A){
                goto label_0;
            } else {
                goto label_1;
            }
        }
    } par {
        HandleB:
        pause;
        if (B){
            O1 = true;
        } else {
            goto HandleB;
        }
    } join1(2);
    O1 = false;
    O2 = true;
    tickreturn();
}

The compilation result for ABO.

Packages belonging to this Project:

...

• The node priorities, thread segment ids and prioIDs are now shown in the SCG

...