Überprüfung von digitalen Schaltkreisen. Rückblick

Ich werde versuchen, allgemein über die Verifizierung digitaler Schaltkreise zu sprechen.

Die Überprüfung in diesem Bereich ist ein wichtiger Prozess, bei dem erfahrene Ingenieure hinzugezogen werden müssen. Beispielsweise muss ein Verifizierungsspezialist, der an Systemen mit einer CPU arbeitet, in der Regel über Skriptsprachen und Befehlsshellsprachen (Tcl, bash, Makefile usw.), Programmiersprachen (C, C ++, Assembler) und HDL / HDVL verfügen (SystemVerilog [10, Anhang C - Geschichte der Sprache] [11], Verilog, VHDL), moderne Methoden und Frameworks (UVM).

Der für die Überprüfung aufgewendete Zeitanteil beträgt 70-80% der gesamten Projektzeit. Einer der Hauptgründe für diese Aufmerksamkeit ist, dass Sie nach der Serienproduktion keinen „Patch“ auf dem Chip veröffentlichen können, sondern nur „Silizium-Errata“ (dies gilt nicht für FPGA / FPGA-Projekte).

Mit digitalen Schaltungen meine ich:

• komplexe Funktionsblöcke / geistiges Eigentum (SFB / IP);
• Kundenspezifische Chips für anwendungsspezifische integrierte Schaltkreise (ASIC)
• integrierte programmierbare Logikschaltungen / feldprogrammierbares Gate-Array (FPGA);
• Systeme auf einem Chip / System-on-Crystal (SoC / SoC);
• usw.

Aktuelle Überprüfungsprobleme

Der aktuelle Stand und die Trends auf dem Gebiet der Verifizierung können anhand der folgenden Herausforderungen und Probleme beurteilt werden [6]:

• Die Größe des Verifizierungsobjekts (OB) wächst ständig. Selbst ein kleiner Mikrocontroller-IC besteht aus einem Satz von Dutzenden von Submodulen, die häufig komplexe Funktionen aufweisen. Große ICs sind Komplexe, in denen es bis zu zehn Milliarden Transistoren geben kann, und das Energieverwaltungsschema allein kann einige Prozessoren in seiner Komplexität übertreffen [8].
• Es ist unmöglich, zu Beginn des Projekts eine Spezifikation für IMS zu erstellen und diese erst in der Zukunft zu befolgen. Sie ändert sich während des gesamten Entwicklungsprozesses ständig (der Kunde ändert die Anforderungen, technischen Probleme oder findet optimale Lösungen, um Ansätze zu überdenken usw.). Auf dieser Grundlage sollten alle Prozesse die Dynamik von Spezifikationsänderungen wahrnehmen und entsprechend den Anforderungen modifiziert werden.
• Häufig arbeiten mehrere voneinander entfernte Teams an der Projektüberprüfung, deren Anzahl Dutzende von Personen erreichen kann.
• Die Anzahl der einzelnen Tests und ihre Arten erreicht eine große Anzahl, ihre Ergebnisse müssen gesammelt und analysiert werden.
• Die Modellierung auch digitaler Systeme erfordert viel Computerzeit.
• Die Vollständigkeit der für das Projekt festgelegten Vorbereitungsziele hängt weitgehend von der Kompetenz und der Intuition der Verifizierungsspezialisten ab.
• Trotz des Vorhandenseins von Indikatoren für die Projektabdeckung mit Tests (Metriken) besteht die einzige Möglichkeit, die Überprüfung abzuschließen, darin, sie auszusetzen. Dies basiert hauptsächlich auf den folgenden Schlussfolgerungen: Das Geld oder die Zeit, die für die Projektphase aufgewendet werden muss, scheint eine Codeabdeckung von 100 zu haben %, wir testen seit einer Woche und haben keine Fehler gefunden.

Überprüfungstypen

Die Überprüfung von digitalen Schaltkreisen kann in folgende Haupttypen unterteilt werden:

1. funktional (Funktionsüberprüfung) - der Name spricht für sich selbst, Sie prüfen, ob Ihr System seine Funktionen korrekt ausführt;
2. formale Verifikation - Mit dieser Verifikation wird die Gleichwertigkeit der Darstellungen Ihres Systems auf verschiedenen Stufen des Entwurfswegs oder die Erfüllung der im Quellcode gesetzten Aussagen festgestellt:
   
   • Äquivalenzprüfung (z. B. RTL-zu-RTL, RTL-zu-Gate, Gate-zu-Gate);
   • Eigenschaftsprüfung (Modellprüfung) (prüft die im Code angegebenen Eigenschaften (Zusicherungen) mit SVA (zum Beispiel)).
3. Statische Code-Analyse - Überprüfung des Quellcodes nach formalen Kriterien hinsichtlich der Einhaltung der Regeln für die Verwendung der Sprache und ihrer Konstruktionen. Sehr oft werden die konfigurierten Überprüfungsregeln an RMM gesendet [4]. Programme für eine solche Überprüfung werden normalerweise als Flusen oder Linter bezeichnet.
4. physische Verifizierung - beinhaltet im Wesentlichen DRC-, LVS-, PERC- usw. Überprüfungen, die physische Darstellung des Systems wird auf Übereinstimmung mit technologischen Standards und die Konformität von physischen und logischen Darstellungen usw. überprüft. Die Zusammensetzung der Schecks ist stark technologieabhängig. In der Regel wird die physische Überprüfung von einem Ingenieur oder einem topologischen Designteam durchgeführt.
5. Prototyping - Verwendung von FPGA zur Funktionsüberprüfung [18].

Die Funktionsüberprüfung im Rahmen aller Arbeiten ist von größter Bedeutung und erfordert die direkte Einbeziehung des Menschen.

Die Analyse des statischen Codes erfordert nur eine Erstkonfiguration der Tools, die den vom Unternehmen festgelegten internen Designregeln entspricht. Dann ist das Tool darauf bedacht, dass es Entwicklern „wertvolle Hinweise“ gibt und keine ständige Überwachung erfordert.

Formale Überprüfungswerkzeuge sind oftmals auch sehr unabhängig und erfordern nur eine sorgfältige Analyse der von ihnen erstellten Berichte. Sie eignen sich auch für das Reverse Engineering, wenn Sie aus irgendeinem Grund wissen, dass Sie den Code aus der Liste der Schaltkreise wiederherstellen müssen.

Beispiele für Überprüfungstools

Beispiele für Tools zur Überprüfung digitaler Schaltungen (Digital-On-Top-Route):

• Überprüfungsverwaltungstools
  
  • Mentor Graphics - Questa Überprüfungsmanagement
  • Cadence - vManager
  • Synopsys - Verdi, VC Execution Manager ("ExecMan")
• funktionsfähig - in der Regel Simulatoren
  
  • Mentor Graphics - ModelSim, QuestaSim
  • Cadence - Incisive, Xcelium
  • Synopsys - VCS
  • Freie Software von unabhängigen Entwicklern - Simulatoren Verilator, Icarus [5]
• formal
  
  • Mentor Graphics - Formal Pro, Questa Formale Verifizierung
  • Cadence - JasperGold, Conformal LEC, Plattform für formale Verifizierung
  • Synopsys - Formalität, VC Formal
• statische Code-Analyse
  
  • Mentor Graphics - Questa AutoCheck
  • Cadence - HAL, JasperGold
  • Inhaltsangabe - SpyGlass Lint
• physische Überprüfung
  
  • Mentor Graphics - Kaliber
  • Cadence - Pegasus, System zur physischen Verifizierung,
  • Synopsys - Hercules, IC Validator

Funktionsprüfungsmethoden

Funktionsüberprüfung - ist eine Reihe von Tests, ich erlaube mir unter bestimmten Bedingungen, in drei Gruppen eingeteilt zu werden (dies ist kein Dogma, dies ist aus persönlicher Erfahrung):

1. Positive Verzweigungen - Überprüfung des Verhaltens in normalen Situationen, geregelt durch die Spezifikation für das Gerät oder den Standard usw. Das heißt Wir prüfen Situationen, in denen alles gut läuft.
2. Negative Verzweigungen - Überprüfung von Abweichungen von Standardsituationen, aber beispielsweise im Rahmen einer Spezifikation oder eines Standards - Nichtübereinstimmung der Prüfsumme, Anzahl der empfangenen Daten usw. Das heißt wenn etwas schief geht, aber wir wussten, dass dies sein könnte und wir wissen, wie man in dieser Situation arbeitet.
3. Nicht-Standard-Situationen - beliebige Situationen, von Verstößen gegen Kommunikationsprotokolle, die Reihenfolge der Daten bis hin zu physischen Kollisionen in Schnittstellen, zufälligen Änderungen des Zustands von Logikelementen usw. Das heißt In diesem Fall kann alles passieren und Sie müssen sicherstellen, dass der OB danach wieder funktionsfähig ist.

Die ersten beiden Stufen können mithilfe von UVC / VIP (Universal Verification Component / Verification IP) automatisiert werden. Dort können Sie schnell das Volumen verschiedener Tests erhöhen, auch der automatisch generierten. Die dritte Stufe ist ein "Meisterstück" in der Verifikation, diese Stufe erfordert einen außergewöhnlichen Ansatz und Erfahrung, es ist sehr schwer zu automatisieren, weil Die meisten Situationen sind ein separater Algorithmus, möglicherweise ein Skript für CAD oder Anweisungen für "manuelle" Prüfungen.

Arten von Metriken zur Funktionsüberprüfung

Metriken sind Indikatoren für die Testabdeckung eines Projekts. Sie werden benötigt, um zu verstehen, welche anderen Tests entwickelt werden müssen, um mögliche Situationen zu überprüfen und wie viel Zeit die Überprüfung in Anspruch nehmen kann [16].

Leider wird nur ein Metriktyp basierend auf dem Quellcode des Projekts bewertet, die Definition der Kriterien für die übrigen Typen ist das Ergebnis intellektueller Arbeit.

Darüber hinaus muss beachtet werden, dass das Erreichen der gewünschten Indikatoren durch eine Art von Metrik nicht die Verarbeitbarkeit im Allgemeinen bedeutet, es ist immer notwendig, den Komplex zu bewerten.

Arten von Metriken [3]:

• funktionelle Beschichtung . Zeigt an, wie viel die OB-Funktion getestet wurde. Die Kriterien für diese Abdeckung können durch den Testplan und die Einführung von Sonderkonstruktionen (Covergroup [1]) in die Testumgebung und / oder das OM festgelegt werden. Dabei kann überwacht werden, ob eine bestimmte Funktion / Aktion ausgeführt wurde, ob sich die Daten auf eine bestimmte Art und Weise geändert haben usw. Informationen aus im Quellcode eingebetteten Designs können automatisch von CAD erfasst werden.
• Codeabdeckung - Ändern des Status von Quellcodekonstruktionen während der Tests. Es wird automatisch von CAD gesammelt, erfordert keine Einführung von Strukturen im Quellcode. Zum Beispiel:
  
  • Schaltregister (Toggle Coverage);
  • Aktivität jeder Codezeile (Line Coverage);
  • Aktivität von Ausdrücken (Anweisungsabdeckung) - Dies ist zwar die Zeilenabdeckung, kann jedoch Ausdrücke verfolgen, die mehr als eine Zeile im Editor enthalten.
  • Aktivität eines Codesegments innerhalb einer bedingten Anweisung oder Prozedur (Block Coverage), eine Variation der Anweisungsabdeckung;
  • Aktivität aller Zweige von bedingten Anweisungen, z. B. wenn, während, für immer wiederholen, für, Schleife (Branch Coverage);
  • Änderung aller Zustände (wahr, falsch) der logischen Ausdrücke der Komponente (Ausdrucksüberdeckung);
  • Zustand der Zustandsmaschine (Finite-State-Machine-Coverage).
• Ansprüche decken . Anweisungen sind spezielle Sprachkonstrukte, die verschiedene Ereignisse und Sequenzen verfolgen und nach festgelegten Kriterien die Rechtmäßigkeit ihres Auftretens bestimmen.

Funktionsprüfungsmethoden

Directed Tests Method (DTM)

Direkte, aussagekräftige Tests. Wenn diese Methode im Projekt übernommen wird, besteht der Überprüfungsplan aus Tests, mit denen das Verhalten von organischer Substanz an bestimmten Punkten von Interesse (Zuständen) überprüft werden soll. Es ist fast unmöglich, alle möglichen Situationen, insbesondere in komplexen Projekten, zu überprüfen.
Gleichzeitig werden Probleme, die in Situationen auftreten können, die nicht durch Tests abgedeckt sind, nicht erkannt, bevor das Gerät unter realen Bedingungen in Betrieb genommen wird. In der Regel verwenden diese Tests Metriken für die funktionale Abdeckung.

Coverage-Driven Verification, Metric-Driven Verification (CDV, MDV) [17]

Das Konzept der Erstellung von Tests zielt darauf ab, eine bestimmte „Testabdeckung“ von organischen Substanzen zu erreichen. Sie verlassen sich auf Metriken, um zu verstehen, welche Tests zum Verifizierungsplan hinzugefügt werden müssen, um die Projektbereitschaftsziele zu erreichen.
Sie müssen Abdeckungsanalyse-Tools verwenden, um zu sehen, was dem Überprüfungsplan noch hinzugefügt werden muss. In der Tat können wir bereits davon ausgehen, dass wir reibungslos von DTM zu CDV gewechselt sind, wenn wir beginnen, den Überprüfungsplan im DTM anzupassen, indem wir uns zumindest auf die „Codeabdeckung“ verlassen.

Eingeschränkte zufällige Überprüfung (CRV)

Überprüfung durch Einreichung zufälliger Einflüsse. Dies sind wirklich automatische Tests, bei denen zufällige Effekte auf OM erzeugt werden. Eine Symbiose mit ABV ist jedoch nur schwer vorstellbar.
Die Methode ist zunächst sehr aufwendig, weil Die Vorbereitung der Werkzeuge dauert lange. Nach Abschluss der anfänglichen Vorbereitungsphase kann der Test automatisch wiederholt mit unterschiedlichen Anfangsdaten gestartet werden. Wenn eine Assertionsinkongruenz erkannt wird, beginnt das Entwicklungs- und Verifizierungsteam mit der Analyse des erkannten Fehlers.
In einem realen Projekt kann man sich nicht nur auf diese Methode beschränken, weil Mit dieser Methode können Sie Codeabdeckung und Anweisungsabdeckung erfassen, und sie können nichts über den korrekten Betrieb des Betriebssystems aussagen, d. H. Einhaltung der Spezifikationen. Es muss mit Funktionstests ergänzt werden.
Zur Implementierung dieser Methodik ist Folgendes erforderlich:

1. Implementieren Sie "Assertion" in allen wichtigen Punkten des Quellcodes des OB und der Testumgebung.
2. Generatoren zufälliger Effekte und Szenarien ihrer Arbeit zu entwickeln, d.h. Die Auswirkungen sind zufällig, es bestehen jedoch Einschränkungen hinsichtlich der Reichweite (wir haben nicht die Zeit, alles zu sortieren), der Reihenfolge der Ablage usw.

Durchsetzungsbasierte Überprüfung [9] (ABV)

Überprüfung mit Aussagen. Wahrscheinlich ist dies nicht einmal eine eigenständige Methode, sondern eine Komponente oder Grundkomponente der obigen.

Ein wichtiges Thema bei ABV ist die Verteilung von Behauptungen, die sich am besten im Quellcode des OB befinden und die sich in der Testumgebung befinden sollten.

Es sollte sofort beachtet werden, dass die Verilog-Sprache keine Assertions in ihrem Standard enthält (sie können mit den grundlegenden Sprachkonstrukten erstellt werden, aber für den Synthesizer sind Direktiven erforderlich, damit sie sich nicht mit ihrer Konvertierung befassen). Zusicherungen werden nur im SystemVerilog-Standard angezeigt und waren ursprünglich auch im VHDL- und e-Sprachstandard enthalten.

Ich schlage vor, dass Sie sich mit den Empfehlungen von Fachleuten vertraut machen, darunter Clifford Cummings [12, Artikel über SVA] über die Verbreitung von Werken zu deren Verfassen sowie Materialien zu ABV auf der Website der Verification Academy [13].

Referenzliste

1. IEEE Std 1800TM-2012. IEEE-Standard für SystemVerilog - Einheitliche Hardware-Design-, Spezifikations- und Verifikationssprache
2. Clive Maxfield. FPGA-Design. Architektur, Werkzeuge und Methoden. Der Kurs des jungen Kämpfers. ISBN 978-5-94120-147-1 (RUS), ISBN 0-7506-7604-3 (ENG)
3. Verification Academy. Abdeckungs-Kochbuch. Pro Testabdeckung
4. Michael Keating, Pierre Bricaud. Handbuch zur Wiederverwendung von Methoden für System-on-a-Chip-Designs. Druck ISBN 1-4020-7141-8, eBook ISBN 0-306-47640-1
5. Liste der lizenzierten und frei verteilten CAD
6. Mentor Graphics. Ein Beispiel für Statistiken zum aktuellen Status und zum Umfang der Überprüfung
7. WikiChip. Chips Wikipedia
8. Wikipedia Verallgemeinerte Daten zur Anzahl der Transistoren im IC
9. Harry Foster, Adam Krolnik und David Lacey. Durchsetzungsbasiertes Design. Druck-ISBN 1-4020-8027-1, eBook ISBN 1-4020-8028-X
10. Stuart Sutherland, Simon Davidmann und Peter Flake. SystemVerilog für Design. Print ISBN-10: 0-387-33399-1, eBook ISBN-10: 0-387-36495-1
11. Chris Spear, Greg Tumbush. SystemVerilog zur Überprüfung. Print ISBN: 978-1-4614-0714-0, eBook ISBN: 978-1-4614-0715-7
12. Sunburst Design. Papiere
13. Verification Academy. ABV natürlich
14. Doulos. Nützliche Online-Materialien und Nachschlagewerke
15. Prakash Rashinkar, Peter Paterson, Leena Singh. System-on-a-Chip-Überprüfung. Methodik und Techniken. Print ISBN: 0-792-37279-4, eBook ISBN: 0-306-46995-2
16. Verification Academy. Metriken bei der SoC-Überprüfung
17. Doulos. Coverage-basierte Verifizierungsmethode
18. Doug Amos, Austin Lesea, Rene Richter. Handbuch zur FPGA-basierten Prototyping-Methodik: Best Practices für Design-for-Prototyping (FPMM). Druck-ISBN: 978-1617300042. Kostenloser Download von der Synopsys-Website