Offensichtlich gibt es viele Möglichkeiten (und viele Ansichten) auf, wie etwa die Überprüfung eines DUT zu gehen.
Dies ist nur eine der vielen Ansichten. Obwohl es eine Reihenfolge gibt, können sich einige der Schritte ändern, oder sie können basierend auf den designspezifischen Anforderungen sogar zusammengeführt oder sogar übersprungen werden.
- Studie Spezifikation (natürlich)
- Prüfanforderungen sammeln. a. High-Level - Blockgröße, mögliche Benutzer des TB, Ausgaben benötigt, Arten der Eingabe in die TB b. Low-level/Details - spezifische Debug-Anforderungen,
- Entwickeln Top-Level-TB-Architektur Dokument.
- Top-Level-Testplan entwickeln.
- Top-Level-Testplan kann konvertiert werden oder ein detaillierter Testplan kann entwickelt werden.
- Entwickeln oder herleiten eines Excel-Tabellenblattes. [Die meisten Simulatoren unterstützen die Verfolgung eines solchen Blattes]
- Leiten Sie eine zufällige Kontrollvariablenliste und einen Bereich/Einschränkung für die Variablen ab. [optional]
- Low-Level-TB-Dokument - beschreibt Treiber, Agenten, Schnittstellen.
- Entwickeln Sie einen Zeitplan basierend auf den oben genannten Eingaben - Komplexität von Design und TB. [Dieser Schritt selbst kann in Teilen passieren]
- Starten Sie die Skriptentwicklung - für Lauf und Regression usw..
- Entwickeln und implementieren Sie Testfälle gemäß dem Testplan.
- Bericht/Datei Bugs - Monitor Bug Rate.
- Überwachung und Messung der Abdeckung - Code und Funktion.
- Reichweite 100% Deckung (im Idealfall), aber realistisch vereinbart einig auf Ziel und 0 Anzahl der Fehler (pipe dream)
- End Verifikation und Deklarieren Erfolg
Dinge auf dem Weg zu betrachten
1) 1) Ist dies eine System-Level-, Full-Chip-, Blocklevel-Verifikationsumgebung oder Ist dies ein ASIC oder ein FPGA?
2) Basierend auf der Komplexität, wie viele TB-Stufen benötigt werden.
z.B.viele Blocklevel -> wenige Subsystem-> einzelne Full-Chip-Umgebung ...
3) Basierend auf Projektdauer und Zeit bis zur Schließung - müssen Sie FPGA und/oder Emulation unterstützen.
4) Formale Verifizierung - welche blockiert.
5) Ist eine Co-Simulation erforderlich - vom Software-Team. Benötigen Sie eine API aus dem Software/Architektur-Team?
6) Ist es erforderlich, Vektoren zu generieren - Tester-Vektoren, Vektoren heraufbringen.
7) Wie möchten Sie die Test-Pass-Kriterien überprüfen?
a. Modell/Anzeigetafeln -
i. Architekturmodelle
ii. Transaktionsebene Modelle (detaillierter von oben)
iii. Zyklusgenaue Modelle. (z. B. Schiedsrichter)
b. Assertions - Laufzeit + formale
8) Re-use Berücksichtigung
ein. Sequenzen
i. Init
ii. Daten/Kontrolle
b. Anzeigetafel
c. Agents
9) Austestanforderungen
a. Formatierung der Ausgabe
b. Tools zum Überwachen und Extrahieren von Informationen.
10) Welche Sprache, Simulator und Werkzeuge passen am besten zu den Anforderungen?
Für welche Art von Job interviewen Sie? Wenn es für eine Designposition ist, sagen Sie etwas über Unit-Tests mit einem selbstüberprüfenden Prüfstand, und studieren Sie TDD. Wenn es sich um eine technische Führungsposition handelt, sagen Sie etwas über unabhängige Verifizierung auf der Grundlage eines Verifizierungsplans, der beschreibt, wie Anforderungen in der Spezifikation verifiziert werden, z. statische Analyse, eingeschränkte zufällige oder formale Verifikation. Wenn es sich um eine Verifizierungsposition handelt und Sie die Antwort nicht kennen, sollten Sie mit einer anderen Position beginnen und die Verifizierung am Arbeitsplatz lernen. – Teajay