Content
- 1 Introduction
- 2 Notation
- 3 Tool Usage
- 4 Top Level Elements
- 5 Control Flow Elements
- 6 Data Flow Elements
- 7 Location Attributes
- 8 Loop Bound Attributes
- 9 Time and Execution Attributes
- 10 Control Flow Properties
- 11 Control Flow Constraints
- 12 Data Flow Properties
- 13 Data Flow Constraints
- 14 Future Developments
- 15 Appendix A: FFX Grammar
- 16 Appendix B: Example – output of oRange tool
4 Top Level Elements
The aim of this format is to associate information :
flow facts
state definition
with the different locations of the program :
contextual location (task, architecture, scenario, etc)
static location (in code)
dynamic location (path identification, context call, loop iteration, etc).
The basic content of an OTAWA flow facts file (.ffx) is presented below and detailed in the following sub-sections:
FLOWFACTS ::= <flowfacts> TOP-LEVEL-ITEM* </flowfacts>
Top-level items are mainly responsible to identify the contextual location. Two top-level elements may be distinguished:
contexts – takes into account a particular context (scenario, hardware configuration, task, etc)
function – that give information for a call to an identified function
If contexts may be composed / chained according to an AND logic, the functions can only contain intra-function elements.
TOP-LEVEL-ITEM ::= CONTEXT | FUNCTION | ...
This scheme allows to link together information from the most general case to the most specific one. An information at the top-level will apply to all possible uses of the program parts is applied to. In the opposite, it may be superseded in a particular context if the context is activated.
4.1 Context Element
A context defines a condition to cope with the information it contains. Before a computation, all activated contexts must be passed to the calculator and only information that satisfy all contexts they are embedded in are used.
CONTEXT ::=
<context name="TEXT">
TOP-LEVEL-ITEM*
</context>
For example, in the code below :
<context name="arm"> <function name="f"> <loop maxcount="10"/> </function> </context> </context> <context name="arm"> <context name="task_1"> <function name="f"> <loop maxcount="5"/> </function> <context> </context>
If only the arm context is given, the loop bound will be 10 while, if both contexts arm and task_1 are passed, the bound 5 will be applied.
Notice that the context names may be classified and prefixed using the construction below:
| Template | Description |
|---|---|
| hard:TEXT | hardware context |
| task:TEXT | task context |
| scen:TEXT | scenario context |
An hardware represents the different behavior of an application to the hardware they are running on. For example, the number of iteration of a loop counting the number of bits to one in a word depends on the size of the word. It will be 32 on a 32-bits machine and 64 on a 64-bits machine.
The function composing the application may be called by different tasks making the real-time work. According to the task calling the function, some flow properties may have different values. We could just take the worst case to describe the function whatever the context but it would at the price of a loss of precision and an overestimation of the WCET.
Finally, flow information may depend on a chosen scenario, mainly a running situation chosen by the user. For example, when a system exhibits running states like normal state, failure state or critical state, it may be interesting to examines the different times of a task according to the state as the scheduling may also changes. In addition, the properties defined in a scenario may also used to force the behavior of the task by, for example, fixing the value of the state variable.
4.2 Code and Data Elements
From the context description or the main elements of flowfacts, we get the elements describing the code, mainly function elements and the data elements describing the used variables and types. They are described in the following sections.