Design Vision
Zweck und Konfiguration
Graphische Design-Inspektion und Synthese-Interaktion für DC. Verwenden Sie Design Compiler für reproduzierbare Headless-Synthese; Design Vision eignet sich für die Untersuchung von Hierarchie, Timing und Schaltplänen.
design_vision aus der konfigurierten Umgebung oder dem Tool-Profil des Benutzers auflösen.
Ermitteln Sie die tatsächliche Version, unterstützte Optionen, Lizenzen und lokale Dokumentation.
Verwenden Sie die Umgebungserkennung; gehen Sie nicht von einem bestimmten Installationsverzeichnis, Konto, Lizenzendpunkt oder einer bestimmten Start-Shell aus.
Bewahren Sie Installationsinventare, Logs und Dokumentationsindizes im privaten lokalen Zustand auf.
Aufruf- und Befehlskonventionen
Verwenden Sie die konfigurierte ausführbare Datei direkt aus der vorbereiteten Umgebung. Behalten Sie ihren Wrapper-Dateinamen bei; eine Änderung des Aufrufnamens eines Dispatchers kann die Auswahl eines anderen Produkts zur Folge haben. Bestätigen Sie interaktive und Batch-Konventionen in der Dokumentation dieser Version. Diese Referenz enthält Befehlskandidaten, keinen Beweis, dass sie in jeder Version existieren.
design_vision -f design.tcl
Für unterstützte Stage-Skripte erfasst flow.py Befehle, Status, Logs, Artefakte und Checkpoints, ohne einen Shell-Wrapper zu benötigen. Tools können native Schnittstellen mit unterschiedlichen Semantiken für ähnliche Flags bereitstellen.
Eingaben und Ausgaben
DC-.ddc- oder unterstützte RTL/Netlist mit passenden Bibliotheken, SDC und Design-Setup; ein funktionierender Bildschirm für die GUI-Nutzung. Verwenden Sie Kopien von Checkpoints für explorative Bearbeitung.
DC-kompatible Design-Checkpoints, Berichte und Sitzungsprotokolle; explizit exportierte GUI-Artefakte, sofern unterstützt. Überschreiben Sie keine akzeptierten Synthese-Checkpoints während der Inspektion.
Stage-Operationen
Rufen Sie die installierte Befehlssyntax, Argumenttypen, Standardwerte, Einschränkungen, Beispiele, Feature-Anforderungen und Design-Zustandsvoraussetzungen ab, bevor Sie neue Befehle konstruieren. Identifizieren Sie, ob jeder Vorgang den Zustand abfragt, abgeleiteten Zustand aktualisiert, ein Design mutiert oder Artefakte exportiert.
| Stage | Befehle oder native Prozedur | Voraussetzungen und Prüfungen |
|---|---|---|
| Laden/Inspizieren | read_ddc current_design report_hierarchy report_timing | Verwenden Sie den Synthesebibliotheks-/Constraint-Kontext, der zum gespeicherten Design passt. |
| Synthese | analyze elaborate compile | Delegieren Sie reproduzierbare Synthese und formale Gatter an synopsys-design-compiler. |
| Speichern | write_file write_sdc | Behandeln Sie jede Design-Änderung als neuen Kandidaten, der eine Verifikation erfordert. |
Tcl, Inspektion und Dokumentation
DC-Design-/Sammlungsbefehle gelten, wo dokumentiert: current_design, get_designs *, report_hierarchy, report_timing, report_area und check_design. GUI-spezifische APIs müssen separat nachgeschlagen werden.
Für Tcl-Schnittstellen konstruieren Sie Pfade/Argumente als Tcl-Listen, verarbeiten Sammlungen mit den unterstützten Sammlungs-APIs, fangen Fehler ab und inspizieren explizite Rückgabewerte von Befehlen. Eine syntaktisch gültige Tcl-Datei begründet keine Befehlsverfügbarkeit. Verwenden Sie für native Treiber stattdessen deren dokumentiertes Eingabeformat.
python3 scripts/docs.py search '' --tool design-vision --limit 20
# Wählen Sie die installierte Version/Installation aus, wenn mehrere Übereinstimmungen vorhanden sind.
# Rufen Sie einen zurückgegebenen Eintrag ab mit: python3 scripts/docs.py show DOKUMENT_ID
Die Beispiele werden aus dem Bundle-Verzeichnis ausgeführt. Lesen Sie Befehlsermittlung für die private Indexerstellung, eingeschränkte Abfrage, Laufzeitverfügbarkeit und Lebenszyklusprüfungen. Ein manueller Eintrag kann eine Variable oder Diagnose beschreiben, nicht einen aufrufbaren Befehl. Fehlende Dokumentation bleibt ein Hindernis für die Auswahl nicht unterstützter Befehle.
Kontrollierte Parameter und Abhängigkeiten
Syntheseeinstellungen folgen der DC-Richtlinie. GUI-Anzeige-/Layout-Einstellungen sind beobachtend; jede abgebildete Design-Änderung macht nachgelagerte Äquivalenz- und physische Nachweise ungültig.
Gleicher DC-Release/Datenbank-/Bibliothekskontext; GUI-Bibliotheken/-Anzeige können unabhängig von dc_shell fehlschlagen. Verwenden Sie den genauen Wrapper-Namen, da er die Produktpersönlichkeit auswählt.
Zeichnen Sie ursprüngliche/vorgeschlagene Werte, die berichtsgestützte Hypothese, manuelle Referenz, gültige Stage und erwartete Metrik auf. Verwenden Sie Optimierung für begrenzte Vergleiche mit unveränderlicher Funktionalität und harten Randbedingungen.
Fehlerbehebung und Verifikation
Diagnostizieren Sie Anzeige-/GUI-Setup getrennt von Synthesefehlern. Bewahren Sie Wrapper-Namen und Design-/Bibliothekskontext. Jede Design-Änderung erfordert neue Synthese-/Formalnachweise, bevor sie downstream gefördert wird.
Erfassen Sie den Befehl/Status, interne Logs, Berichte und die Checkpoint-Identität. Klassifizieren Sie die Ursache, konsultieren Sie die relevante installierte Dokumentation und wenden Sie die am wenigsten disruptive gerechtfertigte Korrektur an. Stellen Sie eine beschreibbare Kopie des letzten gültigen eingehenden Checkpoints wieder her und führen Sie die betroffenen Stages erneut aus. Vergleichen Sie verifizierte Metriken, bevor Sie eine Änderung übernehmen; behalten Sie abgelehnte Versuche bei. Verwenden Sie Fehlerbehebung für die Entscheidung zur Wiederherstellung.
Funktionale Änderungen benötigen explizite Autorisierung. Lockern Sie keine Timing-Anforderungen, entfernen Sie keine erforderlichen Randbedingungen oder umgehen Sie keine Verifikation, um Erfolg zu melden. Stoppen Sie, wenn keine gerechtfertigte Korrektur mehr vorhanden ist oder ein konfiguriertes Budget erschöpft ist, und melden Sie, welche Eingabe- oder Umgebungsreparatur erforderlich ist.
Vorlagen und Abnahme
Inspizieren Sie die tatsächlichen Ausgaben und produktspezifischen Berichte gegen den angeforderten Umfang. Für Synthese/Implementierung erfordern Sie zugeordnete/verknüpfte Artefakte und erhaltene Randbedingungen; beweisen Sie die Funktionalität nach Transformationen neu. Für Verifikation erfordern Sie vollständige Abdeckung und saubere erforderliche Prüfungen. Für Simulation/Debug erfordern Sie, dass die beabsichtigte Aufgabe/der beabsichtigte Test mit überprüften Diagnosen abgeschlossen wird.
Halten Sie Dokumentationsvalidierung, Tcl-Syntaxprüfungen, Tool-Ausführung, Stage-Abnahme und End-to-End-Freigabenachweise getrennt. Ein generierter Stream ist keine verifizierte Implementierung. Siehe Ausführungsvertrag und Validierungsumfang für die erforderlichen Nachweisgrenzen.