Hardware-enforced temporal authority for autonomous AI and robotics on AMD Kria KR260

Community Corner Showcase
,
1

We are implementing and validating an FPGA-based temporal authority architecture for autonomous AI and robotic systems on the AMD Kria KR260.

The core invariant is that the governed system cannot authorize, extend, restore, or enlarge its own operational authority. The design uses time-bounded authorization, fresh reauthorization requirements, persistence controls, and hardware gating to enforce that boundary.

Current KR260 results include successful synthesis, implementation, timing closure, methodology checks, bitstream generation, and device programming. We are now completing board-level runtime acceptance testing and Linux/Kria integration diagnostics.

The project is intended as a practical substrate for safety-critical autonomous systems where runtime authority must remain externally governed and non-self-renewable.

We would welcome AMD community feedback on the KR260 integration path, Linux/device-tree considerations, and best practices for packaging the final demonstrator.

OCUP_3
OCUP_31024×1536 561 KB

Vivado_1
Vivado_11280×720 191 KB

20260907_211834
20260907_2118341920×2560 807 KB

2

Awesome work on this - really impressive progress.
Keep the updates coming, and make sure to share this on our Discord too if you haven’t already!

1 Like
3

This project is valuable because it enforces in hardware the principle that “the governed system cannot renew its own authority.” I would be interested to know how you plan to define the final trust boundary: which of Linux root, xmutil/dfx-mgrd, PCAP, and JTAG are trusted? The KR260 supports dynamically loading bitstreams and DT overlays from Linux (UG1630). If Linux is also part of the governed system, it would be helpful to clarify what prevents it from replacing the authority-gating logic or renewing authority through writable registers.

For the demonstrator package, I suggest including the .bit.bin, .dtbo, and shell.json files, together with exact version information and hashes. The DTBO should describe only the hardware resources, while authorization decisions and freshness validation remain in the PL or an independent trusted controller.

1 Like
4

Thank you, Hongwei. This is exactly the trust-boundary question the KR260 demonstrator must make explicit.

For the current development-stage implementation, Linux root, xmutil/dfx-mgrd, PCAP-mediated reconfiguration, and JTAG are not yet being claimed as outside the trusted computing base. The present milestone is intended to demonstrate the temporal-authority mechanics in PL: exact lease expiration, fresh external quorum material for any subsequent authority, replay and stale-context rejection, and fail-closed capability gating.

The hardened target is stricter: Linux and the governed workload must be treated as potentially compromised and unable to replace, bypass, or rewrite the authority-gating logic. That requires the gate and freshness-validation path to remain within an authenticated static hardware region—or an independent trusted controller—while any permitted dynamic reconfiguration is confined to regions that cannot alter the gate, its trusted state, or the governed physical output path. PCAP/reconfiguration authority and JTAG access must likewise be constrained by the secure deployment configuration.

We will make that distinction explicit in the demonstrator documentation and acceptance tests, including attempts by privileged Linux to rewrite authorization registers, reload the application, substitute a bitstream or overlay, and recover authority after warm reboot, cold reboot, or reconfiguration.

Agreed as well on the reproducibility package. We plan to publish the exact .bit.bin, .dtbo, and shell.json artifacts, tool and platform versions, cryptographic hashes, and measured test results. The DT overlay will describe hardware resources only; authority decisions, freshness validation, and self-extension denial will remain outside Linux control.

Thank you for identifying the right standard for the final trust boundary.

5

Thank you nirth_AMD, I really appreciate the encouragement and AMD’s support. We’ll keep sharing the measured KR260 progress as we move from PL verification toward the full trust-boundary and hostile-host acceptance tests. I’ll join the Discord and share the project there as well!

1 Like