Startseite > Embedded > Entwicklungstools > Verteilte Systeme akkurat entwickeln

Systemdesign / Entwicklungsmanagement

Verteilte Systeme akkurat entwickeln

8. Oktober 2018, 12:33 Uhr | Frank Schirrmeister, Senior Group Director, Product Management, System & Verification Group, Cadence

▶ Diesen Artikel anhören

Fortsetzung des Artikels von Teil 1

Der Entwicklungsablauf verteilter Systeme

Ein klassischer Entwicklungsablauf beginnt mit der Systemspezifikation. Darauf folgt die Implementierung und Verifikation des Chips in Verilog oder VHDL auf der Register-Transfer-Ebene (RTL) durch Hardware-Ingenieure. Im Vergleich zur Entwicklung und Verifikation von RTL, erfordert die Entwicklung von Blöcken auf der Transaktionsebene einen geringeren Aufwand, da weniger Details beschrieben sind. Dies führt zwar zu weniger präzisen Modellen, die aber wiederum gut und früh in der Software-Entwicklung eingesetzt werden können. Entwürfe auf der RTL-Ebene werden zunächst in der Simulation ausgeführt. Ist das RTL einigermaßen stabil, können Subsysteme oder komplette SoC in Emulation ausgeführt werden oder auch in FPGA-basierten Prototypen. Sobald die ersten Silizium-Prototypen verfügbar sind, können diese auch für die Software-Entwicklung zur Verfügung gestellt werden. Auf der einen Seite gibt es hardwarebewusste Software-Entwicklung für die OS-Portierung und Entwicklung der unteren Schichten des Software-Stacks. Auf der anderen Seite steht Anwendungssoftware, die unabhängig von der Hardware entwickelt werden kann. Um die Gefahr eines Korrekturentwurfs des SoC zu vermindern, muss die Integration von Hard- und Software ausgeführt werden bevor der Chip zur Fabrikation freigegeben wird. In der Industrie wird dieser Trend zur frühen Software-Entwicklung oft als „Shift-Left“ bezeichnet.

Hardware/Software-Debug

Dazu nutzt die Entwicklung verteilter Systeme verschiedene Darstellungen der zu entwickelnden Hardware. Eine zusammenfassende Übersicht aller solcher Plattformen zeigt Bild 2.

Software Development Kits (SDKs), beispielsweise für Android und iOS, führen nicht dieselbe Software aus, die später unverändert auf dem Board läuft. Vor der Ausführung der SDK-Beschreibung auf der Hardware ist eine Umkompilierung der Software erforderlich. Die Hauptnutzer sind Anwendungsentwickler, die nur ein minimales Verständnis der Hardware-Details benötigen. SDKs bieten eine hohe Entwicklungsgeschwindigkeit, aber keine Genauigkeit in der Hardwaredarstellung. Komplexe Berechnungen, wie in Grafik- und Video-Applikationen notwendig, werden abstrahiert. Architekturpräzise virtuelle Prototypen auf der Basis von Transaktionsmodellen ermöglichen den Entwicklern, Entscheidungen bzgl. der Architektur zu treffen, und unter anderem auch die Validierung der Geschwindigkeit und der Verlustleistungsaufnahme.

Die zu testenden Systembereiche – wie eine Verzögerung durch Kommunikation und Speicherzugriffe - werden mit hoher Genauigkeit modelliert, vielleicht sogar abschnittsweise in Verilog oder VHDL.

Jobangebote+ passend zum Thema

MACNICA ATD EUROPE - Ihre berufliche Zukunft

MACNICA ATD Europe GmbH, Ingolstadt

Alle Jobangebote im Elektroniknet Karrierebereich anzeigen

Systemarchitekten und Validierungs-Ingenieure sind die Hauptnutzer. Die Geschwindigkeit kann je nach Genauigkeit der Darstellung stark variieren, liegt aber in der Regel zwischen 10 und 100 kHz. Softwarepräzise virtuelle Prototypen sind registerakkurat und führen dieselbe Software auf der Transaktionsebene aus, die ohne Umkompilierung später auch auf der Leiterplatte läuft. Geschwindigkeiten für virtuelle Prototypen erreichen nahezu Echtzeit. Zielanwender sind sowohl Software-Entwickler für Applikationen als auch hardwarebewusste Entwickler. Je nach Bedarf des Entwicklers kann ein gewisses Hardwaretiming genauer dargestellt werden. Diese Art von Prototypen kann auch von HW/SW-Validierungs-Ingenieuren verwendet werden, die sowohl Hardware- als auch Software-Details sehen müssen. Das Debug ist sehr wichtig für virtuelle Prototypen. Heutzutage werden sie überwiegend in IEEE-SystemC entwickelt und bedürfen einer zweckmäßigen Überprüfung. Bild 3 zeigt ein Beispiel für eine Debug-Umgebung, in welcher der Software-Quellcode mit Registern, Speichern und Peripheriekomponenten analysiert werden kann.

Sobald das RTL für die Hardware entwickelt ist, bieten RTL-basierte Prototypen höhere Genauigkeit. RTL-Simulation ist das Standardwerkzeug für die Hardware-Verifikation. Die zu entwickelnde Hardware ist in vollem Detail modelliert (zumindest auf digitaler Seite), das RTL wird zum goldenen Referenzmodell für die Hardwareentwicklung. Ein Emulator wie in Cadence Palladium Z1 bildet als spezielles Verifikationswerkzeug alle Designkomponenten nach. Prozessorbasierte Emulation bietet, mit einer relativ hohen Geschwindigkeit zwischen 1 und 2 MHz und schneller Kompilierung, einen genauen Einblick in die Hardwareausführung. Software-Debugger wie ARM DS-5 und Lauterbach Trace32 können über direkte proprietäre oder auch Standard-JTAG-Schnittstellen angebunden werden. Angesichts der höheren Geschwindigkeit kommen mehr Schnittstellen in realen Testszenarien hinzu.

Unter einigermaßen stabilem RTL, kann mit FPGA-basierten Prototypen eine noch schnellere hardwarebasierte Ausführungsumgebung, wie Cadence Protium S1, benutzt werden. Das funktioniert besonders gut für bereits in RTL-Form vorhandene IP. Siliziumbasierte Prototypen verwenden entweder einen Chip der ersten Tranche aus einem Projekt der vorherigen Generation oder Silizium-Samples. Der tatsächliche siliziumbasierte Prototyp kann verwendet werden, sobald der Chip wieder zurück aus der Fertigung ist. Dann können Anwender diesen bei realen Geschwindigkeiten und mit allen Schnittstellen ausführen. Das Debugging wird anspruchsvoller, da die Ausführungskontrolle nicht trivial ist. Das Starten, Stoppen und Pausieren der Ausführung an definierten Haltepunkten ist weniger einfach, als bei der softwarebasierten Ausführung in Simulation oder Emulation; zum Beispiel kann in einem heterogenen Multicore-System ein Haltepunkt einen der Prozessoren stoppen, während die anderen Hardwareanteile ihre Ausführung fortsetzen.