WCET Analysis

From JopWiki

Jump to: navigation, search

Contents

[edit] Overview

The Worst-Case Execution Time (WCET) Analysis tool computes an upper bound for the time (number of cycles) needed to execute a method.

It supports almost all byte codes, takes the instruction cache into account and uses data flow analysis to derive many loop bounds automatically.

At the end, a report is generated to visualize the execution times.

[edit] See also

Ideas for smaller (engineering) projects

Ongoing work: An extended, more powerful annotation language

Ideas for the next version of Stefan's CFG library (not yet started)

[edit] Getting Started

It is assumed that you build the JOP processor, otherwise first run

 make gen_mem -e ASM_SRC=jvm JVM_TYPE=USB

to generate the assembler files. For the sake of simplicity we will assume from now on that we're trying to analyze the LineFollower benchmark.

To analyze the method wcet.StartLineFollower.measure we run

 make P1=test P2=wcet P3=StartLineFollower java_app wcet WCET_METHOD=wcet.StartLineFollower.measure
 # Also works
 make P1=test P2=wcet P3=StartLineFollower java_app wcet WCET_METHOD=measure

If we want to use DFA analysis (finds many loop bounds automatically, but takes some time), we run

 make P1=test P2=wcet P3=StartLineFollower java_app wcet WCET_METHOD=measure WCET_OPTIONS="-dataflow-analysis"

After a successful WCET analysis, we change into the report directory, run make and then open the report:

 cd java/target/wcet/wcet.StartLineFollower_measure/report/
 make # requires the dot graph visualizer
 open index.html

If everything worked fine, you should now be confronted with a quite detailed execution time report.

There are many more options available, to get a list of them run

 make wcet_help

Most options can be classified as follows:

  • jop-* : to choose the configured JOP hardware
  • cache-* : to choose a cache configuration
  • ipet-* : To control the IPET solver backend
  • uppaal-*: for the experimental UPPAAL solver backend


[edit] Bugs & FAQ

  • Q: I'm using Linux (Ubuntu) and get the following error message:
 [ERROR] Failed to load the lp_solve Java library: java.lang.UnsatisfiedLinkError: no lpsolve55j in java.library.path

A: Unfortunately, the liblpsolve55-dev package is broken and does not include the java bindings. To use the libraries shipped with JOP, try adding the JOP root directory to your LD_LIBRARY_PATH, e.g., when using bash

 export LD_LIBRARY_PATH=/path/to/jop:$LD_LIBRARY_PATH
  • Q: I did so, but then I get complains about libstc++.5 and libcolamd

A: The old stdc++ library is still available (June 09), so

 sudo apt-get install libstdc++5

but for libocamd it is easiest to use a newer version via this (possibly harmful) hack:

 sudo ln -s /usr/lib/libcolamd.so.3.2.0 /usr/lib/libcolamd.so.1
Personal tools