doc: multipass-update, kratos dazu

1 files changed, 0 insertions, 85 deletions

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.