Ü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 PLD-HW/SW-Co-Verifikations-Umgebung mit BFM (Bus Functional Model), QEMU-Emulator und HDL-Simulator.

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).

Seite 3 von 3123