RISC-V-Implementierung Portierung von OpenTitan Earl Grey auf das AMD Zynq Ultrascale+ MPSoC ZCU102 Evaluierungskit

Anbieter zum Thema

AMD Advanced Micro Devices GmbH

Mixed Mode GmbH

Precoplat Präzisions Leiterplatten Technik GmbH

congatec GmbH

Die Implementierung eines RISC-V-Softcores kann Entwickler vor unerwartete Herausforderungen stellen, wenn es an der notwendigen Dokumentation mangelt. Dieser Beitrag zeigt einige potenzielle Hürden und Grenzen anhand der Portierung von OpenTitan Earl Grey auf den ZCU102-SoC auf.

Was als etwas ungewöhnliches Projekt begann, nämlich die Portierung von OpenTitan auf das ZCU102 Bord, da dies für das gegebene Forschungsprojekt APRIORI am sinnvollsten erschien, endete als eine verzwickte Angelegenheit. In der offiziellen OpenTitan-Dokumentation [1] fehlen nämlich bis heute eine Reihe wesentlicher Informationen. Um anderen dieselben misslichen Erfahrungen zu ersparen, haben wir hier unsere Erfahrungen mit der Portierung zusammengefasst.

Die Ingenics Digital GmbH war zwischen 2021 und 2024 Projektpartner des französisch-deutschen Forschungsprojekts APRIORI (Advanced Privacy of IoT Devices through Robust Hardware Implementations) [4], bei welchem es darum ging, private Daten in IoT-Geräten zu gewährleisten und sie gegen Angriffe abzusichern. Als Grundlage sollte ein RISC-V Prozessor ausgewählt werden, der als Softcore auf einem FPGA läuft. In gemeinsamem Übereinkommen entschied man sich für den Open Source Chip „OpenTitan Earl Grey“.

OpenTitan ist ein Open Source Silicon Root of Trust Projekt. Der OpenTitan Earl Grey Chip, der unter besagtes Projekt fällt, ist ein low-power secure Microcontroller, der für Hardware Security Anwendungsfälle konstruiert wurde [1]. Bei dem Prozessor handelt es sich um einen 32-bit RISC-V Kern namens „Ibex“ mit 2-Stufen Pipeline [5]. Ursprünglich wurde der „Ibex“ von der PULP Platform unter dem Namen „Zero-Riscy“ [6] entwickelt. Zusätzlich zum RV32IMC Befehlssatz unterstützt „Ibex“ auch den M (Maschine) und U (User) Modus des RISC-V Standard. Das top_earlgrey Modul besteht aus zwei Domänen, die mit unterschiedlichen Frequenzen betrieben werden (Bild 1):

• High Speed Domain

• Peripheral Domain

In der High Speed Domain befinden sich der Ibex sowie Sicherheit Features, wie z.B. der Key Manager, OTBN, AES, KMAC, HMAC, etc. Zusätzlich findet man dort auch den SPI, ROM, SRAM USB und den Flash. Verbunden sind sämtliche Module über die TL-UL Crossbar, ein leichtgewichtiges, ungecachtes TileLink basiertes Bus Protokoll. Die TL-UL Crossbar wird ebenfalls verwendet, um die High Speed Domain mit der Peripheral Domain zu verbinden. In der Peripheral Domain befinden sich

Sicherheitsfeatures wie der OTP-Controller, die Module Life Cycle und Alert Handler. Ebenfalls vorhanden sind UART, Timers, GPIO, I2C, das SPI Device und Pattern-Generatoren. Ein Teil der Always-on Domain, die im Gegensatz zu den restlichen Modulen nicht durch den Power Manager deaktiviert werden können, sind ebenfalls vorhanden. Hierbei handelt es sich um PWM, Retention SRAM, Power Manger, Sysrst Controller, AON Timers, Clk/Rst Managers, Pinmux /Padctrl, ADC-Controller und Sensor Controller. Die Chip Earlgrey Ebene besteht immer aus dem Top Earlgrey, dem Padring und dem Analog Sensor Top (AST). Der Padring wird zur Verbindung von Modulen genutzt, während der AST analoge Funktionen wie Clocks, Regulatoren, Zufallszahlengeneratoren und Sensoren enthält, um den Chip vor physikalischen Attacken und Manipulationen zu schützen.

Als Portierungsgrundlage wurde der damalige Earlgrey-ES-SV2 Release verwendet (der nicht mehr auf GITHUB verfügbar ist, nächster Nachfolger ist gegenwärtig (August 2025) Earlgrey-PROD.M2, der nicht getestet wurde). Der Anstoß für die Portierung auf das AMD Zynq Ultrascale+ MPSoC ZCU102 Evaluierungskit war die mangelhafte Verfügbarkeit des damaligen Entwicklungsboards „CW310 Bergen Board“. Als Build System wurde Bazel [8] verwendet, welches das Build System FuseSoC startet. Bazel kümmert sich um das Bauen der Software, Tests etc., FuseSoC um die Ansteuerung der Hardware und das Bauen des Bitstreams. Das Blockdesign des Chip Earlgrey für die Portierung auf das ZCU102 zeigt Bild 2.

FuseSoC

Die Funktionalität von FuseSoC [7] basiert auf Cores. Diese Cores sind eigenständige, wiederverwendbare IP-Blöcke wie z.B. eine FIFO-Implementierung. Sie werden durch Core-Files beschrieben, die unter anderem die Source Files für besagte IP beinhalten. Das Build System basiert auf diesen Core-Files, wobei es ein Top Level Core-File gibt, das andere Core-Files aufruft, wodurch das gesamte System beschrieben wird, das gebaut werden soll.

CW310

Bei dem CW310 Board [3] handelt es sich um erweiterte Evaluations Platform für FPGA-basierte Security SoC, RoT oder HSM-basierte Designs. Es hat einen AMD Kintex 7 FPGA mit dem K410T Chipsatz und einen SAM3X Microcontroller, der für die folgenden Aufgaben zuständig ist:

• Konfiguration und Rekonfiguration des FPGAs

• Überwachung der FPGA-Temperatur und Lüfter

• Anpassung der Spannung

• Kontrolle der PLL und Setzen der Clock-Frequenz

• Kommunikation über die seriellen USB-Ports

• Steuerung des Address/Datenbusses, der genutzt werden kann, um 30 vom Computer kontrollierte GPIO-Pins zu steuern

• Kommunikation über das generische SPI-Interface

Beim OpenTitan wird dieser Microcontroller genutzt, um die Firmware zu laden und GPIOs zu setzen.

ZCU102

ZCU102 ist ein Evaluierungskit mit AMD Zynq Ultrascale+ MPSoC mit Quad-Core Arm Cortex-A53, Dual-Core Cortex-R5F Echtzeitprozessoren und einem Mali-400 MP2 Grafikprozessor [2]. Für den OpenTitan wird der FPGA (PL) des AMD Zynq Ultrascale+ MPSoC und der Quad-Core Arm Cortex-A53 (PS) verwendet. Der Quad-Core wird genutzt, um die GPIOs des OpenTitan zu setzen und die Firmware zu laden.

Guidance to Accelerate your Programmable Solution

Featuring Special Tracks with Focus on Embedded AI

The FPGA Conference Europe, Europe's most important platform for manufacturer- and technology-independent cross-application dialogue, provides embedded developers with orientation and practical assistance. Engage with industry leaders, gain insights from hands-on workshops, and connect with fellow experts eager to share the latest innovations and techniques. A new special track will focus on Embedded AI – intelligent systems that implement machine learning directly in programmable hardware.

Learn more

Portierung

Um den Softcore auf dem ZCU102 in Betrieb nehmen zu können, mussten mehrere Anpassungen vorgenommen werden. Zunächst wurde die Datei „chip_earlgrey_cw310.core“ angepasst.

Hierbei handelt es sich um das TOP Level Core-File für den OpenTitan Earl Grey Chip.

Die Bordnummer des CW310 wurde durch die des ZCU102 ersetzt. Anschließend wurde die Clock angepasst. Die Standard-Clock des CW310 läuft mit 100 MHz, während die Standard-Clock des ZCU102 125 MHz hat. Da der OpenTitan über mehrere Clocks verfügt, wurde der MMCME2 IP-Core verwendet, um die entsprechenden Clocks für den FPGA zu generieren:

Für das ZCU102 wurde ein neues Modul mit derselben Funktionalität erstellt, das eine MMCME4 (Äquivalent zu der MMCME2 für Ultrascale+ Bords) instanziiert und die an die neue System Clock angepasst wurde. Entsprechend wurden auch die Constraint Files angepasst. Das File clocks.xdc wurde durch clocks_zcu102.xdc ersetzt und an die neue System Clock angepasst.

Das File pins_cw310.xdc wurde durch pins_zcu102.xdc ersetzt. Auf dem ZCU102 verfügbare Pins wurden verwendet, um die entsprechenden Signale zu verbinden. Die restlichen Signale wurden mit unkritischen Pins verbunden; teilweise wurden Pins intern mit dem verfügbaren Processing System des ZCU102 Boards verbunden. Die Hook Files (vivado_hook_opt_design_post.tcl und vivado_hook_write_bitstream_pre.tcl) beinhalten den Begriff BRAM. Für Ultrascale+ Boards muss dieser in BLOCKRAM geändert werden. Zusätzlich wurden die generate_mmi-Befehle angepasst:

• 'generate_mmi "otp.mmi" $otb_brams "RAMB18" 80 16 2'  'generate_mmi "otp.mmi" $otb_brams "RAMB18" 0 16 2'

• 'generate_mmi "rom.mmi" $rom_brams "RAMB32" 80 1 1'  'generate_mmi "rom.mmi" $rom_brams "RAMB36" 40 1 1'

Um den Softcore programmieren zu können, müssen die BOOTSTRAP-PINs richtig gesetzt werden.

Wenn diese Pins auf die richtigen Werte gesetzt wurden, kann der auszuführende Code über SPI auf den OpenTitan geladen werden.

Verbindung des Flashs mit dem OpenTitan

Um den Flash des ZCU102 benutzen zu können, muss das PS benutzt werden, da es keine direkte Verbindung zur PL gibt. Hierfür wurde ein Blockdesign mit den folgenden Komponenten erstellt (Bild 3):

• AXI GPIO: Bootstrap Pins

• AXI Interrupt Controller: PS Interrupts

• AXI Quad SPI: SPI zum OpenTitan

• AXI Interconnect: for AXI GPIO and AXI Quad SPI

• Processor System Reset: Resets für das Blockdesign, von PS gesetzt

• Zynq UltraScale+ MPSoC: Processing System (PS)

Software für Processing System

Die Software für das Processing System steuert die Module AXI GPIO und AXI Quad SPI, um die BOOTSTRAP Pins zu setzen, die Firmware aus dem Flash zu lesen und an den OpenTitan weiterzuleiten:

• Initialisierung von AXI GPIO

• Steuerung der Bootstrap Pins

• Initialisierung des QSPI und SPI

• Lesen des Flashs via QSPI and beschreiben des OpenTitan via SPI

Laden der Firmware

Es gibt mehrere Möglichkeiten, die Firmware auf das Bord zu laden:

1. Flashen der SW via OpenOCD
2. Flashen der SW in den SPI-Flash des ZCU102 und Weiterleitung via AXI und SPI in den OpenTitan. Das Eeprom Protokoll muss dafür genutzt werden und die BOOT Strap Pins müssen richtig gesetzt sein.
3. Die Verbindung vom Blockdesign zum OpenTitan können direkt von Linux genutzt werden. Die BOOT Strap Pins müssen richtig gesetzt werden und die Firmware wird dann über SPI geladen.

Leitfaden

So wählen Sie den passenden RISC-V-Softcore

Lohnt es sich?

Der Portierungsaufwand zum Zeitpunkt der Portierung war größer als erwartet.

Der SAM3X Microcontroller wird bei der Ausführung der Host SW benötigt, was nicht in der Dokumentation beschrieben ist, wodurch das Laden der Firmware und das Steuern der Pins erschwert wurde. Unglücklicherweise gab es damals noch keine Suchfunktion für die Dokumentation, wodurch das Suchen nach Informationen noch zusätzlich erschwert wurde. Da der OpenTitan als ASIC in Produktion gehen soll, ist das Ziel des Softcores das Testen und Verifizieren der Funktionalität. Durch die beschränkten Ressourcen auf dem FPGA und das über die Entwicklung immer größer werdende Design wurde es immer schwieriger das Timing einzuhalten, weshalb der Clock Speed auf dem FPGA reduziert wurde. Die Information zu den niedrigen Clock-Raten auf dem CW310 ist bis heute nicht in der Dokumentation beschrieben. Andere RISC-V Softcores, wie z.B. Neorv32, Microblaze oder Ibex, können mit 100 MHz oder höher betrieben werden. Mit der derzeitigen Implementierung von clkgen_xil7series, wird der Ibex mit 24 MHz betrieben. Diese Clock-Geschwindigkeit könnte entsprechend auch auf dem ZCU102 möglich sein. Leider wird diese Geschwindigkeit für viele Anwendungen nicht den Anforderungen entsprechen. Letztendlich lohnt sich der Betrieb des OpenTitan als Softcore nur in einigen wenigen Fällen, wenn man zum einen die Sicherheitsfeatures nutzen will und ein entsprechend großes Board zur Verfügung hat. Man muss dann nur dafür sorgen, dass man die Software, die man ausführen will, auf den OpenTitan bekommt: Bootstrap, über SPI Daten schicken - mehr ist es nicht. (sg)

Quellen /Fußnoten

[1] OpenTitan.

[2] ZCU102 Evaluation Board.

[3] CW310 Bergen Board (Kintex FPGA Target).

[4] APRIORI.

[5] Ibex.

[6] ZERO-RISCY.

[7] FuseSoC:

[8] Bazel

(ID:50851908)