Devlog on 0xMax42 - Flatfile-Purist. Autodidakt. Systemdenker.

power-state-target: Wie ich den Energiezustand meines Laptops in systemd modelliert habe

Tue, 02 Dec 2025 21:30:00 +0000

Es gibt diese kleinen Probleme, die einen jahrelang unterschwellig nerven, bis man sie endlich einmal sauber löst. Genau in diese Kategorie fällt bei mir das Thema „Was macht das System, wenn ich auf Akku bin – und was darf es nur am Netz?“

Klar, es gibt Tools wie TLP, Powertop & Co., und viele Desktop-Umgebungen haben ihre eigenen Energiespar-Profile. Aber ich wollte etwas anderes:

Ich wollte den aktuellen Power-Zustand (Akku vs. Netz) als systemd-Target haben – sauber integriert, automatisierbar, paketiert und über meine eigene Debian-Repository-Infrastruktur ausrollbar.

Das Ergebnis ist dieses kleine, aber sehr praktische Projekt: power-state-target.

Problem: Der Energiezustand als „unsichtbare“ Information

UPower weiß, ob die Maschine auf Akku läuft. Der Desktop weiß es. Der Nutzer sieht irgendwo ein Batteriesymbol. Aber für viele meiner eigenen Dienste, Timer und Skripte ist diese Info nicht direkt greifbar.

Typische Fragen:

„Starte diesen Dienst nur, wenn das Gerät am Netz hängt.“
„Fahre diese IO-intensiven Jobs bitte nicht auf Akku.“
„Auf Akku darf etwas weiterlaufen, aber nur in einem Light-Mode.“

Man kann natürlich überall lokale Checks einbauen – upower, busctl, eigene Daemons, irgendwelche kleinen Wrapper. Aber das ist alles verteilt, unübersichtlich und schlecht testbar.

Systemd bietet für solche Zustände eigentlich eine perfekte Abstraktion: Targets.

Also war der Plan:

Ich möchte ein power-ac.target und ein power-battery.target haben.
Genau einer dieser Targets soll immer „aktiv“ sein – je nachdem, ob das System auf Akku oder am Netz hängt.
Dienste können sich dann einfach daran „dranhängen“, statt selbst Power-Logik zu implementieren.

Ziel: systemd als Single Source of Truth für den Power-State

Die Idee hinter power-state-target ist bewusst minimalistisch:

Keine eigene fette Daemon-Logik.
Nutzung von vorhandener Infrastruktur: UPower und systemd.
Ein kleiner Listener, der den Zustand aus UPower liest und passende systemd-Targets setzt.
Das Ganze als Debian-Paket, das sich in meine bestehende Build- und Release-Infrastruktur einfügt.

Im Kern besteht das Projekt aus:

zwei systemd-Targets: power-ac.target und power-battery.target
einem systemd-Service: power-state-listener.service
einem kleinen Shell-Skript: /usr/libexec/update-power-state
Debian-Packaging + automatisierter Build- und Release-Pipeline über Gitea

Die Targets: `power-ac` und `power-battery`

Die beiden Targets sind bewusst extrem simpel gehalten. Sie dienen als Zustandsmarkierungen, nicht als eigene Logik-Einheiten:

1
2
3
4


# /usr/lib/systemd/system/power-ac.target
[Unit]
Description=AC Power Mode
AllowIsolate=yes

1
2
3
4


# /usr/lib/systemd/system/power-battery.target
[Unit]
Description=Battery Power Mode
AllowIsolate=yes

Ein paar Gedanken dazu:

Sie haben keine eigenen [Install]-Sektionen – sie werden nicht direkt aktiviert, sondern vom Listener-Service gesetzt.
Über AllowIsolate=yes kann man sie theoretisch auch isolieren, falls man das einmal für Experimente nutzen möchte.
Für andere Units sind sie vor allem als Anker gedacht: Wants=power-ac.target, BindsTo=power-battery.target, PartOf= usw.

Die eigentliche Intelligenz steckt im Listener.

Der Listener: `power-state-listener.service`

Der Listener ist ein kleiner systemd-Service, der genau eine Aufgabe hat:

UPower beobachten und bei Änderungen der Energiequelle das passende Target aktivieren.

Die Unit dazu sieht so aus:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


# /usr/lib/systemd/system/power-state-listener.service
[Unit]
Description=Wait for UPower power-state change and update targets
Wants=upower.service
After=upower.service

[Service]
Type=simple
ExecStartPre=/usr/libexec/update-power-state
ExecStart=/bin/sh -c \
 'upower --monitor-detail | head -n 1 > /dev/null; \
 /usr/libexec/update-power-state'
Restart=on-success
RestartSec=0

[Install]
WantedBy=multi-user.target

Die wichtigen Punkte:

ExecStartPre=/usr/libexec/update-power-state sorgt dafür, dass der aktuelle Zustand sofort beim Start des Dienstes gesetzt wird (z.B. nach einem Boot).
ExecStart=... upower --monitor-detail hängt sich an die UPower-Monitor-API und wartet auf ein Ereignis (zum Beispiel: Stromkabel gezogen oder eingesteckt).
Sobald ein Ereignis eintritt, läuft danach erneut update-power-state, dann beendet sich der Dienst erfolgreich.
Durch Restart=on-success wird der Service automatisch neu gestartet. Ergebnis: eine kleine Ereignis-Schleife, die immer reagiert, wenn sich der Power-State ändert, ohne selbst busy zu sein.

Das ist im Grunde ein reaktives Mini-Framework: systemd + UPower erledigen 95 % der Arbeit, der Rest ist eine dünne Klebeschicht.

Die eigentliche Logik: `/usr/libexec/update-power-state`

Das Herzstück ist ein Shell-Skript, das genau zwei Dinge tut:

Den aktuellen UPower-Status („bin ich auf Akku?“) abfragen.
Die passenden systemd-Targets setzen.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


#!/bin/sh

get_state() {
 busctl get-property org.freedesktop.UPower \
 /org/freedesktop/UPower \
 org.freedesktop.UPower \
 OnBattery \
 | awk '{print $2}'
}

apply_state() {
 state="$1"
 if [ "$state" = "true" ]; then
 systemctl start power-battery.target
 systemctl stop power-ac.target
 else
 systemctl start power-ac.target
 systemctl stop power-battery.target
 fi
}

apply_state "$(get_state)"

Ein paar Details dazu:

busctl get-property ... OnBattery holt sich direkt den OnBattery-Property von UPower über D-Bus.
UPower liefert hier ein b true oder b false – über awk '{print $2}' ziehe ich mir einfach den Wahrheitswert heraus.
Wenn true, wird power-battery.target gestartet und power-ac.target gestoppt.
Wenn false, genau umgekehrt.

Damit ist sichergestellt, dass nie beide Targets gleichzeitig aktiv sind, sondern immer genau einer der beiden Zustände gilt.

Integration in Debian: Paket `power-state-target`

Weil ich praktisch alles, was ich produktiv nutzen will, in .deb-Pakete verpacke, war von Anfang an klar: Das hier wird ein normales Debian-Paket mit sauberem debian/-Verzeichnis.

Die debian/control ist bewusst minimal:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


Source: power-state-target
Section: utils
Priority: optional
Maintainer: 0xMax42 <debian@0xMax42.io>
Build-Depends: debhelper-compat (= 13)
Standards-Version: 4.7.0
Rules-Requires-Root: no

Package: power-state-target
Architecture: all
Depends: ${misc:Depends}, upower
Description: Power state target management
 Introduces a systemd target that reflects the current power state
 of the system (on battery, on AC power) and updates it
 dynamically as the power state changes.

Architektur ist all, weil es sich nur um Skripte und Unit-Files handelt.
Die einzige echte Laufzeit-Abhängigkeit ist upower.
Rules-Requires-Root: no – gebaut werden kann also auch ohne Root, sofern die Build-Dependencies vorhanden sind.

Die Installation der Dateien übernimmt debian/install:

1
2
3
4


usr/libexec/update-power-state usr/libexec/
usr/lib/systemd/system/power-state-listener.service usr/lib/systemd/system/
usr/lib/systemd/system/power-ac.target usr/lib/systemd/system/
usr/lib/systemd/system/power-battery.target usr/lib/systemd/system/

debian/rules ist dementsprechend trivial:

1
2
3
4


#!/usr/bin/make -f

%:
 dh $@

Das Ganze ist als native Paketquelle (debian/source/format = 3.0 (native)) angelegt, da Projekt und Paket faktisch identisch sind.

Automatisierter Debian-Build mit `build.sh`

Um das Paket nicht nur lokal, sondern auch automatisiert im CI bauen zu können, gibt es ein eigenes Build-Skript:

 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


#!/bin/bash
set -euo pipefail

REQUIRED_PKGS=(build-essential devscripts dkms debhelper dh-dkms)

missing=()
for pkg in "${REQUIRED_PKGS[@]}"; do
 dpkg -s "$pkg" &>/dev/null || missing+=("$pkg")
done

if (( ${#missing[@]} )); then
 echo "🔧 Installing missing build packages: ${missing[*]}"
 sudo apt-get update -qq
 sudo apt-get install -y --no-install-recommends "${missing[@]}"
fi

DIST_DIR="dist"

TAG="${TAG_NAME:-$(exit 1)}"
echo "🔖 Using tag: $TAG"

curl -s https://git.0xmax42.io/actions/deb-changelog-action/raw/branch/main/bootstrap.sh | bash -s -- \
 --version "v0" \
 --tag "$TAG" \
 --package_name "power-state-target" \
 --author_name "0xMax42" \
 --author_email "Mail@0xMax42.io"

PKG_NAME=$(dpkg-parsechangelog --show-field Source)
PKG_VERSION=$(dpkg-parsechangelog --show-field Version)

tar --exclude=debian -czf ../power-state-target_${PKG_VERSION}.orig.tar.gz .

echo "Building Debian package..."
dpkg-buildpackage -us -uc

mkdir -p "$DIST_DIR"
rm -rf "$DIST_DIR"/*

for file in ../${PKG_NAME}*_${PKG_VERSION}_*.deb \
 ../${PKG_NAME}*_${PKG_VERSION}_*.ddeb \
 ../${PKG_NAME}*_${PKG_VERSION}_*.buildinfo \
 ../${PKG_NAME}*_${PKG_VERSION}_*.changes \
 ../${PKG_NAME}*_${PKG_VERSION}.dsc \
 ../${PKG_NAME}*_${PKG_VERSION}.*.tar.* \
 ../${PKG_NAME}*_${PKG_VERSION}.tar.*; do
 [[ -f "$file" ]] && { mv "$file" "$DIST_DIR/"; echo "📦 Moved $(basename "$file") → $DIST_DIR/"; }
done

"dpkg-buildpackage" -T clean

echo "Build complete. Output in $DIST_DIR/"

Wichtige Punkte:

Das Script kümmert sich darum, dass alle benötigten Build-Pakete installiert sind (typische build-essential/devscripts/debhelper-Kette).
Die Versionierung und der Changelog werden über ein externes Script aus meiner deb-changelog-action automatisiert.
Alle entstehenden Artefakte werden in ein zentrales dist/-Verzeichnis verschoben, sodass der CI-Job sie leicht weiterverarbeiten kann.

TAG_NAME kommt dabei aus dem CI-Kontext – das ist die Git-Tag-Version, die zum Release gehört.

CI/CD: Vom Commit zum Debian-Paket in der eigenen Repo

Da das Projekt auf meiner privaten Gitea-Instanz liegt, laufen die CI-Pipelines ebenfalls dort. Es gibt zwei wesentliche Workflows:

release.yml – erstellt automatisch Releases und Changelogs.
build.yml – baut aus einem Release ein Debian-Paket und schiebt es in meine debrepo.

Auto-Changelog & Release

Der Release-Workflow triggert bei Pushes auf main:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


on:
 push:
 branches:
 - main

jobs:
 release:
 runs-on: ubuntu-latest
 steps:
 - uses: actions/checkout@v4
 with:
 fetch-depth: 0
 - name: Release
 uses: https://git.0xmax42.io/actions/auto-changelog-release-action@v1
 with:
 token: ${{ secrets.RELEASE_PUBLISH_TOKEN }}

Die auto-changelog-release-action kümmert sich darum, anhand der Commits (per git-cliff-Konfiguration) einen Changelog zu erzeugen, eine neue Version zu bestimmen, den Tag zu setzen und das Release im Gitea-Repository zu veröffentlichen.

Debian-Build und Push in `debrepo`

Sobald ein Release veröffentlicht ist, greift der zweite Workflow:

1
2
3


on:
 release:
 types: [published]

Der Job:

checkt den Quellcode aus,
ruft build.sh mit dem Tag aus dem Release auf,
macht ein Sparse Checkout meiner debrepo (nur power-state-target/),
kopiert die .deb, .dsc und Tarballs in dieses Verzeichnis,
commitet neue Artefakte auf den packages-Branch.

Damit landet jede neue Version von power-state-target automatisch in meiner eigenen APT-Repository-Struktur – und kann dann wie gewohnt über apt installiert werden.

`git-cliff`: Konsistente Changelogs mit Emojis

Da ich inzwischen sehr viel Wert auf saubere, konsistente Changelogs lege, kommt auch hier wieder git-cliff zum Einsatz. Die cliff.toml ist an meinen üblichen Stil angepasst – inklusive Emoji-Gruppierung:

🚀 Features
🐛 Bug Fixes
⚙️ Miscellaneous Tasks
usw.

Für power-state-target sieht der erste Release-Eintrag aktuell so aus:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


## [0.1.0] - 2025-12-02

### 🚀 Features

- Add systemd targets and service for dynamic power state switching - (...)

### 🐛 Bug Fixes

- *(config)* Correct systemd installation paths in debian install - (...)

### ⚙️ Miscellaneous Tasks

- *(ci)* Add build and release workflows for package automation - (...)
- *(build)* Add script for automated Debian package build - (...)
- Add git-cliff changelog configuration file - (...)
- *(debian)* Add packaging files for power-state-target - (...)

Nichts weltbewegendes, aber genau das ist der Punkt: saubere kleine Bausteine, die später zusammenspielen können.

Wie man `power-state-target` praktisch nutzt

Der eigentliche Mehrwert entsteht dadurch, dass andere Units auf die Targets reagieren können.

Ein paar typische Szenarien:

1. Dienste nur am Netz erlauben

Angenommen, du hast einen Dienst, der nur laufen soll, wenn das System am Netz hängt, z.B. ein Backup- oder Dedupe-Job.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


[Unit]
Description=Heavy IO Job (AC only)
Wants=power-ac.target
After=power-ac.target

[Service]
Type=oneshot
ExecStart=/usr/local/bin/heavy-job.sh

[Install]
WantedBy=multi-user.target
WantedBy=power-ac.target

Hier kann man zusätzlich mit ConditionPathExists, Timer-Units, StartLimit* usw. arbeiten – aber der Kern ist: „nur sinnvoll, wenn AC da ist“.

2. Reduzierter Modus auf Akku

Statt Dienste komplett abzuschalten, kann man auch alternative Konfigurationen fahren, z.B. einen „Light-Modus“ auf Akku und „Full-Modus“ am Netz. Man modelliert dann zwei Units, die jeweils an ein anderes Target gekoppelt sind.

3. Timer, die auf den Power-State hören

Timer-Units können ebenfalls indirekt über die Targets gesteuert werden, etwa indem nur der eigentliche Service an das passende Target gebunden wird.

Das Schöne: Alle Entscheidungen laufen über systemd, nicht über wilde Shell-Ifs überall im System.

Ausblick: Was man darauf noch aufbauen kann

power-state-target ist bewusst klein gehalten. Aber genau dadurch lässt es sich gut als Baustein für komplexere Setups verwenden:

Dynamisches Umschalten des CPU-Governors über separate Dienste.
Anpassung von Backup-Strategien (z.B. nur Metadaten auf Akku, Voll-Backups am Netz).
Steuerung von Container- oder VM-Last abhängig vom Power-State.
Integration in bestehende Tuning-Tools, indem diese die Targets nur noch als Signalquelle verwenden.

Ich mag solche Projekte, weil sie zwei Welten verbinden:

Auf der einen Seite: klassische Desktop-/Laptop-Welt mit Akku, UPower, grafischen Energiemanagern.
Auf der anderen: systemd- und serverartige Steuerung, bei der Zustände explizit modelliert sind.

power-state-target macht den Energiezustand zu einem ersten Bürger in systemd – und damit für alles Weitere komponierbar.

Fazit

Für sich genommen ist power-state-target ein kleines Projekt:

ein Shell-Skript,
zwei Targets,
ein Service,
etwas Debian-Packaging und CI.

Aber für mich ist es genau die Art von Infrastruktur, die ich mag:

klar umrissen,
gut integrierbar,
automatisiert gebaut und ausgeliefert,
und mit einem einfachen mentalen Modell: „Bin ich auf Akku oder am Netz?“ wird zu „Welches systemd-Target ist aktiv?“

Und ab da kann der Rest des Systems sich darauf verlassen.

Skidbuffer in Acton

Fri, 18 Jul 2025 19:46:03 +0000

Mit meinem Artikel “Minimaler Skidbuffer mit AXI-like Handshaking” habe ich bereits die Grundlage gelegt. Jetzt habe ich das ganze in Aktion zusammen mit meinen AXI-Pipeline Modulen auf einem älteren Spartan-3E FPGA getestet.

Ziel war es eine Art “Performance-Benchmark” zu erstellen, um die Effizienz des Skidbuffers in einer realen AXI-Pipeline zu demonstrieren. Dafür habe ich ein AXI-Pipeline Modul erstellt, welches dynamisch zwischen “Mit Skidbuffer” und “Ohne Skidbuffer” umschalten kann. Das ermöglicht es, die Auswirkungen des Skidbuffers auf die erreichbare Taktfrequenz zu messen.

AXI-Pipeline Module

Folgend der Code des AXI-Pipeline Moduls, das den Skidbuffer integriert:

 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
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118


library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
use ieee.math_real.all;

entity Pipeline_pb_Module is
 generic (
 --@ Number of pipeline stages
 G_PipelineStages : integer := 10;
 --@ Data width
 G_Width : integer := 32;
 --@ Register balancing attribute<br>
 --@ - "no" : No register balancing <br>
 --@ - "yes": Register balancing in both directions <br>
 --@ - "forward": Moves a set of FFs at the inputs of a LUT to a single FF at its output. <br>
 --@ - "backward": Moves a single FF at the output of a LUT to a set of FFs at its inputs.
 G_RegisterBalancing : string := "no";
 --@ Enable pipeline buffer
 --@ - true : Use pipeline buffer
 --@ - false : Direct connection (bypass)
 G_EnablePipelineBuffer : boolean := false
 );
 port (
 I_CLK : in std_logic;
 I_RST : in std_logic;
 I_CE : in std_logic;
 ---
 I_Data : in std_logic_vector(G_Width - 1 downto 0);
 I_Valid : in std_logic;
 O_Ready : out std_logic;
 ---
 O_Data : out std_logic_vector(G_Width - 1 downto 0);
 O_Valid : out std_logic;
 I_Ready : in std_logic
 );
end entity Pipeline_pb_Module;

architecture RTL of Pipeline_pb_Module is
 signal C_PipelineEnable : std_logic;
 signal C_PipelineBufferEnable : std_logic_vector(1 downto 0) := (others => '0');

 signal R_Valid : std_logic;
 signal R_Ready : std_logic;
 signal R_Data : std_logic_vector(G_Width - 1 downto 0);
 signal C_Data : std_logic_vector(G_Width - 1 downto 0);
begin
 INST_PipelineControllerIn : entity work.PipelineController
 generic map(
 G_PipelineStages => G_PipelineStages,
 G_ResetActiveAt => '1'
 )
 port map(
 I_CLK => I_CLK,
 I_RST => I_RST,
 I_CE => I_CE,
 O_Enable => C_PipelineEnable,
 I_Valid => I_Valid,
 O_Ready => O_Ready,
 O_Valid => R_Valid,
 I_Ready => R_Ready
 );

 INST_PipelineRegisterIn : entity work.PipelineRegister
 generic map(
 G_PipelineStages => G_PipelineStages,
 G_Width => G_Width,
 G_RegisterBalancing => G_RegisterBalancing
 )
 port map(
 I_CLK => I_CLK,
 I_Enable => C_PipelineEnable,
 I_Data => I_Data,
 O_Data => R_Data
 );

 ---------

 C_Data <= std_logic_vector(unsigned(R_Data) + 3); -- Example operation, can be replaced with actual logic

 ---------

 -- Pipeline Buffer Generation based on G_EnablePipelineBuffer
 GEN_PipelineBuffer : if G_EnablePipelineBuffer generate
 INST_PipelineBufferController : entity work.PipelineBufferController
 generic map(
 G_ResetActiveAt => '1'
 )
 port map(
 I_CLK => I_CLK,
 I_RST => I_RST,
 I_CE => I_CE,
 O_Enable => C_PipelineBufferEnable,
 I_Valid => R_Valid,
 O_Ready => R_Ready,
 O_Valid => O_Valid,
 I_Ready => I_Ready
 );

 INST_PipelineBuffer : entity work.PipelineBuffer
 generic map(
 G_Width => G_Width
 )
 port map(
 I_CLK => I_CLK,
 I_Enable => C_PipelineBufferEnable,
 I_Data => C_Data,
 O_Data => O_Data
 );
 end generate GEN_PipelineBuffer;

 -- Direct connection when pipeline buffer is disabled
 GEN_PassthroughWithoutBuffer : if not G_EnablePipelineBuffer generate
 O_Valid <= R_Valid;
 O_Data <= R_Data;
 R_Ready <= I_Ready;
 end generate GEN_PassthroughWithoutBuffer;

end architecture RTL;

Performance Benchmark

Das Modul habe ich dann in einem Performance-Benchmark (Synthesefähig) getestet, um die erreichbare Taktfrequenz zu messen. Dabei konnte ich eine maximale Taktfrequenz von 270 MHz erreichen - mit bis zu 250 Modulen in einer Pipeline.

Der Performance-Benchmark sieht wie folgt aus:

 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
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157


library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
use ieee.math_real.all;

entity Pipeline_pb is
 generic (
 --@ Number of pipeline stages inside each module
 G_PipelineStages : integer := 2;
 --@ Data width
 G_Width : integer := 8;
 --@ Register balancing attribute<br>
 --@ - "no" : No register balancing <br>
 --@ - "yes": Register balancing in both directions <br>
 --@ - "forward": Moves a set of FFs at the inputs of a LUT to a single FF at its output. <br>
 --@ - "backward": Moves a single FF at the output of a LUT to a set of FFs at its inputs.
 G_RegisterBalancing : string := "yes";
 --@ Enable pipeline buffer
 --@ - true : Use pipeline buffer
 --@ - false : Direct connection (bypass)
 G_EnablePipelineBuffer : boolean := true;
 --@ How many Pipeline modules shall be chained?
 G_PipelineModules : integer := 250;
 --@ Enable chip enable signal
 G_Enable_CE : boolean := false;
 --@ Enable reset signal
 G_Enable_RST : boolean := false
 );
 port (
 I_CLK : in std_logic;
 I_RST : in std_logic;
 I_CE : in std_logic;
 ---
 I_Data : in std_logic_vector(G_Width - 1 downto 0);
 I_Valid : in std_logic;
 O_Ready : out std_logic;
 ---
 O_Data : out std_logic_vector(G_Width - 1 downto 0);
 O_Valid : out std_logic;
 I_Ready : in std_logic
 );
end entity Pipeline_pb;

architecture RTL of Pipeline_pb is
 ---------------------------------------------------------------------------
 -- Attribute helpers
 ---------------------------------------------------------------------------
 attribute keep : string;
 attribute IOB : string;

 ---------------------------------------------------------------------------
 -- Bench‐wrapper FFs (synchronous IO)
 ---------------------------------------------------------------------------
 signal R_RST : std_logic := '0';
 signal R_CE : std_logic := '1';
 attribute keep of R_RST, R_CE : signal is "true";
 attribute IOB of R_RST, R_CE : signal is "false";

 signal R_DataIn : std_logic_vector(G_Width-1 downto 0);
 signal R_ValidIn : std_logic;
 attribute keep of R_DataIn, R_ValidIn : signal is "true";
 attribute IOB of R_DataIn, R_ValidIn : signal is "false";

 signal R_DataOut : std_logic_vector(G_Width-1 downto 0);
 signal R_ValidOut : std_logic;
 signal R_ReadyIn : std_logic;
 attribute keep of R_DataOut, R_ValidOut, R_ReadyIn : signal is "true";
 attribute IOB of R_DataOut, R_ValidOut, R_ReadyIn : signal is "false";

 ---------------------------------------------------------------------------
 -- Chaining arrays (sentinel element @0 and @G_PipelineModules)
 ---------------------------------------------------------------------------
 type T_DataArray is array(0 to G_PipelineModules) of std_logic_vector(G_Width-1 downto 0);

 signal S_Data : T_DataArray;
 signal S_Valid : std_logic_vector(0 to G_PipelineModules);
 signal S_Ready : std_logic_vector(0 to G_PipelineModules);

begin
 GEN_Enable_CE : if G_Enable_CE = true generate
 process(I_CLK)
 begin
 if rising_edge(I_CLK) then
 R_CE <= I_CE;
 end if;
 end process;
 end generate GEN_Enable_CE;

 GEN_Enable_RST : if G_Enable_RST = true generate
 process(I_CLK)
 begin
 if rising_edge(I_CLK) then
 R_RST <= I_RST;
 end if;
 end process;
 end generate GEN_Enable_RST;

 -----------------------------------------------------------------------
 -- Wrapper FFs: register all top‑level ports once for fair timing
 -----------------------------------------------------------------------
 BenchFF : process(I_CLK)
 begin
 if rising_edge(I_CLK) then
 --- Register inputs
 R_DataIn <= I_Data;
 R_ValidIn <= I_Valid;
 O_Ready <= S_Ready(0);
 --- Register outputs
 R_DataOut <= S_Data (G_PipelineModules);
 R_ValidOut <= S_Valid(G_PipelineModules);
 R_ReadyIn <= I_Ready;
 end if;
 end process;

 O_Data <= R_DataOut;
 O_Valid <= R_ValidOut;

 -----------------------------------------------------------------------
 -- Bind sentinel 0 with registered inputs
 -----------------------------------------------------------------------
 S_Data (0) <= R_DataIn;
 S_Valid(0) <= R_ValidIn;

 -----------------------------------------------------------------------
 -- Bind last sentinel with registered outputs
 -----------------------------------------------------------------------
 S_Ready(G_PipelineModules) <= R_ReadyIn;

 -----------------------------------------------------------------------
 -- Generate N pipeline modules in series
 -----------------------------------------------------------------------
 gen_modules : for i in 0 to G_PipelineModules-1 generate

 P_MOD : entity work.Pipeline_pb_Module
 generic map(
 G_PipelineStages => G_PipelineStages,
 G_Width => G_Width,
 G_RegisterBalancing => G_RegisterBalancing,
 G_EnablePipelineBuffer => G_EnablePipelineBuffer
 )
 port map(
 I_CLK => I_CLK,
 I_RST => R_RST,
 I_CE => R_CE,
 -- Up‑stream side
 I_Data => S_Data (i),
 I_Valid => S_Valid(i),
 O_Ready => S_Ready(i),
 -- Down‑stream side
 O_Data => S_Data (i+1),
 O_Valid => S_Valid(i+1),
 I_Ready => S_Ready(i+1)
 );

 end generate gen_modules;

end architecture RTL;

Ergebnisse

Durch die Auftrennung des Ready-Signals mittels Skidbuffer entfällt dessen Propagierung durch die gesamte Pipeline. Valid ist dabei sowieso vollkommen durch Register entkoppelt. Dadurch wird jedes Modul hinsichtlich des Timings unabhängig von den anderen Modulen. Unabhängig davon, wie viele Module in der Pipeline sind, bleibt die erreichbare Taktfrequenz konstant bei 270 MHz.

Das ganze ist auch in der hinsicht Testbar, dass ich den Skidbuffer in der AXI-Pipeline dynamisch aktivieren und deaktivieren kann. Dadurch kann ich die Auswirkungen des Skidbuffers auf die erreichbare Taktfrequenz messen. Ohne diesen sind bei 250 Modulen nicht mal mehr 100 MHz möglich.

HTTP Kernel v0.2.0 – Von dynamischem Dispatch zur vorkompilierten Pipeline

Tue, 27 May 2025 13:00:00 +0000

Mit v0.2.0 hat mein Deno‑basierter HTTP Kernel einen entscheidenden Schritt gemacht: Statt jede Middleware bei jedem Request dynamisch zu verkettet, wird die gesamte Kette jetzt einmalig kompiliert. Das reduziert Overhead, vereinfacht die Fehlerbehandlung – und macht das Routing spürbar schneller.

Ausgangslage

Die erste Generation des Kernels setzte auf einen rekursiven dispatch()‑Mechanismus:

 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


private async executePipeline(
 ctx: TContext,
 middleware: Middleware<TContext>[],
 handler: Handler<TContext>,
): Promise<Response> {
 const handleInternalError = (ctx: TContext, err?: unknown) =>
 this.cfg.httpErrorHandlers[HTTP_500_INTERNAL_SERVER_ERROR](
 ctx,
 normalizeError(err),
 );

 let lastIndex = -1;

 const dispatch = async (currentIndex: number): Promise<Response> => {
 if (currentIndex <= lastIndex) {
 throw new Error('Middleware called `next()` multiple times');
 }
 lastIndex = currentIndex;

 const isWithinMiddleware = currentIndex < middleware.length;
 const fn = isWithinMiddleware ? middleware[currentIndex] : handler;

 if (isWithinMiddleware) {
 if (!isMiddleware(fn)) {
 throw new Error('Expected middleware function, but received invalid value');
 }
 return await fn(ctx, () => dispatch(currentIndex + 1));
 }

 if (!isHandler(fn)) {
 throw new Error('Expected request handler, but received invalid value');
 }

 return await fn(ctx);
 };

 try {
 const response = await dispatch(0);
 return this.cfg.decorateResponse(response, ctx);
 } catch (e) {
 return handleInternalError(ctx, e);
 }
}

Dieser Ansatz war leicht zu verstehen, erzeugte aber pro Request mehrere Closures, Index‑Prüfungen und Typ‑Checks – alles Dinge, die bei hoher Parallelität unnötig Zeit kosten.

Der neue Ansatz

Beim Registrieren einer Route wird nun eine statisch verlinkte Funktionskette erzeugt. Ergebnis ist eine einzige Funktion runRoute(ctx), die alle Middlewares und den Handler inline ausführt.

 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


private compile(
 route: Omit<IInternalRoute<TContext>, 'runRoute' | 'matcher' | 'method'>,
): (ctx: TContext) => Promise<Response> {
 if (!isHandler<TContext>(route.handler)) {
 throw new TypeError('Route handler must be a function returning a Promise<Response>.');
 }
 let composed = route.handler;

 for (let i = route.middlewares.length - 1; i >= 0; i--) {
 if (!isMiddleware<TContext>(route.middlewares[i])) {
 throw new TypeError(`Middleware at index ${i} is not a valid function.`);
 }

 const current = route.middlewares[i];
 const next = composed;

 composed = async (ctx: TContext): Promise<Response> => {
 let called = false;
 return await current(ctx, async () => {
 if (called) {
 throw new Error(`next() called multiple times in middleware at index ${i}`);
 }
 called = true;
 return await next(ctx);
 });
 };
 }

 return composed;
}

Wichtig: Jede Middleware bekommt weiterhin ihr next() – jedoch kann dieses dank called‑Flag nur noch einmal aufgerufen werden, was Mehrfach‑Ausführungen zuverlässig verhindert.

Benchmarks

Gemessen mit 10 000 parallelen Requests auf einem Ryzen 7 8845HS:

Benchmark (parallel)	v0.1.0 (dynamisch)	v0.2.0 (vorkompiliert)	Gewinn
Simple Route	5.4 ms	2.1 ms	≈ 61 %
Complex Route	11.2 ms	7.9 ms	≈ 29 %

Bei Einzeln‑Requests liegen die Werte nahezu gleichauf – der Geschwindigkeitsvorteil zeigt sich vor allem unter hoher Last.

Fazit

Statisches Routing reduziert Overhead und steigert Durchsatz signifikant.
next()‑Fehler werden jetzt sofort erkannt.
API blieb kompatibel – Upgrade von 0.1.x auf 0.2.0 ist ohne Code‑Änderungen möglich.

Der Kernel läuft bereits performant und stabil in meinem build‑cache‑server – einem Deno‑basierten Build‑Cache für act; kompatiibel mit der Github Actions Cache API.

👉 Quellcode & Release‑Notes: https://github.com/0xMax42/http-kernel

Systemd-Timer per CLI erstellen – einfach, schnell, nervenschonend

Sat, 24 May 2025 21:30:00 +0000

Wer schon mal versucht hat, systemd-Timer von Hand zu schreiben, weiß: So richtig Spaß macht das nicht. Zwischen .service- und .timer-Dateien, Pfadangaben, und OnCalendar-Syntax kann man sich schnell vertun. Genau dafür habe ich mir ein kleines Tool gebaut: systemd-timer.

Was macht das Ding?

Ganz einfach: Du rufst ein CLI auf, gibst ein paar Parameter an, und das Tool schreibt dir die passenden .service- und .timer-Units – inklusive Logging, Abhängigkeiten und allem, was systemd eben braucht. Keine Vorlage kopieren, keine Tippfehler mehr, kein Nachdenken darüber, ob das jetzt WantedBy=timers.target heißen muss oder nicht.

Warum nicht einfach `cron`?

Klar, cron funktioniert. Aber systemd hat ein paar Vorteile:

Besseres Logging (auch in Datei)
Einfache Integration mit anderen Diensten (z. B. Netzwerkwarten)
Funktioniert auch pro Benutzer (ohne root-Rechte)
Alles bleibt in einer Sprache: systemd

Das CLI hilft dabei, die Einstiegshürde zu senken und trotzdem “richtig” mit systemd zu arbeiten.

Was kann `systemd-timer`?

.service + .timer-Dateien erstellen
--user-Timer (für Desktop- oder Container-Umgebungen)
Logging per --logfile
Standard-Optionen wie:
- --exec, --calendar, --after, --environment
- --description, --output, --dry-run
CLI basiert auf Cliffy, getippt mit Deno
Plattformunabhängige Installation per Shell-Skript

Ein Beispiel, das du sofort nutzen kannst

1
2
3
4
5
6


systemd-timer create \
 --exec "/usr/local/bin/backup.sh" \
 --calendar "Mon..Fri 02:00" \
 --description "Backup Job" \
 --user \
 --logfile "/var/log/backup.log"

Ergebnis:

~/.config/systemd/user/backup.service
~/.config/systemd/user/backup.timer

Aktivieren:

1
2


systemctl --user daemon-reload
systemctl --user enable --now backup.timer

Installation: Ein Einzeiler

1

curl -fsSL https://git.0xmax42.io/maxp/systemd-timer/raw/branch/main/scripts/install.sh | sh

Das Skript erkennt automatisch deine Architektur (amd64/arm64), lädt die passende Binary und prüft sie mit SHA256. Und ja, du kannst dir den Code vorher anschauen, bevor du ihn durch die Leitung jagst.

Entwicklung & Test

Das Tool ist komplett mit TypeScript/Deno geschrieben, ordentlich typisiert und testgetrieben. Alles Wichtige ist modular aufgebaut, damit man es auch als Bibliothek verwenden könnte.

Tests laufen einfach per:

1

deno task test

Fazit

systemd-timer ist kein Monster-Tool mit 1000 Optionen – sondern genau das, was man sich wünscht, wenn man öfter mal einfache Tasks zeitgesteuert per systemd laufen lassen will, ohne sich jedes Mal die Finger wundzuschreiben. Es richtet sich an Leute, die lieber deklarativ als improvisiert arbeiten.

Quellcode, Releases und alles Weitere findest du hier: 👉 git.0xmax42.io/maxp/systemd-timer

Pydepp: Python Trifft Fpga

Thu, 24 Apr 2025 09:16:09 +0000

Ich habe ein neues Open-Source-Projekt veröffentlicht: PyDEPP – eine Python-Bibliothek für die Kommunikation mit Digilent-FPGA-Boards über das DEPP-Protokoll. Ziel war es, eine moderne, objektorientierte Schnittstelle für den Zugriff auf Register, Datenströme und Debug-Funktionen zu schaffen, die direkt auf dem Adept SDK von Digilent aufbaut.

Warum das Ganze?

Digilent stellt mit dem DEPP-Protokoll eine leistungsfähige, aber recht sperrig zu bedienende Schnittstelle bereit. Wer schon einmal versucht hat, mit den C-APIs zu arbeiten, weiß: Das geht eleganter. PyDEPP abstrahiert diese Komplexität und bringt den Zugriff auf Register und Streams auf Python-Niveau – inklusive Kontextmanagement via with, flexibler Timeout-Steuerung und Debug-Dumps.

Highlights:

get_reg() / set_reg() – einfacher Registerzugriff
put_stream() / get_stream() – performante Datenübertragung
Anpassbare Timeouts
Kontext-Manager für sauberes Ressourcen-Handling
Register-Dumps zur Fehlersuche

Die Bibliothek ist vollständig quelloffen und unter MIT-Lizenz verfügbar. Wer auf Python-basierte Hardwarekommunikation setzt, wird hier fündig.

Getestet mit:

Digilent Nexys2 FPGA-Board
Python 3.11 unter Debian
Shared Libraries: libdmgr.so, libdepp.so aus dem Adept SDK

➡️ Wer sich für Embedded-Entwicklung mit Python interessiert oder einfach die DEPP-Schnittstelle besser nutzen möchte, ist herzlich eingeladen, mitzuwirken.

Pipeline Optimieren

Tue, 22 Apr 2025 09:32:40 +0000

Heute widme ich mich der Optimierung einer kleinen Pipeline, die ich für ein Projekt erstellt habe. Die Pipeline ist dafür verantwortlich, den Adress-Offset eines Sprites zu berechnen und zu prüfen, ob dieses in der aktuell angeforderten Zeile sichtbar ist.

Bisher setze ich darauf, dass das Register Rebalancing seine Arbeit erledigt. Dies funktioniert auch, doch verbleiben klarerweise noch einige Optimierungsmöglichkeiten.

Zum Einstieg erst mal den aktuellen Code:

 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
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163


library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
use ieee.math_real.all;
use work.SpriteRom.all;

entity VerticalSpritePipeline is
 generic (
 --@ Width of the Y position (Line) register
 G_Y_Width : integer := 10;
 --@ The height of the sprite in pixels
 G_Sprite_Height : integer := 16;
 --@ Width of the sprite offset (Line address) register
 G_Offset_Width : integer := 8;
 --@ The pipeline stages for the calculating pipeline (multiply by 2 for the the latency of the pipeline)
 G_PipelineStages : integer := 2
 );
 port (
 --@ Clock signal; (**Rising edge** triggered)
 I_CLK : in std_logic := '0';
 --@ Clock enable signal (**Active high**)
 I_CE : in std_logic := '1';

 --@ @virtualbus VSpritePipeline-OP @dir In Vertical sprite pipeline operation interfacee
 --@ AXI like ready; (**Synchronous**, **Active high**)
 O_VSpritePipeline_OP_Ready : out std_logic := '0';
 --@ AXI like valid; (**Synchronous**, **Active high**)
 I_VSpritePipeline_OP_Valid : in std_logic := '0';
 --@ The line to check if the sprite is in the line visible.
 I_VSpritePipeline_OP_Y_Request : in std_logic_vector(G_Y_Width - 1 downto 0) := (others => '0');
 --@ The sprite Y position to check if the sprite is in the line visible.
 I_VSpritePipeline_OP_Y_Sprite : in std_logic_vector(G_Y_Width - 1 downto 0) := (others => '0');
 --@ @end

 --@ @virtualbus VSpritePipeline-Result @dir Out Vertical sprite pipeline result interface
 --@ AXI like ready; (**Synchronous**, **Active high**)
 I_VSpritePipeline_Ready : in std_logic := '0';
 --@ AXI like valid; (**Synchronous**, **Active high**)
 O_VSpritePipeline_Valid : out std_logic := '0';
 --@ Indicates if the sprite is visible in the line.
 O_VSpritePipeline_IsVisible : out std_logic := '0';
 --@ The calculated offset address of the sprite.
 O_VSpritePipeline_Offset : out std_logic_vector(G_Offset_Width - 1 downto 0) := (others => '0')
 --@ @end
 );
end entity VerticalSpritePipeline;

architecture Rtl of VerticalSpritePipeline is
 --@ Line to check if the sprite is in the line visible
 signal R_Y_Request : std_logic_vector(G_Y_Width - 1 downto 0) := (others => '0');
 --@ The sprite Y position to check if the sprite is in the line visible
 signal R_Y_Sprite : std_logic_vector(G_Y_Width - 1 downto 0) := (others => '0');

 --@ Calculated visibility signal
 signal C_IsVisible : std_logic := '0';
 --@ The calculated offset address of the sprite
 signal C_Offset : std_logic_vector(G_Offset_Width - 1 downto 0) := (others => '0');

 --@ Pipeline enable signal
 signal S_CalculatingPipeline_Enable : std_logic := '0';
begin

 --@ Pipeline controller for the calculating pipeline
 I_CalculatingPipelineCtrl : entity work.PipelineController
 generic map(
 G_PipelineStages => G_PipelineStages * 2
 )
 port map(
 I_CLK => I_CLK,
 I_CE => I_CE,
 O_Enable => S_CalculatingPipeline_Enable,
 I_Valid => I_VSpritePipeline_OP_Valid,
 O_Ready => O_VSpritePipeline_OP_Ready,
 O_Valid => O_VSpritePipeline_Valid,
 I_Ready => I_VSpritePipeline_Ready
 );

 --@ Input register for the Y position of the sprite
 I_Y_InputRegister : entity work.PipelineRegister
 generic map(
 G_PipelineStages => G_PipelineStages,
 G_Width => G_Y_Width,
 G_RegisterBalancing => "forward"
 )
 port map(
 I_CLK => I_CLK,
 I_Enable => S_CalculatingPipeline_Enable,
 I_Data => I_VSpritePipeline_OP_Y_Sprite,
 O_Data => R_Y_Sprite
 );

 --@ Input register for the line to check if the sprite is in the line visible
 I_YToCheck_InputRegister : entity work.PipelineRegister
 generic map(
 G_PipelineStages => G_PipelineStages,
 G_Width => G_Y_Width,
 G_RegisterBalancing => "forward"
 )
 port map(
 I_CLK => I_CLK,
 I_Enable => S_CalculatingPipeline_Enable,
 I_Data => I_VSpritePipeline_OP_Y_Request,
 O_Data => R_Y_Request
 );

 --@ Combinatory process to calculate the visibility and offset of the sprite.
 P_CalculateVisibility : process (R_Y_Sprite, R_Y_Request)
 variable V_Y_Sprite : unsigned(R_Y_Sprite'range);
 variable V_Y_Request : unsigned(R_Y_Request'range);
 variable V_SpriteYBottom : unsigned(R_Y_Sprite'range);
 variable V_OffsetLine : integer;
 variable V_Offset : unsigned(C_Offset'range);
 begin
 V_Y_Sprite := unsigned(R_Y_Sprite);
 V_Y_Request := unsigned(R_Y_Request);
 V_SpriteYBottom := V_Y_Sprite + to_unsigned(G_Sprite_Height - 1, R_Y_Sprite'length);

 if V_Y_Request >= V_Y_Sprite and
 V_Y_Request <= V_SpriteYBottom then
 C_IsVisible <= '1';
 else
 C_IsVisible <= '0';
 end if;

 V_OffsetLine := to_integer(V_Y_Request - V_Y_Sprite);
 -- pragma translate_off
 if V_OffsetLine < 0 or V_OffsetLine >= K_SPRITE_ROW_OFFSETS'length then
 V_OffsetLine := 0;
 end if;
 -- pragma translate_on

 V_Offset := to_unsigned(K_SPRITE_ROW_OFFSETS(V_OffsetLine), C_Offset'length);
 C_Offset <= std_logic_vector(V_Offset);
 end process;

--@ Output register for the visibility of the sprite
 I_IsVisible_OutputRegister : entity work.PipelineRegister
 generic map(
 G_PipelineStages => G_PipelineStages,
 G_Width => 1,
 G_RegisterBalancing => "backward"
 )
 port map(
 I_CLK => I_CLK,
 I_Enable => S_CalculatingPipeline_Enable,
 I_Data(0) => C_IsVisible,
 O_Data(0) => O_VSpritePipeline_IsVisible
 );

--@ Output register for the offset of the sprite
 I_Offset_OutputRegister : entity work.PipelineRegister
 generic map(
 G_PipelineStages => G_PipelineStages,
 G_Width => G_Offset_Width,
 G_RegisterBalancing => "backward"
 )
 port map(
 I_CLK => I_CLK,
 I_Enable => S_CalculatingPipeline_Enable,
 I_Data => C_Offset,
 O_Data => O_VSpritePipeline_Offset
 );
end architecture;

Wie man erkennt, wird das Aufteilen der Berechnung aktuell vollständig der Synthese überlassen. Nun geht es darum, eine performante Aufteilung der Berechnung zu finden.

In dem Berechnungsprozess finden wir zwei relevante Berechnungen und einen Vergleich:

Berechnung der unteren Sprite-Grenze

1

V_SpriteYBottom := V_SpriteY + to_unsigned(G_Sprite_Height - 1, R_Y_Sprite'length);

Vergleich der Y-Position mit der Sprite-Grenze (Sichtbarkeitsprüfung)

1
2


if V_YToCheck >= V_SpriteY and
 V_YToCheck <= V_SpriteYBottom then

Berechnung des Address-Offsets

1

V_OffsetLine := to_integer(V_YToCheck - V_SpriteY);

Da die Operationen Nr. 2 und 3 auf das Ergebnis der ersten Berechnung angewiesen sind, werden wir diese als Erstes in einer getrennten Stufe durchführen.

Als Vorarbeit dazu arbeiten wir unsere Register zuerst einmal um. Zum einen passen wir die Benennung an und zum anderen definieren wir die Anzahl der Stufen nicht mehr dynamisch, sondern statisch.

Hierzu passen wir den Pipeline-Controller an:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


 INST_VSpritePipeline_Ctrl : entity work.PipelineController
 generic map(
 G_PipelineStages => 3 -- TODO
 )
 port map(
 I_CLK => I_CLK,
 I_CE => I_CE,
 O_Enable => O_VSpritePipelineCtrl_Enable,
 I_Valid => I_VSpritePipeline_OP_Valid,
 O_Ready => O_VSpritePipeline_OP_Ready,
 O_Valid => O_VSpritePipeline_Valid,
 I_Ready => I_VSpritePipeline_Ready
 );

Und die beiden Eingangsregister, welche auf eine Stufe verkleinert wurden:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


 INST0_VSpritePipeline_Y_Sprite : entity work.PipelineRegister
 generic map(
 G_Width => G_Y_Width
 )
 port map(
 I_CLK => I_CLK,
 I_Enable => O_VSpritePipelineCtrl_Enable,
 I_Data => I_VSpritePipeline_OP_Y_Sprite,
 O_Data => R0_Y_Sprite
 );

 INST0_VSpritePipeline_Y_Request : entity work.PipelineRegister
 generic map(
 G_Width => G_Y_Width
 )
 port map(
 I_CLK => I_CLK,
 I_Enable => O_VSpritePipelineCtrl_Enable,
 I_Data => I_VSpritePipeline_OP_Y_Request,
 O_Data => R0_Y_Request
 );

Wir führen ein neues kombinatorisches und ein registriertes Signal C_Y_Bottom_Sprite bzw. R_Y_Bottom_Sprite ein, auf welches die Berechnung Nr. 1 geleitet wird. Die Berechnung wird gleichzeitig als concurrent signal assignment durchgeführt. Dies hat den Vorteil, dass wir die Berechnung nicht in einen Prozess packen müssen.

1
2
3
4


 --@ Calculate the bottom Y position of the sprite
 C_Y_Bottom_Sprite <= std_logic_vector(
 unsigned(R_Y_Sprite) + to_unsigned(G_Sprite_Height - 1, G_Y_Width)
 );

Weiter benötigen wir ein neues Register für diese Berechnung:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


 INST_VSpritePipeline_Y_Bottom_Sprite : entity work.PipelineRegister
 generic map(
 G_Width => G_Y_Width
 )
 port map(
 I_CLK => I_CLK,
 I_Enable => O_VSpritePipelineCtrl_Enable,
 I_Data => C_Y_Bottom_Sprite,
 O_Data => R_Y_Bottom_Sprite
 )

Weiterhin brauchen müssen wir die Grundlagen unserer Berechnung ebenfalls eine Stufe weiter mitnehmen. Hierfür erstellen wir uns weitere Signale und erneut zwei Register:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


 INST1_VSpritePipeline_Y_Sprite : entity work.PipelineRegister
 generic map(
 G_Width => G_Y_Width
 )
 port map(
 I_CLK => I_CLK,
 I_Enable => O_VSpritePipelineCtrl_Enable,
 I_Data => R0_Y_Sprite,
 O_Data => R1_Y_Sprite
 );

 INST1_VSpritePipeline_Y_Request : entity work.PipelineRegister
 generic map(
 G_Width => G_Y_Width
 )
 port map(
 I_CLK => I_CLK,
 I_Enable => O_VSpritePipelineCtrl_Enable,
 I_Data => R0_Y_Request,
 O_Data => R1_Y_Request
 );

In der nächsten Stufe haben wir nun die registrierten Signale R1_Y_Sprite, R1_Y_Request und R_Y_Bottom_Sprite zur Verfügung. Die Operationen 2 und 3 aus unserer Liste können parallel durchgeführt werden. Hierzu verwenden wir die schon vorhandenen Signale C_IsVisible und C_Offset:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


 --@ Calculate the visibility of the sprite
 C_IsVisible <= '1' when (
 (unsigned(R1_Y_Request) >= unsigned(R1_Y_Sprite)) and
 (unsigned(R1_Y_Request) <= unsigned(R_Y_Bottom_Sprite))
 ) else '0';

 --@ Calculate the offset address of the sprite
 C_Offset <= std_logic_vector(
 to_unsigned(
 K_SPRITE_ROW_OFFSETS(to_integer(unsigned(R1_Y_Request) - unsigned(R1_Y_Sprite))),
 C_Offset'length)
 );

Diese beiden Werte sind nun unsere Ergebnisse der Pipeline und müssen letztmalig im Ausgangsregister gespeichert werden. Hierzu verwenden wir die schon vorhandenen Register und passen sie nur leicht an:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


 INST_IsVisible_OutputRegister : entity work.PipelineRegister
 generic map(
 G_Width => 1
 )
 port map(
 I_CLK => I_CLK,
 I_Enable => O_VSpritePipelineCtrl_Enable,
 I_Data(0) => C_IsVisible,
 O_Data(0) => O_VSpritePipeline_IsVisible
 );

 INST_Offset_OutputRegister : entity work.PipelineRegister
 generic map(
 G_Width => G_Offset_Width
 )
 port map(
 I_CLK => I_CLK,
 I_Enable => O_VSpritePipelineCtrl_Enable,
 I_Data => C_Offset,
 O_Data => O_VSpritePipeline_Offset
 );

Zum Schluss müssten wir nun noch G_PipelineStages auf 3 setzen. Vorausschauend habe ich diesen Wert oben aber schon gesetzt, sodass wir hier nichts mehr anpassen müssen und das ``– TODO` entfernen können.

Der Code sieht nun wie folgt aus:

 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
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176


library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
use ieee.math_real.all;
use work.SpriteRom.all;

entity VerticalSpritePipeline is
 generic (
 --@ Width of the Y position (Line) register
 G_Y_Width : integer := 10;
 --@ The height of the sprite in pixels
 G_Sprite_Height : integer := 16;
 --@ Width of the sprite offset (Line address) register
 G_Offset_Width : integer := 8;
 --@ The pipeline stages for the calculating pipeline (multiply by 2 for the the latency of the pipeline)
 G_PipelineStages : integer := 2
 );
 port (
 --@ Clock signal; (**Rising edge** triggered)
 I_CLK : in std_logic := '0';
 --@ Clock enable signal (**Active high**)
 I_CE : in std_logic := '1';

 --@ @virtualbus VSpritePipeline-OP @dir In Vertical sprite pipeline operation interfacee
 --@ AXI like ready; (**Synchronous**, **Active high**)
 O_VSpritePipeline_OP_Ready : out std_logic := '0';
 --@ AXI like valid; (**Synchronous**, **Active high**)
 I_VSpritePipeline_OP_Valid : in std_logic := '0';
 --@ The line to check if the sprite is in the line visible.
 I_VSpritePipeline_OP_Y_Request : in std_logic_vector(G_Y_Width - 1 downto 0) := (others => '0');
 --@ The sprite Y position to check if the sprite is in the line visible.
 I_VSpritePipeline_OP_Y_Sprite : in std_logic_vector(G_Y_Width - 1 downto 0) := (others => '0');
 --@ @end

 --@ @virtualbus VSpritePipeline-Result @dir Out Vertical sprite pipeline result interface
 --@ AXI like ready; (**Synchronous**, **Active high**)
 I_VSpritePipeline_Ready : in std_logic := '0';
 --@ AXI like valid; (**Synchronous**, **Active high**)
 O_VSpritePipeline_Valid : out std_logic := '0';
 --@ Indicates if the sprite is visible in the line.
 O_VSpritePipeline_IsVisible : out std_logic := '0';
 --@ The calculated offset address of the sprite.
 O_VSpritePipeline_Offset : out std_logic_vector(G_Offset_Width - 1 downto 0) := (others => '0')
 --@ @end
 );
end entity VerticalSpritePipeline;

architecture Rtl of VerticalSpritePipeline is
 --@ Line to check if the sprite is in the line visible
 signal R0_Y_Request : std_logic_vector(G_Y_Width - 1 downto 0) := (others => '0');
 signal R1_Y_Request : std_logic_vector(G_Y_Width - 1 downto 0) := (others => '0');
 --@ The sprite Y position to check if the sprite is in the line visible
 signal R0_Y_Sprite : std_logic_vector(G_Y_Width - 1 downto 0) := (others => '0');
 signal R1_Y_Sprite : std_logic_vector(G_Y_Width - 1 downto 0) := (others => '0');

 --@ The bottom Y position of the sprite
 signal C_Y_Bottom_Sprite : std_logic_vector(G_Y_Width - 1 downto 0) := (others => '0');
 signal R_Y_Bottom_Sprite : std_logic_vector(G_Y_Width - 1 downto 0) := (others => '0');

 --@ Calculated visibility signal
 signal C_IsVisible : std_logic := '0';
 --@ The calculated offset address of the sprite
 signal C_Offset : std_logic_vector(G_Offset_Width - 1 downto 0) := (others => '0');

 --@ Pipeline enable signal
 signal O_VSpritePipeline_Ctrl_Enable : std_logic := '0';
begin
 INST_VSpritePipeline_Ctrl : entity work.PipelineController
 generic map(
 G_PipelineStages => 3
 )
 port map(
 I_CLK => I_CLK,
 I_CE => I_CE,
 O_Enable => O_VSpritePipeline_Ctrl_Enable,
 I_Valid => I_VSpritePipeline_OP_Valid,
 O_Ready => O_VSpritePipeline_OP_Ready,
 O_Valid => O_VSpritePipeline_Valid,
 I_Ready => I_VSpritePipeline_Ready
 );

 INST0_VSpritePipeline_Y_Sprite : entity work.PipelineRegister
 generic map(
 G_Width => G_Y_Width
 )
 port map(
 I_CLK => I_CLK,
 I_Enable => O_VSpritePipeline_Ctrl_Enable,
 I_Data => I_VSpritePipeline_OP_Y_Sprite,
 O_Data => R0_Y_Sprite
 );

 INST0_VSpritePipeline_Y_Request : entity work.PipelineRegister
 generic map(
 G_Width => G_Y_Width
 )
 port map(
 I_CLK => I_CLK,
 I_Enable => O_VSpritePipeline_Ctrl_Enable,
 I_Data => I_VSpritePipeline_OP_Y_Request,
 O_Data => R0_Y_Request
 );

 --@ Calculate the bottom Y position of the sprite
 C_Y_Bottom_Sprite <= std_logic_vector(
 unsigned(R0_Y_Sprite) + to_unsigned(G_Sprite_Height - 1, G_Y_Width)
 );

 INST_VSpritePipeline_Y_Bottom_Sprite : entity work.PipelineRegister
 generic map(
 G_Width => G_Y_Width
 )
 port map(
 I_CLK => I_CLK,
 I_Enable => O_VSpritePipeline_Ctrl_Enable,
 I_Data => C_Y_Bottom_Sprite,
 O_Data => R_Y_Bottom_Sprite
 );

 INST1_VSpritePipeline_Y_Sprite : entity work.PipelineRegister
 generic map(
 G_Width => G_Y_Width
 )
 port map(
 I_CLK => I_CLK,
 I_Enable => O_VSpritePipeline_Ctrl_Enable,
 I_Data => R0_Y_Sprite,
 O_Data => R1_Y_Sprite
 );

 INST1_VSpritePipeline_Y_Request : entity work.PipelineRegister
 generic map(
 G_Width => G_Y_Width
 )
 port map(
 I_CLK => I_CLK,
 I_Enable => O_VSpritePipeline_Ctrl_Enable,
 I_Data => R0_Y_Request,
 O_Data => R1_Y_Request
 );

 --@ Calculate the visibility of the sprite
 C_IsVisible <= '1' when (
 (unsigned(R1_Y_Request) >= unsigned(R1_Y_Sprite)) and
 (unsigned(R1_Y_Request) <= unsigned(R_Y_Bottom_Sprite))
 ) else '0';

 --@ Calculate the offset address of the sprite
 C_Offset <= std_logic_vector(
 to_unsigned(
 K_SPRITE_ROW_OFFSETS(to_integer(unsigned(R1_Y_Request) - unsigned(R1_Y_Sprite))),
 C_Offset'length)
 );

 INST_IsVisible_OutputRegister : entity work.PipelineRegister
 generic map(
 G_Width => 1
 )
 port map(
 I_CLK => I_CLK,
 I_Enable => O_VSpritePipeline_Ctrl_Enable,
 I_Data(0) => C_IsVisible,
 O_Data(0) => O_VSpritePipeline_IsVisible
 );

 INST_Offset_OutputRegister : entity work.PipelineRegister
 generic map(
 G_Width => G_Offset_Width
 )
 port map(
 I_CLK => I_CLK,
 I_Enable => O_VSpritePipeline_Ctrl_Enable,
 I_Data => C_Offset,
 O_Data => O_VSpritePipeline_Offset
 );
end architecture;

Im Vergleich mit der vorherigen Version haben wir nun eine vorgelagerte Berechnung (1. Stufe) und die Berechnung der Sichtbarkeit und des Offsets (2. Stufe) parallelisiert. Dies sollte uns eine kleine Verbesserung hinsichtlich der Performance bringen. In meinem gesamten Design wurde damit die Pipeline vom Flaschenhals zum hinsichtlich des Timings unbeachtlichen Teil.

Innerhalb der Synthese (Prä Place&Route) haben wir eine erhebliche Verbesserung auf dem eingesetzte Spartan 3 erreicht:

Vorher: Minimum period: 5.739ns (Maximum Frequency: 174.246MHz)
Nachher: Minimum period: 4.857ns (Maximum Frequency: 205.888MHz)

Daher haben wir die Pipeline beschleunigt und den Code vereinfacht.

Minimaler Skidbuffer mit AXI-like Handshaking

Sat, 19 Apr 2025 19:14:03 +0000

In weniger als einer Stunde entstanden:
Ein kompakter Skidbuffer, der nur das ready-Signal entkoppelt – ohne zusätzliche Latenz.

Hintergrund ist hier die Verwendung von AXI-like Handshaking und die Notwendigkeit, das ready-Signal zu entkoppeln, um die Datenverarbeitung zu optimieren. In den von mir genutzten Desisngs ist das ready-Signal oft der Flaschenhals, da es in der Regel durch mehrere Pipelines hindurch propagiert werden muss. Ein Skidbuffer kann hier helfen, die Latenz zu reduzieren und die Datenverarbeitung zu optimieren. Dagegen wird das valid-Signal nicht entkoppelt, da es durch jede Pipeline selbst entkoppelt wird.

Das Design nutzt ein einfaches Prinzip:

Wenn ready = '1', wird direkt durchgeschaltet (MUX = 0)
Wenn ready = '0', wird ein Zwischenspeicher aktiviert (MUX = 1)
valid bleibt entweder durchgeschliffen oder stammt aus dem Puffer

Das System erfüllt vollständiges AXI-like Handshaking
und wurde bei zufällig verzögertem Up- und Downstream erfolgreich getestet.

Ressourcenbedarf (nach Synthese, Xilinx Spartan-3):

1 Flipflop
4 LUTs
0 zusätzliche Latenz

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


--@ Set mux to buffered mode if data is available in the buffer.
C_MUX <= R_IsBuffered;
--@ Enable the buffer register if not buffered and chip enable is high.
C_Enable <= I_CE and not R_IsBuffered;
--@ Set the ready signal to high if not buffered.
O_Ready <= not R_IsBuffered;
--@ Set the valid signal to high if data is available in the buffer or if data is valid.
O_Valid <= R_IsBuffered or I_Valid;

process (I_CLK)
begin
 if rising_edge(I_CLK) then
 if I_RST = G_ResetActiveAt then
 R_IsBuffered <= '0';
 elsif I_CE = '1' then
 if R_IsBuffered = '0' and I_Valid = '1' then
 R_IsBuffered <= '1';
 elsif I_Ready = '1' and (R_IsBuffered or I_Valid) = '1' then
 R_IsBuffered <= '0';
 end if;
 end if;
 end if;
end process;

Die Architektur eignet sich besonders für tiefe Pipeline-Systeme mit Timing-Engpässen auf ready.

Kein Overhead – nur Datenfluss.

Devlog on 0xMax42 - Flatfile-Purist. Autodidakt. Systemdenker.

power-state-target: Wie ich den Energiezustand meines Laptops in systemd modelliert habe

Problem: Der Energiezustand als „unsichtbare“ Information

Ziel: systemd als Single Source of Truth für den Power-State

Die Targets: power-ac und power-battery

Der Listener: power-state-listener.service

Die eigentliche Logik: /usr/libexec/update-power-state

Integration in Debian: Paket power-state-target

Automatisierter Debian-Build mit build.sh

CI/CD: Vom Commit zum Debian-Paket in der eigenen Repo

Auto-Changelog & Release

Debian-Build und Push in debrepo

git-cliff: Konsistente Changelogs mit Emojis

Wie man power-state-target praktisch nutzt

1. Dienste nur am Netz erlauben

2. Reduzierter Modus auf Akku

3. Timer, die auf den Power-State hören

Ausblick: Was man darauf noch aufbauen kann

Fazit

Skidbuffer in Acton

AXI-Pipeline Module

Performance Benchmark

Ergebnisse

HTTP Kernel v0.2.0 – Von dynamischem Dispatch zur vorkompilierten Pipeline

Ausgangslage

Der neue Ansatz

Benchmarks

Fazit

Systemd-Timer per CLI erstellen – einfach, schnell, nervenschonend

Was macht das Ding?

Warum nicht einfach cron?

Was kann systemd-timer?

Ein Beispiel, das du sofort nutzen kannst

Installation: Ein Einzeiler

Entwicklung & Test

Fazit

Pydepp: Python Trifft Fpga

Pipeline Optimieren

Minimaler Skidbuffer mit AXI-like Handshaking

Die Targets: `power-ac` und `power-battery`

Der Listener: `power-state-listener.service`

Die eigentliche Logik: `/usr/libexec/update-power-state`

Integration in Debian: Paket `power-state-target`

Automatisierter Debian-Build mit `build.sh`

Debian-Build und Push in `debrepo`

`git-cliff`: Konsistente Changelogs mit Emojis

Wie man `power-state-target` praktisch nutzt

Warum nicht einfach `cron`?

Was kann `systemd-timer`?