Verkürzung des Designzyklus in gemeinsam entworfenen SoCs mit Renode

In diesem Artikel erklären wir, wie der Einsatz von Open-Source-Funktionssimulatoren wie Renode von Antmicro ein wesentlicher Bestandteil des gemeinsamen Hardware-Software-Designs sein kann .

In diesem Artikel erklären wir, wie die Verwendung von Open-Source-Funktionssimulatoren wie Renode von Antmicro ein integraler Bestandteil der gemeinsamen Entwicklung von Hardware und Software sein kann.

Da die Märkte mehr von ihren eingebetteten Systemen verlangen, werden SoCs der nächsten Generation komplexer, was laut Semico Research zu längeren Designzyklen und steigenden Kosten führt.

Die frustrierende Realität für Gerätehersteller ist, dass der einzige Weg, um die neuen und innovativen Funktionen, mehr Sicherheit und bessere Leistung zu liefern, die ihre Kunden verlangen, darin besteht, sich am „Whole-Stack“-Co-Design zu beteiligen und Hardware, Firmware und Laufzeit weiterzuentwickeln (OS) und Entwicklungs-Toolchain im Tandem. Auf diese Weise können Hardware- und Softwareteams komplexe Kompromisse hinsichtlich der Position im Stack eingehen, um Funktionen und Optimierungen zu implementieren.

Leider ist Co-Design oft der Hauptgrund für die Verlängerung der Designzyklen – und damit der Kosten –, wenn keine geeigneten Simulationstools vorhanden sind.

In diesem Artikel erklären wir, wie der Einsatz von Open-Source-Funktionssimulatoren wie Renode von Antmicro ein integraler Bestandteil des gemeinsamen Hardware-Software-Designs sein kann. Darüber hinaus zeigen wir Ihnen ein Beispiel dafür, wie Renode-Anwender das Tool nutzen können, um die Länge ihrer Designzyklen drastisch zu verkürzen, Kunden eine einfache und effektive Möglichkeit zu bieten, ihre Lösungen zu evaluieren und parallel mit der Anpassung von Software-Materialien zu beginnen mit Hardwareintegrationsbemühungen.

Wo Software-Simulatoren zu kurz kommen

Die Bedeutung der Auswahl des richtigen Simulationstools wird am besten im Fall von Dover Microsystems veranschaulicht.

Die CoreGuard®-Technologie von Dover ist die einzige Lösung, die das Ausnutzen von Software-Schwachstellen verhindert und es Prozessoren ermöglicht, sich gegen netzwerkbasierte Angriffe zu verteidigen. Dover konnte dies durch acht Jahre Forschung und Entwicklung erreichen – zuerst als größter Performer im DARPA-Crash-Programm und dann bei Draper Labs –, was zu einer einzigartigen Hardware/Software-Hybridlösung für eingebettete Systeme führte.

Diese Hybridlösung erfordert eine enge Integration zwischen Hardware- und Softwarekomponenten. CoreGuard Silicon IP ist ein Wachprozessor, der als Leibwächter fungiert und eingebettete Systeme vor Cyberangriffen schützt. Es überwacht jede vom Host-Prozessor ausgeführte Anweisung, um sicherzustellen, dass sie einem definierten Satz von Sicherheits- und Datenschutzregeln, den sogenannten Mikrorichtlinien – der Softwarekomponente von CoreGuard – entspricht. Wenn eine Anweisung gegen eine bestehende Regel verstößt, stoppt CoreGuard die Ausführung, bevor Schaden angerichtet werden kann.

Um dies zu erreichen, muss CoreGuard mit der Ausführung des Host-Prozessors Schritt halten. Das heißt, er muss im Durchschnitt in der Lage sein, Befehle mit der gleichen Rate wie der zu schützende Host-Prozessor zurückzuziehen (über Mikrorichtlinien zu genehmigen). Es ist auch wünschenswert, dass CoreGuard den für die Metadatenverwaltung erforderlichen Speicher minimiert.

Daher erfordert die Erfüllung der Leistungs-, Leistungs- und Flächenanforderungen ein komplexes Zusammenspiel von Optimierungen sowohl auf Hardware- als auch auf Softwareebene.

Das Hardware-Team bei Dover verwendet einen standardmäßigen SystemVerilog-basierten Prozess und eine Toolchain. Erste Prototypen des CoreGuard-Systems basieren auf RISC-V-basierten SoCs. Da CoreGuard neben der Hardware-IP über eine wesentliche Softwarekomponente verfügt, war es wichtig, dass das Softwareteam rechtzeitig beginnen kann, bevor Hardware-Prototypen verfügbar waren.

Das Softwareteam von Dover verwendete zunächst den Spike RISC-V ISA-Softwaresimulator, der über die RISC-V GitHub-Repositorys verfügbar ist. Bei der kommerziellen Entwicklung von CoreGuard rund um Spike stießen sie auf zwei Probleme:

1. Spike bietet keine realistischen Peripheriegeräte; das heißt, Spike ist ein ISA-Simulator, kein SoC-Simulator. Das Dover-Team begann damit, Spike Peripheriegeräte wie UARTs und persistenten Speicher hinzuzufügen, und das war eine Menge Arbeit.
2. Spike ist per Definition RISC-V-spezifisch, aber die ersten Kunden von Dover Microsystems sind sowohl RISC-V- als auch ARM-basiert.

Diese Mängel unterstrichen den Bedarf von Dover an einem flexiblen Multi-Architektur-Simulator mit dem Konzept der Peripheriemodelle, der anstelle von Spike verwendet werden sollte.

Wie Renode wichtige Co-Design-Anforderungen erfüllt

Sich ähnlichen heterogenen Herausforderungen im Hardware-/Software-Codesign-Engineering stellen, die sich aus der Arbeit mit Open-Source-Softcores, früher Software für führende Computerplattformen, FPGA-SoCs und aufkommenden CPU-Architekturen wie RISC-V, Antmicro – einem Open-Source-fokussierten Technologie- und Dienstleistungsanbieter – entwickelte ein flexibles Simulationsframework namens Renode.

Renode ist ein hierarchisches, modulares Simulations-Framework, das darauf abzielt, reale Produktions-Firmware (dh unmodifizierte) in einer Vielzahl komplexer Systeme auszuführen, einschließlich miteinander verbundener Multi-Node-, Multi-Architektur-, heterogener, MCU-Level- und Linux-fähiger Systeme.

Um diese unterschiedlichen Komplexitätsebenen zu bewältigen, basiert Renode auf einem starken Abstraktionsgedanken und verfolgt einen objektorientierten, modularen Ansatz für die Systemsimulation. Kerne und Peripherie werden als Bausteine ​​angesehen, die über Schnittstellen in verschiedenen Konfigurationen verbunden werden können, was widerspiegelt, wie echte SoCs gebaut werden.

Abbildung 1. Ein Beispiel für einen simulierten RISC-V-SoC.

Abbildung 1 zeigt ein Beispiel für einen simulierten RISC-V-SoC. Jeder Baustein, einschließlich der CPU, verfügt über eine Reihe von Eigenschaften und APIs, mit denen das Simulationsmodell des gesamten SoC erstellt werden kann. Ebenso können einzelne Knoten mit virtualisierten drahtlosen und drahtgebundenen Verbindungen (6LoWPAN, UART, Ethernet usw.) zu einem Mehrknotensystem weiter kombiniert werden. All dies erfordert keine Änderungen an der Codebasis von Renode, sondern erfolgt über Konfiguration und Skripting, wodurch die Lernkurve verkürzt und die Fragmentierung der Codebasis begrenzt wird.

Die Flexibilität des Renode-Frameworks, seine Open-Source-Verfügbarkeit und die Existenz kommerzieller Unterstützung durch seine Autoren machten es Dover leicht, zunächst eine Prototyp-Implementierung des gewünschten Workflows zu erstellen und dann Antmicro mit der Implementierung zu beauftragen (und in die Open-Source-Umgebung zu veröffentlichen). Quelldomäne) Funktionalitäten, die Renode noch besser für ihren Anwendungsfall geeignet machten, wie die Anweisungsausführung.

Insbesondere können die Dover-Ingenieure mit Renode jetzt:

• Wechseln Sie zwischen Arm- und RISC-V-basierten Integrationsbemühungen mit demselben Setup.
• Prototyp-SoCs (sowohl Referenz/Minimal als auch kundendefiniert) mit unterschiedlichen Detaillierungs-/Wiedergabeebenen.

Modellieren Sie die Hardwarearchitekturspezifikation der Hardwaregruppe von Dover, schreiben und testen Sie dann die Firmware anhand dieser Modelle, während die Hardware noch in der Entwicklung ist.

Wie Renode den Designzyklus von Dover erheblich verkürzte

Die CoreGuard-Technologie von Dover ist ein hybrides Cybersicherheitsprodukt, bei dem sich sowohl Hardware- als auch Softwaredesigns weiterentwickeln. Daher ist es wichtig, dass der Entwicklungsprozess von Dover die parallele Entwicklung und das Testen von Hardware und Software ermöglicht.

Abbildung 2. Der von Dover verwendete Entwicklungsprozess.

Dover verwendet den in Abbildung 2 skizzierten Entwicklungsprozess. Die Hardware- und Softwareteams arbeiten an der Hardwareschnittstelle (die natürlich weiter entwickelt wird) zusammen. Während das Hardwareteam mit der Implementierung von Blöcken in SystemVerilog beginnt, erstellt das Softwareteam Modelle der neuen Blöcke in C#, der Muttersprache von Renode. Das Softwareteam ist dann in der Lage, Firmware zu schreiben, die mit den neuen Hardwareschnittstellen kommuniziert, und diese Software unter Renode-Simulation zu testen. Schließlich wird die Software auf einem FPGA-Emulator ausgeführt.

Dieser von Renode ermöglichte Entwicklungsprozess hat Dover geholfen, sowohl „low fidelity“- als auch „high fidelity“-Simulationen zu optimieren.

Während diese „low fidelity“-Simulation die gesamte Hardwarelogik von CoreGuard abstrahiert, findet Dover dieses Setup dennoch in den folgenden Kontexten nützlich:

• Mikrorichtlinien-Debugging: Wenn neue CoreGuard-Mikrorichtlinien entwickelt werden, möchten wir schnell eine Reihe von Softwaretests durchlaufen, um das Verhalten zu überprüfen.
• Demos und Kundenvorschauen: Bei CoreGuard-Demonstrationen reicht oft eine reine Softwaresimulation aus, um einen potenziellen Kunden über die Fähigkeiten von CoreGuard® aufzuklären und das Interesse an weiteren Diskussionen zu wecken. Darüber hinaus liefert Dover seinen Kunden häufig ein „SDK“, das aus diesem „Low-Fidelity“-Simulator mit einigen vordefinierten Mikrorichtlinien besteht, damit der Kunde mit CoreGuard „spielen“ kann, einschließlich möglicherweise der Ausführung von CoreGuard-Mikrorichtlinien gegen die Software des Kunden.

Bei „High-Fidelity“-Simulationen, die ein genaueres Hardwaremodell nachbilden, konnte das Ingenieursteam von Dover eine Reihe von Vorteilen von Renode erkennen, darunter:

• Integration mit verschiedenen Nicht-ELF-Binärformaten (z. B. Scatter-Load), die von Hardware-Boot-ROMs verwendet werden.
• Entwickeln und Testen des Bootvorgangs; Kopieren von Flash in RAM, Initialisieren von Geräten.
• Debugging von Busverkehr mit Renode-Instrumentierung.
• Debugging von Peripheriegeräten (UARTs, PICs, die CoreGuard-Schnittstelle selbst) durch Instrumentierung.
• Spielen mit der Speicherkarte.
• Implementieren der HDMI-Video-Firmware, bevor die Hardware funktionierte.

Wie bereits erwähnt, gibt es einige schwierige Leistungs- und Bereichseinschränkungen, die Lösungen der nächsten Generation wie CoreGuard den SoC-Designteams während der Implementierung auferlegen.

Um die Leistung zu steigern und den Speicherverbrauch zu reduzieren, müssen zahlreiche Optimierungen vorgenommen werden, die häufig die Hardware-/Software-Grenze überschreiten.

Es ist von entscheidender Bedeutung, dass Designteams in der Lage sind, eine Vielzahl möglicher Techniken und Kompromisse zur Hardware-/Software-Kooptimierung zu untersuchen, ohne einen großen, serialisierten „Erst-Hardware-dann-Software-Entwicklungsprozess“. Ein flexibler Software-Funktionssimulator wie Renode ermöglicht es den Dover-Ingenieuren, über die Hardware-Software-Kluft hinweg zusammenzuarbeiten, um optimale Kompromisse zwischen Hardware- und Softwarekomplexität zu finden, und wird so zu einem integralen Bestandteil ihrer Bemühungen.

Um mehr darüber zu erfahren, wie Renode Co-Design-Projekte rationalisieren kann, besuchen Sie renode.io. Um mehr darüber zu erfahren, wie CoreGuard eingebettete Systeme vor netzwerkbasierten Angriffen schützen kann, fordern Sie eine Demo an, um CoreGuard in Aktion zu sehen.

Dieser Artikel wurde von Michael Gielda, VP Business Development und Mitbegründer von Antmicro, mitverfasst.

Branchenartikel sind eine Inhaltsform, die es Branchenpartnern ermöglicht, nützliche Nachrichten, Nachrichten und Technologien mit All About Circuits-Lesern auf eine Weise zu teilen, für die redaktionelle Inhalte nicht gut geeignet sind. Alle Branchenartikel unterliegen strengen redaktionellen Richtlinien, um den Lesern nützliche Neuigkeiten, technisches Know-how oder Geschichten zu bieten. Die in Branchenartikeln zum Ausdruck gebrachten Standpunkte und Meinungen sind die des Partners und nicht unbedingt die von All About Circuits oder seinen Autoren.