RTL to gate-level netlist on the TSMC N16 ADFP process: licence, library setup, constraints, compile, reports, SDF back-annotated gate-level simulation, and the four numbers you have to hand in.在 TSMC N16 ADFP 製程上把 RTL 變成閘級網表：授權、函式庫設定、約束、compile、報告、SDF 反標註的閘級模擬，以及你必須繳交的那四個數據。TSMC N16 ADFP プロセスで RTL をゲートレベルネットリストにするまで。ライセンス、ライブラリ設定、制約、compile、レポート、SDF をバックアノテートしたゲートレベルシミュレーション、そして提出しなければならない 4 つの数値。
Design Compiler (DC) takes your behavioural Verilog plus a set of constraints and emits a gate-level netlist — the same function rebuilt entirely out of cells that physically exist in the TSMC N16 ADFP standard-cell library. Alongside the netlist it writes the delay of every one of those cells and nets into an SDF file, so a second simulation can prove the circuit still works at real silicon speed, not at the zero-delay speed of RTL.Design Compiler（DC）吃進你的行為級 Verilog 和一組約束，吐出一份閘級網表——同樣的功能，但完全由 TSMC N16 ADFP 標準元件庫裡真實存在的元件重新搭出來。除了網表，它還會把每一顆元件與每一條連線的延遲寫進 SDF 檔，讓第二次模擬能證明電路在真實矽的速度下仍然正確，而不是只在 RTL 的零延遲世界裡正確。Design Compiler（DC）は動作レベルの Verilog と一組の制約を受け取り、ゲートレベルネットリストを出力する。同じ機能を、TSMC N16 ADFP 標準セルライブラリに実在するセルだけで組み直したものだ。ネットリストに加えて、そのセルと配線ひとつひとつの遅延を SDF ファイルに書き出す。これにより 2 回目のシミュレーションで、RTL のゼロ遅延の世界ではなく実シリコンの速度でも回路が正しく動くことを確かめられる。
REFRACT.v (your RTL, single file)
|
| Spyglass lint ---------------> must be clean BEFORE you synthesize
v
+-----------------------------------------------+
| Design Compiler |
| analyze / elaborate / link | <-- drawn out below
| source REFRACT.sdc (constraints) |
| compile |
+-----------------------------------------------+
| | |
v v v
REFRACT_syn.v REFRACT_syn.sdf REFRACT_syn.ddc
(netlist) (cell+net delay) (DC database -> hand in)
| |
+------+------+
v
Gate-level simulation (xrun / ncverilog, +define+SDF)
|
v
PASS, zero timing violations --> fill Excel --> upload REFRACT.v (你的 RTL，單一檔案)
|
| Spyglass lint ---------------> 合成之前必須完全乾淨
v
+-----------------------------------------------+
| Design Compiler |
| analyze / elaborate / link | <-- 下方有展開圖
| source REFRACT.sdc (約束) |
| compile |
+-----------------------------------------------+
| | |
v v v
REFRACT_syn.v REFRACT_syn.sdf REFRACT_syn.ddc
(網表) (元件+連線延遲) (DC 資料庫 -> 要繳交)
| |
+------+------+
v
閘級模擬 (xrun / ncverilog, +define+SDF)
|
v
PASS、零時序違規 --> 填 Excel --> 上傳 REFRACT.v (あなたの RTL、単一ファイル)
|
| Spyglass lint ---------------> 合成の前に完全にクリーンであること
v
+-----------------------------------------------+
| Design Compiler |
| analyze / elaborate / link | <-- 下に展開図あり
| source REFRACT.sdc (制約) |
| compile |
+-----------------------------------------------+
| | |
v v v
REFRACT_syn.v REFRACT_syn.sdf REFRACT_syn.ddc
(ネットリスト) (セル+配線遅延) (DC データベース -> 提出)
| |
+------+------+
v
ゲートレベルシミュレーション (xrun / ncverilog, +define+SDF)
|
v
PASS、タイミング違反ゼロ --> Excel 記入 --> 提出
The middle box is where the work happens, and the four commands in it are not four ways of saying "synthesize". Each one hands the next a different representation of your design, and only the last one knows what a TSMC cell is:中間那個方塊才是真正做事的地方，而裡面那四道指令並不是「合成」的四種說法。每一道都把你的設計以不同的表示形式交給下一道，而且只有最後一道知道 TSMC 元件長什麼樣子：実際に仕事をしているのは中央の枠で、その中の 4 つのコマンドは「合成する」の 4 通りの言い方ではない。それぞれが設計の異なる表現を次のコマンドへ渡しており、TSMC のセルを知っているのは最後の 1 つだけである。
module REFRACT( input wire CLK, input wire RST, input wire [3:0] RI, output reg [8:0] SRAM_A, output reg [15:0] SRAM_D, input wire [15:0] SRAM_Q, output reg SRAM_WE, output reg DONE ); // ... your logic ... endmodule
The SRAM is not a hard macro — tb.v contains a behavioural module SRAM with a 512×16 array, synchronous write on WE and a registered Q. That matters for synthesis: you do not need an SRAM .db in your link library, because the memory lives outside the design under test. DC only ever sees REFRACT and the standard cells.SRAM 不是硬巨集——tb.v 裡有一個行為級的 module SRAM，含 512×16 陣列、WE 同步寫入與暫存過的 Q。這對合成很重要：你的 link library 裡不需要 SRAM 的 .db，因為記憶體位於待測設計之外。DC 從頭到尾只看得到 REFRACT 和標準元件。SRAM はハードマクロではない。tb.v の中に動作レベルの module SRAM があり、512×16 の配列、WE による同期書き込み、レジスタ出力の Q を持つ。これは合成上重要で、link library に SRAM の .db は要らない。メモリは被試験設計の外側にあるからだ。DC が目にするのは REFRACT と標準セルだけである。
Log into the workstation, cd into your working directory — keep a dedicated folder for DC so logs and the .ddc do not get mixed with simulation output — then:登入工作站，cd 到你的工作目錄——替 DC 留一個專用資料夾，這樣 log 和 .ddc 才不會跟模擬輸出混在一起——然後：ワークステーションにログインし、作業ディレクトリへ cd する。ログや .ddc がシミュレーション出力と混ざらないよう、DC 専用のフォルダを用意しておくこと。そのうえで：
cd ~/EP1/syn snsd # menu appears -> select the Design Compiler licence # -> then select ADFP_n16 (REQUIRED for EP1)
snsd is the site licence / environment selector. Picking ADFP_n16 is what points the shell at the TSMC 16 nm ADFP collateral — the .db timing libraries DC maps into, and the Verilog cell models the gate-level simulator needs. Start dc_shell without it and DC will either fail to find the target library, or quietly map to whatever default process is configured — and then your area number is meaningless next to everyone else's.snsd 是站台的授權 / 環境選擇器。選 ADFP_n16 才會把 shell 指向 TSMC 16 奈米 ADFP 的資料——也就是 DC 要對映過去的 .db 時序函式庫，以及閘級模擬器需要的 Verilog 元件模型。沒做就直接開 dc_shell，DC 要嘛找不到 target library，要嘛默默對映到某個預設製程——那你的面積數字跟別人的根本不能比。snsd はサイトのライセンス / 環境セレクタである。ADFP_n16 を選ぶことでシェルが TSMC 16 nm ADFP の資材——DC がマップ先とする .db タイミングライブラリと、ゲートレベルシミュレータが必要とする Verilog セルモデル——を向く。これをせずに dc_shell を起動すると、DC は target library を見つけられないか、設定されている既定のプロセスへ黙ってマップする。そうなると面積の数値は他の人のものと並べても意味がない。
The ADFP addendum to the DC SOP says the same in one line: 進入以下畫面後，source Design Compiler 和 ADFP 的權限 — you need both entries, the tool licence and the process.DC SOP 的 ADFP 補充文件一句話說了同樣的事：進入以下畫面後，source Design Compiler 和 ADFP 的權限——兩項都要，工具授權和製程。DC SOP の ADFP 補足文書も 1 行で同じことを言っている：進入以下畫面後，source Design Compiler 和 ADFP 的權限——ツールのライセンスとプロセスの両方が必要だ。
DC reads .synopsys_dc.setup from, in order, the Synopsys install root, your home directory, and the directory you launch from. The last one wins. On a lab machine where snsd already configured ADFP a site-wide setup file usually exists and you may not need your own — check first:DC 會依序從 Synopsys 安裝根目錄、你的家目錄、以及你啟動它的那個目錄讀取 .synopsys_dc.setup，最後一個優先。在 snsd 已經配好 ADFP 的實驗室機器上，通常已經有站台層級的設定檔，你不見得需要自己寫——先檢查：DC は .synopsys_dc.setup を、Synopsys のインストールルート、ホームディレクトリ、起動したディレクトリの順に読み、最後のものが優先される。snsd がすでに ADFP を設定している実験室のマシンなら、たいていサイト全体の設定ファイルが存在し、自分で書く必要はない。まず確認すること：
ls -a ./.synopsys_dc.setup ~/.synopsys_dc.setup
If neither exists, write one in the directory you will run DC from:如果兩個都不存在，就在你要執行 DC 的目錄裡寫一份：どちらも存在しなければ、DC を実行するディレクトリに 1 つ書く：
#=== .synopsys_dc.setup — TSMC N16 ADFP, cell-based === set ADFP /cad/CBDK/Executable_Package/Collaterals/IP/stdcell/N16ADFP_StdCell set search_path [concat $search_path $ADFP/CCS $ADFP/NLDM ./] # Library DC maps gates into. Must be one real .db found in search_path. set target_library { N16ADFP_StdCellff0p88v125c_ccs.db } # Everything DC must resolve while linking. # "*" = look in DC memory first # dw_foundation = lets DesignWare IP (adders, multipliers, sqrt...) be mapped set link_library [concat "*" $target_library dw_foundation.sldb] set symbol_library { generic.sdb } define_design_lib work -path ./work sh mkdir -p ./work
REFRACT.sdc ends withREFRACT.sdc 的結尾是REFRACT.sdc の末尾はこうなっている
set_operating_conditions -library N16ADFP_StdCellff0p88v125c_ccs set_wire_load_model -name ZeroWireload -library N16ADFP_StdCellff0p88v125c_ccs
Both commands take a library that is already loaded. So whichever corner the SDC names must appear in target_library or link_library, otherwise you get Error: Can't find library 'N16ADFP_StdCellff0p88v125c_ccs' the moment the SDC is sourced. The simplest consistent choice is to make the target library the same corner the SDC names — which is what the template above does.這兩道指令吃的函式庫都必須已經載入。所以 SDC 指名的那個 corner 一定要出現在 target_library 或 link_library 裡，否則 SDC 一被 source 就會得到 Error: Can't find library 'N16ADFP_StdCellff0p88v125c_ccs'。最簡單又一致的做法，就是讓 target library 等於 SDC 指名的那個 corner——上面的範本正是這麼做的。どちらのコマンドもすでにロードされたライブラリを引数に取る。したがって SDC が名指しするコーナーは target_library か link_library に現れていなければならず、そうでなければ SDC を source した瞬間に Error: Can't find library 'N16ADFP_StdCellff0p88v125c_ccs' が出る。最も単純で一貫した選び方は、target library を SDC が名指しするコーナーと同じにすることで、上のテンプレートはまさにそうしている。
ff0p88v125c is a fast-fast corner: 0.88 V, 125 °C, fast transistors. The textbook choice for a setup-time (max) analysis is the slow corner — ss0p72v125c or ss0p72vm40c — which is what the ADFP Cloud manual lists as target_library (slow case). Constraining at a fast corner makes timing look easier than silicon would.ff0p88v125c 是 fast-fast corner：0.88 V、125 °C、快速電晶體。教科書上做建立時間（max）分析該選的是慢 corner——ss0p72v125c 或 ss0p72vm40c——也正是 ADFP Cloud 手冊列為 target_library (slow case) 的那一組。用快 corner 下約束，會讓時序看起來比真實矽片輕鬆。ff0p88v125c は fast-fast コーナーである：0.88 V、125 °C、速いトランジスタ。セットアップ時間（max）解析で教科書的に選ぶのは遅いコーナー——ss0p72v125c または ss0p72vm40c——であり、ADFP Cloud マニュアルが target_library (slow case) として挙げているのもそちらだ。速いコーナーで制約をかけると、タイミングは実シリコンより楽に見えてしまう。
Keep the SDC as the course gave it: every group is graded against the same constraint, and changing it makes your Area and Period incomparable. But know what the number means, and be able to say so if asked in the presentation.但 SDC 請保持課程給的原樣：每一組都用同一組約束評分，改了就讓你的 Area 和 Period 失去可比性。不過你要知道這個數字的意義，被問到時說得出來。ただし SDC は授業で配られたままにしておくこと。どの班も同じ制約で採点されるので、変えてしまうと Area と Period が比較できなくなる。とはいえその数値の意味は理解し、発表で問われたら説明できるようにしておく。
Corner names decode as <ss|ff><voltage>v<temperature>, with m40c meaning −40 °C:Corner 命名的解讀方式是 <ss|ff><電壓>v<溫度>，其中 m40c 代表 −40 °C：コーナー名は <ss|ff><電圧>v<温度> と読み、m40c は −40 °C を意味する：
| Library函式庫ライブラリ | CornerCornerコーナー | Normal use一般用途通常の用途 |
|---|---|---|
| N16ADFP_StdCellss0p72v125c_ccs | slow, 0.72 V, 125 °C慢速、0.72 V、125 °C遅い、0.72 V、125 °C | setup / max analysissetup / max 分析setup / max 解析 |
| N16ADFP_StdCellss0p72vm40c_ccs | slow, 0.72 V, −40 °C慢速、0.72 V、−40 °C遅い、0.72 V、−40 °C | setup, cold cornersetup，低溫 cornersetup、低温コーナー |
| N16ADFP_StdCellff0p88v125c_ccs | fast, 0.88 V, 125 °C快速、0.88 V、125 °C速い、0.88 V、125 °C | hold / min analysis — what this SDC useshold / min 分析 — 這份 SDC 用的就是它hold / min 解析 — この SDC が使っているもの |
CCS vs NLDM: CCS (Composite Current Source) models a cell as a current source and is the more accurate of the two; NLDM is the older lookup-table delay model. ADFP ships both, under $ADFP/CCS/ and $ADFP/NLDM/. The SDC names _ccs, so use the CCS directory.CCS 與 NLDM：CCS（Composite Current Source）把元件模擬成電流源，是兩者中較精確的；NLDM 則是較舊的查表式延遲模型。ADFP 兩種都有，分別放在 $ADFP/CCS/ 和 $ADFP/NLDM/。SDC 指名的是 _ccs，所以用 CCS 目錄。CCS と NLDM：CCS（Composite Current Source）はセルを電流源としてモデル化するもので、2 つのうち精度が高い。NLDM は古いルックアップテーブル方式の遅延モデルである。ADFP は両方を $ADFP/CCS/ と $ADFP/NLDM/ に用意している。SDC が名指しするのは _ccs なので、CCS のディレクトリを使う。
The local site path is visible in xrun.cmd, where the gate-level runs load /cad/CBDK/Executable_Package/Collaterals/IP/stdcell/N16ADFP_StdCell/VERILOG/N16ADFP_StdCell.v. The ADFP Cloud 2.0 manual uses /ADFP/Executable_Package/... for the same tree. Check which root your machine has:本地站台的路徑可以在 xrun.cmd 裡看到，閘級模擬在那裡載入 /cad/CBDK/Executable_Package/Collaterals/IP/stdcell/N16ADFP_StdCell/VERILOG/N16ADFP_StdCell.v。ADFP Cloud 2.0 手冊對同一棵樹用的是 /ADFP/Executable_Package/...。確認你的機器是哪一個根目錄：ローカルサイトのパスは xrun.cmd で確認できる。ゲートレベル実行はそこで /cad/CBDK/Executable_Package/Collaterals/IP/stdcell/N16ADFP_StdCell/VERILOG/N16ADFP_StdCell.v を読み込んでいる。ADFP Cloud 2.0 マニュアルは同じツリーに /ADFP/Executable_Package/... を使う。自分のマシンがどちらのルートかを確認すること：
ls /cad/CBDK/Executable_Package/Collaterals/IP/stdcell/N16ADFP_StdCell/CCS/ | head ls /ADFP/Executable_Package/Collaterals/IP/stdcell/N16ADFP_StdCell/CCS/ | head
The script you were given is a generic template that still carries TSMC 0.13 µm settings. Run it as-is against ADFP N16 and DC stops with Can't find library 'slow'. This is exactly the fix the ADFP addendum describes: comment out the old process lines, and let the SDC supply the new ones.你拿到的腳本是通用範本，裡面還留著 TSMC 0.13 µm 的設定。原封不動拿去跑 ADFP N16，DC 會停在 Can't find library 'slow'。這正是 ADFP 補充文件描述的修法：把舊製程那幾行註解掉，改由 SDC 提供新的。配られたスクリプトは汎用テンプレートで、TSMC 0.13 µm の設定がまだ残っている。そのまま ADFP N16 に対して実行すると、DC は Can't find library 'slow' で止まる。これはまさに ADFP 補足文書が説明している修正である：古いプロセスの行をコメントアウトし、新しい設定は SDC に供給させる。
#--- DELETE or COMMENT OUT these two (tsmc13 leftovers) ---
set_operating_conditions -max_library slow -max slow
set_wire_load_model -name tsmc13_wl10 -library slow
REFRACT.sdc already sets both for N16, and it is sourced a few lines later, so nothing is lost.REFRACT.sdc 已經為 N16 設好這兩項，而且幾行之後就會被 source，所以什麼都不會少。REFRACT.sdc はすでに N16 用に両方を設定しており、数行あとで source されるので失われるものはない。
set DESIGN "REFRACT" set_host_options -max_cores 16 ############## Read all files ############## analyze -format verilog ${DESIGN}.v # -format sverilog if you wrote SV elaborate ${DESIGN} link current_design ${DESIGN} # set_operating_conditions -max_library slow -max slow <-- tsmc13, removed # set_wire_load_model -name tsmc13_wl10 -library slow <-- tsmc13, removed ############## Constraints ############## source -echo -verbose ${DESIGN}.sdc set_fix_hold [all_clocks] check_timing check_design set high_fanout_net_threshold 0 uniquify set_fix_multiple_port_nets -all -buffer_constants [get_designs *] ############## Compile ############## compile -exact_map # compile -map_effort high -area_effort high # compile -map_effort high -area_effort high -inc # compile_ultra -no_autoungroup ############## Clean names BEFORE writing ############## define_name_rules name_rule -case_insensitive change_names -hierarchy -rules name_rule change_names -hierarchy -rules verilog ############## Outputs ############## write -format ddc -hierarchy -output "${DESIGN}_syn.ddc" write -format verilog -hierarchy -output ${DESIGN}_syn.v write_sdf -version 2.1 ${DESIGN}_syn.sdf ############## Reports ############## report_area -hierarchy > area.log report_timing -delay max > timing_max.log report_timing -delay min > timing_min.log report_power > power.log report_qor > ${DESIGN}_syn.qor report_constraint -all_violators > violation.log exit
| Added / changed新增 / 變更追加 / 変更 | Why為什麼理由 |
|---|---|
| check_timing | Lists paths you forgot to constrain. Unconstrained endpoints are not optimised and silently "pass". The SOP lists it as the companion to check_design.列出你忘了下約束的路徑。未受約束的端點不會被最佳化，卻會默默「通過」。SOP 把它列為 check_design 的搭檔。制約を忘れたパスを列挙する。制約のないエンドポイントは最適化されないのに、黙って「通過」してしまう。SOP はこれを check_design の相棒として挙げている。 |
| define_name_rules / change_names | Strips illegal characters and case collisions out of net and instance names. Skip it and the netlist can be unreadable by the simulator or fail LVS downstream. Straight from SOP Step 7.把連線與實例名稱中的非法字元與大小寫衝突清掉。省略它，網表可能讓模擬器讀不懂，或在後段 LVS 失敗。直接取自 SOP 第 7 步。ネットとインスタンス名から不正な文字と大文字小文字の衝突を取り除く。省略すると、ネットリストをシミュレータが読めなかったり、後段の LVS で落ちたりする。SOP 手順 7 そのままである。 |
| write_sdf -version 2.1 | The template says 1.0; the SOP says 2.1, which is what modern $sdf_annotate expects. If your simulator complains, fall back to 1.0 — the file is only read by the testbench.範本寫 1.0；SOP 寫 2.1，而後者才是現代 $sdf_annotate 預期的版本。若你的模擬器抱怨，退回 1.0 即可——這個檔只有 testbench 會讀。テンプレートは 1.0 と書くが、SOP は 2.1 と書く。現代の $sdf_annotate が期待するのは後者だ。シミュレータが文句を言うなら 1.0 に戻せばよい。このファイルを読むのはテストベンチだけである。 |
| report_power | The template never writes power, but the Excel asks for Power (mW). Without this line you re-run DC just to get one number.範本從來不輸出功耗，但 Excel 要 Power (mW)。少了這一行，你就得為了一個數字重跑一次 DC。テンプレートは電力を一切出力しないが、Excel は Power (mW) を求める。この行がないと、たった 1 つの数値のために DC を再実行することになる。 |
| report_timing -delay min | Setup (max) alone hides hold violations. With set_fix_hold active you want to confirm hold really was fixed.只看 setup（max）會蓋掉 hold 違規。既然開了 set_fix_hold，就該確認 hold 真的被修好了。setup（max）だけを見ると hold 違反を見落とす。set_fix_hold を有効にしているなら、hold が本当に直ったことを確認したい。 |
| report_constraint -all_violators | One file answering "is anything violated at all" — timing, max fanout, max transition, max capacitance.用一個檔回答「到底有沒有任何東西違規」——時序、max fanout、max transition、max capacitance。「そもそも何か違反しているか」に 1 つのファイルで答える——タイミング、max fanout、max transition、max capacitance。 |
This file decides your Period, and therefore most of your score. Nothing else in the flow has as much leverage.這個檔決定你的 Period，也因此決定你大部分的分數。整個流程裡沒有別的東西有這麼大的槓桿。このファイルが Period を決め、したがって得点の大部分を決める。フロー中でこれほど効くものは他にない。
set cycle 5.0 ;# clock period defined by designer <-- YOUR KNOB create_clock -name CLK -period $cycle [get_ports CLK] set_dont_touch_network [all_clocks] set_fix_hold [all_clocks] set_clock_uncertainty -setup 0.1 [all_clocks] set_clock_uncertainty -hold 0.05 [all_clocks] set_clock_latency 0.5 [all_clocks] set_ideal_network [get_ports CLK] #Don't touch the basic env setting as below set_input_delay -max [expr $cycle / 10.0] -clock CLK \ [remove_from_collection [all_inputs] [get_ports CLK]] set_input_delay -min 0.0 -clock CLK \ [remove_from_collection [all_inputs] [get_ports CLK]] set_output_delay -max [expr $cycle / 10.0] -clock CLK [all_outputs] set_output_delay -min 0.0 -clock CLK [all_outputs] set_load 0.01 [all_outputs] set_drive 0.1 [all_inputs] set_operating_conditions -library N16ADFP_StdCellff0p88v125c_ccs set_wire_load_model -name ZeroWireload -library N16ADFP_StdCellff0p88v125c_ccs set_max_fanout 6 [all_inputs]
| Command指令コマンド | Meaning意義意味 |
|---|---|
| create_clock -period $cycle | Defines the only clock. Every register-to-register path must close inside $cycle.定義唯一的時脈。每條暫存器對暫存器的路徑都必須在 $cycle 內收斂。唯一のクロックを定義する。すべてのレジスタ間パスは $cycle 以内に収まらなければならない。 |
| set_dont_touch_network | Leave the clock tree alone — it is built at place-and-route, not here.別動時脈樹——它是在 place-and-route 階段才建的，不是這裡。クロックツリーには手を付けない——それは配置配線で構築されるもので、ここではない。 |
| set_ideal_network [get_ports CLK] | Treat the clock as infinitely strong, zero transition. The SOP is blunt: without both dont_touch_network and ideal_network the timing analysis 爆掉 — DC starts buffering the clock and the report becomes fiction.把時脈視為驅動力無限大、轉態為零。SOP 說得很直接：少了 dont_touch_network 和 ideal_network 其中任一個，時序分析就會爆掉——DC 會開始對時脈插緩衝器，報告也就成了虛構。クロックを駆動力無限大・遷移時間ゼロとして扱う。SOP は率直だ：dont_touch_network と ideal_network のどちらか一方でも欠けるとタイミング解析は爆掉——DC がクロックにバッファを挿入しはじめ、レポートは作り話になる。 |
| set_clock_uncertainty | Margin for the clock skew and jitter P&R will introduce: 0.1 ns setup, 0.05 ns hold. It is subtracted from your usable period.為 P&R 將引入的時脈偏斜與抖動預留的餘裕：setup 0.1 ns、hold 0.05 ns。這是從你可用的週期中扣掉的。配置配線が持ち込むクロックスキューとジッタのためのマージン：setup 0.1 ns、hold 0.05 ns。使える周期から差し引かれる。 |
| set_clock_latency 0.5 | Modelled insertion delay from the clock port to the flip-flop clock pins.從時脈埠到正反器時脈腳之間，被模擬出來的插入延遲。クロックポートからフリップフロップのクロックピンまでの挿入遅延をモデル化した値。 |
| set_input_delay / set_output_delay | How much of the cycle is consumed outside your block. At $cycle/10, 10 % goes at the input and 10 % at the output, leaving 80 % for your logic. Marked "don't touch" — leave them.一個週期中有多少被你的區塊之外消耗掉。設成 $cycle/10 時，輸入端 10 %、輸出端 10 %，留 80 % 給你的邏輯。檔案裡註明「別動」——就別動。1 周期のうちどれだけが自分のブロックの外で消費されるか。$cycle/10 なら入力側 10 %、出力側 10 % で、論理には 80 % が残る。「触るな」と注記されている——そのままにしておくこと。 |
| set_load 0.01 / set_drive 0.1 | Output capacitance (pF) and input driver resistance — block-to-block scale values, consistent with the SOP's guidance (0.002 block-to-block, 0.05 excluding IO pads, 10 for PCB, 40 for the TSRI 93k tester).輸出電容（pF）與輸入驅動電阻——區塊對區塊等級的數值，與 SOP 的建議一致（區塊對區塊 0.002、不含 IO pad 0.05、PCB 10、TSRI 93k 測試機 40）。出力容量（pF）と入力ドライバ抵抗——ブロック間規模の値で、SOP の指針（ブロック間 0.002、IO パッドを除いて 0.05、PCB は 10、TSRI 93k テスタは 40）と一致する。 |
| set_wire_load_model ZeroWireload | Pre-layout wire delay ignored. Intentional: the SOP notes net-area estimates are inaccurate enough that most flows no longer set a real WLM.忽略佈局前的連線延遲。這是刻意的：SOP 指出淨面積估計不準到一個程度，多數流程已不再設定真正的 WLM。レイアウト前の配線遅延を無視する。これは意図的で、SOP はネット面積の見積もりが不正確なため多くのフローがもはや実際の WLM を設定しないと述べている。 |
| set_max_fanout 6 | Design-rule constraint — no net drives more than 6 loads; DC inserts buffers to comply.設計規則約束——任何連線驅動的負載不超過 6 個；DC 會插緩衝器來符合。デザインルール制約——どのネットも負荷を 6 個より多く駆動しない。DC は適合させるためにバッファを挿入する。 |
REFRACT.sdc has set cycle 5.0. tb.v has `define CYCLE 50.0. EP1 announcement item 5 is explicit: if you modify the Period, update the setting in both REFRACT.sdc and tb.v; the DC SOP Step 8 repeats it — CYCLE 的數值需與 SDC 所設定的 Clock 數值相同.REFRACT.sdc 寫 set cycle 5.0，tb.v 卻寫 `define CYCLE 50.0。EP1 公告第 5 點講得很明白：若你改動 Period，REFRACT.sdc 和 tb.v 兩邊都要更新；DC SOP 第 8 步也重複了一次——CYCLE 的數值需與 SDC 所設定的 Clock 數值相同。REFRACT.sdc は set cycle 5.0、tb.v は `define CYCLE 50.0 である。EP1 公告の第 5 項は明確だ：Period を変更したら REFRACT.sdc と tb.v の両方の設定を更新すること。DC SOP の手順 8 も繰り返している——CYCLE 的數值需與 SDC 所設定的 Clock 數值相同。
Simulating at 50 ns a netlist synthesized for 5 ns will pass — you gave it ten times the time it needs — so the mismatch produces no error. It produces a Latency number that is 10× too large, and a gate-level run that proves nothing about whether the design closes at 5 ns. Decide on one period, write it into both files, re-run both.拿一份為 5 ns 合成的網表在 50 ns 下模擬，一定會過——你給了它十倍的時間——所以這個不一致不會產生任何錯誤訊息。它產生的是一個大了 10 倍的 Latency 數字，以及一次完全無法證明設計能在 5 ns 收斂的閘級模擬。選定一個週期，寫進兩個檔案，兩邊都重跑。5 ns 用に合成したネットリストを 50 ns でシミュレーションすれば必ず通る——必要な時間の 10 倍を与えたのだから——ので、この食い違いはエラーを生まない。生むのは10 倍大きい Latency の数値と、5 ns で設計が収束するかどうかを何も証明しないゲートレベル実行である。周期を 1 つに決め、両方のファイルに書き、両方を再実行すること。
Start where the file starts (5.0 ns) and get a clean flow end to end. Then sweep: lower $cycle until report_timing shows negative slack or gate-level sim fails, and back off one step. The score generally rewards small Area × small Period × small Latency — but a design that fails gate-level sim scores nothing, so bank a working version before chasing the last 0.2 ns. Keep each attempt in its own directory (syn_5p0/, syn_4p5/) so you can always fall back.從檔案原本的值（5.0 ns）開始，先讓整條流程從頭到尾跑乾淨。然後掃描：把 $cycle 往下調，直到 report_timing 出現負 slack 或閘級模擬失敗，再退回一格。評分通常獎勵小面積 × 小週期 × 小延遲——但閘級模擬失敗的設計一分也拿不到，所以在追最後那 0.2 ns 之前，先把一個會動的版本存起來。每次嘗試放在自己的目錄（syn_5p0/、syn_4p5/），你才隨時退得回去。まずファイルの値（5.0 ns）のまま、端から端までクリーンに流すこと。次にスイープする：report_timing がスラック負を示すかゲートレベルシミュレーションが落ちるまで $cycle を下げ、1 段戻す。得点はおおむね小さい Area × 小さい Period × 小さい Latency を評価する——が、ゲートレベルで落ちる設計は 0 点なので、最後の 0.2 ns を追う前に動くバージョンを確保しておくこと。試行ごとに専用ディレクトリ（syn_5p0/、syn_4p5/）に置けば、いつでも戻れる。
REFRACT_syn.v is not a file you download or copy. It does not exist until Design Compiler writes it, and the line that writes it is already in your script:REFRACT_syn.v 不是一個你去下載或複製的檔案。在 Design Compiler 寫出它之前它並不存在，而寫出它的那一行早就在你的腳本裡：REFRACT_syn.v はダウンロードしたりコピーしたりするファイルではない。Design Compiler が書き出すまで存在せず、それを書き出す行はすでにスクリプトの中にある：
write -format verilog -hierarchy -output ${DESIGN}_syn.v <- dc_syn.tcl
So "getting" it means running a synthesis that completes. The whole recipe, assuming the sections above are done:所以所謂「拿到」它，就是跑完一次成功的合成。假設前面各節都做完了，完整流程是：つまり「手に入れる」とは、完走する合成を 1 回走らせるということだ。前節までが済んでいる前提で、手順の全体は：
# On the lab Linux workstation. This cannot be done on Windows — # the licence and the N16ADFP .db libraries only exist there. cd .../2026_grad_cell snsd # 1. Design Compiler licence, then ADFP_n16 vi dc_syn.tcl # 2. comment out the two tsmc13 lines (§4): # set_operating_conditions -max_library slow -max slow # set_wire_load_model -name tsmc13_wl10 -library slow dc_shell -f dc_syn.tcl | tee syn.log # 3. run it (minutes, not seconds) grep -n "^Error" syn.log # 4. must print nothing ls -l REFRACT_syn.v REFRACT_syn.sdf REFRACT_syn.ddc
If step 4 is silent and the three files carry a fresh timestamp and a non-zero size, you have your netlist. A quick look to confirm it is what you think it is:如果第 4 步沒有任何輸出，而那三個檔案都有新的時間戳記與非零大小，你的網表就到手了。再快速看一眼，確認它確實是你以為的東西：手順 4 が無言で終わり、3 つのファイルが新しいタイムスタンプと 0 でないサイズを持っていれば、ネットリストは手に入っている。思ったとおりのものかどうか、ざっと確認する：
head -30 REFRACT_syn.v # module REFRACT (...); then nothing but cell instances grep -c "BWP" REFRACT_syn.v # rough gate count — N16ADFP cell names contain BWP
DC writes REFRACT_syn.v as long as compile ran to completion, whether or not timing was met. The file existing proves nothing by itself. It is a usable result only when, in addition:只要 compile 跑完，DC 就會寫出 REFRACT_syn.v，不管時序有沒有收斂。檔案存在本身什麼都證明不了。它要同時滿足以下條件，才算是可用的結果：compile が最後まで走りさえすれば、タイミングが収束したかどうかに関係なく DC は REFRACT_syn.v を書き出す。ファイルが存在すること自体は何の証明にもならない。次の条件がそろって初めて使える結果になる：
Until all four hold, treat the netlist as a draft.在四項全部成立之前，把這份網表當草稿看待。4 つすべてが成り立つまでは、このネットリストは下書きだと思っておくこと。
The RTL is the merged hierarchy below. All nine modules are synthesizable as written — no delays, no initial blocks, no ** with a variable base, no behavioural-only construct — so analyze -format verilog takes the whole file in one go.RTL 就是下面這棵合併後的階層。九個模組照原樣都可以合成——沒有延遲、沒有 initial 區塊、沒有以變數為底的 **、沒有任何只能模擬的語法——所以 analyze -format verilog 一次就能把整個檔吃下去。RTL は下のマージ済み階層である。9 つのモジュールはいずれも書かれたまま合成可能で——遅延なし、initial ブロックなし、変数を底とする ** なし、シミュレーション専用の記述なし——だから analyze -format verilog はファイル全体を一度に受け取れる。
| Check檢查項目確認項目 | Status狀態状態 |
|---|---|
| Address map vs golden/*.memh位址對映 vs golden/*.memhアドレスマップと golden/*.memh | Matches. SRAM_A <= {out_y, out_x, 1'b0} gives 2i and 2i+1 for i = 16Y + X. All 512 golden words are populated, and words 0/1 and 510/511 are equal pairs — the symmetric corners (0,0) and (15,15). Same layout.相符。SRAM_A <= {out_y, out_x, 1'b0} 對 i = 16Y + X 給出 2i 與 2i+1。512 個 golden 字全都有值，而第 0/1 與第 510/511 字成對相等——對應對稱的角落 (0,0) 與 (15,15)。版面相同。一致。SRAM_A <= {out_y, out_x, 1'b0} は i = 16Y + X に対して 2i と 2i+1 を与える。512 個の golden ワードはすべて埋まっており、ワード 0/1 と 510/511 は等しい対——対称な角 (0,0) と (15,15) に対応する。配置は同じである。 |
| Run length vs `MAX_CYCLE執行長度 vs `MAX_CYCLE実行長と `MAX_CYCLE | Fits. 256 points × ~148 clocks ≈ 37 893 clocks, against the 100 000 limit. At a 5 ns period that is a Latency of roughly 189 µs.放得下。256 個點 × 約 148 個時脈 ≈ 37 893 個時脈，對上限 100 000。在 5 ns 週期下，Latency 約為 189 µs。収まる。256 点 × 約 148 クロック ≈ 37 893 クロックで、上限の 100 000 に対して余裕がある。周期 5 ns なら Latency はおよそ 189 µs。 |
| Reset coverage重置涵蓋範圍リセットの範囲 | Safe, but not clean. The clocked blocks in unit_normal_vector and refract_vector have no reset, so nx/ny/nz and T hold x at gate level until their first update. The start sequencing means nothing samples them before then, so simulation is fine — but Spyglass will flag it, and EP1 wants a clean Spyglass run.安全，但不乾淨。unit_normal_vector 與 refract_vector 裡的時脈區塊沒有重置，所以 nx/ny/nz 和 T 在閘級下會一直是 x，直到第一次更新為止。啟動時序安排使得在那之前沒有東西會取樣它們，所以模擬沒問題——但 Spyglass 會標記它，而 EP1 要求 Spyglass 乾淨。安全だが、きれいではない。unit_normal_vector と refract_vector のクロック同期ブロックにはリセットがないので、nx/ny/nz と T はゲートレベルで最初の更新まで x のままになる。起動のシーケンスにより、それ以前にこれらをサンプリングするものはないのでシミュレーションは問題ない——しかし Spyglass は指摘するし、EP1 は Spyglass がクリーンであることを求める。 |
| Unused ports未使用的埠未使用のポート | SRAM_Q (required by the interface), test.z and ray_top.n_done are driven but never read. Harmless to DC; more Spyglass warnings.SRAM_Q（介面規定要有）、test.z 和 ray_top.n_done 被驅動卻從未被讀取。對 DC 無害；但會多出 Spyglass 警告。SRAM_Q（インタフェース上必須）、test.z、ray_top.n_done は駆動されているが読まれていない。DC には無害だが、Spyglass の警告が増える。 |
| Combinational arithmetic組合邏輯算術組合せ論理の算術 | The thing to watch. See below.這才是要盯的地方。見下文。注視すべきはここ。以下を参照。 |
z_surface and normal_vector raise a 40-bit value to the 8th and 7th power by writing the multiplication out:z_surface 和 normal_vector 把一個 40 位元的值寫成連乘，算出 8 次方與 7 次方：z_surface と normal_vector は、40 ビットの値の 8 乗と 7 乗を掛け算を書き下す形で求めている：
dx = {36'b0,x} - 40'sd8;
temp = (40'sd6 << 24) - ((dx*dx*dx*dx*dx*dx*dx*dx)<<1) - ... // z_surface
x1 = (dx*dx*dx*dx*dx*dx*dx)<<14; // normal_vector
Read literally, that is a chain of seven 40×40 multipliers in one combinational cone, feeding yet another multiply — z * ax in ray_z0, or the three squares in sum — before anything is registered. Nothing in a 5 ns budget survives eight dependent multipliers, and the area is large.照字面讀，那是同一個組合錐裡串了七個 40×40 乘法器，接著還要再乘一次——ray_z0 裡的 z * ax，或 sum 裡的三個平方——然後才進暫存器。5 ns 的預算撐不住八層相依的乘法器，而且面積很大。文字どおりに読めば、これは 1 つの組合せコーンの中に 40×40 の乗算器が 7 段つながり、その先でさらにもう 1 回掛ける——ray_z0 の z * ax、あるいは sum の 3 つの二乗——という構造で、そこまでレジスタに入らない。5 ns の予算で依存関係のある乗算器 8 段は持ちこたえられないし、面積も大きい。
DC may rescue it: x and y are only 4 bits, so the whole cone is a Boolean function of 8 inputs, and if DC flattens it instead of keeping it as a datapath block it can collapse to almost nothing. That is not a property to gamble a submission on. Replacing each chain with the 16-entry table it actually is removes the multipliers outright and costs about twenty lines:DC 有可能救得了它：x 和 y 只有 4 位元，所以整個錐其實是 8 個輸入的布林函數，只要 DC 把它攤平而不是當成 datapath 區塊保留，就可能縮到幾乎沒有。但這不是能拿一份作業去賭的性質。把每條連乘換成它本來就是的 16 項查表，可以直接消掉乘法器，代價約二十行：DC が救ってくれる可能性はある：x と y は 4 ビットしかないので、コーン全体は入力 8 本のブール関数であり、DC がデータパスブロックとして保持せず平坦化すれば、ほとんど無に縮む。しかし提出物を賭けてよい性質ではない。それぞれの連鎖を、実際にはそれそのものである 16 エントリのテーブルに置き換えれば乗算器はきれいに消え、コストは 20 行ほどである：
// (x-8)^8 for x = 0..15. 2*((x-8)/8)^8 in q4.24 is exactly (x-8)^8 << 1. function [24:0] p8(input [3:0] v); case (v) 4'd0: p8 = 25'd16777216; 4'd8: p8 = 25'd0; 4'd1: p8 = 25'd5764801; 4'd9: p8 = 25'd1; 4'd2: p8 = 25'd1679616; 4'd10: p8 = 25'd256; 4'd3: p8 = 25'd390625; 4'd11: p8 = 25'd6561; 4'd4: p8 = 25'd65536; 4'd12: p8 = 25'd65536; 4'd5: p8 = 25'd6561; 4'd13: p8 = 25'd390625; 4'd6: p8 = 25'd256; 4'd14: p8 = 25'd1679616; 4'd7: p8 = 25'd1; 4'd15: p8 = 25'd5764801; endcase endfunction wire signed [39:0] temp = (40'sd6 <<< 24) - ({15'd0, p8(x)} <<< 1) - ({15'd0, p8(y)} <<< 1); assign z = temp[27:0];
The same applies to normal_vector, where (x-8)^7 is a signed 23-bit table. Tabling its square as well deletes the three 36×36 multipliers in sum, because x1² = ((x-8)^7)² << 28:normal_vector 也一樣，那裡的 (x-8)^7 是一張有號 23 位元的表。連它的平方也一併查表，還能刪掉 sum 裡那三個 36×36 乘法器，因為 x1² = ((x-8)^7)² << 28：normal_vector も同様で、そこの (x-8)^7 は符号付き 23 ビットのテーブルになる。その二乗までテーブル化すれば、x1² = ((x-8)^7)² << 28 なので sum の 36×36 乗算器 3 個も消せる：
// x (x-8)^7 ((x-8)^7)^2 // 0 -2097152 4398046511104 // 1 -823543 678223072849 // 2 -279936 78364164096 // 3 -78125 6103515625 // 4 -16384 268435456 // 5 -2187 4782969 // 6 -128 16384 // 7 -1 1 // 8 0 0 // 9 1 1 // 10 128 16384 // 11 2187 4782969 // 12 16384 268435456 // 13 78125 6103515625 // 14 279936 78364164096 // 15 823543 678223072849 assign x1 = {{13{p7x[22]}}, p7x} <<< 14; // q2.34, p7x is signed [22:0] assign z1 = 36'sd1 <<< 34; assign sum = ({29'd0, p7sq(x)} <<< 28) + ({29'd0, p7sq(y)} <<< 28) + (72'd1 <<< 68); // q4.68
The multiplies worth keeping are the ones whose operands are genuinely wide at run time: z * ax and z * ay in ray_z0, and the three 56×36 products in refract_vector's output stage. Those are one level deep and run in parallel.值得留下的乘法，是那些運算元在執行期真的很寬的：ray_z0 裡的 z * ax 與 z * ay，以及 refract_vector 輸出級的三個 56×36 乘積。它們只有一層深，而且是並行的。残す価値のある乗算は、実行時にオペランドが本当に広いものである：ray_z0 の z * ax と z * ay、そして refract_vector の出力段にある 3 つの 56×36 の積。これらは 1 段の深さで、並列に動く。
Measure before rewriting. The tables are a safe change in principle, but they are still a change to working arithmetic, and the golden comparison allows an error of only 16/4096.先量測，再改寫。查表原則上是安全的改動，但它畢竟是在動一段本來就正確的算術，而 golden 比對只容許 16/4096 的誤差。書き換える前に測ること。テーブル化は原理的には安全な変更だが、正しく動いている算術に手を入れることに変わりはなく、golden との比較が許す誤差は 16/4096 しかない。
REFRACT_lut.v sits next to REFRACT.v in 2026_grad_cell/. It is the same file with only z_surface and normal_vector rewritten as tables — every other module is copied across unchanged, and the top module is still called REFRACT, so the testbench does not know the difference.REFRACT_lut.v 就放在 2026_grad_cell/ 裡 REFRACT.v 旁邊。它是同一份檔案，只有 z_surface 與 normal_vector 改寫成查表——其他模組原封不動照抄，而上層模組依然叫 REFRACT，所以 testbench 根本察覺不出差別。REFRACT_lut.v は 2026_grad_cell/ の REFRACT.v の隣にある。同じファイルで、z_surface と normal_vector だけをテーブルとして書き直したもの——他のモジュールはそのまま複写されており、トップモジュールの名前も REFRACT のままなので、テストベンチは違いに気づかない。
The two versions were checked to be bit-identical over all 256 (x, y) for z, x1, y1, z1 and sum, modelling Verilog's truncation at every assignment width. The tables carry no headroom they do not need: p8 peaks at 16 777 216 in a 25-bit field, p7 spans −2 097 152…823 543 in a signed 23-bit field, p7sq peaks at 4 398 046 511 104 in 43 bits.兩個版本已經驗證過，在全部 256 組 (x, y) 下，z、x1、y1、z1 與 sum 皆逐位元相同，而且是在模擬 Verilog 於每個指派位寬上的截斷之後。這些表沒有多餘的位寬：p8 的最大值 16 777 216 落在 25 位元欄位，p7 的範圍 −2 097 152…823 543 落在有號 23 位元欄位，p7sq 的最大值 4 398 046 511 104 落在 43 位元。2 つのバージョンは、z、x1、y1、z1、sum について 256 通りの (x, y) すべてでビット単位まで一致することを、各代入のビット幅での Verilog の切り捨てまでモデル化して確認済みである。テーブルは不要な余裕を持たない：p8 は 25 ビット幅で最大 16 777 216、p7 は符号付き 23 ビット幅で −2 097 152…823 543、p7sq は 43 ビットで最大 4 398 046 511 104 である。
# simulate the variant — identical command, different file xrun tb.v REFRACT_lut.v +define+RI=5 +access+r -clean -createdebugdb \ -input xrun.tcl \ +incdir+/cad/synopsys/synthesis/cur/dw/sim_ver/ +libext+.v # synthesize it into its own directory so the two results can be compared mkdir -p syn_lut && cd syn_lut cp ../REFRACT_lut.v ./REFRACT.v # dc_syn.tcl analyzes ${DESIGN}.v cp ../REFRACT.sdc ../dc_syn.tcl . dc_shell -f dc_syn.tcl | tee syn.log # then put the two side by side grep "Total cell area" ../area.log ./area.log grep slack ../timing_max.log ./timing_max.log
Whichever has the better area and slack after both have passed gate-level simulation for the RI values you are reporting. If DC already collapsed the chains on its own, the two results will be close and you should keep REFRACT.v — fewer moving parts. If they differ sharply, copy the winner over REFRACT.v, because the upload expects that filename and a single merged RTL file.在兩者都通過你要回報的那些 RI 值的閘級模擬之後，面積與 slack 較好的那個。如果 DC 本來就把連乘收掉了，兩邊結果會很接近，那就留 REFRACT.v——變數少比較好。如果差很多，就把贏的那份蓋到 REFRACT.v，因為上傳規定就是這個檔名，而且要單一合併的 RTL 檔。報告する RI 値についてどちらもゲートレベルシミュレーションを通ったあとで、面積とスラックの良いほうを選ぶ。DC がすでに自力で連鎖を潰していれば結果は近いはずで、その場合は REFRACT.v を残すのがよい——動く部分が少ないほうがよい。大きく違うなら勝ったほうを REFRACT.v に上書きする。提出はそのファイル名と、マージされた 1 つの RTL ファイルを前提にしているからだ。
dc_shell -f dc_syn.tcl | tee syn.log
Or, in the form the ADFP Cloud manual gives, with DC NXT and an explicit log file:或者，用 ADFP Cloud 手冊給的寫法，搭配 DC NXT 與明確的 log 檔：あるいは、ADFP Cloud マニュアルが示す形で、DC NXT と明示的なログファイルを使う：
dcnxt_shell -f dc_syn.tcl -x "set_host_options -max_cores 8" -output_log_file syn.log
dv & # site alias dc_shell -gui & # the real command behind it dcnxt_shell -f dc_syn.tcl -x "set_host_options -max_cores 8" -output_log_file syn.log -gui
In design_vision the prompt at the bottom takes the same commands; Tab completes them, and a return value of 1 means the command succeeded. The History pane re-runs anything you typed before. Menu equivalents: File → Read, Design → Compile Design, Design → Compile Ultra, Timing → Report Timing Path, Design → Report Area, Design → Report Power.在 design_vision 裡，底部的提示列吃同樣的指令；Tab 可以補完，回傳值 1 表示指令成功。History 窗格可以重跑你打過的任何東西。選單對應：File → Read、Design → Compile Design、Design → Compile Ultra、Timing → Report Timing Path、Design → Report Area、Design → Report Power。design_vision では下部のプロンプトが同じコマンドを受け付ける。Tab で補完でき、戻り値 1 はコマンドが成功したことを意味する。History ペインから、以前打ったものを再実行できる。メニューでの対応：File → Read、Design → Compile Design、Design → Compile Ultra、Timing → Report Timing Path、Design → Report Area、Design → Report Power。
If you stay in an interactive session and synthesize twice, clear the previous result first or you will link against stale designs:如果你待在互動式工作階段裡合成第二次，要先清掉前一次的結果，否則會 link 到過期的設計：対話セッションに留まったまま 2 回合成するなら、先に前回の結果を消すこと。さもないと古い設計に link してしまう：
remove_design -designs
source dc_syn.tcl
grep -nE "^Error|^Warning.*(latch|unresolved|multiple|sensitivity)" syn.log | head -40
The SOP says it plainly: Compiler 是利用演算法合成電路，因此每次給定 Constraints 所合成出來結果不一定會相同. Nudging the period by 0.1 ns can reorganise the whole netlist and move area by a surprising amount, sometimes in the direction you did not expect. Record the constraint set alongside every result.SOP 說得很直白：Compiler 是利用演算法合成電路，因此每次給定 Constraints 所合成出來結果不一定會相同。把週期推動 0.1 ns，可能就重組了整個網表，面積的變動幅度常常令人意外，方向有時還跟你預期的相反。每一份結果旁邊都記下當時的約束。SOP は率直に書いている：Compiler 是利用演算法合成電路，因此每次給定 Constraints 所合成出來結果不一定會相同。周期を 0.1 ns 動かすだけでネットリスト全体が組み替わり、面積が驚くほど動くことがあるし、予想と逆の方向に動くこともある。結果にはそのときの制約を必ず添えて記録すること。
grep -E "slack" timing_max.log timing_min.log
report_timing prints the single worst path; the last line is what matters:report_timing 只印出最差的那一條路徑；重點是最後一行：report_timing は最悪のパスを 1 本だけ表示する。重要なのは最後の行だ：
-delay max is setup, -delay min is hold. One at a time — the SOP notes you cannot ask for both in a single report_timing.-delay max 是 setup，-delay min 是 hold。一次只能問一種——SOP 指出同一道 report_timing 無法同時要求兩者。-delay max が setup、-delay min が hold である。一度に 1 つずつ——SOP は 1 回の report_timing で両方を要求することはできないと述べている。
grep -A4 "Total cell area" area.log
report_area -hierarchy also breaks the number down per sub-module, which is how you find which block is eating the budget. Report Total cell area in µm² (combinational + non-combinational). Note that if you ever run compile_ultra without -no_autoungroup, the hierarchy is dissolved and this breakdown disappears.report_area -hierarchy 還會把數字拆到各個子模組，這是你找出哪一塊在吃預算的方法。回報 µm² 的 Total cell area（組合 + 非組合）。注意：只要你跑過不帶 -no_autoungroup 的 compile_ultra，階層就會被打散，這份拆解也就消失了。report_area -hierarchy はサブモジュールごとの内訳も出すので、どのブロックが予算を食っているかが分かる。µm² の Total cell area（組合せ + 非組合せ）を報告すること。なお -no_autoungroup なしで compile_ultra を一度でも走らせると階層は解体され、この内訳は消える。
grep -A8 "Total Dynamic Power" power.log
Total power = dynamic (switching + internal) + leakage. Convert to mW for the Excel. Without an SAIF or VCD, DC estimates switching activity statistically, so treat it as a comparison number between your own runs rather than an absolute.總功耗 = 動態（切換 + 內部）+ 漏電。換算成 mW 填進 Excel。沒有 SAIF 或 VCD 時，DC 是用統計方式估切換活動率，所以把它當成你自己幾次執行之間的比較值，而不是絕對值。総電力 = 動的（スイッチング + 内部）+ リーク。Excel 用に mW へ換算すること。SAIF も VCD もない場合、DC はスイッチング確率を統計的に見積もるので、絶対値ではなく自分の実行どうしを比べる数値として扱うこと。
Dynamic power is burned charging loads and switching transistors; a flip-flop whose input never changes still burns clock power every cycle. Clock gating holds the clock low for registers that are not being updated, and the SOP puts the saving at 20–40 % depending on the design.動態功耗燒在充放電負載與電晶體切換上；一個輸入從不改變的正反器，每個週期照樣燒時脈功耗。Clock gating 把不更新的暫存器的時脈壓住，SOP 給出的節省幅度是 20–40 %，視設計而定。動的電力は負荷の充放電とトランジスタのスイッチングで消費される。入力が決して変わらないフリップフロップでも、毎サイクル クロックの電力を食う。クロックゲーティングは更新されないレジスタのクロックを止めるもので、SOP は設計にもよるが 20–40 % の削減としている。
compile -gate_clock # let DC insert gating automatically # or, manually: replace_clock_gate compile report_clock_gating -gating_elements
Two caveats from the SOP. First, inserted clock-gating cells can break the set_ideal_network on CLK and create a high-fanout net — check with report_net_fanout -high_fanout and re-apply set_ideal_network to the gated net if one appears. Second, the enable must be glitch-free: an unstable enable produces a glitch on the gated clock, which is a real functional failure, not a warning.SOP 有兩個提醒。第一，插入的 clock-gating 元件可能破壞 CLK 上的 set_ideal_network，並造出一條高扇出連線——用 report_net_fanout -high_fanout 檢查，若出現就對被 gate 的那條線重新套用 set_ideal_network。第二，enable 必須無毛刺：不穩定的 enable 會在被 gate 的時脈上產生毛刺，那是真正的功能失效，不只是警告。SOP からの注意が 2 つ。第 1 に、挿入されたクロックゲーティングセルが CLK の set_ideal_network を壊し、ファンアウトの大きいネットを作ってしまうことがある——report_net_fanout -high_fanout で確認し、出てきたらゲーティング後のネットに set_ideal_network をかけ直すこと。第 2 に、イネーブルはグリッチフリーでなければならない。不安定なイネーブルはゲーティングされたクロックにグリッチを生み、それは警告ではなく本物の機能不良である。
cat REFRACT_syn.qor
Worst slack, total negative slack, violating path count, cell count and total area, all in one place. This is the file to screenshot for your slides.最差 slack、總負 slack、違規路徑數、元件數與總面積，全在一個地方。這就是要截圖放進投影片的檔案。最悪スラック、総負スラック、違反パス数、セル数、総面積が 1 か所にまとまっている。スライド用にスクリーンショットを撮るならこのファイルだ。
| File檔案ファイル | Written by由誰寫出書き出すもの | Used for用途用途 |
|---|---|---|
| REFRACT_syn.v | write -format verilog -hierarchy | The gate-level netlist; input to gate-level simulation.閘級網表；閘級模擬的輸入。ゲートレベルネットリスト。ゲートレベルシミュレーションの入力になる。 |
| REFRACT_syn.sdf | write_sdf -version 2.1 | Delay of every cell and net, back-annotated by $sdf_annotate during gate-level sim.每顆元件與每條連線的延遲，閘級模擬時由 $sdf_annotate 反標註。すべてのセルとネットの遅延。ゲートレベル実行時に $sdf_annotate がバックアノテートする。 |
| REFRACT_syn.ddc | write -format ddc -hierarchy | DC's own database — netlist + constraints + timing. This is what you upload.DC 自己的資料庫——網表 + 約束 + 時序。這就是你要上傳的東西。DC 自身のデータベース——ネットリスト + 制約 + タイミング。提出するのはこれである。 |
Name rules rewrite the netlist's identifiers. Write first and you ship a netlist with names the simulator or a downstream LVS tool may reject — case-only collisions such as data vs DATA are the classic one. The order in the corrected script is correct: compile → change_names → write.命名規則會改寫網表裡的識別字。先 write 的話，你交出去的網表帶著模擬器或後段 LVS 工具可能拒收的名字——只差在大小寫的衝突，例如 data 與 DATA，就是經典案例。修正後腳本裡的順序是對的：compile → change_names → write。ネームルールはネットリストの識別子を書き換える。先に write してしまうと、シミュレータや後段の LVS ツールが受け付けないかもしれない名前のままのネットリストを出すことになる——data と DATA のように大文字小文字だけが違う衝突が典型例だ。修正後のスクリプトの順序は正しい：compile → change_names → write。
If -output has no path, files land in the current directory; a relative or absolute path sends them elsewhere. Keep the netlist and SDF in the same directory as tb.v, because the testbench hard-codes `define SDFFILE "./REFRACT_syn.sdf".如果 -output 沒有帶路徑，檔案會落在當前目錄；給相對或絕對路徑則會送到別處。把網表與 SDF 放在跟 tb.v 同一個目錄，因為 testbench 寫死了 `define SDFFILE "./REFRACT_syn.sdf"。-output にパスがなければファイルはカレントディレクトリに落ちる。相対パスや絶対パスを付ければ別の場所に送られる。テストベンチが `define SDFFILE "./REFRACT_syn.sdf" をハードコードしているので、ネットリストと SDF は tb.v と同じディレクトリに置くこと。
This is the step that decides whether your synthesis was real. Same testbench, same golden files — but now the DUT is the netlist, and every gate carries its true delay.這一步決定你的合成是不是真的。同一個 testbench、同一批 golden 檔——但這次待測物是網表，而且每一顆閘都帶著它真實的延遲。合成が本物だったかどうかを決める手順である。テストベンチも golden ファイルも同じ——ただし今回の被試験対象はネットリストで、どのゲートも実際の遅延を持っている。
xrun tb.v REFRACT.v +define+RI=5 +access+r -clean -createdebugdb \
-input xrun.tcl \
+incdir+/cad/synopsys/synthesis/cur/dw/sim_ver/ +libext+.v
xrun tb.v REFRACT_syn.v +define+SDF+RI=5 +access+r -clean -createdebugdb \
-input xrun.tcl \
-v /cad/CBDK/Executable_Package/Collaterals/IP/stdcell/N16ADFP_StdCell/VERILOG/N16ADFP_StdCell.v
xrun.cmd already contains both commands for every RI from 2 to 15, commented out — uncomment the line you want rather than retyping. ncverilog accepts the same arguments; the ModelSim equivalent is in vsim.cmd, the VCS one in vcs.cmd.xrun.cmd 裡已經為每個 2 到 15 的 RI 準備好兩種指令，被註解起來——把你要的那一行解開註解，不要重打。ncverilog 吃同樣的參數；ModelSim 的對應版本在 vsim.cmd，VCS 的在 vcs.cmd。xrun.cmd には 2 から 15 までのすべての RI について両方のコマンドがコメントアウトされた形で入っている——打ち直さず、使いたい行のコメントを外すこと。ncverilog は同じ引数を受け付ける。ModelSim 用は vsim.cmd、VCS 用は vcs.cmd にある。
| Argument參數引数 | Why it is there它為什麼在那裡なぜ必要か |
|---|---|
| +define+SDF | Enables initial $sdf_annotate(`SDFFILE, u_REFRACT); in the testbench. Without it you are running a zero-delay gate sim — it will pass, and it will have proved nothing.啟用 testbench 裡的 initial $sdf_annotate(`SDFFILE, u_REFRACT);。少了它，你跑的是零延遲的閘級模擬——它會過，但什麼都沒證明到。テストベンチの initial $sdf_annotate(`SDFFILE, u_REFRACT); を有効にする。これがなければ走るのは遅延ゼロのゲートシミュレーションである——通るだろうが、何も証明していない。 |
| +define+RI=5 | Selects which golden/golden_5.memh the testbench compares against. Sweep 2…15 before handing in.選擇 testbench 要比對哪一份 golden/golden_5.memh。繳交前把 2…15 都掃過。テストベンチがどの golden/golden_5.memh と比較するかを選ぶ。提出前に 2…15 をすべて回すこと。 |
| -v .../N16ADFP_StdCell.v | The library of cell behavioural models. The netlist is nothing but instances of these; omit it and every cell is an unresolved module.元件行為模型的函式庫。網表裡除了這些元件的實例什麼都沒有；少了它，每顆元件都會是未解析的模組。セルの動作モデルのライブラリ。ネットリストはこれらのインスタンスの集まりでしかなく、指定を落とすとすべてのセルが未解決モジュールになる。 |
| +incdir+.../dw/sim_ver/ +libext+.v | DesignWare simulation models — needed on the RTL side if you inferred DW components. Not needed at gate level, where DW has already been mapped to gates.DesignWare 的模擬模型——如果你推導出 DW 元件，RTL 那一側需要它。閘級不需要，因為 DW 已經被對映成閘了。DesignWare のシミュレーションモデル——DW コンポーネントを推論したなら RTL 側で必要になる。ゲートレベルでは DW はすでにゲートへマップされているので不要である。 |
| -input xrun.tcl | Runs ida_probe (waveform capture, all depths, including memories), then run, then exit.執行 ida_probe（波形擷取，全深度，含記憶體），接著 run，再 exit。ida_probe（波形取得、メモリを含む全階層）を実行し、続いて run、最後に exit する。 |
Loading golden file: golden/golden_5.memh
--------------------------------
-- Simulation Start , RI = 5 --
--------------------------------
1234.00ns, Recive DONE
--------------------------------------------------
-- Simulation Finished , RI = 5
-- PASS: all 256 points match
-- Execution Time: 1234.00ns <- this is your Latency
--------------------------------------------------
The testbench reads back 256 (x, y) pairs from the SRAM model and accepts each within a tolerance radius of 16/4096 units. Anything outside that, or any x in the data, counts as a mismatch; at most 8 are printed.Testbench 會從 SRAM 模型讀回 256 組 (x, y)，每一組都容許 16/4096 單位的誤差半徑。超出這個範圍的，或資料中出現任何 x，都算不符；最多印出 8 筆。テストベンチは SRAM モデルから 256 組の (x, y) を読み戻し、それぞれ 16/4096 単位の許容半径内であれば受け入れる。その外に出たもの、あるいはデータ中の x は不一致と数え、表示されるのは最大 8 件である。
EP1 item 3 requires the gate-level result to contain no timing violations. These appear as simulator messages from the cell models' $setuphold / $width timing checks, not as a testbench failure — a design can print PASS while having violated setup on a flip-flop. Grep the gate-level log explicitly:EP1 第 3 點要求閘級結果沒有任何時序違規。這些違規是元件模型的 $setuphold / $width 時序檢查所發出的模擬器訊息，不是 testbench 的失敗——一個設計可以一邊印 PASS、一邊在某顆正反器上違反 setup。請明確地 grep 閘級 log：EP1 の第 3 項はゲートレベルの結果にタイミング違反がないことを要求する。これはセルモデルの $setuphold / $width タイミングチェックが出すシミュレータのメッセージとして現れ、テストベンチの失敗としては現れない——あるフリップフロップで setup を破りながら PASS と表示する設計はありうる。ゲートレベルのログを明示的に grep すること：
xrun ... 2>&1 | tee gate_RI5.log grep -niE "timing violation|setuphold|\$setup|\$hold|\$width|\$recovery" gate_RI5.log
Empty output is what you want. If violations appear, the honest fixes are to raise the period in both files, or to let DC work harder (compile -map_effort high, then an incremental pass) so the critical path shrinks.沒有輸出才是你要的。如果真的出現違規，誠實的修法是把兩個檔案裡的週期都調大，或是讓 DC 更用力（compile -map_effort high，再加一次 incremental）把關鍵路徑縮短。出力が空であることが望ましい。違反が出たなら、誠実な直し方は両方のファイルの周期を大きくするか、DC により働かせて（compile -map_effort high のあとインクリメンタルパス）クリティカルパスを縮めることである。
At gate level flip-flops start at x — RTL often hides this. If DONE never asserts and the run dies at MAX_CYCLE (100 000), the usual cause is a register your RTL never resets feeding a control path. Reset every state-holding signal the control logic depends on. The testbench holds RST high for two cycles, drops it 1 ns after a posedge, then waits two more cycles — design to that.在閘級，正反器的初值是 x——RTL 常常把這件事蓋掉。如果 DONE 從未拉起、執行在 MAX_CYCLE（100 000）就死掉，通常是因為某個你的 RTL 從不重置的暫存器餵進了控制路徑。把控制邏輯依賴的每個狀態訊號都重置。Testbench 把 RST 拉高兩個週期，在某次正緣後 1 ns 放掉，再等兩個週期——照這個時序去設計。ゲートレベルではフリップフロップは x から始まる——RTL はこれをしばしば覆い隠す。DONE が立たず MAX_CYCLE（100 000）で実行が終わってしまう場合、よくある原因は RTL がリセットしていないレジスタが制御パスへ入っていることだ。制御論理が依存する状態保持信号はすべてリセットすること。テストベンチは RST を 2 サイクル高く保ち、立ち上がりの 1 ns 後に落とし、さらに 2 サイクル待つ——それに合わせて設計する。
verisium -lwd xcelium.d -db ida.db # per verisium.cmd nWave -ssf *.fsdb & # if you dump FSDB instead
The productive comparison is RTL and gate-level waveforms side by side: identical values, but the gate version arriving late within each cycle. The point where they diverge is the point your netlist stopped matching your intent.最有收穫的比較是把 RTL 與閘級波形並排看：數值相同，但閘級版本在每個週期內來得比較晚。它們開始分歧的那一點，就是你的網表不再符合你意圖的那一點。実りのある比較は RTL とゲートレベルの波形を並べて見ることだ。値は同じだが、ゲート版は各サイクルの中で遅れて到着する。両者が分かれる点が、ネットリストが意図と合わなくなった点である。
| Excel columnExcel 欄位Excel の列 | Where it comes from它從哪裡來どこから得るか |
|---|---|
| Area (um^2) | area.log → Total cell areaarea.log → Total cell areaarea.log → Total cell area |
| Period (ns) | set cycle in REFRACT.sdc — and it must equal `define CYCLE in tb.vREFRACT.sdc 裡的 set cycle——而且必須等於 tb.v 裡的 `define CYCLEREFRACT.sdc の set cycle——そして tb.v の `define CYCLE と等しくなければならない |
| Power (mW) | power.log → total power, converted to mWpower.log → 總功耗，換算成 mWpower.log → 総電力を mW に換算したもの |
| Latency (ns) | Execution Time printed at $finish in the gate-level run — the total execution time, i.e. Period × cycles閘級執行在 $finish 時印出的 Execution Time——總執行時間，也就是 Period × 週期數ゲートレベル実行の $finish で表示される Execution Time——総実行時間、すなわち Period × サイクル数 |
| RTL Pass/Fail | Y if the RTL run prints PASSRTL 執行印出 PASS 就填 YRTL 実行が PASS を表示すれば Y |
| Gate level Pass/Fail | Y only if PASS and the violation grep came back empty只有在 PASS 而且違規 grep 查不到東西時才填 YPASS かつ違反 grep が空だったときだけ Y |
| RI | Which golden set you ran. Report your best version; verify across the full 2–15 range.你跑的是哪一組 golden。回報你最好的版本；但要在完整的 2–15 範圍上都驗過。どの golden セットで走らせたか。最良のバージョンを報告し、2–15 の全範囲で検証しておくこと。 |
| Command指令コマンド | Behaviour行為振る舞い | When何時用使いどころ |
|---|---|---|
| compile -exact_map | Conservative. Registers are mapped exactly as inferred; little restructuring.保守。暫存器完全照推導結果對映，幾乎不重構。保守的。レジスタは推論されたとおりに正確にマップされ、再構成はほとんどしない。 | The given default. Start here — the netlist stays closest to your RTL, so a gate-level failure points at your design, not the tool.題目給的預設值。從這裡開始——網表最接近你的 RTL，所以閘級失敗時矛頭指向你的設計，而不是工具。配られた既定値。ここから始める——ネットリストが RTL に最も近いので、ゲートレベルで落ちたときに原因がツールではなく自分の設計だと分かる。 |
| compile -map_effort high -area_effort high | Full optimisation inside the existing hierarchy. Longer CPU time.在既有階層內做完整最佳化。CPU 時間較長。既存の階層の中で完全な最適化を行う。CPU 時間は長くなる。 | The normal production setting once the flow works.流程跑通之後的正常生產設定。フローが通ったあとの、通常の実運用設定。 |
| compile ... -inc | Incremental: gate-level touch-up only, no logic restructuring. Requires a prior full compile.Incremental：只做閘級修補，不重構邏輯。需要先有一次完整 compile。インクリメンタル：ゲートレベルの手直しのみで、論理の再構成はしない。先に完全な compile が済んでいる必要がある。 | Closing a small residual negative slack.用來收掉一點點殘餘的負 slack。わずかに残った負スラックを詰めるとき。 |
| compile_ultra -no_autoungroup | Much stronger optimisation; the SOP quotes roughly 40 % area and 20 % delay improvement. -no_autoungroup keeps your module hierarchy intact.強上許多的最佳化；SOP 引述約可改善 40 % 面積與 20 % 延遲。-no_autoungroup 會保住你的模組階層。はるかに強い最適化。SOP は面積が約 40 %、遅延が約 20 % 改善すると引用している。-no_autoungroup を付けるとモジュール階層が保たれる。 | Only once you have a safe working version banked. The SOP warns it is 破壞性 — destructive enough that gate-level simulation may stop passing.只有在你已經存好一個安全可用的版本之後才用。SOP 警告它是破壞性的——破壞到閘級模擬可能就此不過。安全に動くバージョンを確保したあとでのみ使う。SOP はこれを破壞性——ゲートレベルシミュレーションが通らなくなりうるほど破壊的——だと警告している。 |
Script the sweep rather than editing by hand. Replace the SDC's hard-coded value with if {![info exists cycle]} {set cycle 5.0} and you can drive the period from the command line: dc_shell -f dc_syn.tcl -x "set cycle 4.5".把掃描寫成腳本，不要手動改。把 SDC 裡寫死的值換成 if {![info exists cycle]} {set cycle 5.0}，你就能從命令列驅動週期：dc_shell -f dc_syn.tcl -x "set cycle 4.5"。スイープは手で編集せずスクリプト化すること。SDC のベタ書きの値を if {![info exists cycle]} {set cycle 5.0} に置き換えれば、コマンドラインから周期を与えられる：dc_shell -f dc_syn.tcl -x "set cycle 4.5"。
DC can only rearrange the logic you wrote. If the critical path is a long arithmetic chain evaluated in one cycle, no compile effort will save it — pipelining it across two cycles will. Conversely, if Latency dominates your score, the win is algorithmic: fewer SRAM accesses, or overlapping the read of point n+1 with the computation of point n. Read the path listing in timing_max.log before deciding which of the two you are fighting.DC 只能重排你寫出來的邏輯。如果關鍵路徑是一條在單一週期內算完的長算術鏈，再高的 compile 努力也救不了——把它切成兩個週期的管線才行。反過來說，如果主導你分數的是 Latency，勝負就在演算法：減少 SRAM 存取，或讓第 n+1 點的讀取與第 n 點的運算重疊。在決定自己要對付哪一邊之前，先讀 timing_max.log 裡的路徑列表。DC は書かれた論理を並べ替えることしかできない。クリティカルパスが 1 サイクルで評価される長い算術の連鎖なら、compile の努力をいくら上げても救えない——2 サイクルに分けてパイプライン化すれば救える。逆に得点を支配しているのが Latency なら、勝負はアルゴリズムにある：SRAM アクセスを減らすか、点 n+1 の読み出しを点 n の計算と重ねることだ。どちらと戦っているのかを決める前に、timing_max.log のパスの一覧を読むこと。
| Symptom症狀症状 | Cause原因原因 | Fix修法対処 |
|---|---|---|
| Can't find library 'slow' | tsmc13 lines still in dc_syn.tcldc_syn.tcl 裡還留著 tsmc13 那兩行dc_syn.tcl に tsmc13 の行が残っている | Comment out both — see §4.兩行都註解掉——見 §4。どちらもコメントアウトする——§4 を参照。 |
| Can't find library 'N16ADFP_StdCellff0p88v125c_ccs' | That corner is not in target_library / link_library, or snsd → ADFP_n16 was not sourced那個 corner 不在 target_library / link_library 裡，或是沒有 source snsd → ADFP_n16そのコーナーが target_library / link_library にない。または snsd → ADFP_n16 を source していない | Re-run snsd; add the .db to the setup file; confirm the CCS directory path exists.重跑 snsd；把 .db 加進設定檔；確認 CCS 目錄路徑存在。snsd を実行し直す。.db を設定ファイルに追加する。CCS ディレクトリのパスが存在することを確認する。 |
| unresolved reference to 'DW02_mult' | DesignWare inferred but dw_foundation.sldb missing推導出了 DesignWare，但缺少 dw_foundation.sldbDesignWare が推論されたが dw_foundation.sldb がない | Add it to link_library.把它加進 link_library。link_library に追加する。 |
| ... is being inferred as a latch | Incomplete if / case in a combinational block組合區塊裡不完整的 if / case組合せブロックの中の不完全な if / case | Add the else / default, or assign a default at the top of the block. Fix it in RTL — do not synthesize around it.補上 else / default，或在區塊開頭先指派預設值。在 RTL 裡修——不要繞過它硬合成。else / default を足すか、ブロックの先頭で既定値を代入する。RTL で直すこと——合成でごまかさない。 |
| Timing met in DC, violations in gate-level simDC 裡時序有收斂，閘級模擬卻有違規DC ではタイミングが収束しているのにゲートレベルで違反が出る | Period in tb.v smaller than the SDC's; or SDF not annotated; or hold not fixedtb.v 裡的週期比 SDC 的小；或 SDF 沒有被反標註；或 hold 沒修好tb.v の周期が SDC より小さい。または SDF がアノテートされていない。または hold が直っていない | Align `CYCLE with $cycle; confirm +define+SDF; check timing_min.log.讓 `CYCLE 與 $cycle 對齊；確認 +define+SDF；檢查 timing_min.log。`CYCLE を $cycle に合わせる。+define+SDF を確認する。timing_min.log を見る。 |
| Gate-level sim runs but every output is x閘級模擬跑得動，但每個輸出都是 xゲートレベルシミュレーションは走るが出力がすべて x | $sdf_annotate failed, or the cell library was not loaded$sdf_annotate 失敗，或元件庫沒載入$sdf_annotate が失敗した、またはセルライブラリが読み込まれていない | Look for the annotation message in the log; verify -v .../N16ADFP_StdCell.v and that ./REFRACT_syn.sdf sits next to tb.v.在 log 裡找反標註的訊息；確認 -v .../N16ADFP_StdCell.v，以及 ./REFRACT_syn.sdf 就放在 tb.v 旁邊。ログでアノテーションのメッセージを探す。-v .../N16ADFP_StdCell.v と、./REFRACT_syn.sdf が tb.v の隣にあることを確認する。 |
| MAX_CYCLE 100000 reached | DONE never asserts — usually an unreset register at gate level, or a genuine hangDONE 從未拉起——通常是閘級下某個未重置的暫存器，或真的卡住了DONE が立たない——ゲートレベルで未リセットのレジスタがあるか、本当にハングしている | Reset all control state. If the design is legitimately long, raise `MAX_CYCLE in tb.v — but confirm it is not a hang first.重置所有控制狀態。如果設計本來就跑很久，就把 tb.v 裡的 `MAX_CYCLE 調大——但先確認它不是卡住。制御状態をすべてリセットする。設計が本来長いのなら tb.v の `MAX_CYCLE を大きくする——ただし先にハングでないことを確認すること。 |
| Netlist has odd names, simulator parse errors網表名稱很奇怪，模擬器解析錯誤ネットリストの名前がおかしく、シミュレータがパースエラーを出す | change_names skipped, or run after writechange_names 被略過，或跑在 write 之後change_names を飛ばした、または write のあとに実行した | Run define_name_rules + change_names before every write.每次 write 之前都先跑 define_name_rules + change_names。write の前に毎回 define_name_rules + change_names を実行する。 |
| Area far larger than expected面積遠大於預期面積が予想よりはるかに大きい | Period over-constrained — DC used huge parallel structures and high-drive cells chasing an impossible target週期約束過緊——DC 為了追一個不可能的目標，用上了龐大的並行結構與高驅動力元件周期の制約がきつすぎる——DC が不可能な目標を追って巨大な並列構造と高駆動セルを使った | Relax $cycle and re-measure; the area/period curve is steeply non-linear near the limit.放寬 $cycle 再量一次；面積／週期曲線在極限附近是陡峭的非線性。$cycle を緩めて測り直す。面積／周期の曲線は限界付近で急激に非線形になる。 |
| report_area -hierarchy shows no sub-modulesreport_area -hierarchy 顯示不出子模組report_area -hierarchy にサブモジュールが出ない | compile_ultra ran without -no_autoungroupcompile_ultra 跑的時候沒加 -no_autoungroupcompile_ultra を -no_autoungroup なしで実行した | Add the flag if you need the breakdown.如果你需要那份拆解，就把這個旗標加上。内訳が必要ならこのオプションを付ける。 |
| Second synthesis in one shell links the old design同一個 shell 裡的第二次合成 link 到了舊設計同じシェルでの 2 回目の合成が古い設計に link する | Previous design still in memory前一個設計還留在記憶體裡前の設計がメモリに残っている | remove_design -designs before re-sourcing.重新 source 之前先下 remove_design -designs。source し直す前に remove_design -designs を実行する。 |
help *clock* # commands matching a keyword printvar *library* # current value of matching variables man set_clock_latency # full documentation for a command or variable
snsd # DC + ADFP_n16 vi dc_syn.tcl # comment tsmc13 lines dc_shell -f dc_syn.tcl | tee syn.log grep -n "^Error" syn.log grep slack timing_max.log xrun tb.v REFRACT_syn.v \ +define+SDF+RI=5 +access+r -clean \ -createdebugdb -input xrun.tcl \ -v $ADFP/VERILOG/N16ADFP_StdCell.v \ 2>&1 | tee gate_RI5.log grep -ni "violation" gate_RI5.log
REFRACT_syn.v netlist -> gate sim REFRACT_syn.sdf delays -> gate sim REFRACT_syn.ddc database -> UPLOAD area.log Area (um^2) power.log Power (mW) timing_max.log setup slack timing_min.log hold slack REFRACT_syn.qor one-page summary violation.log any DRC/timing breach
| Command指令コマンド | Does作用作用 |
|---|---|
| analyze -format verilog f.v | Parse RTL解析 RTLRTL をパースする |
| elaborate TOP | Build the design, infer registers建出設計，推導暫存器設計を構築し、レジスタを推論する |
| link | Resolve all references against the libraries對著函式庫解析所有參照すべての参照をライブラリに対して解決する |
| current_design TOP | Set the working design — module name only, no file extension設定工作中的設計——只填模組名，不加副檔名作業対象の設計を設定する——モジュール名のみ、拡張子は付けない |
| check_design / check_timing | Structural issues / unconstrained paths結構問題 / 未受約束的路徑構造上の問題 / 制約のないパス |
| uniquify | Give each instance of a shared module its own copy讓共用模組的每個實例各有一份副本共有モジュールの各インスタンスに専用のコピーを与える |
| compile -exact_map | Conservative mapping保守對映保守的なマッピング |
| compile_ultra -no_autoungroup | Aggressive, hierarchy preserved激進，但保留階層積極的だが階層は保持 |
| report_timing -delay max|min | Setup | hold worst pathSetup | hold 的最差路徑setup | hold の最悪パス |
| report_area -hierarchy | Area per module各模組的面積モジュールごとの面積 |
| report_power | Dynamic + leakage動態 + 漏電動的 + リーク |
| report_constraint -all_violators | Everything currently violated目前所有違規項目現在違反しているものすべて |
| report_net_fanout -high_fanout | Find high-fanout nets (clock-gating check)找出高扇出連線（clock-gating 檢查）ファンアウトの大きいネットを探す（クロックゲーティングの確認） |
| remove_design -designs | Clear memory before re-synthesizing重新合成前清空記憶體再合成の前にメモリを空にする |
| write -format ddc -hierarchy -output X.ddc | Save the DC database存下 DC 資料庫DC データベースを保存する |
Marked so you can go back to the original when something on your machine differs.都標註出來，這樣當你機器上的情況不同時，可以回頭查原始文件。自分のマシンで様子が違ったときに原典へ戻れるよう、出典を示してある。
| Source來源出典 | What it supplied它提供了什麼そこから得たもの |
|---|---|
| local本機ローカル project/DC SOP with Synopsys Design Compiler V2.pdf | The whole 8-step flow: licence, GUI, analyze/elaborate, constraints, compile strategies, reports, name rules, save, gate-level sim; the clock-gating supplement; help / printvar / man.完整的 8 步流程：授權、GUI、analyze/elaborate、約束、compile 策略、報告、命名規則、存檔、閘級模擬；clock-gating 補充；以及 help / printvar / man。8 手順のフロー全体：ライセンス、GUI、analyze/elaborate、制約、compile の戦略、レポート、ネームルール、保存、ゲートレベルシミュレーション。クロックゲーティングの補足。help / printvar / man。 |
| local本機ローカル project/ep-1/1.pdf (= DC SOP with ADFP) | The one change for ADFP: comment out the tsmc13 set_operating_conditions / set_wire_load_model, substitute the N16ADFP pair; source both the DC and ADFP licences.針對 ADFP 的那一項改動：把 tsmc13 的 set_operating_conditions / set_wire_load_model 註解掉，換成 N16ADFP 的那一組；並且 DC 與 ADFP 兩份授權都要 source。ADFP 向けの唯一の変更点：tsmc13 の set_operating_conditions / set_wire_load_model をコメントアウトし、N16ADFP の組に置き換えること。DC と ADFP の両方のライセンスを source すること。 |
| local本機ローカル project/ep-1/xyshih_snsd.md | EP1 rules: ADFP_n16 mandatory, the exact xrun commands, no timing violations, the four Excel figures, the upload list and folder naming.EP1 規則：ADFP_n16 為必要、確切的 xrun 指令、不得有時序違規、Excel 的四個數據、上傳清單與資料夾命名。EP1 の規則：ADFP_n16 必須、正確な xrun コマンド、タイミング違反なし、Excel の 4 つの数値、提出一覧とフォルダ命名。 |
| local本機ローカル 2026_grad_cell/{dc_syn.tcl, REFRACT.sdc, tb.v, xrun.cmd, xrun.tcl} | Every concrete path, option and value quoted above; the CYCLE/period mismatch; the behavioural SRAM; the tolerance and pass criteria.上面引用的每一條具體路徑、選項與數值；CYCLE/週期不一致；行為級 SRAM；容差與通過判準。上で引用した具体的なパス、オプション、数値のすべて。CYCLE と周期の不一致。動作レベル SRAM。許容誤差と合格判定。 |
| network網路ネットワーク ADFP Cloud 2.0 — Cell-based 設計使用者手冊 v1 | N16ADFP collateral layout (CCS / NLDM / VERILOG), the target_library slow-case naming, and the dcnxt_shell -f ... -output_log_file invocation.N16ADFP 資料的目錄配置（CCS / NLDM / VERILOG）、target_library 的 slow-case 命名，以及 dcnxt_shell -f ... -output_log_file 的呼叫方式。N16ADFP 資材のディレクトリ構成（CCS / NLDM / VERILOG）、target_library の slow case の命名、そして dcnxt_shell -f ... -output_log_file の呼び出し方。 |
| judgement判斷判断 | The ff-vs-ss corner observation (§3), the added report_power / check_timing / report_constraint lines, the explicit violation grep, and the tuning order in §12 are reasoning from the above, not quotations. Check them against your instructor's grading sheet before relying on them.ff 與 ss corner 的觀察（§3）、額外加上的 report_power / check_timing / report_constraint 這幾行、明確的違規 grep，以及 §12 的調校順序，都是從上述資料推論而來，並非原文引用。在據以行事之前，請對照你授課教師的評分表確認。ff と ss のコーナーに関する指摘（§3）、追加した report_power / check_timing / report_constraint の行、明示的な違反 grep、そして §12 のチューニング順序は、以上からの推論であって引用ではない。頼る前に担当教員の採点表と突き合わせて確認すること。 |