Überprüfen der Code-Qualität

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

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.

Seite 2 von 3123