Modellbasierter Workflow für Motorregelungen auf System-on-Chip FPGAs

Modellbasierte Ansätze haben sich zur Entwicklung und Verifikation von Regelalgorithmen bewährt. Doch eignet sich ein solcher Workflow nicht nur zur Simulation. Mit der richtigen Methode lässt sich direkt aus dem Workflow nutzbarer Code generieren, der automatisch auf programmierbaren SoC-FPGAs als laufendes System genutzt werden kann.

Für die Entwicklung und Verifikation von Regelalgorithmen wird überwiegend ein modellbasierter Entwurfsansatz eingesetzt. Dieser ermöglicht zusammen mit dem physikalischen Modell der Regelstrecke eine frühzeitige Simulation des Algorithmus. In diesem Artikel wird ein Workflow beschrieben, der darüber hinaus mittels Codegenerierung aus dem Simulationsmodell des Regelalgorithmus eine automatisierte Implementierung auf programmierbare System-on-Chip (SoC)-FPGAs gestattet. Die Modellierung hilft dabei, den Entwurf in weiteren Verfeinerungsschritten auf Software und Hardware zu partitionieren und die Funktionen auf die vorhandenen Implementierungsressourcen abzustimmen. Der Workflow erlaubt einerseits, mit dem Simulationsmodell eine schnelle Prototypenimplementierung zu erreichen, andererseits kann nach dem Prototypentest im Labor ein produktionsreifer Implementierungscode generiert werden.

Heterogene, frei programmierbare System-on-Chips, wie Xilinxs Zynq-SoCs, Intels SoC-FPGAs und Microsemis SoC-FPGAs, die programmierbare Logik und Mikroprozessorkerne auf dem gleichen Chip vereinen, bieten Entwurfsteams neue Plattformen für die Algorithmen-Entwicklung. Zu den vielfältigen Anwendungsbereichen gehören Embedded Vision, Kommunikationstechnik sowie Regelungstechnik von Motoren und Leistungselektronik. Die Entwurfsteams setzen sich in der Regel zusammen aus Algorithmus-Ingenieuren, die für die Konzeptentwicklung und Ausarbeitung mathematik- und regelbasierter Algorithmen verantwortlich sind, sowie Embedded-Ingenieuren, die für die Verfeinerung der Algorithmen und deren Implementierung in Software oder Hardware zuständig sind.

Bildergalerie

Bildergalerie mit 6 Bildern

Algorithmus-Ingenieure nutzen Modellierung bereits frühzeitig im Entwicklungsprozess, um sicherzustellen, dass ihre Algorithmen für die jeweilige Anwendung korrekt funktionieren. Embedded-Ingenieure andererseits erkennen die Vorteile der Modellierung nicht immer sofort. Ohne enge Zusammenarbeit dieser Teams, kann es so zu einer verspäteten Fehlererkennung und dadurch zu Projektverzögerungen, übermäßigem Ressourcenverbrauch oder einer beeinträchtigten Funktionalität aufgrund unzureichender Entwurfs- und Testiterationen kommen.

Der modellbasierte Entwurf kann Algorithmus- und Embedded-Ingenieuren helfen, einen effizienten und kooperativen Entwurfsprozess zu schaffen. Die Konzentration auf Modellierung und Simulation unterstützt frühe Partitionierungsentscheidungen für Algorithmus-Komponenten, Simulation und Codegenerierung erlauben das funktionale Verhalten auf die Implementierungsressourcen abzustimmen und die Bereitstellung und Integration von generiertem und manuell erzeugtem Code in einem automatisierten Workflow erlauben es, die Laborzeit für die Prototypenverifikation effizienter zu nutzen.

Modellbasierter Workflow

Für die Implementierung auf SoCs hat sich ein Workflow bewährt, der aus einer Kombination von aus Modellen generiertem und manuell bereitgestelltem Code besteht. Der manuell programmierte Code wird hierbei als Referenzdesign bezeichnet. Vom Algorithmus-Entwickler werden Modelle zur Verfügung gestellt, die durch iteratives Hinzufügen von Implementierungsdetails weiter ausgearbeitet werden. Mit jeder Iteration wird das Systemverhalten erneut simuliert, um die korrekte Funktion der Modelle sowie des aus den Modellen generierten Code zu gewährleisten. Dieser wird in einem automatisierten Schritt in dem Referenzdesign integriert und in einem wiederholbaren Prozess zur Hardware-Implementierung weiterentwickelt (siehe Bild 1).

Auswahl einer Hardware-Plattform

Für eine Fallstudie soll der Entwurf eines Geschwindigkeitsreglers für einen Permanentmagnet-Synchronmotor unter Verwendung eines feldorientierten Regelalgorithmus (Field-Oriented Control, FOC) betrachtet werden, der auf einen Zynq-7000 All Programmable SoC Intelligent Drives Kit II (siehe Bild 2) implementiert wird. Die Motorregelung wurde ausgewählt, da bei dieser Anwendung Algorithmus- und Embedded-Ingenieure eng zusammenarbeiten müssen. Das Zynq Intelligent Drives Kit II wurde gewählt, weil es sofort verfügbar ist und die erforderliche I/O-Schnittstellen-Unterstützung bietet.

Das Zynq Intelligent Drives Kit II ist eine Entwicklungsplattform, die von Ingenieuren eingesetzt wird, um die Motorregelungsalgorithmen auf einem Zynq Z-7020 SoC-Baustein auszuführen und zu testen. Das Kit basiert auf dem ZedBoard-Entwicklungs-Board und umfasst ein Analog-Devices-FMC-Motorsteuerungsmodul sowie einen bürstenlosen 24-V-Gleichstrommotor mit einem Encoder für 1250 Zyklen/Umdrehung. Da die Motorregelungsalgorithmen unter verschiedenen Betriebsbedingungen getestet werden sollen, wird das Zynq Intelligent Drives Kit II mit einem optionalen Dynamometersystem verwendet.

Partitionierung der Algorithmus-Komponenten

Ein vom Algorithmus-Ingenieur bereitgestelltes erstes Systemsimulationsmodell muss um weitere Komponenten ergänzt werden, die für die Bereitstellung auf der SoC-Prototypenplattform erforderlich sind. Das Modell umfasst einen Regelalgorithmus für ein auf Datenblattparametern basierendes Motormodell. Der Regelalgorithmus besteht aus einer äußeren Geschwindigkeitsregelschleife, die eine innere, feldorientierte Stromregelschleife regelt.

Obgleich dieses Modell den Algorithmus der Regelung erfasst, berücksichtigt es nicht die Auswirkungen der Peripherie-Komponenten (wie ADC, Encoder und PWM), oder die für andere Betriebsarten erforderlichen Algorithmus-Komponenten (deaktiviert, offene Regelschleife und Encoder-Kalibrierung). Zusammen mit dem Algorithmus-Ingenieur wird ermittelt, welche Komponenten modelliert werden sollen, und ob diese auf dem ARM oder in der programmierbaren Logik im SoC (siehe Bild 3) implementiert werden sollen.

Das ursprüngliche Modell wird mit den neuen Algorithmus-Komponenten ergänzt (siehe Bild 4). Um die Systemsimulation zu ermöglichen, werden konzentrierte Parametermodelle bestehender Peripheriekomponenten erstellt, die mit dem Motormodell interagieren. Bestehender HDL-Code, beispielsweise für die Peripherie-Komponente Encoder, wird im bereitgestellten Entwurf wiederverwendet. Der Encoder liest einen Datenstrom digitaler Impulse bei 50 MHz und übersetzt diese in Zählersignale, die vom Regelungsalgorithmus mit 25 kHz gelesen werden. Eine direkte Modellierung dieses Impulsstroms würde eine 50-MHz-Dynamik in das Systemmodell einführen und die Simulationszeit beträchtlich erhöhen.

Stattdessen wird ein konzentriertes Parametermodell des Encoders erstellt, das die ideale Rotorposition aus dem Motormodell in das Encoder-Zählersignal umwandelt, welches dann von den Algorithmus-Komponenten verarbeitet wird. Eine Modellierung auf dieser Genauigkeitsstufe ermöglicht die Simulation der zum Testen der Encoder-Kalibrierungskomponente erforderlichen Startbedingungen sowie die Einführung von Positions-Quantisierungseffekten zum Testen der Komponente zur Geschwindigkeitsregelung (siehe Bild 5) bei gleichzeitiger Wahrung angemessener Simulationszeiten.

Algorithmus-Komponenten mit Raten von einigen kHz oder weniger können auf dem ARM implementiert werden. Die Beschränkung auf Raten mit nur wenigen kHz wird vom Linux-Betriebssystem vorgegeben, das auf dem ARM ausgeführt werden soll. Algorithmus-Komponenten, die schnellere Raten erfordern, sollen im FPGA implementiert werden.

Wenn möglich, sollen Algorithmus-Komponenten bevorzugt auf dem ARM implementiert werden, da Entwurfsiterationen auf dem ARM schneller als auf dem FPGA durchgeführt werden können. Es ist zudem einfacher, den Algorithmus auf den ARM-Prozessorkern zu implementieren, weil er native mathematische Gleitkomma-Operationen unterstützt. Die meisten FPGAs führen Gleitkomma-Operationen lediglich ineffizient aus, daher erfordert die Implementierung in programmierbarer Logik den zusätzlichen Schritt der Umwandlung von Algorithmen in das Festkommaformat. Darüber hinaus ist der Prozess der Kompilierung von C-Code für den ARM in der Regel deutlich schneller als der zum Kompilieren von HDL-Code für das FPGA.

Die Simulation kann dazu verwendet werden, zu bestimmen, ob einzelne Algorithmus-Komponenten bei Raten ausgeführt werden können, die langsam genug für den ARM sind, oder ob das FPGA erforderlich sein wird. Ein Beispiel: Der Algorithmus-Ingenieur schlägt zunächst eine Encoder-Kalibrierungsroutine vor, die bei 25 kHz ausgeführt und auf dem FPGA implementiert werden soll. Die Simulation bietet die Möglichkeit einer Untersuchung der Encoder-Kalibrierungskomponente bei 1 kHz und die Ergebnisse zeigen, dass auch eine Implementierung auf dem ARM-Kern möglich ist.

Abstimmung des funktionalen Verhaltens an die Implementierungsressourcen

Nach der Entwicklung der funktional korrekten Modelle mit den gewünschten Taktraten können die für die C-Codegenerierung vorgesehenen Komponenten in einem Algorithmus-C-Modell und alle Komponenten für die HDL-Codegenerierung in einem Algorithmus-HDL-Modell gruppiert werden (siehe Bild 6). Anschließend werden iterativ Implementierungsdetails zu den Modellen hinzugefügt und Code generiert, bis der generierte C-Code in einen akzeptablen Speicherbereich passt und mit der Komponentenrate ausgeführt werden kann.

Mit Hilfe von Embedded Coder kann aus dem Algorithmus-C-Modell C-Code generiert und ein Bericht erstellt werden, in dem die Schnittstelle des Aufrufs sowie die geschätzte Datenspeichernutzung zusammengefasst sind. In einem ersten Schritt sind alle Datentypen Gleitkommazahlen doppelter Genauigkeit. Für die Daten, die eine Schnittstelle mit dem FPGA bilden, sollen jedoch Ganzzahl- oder Festkomma-Datentypen verwendet werden. Der Rest der Mathematik soll vom Datentyp Gleitkommazahl einfacher Genauigkeit sein. Nach Anwendung dieser Datentypen auf das Modell wird mittels Simulation bestätigt, dass das Verhalten noch akzeptabel ist, und anschließend optimierter Code generiert. Zu diesem Zeitpunkt kann man bereits einschätzen, ob der Code für die Implementierung auf dem ARM geeignet ist.

Das Algorithmus-HDL-Modell wird mit Festkomma-Datentypen implementiert, da Festkomma-Operationen auf FPGAs weniger Ressourcen verbrauchen. Dazu kann mit dem Algorithmus-Ingenieur zusammengearbeitet werden, um die Wertebereiche von Schlüsselsignalen im Entwurf zu identifizieren und festzuhalten (z.B. Stromstärke, Spannung und Geschwindigkeit). Daraufhin werden mithilfe von Fixed-Point Designer Festkomma-Datentypen definiert, die gewährleisten, dass es zu keinem Berechnungsüberlauf kommt. Mithilfe von HDL Coder werden der HDL-Code und ein Code-Generierungsbericht erstellt.

Der Abschnitt des Berichts über die Ressourcennutzung kann verwendet werden, um mathematische Operationen zu identifizieren, die unerwartet umfassend erscheinen. In diesem Fallbeispiel kann eine anfängliche Auswahl der Wortlängen zu mehreren Multiplikationen von zwei 34-Bit-Zahlen führen, was unnötig FPGA-Ressourcen verbrauchen würde. Dieses Problem kann im Ressourcennutzungsbericht identifiziert und die Präzision im Modell entsprechend reduziert werden. Mithilfe der Simulation lässt sich im Anschluss bestätigen, dass die Funktionalität noch korrekt ist. Daraufhin kann der optimierte HDL-Code generiert und unter Verwendung von Xilinx Vivado Design Suite synthetisiert werden. Die anschließende statische Timing-Analyse bestätigt die Einhaltung der Zeitanforderungen im FPGA.

Testen im Labor

Nachdem ein erster Kandidat für die Implementierung des Algorithmus vorbereitet wurde, kann er in das Referenzdesign integriert werden. Im ersten Durchlauf wird eine manuelle Integration der generierten C-Funktionalität mithilfe des manuell codierten Embedded-ARM-Projekts und der Integration der generierten HDL-Entity in das manuell codierte Vivado-Projekt durchgeführt. Bei dieser manuellen Vorgehensweise war es erforderlich, dass die Embedded-Ingenieure für die Integration jeder Entwurfsiteration verfügbar sind. Ein Ziel bei der Verwendung des vorgestellten Workflows bestand darin, ihn weitgehend zu automatisieren und somit den Algorithmus-Ingenieur in die Lage zu versetzen, den Integrations- und Bereitstellungsprozess im Labor selbständig durchzuführen.

Dazu kann das HDL Coder Support Package für die Xilinx Zynq-Plattform verwendet werden, um das manuell codierte Vivado-Projekt als Referenzdesign zu registrieren. Somit kann die Integration des generierten Algorithmus-HDL-Codes mit dem manuellen Code automatisiert, ein Bitstream erstellt und auf das FPGA heruntergeladen werden. Mit Hilfe des Embedded Coder Support Package für die Xilinx Zynq-Plattform kann die Automatisierung der Integration des generierten Algorithmus-C-Codes mit einem Linux-Betriebssystem, die Erstellung einer ausführbaren Datei, das Herunterladen dieser Datei auf den ARM-Prozessor und die Interaktion mit dem ausgeführten Programm über Simulink erfolgen. Die Support-Pakete stellen das AXI-Interconnect bereit, welches die Kommunikation zwischen den Algorithmuskomponenten im ARM-Prozessorkern und der programmierbaren Logik ermöglicht.

Während der anfänglichen Systemeinrichtung ist es notwendig, dass Algorithmus- und Embedded-Ingenieure im Labor eng zusammenarbeiten. Die Embedded-Ingenieure müssen die Deployment-Konfiguration einrichten und sich kontinuierlich mit dem Algorithmus-Ingenieur abstimmen, um die grundlegende Funktionalität zu verifizieren. Nachdem das System eingerichtet ist, kann der Algorithmus-Ingenieur selbstständig Entwurfsiterationen ausführen und über Simulink mit dem SoC kommunizieren.

Der Algorithmus-Ingenieur testet die eingesetzte Regelung und verifiziert die Ergebnisse. Der Vergleich der Simulations- und Hardware-Ergebnisse kann in diesem Fallbeispiel darauf hinweisen, dass die Zuordnung des ADC-Zählerwertes zur Stromstärke falsch berechnet wurde. Daraufhin kann der Algorithmus-Ingenieur weitere Tests erstellen, um die Drehmomentkonstante des Motors besser zu charakterisieren und die Korrelation zwischen Simulation und Hardware (siehe Bild 7) zu verbessern.

Die hohe Korrelation zwischen den Simulations- und Hardware-Testergebnissen zeigt, dass sinnvolle Entwurfsentscheidungen auf Modellebene getroffen wurden und die Laborzeit durch den integrierten Workflow weiter reduziert werden kann.

Vorteile dieses Ansatzes zur Modellbasierten Entwicklung

Der hier beschriebene Workflow ermöglicht eine effizientere Zusammenarbeit zwischen Embedded- und Algorithmus-Ingenieuren als zuvor. Durch Simulation können die Auswirkung der Algorithmus-Partitionierung auf die Systemleistung beurteilt und verifiziert werden, beispielsweise, dass es möglich war, die Encoder-Kalibrierungskomponente von der höherratigen programmierbaren Logikpartition zur niederratigen ARM-Partition zu verschieben.

Die Simulation ermöglicht es auch, Entscheidungen zu treffen, die Implementierungsressourcen einsparen, während gleichzeitig das funktionale Verhalten erhalten bleibt. Hierzu gehört beispielsweise die Reduzierung der Wortlänge mathematischer Operationen in der programmierbaren Logik, oder auch die Konvertierung der über das AXI-Interconnect weitergeleiteten Daten von Gleitkomma- in Festkomma-Datentypen. Schließlich ermöglichen es Prototypentests im Labor den Algorithmus-Ingenieuren weitere Tests zur Charakterisierung der Drehmomentkonstante des Motors durchzuführen.

Insgesamt unterstützt der Workflow eine enge Zusammenarbeit zwischen Embedded- und Algorithmus-Ingenieuren, wodurch eine effizientere Implementierung ermöglicht und gleichzeitig Laborzeit eingespart werden kann.

Grundlagen des Modellbasierten System-Engineering (MBSE)

Applikations-Know-how ins FPGA bringen

FGPA-Prototypen in MATLAB entwickeln – Teil 1

Modellbasierte Risikoanalyse sicherheitskritischer Systeme

(ID:45336031)