From b0ffa67141ca17c2c6f48cc2313fdd51d8f1b6e6 Mon Sep 17 00:00:00 2001 From: Daniel Friesel Date: Mon, 3 May 2021 15:29:25 +0200 Subject: doc: multipass-update, kratos dazu --- doc/energy-kratos.md | 49 ++++++++++++++++++++++++ doc/energy-multipass.md | 86 +++++++++++++++++++++++++++++++++++++++++++ doc/generate-dfa-benchmark.md | 85 ------------------------------------------ 3 files changed, 135 insertions(+), 85 deletions(-) create mode 100644 doc/energy-kratos.md create mode 100644 doc/energy-multipass.md delete mode 100644 doc/generate-dfa-benchmark.md diff --git a/doc/energy-kratos.md b/doc/energy-kratos.md new file mode 100644 index 0000000..03ac3de --- /dev/null +++ b/doc/energy-kratos.md @@ -0,0 +1,49 @@ +Diese Anleitung beschreibt die Generierung von Energiemodellen mit dfatool und +Kratos. Sie geht von der folgenden Verzeichnisstruktur aus. + +* `data`: Benchmark-Messdaten +* `data/cache`: Cache für teilweise ausgewertete Benchmarks +* `dfatool`: dfatool-Repository +* `kratos`: Kratos-Repository + +*kratos* enthält Gerätetreiber mit zugehörigen PTA-Definitionen +(Transitionen, Zustände und Parameter der Hardware) sowie Hilfsfunktionen für +Benchmarks. In *dfatool* liegen die Generierungs- und Auswertungsskripte. + +## Benchmarkgenerierung + +Die Generierung und Vermessung von Benchmarks erfolgt immer mit +`generate-dfa-benchmark.py`. Dieses muss vom Kratos-Verzeichnis aus +aufgerufen werden. Kratos muss zuvor passend konfiguriert worden sein. + +Konfiguration: + +* msp430fr5994 "UART on eUSCI\_A" aktiv: "uart" mit 9600 Baud auf A1 +* msp430fr5994 "Timer/Counter" aktiv: 16/1/1 == 16 MHz CONTINUOUS von SMCLK auf A1 +* msp430fr5994 "Cycle Counter" aktiv: via A1 +* apps "dfatool energy benchmark" aktiv (und sonst nix) + +Ablauf: Siehe energy-multipass.md + +## Beispiel + +Wenn sich msp430-etv und energytrace in $PATH befinden und ein CC1101 Funkchip +angeschlossen und in Kratos konfiguriert ist, generiert der folgende Aufruf mit +einem MSP430FR5994 Launchpad einen erfolgreichen Benchmark-Ablauf: + +``` +cd kratos +../dfatool/bin/generate-dfa-benchmark.py --data=../data \ +--os=kratos --sleep=500 --repeat=1 --depth=3 --arch=msp430fr \ +--energytrace=sync=timer model/drivers/radio/cc1101_simpliciti.dfa src/apps/AEMR/AEMR.cc +``` + +Nach einigen Minuten wird unter `data` ein auf radio.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/...-radio.tar +``` diff --git a/doc/energy-multipass.md b/doc/energy-multipass.md new file mode 100644 index 0000000..bc49175 --- /dev/null +++ b/doc/energy-multipass.md @@ -0,0 +1,86 @@ +Diese Anleitung beschreibt die Generierung von Energiemodellen mit dfatool und +multipass. 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. Die multipass-Konfiguration (Treiber und Anwendungen) +sowie Codegenerierung läuft automatisch. + +* 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 \ +--sleep=50 --repeat=3 --arch=msp430fr5994lp \ +--energytrace=sync=timer 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. diff --git a/doc/generate-dfa-benchmark.md b/doc/generate-dfa-benchmark.md deleted file mode 100644 index 48a991d..0000000 --- a/doc/generate-dfa-benchmark.md +++ /dev/null @@ -1,85 +0,0 @@ -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. -- cgit v1.2.3