Hardware oder Software – Aufgabenverteilung bei der PLD-Entwicklung

Bei Diskussionen über die Entwicklungsmethodik von programmierbaren Logikbausteinen (PLD) mit den R&D-Abteilungen im Bereich Elektronik herrschen aktuell unterschiedliche Philosophien. Die Sichtweisen der Entwicklungsleiter gehen von: „FPGAs werden programmiert und die Firmwareentwicklung gehört zur Softwareentwicklung, da wir es mit VHDL und nicht mit C zu tun haben“ bis zu „Digitale Logik ist Hardwaredesign und daher gehört das FPGA-Design zur PCB-Entwicklung“. Daneben gibt es auch reine FPGA-Entwicklungsbereiche, die aber oft nur in größeren Unternehmen auftreten. Bild 1 zeigt als Beispiel für ein komplexes System ein Videointerface mit einem FPGA.

Bild 1: Videointerface mit einem FPGA für die Bereitstellung von standardkonformen Videodaten. Evision Systems

Bei der Entwicklung von programmierbarer Logik ist es in der Regel unmöglich, sich nicht mit den beiden Hardwarebeschreibungssprachen VHDL (VHSIC Hardware Description Language) und Verilog zu befassen. Auch wenn es immer wieder Ansätze gibt, FPGA-Beschreibungen automatisch aus anderen Abstraktionsebenen zu generieren, wie beispielsweise aus mathematischen Tools oder aus Softwaremodellen, erfolgt die FPGA-Entwicklung doch am häufigsten in VHDL oder Verilog. Besonders in Europa ist in vielen Firmen VHDL verbreitet. Die Sprache geht auf die VHSIC-Initiative (Very High Speed Integrated Circuit) der US-Regierung zurück, die 1987 zur Standardisierung von VHDL geführt hat. Idee dahinter war es, eine einheitliche, ausführbare und simulierbare Beschreibung hochkomplexer, digitaler Bausteine zu ermöglichen. Der Fokus lag auf der Modellierung von Hardware. Genau diese beiden Begriffe verursachen viele Diskussionen im Bereich der Entwicklungsmethodik.

PLD-Modellierung

Spätestens seit der Einführung von Synthese-Tools durch die EDA-Hersteller (Elektronic Design Automation) sind HDL-Beschreibungen nicht nur reine ausführbare Spezifikationen, sondern auch Modelle für die Implementierung. Die automatische Implementierung hat aber andere Anforderungen an die Beschreibung als die reine Simulation. Dadurch haben sich die Anforderungen an die Beschreibung geändert. Bis heute kann es daher passieren, dass bei ungünstig geschriebenem Code das Verhalten eines VHDL-Files in der Simulation von dem des synthetisierten Designs abweicht.

Hardware

Ursprünglich bestanden PLD-Bausteine wie FPGAs nur aus Logikzellen. Für die meisten Firmen folgte daraus, dass die Entwicklung dieser Bausteine ein Bestandteil der Hardwareentwicklung war. Für diesen Anwendungsfall waren auch die HDL-Sprachen konzipiert. Inzwischen befinden sich aber immer häufiger Softcores oder sogar Hardcores von Prozessoren auf einem FPGA. Die Anwendungen, die auf diesen CPUs laufen, sind dann wiederum Software.

Entwickler, die PLDs für sicherheitskritische Anwendungen entwickeln, sehen sich oft mit widersprüchlichen Anforderungen konfrontiert. Einige Standards behandeln VHDL mehr oder weniger wie Software, andere Standards unterscheiden klar zwischen Software- und Hardware-Anforderungen (zum Beispiel die Aerospace-Normen DO-254 für PLDs und die DO-178 für Software).

Für ein systematisches Vorgehen bei der Verifikation solch komplexer Bausteine wird es daher immer wichtiger, sich bei der Projektplanung Gedanken darüber zu machen, welche Anforderungen an die Methodik des jeweiligen Projekts bestehen, welche Expertise das Entwicklungsteam dafür benötigt und welche Werkzeuge zum Einsatz kommen sollen. Im Gegensatz zur Softwareentwicklung müssen bei der Verifikation komplexer FPGAs auch Verifikationsschritte auf sehr niedrigen Abstraktionsebenen durchgeführt werden. Dazu gehören neben der Analyse der Signallaufzeit auf dem Chip und der Abschätzung des Leistungsverbrauchs des Bausteins auch die richtige Verteilung gleichzeitig schaltender I/O-Leitungen auf den verschiedenen I/O-Bänken.

Während die Toolkette für die Softwareentwicklung meist recht übersichtlich ist, findet sich in aktuellen Entwicklungswerkzeugen komplexer FPGAs eine oftmals unübersichtliche Anzahl von speziellen Programmen. Dies liegt an der beschriebenen Vielfalt der Verifikationsaufgaben. Die Aufteilung dieser Aufgaben auf unterschiedliche Verifikationsdomänen ist eine einfache Möglichkeit, die Verifikation zu strukturieren. Hieraus ergibt sich oft auch, welche Methoden, Werkzeuge und Fertigkeiten beziehungsweise welches Wissen erforderlich ist, um die Aufgaben durchzuführen.

Wie sich die Code-Qualität überprüfen und die Funktionalität auf RTL-Ebene testen lässt, zeigt der Beitrag im Folgenden.

Überprüfen der Code-Qualität

Bild 2: Ausgänge von kombinatorischen Schaltungsteilen sollten niemals mit asynchronen Kontrollpins im FPGA verbunden sein. Design-Rule-Checker können solche Fehler automatisch finden. Evision Systems

Ein schlechter Kodierungsstil beim Erstellen der HDL Beschreibungen kann dazu führen, dass sich das Verhalten nach der Synthese vom Verhalten in der RTL-Simulation unterscheidet. Solche Abweichungen entstehen zum Beispiel, wenn die Regeln für synthetisierbare Designs nicht eingehalten werden. Das manuelle Überprüfen dieser Regeln ist zeitaufwändig und oft auch fehlerbehaftet. Verifikationsaufgaben dieser Art lassen sich einfach durch geeignete Tools automatisieren. Bei der Softwareentwicklung kommen diese Werkzeuge schon lange zum Einsatz,  während im Bereich der FPGA-Entwicklung erst in jüngster Zeit damit begonnen wird. In Frage kommen hierbei Design-Rule-Checker (Bild 2). Gute HDL-Eingabesysteme (zum Beispiel Sigasi) bieten diese Checks oft schon im Editor an. Daneben gibt es allerdings auch separate Design-Rule-Checker, die meist konfigurierbare Regelsätze anbieten (beispielsweise Alint von Aldec). Einen Schritt weiter gehen formale Code-Inspection-Systeme, mit denen sich auch unerreichbare Zustände, fehlerhafte Adressierungen oder das Propagieren unbekannter Signalzustände ohne Simulation herausfinden lassen (zum Beispiel 360 DV_Inspect von Onespin).

Funktionalität auf RTL-Ebene testen

Die Beschreibung der meisten PLD-Bausteine erfolgt auf der Register-Transfer-Ebene (RTL). Hierbei handelt es sich um eine Abstraktionsebene, die das Verhalten eines Bausteins Takt- und Bit-genau beschreibt. Diese Ebene kann Hierarchien, Beschreibungen von Protokollen, aber auch Elemente wie Register, Zähler, arithmetische Elemente oder Automaten enthalten. Um zu untersuchen, ob die Beschreibung auch die beabsichtige Funktion zum Ausdruck bringt, können grundsätzlich zwei verschiedene Methoden zum Einsatz kommen: die Überprüfung des Verhaltens mittels Simulation oder die Überprüfung des Verhaltens durch formale Verifikation. Der Simulationsansatz benötigt Stimuli für das Design-Under-Test, während der Verifikationsansatz den Vorteil bietet, dass keine Stimuli notwendig sind. Vielmehr werden die funktionalen Anforderungen durch Cover-Statements und Assertions zum Ausdruck gebracht. Cover-Statements beschreiben ein Verhalten, das durch einen formalen Beweis nachweisbar sein muss, Assertions hingegen ein verbotenes Verhalten, welches auf gar keinen Fall nachgewiesen werden darf.

Bei der Auswahl einer der Methoden ist es wichtig, die Stärken und Schwächen der verschiedenen Verfahren zu verstehen. Die formale Methodik bietet die Möglichkeit einer vollständigen Aussage, während die Simulation nur eine Aussage auf Basis der zur Verfügung gestellten Stimuli zulässt. Da die formale Verifikation jedoch alle vorhandenen Möglichkeiten durchrechnet, kann sie bei extrem komplexen und breiten arithmetischen Modulen oder bei Abläufen mit großer sequentieller Tiefe durchaus an ihre Grenzen stoßen. Hier macht oftmals eine Simulation auf Systemebene mehr Sinn. Auf der anderen Seite ist die Überprüfung mit der Simulation oft unvollständig und gerade bei sicherheitsrelevanten Funktionen lassen sich durch die Verwendung von formalen Werkzeugen versteckte Probleme finden. Die Frage sollte also bei der Verifikation von sicherheitsrelevanten Schaltungen nicht lauten: „Verwende ich die Simulation oder eine formale Verifikation?“, sondern „Welche Methode verwende ich für welche Teile der Verifikationsaufgabe?“.

Bei der Beurteilung spielen natürlich auch wirtschaftliche Betrachtungen eine Rolle. Entscheidend sollten hier aber nicht nur die direkten Kosten sein (Rechner, Software-Lizenzen, etc.), sondern die kompletten Aufwendungen des Verifikationsvorhabens. Dies schließt die Arbeitszeit der Ingenieure genauso ein wie Gewinnausfälle durch zu späte Markteinführung oder Rückrufaktionen wegen fehlerhafter Produkte. Design-Rule-Checker, Simulatoren und formale Verifikationswerkzeuge dienen insbesondere dazu, Fehler frühzeitig zu erkennen. Je früher ein Fehler erkannt und behoben wird, desto billiger ist es für das Unternehmen.

Auf der nächsten Seite erfahren Sie, wie sich die Implementierung überprüfen lässt und warum CPUs auf dem FPGA neue Designmethoden erfordern.

Überprüfen der Implementierung

Sobald ein PLD Baustein funktional beschrieben ist, wird das HDL-Modell in den Baustein implementiert. Dabei erfolgt in den meisten Fällen die Synthese der RTL-Beschreibung in eine technologiespezifische Netzliste. Im Anschluss geschieht das Mapping der Elemente der Netzliste auf die physikalischen Ressourcen im PLD Baustein und die Verbindung und Verteilung mittels Place&Route auf dem Baustein. Je nach Halbleiterhersteller sind die verschiedenen Schritte einzeln nachvollziehbar oder in komplexen Prozessen miteinander verschmolzen.

Bei der Erzeugung des endgültigen Konfigurationsfiles für den Baustein stellt sich natürlich die Frage, ob durch die verwendeten Werkzeuge oder deren Konfiguration keine Fehler hinzugefügt wurden.

Auch hier gibt es verschiedene Verifikationsstrategien. Bei der Simulation der implementierten Schaltung nach dem Place&Route-Prozess ermöglichen es die meisten Tool-Flows, ein HDL-File zu generieren. Dieses beschreibt die endgültig implementierte Funktion. Darauf basierend erfolgt eine Simulation wahlweise mit oder ohne Timing-Informationen. Anschließend wird das Ergebnis mit dem der RTL-Simulation verglichen. Dieses Vorgehen erkennt aber nur die Fehler, die mit den verwendeten Stimuli sichtbar sind. Bei großen Bausteinen können Simulationen mit ausreichend vollständigen Stimuli sehr lange dauern.

Beim Testen der funktionalen Übereinstimmung der beiden Schaltungsbeschreibungen (RTL und Netzliste) werden Equivalence-Checks durchgeführt. Im Bereich der ASIC-Verifikation kommen diese Verfahren schon seit geraumer Zeit zum Einsatz. FPGAs galten wegen ihrer speziellen internen Struktur lange Zeit als schwer handhabbar. Inzwischen gibt es aber mit 360-EC-FPGA von Onespin ein speziell für FPGA-Technologien entwickeltes formales Werkzeug, welches die komplexen FPGA-Bausteine der führenden Hersteller unterstützt.

Als Testverfahren kommt auch der Test der kompletten Baugruppe mit Messtechnik in Frage. Dieses Verfahren hat das Problem, dass die PLD-Bausteine oft nur als Blackbox testbar sind und ein vollständiger Test extrem aufwändig und auch teuer ist. Wird ein Fehler gefunden, ist es oft unmöglich, die Ursache ohne weitere umfangreiche Simulationen zu bestimmen.

Neben den beschriebenen rein funktionalen Betrachtungen bieten FPGA-Hersteller in ihren Design-Werkzeugen auch noch die Möglichkeit, statische Timing-Analysen durchzuführen und die voraussichtliche Verlustleistung des Chips abzuschätzen. Auch diese Schritte sind sehr wichtig um sicherzustellen, dass die Schaltung im kompletten System richtig funktioniert.

CPUs auf dem FPGA

Bild 3: Aufbau einer HW/SW-Co-Verifikations-Umgebung mit BFM (Bus Functional Model), QEMU-Emulator und HDL-Simulator. Evision Systems

Immer häufiger entwickeln sich PLD-Bausteine hin zu komplexen System auf einem Chip. Dies erfordert jedoch zusätzliche oder neue Design- und Verifikationsmethoden. Häufig erfolgen die Verifikationen des FPGA-Logikteils und der Prozessor-Software separat voneinander. Das Zusammenspiel von Software und Hardware lässt sich im realen Betrieb überprüfen. Zum Debuggen stellen die Halbleiterhersteller meist spezielle IP-Cores zur Verfügung, die es erlauben, Register im PLD während des Betriebs zu beobachten und auszulesen (zum Beispiel Chipscope von Xilinx oder Reveal von Lattice). Eine weitere Möglichkeit ist die vollständige Co-Verifikation von Hardware und Software mit Emulatoren oder funktionalen Busmodellen (Bild 3).

(na)