Hardware muss in der Lage sein, jede Software auszuführen. Während das vielleicht ein gutes Mantra war, als Chips noch relativ einfach waren, wird es zu einer unmöglichen Verifikationsaufgabe, wenn man es mit SoCs zu tun hat, die Dutzende von tief eingebetteten Prozessoren enthalten. Wann wird es notwendig, Produktionssoftware zu verwenden und welche Probleme kann das mit sich bringen?
Wenn Verifikationsziele wie der Stromverbrauch hinzukommen, wird es noch viel komplizierter, wie ein Hersteller von Telefonmodems vor ein paar Jahren herausfand. Sein Chip hatte Überhitzungsprobleme in einem Telefon, funktionierte aber in einem Telefon eines Konkurrenten ganz zufriedenstellend. War dies ein Fehler in der Verifizierungsstrategie und vermeidbar, oder wird diese Art von Vorfällen wahrscheinlich immer häufiger auftreten?
Eine Schlüsselfrage ist hier, wie viel Software muss vor dem Silizium ausgeführt werden? „Software hat einen definierten Einfluss auf die Hardware“, betont Russell Klein, technischer Direktor bei Mentor, einem Siemens-Geschäft. „Genauer gesagt, treibt die Software eine Sequenz von Transaktionen in die Hardware. In jeder gegebenen Verifikation werden einige dieser Transaktionen wichtig sein, aber viele von ihnen sind überflüssig.“
Der Trick besteht darin, herauszufinden, was ignoriert werden kann.
Arten von Software
Nicht jede Software ist gleich. „Alles stützt sich auf Software, Firmware oder Middleware“, sagt Rupert Baines, CEO von UltraSoC. „Fast immer wird Software auf mehreren Geräten laufen, oft auf Geräten mit unterschiedlichen Architekturen, oder sie interagiert auf sehr schwierige, komplexe, unvorhersehbare Weise.“
Aber es gibt auch andere Möglichkeiten, die von Software bereitgestellte Funktionalität zu betrachten. „Software auf Anwendungsebene leitet den Datenverkehr in einem System auf einer hohen Ebene, wie beispielsweise RTOS-basierte Anwendungssoftware“, sagt Gordon Allan, Produktmanager bei Mentor. „Auf der untersten Ebene, wie z. B. einem DSP-Codec ganz unten in der Pipeline, läuft ohne diese Software eigentlich gar nichts. Dann gibt es eine Zwischenebene, die ich als strukturelle Software bezeichne, wo sie für den Betrieb intrinsisch ist. Ohne diese Software läuft nichts und sie ist schwer durch eine andere Darstellung zu ersetzen, da sie nicht algorithmisch ist. Es ist eher wie Logik, die zufällig in Software implementiert ist.“
Klein fügt einige Beispiele für diese Zwischenebene hinzu. „Es gibt üblicherweise Power-Management-Prozessoren, Sicherheitsprozessoren und eine Vielzahl anderer tief eingebetteter Prozessoren in einem SoC. Diese Prozessoren sind für den Endanwender des Geräts nicht zugänglich. Jede Software, die auf ihnen läuft, wird vom Entwickler des SoCs geschrieben und muss in jede signifikante Simulation auf Systemebene einbezogen werden.“
System-Level-Simulation mit etwas Software ist eine Notwendigkeit. „Um eine Hardware/Software-Ko-Validierung zu ermöglichen, sind zwei wichtige Bestandteile notwendig“, sagt Roland Jancke, Leiter unserer Abteilung für Entwurfsmethodik am Fraunhofer EAS. „Erstens brauchen wir eine abstrakte Darstellung des Systems und seiner Komponenten, die schnell genug für die Komplexität ist. Und dann brauchen wir eine Sprache, die sowohl die Beschreibung von Software- als auch von Hardwarekomponenten unterstützt, um beide Sichten in einem Simulationsmodell abzudecken.“
Wie viel Software?
Der Umfang der benötigten Software hängt von der Verifikationsaufgabe ab. „Suchen wir nach Fehlern in der RTL oder verifizieren wir die Firmware?“, fragt Allan. „Verifizieren wir die Integration von zwei wiederverwendeten Blöcken? Verifizieren wir einige Aspekte der Leistung? Solange wir diese Fragen stellen und die Möglichkeiten in Bezug auf den Aufbau einer Verifikationslösung kennen, können wir ein optimiertes System erstellen. Sobald wir die Grenzen verwischen, verifizieren wir plötzlich einen ganzen Stapel von Anwendungssoftware und müssen mehr Emulatoren kaufen.“
Und man kann es sich nicht leisten, die Firmware-Verifikation zu vermeiden. „Wir haben sehr gute Tools für die Arbeit an der Hardware, und es ist mittlerweile recht ungewöhnlich, dass ein Chip wegen eines Verdrahtungs- oder Logikproblems ausfällt“, sagt Baines. „Allerdings hören wir zunehmend von Produkten, die drei, sechs oder neun Monate zu spät kommen, weil es Probleme mit der Firmware gibt.“
Aber Firmware kann sich ändern. Bedeutet das, dass wir die gesamte zugehörige Verifikation neu machen müssen? Vielleicht nicht, aber man muss Vertrauen in die unteren Ebenen haben, und das bedeutet, dass wir eine solide hierarchische Verifikationsgrundlage nicht vergessen dürfen.
„Wir können mit der Simulation beginnen und zur Emulation übergehen und haben am Ende viel Vertrauen in die unteren Ebenen“, sagt Baines. „Dann können wir eine Abstraktionsebene höher gehen und aufhören, über absolutes Timing und Signale und Race Conditions nachzudenken, und anfangen, über Transaktionen und die Systemebene nachzudenken, während wir zur Emulation und dann zum Prototyping übergehen. Es wird machbar, einen kompletten Software-Stack von etwas auszuführen – nicht mit echter Geschwindigkeit, sondern mit einem Bruchteil der echten Geschwindigkeit. Aber es ist echte Software, und das verschafft Ihnen einen großen Vorsprung im Verifikations- und Debugging-Prozess. Da es nicht in Echtzeit ist, bedeutet das, dass es eine Menge Probleme geben wird, die man nicht sieht, aber man bekommt eine Menge Vertrauen.“