Design Compiler
目的與配置
將 RTL 進行詳細化、映射邏輯至已表徵的標準單元、最佳化時序/面積/功耗，並匯出實現網表。DC 輸出是邏輯實現結果，並非實體或簽核結果。
從用戶配置的環境或工具設定檔中解析 dc_shell。
發現實際的版本、支援的選項、授權與本地文件。
使用環境發現；不要假設特定的安裝目錄、帳戶、授權端點或啟動 shell。
將安裝庫存、日誌與文件索引保留在私有本地狀態中。
調用與指令慣例
直接從準備好的環境中使用配置的可執行檔。保留其包裝器檔名；更改調度器的調用名稱可能會選擇不同的產品。確認該版本文件中的互動式與批次慣例。本參考提供指令候選項，但不證明它們在每個版本中都存在。
dc_shell -f design.tcl
對於支援的階段腳本，flow.py 會捕獲指令、狀態、日誌、工件與檢查點，無需 shell 包裝器。 工具可能提供原生介面，其語義與類似旗標不同。
輸入與輸出
有序的 Verilog/SystemVerilog/VHDL 源碼、頂層模組、參數/定義/包含路徑、目標/連結 .db 函式庫、批准的 SDC；必要時包含 UPF 與實體參考。記錄重置語義與 DesignWare 依賴項。.lib 轉換需要可用的 Library Compiler；驗證其在本地是否可用。
映射後的 .v、.ddc、匯出的 .sdc、綜合 .svf；設計、約束、面積、時序、功耗與 QoR 報告。保留未映射/詳細化的證據以及原始 RTL/SDC 的雜湊值。教學用函式庫面積以函式庫單位為單位，而非斷言的平方微米值。
階段操作
在建構新指令前，檢索已安裝的指令語法、參數類型、預設值、限制、範例、功能需求與設計狀態前置條件。識別每個操作是查詢狀態、更新衍生狀態、修改設計還是匯出工件。
| 階段 | 指令或原生程序 | 前置條件與檢查 |
|---|---|---|
| RTL | analyze elaborate link check_design | 邏輯函式庫與有序源碼必須解析每個必要參考。 |
| 約束 | read_sdc check_timing report_clock | 檢查時鐘定義、所有介面延遲、恢復/移除、例外與未約束端點。 |
| 映射 | compile compile_ultra | 使用 compile -map_effort medium/high；compile_ultra 需要其功能授權與模式前置條件。 |
| 檢查 | report_area report_timing report_power report_qor | 讀取單位、活動假設與路徑覆蓋率；在沒有適當活動的情況下，功耗僅為估計值。 |
| 匯出 | set_svf write_file write_sdc | 在轉換前啟用 SVF；同時輸出映射網表與檢查點。 |
Tcl、檢查與文件
current_design；get_designs *；get_cells -hierarchical；get_clocks *；report_hierarchy；check_design；check_timing。對於 Synopsys 集合，請使用 sizeof_collection，而不是 Tcl 的 llength。
對於 Tcl 介面，請以 Tcl 列表形式建構路徑/參數，使用支援的集合 API 處理集合，捕獲錯誤並檢查明確的指令返回值。語法正確的 Tcl 檔案並不保證指令的可用性。對於原生驅動，請改用其記錄的輸入格式。
python3 scripts/docs.py search '' --tool design-compiler --limit 20
# 當有多個匹配項時，選擇已安裝的版本/安裝。
# 使用以下命令檢索回傳的條目：python3 scripts/docs.py show DOCUMENT_ID
這些範例從套件目錄執行。閱讀指令發現以了解私有索引建立、有界檢索、執行階段可用性與生命週期檢查。手冊條目可能描述變數或診斷訊息，而非可呼叫的指令。缺少文件仍然是選擇不支援指令的障礙。
受控參數與依賴項
映射努力程度（中等/高）、增量編譯、PDK 允許的緩衝/單元選擇、面積與時序的權重。compile_ultra -timing_high_effort_script 與 -area_high_effort_script 是不同的策略；在合併開關前請檢索限制。重新計時、層次結構更改與時鐘閘控會改變驗證義務，並需要新的等價性證據。
較小的面積可能會增加延遲與扇出。物理感知/拓撲設定需要實體函式庫與 RC 技術；切勿僅因旗標存在就啟用它們。時鐘週期與介面預算保持固定。更改後的網表會使 Formality 與所有下游檢查點失效。
記錄原始/建議值、報告支援的假設、手冊參考、有效階段與預期指標。使用最佳化進行有界比較，並保持功能不變與硬性約束。
失敗恢復與驗證
在調整之前，診斷源碼順序、定義、未解析參考、函式庫選擇與約束。檢查推斷出的鎖存器與多重驅動器是否符合功能意圖。不支援的指令需要已安裝版本的文件。許可證或載入器故障需要環境修復。
捕獲指令/狀態、內部日誌、報告與狀態/檢查點標識。分類原因，查閱相關的已安裝文件，並套用最小干擾且合理的修正。恢復最後有效傳入檢查點的可寫副本，並重新執行受影響的階段。在保留更改前比較已驗證的指標；保留被拒絕的嘗試。使用故障排除進行恢復決策。
功能更改需要明確授權。不要為了報告成功而放寬時序要求、移除必要約束或繞過驗證。當沒有合理的修正可用或配置的預算已耗盡時，停止操作，並報告需要什麼輸入或環境修復。
範本與驗收
針對要求的範圍檢查實際輸出與產品特定報告。對於綜合/實現，需要映射/連結的工件與保留的約束；在轉換後重新驗證功能。對於驗證，需要完整的覆蓋率與乾淨的必要檢查。對於模擬/除錯，需要預期的任務/測試完成並審查診斷結果。
將文件驗證、Tcl 語法檢查、工具執行、階段驗收與端到端簽核證據分開。產生的串流並非經過驗證的實現。請參閱執行合約與驗證範圍以了解所需的證據邊界。