Design Compiler
Zweck und Konfiguration
Verfeinern Sie RTL, mappen Sie Logik auf charakterisierte Standardzellen, optimieren Sie Timing/Area/Leistung und exportieren Sie Implementierungsnetzlisten. Die DC-Ausgabe ist eine logische Implementierung; sie ist kein physisches oder Signoff-Ergebnis.
Lösen Sie dc_shell aus der konfigurierten Umgebung des Benutzers oder dem Tool-Profil auf.
Ermitteln Sie die tatsächliche Version, unterstützte Optionen, Lizenzen und Dokumentation lokal.
Verwenden Sie die Umgebungserkennung; gehen Sie nicht von einem bestimmten Installationsverzeichnis, Benutzerkonto, Lizenzendpunkt oder einer Start-Shell aus.
Bewahren Sie Installationsinventare, Protokolle und Dokumentationsindizes im privaten lokalen Zustand auf.
Aufruf- und Befehlskonventionen
Verwenden Sie die konfigurierte ausführbare Datei direkt aus der vorbereiteten Umgebung. Behalten Sie den Wrapper-Dateinamen bei; die Änderung des Aufrufnamens eines Dispatchers kann ein anderes Produkt auswählen. Bestätigen Sie interaktive und Batch-Konventionen in der Dokumentation dieser Version. Diese Referenz enthält Befehlsvorschläge, keinen Beweis, dass sie in jeder Version existieren.
dc_shell -f design.tcl
Für unterstützte Stage-Skripte erfasst flow.py Befehle, Status, Protokolle, Artefakte und Checkpoints, ohne einen Shell-Wrapper zu benötigen. Tools können native Schnittstellen mit unterschiedlicher Semantik für ähnliche Flags bereitstellen.
Eingaben und Ausgaben
Geordnete Verilog/SystemVerilog/VHDL-Quellen, Top-Level, Parameter/Defines/Include-Pfade, Ziel-/Link-.db-Bibliotheken, genehmigte SDC; UPF und physische Referenzen, wenn erforderlich. Zeichnen Sie Reset-Semantik und DesignWare-Abhängigkeiten auf. Die .lib-Konvertierung erfordert einen funktionierenden Library Compiler; überprüfen Sie dessen lokale Verfügbarkeit.
Gemappte .v, .ddc, exportierte .sdc, Synthese-.svf; Design-, Constraint-, Flächen-, Timing-, Leistungs- und QoR-Berichte. Behalten Sie nicht gemappte/Verfeinerungs-Nachweise und die ursprünglichen RTL/SDC-Hashes bei. Die Tutorial-Bibliotheksfläche ist in Bibliothekseinheiten angegeben, nicht als bestätigter Quadratmikrometerwert.
Stage-Operationen
Rufen Sie die installierte Befehlssyntax, Argumenttypen, Standardwerte, Einschränkungen, Beispiele, Feature-Anforderungen und Design-State-Voraussetzungen ab, bevor Sie neue Befehle konstruieren. Identifizieren Sie, ob jede Operation den Zustand abfragt, abgeleiteten Zustand aktualisiert, ein Design mutiert oder Artefakte exportiert.
| Stage | Befehle oder native Prozedur | Voraussetzungen und Prüfungen |
|---|---|---|
| RTL | analyze elaborate link check_design | Logische Bibliotheken und geordnete Quellen müssen jede erforderliche Referenz auflösen. |
| Constraints | read_sdc check_timing report_clock | Überprüfen Sie Taktdefinitionen, alle Schnittstellenverzögerungen, Recovery/Removal, Ausnahmen und nicht eingeschränkte Endpunkte. |
| Mapping | compile compile_ultra | Verwenden Sie compile -map_effort medium/high; compile_ultra benötigt seine Feature-Lizenz und Modusvoraussetzungen. |
| Inspektion | report_area report_timing report_power report_qor | Lesen Sie Einheiten, Aktivitätsannahmen und Pfadabdeckung; die Leistung ist eine Schätzung ohne entsprechende Aktivität. |
| Export | set_svf write_file write_sdc | Aktivieren Sie SVF vor Transformationen; geben Sie gemappte Netzliste und Checkpoint zusammen aus. |
Tcl, Inspektion und Dokumentation
current_design; get_designs *; get_cells -hierarchical; get_clocks *; report_hierarchy; check_design; check_timing. Überprüfen Sie sizeof_collection, nicht Tcl llength, für Synopsys-Sammlungen.
Konstruieren Sie für Tcl-Schnittstellen Pfade/Argumente als Tcl-Listen, behandeln Sie Sammlungen mit den unterstützten Sammlungs-APIs, fangen Sie Fehler ab und überprüfen Sie explizite Befehlsrückgabewerte. 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-compiler --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 DOCUMENT_ID
Die Beispiele werden aus dem Bundle-Verzeichnis ausgeführt. Lesen Sie Befehlserkennung für die private Indexerstellung, eingeschränkten Abruf, Laufzeitverfügbarkeit und Lebenszyklusprüfungen. Ein Handbucheintrag kann eine Variable oder Diagnose anstelle eines aufrufbaren Befehls beschreiben. Fehlende Dokumentation bleibt ein Hindernis für die Auswahl nicht unterstützter Befehle.
Kontrollierte Parameter und Abhängigkeiten
Map-Effort (medium/high), inkrementelle Kompilierung, durch das PDK erlaubte Puffer-/Zellauswahl, Flächen- vs. Timing-Gewichtung. compile_ultra -timing_high_effort_script und -area_high_effort_script sind unterschiedliche Strategien; rufen Sie Einschränkungen ab, bevor Sie Schalter kombinieren. Retiming, Hierarchieänderungen und Taktgatter ändern die Verifikationsanforderungen und erfordern neue Äquivalenznachweise.
Geringere Fläche kann die Verzögerung und den Fanout erhöhen. Physical-aware/topographische Einstellungen erfordern physische Bibliotheken und RC-Technologie; aktivieren Sie sie niemals nur, weil ihre Flags existieren. Taktperiode und Schnittstellenbudgets bleiben fest. Eine geänderte Netlist invalidiert Formality und alle nachgelagerten Checkpoints.
Zeichnen Sie ursprüngliche/vorgeschlagene Werte, die durch Berichte gestü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 Constraints.
Fehlerbehebung und Verifikation
Diagnostizieren Sie Quellreihenfolge, Defines, ungelöste Referenzen, Bibliotheksauswahl und Constraints vor der Abstimmung. Überprüfen Sie abgeleitete Latches und mehrere Treiber auf funktionale Absicht. Nicht unterstützte Befehle benötigen Dokumentation der installierten Version. Lizenz- oder Loader-Fehler erfordern eine Umgebungsreparatur.
Erfassen Sie den Befehl/Status, interne Protokolle, Berichte und die Checkpoint-Identität. Klassifizieren Sie die Ursache, konsultieren Sie die relevante installierte Dokumentation und wenden Sie die am wenigsten störende 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 beibehalten; behalten Sie abgelehnte Versuche. Verwenden Sie Fehlerbehebung für die Wiederherstellungsentscheidung.
Funktionale Änderungen benötigen eine explizite Autorisierung. Lockern Sie keine Timing-Anforderungen, entfernen Sie keine erforderlichen Constraints oder umgehen Sie die Verifikation, um Erfolg zu melden. Stoppen Sie, wenn keine gerechtfertigte Korrektur mehr übrig ist oder ein konfiguriertes Budget ausgeschöpft ist, und melden Sie, welche Eingabe- oder Umgebungsreparatur erforderlich ist.
Vorlagen und Akzeptanz
Überprüfen Sie die tatsächlichen Ausgaben und produktspezifischen Berichte auf den angeforderten Umfang. Für Synthese/Implementierung erfordern Sie gemappte/verlinkte Artefakte und erhaltene Constraints; beweisen Sie die Funktionalität nach Transformationen erneut. 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.
Bewahren Sie Dokumentationsvalidierung, Tcl-Syntaxprüfungen, Tool-Ausführung, Stage-Akzeptanz und End-to-End-Signoff-Nachweise getrennt auf. Ein generierter Stream ist keine verifizierte Implementierung. Siehe Ausführungsvertrag und Validierungsumfang für die erforderlichen Nachweisgrenzen.