Back to Homepage
Why are control terminals necessary?
The control terminal is one of the most important concepts in SFL, and was introduced to allow the handling of hierarchical layers using procedures. It allows a complicated system to be described without using a static expression for connections.
An important lesson we have learned from the various design experiences over the years is that we should not use a static expression for connections, i.e., a circuit diagram.
You cannot fully understand a circuit from a circuit diagram. You have to work hard to figure out from it how the circuit operates. Design work based on a circuit diagram is by nature laborious and time consuming: from translating the design idea into connections, and then, through reverse engineering, working out the operations from the connections, to finally revising and completing the design.
But a circuit diagram has one advantage. Expressing an object with connections between component elements allows any of the component elements to be similarly expressed with connections between low-order component elements. That is, a circuit diagram has recursiveness by nature. This allows for a hierarchical structure and reuse of components. Moreover, recursive expression can be applied at any stage of circuit synthesis. This is why circuit diagrams are widely used for circuit design in spite of the drawback mentioned above.
Our conclusion from the above is that we must provide for the description of both operations (procedures) and hierarchical structure. This has led to the concept of the control terminal.
Example of describing a control terminal
The control input terminal is used to pass the procedure (control) from outside a given layer to inside it. For example,
abc.xyz();
indicates "Execute 'xyz' on the component element 'abc'." Viewed from "abc", control comes from "xyz", and therefore, "xyz" is called a control input terminal. A control input terminal is associated with an operation, and this operation is activated from outside. If the execution of "xyz" requires multiple machine cycles, a job for stage stg is generated by the control terminal "xyz", for example, as follows:
instruct xyz par {
generate stg.tsk();
...
}
The line "instruct ..." associates the control terminal with an operation. The description of job generation is:
generate Object.Indication( );
This Object.Indication( ) format is one of the key concepts in the SFL language.
The control terminals in the example in Section 3.4 were activated by:
do();
or
do().result
The activation of control terminals and stages is differentiated from the operation of other data elements by the parentheses () placed after the name. Since the control internal terminal and control output terminal can be uniquely identified by name alone, the above description is sufficient. However, the activation of control input terminals of a sub-module must be modified with the sub-module name, as follows:
Sub-moduleName.ControlInputTerminalName();
The same concept applies to the format of stage activation. In its basic form, a stage is activated by,
StageName.TaskName();
However, since the activation involves job generation and job relay, the activation is divided into
generate StageName.TaskName();
and
relay StageName.TaskName();
The "do().result" format is a composite form of both control terminal activation and result reference combined.
This format can be further modified with a sub-module name as follows:
ALU.add(ox11,oxff).sum
This denotes the value of an "ALU" data output terminal named "sum", resulting from the activation of an "ALU" control input terminal named "add". The items inside the parentheses () are actual arguments (values) to be relayed at the time the control input terminal is activated. Which "ALU" data input terminal receives these actual arguments is specified by the "instr_arg" syntax described in Section 3.9. Of course, actual arguments can be specified to activate a control terminal alone (i.e., without result reference being combined).
Control terminals are classified into control input terminals, which are controlled from outside, control output terminals, which control the outside, and internal control terminals, which are controlled internally.
Repeatedly-used processes of the subcontracting type, which are completed within a machine cycle, are candidates for internal control terminals. So, when you find a similar description appearing frequently in an SFL description, consider the use of an internal control terminal.
Back to the SFL (Structured Function Description Language) page