2 Operation Set Abstraction Layer (OSAL) Tools

Input: OSAL definitions

Output: OSAL definitions

1 Operation Set Editor (OSEd)

Operation Set Editor (OSEd) is a graphical application for managing the OSAL (Section 2.2.6) operation database. OSEd makes it possible to add, simulate, edit and delete operation definitions.

1 Capabilities of the OSEd

OSEd is capable of the following operations:

All operations found in pre-defined search paths (see Section 4.4) are organised in a tree-like structure which can be browsed.
Operation properties can be examined and edited.
Operations with a valid behavior model can be tested (simulated).
New operation modules can be added to search paths.
Operation definitions can be added to a module.
Modules containing operation behaviors can be compiled, either all at once, or separately.
Modules can be removed.
Contents of the memory can be viewed and edited.

2 Usage

This chapter introduces the reader to the usage of OSEd. Instructions to accomplish the common tasks are given in detail.

Operation Set Editor can simply be executed from command line with:

osed

**Figure 4.1:** OSEd Main window.
$\begin{figure}\centerline{\psfig{figure=eps/osed/MainWindow.eps,width=0.75\textwidth}}\end{figure}$

The main window is split in two areas. The left area always displays a tree-like structure consisting of search paths for operation definition modules, operation modules, and operations. The right area view depends on the type of the item that is currently selected in the left area. Three cases are possible.

If the selected item is a search path, the right area shows all operation modules in that path.
If the item is a module, the right area shows all the operations defined in the module.
If the item is an operation, the right area displays all the properties of the operation.

Figure 4.1 shows an example of the second situation, in which the item currently selected is a module. The right area of the window shows all the operations in that module. If an operation name is shown in bold text, it means that the operation definition is ``effective'', that is, it will actually be used if clients of OSAL request an operation with that name. An operation with a given name is effective when it is the first operation with that name to be found in the search paths. Other operations with the same name may be found in paths with lower search priority. Those operations are not effective.

Figure 4.2 shows an example of an operation property view, that is shown in the right side when an operation is selected on the left side.

**Figure 4.2:** Operation property view.
$\begin{figure}\centerline{\psfig{figure=eps/osed/StaticOperationProperties.eps, width=0.50\textwidth}}\end{figure}$

1 Editing Static Operation Properties

Figure 4.3 shows the dialog for editing the static properties of an operation.

**Figure 4.3:** Operation property window
$\begin{figure}\centerline{\psfig{figure=eps/osed/OperationProperties.eps, width=0.70\textwidth}}\end{figure}$

Operation inputs and outputs (henceforth, ``terminal'' is used to denote both) can be deleted by selecting an item from the list and clicking the Delete button. New terminals can be added by clicking the Add button, and can be modified by clicking the Modify button. The order of the terminals can be changed by selecting a terminal and pushing on of the arrow buttons. By pushing the downward arrow button, the terminal is moved one step downwards in the list; by pushing the upward arrow button, it is moved one step up on the list.

Operand properties can be modified by clicking on the check boxes. The set of operands that can be swapped with the operand being edited are shown as a list of references to operands (input indentification numbers). A reference to an operand can be removed by selecting the corresponding item in the `can swap' list and clicking the Delete button. A new reference to another operand can be added by selecting an item from the choice list and clicking the Add button.

2 Operation Behaviour Model

Behaviour models of operations are stored in separate source files. If the operation definition includes a behaviour model, the behaviour source file can be opened in a text editor of choice by clicking on the Open button. If the operation does not have behavior source file, clicking Open will open an empty file in an editor. The text editor to use can be defined in the options dialog. All changes to operation properties are committed by clicking the OK button and canceled by clicking the Cancel button.

3 Operation Directed Acyclic Graph

By treating each operation as a node and each input-output pair as an directed arc, it is possible to construct operation's Directed Acyclic Graph (DAG) presentation. For primitive operations which do not call any other operations, this graph is trivial; one node (operation itself) with input arcs from root nodes and output arcs to leafs. With OSAL DAG language, it is possible to define operation behavior model by composing it from multiple operations' respective models.

Operation's OSAL DAG code sections can be edited by pressing the Open DAG button, which opens the DAG editor window. Code section shows the currently selected DAG code from the list box below. A new DAG section can be created either by selecting New DAG list box item or pressing the New button. By pressing the Undo button, it is possible to revert changes to current code from the last saved position. DAG can be saved to operation's definition file by pressing the Save button. Unneccessary DAG sections can be deleted by pressing the Delete button.

If code section contains valid OSAL DAG code, then the editor window shows a DAG presentation of that code. In order to view the graph, a program called dot must be installed. This is included in Graphviz graph visualization software package and can be obtained from www.graphviz.org.

4 Operation Modules

Figure 4.4 shows the dialog for adding a new operation module to a search path. The name of the module can be entered into the text input field.

Operation modules may consist also of a behaviour source file. Before operation behaviour modules can be simulated, it is necessary to compile the source file. Figure 4.5 shows a result dialog of module compilation.

**Figure 4.4:** Dialog for adding new operation module.
$\begin{figure}\centerline{\psfig{figure=eps/osed/AddModule.eps,width=0.32\textwidth}}\end{figure}$

**Figure 4.5:** Result of module compilation
$\begin{figure}\centerline{\psfig{figure=eps/osed/BuildResult.eps,width=0.55\textwidth}}\end{figure}$

5 Data Memory Simulation Model

The contents of the data memory simulation model used to simulate memory accessing operations can be viewed and edited. Figure 4.6 shows the memory window. Memory can be viewed as 1, 2, 4, or 8 MAUs. The format of the data is either in binary, hexadecimal, signed integer, unsigned integer, float, or double format. The contents of the memory can be changed by double clicking a memory cell.

**Figure 4.6:** Memory window
$\begin{figure}\centerline{\psfig{figure=eps/osed/Memory.eps,width=0.60\textwidth}}\end{figure}$

6 Simulating Operation Behavior

The behavior of operation can be simulated using the dialog in Figure 4.7. Input values can be edited by selecting a input from the input list and typing the new value in a text field below the input list. Change can be committed by pushing Update button. Trigger command and advance clock command are executed by pushing Trigger and Advance clock buttons. The format of the inputs and outputs can be modified by selecting a new format from the choice list above the Trigger button.

**Figure 4.7:** Operation Simulation
$\begin{figure}\centerline{\psfig{figure=eps/osed/Simulate.eps,width=0.85\textwidth}}\end{figure}$

2 Operation Behavior Module Builder (buildopset)

The OSAL Builder is an external application that simplifies the process of compiling and installing new (user-defined) operations into the OSAL system.

The OSAL Builder is invoked with the following command line:

buildopset <options> operation_module

where operation_module is the name of the operation module. Operation module is the base name of a definition file, e.g., the module name of base.opp is `base'. The operation_module can also be a full path, e.g., `/home/jack/.tce/opset/custom/mpeg'.

The behavior definition source file is searched in the directory of the operation_module. The directory of the operation_module is by default the current working directory. User may also enter the directory of the source file explicitly with switch `-s'. The suffix of the behavior definition source file is `.cc'.If no options are given, the output file is a dynamic module and is stored in the directory of the operation_module.

The OSAL Builder accepts the following command line options:

$\begin{longtable}[htb]{@{}p{.10\textwidth}@{}p{.20\textwidth}@{}p{.15\textwidth}... ...re the behavior definition source file to be used is found. \par \end{longtable}$

Third-party libraries can be used in the operation behavior model. buildopset uses the environment variables CPPFLAGS, CXXFLAGS and LDFLAGS to search for the external library. E.g.:

CPPFLAGS=-I/opt/mpeg/inlucde LDFLAGS=-lmpeg buildopset /home/jack/.tce/opset/custom/mpeg

3 OSAL Tester (testosal)

The OSAL Tester is a small external application meant for debugging operation behavior models. The Tester lets user to specify lists of operations and constant input values and the outputs the corresponding sequence of result values.

The OSAL Tester can be run in interactive mode or in batch mode (like a script interpreter). The batch mode is especially useful to create input data sets of regression tests.

For all operations having state, a single operation state instance is constructed the first time the operation is simulated. This state instance is then used through the testing session by all operations that share the same operation state.

When started, the OSAL Tester enters interactive mode and prompts the user for operations. Any nonempty line entered by the user is interpreted as one operation (e.g. ``ADD 1 2``), unless the character `!' is given at the beginning of the string. This character (which is not allowed in operation names) introduces meta-commands that are recognized by the interpreter and are not treated as potential operations in the architecture repertoire. For example, the OSAL Tester can be quit with the meta-command !quit. See !help for a list of meta commands and !help <cmdname> for their usage.

Single operands of operations may only be constants and are separated by blanks.

For any line entered by the user, the Tester responds with a text line containing the results computed by the operation.

Pekka Jääskeläinen 2018-03-12