1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
|
Diese Anleitung beschreibt die Benchmarkgenerierung mit AEMR/dfatool. Sie geht
von der folgenden Verzeichnisstruktur aus.
* `data`: Benchmark-Messdaten
* `data/cache`: Cache für teilweise ausgewertete Benchmarks
* `dfatool`: dfatool-Repository
* `multipass`: multipass-Repository
*multipass* enthält Gerätetreiber mit zugehörigen PTA-Definitionen
(Transitionen, Zustände und Parameter der Hardware) sowie Hilfsfunktionen für
Benchmarks. Es verzichtet bewusst auf Tasking und System-Ticks, um Benchmarks
nicht durch Timer Interrupts zu beeinflussen. In *dfatool* liegen die
Generierungs- und Auswertungsskripte.
## Benchmarkgenerierung
Die Generierung und Vermessung von Benchmarks erfolgt immer mit
`generate-dfa-benchmark.py`. Dieses muss vom multipass-Verzeichnis aus
aufgerufen werden. Ein Benchmark läuft wie folgt ab.
* Generierung von Läufen durch den PTA des zu vermessenden Geräts. Die Läufe
können u.a. mit `--depth`, `--shrink` und `--trace-filter` beeinflusst
werden.
* Erzeugung einer C++-Anwendung (`src/app/aemr/main.cc`), welche die Hardware
durch die Läufe schickt und die ausgeführten Transitionen protokolliert. Sie
greift auf `include/object/ptalog.h` zurück.
* Die grundlegende Anwendungsstruktur (Header, Aufruf der Treiberfunktionen,
Wartezeit zwischen Funktionsaufrufen) wird von generate-dfa-benchmark
vorgegeben (`benchmark_from_runs`)
* Ein Test Harness aus `lib/harness.py` (OnboardTimerHarness für
energytrace/timing benchmarks, TransitionHarness für MIMOSA) erweitert
die generierte Anwendung um Synchronisierungsaufrufe und/oder zusätzliche
Messungen, z.B. mit einem Onboard-Timer. Dazu werden für jeden Lauf durch
den PTA `start_run` und `start_trace` aufgerufen ("ein neuer Lauf beginnt"),
dann für jeden Funktionsaufruf und jeden Zustand `append_transition`,
`append_state` und `pass_transition` und schließlich `stop_run`.
Das Harness speichert die zum generierten Code gehörenden Läufe und die
während eines Zustands / einer Transition gültigen PTA-Parameter intern als
`{"isa": "state", "name": ..., "parameter": dict(...)}` bzw.
`{"isa": "transition", "name": ..., "parameter: dict(...), "args": list(...)}`
* Kompilieren der Anwendung in `run_benchmark` per `runner.build` (siehe
`runner.py`). Falls der Benchmark zu groß ist, wird er in mehrere
Anwendungen aufgeteilt, die nacheinander ausgeführt und vermessen werden.
Zusätzlich wird jede Messung mehrfach durchegführt, um Einflüsse durch
Messfehler zu minimieren.
* Ausführung des Benchmarks. Der Code wird mittels `runner.flash` programmiert,
die Ansteuerung zusätzlicher Software (z.B. MIMOSA, EnergyTrace) erfolgt über
einen Monitor aus `lib/runner.py`. Sobald der Monitor mittels `get_monitor`
erzeugt wird, beginnt die Messung. Während der Messung werden Ausgaben
von der seriellen Konsole über den `parser_cb` des aktiven Test Harness
verarbeitet; auf diese Weise wird auch das Ende des Benchmarks erkannt.
`monitor.close()` beendet die Messung.
* Nach Abschluss aller (Teil)benchmarks und Wiederholungen werden
die Benchmarkpläne (`harness.traces`), UART-Ausgaben (`monitor.get_lines()`)
und ggf. zusätzliche Logfiles (`monitor.get_files()`) in eine tar-Datei
archiviert.
## Beispiel
Wenn sich msp430-etv und energytrace in $PATH befinden, generiert der folgende
Aufruf mit einem MSP430FR5994 Launchpad ohne Peripherie einen erfolgreichen
Benchmark-Ablauf:
```
cd multipass
../dfatool/bin/generate-dfa-benchmark.py --data=../data \
--timer-pin=GPIO::p1_0 --sleep=200 --repeat=3 --arch=msp430fr5994lp \
--energytrace=sync=bar model/driver/sharp96.dfa src/app/aemr/main.cc
```
Nach einigen Minuten wird unter `data` ein auf sharp96.tar endendes Archiv mit
Benchmark-Setup (Treiber-PTA, energytrace-Config, Traces durch den
Automaten) und Messdaten (energytrace-Logfiles) abgelegt. Dieses kann wie folgt
analysiert werden:
```
cd dfatool
bin/analyze-archive.py --info --show-model=all --show-quality=table ../data/...-sharp96.tar
```
Sofern sich die LED-Leistungsaufnahme des verwendeten Launchpads im üblichen
Rahmen bewegt, funktioniert die Auswertung. Hier sollten für POWEROFF und
POWERON sehr ähnliche Werte herauskommen (da ja keine Peripherie angeschlossen
war) und die writeLine-Transition deutlich mehr Zeit als die restlichen
benötigen.
|
