Embedded-Software Anforderungen an Entwicklungs-Tools steigen

Unerlässlich ist mittlerweile eine hohe Flexibilität der Entwicklungstools beim Zugang zu den verschiedenen Targets
Unerlässlich ist mittlerweile eine hohe Flexibilität der Entwicklungstools beim Zugang zu den verschiedenen Targets

Die Anforderungen an embedded-Software-Entwicklungssysteme sind in den letzten Jahren drastisch gestiegen – vor allem in den Bereichen Test und Debugging. Extrem leistungsfähige Multicore-SoCs, die immer mehr Funktionen integrieren, erfordern in mancherlei Hinsicht ein radikales Umdenken.

Es ist noch gar nicht lange her, dass in Mikrocontroller-Applikationen die Hardware die Wertschöpfungskette klar dominierte. Inzwischen allerdings hat sich zumindest im High-End-Bereich das Verhältnis klar zugunsten der Software gewandelt. Weil die Software nicht nur den größten Anteil der Wertschöpfung, sondern auch der Entwicklungszeit einnimmt, sollte möglichst früh mit der Implementierung begonnen werden. Bei großen Projekten geschieht das heutzutage schon lange bevor erste reale Exemplare neuer Mikrocontroller zur Verfügung stehen. Während dieser Phase dienen Entwicklungssysteme in der Regel vor allem als Frontend für virtuelle Targets, also für Software-Systeme, mit denen sich ganze SoCs oder Teile davon simulieren lassen. Das hat den Vorteil, dass von Beginn an alle an der Produktentwicklung beteiligten Personen mit der gleichen Bedienoberfläche arbeiten können, was letztlich nicht nur Zeit, sondern auch Kosten spart.

Bilder: 4

Designtools und Entwicklungssysteme: Auf die Flexibilität kommt's an

Designtools und Entwicklungssysteme: Auf die Flexibilität kommt's an

Für die Entwicklungssystemhersteller bedeutet die Anpassung an die Simulatoren verschiedener Hersteller eine enorme Herausforderung. Schließlich gilt es, nicht nur die unterschiedliche Leistungsfähigkeit der Simulatoren, sondern auch die Unterschiede zur kommenden realen Hardware zu berücksichtigen und möglichst nahtlos in die Bedienoberfläche zu integrieren. Klar im Vorteil sind hierbei modular aufgebaute Entwicklungstools mit strikter Trennung von Funktionalität und Visualisierung, weil bei diesen nur die betroffenen Komponenten ausgetauscht werden müssen. Als standardisierte Schnittstelle zwischen den Simulatoren und Frontends verschiedener Hersteller etabliert sich gegenwärtig die so genannte Multi-Core-Debug-API (MCD-API), die von verschiedenen Anbietern bereits genutzt wird.

Hardware-unterstützte Simulation

Ein anderer Einsatzbereich für Entwicklungssysteme während der Phase, in der noch kein reales Silizium zur Verfügung steht, basiert darauf, dass die Halbleiterhersteller ihre Entwürfe mit hardwareunterstützter Simulation bzw. durch Emulation verifizieren. Ein typisches Beispiel für eine solche Hardware-Software-Co-Verifikation ist die Palladium-Serie von Cadence, die SoC-Entwicklern in der höchsten Ausbaustufe bis zu 256 Millionen ASIC-Gatter zur Verfügung stellt. Weil in diesem Fall auch die On-chip-Debug-Hardware und die Schnittstellen emuliert werden, besteht für die Entwicklungssystem-Hersteller die Möglichkeit, ihre Tools ebenfalls vor Verfügbarkeit der ersten Bausteine anzupassen und zu verifizieren. Dazu muss die zu einem professionellen Entwicklungssystem gehörende Debug-Hardware-Probe zur Signalkonditionierung und -verarbeitung lediglich an den Hardware-Emulator angeschlossen sein. Dieser kann sich – eine geschützte VPN-Verbindung für die sichere Steuerung über das Internet vorausgesetzt – auch viele tausend Kilometer von der Entwicklungsabteilung des Toolherstellers entfernt befinden.

In der realen Anwendung ist das Szenario komplexer. Schließlich muss auf der Debug-Probe, die später eine neue Mikrocontroller-Architektur unterstützen soll, Software getestet, gedebuggt und modifiziert werden. Idealerweise hat die Debug-Probe deshalb einen Ethernet-Anschluss, der auch dann von Vorteil ist, wenn am Beginn eines Projekts mehrere Software-Entwickler gemeinsam an einem der raren Hardware-Prototypen arbeiten müssen.