FPGA vs. CPU für die Echtzeit-Simulation von Leistungselektronik

Wichtigste Erkenntnisse

• Beginnen Sie die Entscheidung zwischen CPU und FPGA mit festen Zeitschritten, Worst-Case-Latenz und Jitter-Grenzwerten, da verpasste Fristen die HIL-Ergebnisse schneller ungültig machen als jegliche Kompromisse bei der Modellierung.
• Verwenden Sie CPUs für schnelle Iterationen, größere Multi-Domain-Modelle und häufige Aktualisierungen und verwenden Sie FPGAs, wenn Switching, Schutz und I/O bei jedem Sample deterministisch bleiben müssen.
• Erzielen Sie die besten Ergebnisse in Bezug auf Kosten und Zeitplan durch disziplinierte Partitionierung, indem Sie nur zeitkritische Pfade auf dem FPGA belassen und den Rest auf der CPU, sodass Ihr Team Modelle reibungslos debuggen und aktualisieren kann.

Wählen Sie eine CPU, wenn Ihr Modell Flexibilität erfordert, und wählen Sie einen FPGA, wenn es deterministisches Timing im Submikrosekundenbereich benötigt.

Diese Entscheidung ist wichtig, da die Echtzeit-Simulation von Leistungselektronik selten allein durch die Mathematik begrenzt wird, sondern durch Zeitschritte, I/O und den Umfang der gespeicherten Schaltdetails. Die Leistungselektronik verarbeitet bereits etwa 70 % des Stroms in den Vereinigten Staaten, weshalb der Validierungsdruck gleichzeitig auf Leistungsstufen, Steuerungen, Schutzvorrichtungen und Netzinteraktion lastet. Wenn Ihr Simulator die Fristen nicht einhält, wird Ihr Reglertest zu einem Timing-Test und nicht zu einem Steuerungstest.

CPU-basierte Simulationen decken einen Großteil der hardware(HIL) ab, da sie schnell zu erstellen, zu iterieren und zu debuggen sind. FPGA-basierte Simulationen lohnen sich, wenn Ihre Schalt-, Sensor- oder Schutzpfade sich hardware jeder Abtastung wie hardware verhalten müssen, mit engen Grenzen hinsichtlich Latenz und Jitter. Teams, die dies als Partitionierungs- und Timing-Problem betrachten und nicht als Prozessor-Konkurrenz, erzielen schneller stabile Ergebnisse.

Passen Sie die Zeitschrittziele des Match-Solvers an die CPU oder den FPGA an.

Eine CPU eignet sich am besten, wenn Ihr fester Zeitschritt im Bereich von einigen zehn Mikrosekunden liegt und Sie dennoch Ihre Testziele erreichen können. Ein FPGA eignet sich am besten, wenn Ihr fester Zeitschritt auf einstellige Mikrosekunden oder weniger sinken muss und Sie dennoch alle Fristen einhalten können. Die erste Entscheidung betrifft nicht die Genauigkeit, sondern die Zeitplanung. Wenn der Simulator nicht jeden Schritt rechtzeitig abschließen kann, sind die Ergebnisse nicht mehr zuverlässig.

Beginnen Sie mit der schnellsten Schleife, die in Echtzeit geschlossen werden muss, und arbeiten Sie sich dann nach außen vor. Gate-Drive- und Schutzlogik zwingen Sie zu kleinsten Zeitschritten, während Wärme- oder Energiemanagementmodelle größere Schritte tolerieren. CPU-Löser können viele kontinuierliche Zustände gut verarbeiten und glänzen, wenn Sie täglich Modellvarianten austauschen, Parameter live abstimmen oder Batch-Sweeps über mehrere Kerne hinweg ausführen müssen. FPGA-Löser glänzen, wenn parallele Ausführung mit fester Latenz wichtiger ist als die Bequemlichkeit von Fließkommazahlen.

Die Auswahl des Zeitschritts bestimmt auch, was Sie ohne numerische Artefakte darstellen können. Kanten, die für Ihren Zeitschritt „zu scharf“ sind, verschmieren in die nächste Probe hinein und verzerren die aktuellen Wellenform- und Spitzenwerte. Wenn Ihr Ziel die Stabilität des Reglers und der durchschnittliche Leistungsfluss ist, können ein größerer Zeitschritt und ein gemitteltes Modell die richtige Wahl sein. Wenn Ihr Ziel die Schutzzeitsteuerung oder die Strombegrenzung auf Zyklusbasis ist, setzt der Zeitschritt eine harte Grenze für das, was eine CPU leisten kann.

Vergleichen Sie die Anforderungen hinsichtlich Latenz, Jitter und I/O .

„Der Hauptunterschied zwischen CPU- und FPGA-Timing ist der Determinismus.“

Eine CPU kann eine geringe durchschnittliche Latenzzeit liefern, weist jedoch Jitter aufgrund von Scheduling, Interrupts und Buskonflikten auf, sofern nicht der gesamte Stack für Determinismus ausgelegt ist. Ein FPGA führt Logik mit vorhersagbarem Timing aus, das Sie im Voraus festlegen können. Wenn es bei Ihrem Test auf das Worst-Case-Timing ankommt, ist Jitter wichtiger als die durchschnittliche Geschwindigkeit.

I/O wird oft zur versteckten Anforderung. Analoge und digitale I/O müssen mit dem Solver-Schritt übereinstimmen, und Aktuator-Aktualisierungen müssen zu konsistenten Zeitpunkten erfolgen, wenn Sie einen schnellen Schutz oder eine PWM-Synchronisation validieren. CPU-Systeme können ein straffes Timing einhalten, wenn das Modell leicht ist und der software optimiert ist, aber schwere Modelle und Hintergrundaktivitäten erhöhen das Risiko von Jitter. I/O taktsynchronisiert werden, wodurch Abtastung, Latching und Vorteil über alle Läufe hinweg konsistent bleiben.

Bewertung der Modellgenauigkeitsgrenzen für Schaltnetzteile

Modelltreue ist ein Budget, das Sie für Berechnungen und Zeitmargen aufwenden. Die CPU-Simulation eignet sich gut für gemittelte und phasorartige Modelle und kann nur dann Schaltmodelle verarbeiten, wenn der Zeitschritt überschaubar bleibt. Die FPGA-Simulation ist für Schaltlogik mit sehr kleinen Zeitschritten ausgelegt, allerdings müssen Sie dabei einige Modellierungsvorteile einbüßen. Das richtige Ziel ist das einfachste Modell, das dennoch Ihre Testfrage beantwortet.

Schaltgeräte werden immer schneller, was den Zeitdruck im Simulator erhöht. Schaltübergänge nahe 50 ns wurden in Siliziumkarbid-Geräten demonstriert, was zeigt, wie viele Details innerhalb einer einzigen Mikrosekunde Verhalten vorhanden sein können. Sie werden Nanosekunden-Flanken nicht in Echtzeit simulieren, aber diese Geschwindigkeit verdeutlicht, warum Totzeit, Diodenrückgewinnung und dv/dt-bezogene Effekte empfindlich auf die Wahl der Solver-Schritte reagieren können. Wenn Ihre Akzeptanzkriterien Spitzenstrom, Überspannungsauslösungen oder Austastzeiten umfassen, werden Sie diese Grenzen schnell spüren.

Fidelity-Entscheidungen verändern auch, was Sie mit Sicherheit validieren können. Durchschnittsmodelle bieten eine saubere Abstimmung der Regelschleife und ein sauberes Leistungsflussverhalten, können jedoch Fehler auf Zyklusebene und Schaltwelligkeiten verbergen, die mit der Strommessung interagieren. Schaltmodelle erfassen diese Effekte, können Sie jedoch dazu zwingen, an anderer Stelle Vereinfachungen vorzunehmen, um Termine einzuhalten. Ein praktischer Ansatz besteht darin, die Genauigkeit an das zu beurteilende Signal anzupassen und dann alle zusätzlichen Details als Risiko für die Echtzeitausführung zu behandeln, es sei denn, Sie können nachweisen, dass sie über alle Betriebspunkte hinweg stabil bleiben.

„Wählen Sie eine CPU, wenn Ihr Modell Flexibilität erfordert, und wählen Sie einen FPGA, wenn es deterministisches Timing im Sub-Mikrosekundenbereich benötigt.“

Planen Sie die Aufteilung zwischen CPU und FPGA in HIL-Setups.

Die Partitionierung funktioniert, wenn Sie jede Aufgabe auf den Prozessor legen, der ihren zeitlichen Anforderungen entspricht. Schnelle Umschalt- und Schutzpfade gehören dorthin, wo die Ausführung deterministisch ist, während langsamere Anlagendynamiken und Überwachungslogik dorthin gehören, wo die Modellierung Flexibel ist. Die Schnittstelle zwischen ihnen muss absichtlich abgetastet, skaliert und synchronisiert werden. Wenn die Grenze ungenau ist, werden Sie Artefakte verfolgen, die wie Steuerungsprobleme aussehen.

Ein konkretes Beispiel verdeutlicht, wie dies funktioniert. Ein Team, das einen zweistufigen netzgekoppelten Wechselrichter validiert, kann die PWM-Erzeugung, den komparatorartigen Überstromschutz und die Schaltstufe auf dem FPGA in Schritten von weniger als einer Mikrosekunde ausführen, während die Netzimpedanz, die Phasenregelschleife und die Leistungsberechnungen auf der CPU in größeren Schritten mit Ratenübergängen ausgeführt werden. Diese Aufteilung sorgt für ein enges Timing, wo Schutz und Schaltung es benötigen, und bewahrt gleichzeitig CPU-Headroom für Testautomatisierung und Parametersweeps. OPAL-RT-Systeme werden häufig in diesem gemischten Rechenstil verwendet, da sie die CPU- und FPGA-Ausführung unter einem HIL-Workflow unterstützen, was Ingenieur:innen die Arbeit erleichtert, Ingenieur:innen sie eigene Lösungen entwickeln müssen.

Planen Sie die Grenze wie einen I/O und nicht wie eine software . Entscheiden Sie, welche Signale die CPU-zu-FPGA-Leitung überqueren, wählen Sie explizite Abtastraten und legen Sie fest, wie Sie mit Quantisierung und Sättigung umgehen. Die Latenz muss durchgängig gemessen werden, einschließlich A/D, Solver-Schritt-Ausrichtung und D/A-Aktualisierungen. Wenn Sie die Partitionierung als Timing-Architektur betrachten, wissen Sie, welcher Teil des Systems für jede Mikrosekunde Verzögerung verantwortlich ist.

Aufwand für Toolchain, Debugging und Modellaktualisierung berücksichtigen

CPU-Modelle werden schnell aktualisiert, und die Debugging-Schleife ist den meisten Entwicklerteams vertraut. FPGA-Modelle erfordern mehr Vorausplanung, da Kompilierung, Ressourcenbeschränkungen und Festkomma-Auswahl Teil der Entwicklungsarbeit werden. Dieser Aufwand zahlt sich aus, wenn Sie deterministisches Timing benötigen, verlangsamt jedoch die Iteration, wenn Sie zu früh zu viel ändern. Ein stufenweiser Ansatz hält das Projekt am Laufen, während Sie festlegen, was deterministisch sein muss.

Auch das Debugging fühlt sich anders an. CPU-Workflows unterstützen Breakpoints, Profiler und schnelle Neuaufbauten, während FPGA-Workflows eher auf Assertions, Signalerfassung und sorgfältiger Überprüfung von Timing und Skalierung basieren. Modelländerungen, die auf der CPU trivial sind, können auf dem FPGA eine erneute Prüfung der numerischen Bereiche, eine Überprüfung des Sättigungsverhaltens und eine Validierung I/O erfordern. Teams erzielen reibungslosere Ergebnisse, wenn sie die FPGA-Arbeit wie ein eingebettetes Design mit formalen Prüfungen behandeln und nicht wie einen Last-Minute-Performance-Patch.

• Ihr kleinster erforderlicher Zeitschritt und die schlechteste Rechenmarge bei diesem Schritt.
• Ihr zulässiger Jitter im schlimmsten Fall bei PWM, Auslösungen und abgetasteten Schutzsignalen.
• Ihr Plan für Festkomma-Bereich, Skalierung und Sättigungsprüfungen.
• Die von Ihnen erwartete Häufigkeit von Modelländerungen nach der ersten stabilen Baseline.
• Ihre Fähigkeit, das zeitliche und numerische Verhalten über Testumgebungen hinweg zu reproduzieren.

Kosten- und Zeitplanrisiken entstehen in der Regel durch Reibungsverluste im Arbeitsablauf und nicht durch die reine Rechenleistung. Die CPU-Auslastung kann sich ausweiten, wenn Sie bis zum Verpassen der Fristen immer mehr Details hinzufügen, während die FPGA-Auslastung ins Stocken geraten kann, wenn Sie mit einem zu großen Umfang und einer zu geringen Verifizierungsstruktur beginnen. Legen Sie klare Grenzen fest, was „fertig“ in Bezug auf Zeitplan, Genauigkeit und I/O bedeutet. Diese Disziplin sorgt dafür, dass das Team auch dann an einem Strang zieht, wenn die Testergebnisse unklar sind.

Wählen Sie eine HIL-Simulationsplattform, die mit Ihren Projekten mitwächst.

Eine HIL-Plattform ist für Sie von großem Nutzen, wenn Sie damit Zeitvorgaben einhalten, ein nachvollziehbares Modellverhalten gewährleisten und die Iterationsgeschwindigkeit auch bei wachsenden Projekten hoch halten können. Die CPU-Kapazität allein reicht nicht aus, um einen Prüfstand zu retten, der deterministische I/O benötigt, und der Determinismus von FPGAs allein reicht nicht aus, um einen Prüfstand zu retten, der ständige Modelländerungen und einen multidisziplinären Anwendungsbereich erfordert. Die beste Wahl ist in der Regel eine Plattform, die CPU- und FPGA-Berechnungen unterstützt und es Ihnen ermöglicht, Grenzen zu verschieben, ohne alles neu schreiben zu müssen. Sie kaufen eher ein wiederholbares Ausführungsmodell als einen Prozessor Kategorie.

Konzentrieren Sie sich auf einige wenige Plattformmerkmale, die sich auf die tägliche Arbeit auswirken. Deterministisches I/O , klare Handhabung von Ratenübergängen und zuverlässige Synchronisationstools sind jede Woche von Bedeutung. Hardware ist wichtig, da die Anzahl der Kanäle und Sensortypen in der Regel über verschiedene Programme hinweg zunimmt. Software ist wichtig, da Ihr Team MATLAB, Python, Testsequenzer und Datenpipelines miteinander verbinden wird und geschlossene Stacks eine einfache Integration zu einem Projekt machen.

Gutes technisches Urteilsvermögen zeigt sich darin, wie Sie den Simulator über einen längeren Zeitraum hinweg zuverlässig halten. Legen Sie frühzeitig Zeitbudgets fest und erhöhen Sie dann die Genauigkeit nur, wenn sich dadurch das Ergebnis „bestanden“ oder „nicht bestanden“ ändert. Halten Sie CPU-Modelle Flexibel Lernzwecke Flexibel und konzentrieren Sie sich bei FPGA-Modellen auf die Teile, bei denen Determinismus unverzichtbar ist. OPAL-RT passt zu dieser „Execution-First”-Denkweise, wenn Sie beide Rechentypen auf derselben Plattform benötigen, sodass Sie FPGA als präzises Timing-Tool und CPU als Iterationstool behandeln können, anstatt eines davon zu beiden Aufgaben zu zwingen.