The user must load a compiled binary into the XTA, then define the timing-critical sections of code within the application and specify the timing constraints for each section of code. The tool supports timing functions, timing loops and the execution between two endpoints. The tool verifies that all possible paths of execution meet the specified timing constraints. If all paths meet their timing requirements then the minimum xCORE tile frequency the xCORE device can be run at to meet timing requirements is also output.

The tool can be used interactively on the command-line or through a graphical user interface (GUI) in xTIMEcomposer Studio.

When working within xTIMEcomposer Studio, loading a binary into the XTA is done by creating a new Time configuration. These work in the same way as the Run and Debug configurations. Once the configuration exists, the binary can be loaded into the XTA using the Time button in the toolbar. To load a binary that does not have an associated xTIMEcomposer project, see Files View.

To load a binary from the console, type:

load <FILE NAME>

A route is a timing-critical section of code. It consists of the set of all paths through which control can flow between two points in a program (endpoints). A route can be created by timing a function, timing a loop or by timing between endpoints.

An endpoint is any source line that, during the compilation process, must be preserved, and its order with respect to other endpoints must be maintained. In the GUI the locations of valid endpoints are marked in the editor.

To show a list of all endpoints type the following command on the console:

list allendpoints

If specifying a route with respect to assembly code then any valid label/program counter (PC) can be used as an endpoint. However, program counters are classed as non-portable endpoints as they are likely to change between compilations and their use in scripts is therefore discouraged.

Source lines can be labeled with endpoint pragmas in order to ensure that the endpoints are portable. For example, Putting an endpoint pragma into XC. shows a function that has been annotated with endpoint pragmas called start and stop.

int g(in port p) {
    int x, y;

    # pragma xta endpoint " start "
    p :> x;

    # pragma xta endpoint " stop "
    p :> y;

    return (y - x);
}

The endpoints defined in source are listed in the Info View.

On the console, type:

list endpoints

In xTIMEcomposer Studio set the from and to endpoint and then click the Analyze endpoints button. Endpoints are set by right-clicking on the marker showing where valid endpoints are in the source.

On the console, type:

analyze endpoints <from ENDPOINT> <to ENDPOINT>

The tool does not time code across multiple xCORE tiles so both endpoints must be on the same tile.

One analysis can result in multiple routes being generated (see Multiple Route Creation for further details).

In xTIMEcomposer Studio select the function name from the list of available functions using the Analyze function button.

On the console, type:

analyze function <FUNCTION>

This will create a route which describes the set of all possible paths from the function entry point to all the function return points.

In xTIMEcomposer Studio set the looppoint and then click the Analyze loop button. Looppoints are set by right-clicking in the margin and selecting the Set loop point option.

On the console, type:

analyze loop <ANY>

This creates a route that describes all possible paths through the loop. It it effectively a shortcut for timing between endpoints where the start and stop endpoint is the same, the point is within a loop and an exclusion has been placed such that everything outside the loop is excluded.

One analysis can result in multiple routes being generated (see Multiple Route Creation for further details).

For each route created it is necessary to define its timing requirements. In xTIMEcomposer Studio right-click on the route in the upper panel of the Routes View and select Set timing requirements in the context menu.

On the console, type:

set required <route id> <value> <MODE>

The supported timing modes are defined in Timing Modes.

The route IDs can be found in the console by typing:

print summary

Alternatively, the - character can be used on the command-line or in a script to refer to the last route analyzed.