Wie Modellierung Embedded-Ingenieuren hilft, Anwendungen für SoCs zu entwickeln

In diesem Artikel erfahren Sie, wie Modellierung einem kleinen Team von Algorithmus- und Embedded-Softwareingenieuren dabei half, einen Algorithmus zur Motorregelung zu entwickeln und in einem programmierbaren System-on-Chip (SoC) zu implementieren. Wir waren die Embedded-Ingenieure in diesem Team. Wir werden aufzeigen, wie Modellierung uns unterstützte, unseren Entwurf zu partitionieren, das funktionale Verhalten auf die Implementierungsressourcen abzustimmen und im Labor zu testen.

Programmierbare SoCs wie Xilinx^® Zynq^® SoCs und Altera^® SoC FPGAs, die programmierbare Logik und Mikroprozessorkerne auf dem gleichen Chip vereinen, bieten Entwurfsteams neue Plattformen für die Algorithmen-Entwicklung in vielfältigen Anwendungsbereichen, die Embedded Vision, Kommunikationstechnik, sowie Regelungstechnik von Motoren und Leistungselektronik umfassen. Zu diesen Entwurfsteams gehören in der Regel zwei Kategorien von Ingenieuren: Algorithmus-Ingenieure, die für die Konzeptentwicklung und Ausarbeitung mathematik- und regelbasierter Algorithmen verantwortlich sind, und Embedded-Ingenieure, die für die Verfeinerung der Algorithmen und deren Implementierung in Software oder Hardware auf einer integrierten Baugruppe zuständig sind.

Algorithmus-Ingenieure nutzen die Modellierung häufig bereits frühzeitig im Entwicklungsprozess, um sicherzustellen, dass ihre Algorithmen für die jeweilige Anwendung korrekt funktionieren. Embedded-Ingenieure andererseits erkennen nicht immer sofort die Vorteile der Modellierung. Falls diese Teams jedoch nicht eng zusammenarbeiten, kann es 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.

Unser Ziel war es, zu ermitteln, ob Modellierung sowohl Algorithmus- als auch Embedded-Ingenieuren dabei helfen kann, einen effizienteren und kooperativeren Entwurfsprozess zu schaffen. Dabei wollten wir uns auf die Modellierung von Algorithmus-Komponenten konzentrieren, die wir mittels Simulation erkunden konnten. Simulation sollte genutzt werden, um Partitionierungsentscheidungen zu unterstützen, Simulation und Codegenerierung sollten verwendet werden, um das funktionale Verhalten auf die Implementierungsressourcen abzustimmen und die Integration und Bereitstellung des generierten und manuellen Codes sollte automatisiert werden, um die Laborzeit effizienter zu nutzen.

Vorgeschlagener Workflow

Wir schlugen einen Workflow vor, der aus einer Kombination von aus Modellen generiertem Code mit manuellem Code bestehen sollte. (In diesem Artikel bezeichnen wir den manuell programmierten Teil des Entwurfs als Referenzdesign.) Wir wollten mit Modellen beginnen, die vom Algorithmus-Entwickler bereitgestellt werden sollten, und die Modelle iterativ durch Hinzufügen von Implementierungsdetails ausarbeiten. Mit jeder Iteration sollte das Systemverhalten simuliert werden, um die korrekte Funktion der Algorithmen-Modelle zu gewährleisten, die Algorithmen sollten mit Codegenerierung implementiert werden, um Code zu erhalten, der sich wie das Modell verhält, und anschließend sollte die Integration mit unserem Referenzdesign automatisiert werden, um einen wiederholbaren Prozess zu gewährleisten, der zur Hardware-Implementierung führt (Abbildung 1).

Auswahl einer Hardware-Plattform

Für diese Fallstudie haben wir uns für den Entwurf eines Geschwindigkeitsreglers für einen Permanentmagnet-Synchronmotor unter Verwendung eines feldorientierten Regelalgorithmus (Field-Oriented Control, FOC) mit darauffolgender Bereitstellung auf einen Zynq-7000 All Programmable SoC Intelligent Drives Kit II (Abbildung 2) entschieden. Wir wählten die Motorregelung, da es sich dabei um eine Anwendung handelt, bei der Algorithmus- und Embedded-Ingenieure oft zusammenarbeiten müssen. Das Zynq Intelligent Drives Kit II wurde ausgewählt, weil es sofort verfügbar ist und die von uns erforderte I/O-Unterstützung bietet.

Das Zynq Intelligent Drives Kit II ist eine Entwicklungsplattform, die von Ingenieuren eingesetzt wird, die Algorithmen zur Motorregelung auf einem Zynq Z-7020 SoC-Baustein ausführen und 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 mit 1250 Zyklen/Umdrehung. Weil wir die Algorithmen für die Motorregelung unter verschiedenen Betriebsbedingungen testen wollten, verwendeten wir das Zynq Intelligent Drives Kit II mit einem optionalen Dynamometersystem.

Partitionierung der Algorithmus-Komponenten

Nach der Wahl der Hardware-Plattform prüften wir ein vom Algorithmus-Ingenieur bereitgestelltes erstes System-Simulationsmodell und identifizierten weitere Algorithmus-Komponenten, die für die Bereitstellung auf dem SoC erforderlich sein würden. Das Modell umfasste einen Regelalgorithmus für einen auf Datenblattparametern basierenden Motor. Dieser Algorithmus bestand aus einer äußeren Geschwindigkeitsregelschleife, die eine innere Stromregelschleife mithilfe von FOC regelte.

Obgleich dieses Modell die Kernmathematik der Regelung erfasste, berücksichtigte es nicht die Auswirkungen der Peripheriekomponenten (wie ADC, Encoder und PWM) oder die für andere Betriebsarten erforderlichen Algorithmus-Komponenten (Deaktiviert, Offene Regelschleife und Encoder-Kalibrierung). Wir arbeiteten dann mit dem Algorithmus-Ingenieur zusammen, um zu ermitteln, welche Algorithmus-Komponenten modelliert werden sollten, und zu entscheiden, ob diese Komponenten auf dem ARM oder in der programmierbaren Logik im SoC (Abbildung 3) implementiert werden sollten.

Wir arbeiteten das Modell des ursprünglichen Systems so aus, dass die neuen Algorithmus-Komponenten enthalten waren (Abbildung 4). Um die Systemsimulation zu ermöglichen, erstellten wir konzentrierte Parametermodelle bestehender Peripheriekomponenten, die mit dem Motormodell interagieren. Wir hatten z. B. bestehenden HDL-Code für die Peripheriekomponente Encoder, den wir im bereitgestellten Entwurf wiederverwenden wollten. Die Peripheriekomponente Encoder liest einen Datenstrom digitaler Impulse bei 50 MHz und übersetzt diese in Zählersignale, die vom Regelungsalgorithmus mit 25 kHz gelesen werden. Wenn wir diesen Impulsstrom direkt modellieren würden, würden wir eine 50-MHz-Dynamik in das Systemmodell einführen und die Simulationszeit beträchtlich erhöhen. Stattdessen erstellten wir ein konzentriertes Parametermodell des Encoders, das die ideale Rotorposition aus dem Motormodell in das Encoder-Zählersignal umwandelt, das von den Algorithmus-Komponenten erkannt wird. Modellierung auf dieser Genauigkeitsstufe ermöglichte uns die Simulation der zum Testen der Encoder-Kalibrierungskomponente erforderlichen Startbedingungen sowie die Einführung von Positions-Quantisierungseffekten zum Testen der Geschwindigkeitsregelungs-Komponente (Abbildung 5) bei gleichzeitiger Wahrung angemessener Simulationszeiten.

Wir entschieden uns für die Implementierung von Algorithmus-Komponenten auf dem ARM, wenn sie Raten von wenigen kHz oder weniger erforderten. Die Beschränkung auf Raten mit nur wenigen kHz war gegeben, weil wir vorhatten, ein Linux^®-Betriebssystem auf dem ARM auszuführen. Algorithmus-Komponenten, die schnellere Raten erfordern, sollten im FPGA implementiert werden.

Wir wollten Algorithmus-Komponenten wenn möglich auf dem ARM implementieren, weil wir festgestellt hatten, dass Entwurfsiterationen auf dem ARM schneller als auf dem FPGA waren. Es war einfacher, den Algorithmus auf den ARM-Prozessorkern zu implementieren, weil er native mathematische Gleitkomma-Operationen unterstützte. Die meisten FPGAs führen Gleitkomma-Operationen nur ineffizient aus, daher erfordert die Implementierung in programmierbarer Logik den zusätzlichen Schritt der Umwandlung von Algorithmen in das Festkommaformat. Darüber hinaus stellten wir fest, dass der Prozess der Kompilierung von C-Code für den ARM in der Regel schneller als der zum Kompilieren von HDL-Code für das FPGA war.

Wir verwendeten die Simulation, um zu bestimmen, ob einzelne Algorithmus-Komponenten bei Raten ausgeführt werden konnten, die langsam genug für den ARM waren, oder ob das FPGA erforderlich sein würde. Beispiel: Der Algorithmus-Ingenieur schlug zunächst eine Encoder-Kalibrierungsroutine vor, die bei 25 kHz ausgeführt wurde, was auf dem FPGA implementiert werden müsste. Wir verwendeten die Simulation, um zu testen, ob wir die Encoder-Kalibrierungskomponente bei 1 kHz ausführen könnten, stellten fest, dass dies möglich war, und beschlossen, sie auf dem ARM zu implementieren.

Abstimmung des funktionalen Verhaltens an die Implementierungsressourcen

Als wir funktional korrekte Modelle mit den gewünschten Komponentenraten vorliegen hatten, gruppierten wir alle 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 (Abbildung 6). Dann fügten wir iterativ Implementierungsdetails zu den Modellen hinzu und generierten Code, bis wir der Meinung waren, dass er in einen akzeptablen Speicherbereich passen würde und mit der Komponentenrate ausgeführt werden könnte.

Wir benutzten Embedded Coder^®, um aus dem Algorithmus-C-Modell C-Code zu generieren und erstellten einen Bericht, in dem die Schnittstelle des Aufrufs sowie die geschätzte Datenspeichernutzung zusammengefasst wurden. Als wir den Bericht durchsahen, stellten wir fest, dass alle Datentypen Gleitkommazahlen doppelter Genauigkeit waren. Wir wollten, dass die Daten, die eine Schnittstelle mit dem FPGA bilden würden, Ganzzahl- oder Festkommawerte sein sollten. Der Rest der Mathematik sollte vom Datentyp Gleitkommazahl einfacher Genauigkeit sein. Wir wendeten diese Datentypen auf das Modell an, nutzten Simulation, um zu bestätigen, dass das Verhalten noch akzeptabel war, und generierten dann den verbesserten Code. Zu diesem Zeitpunkt waren wir zuversichtlich, dass der Code für die Implementierung auf dem ARM geeignet war.

Wir implementierten das Algorithmus-HDL-Modell mit dem Festkomma-Datentyp, weil Festkomma-Operationen auf FPGAs weniger Ressourcen verbrauchen. Dazu arbeiteten wir mit dem Algorithmus-Ingenieur zusammen, um die Wertebereiche von Schlüsselsignalen im Entwurf zu identifizieren und festzuhalten (Stromstärke, Spannung und Geschwindigkeit). Dann definierten wir mithilfe von Fixed-Point Designer™ Festkomma-Datentypen, die gewährleisten würden, dass es zu keinem Berechnungsüberlauf kommen würde. Mithilfe von HDL Coder™ generierten wir Code und einen Code-Generierungsbericht.

Wir prüften den Abschnitt zur Ressourcennutzung des Berichts, um mathematische Operationen zu identifizieren, die unerwartet umfassend erschienen. Ein Beispiel: Unsere anfängliche Auswahl der Wortlängen führte zu mehreren Multiplikationen von zwei 34-Bit-Zahlen, was unserer Meinung nach unnötig FPGA-Ressourcen aufbrauchen würde. Wir konnten dieses Problem im Bericht zur Ressourcennutzung identifizieren, die Präzision im Modell reduzieren, mithilfe der Simulation bestätigen, dass die Funktionalität noch korrekt war, und dann den verbesserten Code generieren. Wir synthetisierten den Code mithilfe von Xilinx Vivado^® Design Suite und bestätigten, dass er die Timing-Anforderungen erfüllte.

Testen im Labor

Als wir einen ersten Algorithmus-Kandidaten für die Implentierung hatten, waren wir bereit, ihn in unser Referenzdesign zu integrieren. Wir begannen mit der manuellen Integration der generierten C-Funktion mithilfe unseres manuell codierten Embedded-ARM-Projekts und der Integration der generierten HDL-Entity in unser manuell codiertes Vivado-Projekt. Wir mussten aber erkennen, dass wir bei einer manuellen Integration an jeder Entwurfsiteration im Labor beteiligt sein müssten. Eines unserer Ziele bei der Verwendung dieses Workflows bestand darin, den Algorithmus-Ingenieur in die Lage zu versetzen, den Integrations- und Bereitstellungsprozess im Labor zu automatisieren.

Wir verwendeten das HDL Coder Support Package für die Xilinx Zynq-7000-Plattform, um unser manuell codiertes Vivado-Projekt als Referenzdesign zu registrieren. Dann konnten wir die Integration des generierten Algorithmus-HDL-Codes mit unserem manuellen Code automatisieren, einen Bitstream erstellen und ihn auf das FPGA herunterladen. Wir verwendeten das Embedded Coder Support Package für die Xilinx Zynq-7000-Plattform zur Automatisierung der Integration des generierten Algorithmus-C-Codes mit einem Linux-Betriebssystem, zur Erstellung einer ausführbaren Datei, zum Herunterladen dieser Datei auf den ARM-Prozessor und zur Interaktion mit dem Programm über Simulink^®. Die Support-Pakete stellten das AXI-Interconnect bereit, das die Kommunikation zwischen den Algorithmuskomponenten im ARM-Prozessorkern und der programmierbaren Logik ermöglichte.

Während der anfänglichen Systemeinrichtung war es von grundlegender Bedeutung, dass Algorithmus- und Embedded-Ingenieure im Labor eng zusammenarbeiteten. Wir als die Embedded-Ingenieure mussten die Deployment-Konfiguration einrichten und mit dem Algorithmus-Ingenieur zusammenarbeiten, um die grundlegende Funktionalität zu verifizieren. Nachdem das System eingerichtet war, konnte der Algorithmus-Ingenieur selbstständig Entwurfsiterationen mit Simulink als Hauptschnittstelle mit dem SoC ausführen.

Der Algorithmus-Ingenieur testete die eingesetzte Regelung und stellte fest, dass sie nicht die erwartete Reaktion lieferte. Der Vergleich der Simulations- und Hardware-Ergebnisse zeigte dann, dass wir die Zuordnung des ADC-Zählerwertes zur Stromstärke falsch berechnet hatten. Der Algorithmus-Ingenieur erstellte weitere Tests, um die Drehmomentkonstante des Motors besser zu charakterisieren und die Korrelation zwischen Simulation und Hardware (Abbildung 7) zu verbessern.

Die hohe Korrelation zwischen den Simulations- und Hardware-Testergebnissen zeigte uns, dass wir Entwurfsentscheidungen auf Modellebene treffen und die Laborzeit noch weiter reduzieren konnten. Beispiel: An einem bestimmten Punkt drehte sich der Motor im Labor, wurde aber unter bestimmten Umständen nicht mehr regelbar. Wir vermuteten, dass das Problem mit einem Überlauf der auf dem FPGA implementierten Festkomma-Geschwindigkeitsberechnung zusammenhing. Wir reproduzierten das Problem in der Simulation und identifizierten einen Fehler bei den anfänglichen Annahmen zur maximalen Geschwindigkeit des Motors. Wir konnten das Problem in der Simulation beheben und nutzten Laborzeit nur zur Verifizierung der Änderung.

Vorteile dieses Ansatzes

Der hier beschriebene Workflow ermöglichte eine effizientere Zusammenarbeit mit dem Algorithmus-Ingenieur als zuvor. Durch Simulation konnten wir die Auswirkung der Algorithmus-Partitionierung auf die Systemleistung beurteilen und verifizieren, dass die Encoder-Kalibrierungskomponente von der höherratigen programmierbaren Logikpartition zur niederratigen ARM-Partition verschoben werden konnte.

Die Simulation ermöglichte uns auch, Entscheidungen zu treffen, die Implementierungsressourcen einsparten, während gleichzeitig das funktionale Verhalten gewahrt blieb. Hierzu gehörte z. B. die Reduzierung der Wortlänge mathematischer Operationen in der programmierbaren Logik oder die Konvertierung der über das AXI-Interconnect weitergeleiteten Daten von Gleitkomma- in Festkomma-Datentypen. Schließlich konnten wir mithilfe unserer Prototypentests im Labor auch Fehler bei der Zuordnung der ADC-Zählerwerte zur Stromstärke ermitteln und ermöglichte es unserem Algorithmus-Ingenieur weitere Tests zur Charakterisierung der Drehmomentkonstante des Motors durchführen.

Insgesamt unterstützte der Workflow eine enge Zusammenarbeit zwischen uns und dem Algorithmus-Ingenieur, wodurch eine effizientere Implementierung ermöglicht wurde und gleichzeitig Laborzeit eingespart werden konnte.

Sie benötigen weitere Informationen?

Weitere Details zum in diesem Artikel beschriebenen Workflow finden Sie unter „Field-Oriented Control of a Permanent Magnet Synchronous Machine “. Dieses Bespiel zur Motorregelung auf Basis von Zync umfasst die Simulink-Modelle und MATLAB^®-Skripts, die in unserer Studie verwendet wurden, um Simulationen auszuführen, Code zu generieren, Hardware zu testen und Simulationsläufe mit den Ergebnissen der Hardware-Tests zu vergleichen.

Falls Sie an der Prototypenentwicklung von Algorithmen zur Motorregelung interessiert sind oder die in diesem Artikel und im Beispiel angegebenen Ergebnisse reproduzieren möchten, können Sie weitere Informationen über das Avnet Zynq Intelligent Drives Kit II von Avnet Electronics Marketing einholen.

Um das Zynq-Motorregelungsbeispiel auf andere Hardware-Konfigurationen oder andere Klassen von SoC-Bausteinen von Xilinx oder Altera auszuweiten, empfehlen wir, das Beispiel „Define and Register Custom Board und Reference Design for SoC Workflow“ zurate zu ziehen.

Weitere Einblicke in die Erstellung hochpräziser Modelle von PMSM- und BLDC-Motoren für die Verwendung mit Simulink finden Sie im Artikel „Entwickeln eines qualitativ hochwertigen Elektromotor-Modells für das Design und die Verifizierung eines Regelungssystems“.