Syntax of the Verilog Model, ExplainedVerilog 模型的語法，完整解說Verilog モデルの構文、詳説

1. Primitives, UDPs and Where They Fit1. 原型、UDP，以及它們的定位1. プリミティブ、UDP、そしてその位置づけ

Lecture 3 looks like three unrelated topics stapled together: truth tables, delay numbers, and a list of backtick directives. They are not unrelated. They are the three things you need in order to write a simulation model of a piece of silicon that somebody else fabricated. A standard-cell library vendor hands you a .v file for every cell in the library. Open one. You will find a primitive with a truth table, a specify block full of numbers, and a wrapper of compiler directives. That file is the entire content of this lecture, written by a foundry instead of by you. Understanding it is the difference between running a post-layout simulation and believing it.第 3 講看起來像是三個不相干的題目被硬釘在一起：真值表、延遲數字，還有一串反引號開頭的指令。它們並非不相干。這三樣東西正是你要寫出別人代工做出來的那塊矽的模擬模型時所需要的全部。標準單元庫的供應商會為庫中每一顆單元交給你一個 .v 檔。隨便打開一個來看，你會看到一個帶真值表的 primitive、一個塞滿數字的 specify 區塊，再加上一層編譯指令包裝。那個檔案的內容就是本講的全部，只是由晶圓廠寫的，而不是你寫的。看懂它，是「跑過佈局後模擬」和「相信佈局後模擬」之間的差別。第 3 講は、互いに無関係な三つの話題をホチキスで留めただけのように見える。真理値表、遅延の数値、そしてバッククォートで始まる指令の一覧である。しかしこれらは無関係ではない。誰か他人が製造したシリコンのシミュレーションモデルを書くために必要な三つが、ちょうどこれらなのである。標準セルライブラリのベンダは、ライブラリ内のすべてのセルについて .v ファイルを渡してくる。一つ開いてみればよい。真理値表を持つ primitive、数値で埋まった specify ブロック、そしてコンパイラ指令による包みが見つかるはずだ。そのファイルの中身こそが本講のすべてであり、ただ書いたのが自分ではなくファウンドリだというだけである。それを理解しているかどうかが、レイアウト後シミュレーションを「走らせた」と「信じられる」の差になる。

1.1 What a primitive is, and why it is special1.1 原型是什麼，又為什麼特別1.1 プリミティブとは何か、なぜ特別なのか

A primitive in Verilog is a built-in logic model: and, or, nand, nor, buf, not, xor, xnor, plus the three-state family bufif0, bufif1, notif0, notif1, the MOS switches nmos, pmos, cmos and their resistive variants, and the supply/pull sources. They are not modules. You never write module and; the simulator already knows what an AND gate does, down to the four-value truth table that tells it 0 & x is 0 and 1 & x is x.Verilog 中的原型（primitive）是語言內建的邏輯模型：and、or、nand、nor、buf、not、xor、xnor，再加上三態家族 bufif0、bufif1、notif0、notif1，MOS 開關 nmos、pmos、cmos 及其電阻性變體，以及 supply／pull 這類電源。它們不是模組。你永遠不會寫 module and；模擬器本來就知道 AND 閘做什麼，連「0 & x 是 0、1 & x 是 x」這種四值真值表的細節都知道。Verilog のプリミティブとは、言語に組み込まれた論理モデルである。and、or、nand、nor、buf、not、xor、xnor に加え、三状態系の bufif0、bufif1、notif0、notif1、MOS スイッチ nmos、pmos、cmos とその抵抗性の変種、そして supply／pull の電源がある。これらはモジュールではない。module and と書くことは決してない。シミュレータは AND ゲートの振る舞いを、0 & x が 0、1 & x が x という四値真理値表のレベルまで、はじめから知っている。

Three structural facts about primitives govern everything that follows. First, a primitive has exactly one output, and it is always the first port. Second, it may have any number of inputs: and (d, a, b, c) is a three-input AND whose output is d. Third, a primitive instance is not a module instance — it has no named port connections, no parameters, and its instance name is optional. Writing and (z1, x1, y1); with no name at all is perfectly legal, which is why gate-level netlists produced by synthesis tools are a wall of unnamed primitives.關於原型，有三項結構性的事實支配了接下來的一切。第一，原型恰好只有一個輸出，而且一定是第一個埠。第二，輸入的個數不限：and (d, a, b, c) 是一個輸出為 d 的三輸入 AND。第三，原型實體不是模組實體 — 它沒有具名埠連接、沒有參數，實體名稱也可以省略。寫成 and (z1, x1, y1); 完全不給名字是完全合法的，這也是為什麼合成工具產出的閘層級網表是一整片沒有名字的原型。プリミティブについては、以後のすべてを左右する三つの構造的事実がある。第一に、プリミティブは出力をちょうど一つだけ持ち、それは常に先頭のポートである。第二に、入力はいくつあってもよい。and (d, a, b, c) は出力が d の三入力 AND である。第三に、プリミティブのインスタンスはモジュールのインスタンスではない。名前付きポート接続もパラメータもなく、インスタンス名は省略できる。and (z1, x1, y1); と名前なしで書いても完全に合法であり、だからこそ合成ツールが出力するゲートレベルネットリストは、名前のないプリミティブの壁になる。

Why does the one-output-first rule matter so much? Because the table in a user-defined primitive has no column headings. The simulator aligns table columns to ports positionally, and it knows the last column is the output precisely because the output is pinned to port position zero. If the language allowed outputs anywhere in the port list, a truth table would be unreadable without a schema.為什麼「輸出必須排第一」這條規則如此關鍵？因為使用者自訂原型裡的表格沒有欄位標題。模擬器是依位置把表格的欄對齊到埠的，而它之所以知道最後一欄是輸出，正是因為輸出被釘死在埠位置零。如果語言允許輸出出現在埠列表的任何位置，真值表少了綱要就無法閱讀。なぜ「出力が先頭」という規則がこれほど重要なのか。ユーザ定義プリミティブのテーブルには列見出しがないからである。シミュレータはテーブルの列を位置によってポートに対応づけており、最後の列が出力だと分かるのは、出力がポート位置ゼロに固定されているからにほかならない。もし出力をポートリストのどこにでも置けるなら、真理値表はスキーマなしには読めなくなる。

1.2 Why user-defined primitives were invented1.2 為什麼會有使用者自訂原型1.2 なぜユーザ定義プリミティブが生まれたか

The built-in set is small and strictly combinational. It contains no latch, no flip-flop, no multiplexer, no AOI (and-or-invert) cell. Yet those are exactly the cells a real library contains, and a library model has to be fast: a gate-level netlist of a million instances is simulated event by event, and every instance evaluation costs time. A behavioural always block that recomputes an expression is an order of magnitude more expensive than a table lookup.內建的那一組數量很少，而且嚴格說來都是組合邏輯。裡面沒有閂鎖器、沒有正反器、沒有多工器，也沒有 AOI（and-or-invert）單元。然而真實單元庫裡有的正是這些單元，而且單元庫的模型必須快：一個百萬實體的閘層級網表是逐事件模擬的，每一次實體求值都要花時間。一個會重算表示式的行為式 always 區塊，成本比查表高一個數量級。組み込みの一式は数が少なく、しかも厳密に組み合わせ回路だけである。ラッチもフリップフロップもマルチプレクサも、AOI（and-or-invert）セルもない。ところが実際のライブラリが持つのはまさにそうしたセルであり、しかもライブラリのモデルは速くなければならない。百万インスタンスのゲートレベルネットリストはイベントごとにシミュレートされ、インスタンスの評価一回ごとに時間がかかる。式を再計算する動作記述の always ブロックは、テーブル引きより一桁高価である。

So the language offers primitive ... endprimitive: you write a truth table, and the simulator compiles it into a lookup structure that evaluates in roughly the cost of an array index. The slides give the motivation in one line — "predefined primitives are limited" — and that is true, but the performance argument is the reason UDPs survived into the era when everybody else moved to behavioural modelling.所以語言提供了 primitive ... endprimitive：你寫一張真值表，模擬器把它編譯成一個查表結構，求值的成本大約就是一次陣列索引。講義用一句話給出動機 —「預先定義的原型種類有限」— 這沒錯，但效能上的理由才是 UDP 能在大家都轉向行為式建模的年代存活下來的原因。そこで言語は primitive ... endprimitive を用意した。真理値表を書くと、シミュレータはそれを配列添字一回ぶん程度のコストで評価できるルックアップ構造にコンパイルする。講義スライドは動機を一行で述べている — 「定義済みプリミティブは限られている」— それは正しいが、他の誰もが動作記述へ移った時代に UDP が生き残った理由は、性能のほうである。

1.3 Rules shared by built-in and user-defined primitives1.3 內建原型與使用者自訂原型共通的規則1.3 組み込みプリミティブとユーザ定義プリミティブに共通の規則

The lecture lists these as a flat bullet list. They are worth separating into the ones that are syntactic and the ones that bite you at run time.講義把這些列成一串平鋪的項目。值得把它們分成「屬於語法的」和「會在執行期咬你一口的」兩類。講義ではこれらが平坦な箇条書きとして並んでいる。構文上の規則と、実行時に牙を剥く規則とに分けて見ておく価値がある。

and          (z1, x1, y1);   // built-in, unnamed
and    M1    (z2, x2, y2);   // built-in, named
my_udp       (c2, a2, b2);   // user-defined, unnamed
my_udp N1    (c1, a1, b1);   // user-defined, named
my_udp #3 N2 (c3, a3, b3);   // user-defined with a delay: delay comes before the name

Note the position of the delay in the last line. For a primitive instance the syntax is <keyword> <delay> <name> (ports). Students routinely write my_udp N2 #3 (...) and get a parse error whose message mentions neither delays nor names.注意最後一行裡延遲的位置。原型實體的語法是 <關鍵字> <延遲> <名稱> (埠)。學生常常寫成 my_udp N2 #3 (...)，然後得到一個訊息裡既沒提延遲也沒提名稱的語法錯誤。最後の行における遅延の位置に注意すること。プリミティブインスタンスの構文は <キーワード> <遅延> <名前> (ポート) である。学生はしばしば my_udp N2 #3 (...) と書き、遅延にも名前にも言及しないメッセージの構文エラーを受け取る。

1.4 Net output for combinational, reg output for sequential1.4 組合邏輯用 net 輸出，循序邏輯用 reg 輸出1.4 組み合わせは net 出力、順序は reg 出力

This is the rule most often quoted and least often explained. A combinational UDP declares its output as a net:這條規則最常被引用，也最少被解釋。組合邏輯 UDP 的輸出宣告為 net：この規則は最もよく引用され、最も説明されない。組み合わせ UDP は出力を net として宣言する。

primitive p_comb (y, a, b);
  output y;          // implicitly a net; no reg declaration
  input  a, b;
  ...
endprimitive

A sequential UDP adds reg y;. The reason is not stylistic. A sequential UDP has state, and in Verilog a value that persists between evaluations has to live in a variable, not in a net. The reg declaration is what creates that storage, and the storage is exactly what the state column of the table reads. If you write a table with n+2 columns but forget reg q;, the compiler reports a column-count mismatch, because without the reg there is no state column for the extra field to attach to.循序邏輯 UDP 要加上 reg y;。理由不是風格問題。循序邏輯 UDP 有狀態，而在 Verilog 裡，要在兩次求值之間留住的值必須存在變數中，不能存在 net 上。reg 宣告建立的就是那塊儲存，而那塊儲存正好就是表格狀態欄所讀的東西。如果你寫了 n+2 欄的表卻忘了 reg q;，編譯器會報欄數不符，因為沒有 reg 就沒有狀態欄可以讓多出來的那一欄掛上去。順序 UDP には reg y; が加わる。理由は様式の問題ではない。順序 UDP は状態を持ち、Verilog では評価と評価のあいだ保持される値は net ではなく変数に置かれなければならない。その記憶を作るのが reg 宣言であり、その記憶こそテーブルの状態列が読む対象である。n+2 列のテーブルを書きながら reg q; を忘れると、コンパイラは列数の不一致を報告する。reg がなければ、余分な列を結びつける状態列が存在しないからである。

Conversely, if you declare reg y; on a UDP whose table has only n+1 columns, some simulators accept it and treat the UDP as sequential with an invisible state. That is a portability landmine. Declare the reg if and only if the table has a state field.反過來說，如果你在一個表只有 n+1 欄的 UDP 上宣告了 reg y;，有些模擬器會照單全收，把這個 UDP 當成帶有看不見的狀態的循序邏輯。那是一顆可攜性地雷。唯有表中確實有狀態欄時，才宣告 reg。逆に、テーブルが n+1 列しかない UDP に reg y; を宣言すると、それを受け入れて見えない状態を持つ順序 UDP として扱うシミュレータもある。これは移植性の地雷である。reg を宣言するのは、テーブルに状態フィールドがあるとき、かつそのときに限る。

There are also size limits that the slides do not mention but which the standard imposes and real simulators enforce: a combinational UDP may have at most 10 inputs, and a sequential UDP at most 9 (the state column consumes one of the ten table fields the implementation reserves). A table for ten inputs has up to $3^{10} = 59049$ expanded rows, which is already a large compiled object; the limit is an engineering compromise, not a mathematical one. If you need a wider function, decompose it into two UDPs or write a module.還有一些講義沒提、但標準有規定且真實模擬器會強制的大小上限：組合邏輯 UDP 最多 10 個輸入，循序邏輯 UDP 最多 9 個（狀態欄用掉了實作保留的十個表格欄位之一）。十個輸入的表展開後最多有 $3^{10} = 59049$ 列，編譯出來已經是個很大的物件；這個上限是工程上的折衷，不是數學上的必然。如果你需要更寬的函數，就把它拆成兩個 UDP，或乾脆寫一個模組。講義には出てこないが、標準が課し実際のシミュレータも強制するサイズ上限もある。組み合わせ UDP は入力が最大 10 個、順序 UDP は最大 9 個である（状態列が、実装の予約する十個のテーブルフィールドのうち一つを消費する）。入力十個のテーブルは展開すると最大 $3^{10} = 59049$ 行になり、コンパイル結果はすでに巨大なオブジェクトである。この上限は数学的必然ではなく工学上の妥協である。より幅の広い関数が必要なら、二つの UDP に分解するかモジュールを書けばよい。

1.5 UDPs cannot be synthesised — and that is the point1.5 UDP 不能被合成 — 而這正是重點1.5 UDP は合成できない — そしてそれこそが要点である

No synthesis tool reads a UDP table and infers logic from it. Not synthesisable Ask a synthesiser to compile a design containing primitive and it will either error out or, worse, treat the instance as a black box with unknown function and optimise around it. This surprises students who reason, correctly, that a truth table is the most synthesisable thing imaginable.沒有任何合成工具會去讀 UDP 的表並從中推論出邏輯。不可合成 叫合成器去編譯一個含有 primitive 的設計，它要嘛直接報錯，要嘛更糟 — 把那個實體當成功能未知的黑盒子，然後繞著它最佳化。這會讓學生很意外，因為他們的推理其實沒錯：真值表聽起來是世界上最適合合成的東西。UDP のテーブルを読んで論理を推論する合成ツールは存在しない。合成不可 primitive を含む設計を合成器にかければ、エラーで止まるか、さらに悪いことに、そのインスタンスを機能不明のブラックボックスとして扱い、その周囲を最適化してしまう。真理値表こそ最も合成しやすいものではないかという、それ自体は正しい推論をする学生にとって、これは意外な事実である。

The resolution is that UDPs live on the other side of the flow. Synthesis goes from RTL to a netlist of library cells. The library cells themselves are not synthesised — they were designed transistor by transistor, characterised with SPICE, and shipped. The vendor needs two views of each cell: a timing view (the .lib / Liberty file, which the synthesiser and the static timing analyser read) and a simulation view (the Verilog .v model, which the event simulator reads). The UDP is the functional core of the simulation view.答案是：UDP 住在流程的另一側。合成是從 RTL 到單元庫單元網表。單元庫裡的單元本身並不是合成出來的 — 它們是一顆一顆電晶體畫出來、用 SPICE 特性化、然後出貨的。供應商必須為每顆單元提供兩種視圖：時序視圖（.lib／Liberty 檔，由合成器與靜態時序分析器讀取）與模擬視圖（Verilog .v 模型，由事件模擬器讀取）。UDP 就是模擬視圖的功能核心。答えは、UDP がフローの反対側に住んでいるということである。合成は RTL からライブラリセルのネットリストへ向かう。ライブラリセル自体は合成されたものではない。トランジスタ一つずつ設計され、SPICE で特性化され、出荷されたものである。ベンダは各セルについて二つのビューを用意する必要がある。タイミングビュー（.lib／Liberty ファイル。合成器と静的タイミング解析器が読む）とシミュレーションビュー（Verilog .v モデル。イベントシミュレータが読む）である。UDP はシミュレーションビューの機能的中核にあたる。

// Shape of a real standard-cell simulation model (abridged)
`celldefine
`timescale 1ns/10ps

primitive UDP_DFF (q, clk, d, notifier);
  output q;  input clk, d, notifier;  reg q;
  table
    r 0 ? : ? : 0;
    r 1 ? : ? : 1;
    f ? ? : ? : -;
    ? * ? : ? : -;
    ? ? * : ? : x;      // timing violation forces x
  endtable
endprimitive

module DFFHQX1 (Q, D, CK);
  output Q;  input D, CK;
  UDP_DFF u0 (Q, CK, D, notifier);
  specify
    (posedge CK => (Q : D)) = (0.142, 0.158);
    $setup (D, posedge CK, 0.071, notifier);
    $hold  (posedge CK, D, 0.034, notifier);
  endspecify
endmodule
`endcelldefine

Everything in that listing is Lecture 3 material: the UDP table, the edge-sensitive module path, the timing checks, the `celldefine wrapper and the `timescale. The notifier argument is the mechanism by which a setup or hold violation reaches the functional model — the timing check toggles notifier, the last table row sees a change on it, and the flip-flop output goes to x. That is how a post-layout simulation turns a timing failure into visible corruption instead of silently passing.那段程式碼裡的每一樣東西都是第 3 講的教材：UDP 表、邊緣敏感的模組路徑、時序檢查、`celldefine 包裝與 `timescale。notifier 引數則是 setup 或 hold 違規傳達到功能模型的機制 — 時序檢查把 notifier 翻轉，表格最後一列看到它變了，正反器的輸出就變成 x。佈局後模擬就是這樣把一次時序失效變成看得見的資料毀損，而不是默默地通過。そのリストに現れるものはすべて第 3 講の内容である。UDP テーブル、エッジ感応のモジュールパス、タイミングチェック、`celldefine の包み、そして `timescale。notifier 引数は、セットアップやホールドの違反が機能モデルに届く仕組みである。タイミングチェックが notifier をトグルし、テーブルの最終行がその変化を見て、フリップフロップの出力が x になる。レイアウト後シミュレーションがタイミング違反を、黙って通過させるのではなく目に見える破壊として示すのは、この経路による。

2. Inside the UDP Table: How a Row Is Matched2. UDP 表格的內部：一列是怎麼被對應到的2. UDP テーブルの内側：行はどう照合されるか

The single most useful thing you can learn about UDPs is the matching algorithm, because every exam question and every real debugging session reduces to running it in your head. The lecture states the rules in scattered bullets; here they are as one procedure.關於 UDP，最有用的一件事就是學會匹配演算法，因為每一道考題、每一次真實的除錯都可以化約成在腦中跑一遍這個演算法。講義把規則散在各個項目裡；這裡把它們寫成單一的程序。UDP について学べる最も有用なことは照合アルゴリズムである。あらゆる試験問題も、あらゆる実際のデバッグも、これを頭の中で実行することに帰着するからだ。講義では規則が箇条書きに散らばっているが、ここでは一つの手順としてまとめる。

2.1 The symbol alphabet2.1 符號字母表2.1 記号のアルファベット

Two of these deserve emphasis because the slides list them without comment. p and n are the pessimism-tolerant edges: they fire not only on a clean 0→1 but also on 0→x and x→1. Library flip-flop models use r and f when they want to ignore unknown clock edges and p/n when they want to propagate the uncertainty. The choice is a deliberate optimism/pessimism trade-off, and getting it wrong is how a gate-level simulation either hides a real reset problem or drowns in spurious x.其中有兩個值得特別強調，因為講義只是列出來而沒有說明。p 與 n 是容忍悲觀的邊緣：它們不只在乾淨的 0→1 時觸發，0→x 與 x→1 也會觸發。單元庫的正反器模型在想忽略未知時脈邊緣時用 r 與 f，在想把不確定性傳下去時用 p／n。這個選擇是刻意的樂觀／悲觀取捨，選錯了，閘層級模擬要嘛藏住一個真實的重置問題，要嘛被一堆假的 x 淹沒。このうち二つは、講義が注釈なしに並べているだけなので強調しておく価値がある。p と n は悲観性に寛容なエッジである。きれいな 0→1 だけでなく、0→x や x→1 でも発火する。ライブラリのフリップフロップモデルは、不定のクロックエッジを無視したいときに r と f を、不確かさを伝えたいときに p／n を使う。これは意図的な楽観／悲観のトレードオフであり、選択を誤れば、ゲートレベルシミュレーションは実在するリセットの問題を隠すか、偽の x に溺れるかのどちらかになる。

And - is not a don't-care. It is an instruction: do not schedule anything; leave the output where it is. Putting - in an input field is a syntax error. Putting ? in an output field is a syntax error. Students mix these up constantly, because in Karnaugh-map notation both symbols mean "don't care".而 - 並不是不在意。它是一道指令：什麼都不要排程，讓輸出保持原狀。把 - 放進輸入欄是語法錯誤。把 ? 放進輸出欄也是語法錯誤。學生常常把這兩個搞混，因為在卡諾圖的記法裡兩個符號都是「不在意」。一方 - はドントケアではない。これは命令である。何もスケジュールするな、出力をそのままにしておけ、という意味だ。- を入力フィールドに置くのは構文エラーであり、? を出力フィールドに置くのも構文エラーである。カルノー図の記法ではどちらの記号も「ドントケア」を意味するため、学生は絶えずこの二つを混同する。

2.2 The matching procedure2.2 匹配的程序2.2 照合の手順

When any input of a UDP instance changes value, the simulator does the following.當某個 UDP 實體的任一輸入改變值時，模擬器會做下面的事。UDP インスタンスのいずれかの入力が値を変えると、シミュレータは次のことを行う。

1. Freeze the picture. It records the new value of every input, the previous value of every input, and (for a sequential UDP) the current value of the output reg, which is the state.先把畫面定格。它記下每個輸入的新值、每個輸入的前一個值，以及（對循序邏輯 UDP 而言）輸出 reg 目前的值，也就是狀態。画面を静止させる。各入力の新しい値、各入力の直前の値、そして（順序 UDP であれば）出力 reg の現在値、すなわち状態を記録する。
2. Scan the rows in order. For each row it tests every field. A level field matches if the new input value is in the set the symbol denotes. An edge field matches if the pair (previous value, new value) is in the set the edge symbol denotes. The state field matches if the current output value is in the set the symbol denotes.依序掃描每一列。對每一列檢查所有欄位。準位欄位在新的輸入值屬於該符號所代表的集合時成立。邊緣欄位在（前值, 新值）這個序對屬於該邊緣符號所代表的集合時成立。狀態欄位在目前的輸出值屬於該符號所代表的集合時成立。行を順に走査する。各行についてすべてのフィールドを検査する。レベルフィールドは、新しい入力値がその記号の表す集合に属すれば一致する。エッジフィールドは、（旧値, 新値）の順序対がそのエッジ記号の表す集合に属すれば一致する。状態フィールドは、現在の出力値がその記号の表す集合に属すれば一致する。
3. Apply the first match. The output field of the matching row gives the new output: a literal 0, 1 or x, or - meaning hold.套用第一個對應到的列。該列的輸出欄給出新的輸出：字面值 0、1 或 x，或者表示維持的 -。最初に一致した行を適用する。その行の出力フィールドが新しい出力を与える。リテラルの 0、1、x、あるいは保持を意味する - である。
4. If no row matches, drive x. Unconditionally. No warning, no error.如果沒有任何一列對應，就驅動 x。無條件如此。沒有警告，也沒有錯誤。どの行も一致しなければ x を駆動する。無条件に、である。警告もエラーも出ない。

Step 2 hides the rule that catches people out: only one input may have changed. Verilog processes events one at a time. If two inputs of a UDP are assigned in the same time step, the simulator evaluates the UDP twice, once for each change, in an order the standard does not define. A row whose fields require two simultaneous edges can therefore never match. The standard enforces this by forbidding more than one edge specifier per row.第 2 步藏著一條常常絆倒人的規則：同一時刻只能有一個輸入發生變化。Verilog 一次處理一個事件。如果 UDP 的兩個輸入在同一個時間步被指定，模擬器會把這個 UDP 求值兩次，每次對應一個變化，而順序是標準沒有定義的。因此，一列如果要求兩個邊緣同時發生，就永遠不可能對應到。標準透過「每一列最多只能有一個邊緣指定子」來強制這一點。手順 2 には、人をつまずかせる規則が隠れている。変化した入力は一つだけでなければならない。Verilog はイベントを一度に一つずつ処理する。UDP の二つの入力が同じ時間ステップで代入されると、シミュレータはその UDP を変化ごとに一度ずつ、計二回評価する。その順序は標準が定めていない。したがって、二つのエッジが同時に起きることを要求する行は決して一致しない。標準は「一行につきエッジ指定子は高々一つ」と定めてこれを強制している。

2.3 What "anything unspecified is x" really costs2.3 「沒列到的一律是 x」真正的代價2.3 「指定されていないものはすべて x」が本当に要求する代償

The slide says "Anything unspecified will be treated as x" in one line. That line is the single biggest source of mysterious x in gate-level simulation, and it deserves unpacking.投影片用一行寫著「任何未指定的情況都會被當成 x」。那一行是閘層級模擬中神祕 x 的最大單一來源，值得攤開來講。スライドには「指定されていないものはすべて x として扱われる」と一行だけ書かれている。その一行が、ゲートレベルシミュレーションにおける謎の x の最大の供給源であり、展開して説明するに値する。

A combinational UDP with three inputs has $3^3 = 27$ possible input combinations once you include x. A table that covers only the eight all-known combinations leaves 19 uncovered. Every one of those 19 drives the output to x. That is not a bug in the simulator; it is the model telling you "I was never characterised for this case". But the practical effect is that a single unknown anywhere in a gate-level netlist propagates forward through every UDP it touches, and because an x output feeds the next cell's input, the unknown region grows monotonically. One uninitialised flip-flop can turn an entire datapath red within a few clock cycles.三輸入的組合邏輯 UDP，把 x 算進去之後共有 $3^3 = 27$ 種可能的輸入組合。只涵蓋八種全為已知值組合的表，留下了 19 種沒有涵蓋。那 19 種每一種都會把輸出驅動成 x。這不是模擬器的錯；這是模型在告訴你「我從來沒有為這個情況做過特性化」。但實務上的效果是：閘層級網表中任何一處的單一未知值都會往前傳過它碰到的每一個 UDP，而且因為 x 的輸出會餵進下一顆單元的輸入，未知的區域只會單調擴大。一顆沒有初始化的正反器，可以在幾個時脈週期內把整條資料路徑染紅。三入力の組み合わせ UDP は、x を含めると入力の組み合わせが $3^3 = 27$ 通りある。すべて既知の八通りだけを覆うテーブルは、19 通りを覆い残す。その 19 通りはいずれも出力を x に駆動する。これはシミュレータの不具合ではなく、「この場合については特性化されていない」とモデルが告げているのである。しかし実際の効果はこうだ。ゲートレベルネットリストのどこか一か所の不定値が、通過するすべての UDP を経て前方へ伝わり、x の出力が次のセルの入力になるため、不定領域は単調に拡大する。初期化されていないフリップフロップ一つが、数クロックのうちにデータパス全体を赤く染めることがある。

The defence is to write rows that recognise the cases where the output is determined despite an unknown input. An AND gate with one input at 0 outputs 0 no matter what the other input is, even if it is x. A table that does not say so is pessimistic: it reports less knowledge than the circuit actually has. Section 3.3 works through the multiplexer case in detail.對策是補上那些「即使有未知輸入、輸出仍然確定」的列。AND 閘只要有一個輸入是 0，不論另一個輸入是什麼，輸出就是 0，就算另一個是 x 也一樣。沒有把這件事寫出來的表就是悲觀的：它回報的知識比電路實際具有的少。3.3 節會詳細走一遍多工器的例子。対策は、入力が不定であっても出力が決まる場合を認識する行を書くことである。AND ゲートは入力の一方が 0 なら、もう一方が何であっても — たとえ x でも — 出力は 0 である。それを書いていないテーブルは悲観的であり、回路が実際に持っている知識より少ない知識しか報告しない。3.3 節でマルチプレクサの例を詳しく追う。

2.4 Expansion arithmetic: how many rows is a shorthand row worth?2.4 展開的算術：一列簡寫抵幾列？2.4 展開の算術：短縮形の一行は何行ぶんか

A row containing k occurrences of ? and m occurrences of b expands to $3^{k}\cdot 2^{m}$ concrete rows. This is the arithmetic the compiler performs when it builds the lookup structure, and it is worth doing by hand once because it tells you immediately whether a table is complete.含有 k 個 ? 與 m 個 b 的一列，會展開成 $3^{k}\cdot 2^{m}$ 個具體的列。這正是編譯器在建立查表結構時所做的算術，而且值得親手算一次，因為它會立刻告訴你一張表是否完整。? を k 個、b を m 個含む行は、$3^{k}\cdot 2^{m}$ 個の具体的な行に展開される。これはコンパイラがルックアップ構造を構築するときに行う計算そのものであり、一度は手で計算してみる価値がある。テーブルが完全かどうかが即座に分かるからだ。

Take the two-input AND as a worked case. The complete combinational table over $\{0,1,x\}$ has nine rows. Now count what a compact table covers:拿兩輸入 AND 當作例題。在 $\{0,1,x\}$ 上的完整組合表有九列。現在來數一數精簡版的表涵蓋了多少：二入力 AND を例題にとる。$\{0,1,x\}$ 上の完全な組み合わせテーブルは九行である。では簡潔なテーブルが何を覆っているか数えてみる。

primitive and_udp (y, a, b);
  output y;
  input  a, b;
  table
  // a b : y
     0 ? : 0;     // expands to 3 rows: 00, 01, 0x
     ? 0 : 0;     // expands to 3 rows: 00, 10, x0   (00 repeats)
     1 1 : 1;     // 1 row
  endtable
endprimitive

Contrast that with an OR built the same way. If you write only 1 ? : 1; ? 1 : 1; 0 0 : 0; you cover 10, 11, 1x, 01, x1, 00 and leave 0x, x0, xx to default to x — again correct. The pattern generalises: for a monotone gate, listing the controlling value with ? on the other inputs plus the single all-non-controlling row is both minimal and exactly as precise as silicon.拿同樣方式寫成的 OR 來對照。如果你只寫 1 ? : 1; ? 1 : 1; 0 0 : 0;，你涵蓋了 10, 11, 1x, 01, x1, 00，而把 0x、x0、xx 留給預設值 x — 同樣正確。這個模式可以推廣：對單調的閘而言，把控制值配上其他輸入的 ? 列出來，再加上「全部都不是控制值」的那一列，就同時達到最精簡且與矽晶片一樣精確。同じやり方で書いた OR と比べてみる。1 ? : 1; ? 1 : 1; 0 0 : 0; だけを書けば、10, 11, 1x, 01, x1, 00 を覆い、0x、x0、xx は既定の x に委ねられる — これも正しい。このパターンは一般化できる。単調なゲートであれば、制御値を書いて他の入力を ? にした行と、すべてが非制御値である一行とを並べるだけで、最小でありながらシリコンとまったく同じ精度になる。

2.5 Ambiguity, contradiction and row order2.5 歧義、矛盾與列的順序2.5 曖昧さ、矛盾、行の順序

Two rows may overlap. If they agree on the output, nothing happens and the duplication is harmless (as with 00 above). If they disagree, the standard calls the table ambiguous and says the behaviour is undefined; in practice simulators either warn at compile time and take the first row, or warn and produce x. Different tools, different answers — which is why you must never rely on row order in a UDP.兩列可能重疊。如果它們的輸出一致，什麼事都不會發生，重複是無害的（就像前面的 00）。如果它們不一致，標準稱這張表是有歧義的，並說行為未定義；實務上模擬器要嘛在編譯期警告並採用第一列，要嘛警告並產生 x。不同工具、不同答案 — 這就是為什麼你絕不能在 UDP 裡依賴列的順序。二つの行が重なることがある。出力が一致していれば何も起こらず、重複は無害である（先ほどの 00 のように）。一致していなければ、標準はそのテーブルを曖昧と呼び、動作は未定義だと述べる。実際には、シミュレータはコンパイル時に警告して最初の行を採るか、警告して x を出すかのいずれかである。ツールが違えば答えも違う — だからこそ UDP では行の順序に頼ってはならない。

One more subtlety. In a sequential UDP, a row with no edge specifier anywhere is a level-sensitive row, and the standard gives level-sensitive rows precedence over edge-sensitive rows when both match. This is a genuine priority rule, and it is the one exception to "rows have no priority". It exists so that asynchronous set/clear rows, which are level-sensitive, override the clock rows without you having to enumerate the interaction. Section 4.6 returns to it.還有一個細節。在循序邏輯 UDP 裡，一整列都沒有邊緣指定子的列是準位敏感列，而標準規定：當準位敏感列與邊緣敏感列同時對應時，準位敏感列優先。這是一條真正的優先權規則，也是「列沒有優先順序」的唯一例外。它存在的目的，是讓屬於準位敏感的非同步設定／清除列能夠壓過時脈列，而不必由你去逐一列舉兩者的交互作用。4.6 節會再回到這一點。もう一つ微妙な点がある。順序 UDP において、どこにもエッジ指定子のない行はレベル感応の行であり、標準は、両方が一致する場合にレベル感応の行がエッジ感応の行に優先すると定めている。これは本物の優先規則であり、「行に優先順位はない」の唯一の例外である。レベル感応である非同期セット／クリアの行が、相互作用をいちいち列挙しなくてもクロックの行を上書きできるように存在している。4.6 節でこれに戻る。

3. Combinational UDPs in Detail3. 組合邏輯 UDP 詳解3. 組み合わせ UDP の詳細

3.1 Column discipline3.1 欄位的紀律3.1 列の規律

A combinational UDP with n inputs has a table of n+1 columns: the first n are the inputs in port-list order, then a colon, then the single output column, then a semicolon. There are no headings; the comment line that every well-written table carries is purely for humans.有 n 個輸入的組合邏輯 UDP，其表格有 n+1 欄：前 n 欄是依埠列表順序排列的輸入，接著一個冒號，然後是單一的輸出欄，最後是分號。表格沒有標題；每張寫得好的表都會有的那行註解純粹是給人看的。入力が n 個の組み合わせ UDP のテーブルは n+1 列からなる。最初の n 列がポートリストの順序での入力、次にコロン、続いて唯一の出力列、最後にセミコロンである。見出しはない。よく書かれたテーブルに必ず付いているコメント行は、純粋に人間のためのものである。

Port-list order is the whole contract. If the declaration is primitive mux_prim (mux_out, select, a, b); then column one is select, column two is a, column three is b. Reorder the inputs in the declaration and every row in the table changes meaning without a single warning. This is the most common way a hand-written UDP goes wrong, and the reason the colon before the output exists at all: it is the one visual anchor that tells you where the inputs stop.埠列表的順序就是整份契約。如果宣告是 primitive mux_prim (mux_out, select, a, b);，那麼第一欄是 select、第二欄是 a、第三欄是 b。把宣告裡的輸入重新排序，表中每一列的意義都會改變，而且連一個警告都不會有。這是手寫 UDP 最常出錯的方式，也正是輸出前面那個冒號存在的理由：它是唯一能告訴你輸入到哪裡結束的視覺錨點。ポートリストの順序が契約のすべてである。宣言が primitive mux_prim (mux_out, select, a, b); なら、第一列は select、第二列は a、第三列は b である。宣言の入力を並べ替えれば、テーブルのすべての行の意味が変わる。警告は一つも出ない。手書きの UDP が壊れる最も多い原因がこれであり、出力の前のコロンが存在する理由でもある。入力がどこで終わるかを教えてくれる唯一の視覚的な目印なのだ。

3.2 The multiplexer, row by row3.2 多工器，逐列解讀3.2 マルチプレクサを一行ずつ

Here is the lecture's two-to-one multiplexer written out in full, with select = 0 choosing a and select = 1 choosing b.以下是講義那個 2 對 1 多工器的完整寫法，select = 0 選 a，select = 1 選 b。以下は講義の 2 対 1 マルチプレクサを省略せずに書いたものである。select = 0 で a を、select = 1 で b を選ぶ。

primitive mux_prim (mux_out, select, a, b);
  output mux_out;
  input  select, a, b;
  table
  //  select   a   b   :  mux_out
        0     0   0   :    0;    // table order = port order
        0     0   1   :    0;    // one output, many inputs, no inout
        0     0   x   :    0;    // only 0, 1, x may appear
        0     1   0   :    1;    // a z input is treated as x
        0     1   1   :    1;
        0     1   x   :    1;    // last column is the output

        1     0   0   :    0;
        1     1   0   :    0;
        1     x   0   :    0;
        1     0   1   :    1;
        1     1   1   :    1;
        1     x   1   :    1;

        x     0   0   :    0;    // reduces pessimism
        x     1   1   :    1;
  endtable
endprimitive

Fourteen rows out of the $3^3 = 27$ possible combinations. Walk the three groups:$3^3 = 27$ 種可能組合中寫了十四列。逐一看這三組：$3^3 = 27$ 通りの組み合わせのうち十四行を書いている。三つのグループを順に見ていく。

The 13 uncovered combinations are exactly the ones where the answer honestly is unknown: select = 0 with a = x (three rows), select = 1 with b = x (three rows), and select = x with a ≠ b or either data input unknown (seven rows). The model is tight: nothing is lost, nothing is invented.那 13 種沒被涵蓋的組合，正好就是答案老老實實地未知的那些：select = 0 且 a = x（三列）、select = 1 且 b = x（三列），以及 select = x 且 a ≠ b 或任一資料輸入未知（七列）。這個模型很緊：沒有漏掉什麼，也沒有憑空捏造什麼。覆われていない 13 通りは、まさに答えが正直に不定である場合である。select = 0 かつ a = x（三通り）、select = 1 かつ b = x（三通り）、そして select = x で a ≠ b またはいずれかのデータ入力が不定の場合（七通り）。このモデルは引き締まっている。失われたものも、でっち上げられたものもない。

3.3 The ? shorthand and what it buys3.3 ? 簡寫及其好處3.3 ? という短縮形とその効用

The same function compresses to six rows:同一個函數可以壓縮成六列：同じ関数は六行に圧縮できる。

  table
  //  select  a   b  : mux_out
        0    0   ?  :   0;   // ? = 0, 1, x
        0    1   ?  :   1;
        1    ?   0  :   0;
        1    ?   1  :   1;
        ?    0   0  :   0;
        ?    1   1  :   1;
  endtable

row 1:  1 x 1 x 3 = 3   (000, 001, 00x)
row 2:  1 x 1 x 3 = 3   (010, 011, 01x)
row 3:  1 x 3 x 1 = 3   (100, 110, 1x0)
row 4:  1 x 3 x 1 = 3   (101, 111, 1x1)
row 5:  3 x 1 x 1 = 3   (000, 100, x00)
row 6:  3 x 1 x 1 = 3   (011, 111, x11)
                     ----
raw total            18
minus 4 duplicates   14   // 000, 011, 100, 111

Eighteen row-expansions, but four combinations are covered twice — 000 by rows 1 and 5, 011 by rows 2 and 6, 100 by rows 3 and 5, 111 by rows 4 and 6 — so the distinct coverage is 14, exactly matching the long form. The duplicates are consistent (both rows give the same output in each case), so the table is unambiguous. This is the check you should run on any shorthand table you write: expand, count, and look for a combination covered twice with different outputs.展開後共十八列，但有四種組合被涵蓋兩次 — 000 來自第 1 與第 5 列、011 來自第 2 與第 6 列、100 來自第 3 與第 5 列、111 來自第 4 與第 6 列 — 所以相異的涵蓋數是 14，正好與完整寫法相符。重複的部分彼此一致（每一種情況下兩列給出相同的輸出），所以這張表沒有歧義。這就是你對自己寫的任何一張簡寫表都該做的檢查：展開、計數，然後找出有沒有哪個組合被涵蓋兩次卻給出不同的輸出。展開すると十八行ぶんになるが、四つの組み合わせが二度覆われる — 000 は第 1 行と第 5 行、011 は第 2 行と第 6 行、100 は第 3 行と第 5 行、111 は第 4 行と第 6 行である。したがって重複を除いた被覆は 14 となり、完全形とちょうど一致する。重複はいずれも整合しており（どの場合も両方の行が同じ出力を与える）、テーブルは曖昧ではない。自分で書いた短縮形のテーブルには必ずこの検査を行うこと。展開し、数え、二度覆われていて出力が異なる組み合わせがないか探す。

Why bother with the long form at all, then? Because expansion is how the compiler builds the lookup table, and a row with many ? in a wide UDP expands explosively. A nine-input sequential UDP with a row of eight ? expands to $3^8 = 6561$ entries from one line of source. Library writers keep an eye on this; it is why vendor models use b rather than ? wherever the unknown case is handled by a separate row.那為什麼還要有完整寫法？因為展開正是編譯器建立查表的方式，而在寬的 UDP 裡，一列含有很多 ? 會爆炸性地展開。一個九輸入的循序邏輯 UDP，只要有一列含八個 ?，一行原始碼就展開成 $3^8 = 6561$ 筆。單元庫的作者會盯著這件事；這也是為什麼在未知情況由另一列單獨處理時，供應商的模型會用 b 而不用 ?。では完全形を書く意味はどこにあるのか。展開こそコンパイラがルックアップテーブルを構築する方法であり、幅の広い UDP では ? を多く含む行が爆発的に展開するからである。九入力の順序 UDP で ? を八個含む行が一行あれば、ソース一行から $3^8 = 6561$ 項目が生成される。ライブラリの作者はこれに目を光らせている。不定の場合を別の行で処理できるところでベンダのモデルが ? ではなく b を使うのは、そのためである。

3.4 The majority function3.4 多數決函數3.4 多数決関数

The lecture's second combinational example is $\text{out} = ab + ac + bc$, the three-input majority function, which is also the carry-out of a full adder.講義的第二個組合邏輯例子是 $\text{out} = ab + ac + bc$，也就是三輸入的多數決函數，同時也是全加器的進位輸出。講義の二つ目の組み合わせ回路の例は $\text{out} = ab + ac + bc$、すなわち三入力の多数決関数であり、全加算器のキャリー出力でもある。

primitive boolean_func (out, a, b, c);
  output out;
  input  a, b, c;
  table
  // a b c : out
     0 0 ? : 0;
     0 ? 0 : 0;
     ? 0 0 : 0;
     1 1 ? : 1;
     1 ? 1 : 1;
     ? 1 1 : 1;
  endtable
endprimitive

Six rows for a function of three variables, and the structure is beautifully direct: any two inputs at 0 force the output to 0; any two inputs at 1 force it to 1. That is the definition of a majority gate, transcribed. The third input is a ? because it genuinely cannot change the answer, and that includes the case where it is x.三個變數的函數只用六列，而且結構漂亮而直接：任兩個輸入為 0 就把輸出壓成 0；任兩個輸入為 1 就把輸出推成 1。那就是多數決閘的定義，直接抄寫下來。第三個輸入寫成 ?，因為它真的不可能改變答案，連它是 x 的情況也包含在內。三変数の関数がわずか六行で、しかも構造が見事に素直である。いずれか二つの入力が 0 なら出力は 0 に決まり、いずれか二つが 1 なら 1 に決まる。多数決ゲートの定義をそのまま書き写したものだ。第三の入力が ? なのは、それが本当に答えを変えられないからであり、それが x である場合も含まれる。

Compare this with how you would write the same function in RTL — assign out = (a & b) | (a & c) | (b & c); — and evaluate it with a = z, b = 0, c = 0. Verilog's bitwise operators treat z as x too, so each AND yields 0 (x & 0 = 0), and the OR of three zeros is 0. The two models agree here, but they do not always: the built-in operators apply x-optimism term by term, whereas a UDP applies exactly the rows you wrote. That divergence is why a synthesised netlist and its RTL source can disagree on x propagation even when the logic is formally equivalent. Lecture 5 revisits this under the heading of simulation/synthesis mismatch.拿它和你在 RTL 裡寫同一個函數的方式比較 — assign out = (a & b) | (a & c) | (b & c); — 並以 a = z, b = 0, c = 0 求值。Verilog 的位元運算子同樣把 z 當成 x，所以每個 AND 都得到 0（x & 0 = 0），三個 0 做 OR 還是 0。兩個模型在這裡一致，但不是永遠一致：內建運算子是逐項套用 x 樂觀化，而 UDP 套用的恰好只有你寫出來的那些列。這個分歧正是為什麼合成出來的網表與它的 RTL 原始碼，即使在形式上等價，仍可能在 x 的傳播上意見不同。第 5 講會在「模擬／合成不一致」這個標題下再談。同じ関数を RTL で書いた場合 — assign out = (a & b) | (a & c) | (b & c); — と比べ、a = z, b = 0, c = 0 で評価してみる。Verilog のビット演算子も z を x として扱うので、各 AND は 0 を返し（x & 0 = 0）、三つの 0 の OR は 0 になる。ここでは二つのモデルが一致するが、常にそうとは限らない。組み込み演算子は項ごとに x の楽観化を適用するのに対し、UDP は書かれた行だけを適用する。この食い違いこそ、論理的には等価であっても、合成後のネットリストとその RTL ソースが x の伝搬で食い違いうる理由である。第 5 講はこれをシミュレーションと合成の不一致という見出しで再び扱う。

primitive eq1 (y, a, b);
  output y;
  input  a, b;
  table
  // a b : y
     0 0 : 1;
     1 1 : 1;
     0 1 : 0;
     1 0 : 0;
  endtable
endprimitive

4. Sequential UDPs: Level- and Edge-Sensitive Tables4. 循序邏輯 UDP：準位敏感表與邊緣敏感表4. 順序 UDP：レベル感応表とエッジ感応表

4.1 The state column4.1 狀態欄4.1 状態の列

A sequential UDP has n inputs, one output, one unit of state, and n+2 columns:循序邏輯 UDP 有 n 個輸入、一個輸出、一單位的狀態，以及 n+2 欄：順序 UDP は n 個の入力、一つの出力、一単位の状態を持ち、列は n+2 個である。

The crucial realisation is that the state and the output are the same object. There is no separate state register hidden inside the UDP; the state is the current value of the output reg, and the last column is simultaneously "the next state" and "the new output value". The lecture writes the heading as q_out/next state for exactly this reason. A UDP therefore models a Moore machine with a one-bit state and an identity output function — which is all a latch or a flip-flop ever is.關鍵的領悟是：狀態與輸出是同一個東西。UDP 內部沒有另外藏一個狀態暫存器；狀態就是輸出 reg 目前的值，而最後一欄同時是「下一個狀態」與「新的輸出值」。講義把欄位標題寫成 q_out/next state，正是這個理由。因此一個 UDP 所建模的是一台狀態只有一位元、輸出函數為恆等的 Moore 機 — 而閂鎖器或正反器從來就只是這樣。決定的に重要な理解は、状態と出力が同じものだということである。UDP の内部に別の状態レジスタが隠れているわけではない。状態そのものが出力 reg の現在値であり、最後の列は「次状態」であると同時に「新しい出力値」でもある。講義が見出しを q_out/next state と書いているのは、まさにこのためだ。したがって UDP がモデル化するのは、状態が 1 ビットで出力関数が恒等写像の Moore 機械である — ラッチやフリップフロップとは、もともとそれだけのものだ。

The state field accepts 0, 1, x, ? or b, never an edge specifier (state does not have a "previous value" in the matching sense) and never -. The output field accepts 0, 1, x or -, never ? or b.狀態欄接受 0、1、x、? 或 b，不接受邊緣指定子（在匹配的意義上，狀態沒有「前一個值」），也不接受 -。輸出欄接受 0、1、x 或 -，不接受 ? 或 b。状態フィールドは 0、1、x、?、b を受け付け、エッジ指定子は受け付けず（照合の意味で状態には「直前値」がない）、- も受け付けない。出力フィールドは 0、1、x、- を受け付け、? と b は受け付けない。

Because the output reg starts life as x, a sequential UDP powers up unknown unless you initialise it. The standard permits a single initial statement inside the primitive body:因為輸出 reg 一開始的值就是 x，循序邏輯 UDP 若不初始化，上電後就是未知。標準允許在原型本體內寫一個 initial 敘述：出力 reg は x から始まるので、初期化しなければ順序 UDP は電源投入時に不定である。標準はプリミティブ本体の中に initial 文を一つだけ書くことを許している。

primitive dff_init (q, clk, d);
  output q;  input clk, d;  reg q;
  initial q = 1'b0;        // legal only as a simple constant assignment to the output reg
  table
    r 0 : ? : 0;
    r 1 : ? : 1;
    f ? : ? : -;
    ? * : ? : -;
  endtable
endprimitive

That initial is the only procedural statement allowed anywhere in a UDP, it may assign only a constant 0, 1 or x, and it runs once at time zero. Library models use it sparingly, because a flip-flop that silently powers up at 0 can hide a missing reset — the same optimism trap discussed in §2.3.那個 initial 是 UDP 裡唯一允許的程序式敘述，它只能指定常數 0、1 或 x，而且只在時間零執行一次。單元庫的模型很少用它，因為一顆默默從 0 開機的正反器可能藏住缺漏的重置 — 就是 §2.3 討論過的那個樂觀陷阱。この initial は UDP 内で唯一許される手続き文であり、代入できるのは定数 0、1、x のみ、実行は時刻ゼロに一度きりである。ライブラリのモデルがこれを控えめにしか使わないのは、黙って 0 で立ち上がるフリップフロップがリセットの欠落を隠しかねないからだ — §2.3 で論じた楽観の罠そのものである。

4.2 Level-sensitive behaviour: the transparent latch4.2 準位敏感的行為：透通閂鎖器4.2 レベル感応の振る舞い：透過ラッチ

primitive latch (q_out, enable, data);
  output q_out;
  input  enable, data;
  reg    q_out;

  table
  //  en   data  :  state  :  q_out / next state
       1    1    :    ?    :     1;
       1    0    :    ?    :     0;
       0    ?    :    ?    :     -;    // '-' means "no change"
  endtable
endprimitive

Three rows, and every one of them is level-sensitive: no field contains an edge specifier. Read them as English.三列，而且每一列都是準位敏感的：沒有任何欄位含邊緣指定子。把它們當英文讀一遍。三行あり、そのいずれもレベル感応である。エッジ指定子を含むフィールドが一つもない。これらを文章として読んでみる。

• Row 1. Enable is high and data is high, whatever the current state: the new state is 1. The latch is transparent.第 1 列。enable 為高、data 為高，不論目前狀態為何：新狀態是 1。閂鎖器此時是透通的。第 1 行。enable が高、data が高なら、現在の状態によらず新しい状態は 1 である。ラッチは透過状態にある。
• Row 2. Enable high, data low: new state 0. Still transparent.第 2 列。enable 為高、data 為低：新狀態 0。仍然透通。第 2 行。enable が高、data が低なら新しい状態は 0。やはり透過状態である。
• Row 3. Enable low, data anything, state anything: hold. The latch is opaque.第 3 列。enable 為低，data 任意、狀態任意：維持。閂鎖器此時是不透通的。第 3 行。enable が低なら、data も状態も任意で、保持する。ラッチは不透過である。

Count the coverage: rows 1 and 2 each cover one input combination times three state values, row 3 covers $1 \times 3 \times 3 = 9$. Total 15 of the $3 \times 3 \times 3 = 27$ possible (input, input, state) triples. The twelve uncovered ones all have enable = x or data = x with enable = 1, and they all default to x.數一數涵蓋範圍：第 1、2 列各涵蓋一種輸入組合乘以三個狀態值，第 3 列涵蓋 $1 \times 3 \times 3 = 9$ 種。合計 15 種，佔 $3 \times 3 \times 3 = 27$ 種可能的（輸入, 輸入, 狀態）三元組。沒被涵蓋的那十二種，不是 enable = x，就是 enable = 1 時 data = x，而它們全部預設為 x。被覆を数えてみる。第 1 行と第 2 行はそれぞれ入力の組み合わせ一通り × 状態三値を覆い、第 3 行は $1 \times 3 \times 3 = 9$ 通りを覆う。合計 15 通りで、可能な（入力, 入力, 状態）の三つ組 $3 \times 3 \times 3 = 27$ 通りのうちの 15 である。覆われない十二通りは enable = x であるか、enable = 1 で data = x であるかのいずれかで、すべて既定の x になる。

Is that right? Partly. enable = 1, data = x genuinely gives q = x — a transparent latch passes the unknown through. But enable = x is more interesting. If enable = x and data = 1 and the current state is already 1, then whether the latch is transparent or opaque, the answer is 1. A less pessimistic model adds:這樣對嗎？對了一半。enable = 1, data = x 確實應該給 q = x — 透通的閂鎖器會把未知值直接放過去。但 enable = x 就比較有趣了。如果 enable = x、data = 1，而目前狀態已經是 1，那麼不論閂鎖器是透通還是不透通，答案都是 1。比較不悲觀的模型會加上：これは正しいのか。半分は正しい。enable = 1, data = x は確かに q = x を与えるべきだ — 透過状態のラッチは不定値をそのまま通す。しかし enable = x のほうが興味深い。enable = x かつ data = 1 で、現在の状態がすでに 1 なら、ラッチが透過であろうと不透過であろうと答えは 1 である。より悲観的でないモデルは次の行を加える。

       x    1    :    1    :     1;   // transparent or not, the answer is 1
       x    0    :    0    :     0;   // transparent or not, the answer is 0

Real library latch models contain exactly these rows. They are the sequential analogue of the multiplexer's ? 0 0 : 0;, and they matter during clock-gating transients where the enable is briefly unknown.真實單元庫的閂鎖器模型裡就有這幾列。它們是多工器那條 ? 0 0 : 0; 在循序邏輯上的對應物，在時脈閘控（clock gating）的暫態中 enable 短暫未知時特別重要。実際のライブラリのラッチモデルには、まさにこれらの行が入っている。マルチプレクサの ? 0 0 : 0; に対応する順序回路版であり、クロックゲーティングの過渡で enable が一瞬不定になる場面で効いてくる。

4.3 Reading the latch waveform4.3 讀懂閂鎖器的波形4.3 ラッチ波形の読み方

Trace it event by event, because this is precisely what an exam asks you to do.逐事件追蹤一遍，因為考試要你做的正是這件事。イベントごとに追ってみる。試験で求められるのはまさにこれだからである。

4.4 Edge-sensitive behaviour: the D flip-flop4.4 邊緣敏感的行為：D 型正反器4.4 エッジ感応の振る舞い：D フリップフロップ

primitive d_prim1 (q_out, clock, data);
  output q_out;
  input  clock, data;
  reg    q_out;

  table
  //  clk    data  :  state  :  q_out / next state
      (01)    0    :    ?    :    0;    // rising clock edge, capture 0
      (01)    1    :    ?    :    1;    // rising clock edge, capture 1
      (0?)    1    :    1    :    1;    // 0->x edge, data=1, already 1: stays 1

      (?0)    ?    :    ?    :    -;    // any falling clock edge: hold

       ?     (??)  :    ?    :    -;    // data changed, clock steady: hold
  endtable
endprimitive

Five rows, and every one is doing specific work. The first two are the flip-flop proper. The last two are what make the model usable at all, and they are the rows students omit.五列，而且每一列都在做具體的工作。前兩列是正反器本身。後兩列才是讓這個模型堪用的關鍵，而它們正是學生會漏掉的列。五行あり、そのどれもが具体的な仕事をしている。最初の二行がフリップフロップ本体である。最後の二行こそモデルを使い物にしているところであり、学生が省いてしまうのもその二行である。

Why row 4 ((?0) ? : ? : -) is mandatory. Without it, a falling clock edge matches no row and the output goes to x. Every flip-flop in the design would be destroyed on the first negative clock edge. The row says explicitly: a falling clock changes nothing.為什麼第 4 列（(?0) ? : ? : -）是必要的。少了它，時脈的下降緣對應不到任何一列，輸出就變成 x。設計中的每一顆正反器都會在第一個時脈負緣被毀掉。這一列明說：時脈下降什麼都不改變。なぜ第 4 行（(?0) ? : ? : -）が必須か。これがなければクロックの立ち下がりはどの行にも一致せず、出力は x になる。設計中のすべてのフリップフロップが最初のクロック負エッジで壊れてしまう。この行は「クロックの立ち下がりは何も変えない」と明示している。

Why row 5 (? (??) : ? : -) is mandatory. Without it, any change on data while the clock is steady matches no row and the output goes to x. A flip-flop whose D input toggles between clock edges — which is every flip-flop in every design — would be destroyed immediately. The row says: data movement with a static clock is ignored.為什麼第 5 列（? (??) : ? : -）是必要的。少了它，時脈穩定不動時 data 上的任何變化都對應不到任何一列，輸出就變成 x。一顆 D 輸入會在時脈邊緣之間切換的正反器 — 也就是任何設計中的任何一顆正反器 — 會立刻被毀掉。這一列說：時脈不動時的資料變化一律忽略。なぜ第 5 行（? (??) : ? : -）が必須か。これがなければ、クロックが静止しているあいだの data の変化はどの行にも一致せず、出力は x になる。クロックエッジのあいだに D 入力がトグルするフリップフロップ — つまりどの設計のどのフリップフロップも — が即座に壊れる。この行は「クロックが静止しているときのデータの動きは無視する」と述べている。

Why row 3 ((0?) 1 : 1 : 1) exists. This is the pessimism-reduction row of the flip-flop. The clock has gone from 0 to something that is not 0 — either a clean 1 (already covered by row 2) or an x. If it went to x we do not know whether a real edge occurred. But if data = 1 and the flip-flop already holds 1, then both possibilities give 1: if the edge was real we capture 1, if it was not we hold 1. So the output stays 1 and the unknown clock does no damage. The symmetric row (0?) 0 : 0 : 0; is equally valid and appears in most library models; the lecture slide shows only the 1 case.為什麼會有第 3 列（(0?) 1 : 1 : 1）。這是正反器的降低悲觀列。時脈從 0 變成了某個不是 0 的值 — 要嘛是乾淨的 1（已被第 2 列涵蓋），要嘛是 x。如果變成 x，我們不知道是否真的發生了一個邊緣。但如果 data = 1 而且正反器本來就保持著 1，那麼兩種可能都給出 1：邊緣是真的，我們擷取到 1；邊緣不是真的，我們保持 1。所以輸出維持 1，未知的時脈沒有造成傷害。對稱的那一列 (0?) 0 : 0 : 0; 同樣成立，而且出現在大多數單元庫模型中；講義投影片只列了 1 的情況。なぜ第 3 行（(0?) 1 : 1 : 1）があるのか。これはフリップフロップにおける悲観性低減の行である。クロックは 0 から 0 でない何かへ変化した — きれいな 1（これは第 2 行が覆う）か、x かである。x になった場合、本当にエッジが起きたのかは分からない。しかし data = 1 でかつフリップフロップがすでに 1 を保持しているなら、どちらの可能性でも答えは 1 である。エッジが本物なら 1 を取り込み、そうでなければ 1 を保持する。よって出力は 1 のままで、不定のクロックは害を及ぼさない。対称な行 (0?) 0 : 0 : 0; も同様に正しく、ほとんどのライブラリモデルに入っている。講義スライドは 1 の場合しか挙げていない。

4.5 Edge-specifier rules4.5 邊緣指定子的規則4.5 エッジ指定子の規則

• At most one edge specifier per row. Because only one input can change per evaluation, a row demanding two simultaneous edges could never match. The compiler rejects it.每一列最多一個邊緣指定子。因為每次求值只有一個輸入能變化，要求兩個邊緣同時發生的列永遠不可能對應到。編譯器會拒絕它。一行につきエッジ指定子は高々一つ。評価ごとに変化できる入力は一つだけなので、二つのエッジの同時発生を要求する行は決して一致しない。コンパイラはこれを拒否する。
• A row with an edge specifier matches only at the instant of that change. It is not a level condition that stays true; it is consumed by the single event.含邊緣指定子的列只在那個變化發生的瞬間才對應。它不是一個會持續為真的準位條件；它被那單一事件消耗掉。エッジ指定子を含む行は、その変化が起きた瞬間にのみ一致する。真であり続けるレベル条件ではなく、その単一のイベントによって消費される。
• If any row in the table contains an edge specifier, the UDP is edge-sensitive overall. The consequence is important: in such a table, an input change that matches no edge row and no level row gives x, which is why catch-all hold rows like row 5 above are compulsory.只要表中有任何一列含邊緣指定子，整個 UDP 就是邊緣敏感的。後果很重要：在這樣的表裡，一個既對應不到任何邊緣列、也對應不到任何準位列的輸入變化，會給出 x，這就是為什麼上面第 5 列那種「包山包海」的保持列是必須的。テーブル中に一行でもエッジ指定子があれば、UDP 全体がエッジ感応になる。その帰結は重要である。そのようなテーブルでは、どのエッジ行にもどのレベル行にも一致しない入力変化は x を与える。だからこそ、上の第 5 行のような総括的な保持行が必須になる。
• * on an input means "this input changed, I do not care how". It is the universal catch-all and belongs in the last rows of a table.輸入欄的 * 表示「這個輸入變了，怎麼變我不在意」。它是萬用的包山包海符號，應該放在表的最後幾列。入力の * は「この入力が変化した、どう変化したかは問わない」を意味する。万能の総括記号であり、テーブルの末尾の行に置くべきものである。
• Edge specifiers on multi-value symbols are expanded. (0?) means (01), (0x) — and notionally (00), which is not a change and so never fires. (??) means every ordered pair of distinct values.多值符號上的邊緣指定子會被展開。(0?) 代表 (01)、(0x) — 名義上還包含 (00)，但那不是變化，所以永遠不會觸發。(??) 代表所有相異值構成的序對。多値記号に付いたエッジ指定子は展開される。(0?) は (01)、(0x) を意味する — 名目上は (00) も含むが、それは変化ではないので決して発火しない。(??) は相異なる値のあらゆる順序対を意味する。

4.6 Level-sensitive rows beat edge-sensitive rows4.6 準位敏感列勝過邊緣敏感列4.6 レベル感応の行はエッジ感応の行に勝つ

This is the one priority rule in the UDP world, and the slides do not mention it. When a sequential UDP contains both level-sensitive rows (no edge field anywhere) and edge-sensitive rows, and an event matches one of each, the level-sensitive row wins.這是 UDP 世界裡唯一的優先權規則，而投影片沒有提到它。當一個循序邏輯 UDP 同時含有準位敏感列（任何欄位都沒有邊緣）與邊緣敏感列，而某個事件同時對應到兩者各一列時，準位敏感的那一列勝出。これは UDP の世界で唯一の優先規則であり、スライドは触れていない。順序 UDP がレベル感応の行（どのフィールドにもエッジがない）とエッジ感応の行の両方を含み、あるイベントがその両方に一致するとき、レベル感応の行が勝つ。

The rule exists for asynchronous set and clear. Consider a flip-flop with active-low clear:這條規則是為了非同步設定與清除而存在的。考慮一顆低準位有效清除的正反器：この規則は非同期セットとクリアのために存在する。ローアクティブのクリアを持つフリップフロップを考える。

  table
  //  clk    d    clr_n :  state :  q+
       ?     ?     0    :   ?   :  0;    // LEVEL row: clear dominates
      (01)   0     1    :   ?   :  0;    // EDGE rows
      (01)   1     1    :   ?   :  1;
  endtable

Suppose the clock rises at exactly the moment clr_n is already 0. The event is the clock edge, so row 2 or 3 is a candidate; row 1 is also a candidate because clr_n = 0 is a level condition that is true. Without the precedence rule you would have an ambiguous table. With it, the clear wins, which is what the silicon does. Note that the edge rows in the listing above also carry clr_n = 1 in their field, which already makes them mutually exclusive with row 1 — belt and braces, and the style you should copy.假設時脈上升的那一刻 clr_n 已經是 0。事件是時脈邊緣，所以第 2 或第 3 列是候選；第 1 列也是候選，因為 clr_n = 0 是一個為真的準位條件。沒有這條優先權規則，你會得到一張有歧義的表。有了它，清除勝出，而這正是矽晶片的行為。注意上面那段程式碼裡的邊緣列也在欄位裡帶著 clr_n = 1，這本身就已經讓它們與第 1 列互斥了 — 雙重保險，也是你該照抄的寫法。clr_n がすでに 0 のちょうどその瞬間にクロックが立ち上がったとする。イベントはクロックエッジなので第 2 行か第 3 行が候補になり、clr_n = 0 は真であるレベル条件なので第 1 行も候補になる。優先規則がなければ曖昧なテーブルである。規則があればクリアが勝ち、それはシリコンの振る舞いと一致する。上のリストのエッジ行がいずれもフィールドに clr_n = 1 を持っており、それだけですでに第 1 行と相互排他になっていることにも注意。二重の備えであり、まねるべき書き方である。

primitive dff_neg_clr (q, clk, d, clr_n);
  output q;
  input  clk, d, clr_n;
  reg    q;
  table
  //  clk     d    clr_n  :  state :  q+
       ?      ?     0     :   ?   :  0;   // 1. clear asserted: level row, dominates
       ?      ?    (?1)   :   ?   :  -;   // 2. clear released: hold, do not clock
      (10)    0     1     :   ?   :  0;   // 3. falling edge captures 0
      (10)    1     1     :   ?   :  1;   // 4. falling edge captures 1
      (1x)    ?     1     :   ?   :  -;   // 5. ambiguous edges: stay put
      (x0)    ?     1     :   ?   :  -;   // 6.
      (0?)    ?     1     :   ?   :  -;   // 7. rising clock: hold
       ?     (??)   1     :   ?   :  -;   // 8. data moves, clock steady: hold
  endtable
endprimitive

5. Gate Delay and the Inertial Model5. 閘延遲與慣性延遲模型5. ゲート遅延と慣性遅延モデル

Verilog has three places you can attach a propagation delay, and they are not alternatives — they stack. The lecture names them:Verilog 有三個地方可以掛上傳播延遲，而且它們不是三選一 — 它們會疊加。講義把它們命名如下：Verilog には伝搬遅延を付けられる場所が三つあり、それらは択一ではなく積み重なる。講義はそれらを次のように呼んでいる。

This section takes the first layer apart. Sections 7 and 8 take the other two, and section 9 puts them back together.本節把第一層拆開來看。第 7 節與第 8 節處理另外兩層，第 9 節再把它們組回去。本節では第一の層を分解する。7 節と 8 節が残る二つを扱い、9 節で組み直す。

5.1 Rise, fall and turn-off: the three delays5.1 上升、下降與關斷：三種延遲5.1 立ち上がり・立ち下がり・ターンオフ：三つの遅延

Verilog does not have "a" propagation delay. It has up to three, selected by the destination value of the transition, not by the direction in any intuitive sense:Verilog 沒有「那個」傳播延遲。它最多有三個，而且是依轉態的目的值來選，不是依任何直覺意義上的方向：Verilog に「唯一の」伝搬遅延というものはない。最大三つあり、しかもそれを選ぶのは遷移の行き先の値であって、直感的な意味での向きではない。

Read those definitions carefully: the rule is "where you are going", never "where you came from". A transition x→1 uses the rising delay even though x is not 0. This matters in gate-level simulation because the first real transition of every net after power-up is x→something, and it is timed with the rise or fall delay accordingly.請仔細讀這些定義：規則是「你要去哪裡」，絕不是「你從哪裡來」。x→1 的轉態用的是上升延遲，即使 x 並不是 0。這在閘層級模擬中很重要，因為上電之後每一條 net 的第一個真實轉態都是 x→某個值，而它就依此用上升或下降延遲計時。これらの定義は注意して読むこと。規則は「どこへ行くか」であって、「どこから来たか」では決してない。x→1 の遷移は x が 0 でなくても立ち上がり遅延を使う。これはゲートレベルシミュレーションで重要になる。電源投入後、あらゆる net の最初の実際の遷移は x→何か であり、それに応じて立ち上がりか立ち下がりの遅延で時刻が決まるからだ。

Turn-off delay only makes sense for a gate that can drive high impedance. That is why the plain logic primitives accept at most two delay values and the three-state family accepts three:關斷延遲只對能驅動高阻抗的閘有意義。這就是為什麼單純的邏輯原型最多接受兩個延遲值，而三態家族接受三個：ターンオフ遅延は高インピーダンスを駆動できるゲートにしか意味がない。だからこそ単純な論理プリミティブは遅延値を最大二つしか受け付けず、三状態系は三つを受け付ける。

and               (y, x1, x2);      // no delay: output changes in the same time step
and #2            (y, x1, x2);      // one value: all transitions take 2
and #1.45         (y, x1, x2);      // a real number: rounded to the module's precision
and #(2,3)        (y, x1, x2);      // (rise, fall)
bufif1 #(3,4,1)   (out, in, ctrl);  // (rise, fall, turn-off)
bufif1 #(3:4:5, 6:7:8, 5:8:9) (out, in, ctrl);   // each one a min:typ:max triple

Writing and #(2,3,4) is an error: an AND gate can never produce z, so there is no transition for the third number to describe. Simulators reject it.寫成 and #(2,3,4) 是錯誤的：AND 閘永遠不可能產生 z，所以沒有任何轉態可以讓第三個數字去描述。模擬器會拒絕它。and #(2,3,4) と書くのは誤りである。AND ゲートは z を出せないので、第三の数値が記述すべき遷移が存在しない。シミュレータはこれを拒否する。

The bufif1 truth table, and where L and H come frombufif1 的真值表，以及 L 與 H 從哪裡來bufif1 の真理値表と、L・H の出どころ

L means "0 or z" and H means "1 or z". They are not storable net values; they are a compact way of saying "the gate is either driving the stated value or not driving at all, and I cannot tell which". A net receiving L from one driver and 0 from another resolves to 0; a net receiving L and 1 resolves to x. These intermediate symbols exist precisely so that bus resolution can still produce a definite answer when one driver's enable is unknown — the same pessimism-reduction philosophy as §3.3, applied at the net level instead of the table level.L 代表「0 或 z」，H 代表「1 或 z」。它們不是可以儲存在 net 上的值；它們是「這個閘要嘛正在驅動所說的值、要嘛根本沒在驅動，而我分不出是哪一種」的精簡寫法。一條 net 若從某個驅動器收到 L、從另一個收到 0，會解析成 0；收到 L 與 1 則解析成 x。這些中間符號存在的目的，正是為了讓匯流排在某個驅動器的致能未知時仍能解析出確定答案 — 與 §3.3 相同的降低悲觀哲學，只是套用在 net 層級而不是表格層級。L は「0 または z」、H は「1 または z」を意味する。これらは net に保持できる値ではなく、「このゲートは述べられた値を駆動しているか、まったく駆動していないかのどちらかで、どちらかは分からない」を簡潔に言い表す記法である。あるドライバから L を、別のドライバから 0 を受けた net は 0 に解決し、L と 1 を受けた net は x に解決する。これらの中間記号が存在するのは、あるドライバのイネーブルが不定でもバスの解決が確定した答えを出せるようにするためである — §3.3 と同じ悲観性低減の思想を、テーブルのレベルではなく net のレベルに適用したものだ。

5.2 The delay mapping table5.2 延遲對應表5.2 遅延マッピング表

Given one, two or three delay values, which one times a given transition? The lecture's mapping table answers it exhaustively.給定一個、兩個或三個延遲值，某個特定轉態該用哪一個？講義的對應表把這件事窮舉完畢。一つ、二つ、あるいは三つの遅延値が与えられたとき、ある遷移にはどれが使われるのか。講義のマッピング表がそれを網羅的に答えている。

Three observations make this table memorable instead of arbitrary.有三點觀察能讓這張表變得好記，而不只是一堆任意規定。三つの観察によって、この表は恣意的な決まりごとではなく覚えやすいものになる。

The diagonal is empty. A "transition" from a value to itself is not a transition; nothing is scheduled, no delay applies. The simulator discards it before the delay machinery is reached.對角線是空的。從一個值「轉態」到它自己並不是轉態；什麼都不會被排程，也沒有延遲可言。模擬器在延遲機制被用到之前就把它丟掉了。対角線は空である。ある値から同じ値への「遷移」は遷移ではない。何もスケジュールされず、遅延も適用されない。シミュレータは遅延の機構に届く前にそれを捨てる。

Columns 0, 1 and z are uniform. Whatever the starting value, going to 1 costs $d_r$, going to 0 costs $d_f$, going to z costs $d_z$. That is just the §5.1 definition restated — the destination decides.0、1、z 這三欄是一致的。不管起始值是什麼，去 1 要 $d_r$，去 0 要 $d_f$，去 z 要 $d_z$。那不過是把 §5.1 的定義重述一遍 — 目的地決定一切。0、1、z の三列は一様である。開始値が何であれ、1 へ行くなら $d_r$、0 へ行くなら $d_f$、z へ行くなら $d_z$ である。これは §5.1 の定義の言い換えにすぎない — 行き先がすべてを決める。

The x column uses the minimum. This is the only interesting entry, and it is a deliberate pessimism choice. When a gate's output becomes unknown, the simulator does not know which physical transition is actually under way, so it assumes the output could become uncertain as early as any of them could take effect. Making the unknown window start at the earliest possible moment and (via the next transition's own delay) end at the latest possible moment produces the widest x region — which is the safe direction for a model whose purpose is to expose uncertainty rather than hide it.x 那一欄取最小值。這是唯一有趣的欄位，而且是刻意的悲觀選擇。當一個閘的輸出變成未知時，模擬器並不知道實際上正在進行的是哪一種物理轉態，所以它假設輸出可能在其中任何一種生效的最早時刻就變得不確定。讓未知視窗在最早的可能時刻開始，並（透過下一個轉態本身的延遲）在最晚的可能時刻結束，產生的 x 區域最寬 — 對一個目的在於暴露不確定性而非隱藏它的模型來說，那是安全的方向。x の列は最小値を使う。これが唯一興味深い項目であり、意図的な悲観の選択である。ゲートの出力が不定になるとき、実際に進行している物理的遷移がどれなのかシミュレータには分からない。そこで、どの遷移が効くにせよ、その中で最も早い時刻に出力が不確かになりうると仮定する。不定の窓を可能な限り早く始め、（次の遷移自身の遅延によって）可能な限り遅く終わらせれば、x の領域は最も広くなる — 不確かさを隠すのではなく露わにすることを目的とするモデルにとって、それが安全な方向である。

The one asymmetry is $d^{**}$, the x→z entry. With three delays specified, this is $d_z$ rather than the minimum, because going to z is unambiguously a turn-off event: whatever the output was before, the gate is switching off and the turn-off delay is the right physical number. With only two delays there is no $d_z$ to use, so it falls back to $\min(d_r, d_f)$.唯一不對稱的是 $d^{**}$，也就是 x→z 那一格。指定三個延遲時，它是 $d_z$ 而不是最小值，因為變成 z 毫無疑問就是一個關斷事件：不管輸出之前是什麼，這個閘正在關掉，而關斷延遲就是正確的物理數字。只指定兩個延遲時沒有 $d_z$ 可用，於是退回 $\min(d_r, d_f)$。唯一の非対称は $d^{**}$、すなわち x→z の項目である。遅延を三つ指定した場合、これは最小値ではなく $d_z$ になる。z へ行くことは紛れもなくターンオフの事象だからだ。出力が以前何であれ、ゲートは切れつつあり、ターンオフ遅延こそ正しい物理量である。遅延が二つしかなければ使える $d_z$ がないので、$\min(d_r, d_f)$ に戻る。

5.3 min:typ:max and how a triple is chosen5.3 min:typ:max，以及一組三元值是怎麼被選中的5.3 min:typ:max と、三つ組の選ばれ方

Every one of the one, two or three delay values may itself be written as a colon-separated triple min:typ:max. So the maximal gate delay specification carries nine numbers:一個、兩個或三個延遲值中的每一個，本身都可以寫成用冒號分隔的三元組 min:typ:max。所以最完整的閘延遲規格帶有九個數字：一つ、二つ、三つのいずれの遅延値も、それ自体をコロン区切りの三つ組 min:typ:max として書ける。したがって最大限のゲート遅延指定は九個の数値を持つ。

bufif1 #(3:4:5, 6:7:8, 5:8:9) (out, in, ctrl);
//       rise      fall     turn-off
//     min:typ:max  ...        ...

These correspond to the process/voltage/temperature corners the cell was characterised at: min is the fast corner (fast process, high voltage, often low temperature), typ the nominal silicon, max the slow corner. Exactly one of the three is used for a given simulation run, and the choice is made at elaboration time for the whole design, not per instance. Simulators expose it as a command-line switch:它們對應到該單元被特性化時的製程／電壓／溫度角落：min 是快角（快製程、高電壓，通常也是低溫），typ 是標稱矽，max 是慢角。每一次模擬只會用到三者之一，而且這個選擇是在 elaboration 時對整個設計一次決定的，不是逐實體決定。模擬器把它做成命令列開關：これらはセルが特性化されたプロセス／電圧／温度のコーナーに対応する。min は高速コーナー（高速プロセス、高電圧、多くは低温）、typ は公称シリコン、max は低速コーナーである。一回のシミュレーションで使われるのはそのうちちょうど一つであり、選択は設計全体についてエラボレーション時に行われる。インスタンスごとではない。シミュレータはこれをコマンドラインのスイッチとして提供している。

// typical invocation forms (tool-dependent)
vcs  +mindelays  ...        // use the first number of every triple
vcs  +typdelays  ...        // the default
vcs  +maxdelays  ...        // use the third number
vsim -t 1ps -sdfmax /dut=chip.sdf  ...

A detail that trips people up: if a triple is given in only some positions, the others still need to be well-formed. #(3:4:5, 6) is legal — the fall delay is 6 at every corner. And a single #3:4:5 with no parentheses applies that triple to all transitions.一個常絆倒人的細節：如果只在部分位置給了三元值，其餘位置仍必須寫得合法。#(3:4:5, 6) 是合法的 — 下降延遲在每個角落都是 6。而沒有括號的單一 #3:4:5 會把那組三元值套用到所有轉態。人をつまずかせる細部がある。一部の位置にだけ三つ組を書いた場合でも、残りの位置は正しい形でなければならない。#(3:4:5, 6) は合法である — 立ち下がり遅延はどのコーナーでも 6 だ。括弧のない単独の #3:4:5 は、その三つ組をすべての遷移に適用する。

5.4 Inertial delay, mechanically5.4 慣性延遲的機制5.4 慣性遅延の仕組み

"Gate delay is inertial" is usually stated and never explained. Here is the mechanism, in terms of the event queue from Lecture 2.「閘延遲是慣性的」這句話通常只被陳述而從不被解釋。以下是它的機制，用第 2 講的事件佇列來說明。「ゲート遅延は慣性である」は述べられるだけで説明されないことが多い。以下がその仕組みであり、第 2 講のイベントキューの言葉で述べる。

1. An input of the gate changes. The simulator evaluates the gate's function and obtains a candidate output value $v$.閘的某個輸入改變。模擬器對閘的函數求值，得到一個候選輸出值 $v$。ゲートの入力が変化する。シミュレータはゲートの関数を評価し、候補となる出力値 $v$ を得る。
2. If $v$ equals the value currently scheduled for the output (or the output's present value, when nothing is pending), nothing happens.如果 $v$ 等於目前已排程給該輸出的值（或在沒有待決事件時，等於輸出的現值），什麼都不會發生。$v$ がその出力に対してすでにスケジュールされている値（保留中のイベントがなければ出力の現在値）と等しければ、何も起こらない。
3. Otherwise the simulator computes the delay $d$ from the mapping table and wants to schedule "output becomes $v$" at time $t + d$.否則模擬器由對應表算出延遲 $d$，並打算在時間 $t + d$ 排程「輸出變成 $v$」。そうでなければ、シミュレータはマッピング表から遅延 $d$ を求め、時刻 $t + d$ に「出力が $v$ になる」をスケジュールしようとする。
4. Before scheduling, it looks for an event already pending on that output. If one exists and has not yet executed, that pending event is cancelled and replaced by the new one.在排程之前，它會先去找該輸出上已經待決的事件。如果有一個存在而且尚未執行，那個待決事件會被取消，由新的取代。スケジュールする前に、その出力に保留中のイベントがないかを探す。存在していてまだ実行されていなければ、その保留中のイベントは取り消され、新しいイベントに置き換えられる。

Step 4 is the entire inertial model. Nothing explicitly measures pulse width; the pulse-swallowing behaviour is an emergent property of "only one output transition may be in flight at a time, and the newest one wins".第 4 步就是慣性模型的全部。沒有任何地方明確量測脈衝寬度；吞掉脈衝的行為是「同一時間最多只能有一個輸出轉態在飛行中，而且最新的那個獲勝」所湧現出來的性質。手順 4 が慣性モデルのすべてである。パルス幅を明示的に測るところはどこにもない。パルスを飲み込む振る舞いは、「出力の遷移は同時に一つしか飛んでいられず、最新のものが勝つ」から創発する性質である。

Note the subtlety in the middle step: a pulse whose width is exactly equal to the delay lands on a tool-dependent boundary. In an exam, use "width $\lt$ delay ⇒ swallowed, width $\gt$ delay ⇒ passed" and say explicitly that the equality case is implementation-defined. In a design, never build anything that depends on a pulse of width equal to a cell delay.注意中間那一步的微妙之處：寬度恰好等於延遲的脈衝落在一個依工具而異的邊界上。考試時請用「寬度 $\lt$ 延遲 ⇒ 被吞掉、寬度 $\gt$ 延遲 ⇒ 通過」，並明白寫出相等的情況屬於實作定義。在設計中，絕對不要做出任何依賴「脈衝寬度等於單元延遲」的東西。中間の段階の微妙さに注意すること。幅がちょうど遅延に等しいパルスは、ツールに依存する境界に落ちる。試験では「幅 $\lt$ 遅延 ⇒ 飲み込まれる、幅 $\gt$ 遅延 ⇒ 通過する」を使い、等しい場合は実装依存であると明示すること。設計においては、セル遅延に等しい幅のパルスに依存するものを決して作らないこと。

5.5 Inertial versus transport5.5 慣性延遲與傳輸延遲的對照5.5 慣性遅延と伝送遅延の対比

The wide pulse (t = 2 to t = 10, width 8) survives both models identically: the output goes high at 6 and low at 14. The narrow pulse (t = 18 to t = 20, width 2) is where they diverge. Inertially, the rise scheduled for t = 22 is cancelled by the fall arriving at t = 20, and the output stays flat. With a transport delay the two edges are independent and both appear, shifted by 4.寬脈衝（t = 2 到 t = 10，寬度 8）在兩個模型下存活得一模一樣：輸出在 6 變高、在 14 變低。窄脈衝（t = 18 到 t = 20，寬度 2）才是兩者分道揚鑣的地方。在慣性模型下，排在 t = 22 的上升被 t = 20 抵達的下降取消，輸出保持平坦。在傳輸延遲下，兩個邊緣各自獨立，都會出現，只是平移了 4。幅の広いパルス（t = 2 から t = 10、幅 8）は両方のモデルでまったく同じように生き残る。出力は 6 で高く、14 で低くなる。両者が分かれるのは幅の狭いパルス（t = 18 から t = 20、幅 2）である。慣性モデルでは t = 22 に予定された立ち上がりが t = 20 に到着する立ち下がりによって取り消され、出力は平坦なままになる。伝送遅延では二つのエッジは独立で、どちらも 4 だけ移動して現れる。

5.6 Why inertial is the right default — and when it lies5.6 為什麼慣性延遲是正確的預設 — 以及它什麼時候在說謊5.6 なぜ慣性遅延が正しい既定値か — そしてそれが嘘をつくとき

Inertial delay is a model of a physical fact: a real gate has capacitance, and a pulse that does not last long enough to charge or discharge the output node does not produce a full-swing transition at the output. A 20 ps pulse at the input of a cell whose propagation delay is 60 ps genuinely does not appear at the output. Verilog's rule is a crude but correct first-order approximation of that.慣性延遲建模的是一個物理事實：真實的閘有電容，而一個持續時間不足以把輸出節點充飽或放完的脈衝，不會在輸出產生一次全擺幅的轉態。一顆傳播延遲為 60 ps 的單元，其輸入上的 20 ps 脈衝確實不會出現在輸出。Verilog 的規則是對此粗糙但正確的一階近似。慣性遅延がモデル化しているのは一つの物理的事実である。実際のゲートには容量があり、出力ノードを充電あるいは放電しきるだけ持続しないパルスは、出力にフルスイングの遷移を生じさせない。伝搬遅延 60 ps のセルの入力に現れた 20 ps のパルスは、実際に出力には現れない。Verilog の規則はそれに対する粗いが正しい一次近似である。

Where the model lies, and you should know these:這個模型在哪些地方說謊，你應該要知道：このモデルがどこで嘘をつくかは知っておくべきである。

• Real cells partially pass sub-threshold pulses. Silicon does not have a sharp cut-off at the propagation delay; a pulse slightly narrower than $t_{pd}$ produces an attenuated, slow-rising bump on the output that may still be enough to upset a downstream latch. Verilog's binary pass/swallow rule shows nothing. This is one reason glitch-related failures escape simulation and are caught only by SPICE or by silicon.真實的單元會部分地通過次臨界脈衝。矽晶片在傳播延遲處並沒有一個銳利的截止；一個比 $t_{pd}$ 稍窄的脈衝會在輸出產生一個衰減、上升緩慢的鼓包，而那仍可能足以擾亂下游的閂鎖器。Verilog 二元的「通過／吞掉」規則什麼都不會顯示。這是毛刺相關的失效能逃過模擬、只能靠 SPICE 或實際矽晶片抓到的原因之一。実際のセルはしきい値未満のパルスを部分的に通す。シリコンには伝搬遅延のところに鋭い遮断があるわけではない。$t_{pd}$ よりわずかに狭いパルスは、減衰しゆっくり立ち上がる膨らみを出力に生じさせ、それでも下流のラッチを乱すには十分なことがある。Verilog の二値的な通過／飲み込みの規則は何も示さない。グリッチ由来の不具合がシミュレーションをすり抜け、SPICE か実シリコンでしか捕まらない理由の一つがこれである。
• Glitch filtering hides hazards. A combinational network with a static-1 hazard produces a brief dip. If every cell in the path has a delay larger than the dip, the simulation shows a clean signal and the hazard is invisible. A zero-delay RTL simulation shows the glitch (as a zero-width event, which most waveform viewers also hide) and a post-layout simulation may or may not. If the glitch reaches an asynchronous reset or a latch enable, the chip fails and the simulation does not.毛刺濾除會藏起危障（hazard）。含有 static-1 hazard 的組合網路會產生一個短暫的凹陷。如果路徑上每一顆單元的延遲都大於那個凹陷，模擬就會顯示一條乾淨的訊號，危障完全看不見。零延遲的 RTL 模擬會顯示那個毛刺（以零寬度事件的形式，而多數波形檢視器同樣會把它藏起來），佈局後模擬則可能顯示、也可能不顯示。如果那個毛刺跑到非同步重置或閂鎖器的致能上，晶片會壞，而模擬不會。グリッチのフィルタはハザードを隠す。スタティック 1 ハザードを含む組み合わせ回路網は短いくぼみを生じる。経路上のすべてのセルの遅延がそのくぼみより大きければ、シミュレーションはきれいな信号を示し、ハザードはまったく見えない。ゼロ遅延の RTL シミュレーションはそのグリッチを（幅ゼロのイベントとして。多くの波形ビューアはこれも隠す）示し、レイアウト後シミュレーションは示すこともあれば示さないこともある。そのグリッチが非同期リセットやラッチのイネーブルに届けば、チップは壊れるのにシミュレーションは壊れない。
• Power estimation is undercounted. Switching power is proportional to toggle count. A swallowed pulse still consumed real charge in silicon up to the point where it was swallowed, but it contributes zero toggles to the VCD. Gate-level power numbers from an inertial simulation are optimistic for exactly this reason.功耗估算會被低估。切換功耗正比於翻轉次數。一個被吞掉的脈衝在矽晶片裡直到被吞掉為止仍然消耗了真實的電荷，但它對 VCD 的翻轉次數貢獻是零。閘層級模擬得出的功耗數字之所以偏樂觀，原因正是如此。消費電力の見積もりが過小になる。スイッチング電力はトグル数に比例する。飲み込まれたパルスも、飲み込まれるまでのあいだシリコン中では実際に電荷を消費しているが、VCD へのトグル数の寄与はゼロである。慣性シミュレーションから得られるゲートレベルの電力値が楽観的になるのは、まさにこの理由による。
• Zero-delay gates swallow nothing — and can hang. With no #, there is no pending event to cancel, so nothing is ever filtered. Combined with a combinational feedback loop this gives an infinite zero-delay oscillation that the simulator will chase forever within one time step. Adding any non-zero delay to one gate in the loop turns the hang into a visible ring.零延遲的閘什麼都不吞 — 而且可能掛住。沒有 # 就沒有待決事件可以取消，於是什麼都不會被濾掉。再配上一個組合回授迴路，就會得到一個無窮的零延遲振盪，模擬器會在同一個時間步裡永遠追著它跑。只要給迴路裡任一個閘加上非零延遲，掛死就變成看得見的振鈴。ゼロ遅延のゲートは何も飲み込まない — そしてハングしうる。# がなければ取り消すべき保留イベントがなく、したがって何もフィルタされない。これに組み合わせ帰還ループが加わると、無限のゼロ遅延発振となり、シミュレータは一つの時間ステップの中で永遠にそれを追い続ける。ループ中のどれか一つのゲートに非ゼロの遅延を与えれば、ハングは目に見えるリンギングに変わる。

6. Timescale, Precision and the Rounding Trap6. 時間刻度、精度，以及四捨五入的陷阱6. タイムスケール、精度、そして丸めの落とし穴

Every # in Verilog is a pure number. #3 means three time units, and nothing in the expression says what a time unit is. The `timescale compiler directive supplies the missing information, and because it is a compiler directive rather than a language construct, it behaves in ways that surprise people.Verilog 裡的每一個 # 都只是一個純數字。#3 表示三個時間單位，而表示式本身完全沒說一個時間單位是多少。`timescale 這個編譯指令補上了這段缺失的資訊，而由於它是編譯指令而不是語言結構，它的行為常讓人意外。Verilog の # はどれも純粋な数値にすぎない。#3 は三時間単位を意味するが、式のどこにも時間単位が何であるかは書かれていない。`timescale コンパイラ指令がこの欠けた情報を補う。そしてこれが言語構造ではなくコンパイラ指令であるため、その振る舞いは人を驚かせる。

6.1 Unit and precision6.1 單位與精度6.1 単位と精度

`timescale <time_unit> / <time_precision>
`timescale 1ns / 10ps       // #1 means 1 ns; delays are rounded to 10 ps
`timescale 10ps / 1ps       // #1 means 10 ps; delays are rounded to 1 ps

• The time unit is the multiplier applied to every delay number in the modules that follow.時間單位是套用到其後各模組中每一個延遲數字上的乘數。時間単位は、それ以降のモジュール中のすべての遅延数値に掛かる乗数である。
• The time precision is the granularity to which those products are rounded. It is also what determines how finely the simulator's time wheel is divided.時間精度是那些乘積被四捨五入到的粒度。它同時也決定了模擬器的時間輪被切得多細。時間精度は、それらの積を丸める粒度である。同時に、シミュレータのタイムホイールがどれだけ細かく分割されるかも決める。
• Both must be written as 1, 10 or 100 followed by one of s, ms, us, ns, ps, fs. There is no 2ns and no 0.5ns.兩者都必須寫成 1、10 或 100 後面接 s、ms、us、ns、ps、fs 之一。沒有 2ns，也沒有 0.5ns。いずれも 1、10、100 のあとに s、ms、us、ns、ps、fs のいずれかを続けて書かなければならない。2ns も 0.5ns も存在しない。
• The precision may not be coarser than the unit. `timescale 1ps/1ns is an error.精度不可以比單位粗。`timescale 1ps/1ns 是錯誤的。精度は単位より粗くてはならない。`timescale 1ps/1ns は誤りである。

6.2 Rounding happens at compile time, in the local module6.2 四捨五入發生在編譯期，而且在本地模組裡6.2 丸めはコンパイル時に、ローカルなモジュールで起こる

Two consequences follow immediately and both are exam material.立刻有兩個後果，而且兩個都是考試題材。ここから直ちに二つの帰結が出る。どちらも試験に出る材料である。

Rounding is permanent. Once #3.57 has been rounded to 36 ps it is 36 ps forever. A later module with finer precision cannot recover the 35.7. If you want a 35.7 ps delay you must declare a precision of 100 fs or better in the module where the delay is written.四捨五入是永久的。#3.57 一旦被捨入成 36 ps，它就永遠是 36 ps。後面某個精度更細的模組救不回那個 35.7。如果你要 35.7 ps 的延遲，就必須在寫下該延遲的那個模組裡宣告 100 fs 或更細的精度。丸めは恒久的である。#3.57 がいったん 36 ps に丸められたら、それは永遠に 36 ps である。あとからより細かい精度のモジュールが来ても 35.7 は取り戻せない。35.7 ps の遅延が欲しければ、その遅延を書くモジュールで 100 fs 以上に細かい精度を宣言しなければならない。

Rounding can round to zero. Under `timescale 1ns/1ns, the delay #0.4 becomes #0. The gate becomes a zero-delay gate: it no longer swallows any pulses, it no longer breaks feedback loops, and if it was there to fix a race it has silently stopped doing so. Under `timescale 1ns/1ns an entire sub-nanosecond cell library collapses to zero delay and your post-layout simulation becomes a (very slow) zero-delay simulation that happens to pass.四捨五入可能捨到零。在 `timescale 1ns/1ns 之下，延遲 #0.4 變成 #0。那個閘就變成零延遲閘：它不再吞掉任何脈衝，不再切斷回授迴路，而如果它原本是用來修正某個競態的，它已經默默地停止那麼做了。在 `timescale 1ns/1ns 之下，整座次奈秒的單元庫都塌成零延遲，你的佈局後模擬就變成一場（非常慢的）零延遲模擬，而且剛好會通過。丸めはゼロになりうる。`timescale 1ns/1ns のもとでは遅延 #0.4 は #0 になる。そのゲートはゼロ遅延のゲートになり、もうパルスを飲み込まず、帰還ループも断ち切らず、競合の修正のために置かれていたのなら黙ってその役目をやめている。`timescale 1ns/1ns のもとでは、サブナノ秒のセルライブラリ全体がゼロ遅延に潰れ、レイアウト後シミュレーションは（きわめて遅い）ゼロ遅延シミュレーションになり、しかもたまたま合格してしまう。

6.3 The two-module example, line by line6.3 兩個模組的例子，逐行解讀6.3 二つのモジュールの例を一行ずつ

`timescale 1 ns / 10 ps
module modA (y, x1, x2);
  input  x1, x2;
  output y;
  nand #(3.225, 4.237) (y, x1, x2);
endmodule

`timescale 10 ns / 10 ns
module modB ();
  reg  x1, x2;
  wire y;
  modA M1 (y, x1, x2);

  initial
    $monitor($time, " %f x1=%b x2=%b y=%b",
             $realtime, x1, x2, y);

  initial begin
    #5 x1 = 0; x2 = 0;
    #5 x2 = 1;
    #5 x1 = 1;
    #5 x2 = 0;
  end
endmodule

$time   $realtime    x1    x2    y
-------------------------------------
   0     0.000000   x=x   x=x   y=x
   5     5.000000   x1=0  x2=0  y=x
   5     5.323000   x1=0  x2=0  y=1
  10    10.000000   x1=0  x2=1  y=1
  15    15.000000   x1=1  x2=1  y=1
  15    15.424000   x1=1  x2=1  y=0
  20    20.000000   x1=1  x2=0  y=0
  20    20.323000   x1=1  x2=0  y=1

Work the numbers.把數字算一遍。数値を追ってみる。

Notice what the example proves: the delay numbers were interpreted in modA's timescale, while the reported times are in modB's. Those are two different modules with two different timescales, and the simulator reconciles them through a single absolute time axis whose resolution is the finest precision anywhere in the design — here 10 ps.注意這個例子證明了什麼：延遲數字是以 modA 的時間刻度解讀的，而回報的時間卻是以 modB 的單位。那是兩個時間刻度不同的模組，而模擬器透過單一的絕對時間軸把它們調和起來，那條時間軸的解析度是設計中任何一處最細的精度 — 這裡是 10 ps。この例が何を証明しているかに注意すること。遅延の数値は modA のタイムスケールで解釈され、報告される時刻は modB の単位である。タイムスケールの異なる二つのモジュールであり、シミュレータは単一の絶対時間軸を介して両者を調停する。その時間軸の分解能は、設計中のどこかにある最も細かい精度 — ここでは 10 ps — である。

6.4 $time versus $realtime6.4 $time 與 $realtime 的對照6.4 $time と $realtime の対比

Both are scaled to the caller's unit; only $time rounds. In the example, the event at absolute 53.23 ns is reported by $time as 5 (because $5.323$ rounds to 5) and by $realtime as 5.323000. An event at 57 ns would be reported by $time as 6, not 5 — the standard says round, not truncate, and students who assume truncation get the boundary cases wrong.兩者都換算到呼叫者的單位；只有 $time 會四捨五入。在那個例子裡，絕對時間 53.23 ns 的事件被 $time 回報成 5（因為 $5.323$ 捨入成 5），被 $realtime 回報成 5.323000。發生在 57 ns 的事件會被 $time 回報成 6 而不是 5 — 標準說的是四捨五入，不是截斷，而假設是截斷的學生會把邊界情況做錯。どちらも呼び出し側の単位にスケールされるが、丸めるのは $time だけである。先の例では、絶対時間 53.23 ns の事象を $time は 5 と報告し（$5.323$ が 5 に丸められるため）、$realtime は 5.323000 と報告する。57 ns の事象は $time では 5 ではなく 6 と報告される — 標準が言うのは四捨五入であって切り捨てではない。切り捨てだと思い込んだ学生は境界の場合を間違える。

The practical advice: use %t with $timeformat rather than $time with %d. The combination實務上的建議：用 %t 搭配 $timeformat，而不是用 $time 搭配 %d。這個組合実務上の助言：$time と %d の組み合わせではなく、%t と $timeformat を使うこと。この組み合わせは

initial $timeformat(-12, 2, " ps", 10);   // units of 1e-12, 2 decimals, suffix, min field width
...
$display("%t : q = %b", $realtime, q);

prints absolute time in a fixed unit regardless of which module does the printing, which eliminates the entire class of "why does my log say 5 when the waveform says 53 ns" confusion.會以固定的單位印出絕對時間，不論印的是哪個模組，這就消除了「為什麼我的 log 寫 5 而波形寫 53 ns」這一整類的困惑。どのモジュールが印字しても固定の単位で絶対時間を出力する。「なぜログは 5 なのに波形は 53 ns なのか」という類の混乱がまるごと消える。

6.5 Cross-file hazards: why timescale silently changes results6.5 跨檔案的危險：為什麼 timescale 會默默改變結果6.5 ファイルをまたぐ危険：なぜタイムスケールは黙って結果を変えるのか

`timescale is a compiler directive, and compiler directives are not scoped to a file, a module, or anything else. They take effect from the point they are read until they are overridden or until `resetall. The consequences:`timescale 是一個編譯指令，而編譯指令的作用範圍不受檔案、模組或任何東西限制。它們從被讀到的那一點開始生效，直到被覆蓋，或直到遇上 `resetall。後果如下：`timescale はコンパイラ指令であり、コンパイラ指令はファイルにもモジュールにも、何にもスコープされない。読み込まれた地点から効力を持ち、上書きされるか `resetall に出会うまで続く。その帰結は次のとおりである。

• A file without a `timescale inherits the last one the compiler saw — which depends on the order the files were given on the command line. Change the order of two files in a Makefile and the delays in one of them change. This is the mechanism behind "it worked yesterday" bugs that survive a clean rebuild.沒有 `timescale 的檔案會繼承編譯器看到的最後一個 — 而那取決於命令列上給檔案的順序。把 Makefile 裡兩個檔案的順序調換，其中一個檔案裡的延遲就會改變。這就是那種「昨天還好好的」、而且重新乾淨建置也不會消失的錯誤背後的機制。`timescale のないファイルは、コンパイラが最後に見たものを引き継ぐ — そしてそれはコマンドラインでファイルを並べた順序に依存する。Makefile 中の二つのファイルの順序を入れ替えれば、一方のファイルの遅延が変わる。クリーンビルドしても消えない「昨日は動いていた」系のバグの仕組みがこれである。
• If no module in the design has a `timescale and some do, the standard says the behaviour is an error; most tools issue a warning and apply a default such as 1 ns / 1 ns, which is usually wrong for a cell library.如果設計中有些模組有 `timescale 而有些完全沒有，標準說這個行為是錯誤；多數工具會發出警告並套用某個預設值，例如 1 ns / 1 ns，而那對單元庫來說通常是錯的。設計中に `timescale を持つモジュールと持たないモジュールが混在する場合、標準はこれをエラーとしている。多くのツールは警告を出して 1 ns / 1 ns のような既定値を適用するが、それはセルライブラリにとってたいてい誤りである。
• The global simulation precision is the minimum of all precisions in the design. One file declaring 1fs precision forces the whole time wheel to femtoseconds. It does not make the other modules' delays more accurate — they were already rounded — but it does make the simulation consume more memory and run slower, sometimes dramatically.全域的模擬精度是設計中所有精度的最小值。只要有一個檔案宣告 1fs 精度，整個時間輪就被迫以飛秒為刻度。這並不會讓其他模組的延遲更準確 — 它們早就被捨入過了 — 但確實會讓模擬吃掉更多記憶體、跑得更慢，有時慢得非常明顯。全体のシミュレーション精度は、設計中のすべての精度の最小値である。一つのファイルが 1fs の精度を宣言しただけで、タイムホイール全体がフェムト秒刻みになる。それで他のモジュールの遅延が正確になるわけではない — すでに丸められている — が、シミュレーションのメモリ消費は増え、実行は遅くなる。ときに劇的に遅くなる。
• `resetall restores every directive to its default, including clearing the timescale. Putting `resetall at the top of a library file and a fresh `timescale immediately after it is the defensive idiom; the risk is that `resetall also discards all macros defined so far, so it belongs only in self-contained library files, never in the middle of a design.`resetall 會把每一個指令都還原成預設值，包括清掉 timescale。在單元庫檔案最前面放 `resetall、緊接著放一個新的 `timescale，是防禦性的慣用寫法；風險在於 `resetall 也會丟掉目前為止定義的所有巨集，所以它只屬於自給自足的單元庫檔案，絕不該出現在設計的中間。`resetall はすべての指令を既定値に戻す。タイムスケールのクリアも含まれる。ライブラリファイルの先頭に `resetall を置き、その直後に新しい `timescale を置くのが防御的な定石である。リスクは `resetall がそれまでに定義されたマクロもすべて破棄することで、したがってこれは自己完結したライブラリファイルにのみ属し、設計の途中に置いてはならない。
• Most simulators offer a command-line override (-timescale=1ns/1ps in VCS, -timescale in Questa, -t 1ps to force the resolution). Using it is a reasonable safety net, but it masks a missing directive rather than fixing it.多數模擬器提供命令列覆寫（VCS 的 -timescale=1ns/1ps、Questa 的 -timescale、用 -t 1ps 強制解析度）。用它當安全網是合理的，但它掩蓋了缺漏的指令，而不是修好它。多くのシミュレータはコマンドラインでの上書きを提供している（VCS の -timescale=1ns/1ps、Questa の -timescale、分解能を強制する -t 1ps など）。安全網として使うのは妥当だが、それは欠けた指令を隠すのであって直すのではない。

7. Net Delay: Delay That Belongs to the Wire7. net 延遲：屬於導線的延遲7. net 遅延：配線に属する遅延

7.1 Three things that look alike and are not7.1 三種長得很像、其實不同的東西7.1 似て非なる三つの書き方

A delay written near a net can mean three different things depending on where exactly it sits. Getting them confused is the single most common cause of wrong answers in this part of the course.寫在 net 附近的延遲，會依它確切坐落的位置而有三種不同的意義。把它們搞混，是課程這個部分答錯的最常見單一原因。net の近くに書かれた遅延は、正確にどこに置かれているかによって三つの異なる意味を持つ。これらを取り違えることが、この単元で答えを間違える最大の原因である。

wire #2 w;                      // (1) NET DELAY on a plain net declaration
wire #5 y = a ^ b;              // (2) NET DECLARATION ASSIGNMENT: the delay belongs to the assignment
wire z;
assign #3 z = a ^ b;            // (3) CONTINUOUS ASSIGNMENT delay: belongs to the driver

Form (2) is the trap. wire #5 y = a ^ b; looks as though it declares a net with a 5-unit delay and drives it, but the standard says the delay in a net declaration assignment belongs to the assignment. The net contributes zero. That is the whole content of the my_xor1 / my_xor2 comparison in §7.3.寫法 (2) 是陷阱。wire #5 y = a ^ b; 看起來好像同時宣告了一條有 5 單位延遲的 net 並且驅動它，但標準說 net 宣告指定中的延遲屬於那個指定。net 的貢獻是零。這就是 §7.3 中 my_xor1 / my_xor2 比較的全部內容。罠なのは書き方 (2) である。wire #5 y = a ^ b; は 5 単位の遅延を持つ net を宣言しかつそれを駆動しているように見えるが、標準は net 宣言代入における遅延は代入に属すると定めている。net の寄与はゼロだ。§7.3 の my_xor1 と my_xor2 の比較は、まるごとこの内容である。

Net delays are also where a subtlety about multiple drivers appears. If three drivers contend for one net, the net's resolution function runs first and the resolved value is then delayed. A net delay is not per-driver; it is one delay on one wire. A gate delay, by contrast, is per-instance.net 延遲也是多驅動器那個微妙之處浮現的地方。如果三個驅動器搶同一條 net，net 的解析函數會先執行，然後被延遲的是解析後的值。net 延遲不是逐驅動器的；它是一條導線上的一個延遲。相對地，閘延遲是逐實體的。net 遅延は、複数ドライバに関する微妙な点が表れる場所でもある。三つのドライバが一つの net を奪い合う場合、まず net の解決関数が走り、遅延されるのは解決後の値である。net 遅延はドライバごとではなく、一本の配線に対する一つの遅延である。対照的にゲート遅延はインスタンスごとである。

7.2 The slide waveform, built from first principles7.2 從第一原理重建講義的波形7.2 スライドの波形を原理から組み立てる

wire #2 y_tran;                     // the net carries its own 2-unit delay
and  #3 (y_tran,    x1, x2);        // gate delay 3, then the net adds 2
buf  #1 (buf_out,   y_tran);        // a further 1 after the net
and  #3 (y_inertial, x1, x2);       // identical gate, but on a plain net

The figure is the clearest statement of the composition rule in the whole lecture: delays on a path add. Gate, then net, then the next gate, then the next net. There is no interaction term, no maximum, no resolution — just a sum along the path.這張圖是整場講義中對組合規則最清楚的陳述：路徑上的延遲相加。閘、然後 net、然後下一個閘、然後下一條 net。沒有交互項、沒有取最大值、沒有解析 — 就只是沿著路徑求和。この図は、講義全体を通じて合成規則を最も明確に述べたものである。経路上の遅延は加算される。ゲート、次に net、次のゲート、次の net。相互作用項もなく、最大値を取ることもなく、解決もない — 経路に沿った単なる和である。

7.3 my_xor1 versus my_xor27.3 my_xor1 與 my_xor2 的對照7.3 my_xor1 と my_xor2

module my_xor1 (y_out, a, b);
  input  a, b;
  output y_out;
  parameter driver_delay = 5;

  wire #driver_delay y_out = a ^ b;
endmodule

module my_xor2 (y_out, a, b);
  input  a, b;
  output y_out;
  parameter wire_delay   = 5;
  parameter driver_delay = 3;

  wire #wire_delay y_out;
  assign #driver_delay y_out = a ^ b;
endmodule

Why does the language make this distinction instead of always adding? Because a net declaration assignment is syntactic sugar for a declaration plus an assign, and it is defined to expand to the version where the delay lands on the assignment. There is simply no syntax in form (2) for a separate net delay. If you want both, you must write both, which is exactly what my_xor2 does.語言為什麼要做這個區分，而不是一律相加？因為 net 宣告指定是「宣告加上一個 assign」的語法糖，而它被定義成展開為「延遲落在指定上」的那個版本。寫法 (2) 裡根本沒有任何語法可以表達獨立的 net 延遲。如果你兩者都要，就必須兩者都寫，而那正是 my_xor2 做的事。なぜ言語は常に加算するのではなく、この区別を設けたのか。net 宣言代入は「宣言＋assign」の構文糖であり、遅延が代入に付く版へ展開されると定義されているからである。書き方 (2) には、独立した net 遅延を表す構文がそもそも存在しない。両方が欲しければ両方書くしかなく、それがまさに my_xor2 のしていることである。

One more wrinkle worth knowing: the inertial filtering happens at the driver, with the driver's delay as the effective window. In my_xor2 a 4-unit pulse on a ^ b survives the 3-unit assignment delay and then is shifted by the net, arriving as a 4-unit pulse at t+8. A 2-unit pulse is swallowed by the assignment delay and never reaches the net at all. The net's own 5 units play no part in deciding what survives.還有一個值得知道的皺摺：慣性濾除發生在驅動器處，有效視窗是驅動器的延遲。在 my_xor2 裡，a ^ b 上一個 4 單位的脈衝通得過 3 單位的指定延遲，接著被 net 平移，在 t+8 以 4 單位的脈衝抵達。2 單位的脈衝則被指定延遲吞掉，根本到不了那條 net。net 自己的那 5 個單位對「什麼能存活」毫無發言權。もう一つ知っておく価値のある細部がある。慣性フィルタはドライバのところで起こり、有効な窓はドライバの遅延である。my_xor2 では、a ^ b 上の 4 単位のパルスは 3 単位の代入遅延を通過し、その後 net によって平行移動され、t+8 に 4 単位のパルスとして到着する。2 単位のパルスは代入遅延に飲み込まれ、net には届きもしない。net 自身の 5 単位は、何が生き残るかの判断に一切関与しない。

7.4 Net delay in a real post-layout netlist7.4 真實佈局後網表中的 net 延遲7.4 実際のレイアウト後ネットリストにおける net 遅延

Open a netlist that a place-and-route tool has written and you will find no net delays at all. Every wire is a plain wire. This confuses people who expect the interconnect RC delay to be in the Verilog.打開一份佈局繞線工具寫出來的網表，你會發現裡面根本沒有 net 延遲。每一條導線都是普通的 wire。這讓期待在 Verilog 裡看到繞線 RC 延遲的人很困惑。配置配線ツールが書き出したネットリストを開いても、net 遅延は一つも見つからない。配線はすべて素の wire である。配線 RC 遅延が Verilog の中にあると思っている人は、ここで戸惑う。

It is not, because it cannot be: the netlist is written once and must serve every corner and every annotation scenario. The interconnect delays live in a separate SDF (Standard Delay Format) file, as INTERCONNECT entries:它不在裡面，而且也不可能在：網表只寫一次，卻必須服務每一個角落與每一種標註情境。繞線延遲活在另一個 SDF（Standard Delay Format）檔案裡，以 INTERCONNECT 條目的形式存在：入っていないし、入れられもしない。ネットリストは一度だけ書き出され、しかもあらゆるコーナーとあらゆるアノテーションの場面に供しなければならないからだ。配線遅延は別の SDF（Standard Delay Format）ファイルに INTERCONNECT 項目として存在する。

// fragment of an SDF file
(CELL (CELLTYPE "top")
  (INSTANCE)
  (DELAY (ABSOLUTE
    (INTERCONNECT u1/Z u2/A (0.012:0.018:0.031) (0.014:0.021:0.036))
    (INTERCONNECT u1/Z u3/A (0.009:0.013:0.022) (0.010:0.015:0.026))
  ))
)

When the simulator reads this through $sdf_annotate, it installs a delay on the path from one driver pin to one load pin. Notice that u1/Z drives both u2/A and u3/A with different delays — a single net with two different arrival times at its two loads. A Verilog wire #d cannot express that; it is one delay for the whole net. The simulator implements SDF interconnect delays with a mechanism called MIPD (module input port delay), which attaches the delay to the receiving module's input port rather than to the net.當模擬器透過 $sdf_annotate 讀進這份檔案時，它會在某個驅動腳位到某個負載腳位的路徑上裝上一個延遲。注意 u1/Z 同時驅動 u2/A 與 u3/A，而兩者的延遲不同 — 同一條 net 在它的兩個負載上有兩個不同的到達時間。Verilog 的 wire #d 無法表達這件事；它是整條 net 一個延遲。模擬器用一種稱為 MIPD（module input port delay，模組輸入埠延遲）的機制來實作 SDF 的繞線延遲，把延遲掛在接收端模組的輸入埠上，而不是掛在 net 上。シミュレータが $sdf_annotate を通じてこれを読み込むと、あるドライバピンからある負荷ピンまでの経路に遅延が取り付けられる。u1/Z が u2/A と u3/A を異なる遅延で駆動していることに注意 — 一本の net が二つの負荷で二つの異なる到着時刻を持つのである。Verilog の wire #d はこれを表現できない。net 全体に対する一つの遅延だからだ。シミュレータは SDF の配線遅延を MIPD（module input port delay、モジュール入力ポート遅延）と呼ばれる仕組みで実装し、遅延を net ではなく受け側モジュールの入力ポートに付ける。

(a) wire #4 p = a & b;

(b) wire #4 q;
    assign #6 q = a & b;

(c) wire #4 r;
    and  #6 (r, a, b);
    buf  #1 (s, r);

(d) wire #(3, 7) t;
    assign #(2, 5) t = a & b;

8. Module Path Delay and the specify Block8. 模組路徑延遲與 specify 區塊8. モジュールパス遅延と specify ブロック

8.1 Why a third layer exists at all8.1 為什麼需要第三層8.1 そもそもなぜ第三の層があるのか

If gate and net delays already add up along a path, why does the language need a third mechanism? Three reasons, and they are all about the gap between how a model is written and how a cell is characterised.如果閘延遲與 net 延遲本來就會沿路徑相加，語言為什麼還需要第三種機制？有三個理由，而且全都關於「模型是怎麼寫的」與「單元是怎麼特性化的」之間的落差。ゲート遅延と net 遅延がすでに経路に沿って加算されるのなら、なぜ言語に第三の仕組みが要るのか。理由は三つあり、いずれもモデルの書かれ方とセルの特性化のされ方のあいだの隔たりに関わる。

First, a behavioural model has no gates to hang delays on. The lecture states this directly: "in structural descriptions, module delays can be obtained by tracing gate and net delays; in behavioural descriptions, module paths can be described separately". A RAM model written as an array and an always block has no internal structure at all, yet it still has an access time from address to data-out. A module path is the only way to express that.第一，行為式模型沒有閘可以掛延遲。講義直接說了：「在結構化描述中，模組延遲可以由追蹤閘延遲與 net 延遲得到；在行為描述中，模組路徑必須另外描述。」一個寫成陣列加上 always 區塊的 RAM 模型，內部完全沒有結構，但它仍然有一個從位址到資料輸出的存取時間。模組路徑是表達那件事的唯一方式。第一に、動作記述のモデルには遅延を掛ける先のゲートがない。講義は直截にこう述べている。「構造記述ではモジュールの遅延はゲート遅延と net 遅延をたどって得られる。動作記述ではモジュールパスを別途記述する」。配列と always ブロックで書かれた RAM モデルには内部構造がまったくないが、それでもアドレスからデータ出力までのアクセス時間は存在する。それを表現できるのはモジュールパスだけである。

Second, characterisation is pin-to-pin. When a library vendor characterises a NAND cell in SPICE, the measured quantity is "time from the 50% point of A to the 50% point of Z, with B held at 1, under a specified input slew and output load". That is a pin-to-pin number — a timing arc — and it is what appears in the .lib file, in the SDF, and in every static-timing report. Module paths are the Verilog spelling of exactly the same object, which is why the mapping from SDF to specify is one to one.第二，特性化本來就是腳對腳的。當單元庫供應商用 SPICE 特性化一顆 NAND 單元時，量到的是「在指定的輸入斜率與輸出負載下，B 維持 1，從 A 的 50% 點到 Z 的 50% 點的時間」。那是一個腳對腳的數字 — 一條時序弧（timing arc） — 也正是出現在 .lib 檔、SDF 以及每一份靜態時序報告裡的東西。模組路徑就是同一個物件在 Verilog 裡的寫法，這也是為什麼 SDF 與 specify 的對應是一對一的。第二に、特性化はもともとピン間で行われる。ライブラリベンダが NAND セルを SPICE で特性化するとき、測られるのは「指定された入力スルーと出力負荷のもと、B を 1 に保ったまま、A の 50% 点から Z の 50% 点までの時間」である。これはピン間の数値 — 一本のタイミングアーク — であり、.lib ファイルにも SDF にも、あらゆる静的タイミングレポートにも現れるものだ。モジュールパスはまったく同じ対象の Verilog における綴りであり、だからこそ SDF と specify の対応は一対一になる。

Third, back-annotation needs a named handle. An SDF IOPATH A Z (...) entry has to find something in the simulation model to modify. It finds the (A => Z) path in the specify block. A cell model without a specify block is invisible to SDF annotation: the annotator issues "no matching path" warnings and the cell simulates at whatever delay its internal gates happen to carry, which for a typical library model is zero. A post-layout simulation of a netlist whose cells lack specify blocks is a zero-delay simulation wearing a disguise.第三，反標註需要一個具名的把手。一條 SDF 的 IOPATH A Z (...) 條目必須在模擬模型裡找到某個東西來修改。它找到的就是 specify 區塊裡的 (A => Z) 路徑。沒有 specify 區塊的單元模型對 SDF 標註而言是隱形的：標註器會丟出「找不到對應路徑」的警告，而那顆單元就以它內部閘恰好帶著的延遲去模擬 — 對典型的單元庫模型來說那是零。一份單元缺少 specify 區塊的網表，它的佈局後模擬只是一場喬裝過的零延遲模擬。第三に、バックアノテーションには名前の付いた取っ手が要る。SDF の IOPATH A Z (...) 項目は、書き換える対象をシミュレーションモデルの中に見つけなければならない。見つけるのが specify ブロック内の (A => Z) パスである。specify ブロックを持たないセルモデルは SDF アノテーションから見えない。アノテータは「一致するパスがない」と警告を出し、そのセルは内部のゲートがたまたま持っている遅延で — 典型的なライブラリモデルではゼロで — シミュレートされる。セルに specify ブロックのないネットリストのレイアウト後シミュレーションは、変装したゼロ遅延シミュレーションにすぎない。

8.2 specify, endspecify and specparam8.2 specify、endspecify 與 specparam8.2 specify、endspecify、specparam

module norf201 (O, A1, B1);
  output O;
  input  A1, B1;

  nor (O, A1, B1);                 // the function: a zero-delay primitive

  specify                          // the timing: module paths
    (A1, B1 *> O) = (0.1:0.3:0.8, 0.1:0.2:0.5);
  //                 ^ rising (min:typ:max)  ^ falling (min:typ:max)
  endspecify
endmodule

Note the division of labour, which is the standard-cell modelling idiom: the primitive carries the function with no delay, and the specify block carries all the timing. That separation is what makes SDF annotation work — the annotator rewrites the specify numbers and never touches the function.注意這裡的分工，那正是標準單元建模的慣用法：原型只承載功能而沒有延遲，specify 區塊承載全部的時序。那個切分正是讓 SDF 標註能運作的原因 — 標註器改寫 specify 裡的數字，而從不碰功能。ここでの分業に注意すること。これが標準セルモデリングの定石である。プリミティブは遅延を持たず機能だけを担い、specify ブロックがすべてのタイミングを担う。この分離こそ SDF アノテーションを成立させている — アノテータは specify の数値を書き換え、機能には決して触れない。

A specify block may contain only four kinds of item: specparam declarations, module path declarations, pulse-control declarations (pulsestyle_*, showcancelled), and timing checks ($setup and friends). No always, no assign, no instances.一個 specify 區塊只能包含四類項目：specparam 宣告、模組路徑宣告、脈衝控制宣告（pulsestyle_*、showcancelled），以及時序檢查（$setup 那一家人）。不能有 always、不能有 assign、不能有實體。specify ブロックに置けるのは四種類の項目だけである。specparam 宣言、モジュールパス宣言、パルス制御宣言（pulsestyle_*、showcancelled）、そしてタイミングチェック（$setup とその仲間）である。always も assign もインスタンスも置けない。

module nand1 (O, A, B);
  input  A, B;
  output O;
  nand (O, A, B);
  specify
    specparam                      // local to this specify block
      T01 = 1.13:3.09:7.75,        // 0->1 at the output
      T10 = 0.93:2.50:7.34;        // 1->0 at the output
    (A => O) = (T01, T10);
    (B => O) = (T01, T10);
  endspecify
endmodule

specparam versus parameterspecparam 與 parameter 的對照specparam と parameter の対比

The important row is "overridden by SDF annotation". Timing numbers are meant to be replaced wholesale after layout, and specparam is the construct that is designed to be replaced. Writing path delays in terms of ordinary parameters works in a pure simulation but puts you outside the annotation path, which is why no library does it.重要的是「被 SDF 標註覆蓋」那一列。時序數字本來就該在佈局後被整批取代，而 specparam 正是為了被取代而設計的結構。用普通的 parameter 來寫路徑延遲在純模擬裡行得通，卻會讓你脫離標註路徑，這就是為什麼沒有任何單元庫那樣做。重要なのは「SDF アノテーションに上書きされる」の行である。タイミングの数値はレイアウト後にまとめて置き換えられるべきものであり、specparam はまさに置き換えられるために設計された構文である。通常の parameter でパスの遅延を書いても純粋なシミュレーションでは動くが、アノテーションの経路から外れてしまう。どのライブラリもそうしないのはこのためだ。

The PATHPULSE$ family (§8.6) are also specparams — they are declared with the specparam keyword and have a reserved name. That is why the slide shows them inside a specparam declaration list.PATHPULSE$ 家族（§8.6）同樣是 specparam — 它們以 specparam 關鍵字宣告，並帶有保留名稱。這就是為什麼投影片把它們畫在 specparam 宣告串列裡。PATHPULSE$ の一族（§8.6）も specparam である。specparam キーワードで宣言され、予約された名前を持つ。スライドがそれらを specparam 宣言のリストの中に示しているのはこのためである。

8.3 Parallel (=>) versus full (*>) connection8.3 平行連接（=>）與全連接（*>）8.3 並列接続（=>）と全接続（*>）

(A1 => OA) = (2, 3);
(B1 => OB) = (2, 3);

// for vectors, bit i to bit i:
//   A1[3] -> OA[3]
//   A1[2] -> OA[2]  ... etc
// source and destination MUST be
// the same width

(A1, B1 *> O) = (2, 3);

// every bit of every source to
// every bit of every destination:
//   A1[i] -> O[j] for all i, j
//   B1[i] -> O[j] for all i, j
// widths need not match

A concrete consequence: (a[7:0] *> y[7:0]) = 1; creates 64 arcs, whereas (a[7:0] => y[7:0]) = 1; creates 8. For an 8-bit buffer the parallel form is correct and the full form is both wrong (it claims bit 0 of the input affects bit 7 of the output) and 8 times more expensive. For an 8-bit adder the full form is right, because every input bit really can affect every output bit through the carry chain. Choosing the wrong one does not usually change simulation results — the delay numbers are often identical — but it bloats the model and it corrupts any tool that reads the arc structure.一個具體的後果：(a[7:0] *> y[7:0]) = 1; 會建立 64 條弧，而 (a[7:0] => y[7:0]) = 1; 只建立 8 條。對一個 8 位元緩衝器而言平行形式才正確，全連接形式既錯誤（它主張輸入的第 0 位元會影響輸出的第 7 位元）又貴上 8 倍。對一個 8 位元加法器而言全連接形式才對，因為每一個輸入位元確實可以經由進位鏈影響每一個輸出位元。選錯通常不會改變模擬結果 — 延遲數字往往一樣 — 但它會把模型撐大，也會把任何讀取弧結構的工具搞壞。具体的な帰結がある。(a[7:0] *> y[7:0]) = 1; は 64 本のアークを作り、(a[7:0] => y[7:0]) = 1; は 8 本しか作らない。8 ビットのバッファには並列形式が正しく、全接続形式は誤りであり（入力のビット 0 が出力のビット 7 に影響すると主張してしまう）、しかも 8 倍高価である。8 ビット加算器には全接続形式が正しい。キャリーチェーンを通じて、どの入力ビットもどの出力ビットに本当に影響しうるからだ。選択を誤ってもシミュレーション結果はたいてい変わらない — 遅延の数値は同じであることが多い — が、モデルは肥大し、アーク構造を読むツールは壊れる。

The slide also states the legality rules for path endpoints, and one of them is wrong:投影片同時也給出了路徑端點的合法性規則，而其中一條是錯的：スライドはパス端点の適法性の規則も述べているが、そのうち一つは誤っている。

8.4 State-dependent paths8.4 狀態相依路徑8.4 状態依存パス

A state-dependent path exists only while a condition holds:狀態相依路徑只有在某個條件成立時才存在：状態依存パスは、ある条件が成り立っているあいだだけ存在する。

specify
  if (enable)     (data *> q) = (3, 4);   // transparent: data reaches q in 3/4
  if (!enable)    (data *> q) = (0, 0);   // opaque: no path (or model it away entirely)
endspecify

Why a latch needs this: a transparent latch has a data-to-Q arc only while the enable is high. When the enable is low there is no arc at all, because the data input cannot influence the output. Static timing analysis makes exactly the same distinction, and the .lib file records it as a "when" condition on the arc. The if in a specify block is the Verilog spelling of the Liberty when attribute.為什麼閂鎖器需要它：透通的閂鎖器只有在致能為高時才有一條 data 到 Q 的弧。致能為低時根本沒有弧，因為資料輸入無法影響輸出。靜態時序分析做的正是同樣的區分，而 .lib 檔把它記錄成弧上的一個 "when" 條件。specify 區塊裡的 if 就是 Liberty when 屬性在 Verilog 裡的寫法。ラッチにこれが要る理由はこうだ。透過ラッチに data から Q へのアークがあるのはイネーブルが高いあいだだけである。イネーブルが低いときはアーク自体が存在しない。データ入力が出力に影響できないからだ。静的タイミング解析もまったく同じ区別をしており、.lib ファイルはそれをアークの "when" 条件として記録する。specify ブロックの if は、Liberty の when 属性の Verilog における綴りである。

The condition may use module inputs, inouts, locally declared nets and registers, and constants, combined with the usual operators. It may not reference anything outside the module, and it is evaluated continuously — if the condition changes while a transition is in flight, the delay that was selected when the transition started is the one that is used.這個條件可以使用模組的輸入、inout、區域宣告的 net 與暫存器，以及常數，並用一般的運算子組合起來。它不能引用模組以外的任何東西，而且是持續求值的 — 如果某個轉態還在飛行途中而條件改變了，實際採用的是那個轉態開始時所選中的延遲。この条件にはモジュールの入力、inout、ローカルに宣言された net とレジスタ、および定数を、通常の演算子で組み合わせて使える。モジュールの外にあるものは参照できない。条件は継続的に評価され、遷移が飛行中に条件が変わった場合は、遷移が始まった時点で選ばれた遅延が使われる。

Verilog-2001 adds ifnone for the default case:Verilog-2001 為預設情況加上了 ifnone：Verilog-2001 は既定の場合のために ifnone を追加した。

specify
  if (sel)  (a => y) = 2;
  if (!sel) (a => y) = 4;
  ifnone    (a => y) = 3;    // used when sel is x or z: no state-dependent path matches
endspecify

Without ifnone, a condition that evaluates to x leaves no applicable path and the simulator falls back to whatever distributed delay the module has — usually zero. ifnone closes that hole. A specify block may contain at most one ifnone path per source/destination pair, and it may not coexist with a plain unconditional path for the same pair.沒有 ifnone 時，一個求值為 x 的條件會使得沒有任何路徑適用，於是模擬器退回使用模組所具有的分布延遲 — 通常是零。ifnone 把那個洞補起來。一個 specify 區塊中，每一對來源／目的最多只能有一條 ifnone 路徑，而且它不能與同一對端點的無條件路徑並存。ifnone がないと、条件が x に評価された場合に適用できるパスがなくなり、シミュレータはモジュールが持つ分布遅延 — たいていゼロ — に戻ってしまう。ifnone はその穴を塞ぐ。一つの specify ブロックにおいて、始点／終点の組ごとに ifnone パスは高々一つであり、同じ組に対する無条件パスと共存させることはできない。

Path polarity路徑極性パスの極性

(siga +*> q1) = delay_to_q1;   // positive polarity: output moves the same way as the input
(sigb -*> q2) = delay_to_q2;   // negative polarity: output moves the opposite way
(sigc  *> q3) = delay_to_q3;   // unknown polarity (the default)

Polarity tells the simulator which of the two delay numbers to apply. With positive polarity a rising input edge is a rising output transition and uses the first number; with negative polarity a rising input edge produces a falling output and uses the second number. With unknown polarity the simulator does not try to correlate the edges and simply uses the delay appropriate to the observed output transition. For a buffer you would write +=>; for an inverter, -=>. In practice unknown polarity gives the right answer in almost every case and that is why most models omit the sign; the sign matters for tools that read the model structurally, and for the pulse-handling decisions of §8.6.極性告訴模擬器該套用兩個延遲數字中的哪一個。正極性下，輸入的上升緣對應輸出的上升轉態，用第一個數字；負極性下，輸入的上升緣產生輸出的下降，用第二個數字。未知極性下，模擬器不試圖把兩邊的邊緣關聯起來，就直接依實際觀察到的輸出轉態選用對應的延遲。對緩衝器你會寫 +=>；對反相器寫 -=>。實務上未知極性在幾乎所有情況都給出正確答案，這也是多數模型省略符號的原因；符號對那些以結構方式讀取模型的工具才重要，對 §8.6 的脈衝處理決策也重要。極性は、二つの遅延値のどちらを適用するかをシミュレータに伝える。正の極性では入力の立ち上がりエッジが出力の立ち上がり遷移に対応し、第一の数値を使う。負の極性では入力の立ち上がりが出力の立ち下がりを生み、第二の数値を使う。不明の極性では、シミュレータは両者のエッジを対応づけようとせず、観測された出力遷移に応じた遅延を単純に使う。バッファなら +=>、インバータなら -=> と書く。実務上は不明の極性でもほとんどの場合正しい答えが得られ、多くのモデルが符号を省くのはそのためである。符号が効くのは、モデルを構造的に読むツールと、§8.6 のパルス処理の判断においてである。

8.5 Edge-sensitive paths8.5 邊緣敏感路徑8.5 エッジ感応パス

specify
  (posedge clock => (q : data)) = (3, 4);    // clock-to-Q, parallel form
  (posedge clock *> (q : data)) = (3, 4);    // same thing, full form
endspecify

Read it as: "on a rising edge of clock, a path is established to q, and the value that flows along it is data; the path takes 3 to produce a 1 and 4 to produce a 0."把它讀成：「在 clock 的上升緣上，建立一條通往 q 的路徑，沿著它流動的值是 data；這條路徑產生 1 要 3，產生 0 要 4。」こう読む。「clock の立ち上がりエッジで q へ向かうパスが確立され、そこを流れる値は data である。このパスは 1 を生じるのに 3、0 を生じるのに 4 かかる」。

Three parts deserve separate attention.有三個部分值得分開說明。三つの部分を分けて見ておく価値がある。

The edge qualifier. posedge or negedge, or nothing at all (in which case any edge establishes the path). This is what makes the arc a clock-to-output arc rather than a combinational one, and it is what SDF annotates with (IOPATH (posedge CK) Q ...).邊緣修飾子。posedge、negedge，或者什麼都不寫（此時任何邊緣都會建立這條路徑）。這就是讓這條弧成為時脈到輸出的弧、而不是組合弧的東西，也是 SDF 用 (IOPATH (posedge CK) Q ...) 去標註的對象。エッジ修飾子。posedge、negedge、あるいは何も書かない（この場合どのエッジでもパスが確立する）。これがこのアークを組み合わせのアークではなくクロックから出力へのアークにしているものであり、SDF が (IOPATH (posedge CK) Q ...) でアノテートする対象でもある。

The data source expression (q : data). The part after the colon names the value that propagates. For a flip-flop it is the D input, because that is what ends up on Q. You may write (q +: data) or (q -: data) to declare non-inverting or inverting polarity, exactly as for the +*> / -*> forms. For QN you would write (qn -: data).資料來源表示式 (q : data)。冒號後面那部分指名了會傳播過去的值。對正反器而言那是 D 輸入，因為那就是最後會出現在 Q 上的東西。你可以寫 (q +: data) 或 (q -: data) 來宣告非反相或反相極性，寫法與 +*> / -*> 完全一致。對 QN 你會寫 (qn -: data)。データソース式 (q : data)。コロンの後ろの部分が、伝搬していく値を指名する。フリップフロップならそれは D 入力である。最終的に Q に現れるのがそれだからだ。(q +: data) や (q -: data) と書いて非反転／反転の極性を宣言できる。+*> / -*> の形式とまったく同じである。QN なら (qn -: data) と書く。

Why the data source is needed at all. The simulator must decide whether a given clock edge produces a rising or a falling output transition before it has computed the new output, so that it can pick the right delay number. Naming the data source lets it look at the value being captured.為什麼需要指明資料來源。模擬器必須在算出新的輸出之前就決定某個時脈邊緣會產生上升還是下降的輸出轉態，這樣才能挑對延遲數字。指名資料來源讓它可以去看正在被擷取的那個值。なぜデータソースの指定が要るのか。シミュレータは、正しい遅延値を選ぶために、新しい出力を計算する前に、そのクロックエッジが立ち上がりの出力遷移を生むのか立ち下がりを生むのかを決めなければならない。データソースを指名しておけば、取り込まれつつある値を見にいける。

8.6 PATHPULSE$: pulse control on module paths8.6 PATHPULSE$：模組路徑上的脈衝控制8.6 PATHPULSE$：モジュールパスにおけるパルス制御

A module path has the same pulse problem as a gate. By default, a module path behaves inertially with its own delay as the window: a pulse narrower than the path delay is rejected. But that default is often wrong for a characterised cell, because the real pulse-rejection width of a cell is not equal to its propagation delay — it is typically a good deal smaller. PATHPULSE$ lets you set the two thresholds explicitly.模組路徑有著與閘相同的脈衝問題。預設情況下，模組路徑以自己的延遲為視窗、依慣性方式行為：比路徑延遲窄的脈衝會被拒絕。但那個預設對一顆被特性化過的單元來說常常是錯的，因為單元真正的脈衝拒絕寬度並不等於它的傳播延遲 — 它通常小得多。PATHPULSE$ 讓你明確地設定那兩個門檻。モジュールパスにはゲートと同じパルスの問題がある。既定では、モジュールパスは自身の遅延を窓として慣性的に振る舞い、パス遅延より狭いパルスは拒否される。しかし特性化されたセルにとってこの既定はしばしば誤りである。セルの実際のパルス拒否幅は伝搬遅延と等しくなく、たいていかなり小さいからだ。PATHPULSE$ は二つのしきい値を明示的に設定させてくれる。

specify
  (clk => q)          = 10;
  (data => q)         = 7;
  (clr, preset *> q)  = 3;

  specparam
    PATHPULSE$clk$q = (3, 8);   // (reject limit, error limit) for the clk->q path only
    PATHPULSE$clr$q = (0, 5);   // reject nothing; x between 0 and 5
    PATHPULSE$      = 4;        // one value = both limits; applies to every other path
endspecify

The middle regime is the clever part and it has no counterpart in the gate-delay model. A gate makes a binary decision — pass or swallow — and both answers can be wrong for a pulse near the boundary. A module path can say I do not know, and that is almost always the honest answer for a pulse whose width is comparable to the cell's switching time. Setting PATHPULSE$ with a gap between the limits turns marginal pulses into visible x, which is what you want during verification.中間那個區間是巧妙之處，而且在閘延遲模型裡沒有對應物。閘做的是二元決定 — 通過或吞掉 — 而對一個落在邊界附近的脈衝來說，兩種答案都可能是錯的。模組路徑可以說我不知道，而對一個寬度與單元切換時間相當的脈衝來說，那幾乎永遠是誠實的答案。把 PATHPULSE$ 設成兩個界限之間留有間隙，會把邊緣脈衝變成看得見的 x，而那正是驗證期間你想要的。中央の領域が巧妙なところであり、ゲート遅延モデルには対応物がない。ゲートは通すか飲み込むかの二値判断をするが、境界付近のパルスについてはどちらの答えも誤りでありうる。モジュールパスは分からないと言うことができ、セルのスイッチング時間と同程度の幅のパルスについては、それがほぼ常に誠実な答えである。PATHPULSE$ の二つの限界に隙間を設けておけば、際どいパルスは目に見える x になる。検証中に欲しいのはまさにそれだ。

Pulse style: where the x appears脈衝樣式：x 會出現在哪裡パルススタイル：x はどこに現れるか

specify
  (clk => q) = 10;
  pulsestyle_onevent  q;   // default: the x appears at the scheduled output time
  // pulsestyle_ondetect q;   // the x appears the moment the offending pulse is detected
  showcancelled       q;   // show an x where a cancelled transition would have been
  // noshowcancelled    q;   // default: just drop the cancelled transition silently
endspecify

• pulsestyle_onevent (the default) schedules the x at the output at the time the delayed event would have arrived. The output looks clean until the path delay has elapsed, then goes unknown.pulsestyle_onevent（預設值）會把 x 排在「延遲後的事件原本會抵達的那個時刻」出現在輸出上。輸出在路徑延遲走完之前看起來是乾淨的，之後才變成未知。pulsestyle_onevent（既定値）は、遅延後のイベントが本来到着したはずの時刻に出力へ x をスケジュールする。出力はパス遅延が経過するまできれいに見え、そのあとで不定になる。
• pulsestyle_ondetect puts the x on the output immediately, at the moment the simulator notices the narrow pulse at the input. This is more pessimistic and more useful when you are hunting for the cause: the x appears at the same instant as the glitch that caused it.pulsestyle_ondetect 會在模擬器察覺到輸入端那個窄脈衝的瞬間，立刻把 x 放到輸出上。這比較悲觀，但在你追查原因時比較有用：x 與造成它的那個毛刺出現在同一瞬間。pulsestyle_ondetect は、入力側の細いパルスをシミュレータが検出した瞬間に、ただちに出力へ x を置く。より悲観的だが、原因を追うときにはより有用である。x が、それを引き起こしたグリッチと同じ瞬間に現れるからだ。
• showcancelled deals with the case where an output transition is cancelled by a later input event — the ordinary inertial cancellation. With noshowcancelled (the default) the transition simply never happens. With showcancelled the simulator drives x over the interval where the cancelled pulse would have been, which makes an otherwise invisible event visible.showcancelled 處理的是「某個輸出轉態被稍後的輸入事件取消」的情況 — 也就是一般的慣性取消。在 noshowcancelled（預設）之下，那個轉態就是從未發生。在 showcancelled 之下，模擬器會在那個被取消的脈衝本該存在的區間上驅動 x，使得一個原本看不見的事件變得看得見。showcancelled は、出力の遷移が後続の入力イベントによって取り消される場合 — すなわち通常の慣性的取り消し — を扱う。noshowcancelled（既定）ではその遷移はそもそも起こらない。showcancelled では、取り消されたパルスが本来存在したはずの区間にシミュレータが x を駆動し、さもなければ見えないイベントを可視にする。

8.7 Timing checks live here too8.7 時序檢查也住在這裡8.7 タイミングチェックもここに住んでいる

The lecture does not cover timing checks, but they occupy the same specify block and you will meet them the first time you run a gate-level simulation, so it is worth knowing what they are.講義沒有涵蓋時序檢查，但它們佔據的是同一個 specify 區塊，而且你第一次跑閘層級模擬就會遇到它們，所以值得知道它們是什麼。講義はタイミングチェックを扱っていないが、それらは同じ specify ブロックに置かれ、ゲートレベルシミュレーションを初めて走らせればすぐに出会うものなので、何であるかを知っておく価値がある。

specify
  (posedge CK => (Q : D)) = (0.142, 0.158);
  $setup  (D, posedge CK, 0.071, notifier);
  $hold   (posedge CK, D, 0.034, notifier);
  $width  (posedge CK, 0.120, 0, notifier);
  $period (posedge CK, 0.400, notifier);
  $recovery (posedge RN, posedge CK, 0.090, notifier);
endspecify

Each check watches two events and reports a violation if the time between them is less than the stated limit. The fourth argument, the notifier, is a reg declared in the module: on a violation the simulator toggles it, and the UDP inside the cell has a row watching for that toggle (? ? * : ? : x;) which drives the flip-flop output to x. That is the mechanism by which a setup violation becomes visible as data corruption rather than just a line in a log file — and it is why you must never simply suppress timing-check messages in a gate-level run.每個檢查都盯著兩個事件，若兩者之間的時間小於所述的界限就回報一次違規。第四個引數 notifier 是宣告在模組內的一個 reg：發生違規時模擬器會把它翻轉，而單元內部的 UDP 有一列在監看那個翻轉（? ? * : ? : x;），把正反器的輸出驅動成 x。這就是 setup 違規變成看得見的資料毀損、而不只是 log 檔裡一行字的機制 — 也是為什麼你絕對不能在閘層級模擬中隨手把時序檢查訊息關掉。各チェックは二つの事象を見張り、その間隔が指定された限界より小さければ違反を報告する。第四引数の notifier はモジュール内で宣言された reg である。違反が起きるとシミュレータがこれをトグルし、セル内部の UDP にはそのトグルを見張る行（? ? * : ? : x;）があって、フリップフロップの出力を x に駆動する。セットアップ違反がログの一行ではなく目に見えるデータ破壊として現れるのは、この仕組みによる。ゲートレベル実行でタイミングチェックのメッセージを安易に抑止してはならないのも、このためである。

module LATCH (Q, D, G);
  output Q;  input D, G;
  // ... functional model (UDP instance) ...
  specify
    // data to Q exists only while the latch is transparent
    if (G)  (D => Q) = (0.21, 0.19);
    // the enable itself always has an arc: it can open the latch onto new data
    (G => Q) = (0.26, 0.24);
  endspecify
endmodule

module DFFN (Q, QN, D, CKN);
  output Q, QN;  input D, CKN;
  reg notifier;
  // ... functional model (UDP instance with notifier) ...
  specify
    (negedge CKN => (Q  :  D)) = (0.31, 0.28);
    (negedge CKN => (QN : ~D)) = (0.34, 0.30);
    $setup (D, negedge CKN, 0.08, notifier);
    specparam PATHPULSE$ = (0.05, 0.12);
  endspecify
endmodule

9. How the Three Delay Layers Compose9. 三層延遲如何組合起來9. 三つの遅延層はどう合成されるか

9.1 The three-layer picture9.1 三層的全貌9.1 三層の全体像

Three statements summarise everything in sections 5 to 8:三句話就能總結第 5 到第 8 節的全部：三つの文で 5 節から 8 節までのすべてが要約できる。

9.2 Path delay versus distributed delay9.2 路徑延遲與分布延遲的對照9.2 パス遅延と分布遅延

Rule 3 catches people out, because the intuitive guess is that the specify delay is added on top of the gate delays. It is not. The specify path and the internal gate chain are two descriptions of the same physical thing, and the standard resolves the conflict by taking the larger value for each path.第 3 條規則常絆倒人，因為直覺的猜測是 specify 延遲會疊加在閘延遲之上。並不會。specify 路徑與內部的閘鏈是同一個物理事物的兩種描述，而標準解決這個衝突的方式是：對每一條路徑取兩者中較大的值。規則 3 は人をつまずかせる。specify の遅延がゲート遅延の上に加算されるというのが直感的な推測だからだ。そうはならない。specify のパスと内部のゲート連鎖は同一の物理的事物についての二つの記述であり、標準はパスごとに大きいほうの値を取ることでこの衝突を解決する。

In practice the rule almost never bites, because library models are written so that it cannot. Look again at the shape of a cell model:實務上這條規則幾乎從不咬人，因為單元庫的模型就是寫成讓它不可能咬人。再看一次單元模型的形狀：実務ではこの規則がほとんど牙を剥かない。ライブラリのモデルが、そうならないように書かれているからである。セルモデルの形をもう一度見てみる。

module norf201 (O, A1, B1);
  output O;  input A1, B1;

  nor (O, A1, B1);                             // NO delay on the primitive

  specify
    (A1, B1 *> O) = (0.1:0.3:0.8, 0.1:0.2:0.5);
  endspecify
endmodule

The primitive carries no delay, so the distributed delay is zero and $\max(9, 0) = 9$: the path delay is the entire timing of the cell. That is deliberate. It keeps the function and the timing in separate places so that SDF can rewrite the timing without touching the function, and it removes any ambiguity about which number wins.原型不帶延遲，所以分布延遲是零，而 $\max(9, 0) = 9$：路徑延遲就是這顆單元全部的時序。那是刻意的。它把功能與時序放在不同的地方，讓 SDF 可以在不碰功能的情況下改寫時序，也消除了「哪個數字會贏」的任何歧義。プリミティブは遅延を持たないので分布遅延はゼロであり、$\max(9, 0) = 9$ となる。パス遅延がそのセルのタイミングのすべてである。これは意図的だ。機能とタイミングを別々の場所に置くことで、SDF は機能に触れずにタイミングを書き換えられ、どちらの数値が勝つかという曖昧さも消える。

9.3 A worked post-layout number9.3 佈局後數字的實例計算9.3 レイアウト後の数値例

Take a simple launch-to-capture path at the slow corner: a flip-flop, two combinational cells, and the interconnect between them.取一條慢角下簡單的發射到擷取路徑：一顆正反器、兩顆組合邏輯單元，以及它們之間的繞線。低速コーナーにおける単純なローンチからキャプチャまでの経路をとる。フリップフロップ一つ、組み合わせセル二つ、そしてそれらのあいだの配線である。

Every term in that sum is a Lecture 3 construct. $t_{CQ}$ is an edge-sensitive module path. The three interconnect terms are net delays (installed as MIPDs by the annotator). The two cell terms are simple module paths. The setup limit is a $setup timing check inside a specify block. A gate-level simulation computes exactly this sum, event by event, and if the arrival exceeds the required time, the $setup check fires, toggles the notifier, and the capture flip-flop's UDP drives x.那個總和裡的每一項都是第 3 講的結構。$t_{CQ}$ 是一條邊緣敏感的模組路徑。三個繞線項是 net 延遲（由標註器以 MIPD 的形式裝上去）。兩個單元項是簡單模組路徑。setup 界限是 specify 區塊裡的一個 $setup 時序檢查。閘層級模擬逐事件算的正是這個總和，而如果抵達時間超過需求時間，$setup 檢查就會觸發、翻轉 notifier，然後擷取端正反器的 UDP 把輸出驅動成 x。この和の各項はいずれも第 3 講の構文である。$t_{CQ}$ はエッジ感応のモジュールパス。三つの配線項は net 遅延（アノテータが MIPD として取り付ける）。二つのセル項は単純モジュールパス。セットアップ限界は specify ブロック内の $setup タイミングチェックである。ゲートレベルシミュレーションはこの和をイベントごとに計算し、到着時刻が要求時刻を超えれば $setup チェックが発火して notifier をトグルし、キャプチャ側フリップフロップの UDP が出力を x に駆動する。

That last sentence is the answer to "why bother with gate-level simulation when static timing analysis already checked every path?" STA checks every path but assumes the design is synchronous and the constraints are right. Gate-level simulation with SDF checks the paths that actually toggle under real stimulus, catches the asynchronous interfaces and the false-path exceptions you declared carelessly, and turns a timing failure into visible data corruption rather than a number in a report you may not read.最後那句話就是「既然靜態時序分析已經檢查過每一條路徑，為什麼還要做閘層級模擬？」的答案。STA 檢查每一條路徑，但它假設設計是同步的、而且約束是對的。帶 SDF 的閘層級模擬檢查的是在真實激勵下實際會翻轉的那些路徑，抓得到非同步介面以及你隨手宣告的 false path 例外，並且把時序失效變成看得見的資料毀損，而不是一份你可能根本不會讀的報告裡的一個數字。最後の一文が、「静的タイミング解析がすでに全パスを検査しているのに、なぜゲートレベルシミュレーションをするのか」への答えである。STA は全パスを検査するが、設計が同期式であり制約が正しいことを前提にしている。SDF 付きのゲートレベルシミュレーションは、実際の刺激のもとで本当にトグルするパスを検査し、非同期インタフェースや不用意に宣言したフォルスパス例外を捕まえ、タイミング違反を、読まないかもしれないレポートの数値ではなく目に見えるデータ破壊に変える。

9.4 SDF back-annotation9.4 SDF 反標註9.4 SDF バックアノテーション

The link between layout and simulation is one system task:佈局與模擬之間的連結，就是一個系統任務：レイアウトとシミュレーションをつなぐのは一つのシステムタスクである。

initial
  $sdf_annotate("post_route.sdf", dut, , "sdf.log", "MAXIMUM");
//              file            scope  cfg  log       corner

Read that table from right to left and the design of the specify block makes complete sense. Every construct the lecture introduces exists because there is an SDF entry that needs somewhere to land. Module paths exist because IOPATH exists. State-dependent paths exist because COND exists. PATHPULSE$ exists because PATHPULSE exists. The Verilog side was designed as the target of the annotation, not the other way round.把那張表由右往左讀，specify 區塊的設計就完全說得通了。講義介紹的每一個結構之所以存在，都是因為有某個 SDF 條目需要一個落腳處。模組路徑存在是因為 IOPATH 存在。狀態相依路徑存在是因為 COND 存在。PATHPULSE$ 存在是因為 PATHPULSE 存在。Verilog 這一側是被設計成標註的目標，而不是反過來。その表を右から左へ読めば、specify ブロックの設計は完全に筋が通る。講義が紹介する構文はどれも、受け皿を必要とする SDF の項目があるから存在する。モジュールパスが存在するのは IOPATH があるから。状態依存パスが存在するのは COND があるから。PATHPULSE$ が存在するのは PATHPULSE があるからだ。Verilog 側はアノテーションの受け手として設計されたのであって、その逆ではない。

module inv1 (Z, A);
  output Z;  input A;
  not #(0.4, 0.5) (Z, A);
  specify
    specparam Tr = 0.2, Tf = 0.25;
    (A => Z) = (Tr, Tf);
  endspecify
endmodule

10. BNF, System Tasks and Compiler Directives10. BNF、系統任務與編譯指令10. BNF、システムタスク、コンパイラ指令

10.1 Reading BNF10.1 讀懂 BNF10.1 BNF の読み方

The Verilog standard defines the language in Backus-Naur Form, and once you can read it you never again have to guess whether a construct is legal. The whole notation is four symbols:Verilog 標準以 Backus-Naur Form 定義這個語言，而一旦你讀得懂它，就再也不必猜某個結構合不合法。整套記法只有四個符號：Verilog 標準はこの言語をバッカス・ナウア記法で定義しており、これが読めるようになれば、ある構文が合法かどうかを推測する必要は二度となくなる。記法は全部で四つの記号からなる。

Two cautions. First, the braces in BNF are metasyntax; they are not the Verilog concatenation operator, even though the same characters appear in the language. Second, "zero or more" genuinely includes zero: module empty; endmodule is a legal Verilog module with no ports and no items, and the BNF says so.兩點提醒。第一，BNF 裡的大括號是後設語法；它們不是 Verilog 的串接運算子，儘管語言裡也用同樣的字元。第二，「零次或多次」真的包含零次：module empty; endmodule 是一個合法的 Verilog 模組，沒有埠也沒有項目，而 BNF 就是這麼說的。二つ注意しておく。第一に、BNF の波括弧はメタ構文であり、同じ文字が言語中にも現れるとはいえ、Verilog の連結演算子ではない。第二に、「ゼロ回以上」には本当にゼロ回が含まれる。module empty; endmodule はポートも項目もない合法な Verilog モジュールであり、BNF はそう述べている。

10.2 The grammar skeleton, annotated10.2 文法骨架，加上註解10.2 文法の骨格に注釈をつける

source_text        ::= { description }
description        ::= module_declaration | udp_declaration
module_declaration ::= module_keyword module_identifier [ list_of_ports ] ;
                       { module_item }
                       endmodule
module_keyword     ::= module | macromodule
list_of_ports      ::= ( port { , port } )
module_item        ::= module_item_declaration | parameter_override
                     | continuous_assign     | gate_instantiation
                     | udp_instantiation     | module_instantiation
                     | specify_block         | initial_construct
                     | always_construct
continuous_assign  ::= assign [ drive_strength ] [ delay3 ] list_of_net_assignments ;
drive_strength     ::= ( strength0 , strength1 )
delay3             ::= # delay_value
                     | # ( delay_value [ , delay_value [ , delay_value ] ] )
list_of_net_assignments ::= net_assignment { , net_assignment }
net_assignment     ::= net_lvalue = expression

Five things this fragment tells you that the prose of the course does not.這段文法告訴你五件課程的文字說明沒說的事。この断片は、授業の文章が述べていない五つのことを教えてくれる。

A file is a list of modules and UDPs, nothing else. description ::= module_declaration | udp_declaration. There is no file-level variable, no top-level statement, no main. Compiler directives are not in the grammar at all because they are removed by the preprocessor before the parser sees anything — which is precisely why they are not scoped (§6.5).一個檔案就是一串模組與 UDP，別無他物。description ::= module_declaration | udp_declaration。沒有檔案層級的變數、沒有頂層敘述、沒有 main。編譯指令根本不在文法裡，因為它們在剖析器看到任何東西之前就已經被前處理器移除了 — 這正是它們不受作用範圍限制的原因（§6.5）。ファイルとはモジュールと UDP の並びであり、それ以外の何物でもない。description ::= module_declaration | udp_declaration。ファイルレベルの変数も、トップレベルの文も、main も存在しない。コンパイラ指令はそもそも文法に含まれていない。パーサが何かを見る前にプリプロセッサが取り除くからであり、それがスコープを持たない理由でもある（§6.5）。

UDPs are first-class, at the same level as modules. That is the formal statement of "a UDP is not a module and cannot be nested inside one".UDP 是第一級公民，與模組同一層級。這就是「UDP 不是模組，而且不能巢狀寫在模組裡面」的形式化陳述。UDP は第一級の存在であり、モジュールと同じレベルにある。これが「UDP はモジュールではなく、モジュールの内側に入れ子にできない」の形式的な表明である。

The port list is optional. [ list_of_ports ]. This is why a test bench may be written module tb; with no parentheses at all, and why module modB(); with empty parentheses is also legal.埠列表可以省略。[ list_of_ports ]。這就是為什麼測試平台可以寫成完全沒有括號的 module tb;，也是為什麼帶空括號的 module modB(); 同樣合法。ポートリストは省略できる。[ list_of_ports ]。テストベンチを括弧なしの module tb; と書けるのも、空の括弧を持つ module modB(); が合法なのも、このためである。

delay3 is the delay syntax of §5.1, written formally. # delay_value for one value, or parentheses with one, two or three values — the nesting of the square brackets is what encodes "the second is optional, and the third is only possible if the second is present". You cannot write #( , 3).delay3 就是 §5.1 的延遲語法，以形式化方式寫出來。一個值用 # delay_value，或用括號包一個、兩個或三個值 — 方括號的巢狀結構編碼的正是「第二個可省略，而第三個只有在第二個存在時才可能出現」。你不能寫 #( , 3)。delay3 は §5.1 の遅延構文を形式的に書いたものである。値が一つなら # delay_value、あるいは括弧で一つ・二つ・三つの値を囲む — 角括弧の入れ子が「二つ目は省略可能で、三つ目は二つ目があるときにのみ現れうる」を符号化している。#( , 3) とは書けない。

A continuous assignment may carry a drive strength as well as a delay, and the strength comes first. assign (strong1, pull0) #3 y = a; is legal and is how bus models express wired-OR behaviour. Writing them in the other order is a syntax error, and the BNF is where you look to find that out.連續指定除了延遲之外還可以帶驅動強度，而且強度寫在前面。assign (strong1, pull0) #3 y = a; 是合法的，匯流排模型就是這樣表達 wired-OR 行為。順序寫反就是語法錯誤，而 BNF 正是你用來查出這件事的地方。連続代入は遅延に加えてドライブ強度も持て、強度が先に来る。assign (strong1, pull0) #3 y = a; は合法であり、バスのモデルはこうして wired-OR の振る舞いを表現する。順序を逆に書けば構文エラーであり、それを調べる先が BNF である。

10.3 System tasks and functions10.3 系統任務與系統函式10.3 システムタスクとシステム関数

Anything beginning with $ is a system task (a statement) or a system function (returns a value). Not synthesisable They exist for simulation, debugging and test-bench control, and no synthesiser will touch them. Four facts first:凡是以 $ 開頭的都是系統任務（一個敘述）或系統函式（會回傳值）。不可合成 它們是為了模擬、除錯與測試平台控制而存在的，沒有任何合成器會碰它們。先記四件事：$ で始まるものはシステムタスク（文）かシステム関数（値を返す）である。合成不可 これらはシミュレーション、デバッグ、テストベンチ制御のために存在し、合成器は一切触らない。まず四つの事実を押さえる。

• A system task is called as a statement: $display(...);. A system function returns a value and appears in an expression: t = $time;.系統任務以敘述的形式呼叫：$display(...);。系統函式會回傳值，出現在表示式中：t = $time;。システムタスクは文として呼ぶ：$display(...);。システム関数は値を返し、式の中に現れる：t = $time;。
• They may appear anywhere a statement may — inside initial, inside always, inside a task. Putting one inside synthesisable RTL will not break simulation but will break synthesis, which is why designers wrap them in `ifndef SYNTHESIS.它們可以出現在任何能寫敘述的地方 — initial 內、always 內、task 內。把一個放進可合成的 RTL 不會弄壞模擬，但會弄壞合成，這就是為什麼設計者會把它們包在 `ifndef SYNTHESIS 裡。文を書ける場所であればどこにでも置ける — initial の中、always の中、task の中。合成対象の RTL に入れてもシミュレーションは壊れないが合成は壊れる。設計者がこれらを `ifndef SYNTHESIS で囲むのはそのためである。
• They execute in the active event region of the time step in which they are reached, with one critical exception noted below.它們在抵達的那個時間步的 active 事件區執行，只有一個關鍵例外，見下文。到達した時間ステップのアクティブイベント領域で実行される。ただし一つ重要な例外があり、それは後述する。
• The $ namespace is reserved; user-defined system tasks (PLI/VPI) also live in it.$ 這個名稱空間是保留的；使用者自訂的系統任務（PLI／VPI）也住在裡面。$ の名前空間は予約されている。ユーザ定義のシステムタスク（PLI／VPI）もここに属する。

The $display versus $strobe versus $monitor distinction is the one that costs time in practice, and it is really a Lecture 2 topic (the stratified event queue) surfacing here. All three print the same values most of the time; they differ exactly when a signal is updated by a non-blocking assignment in the same time step. $display executes in the active region and sees the pre-update value; $strobe and $monitor execute in the monitor region, after the non-blocking update region, and see the post-update value. If your log and your waveform disagree by one clock cycle, this is why.$display、$strobe 與 $monitor 的區別是實務上最花時間的那一個，而它其實是第 2 講的題目（分層事件佇列）在這裡浮出水面。三者大多數時候印出相同的值；它們的差別恰好出現在「某個訊號在同一個時間步被非阻斷指定更新」的時候。$display 在 active 區執行，看到的是更新前的值；$strobe 與 $monitor 在 monitor 區執行，也就是在非阻斷更新區之後，看到的是更新後的值。如果你的 log 和波形差了一個時脈週期，原因就在這裡。$display、$strobe、$monitor の違いは、実務で最も時間を食う区別であり、実のところ第 2 講の話題（階層化イベントキュー）がここに顔を出したものである。三つはたいてい同じ値を印字するが、同じ時間ステップでノンブロッキング代入によって信号が更新される場合にちょうど食い違う。$display はアクティブ領域で実行され更新前の値を見る。$strobe と $monitor はノンブロッキング更新領域のあとのモニタ領域で実行され、更新後の値を見る。ログと波形が 1 クロックずれるのはこれが理由である。

always @(posedge clk) begin
  q <= d;                             // non-blocking: q updates later in this time step
  $display("display: q = %b", q);     // prints the OLD q
  $strobe ("strobe : q = %b", q);     // prints the NEW q
end

Format specifiers follow C with Verilog additions: %b binary, %d decimal, %h hex, %o octal, %c character, %s string, %f/%e/%g real, %t time (formatted by $timeformat), %m the hierarchical name of the enclosing scope, %v net strength. Prefixing with 0, as in %0d, removes the leading-space padding and is almost always what you want in a log.格式指定子沿用 C 並加上 Verilog 的擴充：%b 二進位、%d 十進位、%h 十六進位、%o 八進位、%c 字元、%s 字串、%f／%e／%g 實數、%t 時間（由 $timeformat 決定格式）、%m 所在範圍的階層名稱、%v net 強度。前面加上 0，像 %0d 這樣，會去掉前導空白的補位，而那幾乎永遠是你在 log 裡想要的。書式指定子は C を踏襲し、Verilog の拡張が加わる。%b は 2 進、%d は 10 進、%h は 16 進、%o は 8 進、%c は文字、%s は文字列、%f／%e／%g は実数、%t は時刻（書式は $timeformat が決める）、%m は囲んでいるスコープの階層名、%v は net の強度である。%0d のように 0 を前置すると先頭の空白詰めがなくなる。ログではほぼ常にそれが望ましい。

10.4 File I/O10.4 檔案 I/O10.4 ファイル I/O

module test_bench ();
  reg        x;
  wire       y;
  reg [31:0] cd;                       // multichannel descriptor
  assign y = ~x;

  initial begin
    cd = $fopen("test.dat");           // returns a channel bit, not a FILE*
    #100 x = 0;
    $fdisplay(cd, "%b %b", x, y);
    $fclose(cd);
  end
endmodule

The reg [31:0] in the lecture's example is not arbitrary. The Verilog-1995 $fopen returns a multichannel descriptor: a 32-bit mask in which exactly one bit is set, identifying the opened file. Bit 0 is permanently assigned to the standard output. Because it is a mask, you can OR descriptors together and write to several destinations in one call:講義例子裡的 reg [31:0] 不是隨便寫的。Verilog-1995 的 $fopen 回傳的是一個多通道描述子（multichannel descriptor）：一個只有一個位元被設起來的 32 位元遮罩，用來識別那個被開啟的檔案。位元 0 永久分配給標準輸出。因為它是遮罩，你可以把多個描述子 OR 起來，一次呼叫就寫到好幾個目的地：講義の例にある reg [31:0] は恣意的な幅ではない。Verilog-1995 の $fopen が返すのはマルチチャネル記述子であり、ちょうど一つのビットが立った 32 ビットのマスクで、開かれたファイルを識別する。ビット 0 は標準出力に恒久的に割り当てられている。マスクであるから、記述子を OR でまとめて一度の呼び出しで複数の宛先に書ける。

reg [31:0] f1, f2, both;
initial begin
  f1   = $fopen("a.log");
  f2   = $fopen("b.log");
  both = f1 | f2 | 32'h1;              // both files AND the console
  $fdisplay(both, "this line goes to three places");
end

That design limits you to 31 open files. Verilog-2001 added a second form: $fopen("name", "r") with a mode string returns an ordinary file descriptor with its most significant bit set, usable with $fgets, $fscanf, $fread, $feof and the rest of the C-like family. The two forms are distinguished by whether you passed a mode argument. Mixing them up — passing a file descriptor where a multichannel descriptor is expected — writes to a nonsensical set of channels and is a classic confusing bug.這個設計把你限制在 31 個開啟的檔案。Verilog-2001 加上了第二種形式：帶模式字串的 $fopen("name", "r") 回傳一個最高位元被設起來的普通檔案描述子，可以搭配 $fgets、$fscanf、$fread、$feof 以及其餘類 C 的家族成員使用。兩種形式是由「你有沒有傳模式引數」來區分的。把它們搞混 — 在該傳多通道描述子的地方傳了檔案描述子 — 會寫到一組毫無意義的通道，是一個經典的惱人錯誤。この設計は同時に開けるファイルを 31 個に制限する。Verilog-2001 は第二の形式を追加した。モード文字列を伴う $fopen("name", "r") は最上位ビットの立った通常のファイル記述子を返し、$fgets、$fscanf、$fread、$feof など C 風の一族とともに使える。二つの形式はモード引数を渡したかどうかで区別される。これらを取り違え、マルチチャネル記述子を期待する場所にファイル記述子を渡すと、意味をなさないチャネル群に書き込むことになり、典型的な分かりにくいバグになる。

The output family mirrors the display family exactly: $fdisplay, $fwrite, $fstrobe, $fmonitor, each taking the descriptor as the first argument and otherwise behaving identically to its console counterpart.輸出家族與顯示家族完全對應：$fdisplay、$fwrite、$fstrobe、$fmonitor，每一個都以描述子為第一個引數，其餘行為與它在主控台的對應者完全相同。出力の一族は表示の一族と完全に対応する。$fdisplay、$fwrite、$fstrobe、$fmonitor はいずれも記述子を第一引数に取り、それ以外はコンソール版とまったく同じに振る舞う。

10.5 $readmemh and $readmemb10.5 $readmemh 與 $readmemb10.5 $readmemh と $readmemb

parameter ram_file = "ram_data_file";
reg [15:0] RAM_1 [0:1023];                  // 1024 words of 16 bits

initial $readmemh(ram_file, RAM_1);         // file holds hex digits
initial $readmemb(ram_file, RAM_1);         // file holds binary digits

initial $readmemh("boot.hex", RAM_1, 16'h100, 16'h1FF);  // load only that range

The file format is simple and worth knowing exactly, because most $readmem problems are file-format problems:檔案格式很簡單，值得精確地記住，因為大多數 $readmem 的問題其實都是檔案格式的問題：ファイル形式は単純だが正確に覚えておく価値がある。$readmem の問題のほとんどは、実はファイル形式の問題だからである。

• Values are separated by any whitespace, including newlines. One value per line is a convention, not a rule; the task reads a stream of tokens.值之間以任何空白分隔，包括換行。每行一個值是慣例而不是規則；這個任務讀的是一串記號。値はあらゆる空白文字で区切られる。改行も含む。一行に一つという書き方は慣習であって規則ではない。このタスクが読むのはトークンの並びである。
• // and /* ... */ comments are allowed and ignored.允許 // 與 /* ... */ 註解，並會被忽略。// と /* ... */ のコメントが許され、無視される。
• Underscores inside a number are allowed and ignored — which is why the lecture's example file can contain 0110_1101_0100_1011.數字中間允許底線並會被忽略 — 這就是為什麼講義的範例檔案可以寫成 0110_1101_0100_1011。数値の途中のアンダースコアが許され、無視される — 講義の例のファイルが 0110_1101_0100_1011 と書けるのはこのためである。
• The digits x and z are allowed, so a memory image can carry explicit unknowns.允許 x 與 z 這兩個數字，所以一份記憶體映像檔可以帶著明確的未知值。x と z の桁も許されるので、メモリイメージは明示的な不定値を持てる。
• A token of the form @address (hex, no spaces) sets the load address. Everything after it loads from there. This is how a sparse image is expressed.形如 @位址 的記號（十六進位，中間不能有空白）會設定載入位址。它之後的所有內容都從那裡開始載入。稀疏的映像檔就是這樣表達的。@アドレス の形のトークン（16 進、空白なし）がロードアドレスを設定する。それ以降の内容はそこから読み込まれる。疎なイメージはこうして表現する。
• Without any @, loading starts at the left index of the array declaration — the first index in [0:1023] is 0, but in [1023:0] it is 1023 and the file loads downwards. This is a genuine trap.完全沒有 @ 時，載入從陣列宣告的左側索引開始 — [0:1023] 的第一個索引是 0，但 [1023:0] 的第一個索引是 1023，於是檔案會往下載入。這是個貨真價實的陷阱。@ がまったくない場合、読み込みは配列宣言の左側の添字から始まる — [0:1023] の最初の添字は 0 だが、[1023:0] では 1023 であり、ファイルは下方向に読み込まれる。これは正真正銘の罠である。
• Locations not covered by the file keep whatever they had, which at time zero is x.檔案沒有涵蓋到的位置保持原有內容，而在時間零那就是 x。ファイルが覆わない位置は元の内容を保つ。時刻ゼロではそれは x である。
• Too many values for the array, or an address outside the declared range, is an error.值的個數超過陣列大小，或位址落在宣告範圍之外，都是錯誤。値が配列より多い場合や、宣言された範囲外のアドレスはエラーである。

10.6 Compiler directives10.6 編譯指令10.6 コンパイラ指令

Directives begin with a backtick, are processed by the preprocessor before parsing, and — this is the point to internalise — are not scoped. They take effect from where they are read until something changes them, across module boundaries and across file boundaries, in compilation order.指令以反引號開頭，在剖析之前由前處理器處理，而且 — 這一點要內化 — 不受作用範圍限制。它們從被讀到的地方開始生效，直到有東西改變它們為止，跨越模組邊界、跨越檔案邊界，依編譯順序而定。指令はバッククォートで始まり、構文解析の前にプリプロセッサが処理する。そして — これを体に染み込ませること — スコープを持たない。読み込まれた地点から、何かが変えるまで効力を持ち、モジュールの境界もファイルの境界も越え、コンパイル順序に従う。

`default_nettype: the most useful line in the table`default_nettype：表中最有用的一行`default_nettype：表の中で最も有用な一行

By default, using an undeclared identifier in a port connection or on the right of a continuous assignment creates a one-bit wire silently. That rule exists for Verilog-1995 convenience and it is a disaster for typos:預設情況下，在埠連接中或在連續指定的右側使用一個未宣告的識別字，會默默建立一條一位元的 wire。那條規則是為了 Verilog-1995 的方便而存在，但對打錯字來說是場災難：既定では、ポート接続や連続代入の右辺で未宣言の識別子を使うと、1 ビットの wire が黙って作られる。この規則は Verilog-1995 の利便のために存在するが、タイプミスにとっては災厄である。

module m (input clk, output q);
  wire data_valid;
  ...
  assign q = data_vaild & clk;
  // data_vaild is implicitly created
  // as a 1-bit wire, never driven,
  // so q is x forever. No warning
  // from most tools.
endmodule

`default_nettype none
module m (input wire clk, output wire q);
  wire data_valid;
  ...
  assign q = data_vaild & clk;
  // ERROR: 'data_vaild' is not declared.
  // Caught at compile time.
endmodule
`default_nettype wire   // restore before the next file

Two practical notes. With none in force, every module port must have an explicit type — input wire clk, not input clk — because the port declaration itself relies on the implicit rule. And because the directive is not scoped, always restore it with `default_nettype wire at the end of your file, or the next file compiled (perhaps someone else's IP) will fail for reasons that have nothing to do with it.兩點實務說明。在 none 生效期間，每一個模組埠都必須有明確的型態 — 要寫 input wire clk，不能寫 input clk — 因為埠宣告本身就依賴那條隱含規則。另外，由於這個指令不受作用範圍限制，請務必在你的檔案結尾用 `default_nettype wire 還原，否則下一個被編譯的檔案（也許是別人的 IP）會因為與它毫無關係的理由而失敗。実務上の注意が二つある。none が有効なあいだ、モジュールのポートはすべて明示的な型を持たねばならない — input clk ではなく input wire clk と書く。ポート宣言自体が暗黙の規則に依存しているからだ。もう一つ、この指令はスコープを持たないので、ファイルの末尾で必ず `default_nettype wire に戻すこと。さもないと、次にコンパイルされるファイル（他人の IP かもしれない）が、それとは無関係な理由で失敗する。

Why `celldefine matters for this lecture為什麼 `celldefine 對本講很重要なぜ `celldefine が本講で重要か

Every standard-cell model is wrapped in `celldefine ... `endcelldefine, and the reason connects straight back to section 8. The flag tells downstream tools "this module is a leaf of the physical hierarchy; its timing comes from its specify block and its SDF annotation, and you should not look inside it". SDF annotators use it to decide where the CELL scopes in the SDF file map to. Coverage tools use it to exclude library cells from toggle coverage, which would otherwise be dominated by a million inverters. Profilers use it to account cell evaluation separately. It costs two lines and it is the difference between a library that integrates cleanly and one that fights every tool in the flow.每一個標準單元的模型都被包在 `celldefine ... `endcelldefine 裡，而理由直接連回第 8 節。這個旗標告訴下游工具：「這個模組是實體階層的葉節點；它的時序來自它的 specify 區塊與 SDF 標註，你不該往裡面看。」SDF 標註器用它來決定 SDF 檔案裡的 CELL 範圍要對應到哪裡。覆蓋率工具用它把單元庫單元排除在翻轉覆蓋率之外，否則那會被上百萬顆反相器淹沒。效能分析器用它把單元求值分開計帳。它只要兩行，卻是「一座能乾淨整合的單元庫」與「一座跟流程中每個工具打架的單元庫」之間的差別。標準セルのモデルはどれも `celldefine ... `endcelldefine に包まれており、その理由は第 8 節に直結する。この印は下流のツールにこう告げる。「このモジュールは物理階層の葉である。そのタイミングは specify ブロックと SDF アノテーションから来るのだから、中を覗くべきではない」。SDF アノテータはこれを使って、SDF ファイルの CELL スコープの対応先を決める。カバレッジツールはこれを使ってライブラリセルをトグルカバレッジから除く。さもなければ百万個のインバータに埋もれてしまう。プロファイラはセルの評価を別勘定にする。費用は二行、そしてそれが、流れの中のすべてのツールときれいに統合されるライブラリと、ことごとく喧嘩するライブラリの差である。

11. Summary, Checklist and Cross-References11. 總結、檢查表與交叉參照11. まとめ、チェックリスト、相互参照

11.1 Exam checklist11.1 考前檢查表11.1 試験前チェックリスト

11.2 Traps that cost marks11.2 會扣分的陷阱11.2 点を落とす落とし穴

1. Putting ? in the output column of a UDP table, or - in an input column. Both are syntax errors and both come from Karnaugh-map habits.把 ? 放進 UDP 表的輸出欄，或把 - 放進輸入欄。兩者都是語法錯誤，而且都來自卡諾圖的習慣。UDP テーブルの出力列に ? を置く、あるいは入力列に - を置くこと。どちらも構文エラーであり、どちらもカルノー図の習慣から来る。
2. Forgetting the catch-all hold rows in a sequential UDP. Without (?0) ? : ? : -; and ? (??) : ? : -; the flip-flop is destroyed by the first falling clock edge or the first data change.在循序邏輯 UDP 中忘記寫包山包海的保持列。少了 (?0) ? : ? : -; 與 ? (??) : ? : -;，正反器會被第一個時脈下降緣或第一次資料變化毀掉。順序 UDP で総括的な保持行を忘れること。(?0) ? : ? : -; と ? (??) : ? : -; がなければ、フリップフロップは最初のクロック立ち下がりか最初のデータ変化で壊れる。
3. Forgetting the clear-release row. When an asynchronous clear deasserts, that is an input event, and if no row matches it the output goes to x the instant you come out of reset.忘記清除解除那一列。非同步清除解除時那是一個輸入事件，如果沒有任何一列對應它，輸出會在你剛離開重置的瞬間變成 x。クリア解除の行を忘れること。非同期クリアのディアサートは入力イベントであり、一致する行がなければ、リセットを抜けた瞬間に出力が x になる。
4. Choosing the delay by the source value. It is always the destination: x→1 uses the rising delay.依來源值選延遲。永遠是依目的地：x→1 用上升延遲。遷移元の値で遅延を選ぶこと。選ぶのは常に行き先である。x→1 は立ち上がり遅延を使う。
5. Forgetting that transitions to x use the minimum delay. This is the only non-obvious row of the mapping table and it is examined every year.忘記變成 x 的轉態取最小延遲。這是對應表中唯一不顯然的一列，而且年年考。x への遷移が最小の遅延を使うことを忘れること。マッピング表で唯一自明でない行であり、毎年出題される。
6. Assuming wire #5 y = a ^ b; gives 10. It gives 5.以為 wire #5 y = a ^ b; 給出 10。它給出 5。wire #5 y = a ^ b; が 10 を与えると思い込むこと。答えは 5 である。
7. Assuming a specify path adds to the gate delays. The larger is used, not the sum.以為 specify 路徑會疊加到閘延遲上。採用的是較大者，不是總和。specify のパスがゲート遅延に加算されると思い込むこと。使われるのは和ではなく大きいほうである。
8. Truncating instead of rounding in $time. 5.7 prints as 6.在 $time 做截斷而不是四捨五入。5.7 會印成 6。$time で四捨五入せず切り捨てること。5.7 は 6 と印字される。
9. Letting a delay round to zero because the precision is coarser than the delay.讓延遲被捨成零，因為精度比那個延遲還粗。精度が遅延より粗いために遅延がゼロに丸められること。
10. Reading a binary memory image with $readmemh — no error, wrong contents.用 $readmemh 讀一份二進位的記憶體映像檔 — 不會報錯，但內容是錯的。2 進のメモリイメージを $readmemh で読むこと — エラーは出ないが内容が誤る。
11. Confusing => and *> on vector ports. Parallel needs equal widths; full creates $n \times m$ arcs.在向量埠上混淆 => 與 *>。平行連接要求位寬相同；全連接會建立 $n \times m$ 條弧。ベクタのポートで => と *> を取り違えること。並列は幅が等しいことを要求し、全接続は $n \times m$ 本のアークを作る。
12. Writing an unconditional (D => Q) path for a latch, creating a combinational path straight through a closed latch.為閂鎖器寫出無條件的 (D => Q) 路徑，於是造出一條直接穿過關閉中閂鎖器的組合路徑。ラッチに無条件の (D => Q) パスを書くこと。閉じたラッチを突き抜ける組み合わせパスを作ってしまう。