Behavioral Descriptions, Explained行為層描述詳解振る舞い記述の解説

1. Behaviors: initial and always1. 行為描述：initial 與 always1. 振る舞い：initial と always

1.1 One module, every level of abstraction1.1 一個模組，涵蓋每一個抽象層次1.1 一つのモジュールに、あらゆる抽象化レベル

The first slide of the lecture is deliberately unglamorous: it shows a module body containing a continuous assignment, a gate primitive, a user-defined primitive, a sub-module instance and an always block, all side by side. The point is not syntax. The point is that Verilog does not have "a behavioral language" and "a structural language" that you choose between; it has one language whose constructs can be mixed freely inside a single module, and the simulator runs all of them concurrently.講義的第一張投影片刻意畫得平淡：它展示一個模組本體，裡面同時擺著一個連續指派、一個閘級基本元件、一個使用者自定義基本元件、一個子模組實例，以及一個 always 區塊。重點不在語法。重點在於 Verilog 並沒有分成「一種行為語言」和「一種結構語言」讓你二選一；它只有一種語言，而這種語言的各種構造可以在同一個模組裡自由混用，模擬器會把它們全部並行執行。講義の最初のスライドはわざと地味である：連続代入、ゲートプリミティブ、ユーザ定義プリミティブ、下位モジュールのインスタンス、そして always ブロックが横並びに入ったモジュール本体を示している。要点は構文ではない。要点は、Verilog には選択すべき「振る舞い記述の言語」と「構造記述の言語」があるのではなく、言語は一つだけで、その構文は単一のモジュール内で自由に混在でき、シミュレータはそれらすべてを並行して走らせるという点である。

module my_module (...);
  ...
  assign ...;               // continuous assignment  - dataflow level
  and (...);                // primitive instance     - gate level
  my_udp (...);             // UDP instance           - gate level
  adder_16bits M1 (...);    // module instance        - structural level
  always @ (...) begin      // behavior               - behavioral level
    ...
  end
endmodule

This matters practically for two reasons. First, real designs are written this way: a datapath is often a structural netlist of hand-chosen adders and multiplexers, while the controller that drives it is a behavioral state machine in the same file. Second, and more subtly, every one of those constructs is a separate process in the simulator's eyes. A continuous assignment is a process that re-executes whenever its right-hand side changes. A gate primitive is a process that re-executes whenever an input changes. An always block is a process that re-executes whenever its event control is satisfied. They are all peers. None of them "runs first" because it appears earlier in the file — a fact that section 2 will turn into a precise statement about event regions, and section 8 will turn into a warning about race conditions.這在實務上有兩個意義。第一，真正的設計就是這樣寫的：資料路徑往往是一份由人工挑選的加法器與多工器構成的結構性 netlist，而驅動它的控制器則是同一個檔案裡的行為層狀態機。第二，更微妙的是，上面每一個構造在模擬器眼中都是一個獨立的行程。連續指派是一個行程，只要右手邊改變就重新執行。閘級基本元件是一個行程，只要輸入改變就重新執行。always 區塊是一個行程，只要事件控制被滿足就重新執行。它們地位完全平等。沒有任何一個會因為寫在檔案前面就「先跑」—— 第 2 節會把這件事變成關於事件區域的精確陳述，第 8 節則會把它變成關於競爭條件的警告。これは実務上二つの意味を持つ。第一に、実際の設計はこのように書かれる：データパスは手で選んだ加算器やマルチプレクサからなる構造的なネットリストであることが多く、それを駆動するコントローラは同じファイル内の振る舞い記述のステートマシンである。第二に、より微妙な点として、これらの構文は一つひとつがシミュレータから見れば別個のプロセスである。連続代入は右辺が変化するたびに再実行されるプロセスである。ゲートプリミティブは入力が変化するたびに再実行されるプロセスである。always ブロックはイベント制御が満たされるたびに再実行されるプロセスである。これらはすべて対等である。ファイル中で先に書かれているからといって「先に走る」ものはない。第 2 節ではこれをイベント領域についての厳密な記述に変え、第 8 節では競合状態への警告に変える。

The carry look-ahead adder of §7.6 is the lecture's showcase of this mixing: the generate and propagate terms are continuous assignments, the carry chain is an event-triggered procedural block, and the sum and carry-out are continuous assignments again. Three levels, eleven lines, one module.§7.6 的超前進位加法器就是這種混用的示範：產生項與傳遞項是連續指派，進位鏈是事件觸發的程序區塊，而總和與進位輸出又是連續指派。三個層次，十一行，一個模組。§7.6 のキャリー先見加算器は、この混在の見本である：生成項と伝播項は連続代入、キャリーチェーンはイベント駆動の手続き型ブロック、和とキャリー出力はふたたび連続代入である。三つの階層、十一行、一つのモジュール。

1.2 initial: the one-shot thread1.2 initial：一次性執行緒1.2 initial：一度きりのスレッド

An initial block starts executing at simulation time 0 and runs its body exactly once. When the last statement of the body completes, the thread dies and is never revived. That is the entire semantics — everything else follows from it.initial 區塊在模擬時間 0 開始執行，把本體剛好跑一次。當本體的最後一道敘述執行完，這個執行緒就死掉，永遠不會復活。語意就只有這些 —— 其他一切都是從這裡推出來的。initial ブロックはシミュレーション時刻 0 で実行を開始し、本体をちょうど一度だけ実行する。本体の最後の文が終わるとスレッドは死に、二度と復活しない。意味論はこれだけであり、残りはすべてここから導かれる。

initial                // an "initial" behavior
  begin
    sig_a = 0;         // procedural assignments
    sig_b = 1;         // execute sequentially
    sig_c = 0;
  end

Three consequences are worth spelling out, because exam questions live in all three.有三個推論值得明講，因為三個都是考題的產地。明示しておく価値のある帰結が三つある。試験問題はこの三つすべてに潜んでいるからだ。

• The body is one statement. initial sig_a = 0; is legal and complete. If you want more than one statement you must wrap them in begin ... end (sequential) or fork ... join (parallel). A missing begin is the classic beginner's bug: only the first statement belongs to the block and the rest become module-level garbage that will not compile.本體就是一道敘述。initial sig_a = 0; 是合法而完整的。如果你想放不只一道敘述，就必須用 begin ... end（循序）或 fork ... join（平行）包起來。漏掉 begin 是最典型的新手錯誤：只有第一道敘述屬於這個區塊，其餘變成模組層級的垃圾，根本編不過。本体は一つの文である。initial sig_a = 0; は合法かつ完結している。二つ以上の文を書きたければ begin ... end（逐次）または fork ... join（並列）で囲まねばならない。begin の書き忘れは初心者の定番のバグである：最初の文だけがブロックに属し、残りはモジュールレベルのゴミとなってコンパイルが通らない。
• "Runs once" does not mean "finishes at time 0". An initial block containing #10, @(posedge clk) or wait(done) suspends and resumes; it may still be running at time 10 000. What it will never do is restart.「跑一次」不等於「在時間 0 跑完」。含有 #10、@(posedge clk) 或 wait(done) 的 initial 區塊會暫停再恢復；它在時間 10 000 時可能都還在跑。它唯一不會做的事，是重新開始。「一度だけ走る」は「時刻 0 で終わる」という意味ではない。#10、@(posedge clk)、wait(done) を含む initial ブロックは中断と再開を繰り返す。時刻 10 000 でもまだ走っているかもしれない。決して行わないのは、やり直すことだけである。
• Multiple initial blocks all start at time 0 in unspecified order. If two of them write the same variable at time 0, the result is implementation-dependent. This is the simplest possible race condition and it is entirely your fault, not the simulator's.多個 initial 區塊都在時間 0 啟動，順序未定義。如果其中兩個在時間 0 寫同一個變數，結果就取決於實作。這是最單純的競爭條件，而且完全是你的錯，不是模擬器的錯。複数の initial ブロックはすべて時刻 0 に、順序未定義で起動する。そのうち二つが時刻 0 に同じ変数へ書き込めば、結果は処理系依存となる。これは最も単純な競合状態であり、責任は完全に書き手にあってシミュレータにはない。

initial is not synthesisable. There is no silicon that "does something once at power-up" unless you build a reset sequencer for it, and a synthesis tool is not going to invent one. Its home is the test bench, where it is used for stimulus sequences, for $monitor setup, for clock initialisation, and for the #T $finish; watchdog that stops a run that would otherwise never terminate.initial 不可合成。除非你自己做一個重置序列器，否則沒有任何矽片會「在上電時做一次某件事」，而合成工具也不會替你發明一個。它的歸宿是測試平台：用來寫激勵序列、設定 $monitor、初始化時脈，以及寫那個 #T $finish; 看門狗，好讓本來永遠不會停的模擬停下來。initial は合成できない。リセットシーケンサを自分で作らない限り「電源投入時に一度だけ何かをする」シリコンは存在せず、合成ツールがそれを発明してくれることもない。その居場所はテストベンチであり、刺激シーケンス、$monitor の設定、クロックの初期化、そして放っておけば終わらない実行を止める #T $finish; のウォッチドッグに使われる。

1.3 always: the cyclic thread1.3 always：循環執行緒1.3 always：循環するスレッド

An always block is an infinite loop. It starts at time 0, executes its body, and then immediately starts executing its body again, forever, until the simulation ends. That is also the entire semantics, and the slide's phrase "cyclic (repetitive) activity flow" is exactly right.always 區塊就是一個無窮迴圈。它在時間 0 啟動，執行本體，然後立刻又開始執行本體，永遠如此，直到模擬結束。語意也就只有這些，而投影片上「循環（重複）的活動流程」這句話說得完全正確。always ブロックは無限ループである。時刻 0 に起動して本体を実行し、終わると直ちにまた本体を実行し、シミュレーションが終わるまでそれを永遠に繰り返す。意味論もこれだけであり、スライドの「循環的（反復的）なアクティビティフロー」という表現はまさに正しい。

always @ (b or c or d) begin
  if (b == 1'b1) begin
    a = c;
  end
  else begin
    a = d;
  end
end

The event control @(b or c or d) is not part of the always construct — it is simply the first statement of the body. Read the block as: "forever: wait for a change on b, c or d; then run the if/else". That reading immediately explains the single most common way to hang a simulator:事件控制 @(b or c or d) 並不是 always 構造的一部分 —— 它只不過是本體的第一道敘述。把這個區塊讀成：「永遠重複：等 b、c 或 d 變化；然後執行那個 if/else」。這樣讀立刻就能解釋，為什麼最常見的模擬器當機寫法會是這樣：イベント制御 @(b or c or d) は always 構文の一部ではない。単に本体の最初の文にすぎない。このブロックは「永遠に繰り返す：b、c、d のいずれかの変化を待ち、それから if/else を実行する」と読めばよい。こう読めば、シミュレータをハングさせる最も一般的な書き方がただちに説明できる。

always
  a = b & c;      // no time control at all

always @ (b or c)
  a = b & c;      // suspends on the event control

The left-hand version is a zero-delay infinite loop. The simulator will execute it an unbounded number of times without ever advancing simulated time, so the run appears to freeze while one CPU core spins at 100%. Every always block must contain at least one construct that consumes simulation time — an event control, a delay control, or a wait — somewhere on every path through the body.左邊那個版本是零延遲無窮迴圈。模擬器會在模擬時間完全不前進的情況下把它執行無限多次，於是整個執行看起來像凍住了，而某一顆 CPU 核心以 100% 空轉。每個 always 區塊都必須在通過本體的每一條路徑上，至少含有一個會消耗模擬時間的構造 —— 事件控制、延遲控制，或一個 wait。左の版はゼロ遅延の無限ループである。シミュレータはシミュレーション時間をまったく進めずにこれを無限回実行するため、実行は凍りついたように見え、CPU コアの一つが 100% で空回りする。すべての always ブロックは、本体を通るあらゆる経路のどこかに、シミュレーション時間を消費する構文——イベント制御、遅延制御、あるいは wait——を少なくとも一つ含まねばならない。

The example block is a two-to-one multiplexer. Its sensitivity list names every signal the body reads: b because the condition tests it, c and d because the branches read them. Omit d and the simulation will fail to update a when d changes, while synthesis will build a mux that does update — the canonical simulation/synthesis mismatch, treated in detail in §2.7. Verilog-2001's always @* (or @(*)) builds the list automatically and should be used for every combinational block in new code.範例區塊是一個二選一多工器。它的敏感度列表列出本體讀取的每一個訊號：b 因為條件要測試它，c 與 d 因為兩個分支會讀它們。少寫一個 d，模擬就會在 d 改變時忘了更新 a，而合成卻會做出一個真的會更新的多工器 —— 這就是經典的模擬／合成不一致，§2.7 會詳談。Verilog-2001 的 always @*（或 @(*)）會自動建出這份列表，新寫的程式碼裡每一個組合邏輯區塊都該用它。例として挙げられているブロックは 2 対 1 のマルチプレクサである。その感度リストには本体が読む信号がすべて並ぶ：条件が評価する b、各分岐が読む c と d である。d を書き落とすと、シミュレーションは d が変化しても a を更新しないのに、合成はきちんと更新するマルチプレクサを作る——これが典型的なシミュレーション／合成の不一致であり、§2.7 で詳しく扱う。Verilog-2001 の always @*（または @(*)）はこのリストを自動生成するので、新しいコードの組合せ論理ブロックにはすべてこれを使うべきである。

1.4 What a behavior may drive1.4 行為描述可以驅動什麼1.4 振る舞いが駆動できるもの

Statements inside initial and always blocks are procedural statements, and procedural assignments may only target register variables — reg, integer, real, time, realtime and memories. They may not target nets. The reason is structural rather than arbitrary: a net models a physical wire whose value is resolved from its drivers, and a procedural block is not a driver — it is a thread that writes a value and walks away. A variable can hold that value between writes; a net cannot, because a net with no active driver goes to z.initial 與 always 區塊裡的敘述是程序性敘述，而程序性指派只能寫到暫存器類變數 —— reg、integer、real、time、realtime 以及記憶體。它們不能寫到 net。理由是結構上的，不是隨便規定的：net 模擬的是一條實體導線，它的值由驅動者解析出來，而程序區塊並不是驅動者 —— 它只是一個寫個值就走人的執行緒。變數可以在兩次寫入之間把值保留住；net 不行，因為沒有作用中驅動者的 net 會變成 z。initial と always ブロックの中の文は手続き型文であり、手続き型代入が書き込めるのはレジスタ型変数——reg、integer、real、time、realtime、およびメモリ——に限られる。ネットには書き込めない。理由は恣意的なものではなく構造的である：ネットは駆動源から値が解決される物理的な配線のモデルであるのに対し、手続き型ブロックは駆動源ではなく、値を書いて立ち去るスレッドにすぎない。変数は書き込みと書き込みの間その値を保持できるが、ネットは保持できない。能動的な駆動源のないネットは z になるからである。

The lecture flags one exception: force ... release, which can drive a net from inside a procedural block. It gets its own treatment in §3.3, and the reason it is allowed is that force does not write a value and leave — it installs a persistent override that behaves like a driver until release removes it.講義指出一個例外：force ... release 可以從程序區塊內部驅動 net。§3.3 會專門處理它，而它之所以被允許，是因為 force 不是寫個值就走 —— 它安裝了一個持續性的覆寫，其行為就像一個驅動者，直到 release 把它拿掉為止。講義は例外を一つ挙げている：force ... release は手続き型ブロックの中からネットを駆動できる。これは §3.3 で改めて扱うが、許される理由は、force が値を書いて立ち去るのではなく、release が外すまで駆動源のように振る舞う持続的なオーバライドを設置するからである。

A final terminology warning that catches people every semester: the keyword reg does not mean "register" in the hardware sense. reg means "a variable that holds its value in the simulator's data structures". Whether it becomes a flip-flop, a latch, or a lump of combinational logic is decided entirely by how you assign to it, which is the business of Lectures 5 and 6. A reg assigned in always @* with a complete branch structure becomes pure combinational logic and no storage element appears in the netlist at all.最後一個每學期都害到人的術語警告：關鍵字 reg 不是硬體意義上的「暫存器」。reg 的意思是「一個在模擬器資料結構裡保有自身數值的變數」。它最後會變成正反器、閂鎖，還是一團組合邏輯，完全取決於你怎麼對它指派，那是第 5、6 講的事。一個在 always @* 裡、分支結構完整地被指派的 reg，會變成純組合邏輯，netlist 裡根本不會出現任何儲存元件。最後に、毎学期必ず誰かがつまずく用語上の注意：キーワード reg はハードウェアの意味での「レジスタ」ではない。reg は「シミュレータのデータ構造の中で値を保持する変数」という意味である。それがフリップフロップになるか、ラッチになるか、組合せ論理の塊になるかは、どう代入するかだけで決まり、それは第 5 講と第 6 講の話題である。分岐構造が完備した always @* の中で代入される reg は純粋な組合せ論理となり、ネットリストには記憶素子がまったく現れない。

module q1 (input a, b, output y, output reg z);
  wire t;
  assign t = a & b;
  and  G1 (y, t, a);
  initial z = 0;
  always @(posedge a) z = ~z;
  always #5 $display("tick");
endmodule

2. Blocking vs Non-Blocking Assignment2. 阻斷式與非阻斷式指派2. ブロッキング代入とノンブロッキング代入

The slide states the rule in two lines: a blocking assignment "is completed before the next assignment starts", a non-blocking assignment is "executed in parallel". Both statements are true and neither is usable for debugging, because neither tells you when the update becomes visible to the rest of the design. To get that you have to know what the simulator's event queue looks like, so we start there.投影片用兩行講完規則：阻斷式指派「在下一個指派開始之前就已完成」，非阻斷式指派則是「並行執行」。兩句話都是對的，也都沒辦法拿來除錯，因為兩句都沒告訴你更新在什麼時候才對設計的其餘部分變得可見。要得到那個答案，你必須知道模擬器的事件佇列長什麼樣子，所以我們就從那裡開始。スライドは規則を二行で述べている：ブロッキング代入は「次の代入が始まる前に完了する」、ノンブロッキング代入は「並列に実行される」。どちらも正しいが、どちらもデバッグには使えない。更新が設計の他の部分からいつ見えるようになるのかを、どちらも述べていないからである。それを知るにはシミュレータのイベントキューの姿を知らねばならない。そこで、まずそこから始める。

2.1 The stratified event queue2.1 分層事件佇列2.1 階層化イベントキュー

IEEE 1364 does not describe simulation as "statements executing". It describes it as a loop over time slots, where each time slot contains several ordered regions, and each region is an unordered bag of events. The simulator picks any event from the earliest non-empty region, executes it, puts any new events it generates into the appropriate region, and repeats. Only when every region of the current time slot is empty does simulated time advance.IEEE 1364 不是把模擬描述成「敘述在執行」。它描述成一個對時槽的迴圈，每個時槽含有數個有序的區域，而每個區域是一袋沒有順序的事件。模擬器從最早的非空區域裡任選一個事件執行，把它產生的新事件放進對應的區域，然後重複。只有當目前時槽的每一個區域都空了，模擬時間才會前進。IEEE 1364 はシミュレーションを「文が実行される」とは記述しない。タイムスロットを回るループとして記述する。各タイムスロットは順序付けられた複数の領域を含み、各領域は順序のないイベントの袋である。シミュレータは最も早い空でない領域から任意のイベントを選んで実行し、生成された新しいイベントを適切な領域に入れ、これを繰り返す。現在のタイムスロットのすべての領域が空になって初めて、シミュレーション時間が進む。

The full standard has five regions. For Lecture 4 you need four of them, in this order:完整的標準有五個區域。就 Lecture 4 而言，你需要其中四個，順序如下：標準の完全な定義には五つの領域がある。Lecture 4 で必要なのはそのうち四つで、順序は次のとおりである。

Two properties of this structure do all the work:這個結構有兩個性質撐起了一切：この構造の二つの性質がすべてを担っている。

• Regions are ordered, events within a region are not. Everything in Active happens before anything in NBA. But if three different always blocks all have an Active event pending, the simulator may run them in any order — and a different simulator, or the same simulator with a different optimisation setting, may choose differently.區域之間有順序，區域之內沒有。Active 裡的每一件事都發生在 NBA 裡任何一件事之前。但如果三個不同的 always 區塊各有一個待處理的 Active 事件，模擬器可以用任意順序執行它們 —— 換一個模擬器，或同一個模擬器換一個最佳化設定，選擇可能就不一樣。領域の間には順序があるが、領域の内部には順序がない。Active にあるものはすべて NBA にあるどれよりも先に起こる。しかし三つの異なる always ブロックがそれぞれ Active イベントを抱えている場合、シミュレータはそれらを任意の順で実行してよい——別のシミュレータなら、あるいは同じシミュレータでも最適化設定が違えば、別の順を選ぶかもしれない。
• Executing an event may add more events to the current region. A blocking assignment to a makes every process sensitive to a active now, inside the same time slot. So a single time slot can contain an arbitrarily long chain of Active events. This is how zero-delay combinational logic settles, and it is why "time 0" in a waveform viewer can hide dozens of intermediate values.執行一個事件可能會往目前這個區域再加入更多事件。對 a 做阻斷式指派，會讓每一個對 a 敏感的行程現在就變成作用中，仍在同一個時槽裡。所以單一個時槽可以含有一條任意長的 Active 事件鏈。零延遲的組合邏輯就是這樣穩定下來的，這也是為什麼波形檢視器裡的「時間 0」可以藏著幾十個中間值。イベントを実行すると現在の領域にさらにイベントが追加されうる。a へのブロッキング代入は、a に感応するすべてのプロセスをいま、同じタイムスロットの中でアクティブにする。したがって一つのタイムスロットは、いくらでも長い Active イベントの連鎖を含みうる。ゼロ遅延の組合せ論理はこうして落ち着くのであり、波形ビューアの「時刻 0」が何十もの中間値を隠しうるのもこのためである。

2.2 What = actually does2.2 = 實際做了什麼2.2 = が実際に行うこと

A blocking assignment a = expr; is a single Active event that does three things without interruption: evaluate expr, write the result into a, and schedule everything sensitive to a. Only then does the calling thread move to the next statement. The name is literal — the assignment blocks the thread until it is finished.阻斷式指派 a = expr; 是單一個 Active 事件，它不被打斷地做三件事：求出 expr、把結果寫進 a、並排程所有對 a 敏感的東西。做完這些，呼叫端的執行緒才往下一道敘述走。這個名字是字面上的意思 —— 指派會阻斷執行緒，直到它做完。ブロッキング代入 a = expr; は単一の Active イベントであり、中断されることなく三つのことを行う：expr を評価し、結果を a に書き込み、a に感応するすべてをスケジュールする。それが済んで初めて、呼び出し側のスレッドは次の文へ進む。名前は文字どおりで、代入は終わるまでスレッドをブロックする。

a = 0;
a = 1;
c = a;     // c = 1  - c sees the value a had one statement earlier

Because the write is immediate and in-region, a blocking assignment creates a visible intermediate value for anything else that happens to run between the two statements. In a single-threaded block this is exactly the behaviour you want from a programming language and exactly the behaviour you want when you are describing combinational logic, where intermediate wires are real.因為寫入是立即而且在同一區域內完成的，阻斷式指派會對任何剛好在兩道敘述之間執行的東西，產生一個看得見的中間值。在單執行緒的區塊裡，這正是你對一個程式語言所期待的行為，也正是你描述組合邏輯時想要的行為 —— 在那裡中間導線是真實存在的。書き込みが即時かつ同一領域内で行われるため、ブロッキング代入は、二つの文の間にたまたま走る何かに対して、見える中間値を作り出す。単一スレッドのブロックの中では、これはプログラミング言語に期待する振る舞いそのものであり、中間配線が実在する組合せ論理を記述するときに望む振る舞いそのものでもある。

2.3 What <= actually does2.3 <= 實際做了什麼2.3 <= が実際に行うこと

A non-blocking assignment a <= expr; is two events, not one. The Active half evaluates expr and stashes the result in an anonymous temporary; the thread then immediately moves to the next statement. The NBA half, scheduled in region 3 of the same time slot, writes the stashed value into a.非阻斷式指派 a <= expr; 是兩個事件，不是一個。Active 那一半求出 expr，把結果藏進一個匿名暫存位置；執行緒接著立刻往下一道敘述走。NBA 那一半排在同一時槽的第 3 區域，把藏起來的值寫進 a。ノンブロッキング代入 a <= expr; は一つではなく二つのイベントである。Active 側は expr を評価し、結果を無名の一時領域に退避させる。スレッドはただちに次の文へ進む。NBA 側は同じタイムスロットの第 3 領域にスケジュールされ、退避させた値を a に書き込む。

a = 0;
a <= 1;    // evaluate 1, remember it; a is still 0
c = a;     // c = 0  - the NBA update has not happened yet
           // ... end of the Active region ...
           // NBA region: a becomes 1

The slide's phrase "executed in parallel" means: every non-blocking assignment in the time slot reads its RHS during the Active region, before any of them writes its LHS. So all the reads see the same consistent snapshot of the design, and all the writes land together. That is precisely the behaviour of a bank of flip-flops sharing a clock edge: each flop samples its D input just before the edge, and all the Q outputs change just after it.投影片上「並行執行」這句話的意思是：這個時槽裡的每一個非阻斷式指派，都在 Active 區域讀它的右手邊，而且是在它們任何一個寫左手邊之前。所以所有的讀都看到同一份一致的設計快照，而所有的寫一起落地。這正是一組共用同一個時脈邊緣的正反器的行為：每個正反器在邊緣之前一瞬取樣它的 D 輸入，而所有 Q 輸出在邊緣之後一瞬一起改變。スライドの「並列に実行される」という表現の意味はこうである：そのタイムスロット内のすべてのノンブロッキング代入は、いずれかが左辺に書き込むより前に、Active 領域で右辺を読む。したがってすべての読み出しは同じ整合したスナップショットを見て、すべての書き込みはまとめて反映される。これはまさに、クロックエッジを共有するフリップフロップ群の振る舞いである：各フリップフロップはエッジの直前に D 入力をサンプルし、すべての Q 出力はエッジの直後にそろって変化する。

2.4 A full trace of the swap2.4 交換動作的完整追蹤2.4 スワップの完全トレース

Slides 7 and 8 of Part 1 show four two-line fragments starting from a = 1; b = 0;. Here is the same material traced event by event, which is what you should be able to do under exam conditions.第 1 部的第 7、8 張投影片展示了四個以 a = 1; b = 0; 為起點的兩行片段。以下是同樣的材料，一個事件一個事件地追蹤 —— 這正是你在考場上應該做得出來的事。パート 1 のスライド 7 と 8 は、a = 1; b = 0; から始まる二行の断片を四つ示している。以下は同じ題材をイベント単位でトレースしたものであり、試験の場で自力でできるようになっておくべき作業である。

That order-independence is the property you are buying when you use <=, and it is worth stating as a rule you can apply without thinking: inside one clocked block, if every assignment is non-blocking, the textual order of the statements cannot change the result. Inside the same block with blocking assignments, the order changes the result and therefore changes the hardware.這種與順序無關的性質，正是你使用 <= 所換來的東西，而且值得寫成一條可以不假思索套用的規則：在一個時脈同步區塊裡，若每一個指派都是非阻斷式的，敘述的文字順序就不可能改變結果。同一個區塊若改用阻斷式指派，順序會改變結果，因此也就改變了硬體。この順序非依存性こそ <= を使うことで得られる性質であり、考えずに適用できる規則として述べておく価値がある：一つのクロック同期ブロックの中で、すべての代入がノンブロッキングであれば、文の記述順序は結果を変えられない。同じブロックをブロッキング代入で書けば、順序が結果を変え、したがってハードウェアを変える。

2.5 Why the shift-register idiom needs <=2.5 為什麼移位暫存器慣用寫法需要 <=2.5 シフトレジスタの定石に <= が要る理由

Here is the canonical three-stage shift register, written both ways. Both compile. Both simulate without a warning. They are different circuits.以下是標準的三級移位暫存器，兩種寫法都列出來。兩者都編得過。兩者模擬時都不會有警告。它們是不同的電路。以下は標準的な三段シフトレジスタを両方の書き方で示したものである。どちらもコンパイルが通る。どちらも警告なしにシミュレーションできる。そして両者は別の回路である。

always @ (posedge clk) begin
  q1 <= d;
  q2 <= q1;
  q3 <= q2;
end

always @ (posedge clk) begin
  q1 = d;
  q2 = q1;
  q3 = q2;
end

Trace the left-hand version at a rising edge where d=1 and the current state is q1=0, q2=0, q3=0. Three Active events evaluate d→1, q1→0 and q2→0 and stash them. Three NBA events then write q1←1, q2←0, q3←0. The data advanced exactly one stage. Repeat for three edges and the 1 walks q1 → q2 → q3. That is a shift register.在 d=1 且目前狀態為 q1=0、q2=0、q3=0 的某個上升緣，追蹤左邊那個版本。三個 Active 事件分別求出 d→1、q1→0、q2→0 並把它們藏起來。接著三個 NBA 事件寫入 q1←1、q2←0、q3←0。資料剛好前進一級。重複三個邊緣，那個 1 就沿著 q1 → q2 → q3 走。這才是移位暫存器。d=1 で現在の状態が q1=0、q2=0、q3=0 である立ち上がりエッジで、左の版をトレースしてみる。三つの Active イベントが d→1、q1→0、q2→0 を評価して退避する。続いて三つの NBA イベントが q1←1、q2←0、q3←0 を書き込む。データはちょうど一段進んだ。エッジを三回繰り返せば、その 1 は q1 → q2 → q3 と歩いていく。これがシフトレジスタである。

Trace the right-hand version at the same edge. Active event 1 writes q1←1 immediately. Active event 2 evaluates q1, which is now 1, and writes q2←1. Active event 3 writes q3←1. All three outputs change on the same edge, and d arrives at q3 in one clock cycle instead of three.同一個邊緣，追蹤右邊那個版本。Active 事件 1 立刻寫入 q1←1。Active 事件 2 求 q1，此時它已經是 1，於是寫入 q2←1。Active 事件 3 寫入 q3←1。三個輸出在同一個邊緣一起改變，而 d 只花一個時脈週期就抵達 q3，不是三個。同じエッジで右の版をトレースする。Active イベント 1 はただちに q1←1 を書き込む。Active イベント 2 は q1 を評価するが、それはすでに 1 なので q2←1 を書き込む。Active イベント 3 は q3←1 を書き込む。三つの出力が同じエッジでそろって変化し、d は三クロックではなく一クロックで q3 に到達する。

Synthesis sees it the same way. A synthesis tool reads a blocking assignment as "compute this value and make it available to the following statements in the same evaluation", which is the definition of a combinational intermediate. So q2 = q1 immediately after q1 = d does not read the flip-flop output q1 — it reads the wire carrying d. The resulting netlist has one flip-flop whose Q fans out to three names, or, depending on how the tool handles the unused registers, three flip-flops all loaded with d. Either way the circuit is wrong and the gate-level simulation will disagree with the RTL simulation.合成的看法也一樣。合成工具把阻斷式指派讀成「算出這個值，並讓它在同一次求值中供後續敘述使用」，這就是組合邏輯中間節點的定義。所以緊接在 q1 = d 之後的 q2 = q1 讀到的不是正反器輸出 q1 —— 它讀到的是那條載著 d 的線。產生出來的 netlist 會有一個正反器，其 Q 扇出到三個名字；或者，視工具怎麼處理那些沒用到的暫存器而定，變成三個都載入 d 的正反器。無論哪一種，電路都是錯的，而閘級模擬會和 RTL 模擬對不上。合成の見方も同じである。合成ツールはブロッキング代入を「この値を計算し、同じ評価内の後続の文から使えるようにする」と読む。これは組合せ論理の中間ノードの定義そのものである。したがって q1 = d の直後の q2 = q1 が読むのはフリップフロップ出力の q1 ではなく、d を運ぶ配線である。得られるネットリストは、Q が三つの名前にファンアウトするフリップフロップ一つになるか、未使用レジスタの扱い方によっては d を取り込むフリップフロップ三つになる。いずれにせよ回路は誤りであり、ゲートレベルシミュレーションは RTL シミュレーションと食い違う。

2.6 Why the combinational idiom needs =2.6 為什麼組合邏輯慣用寫法需要 =2.6 組合せ論理の定石に = が要る理由

Now invert the situation. Combinational logic has no storage, so a multi-step computation inside always @* is a chain of wires, and every step must see the value the previous step just produced.現在把情況反過來。組合邏輯沒有儲存，所以 always @* 裡的多步驟運算就是一串導線，而每一步都必須看到前一步剛產生的值。今度は状況を逆にする。組合せ論理には記憶がないので、always @* の中の多段計算は配線の連鎖であり、各段は前段がいま生み出した値を見なければならない。

always @* begin
  t1 = a ^ b;
  t2 = t1 & c;
  y  = t2 | d;
end

always @* begin
  t1 <= a ^ b;
  t2 <= t1 & c;
  y  <= t2 | d;
end

In the right-hand version, t2's RHS reads the value t1 held before this evaluation, because the NBA update of t1 has not fired yet. The block therefore computes y from a one-evaluation-old t1 and a two-evaluation-old t2.在右邊那個版本裡，t2 的右手邊讀到的是 t1 在這次求值之前所持有的值，因為 t1 的 NBA 更新還沒發動。於是這個區塊是用舊一次求值的 t1 和舊兩次求值的 t2 來算 y。右の版では、t2 の右辺はこの評価の前に t1 が保持していた値を読む。t1 の NBA 更新がまだ発火していないからである。したがってこのブロックは、一評価分古い t1 と二評価分古い t2 から y を計算する。

What saves the right-hand version from being outright broken in simulation is that t1 and t2 appear in the implicit sensitivity list of always @*. When the NBA region writes t1, that is a change on t1, which retriggers the block, which recomputes t2, which retriggers the block again... The block converges to the correct answer after three extra evaluations, in three extra NBA cycles, all at the same simulation time. So the final waveform is right and the intermediate waveform is a mess — and if you had written always @(a or b or c or d) with an explicit list that does not mention t1 and t2, it would never converge at all and y would simply be wrong.右邊那個版本之所以沒有在模擬中徹底壞掉，是因為 t1 和 t2 都出現在 always @* 的隱含敏感度列表裡。當 NBA 區域寫入 t1，那就是 t1 上的一次變化，於是重新觸發這個區塊，於是重算 t2，於是又重新觸發這個區塊……這個區塊在多花三次求值、多花三個 NBA 迴圈之後收斂到正確答案，而且全都發生在同一個模擬時間。所以最終波形是對的，中間波形一團亂 —— 而如果你寫的是 always @(a or b or c or d) 這種沒有提到 t1 和 t2 的明確列表，它根本永遠不會收斂，y 就乾脆是錯的。右の版がシミュレーションで完全に壊れずに済むのは、t1 と t2 が always @* の暗黙の感度リストに入っているからである。NBA 領域が t1 を書き込むと、それは t1 の変化であり、ブロックを再トリガし、t2 を再計算させ、それがまたブロックを再トリガする……。ブロックは追加の三回の評価、追加の三回の NBA サイクルを経て正しい答えに収束し、それらはすべて同一のシミュレーション時刻で起こる。つまり最終波形は正しく、途中の波形はひどいことになる。もし t1 と t2 を書いていない明示リスト always @(a or b or c or d) を書いていたなら、収束すらせず y はただ誤った値になる。

Synthesis, meanwhile, ignores the whole question and builds the same combinational cone in both cases. So the right-hand version is the classic mismatch in the other direction: the netlist is right, the RTL simulation is wrong or at best full of spurious transitions.另一方面，合成完全不理會這個問題，兩種寫法都建出同一個組合邏輯錐。所以右邊那個版本是另一個方向的經典不一致：netlist 是對的，RTL 模擬是錯的，最好的情況也只是充滿虛假的轉態。一方、合成はこの問題をまったく無視し、どちらの書き方からも同じ組合せ論理コーンを作る。したがって右の版は逆方向の典型的な不一致である：ネットリストは正しく、RTL シミュレーションが誤っているか、よくても偽の遷移だらけになる。

2.7 What a simulation/synthesis mismatch looks like2.7 模擬／合成不一致長什麼樣子2.7 シミュレーション／合成の不一致とはどういうものか

"Mismatch" is a vague word, so here is a concrete catalogue of the four ways this lecture's material produces one, with the symptom you will actually see.「不一致」是個模糊的詞，所以這裡列出本講材料會造成不一致的四種具體情況，連同你實際會看到的症狀。「不一致」は曖昧な言葉なので、本講義の題材がそれを生む四つの具体的な経路を、実際に目にする症状とともに一覧にしておく。

Notice the asymmetry. A sensitivity-list bug or an NBA-in-combinational bug makes the simulation pessimistic and the netlist correct. A blocking-in-clocked bug or a latch inference makes the simulation optimistic and the netlist wrong. The second kind is far more dangerous, because your test bench passes.注意這裡的不對稱。敏感度列表的錯、或組合邏輯裡用 NBA 的錯，會讓模擬偏悲觀而 netlist 正確。時脈同步區塊用阻斷式的錯、或推斷出閂鎖，則會讓模擬偏樂觀而 netlist 錯誤。第二種危險得多，因為你的測試平台會通過。ここにある非対称性に注目したい。感度リストのバグや組合せ論理での NBA のバグは、シミュレーションを悲観的にし、ネットリストを正しくする。クロック同期ブロックでのブロッキングのバグやラッチ推論は、シミュレーションを楽観的にし、ネットリストを誤らせる。後者のほうがはるかに危険である。テストベンチが通ってしまうからだ。

2.8 The merged four-flavour example2.8 四種寫法合併的範例2.8 四種類を併記した例

Slides 9 and 10 of Part 1 put all four combinations of (blocking / non-blocking) × (delay before the statement / delay inside the assignment) into one module. It is the single best exam question in the lecture, so work through it rather than memorising the answer.第 1 部的第 9、10 張投影片把（阻斷式／非阻斷式）×（延遲放在敘述之前／延遲放在指派內部）這四種組合全部塞進一個模組。這是整個講次裡最好的一道考題，所以請把它推一遍，不要背答案。パート 1 のスライド 9 と 10 は、（ブロッキング／ノンブロッキング）×（文の前に遅延／代入の内部に遅延）の四つの組合せをすべて一つのモジュールに詰め込んでいる。この講義で最良の試験問題なので、答えを暗記せずに自分で追ってほしい。

module blocking_nonblocking();
reg a, b, c, d;

initial begin            // (A) blocking, inter-assignment delay
  #10 a = 0;
  #11 a = 1;
  #12 a = 0;
  #13 a = 1;
end

initial begin            // (B) non-blocking, inter-assignment delay
  #10 b <= 0;
  #11 b <= 1;
  #12 b <= 0;
  #13 b <= 1;
end

initial begin            // (C) blocking, intra-assignment delay
  c = #10 0;
  c = #11 1;
  c = #12 0;
  c = #13 1;
end

initial begin            // (D) non-blocking, intra-assignment delay
  d <= #10 0;
  d <= #11 1;
  d <= #12 0;
  d <= #13 1;
end

initial begin
  $monitor("TIME = %d A = %b B = %b C = %b D = %b", $time, a, b, c, d);
  #50 $finish;
end
endmodule

The key question for each block is: does the thread wait?每個區塊的關鍵問題只有一個：執行緒會不會等？各ブロックについての鍵となる問いは一つだけである：スレッドは待つのか。

• (A) #10 a = 0; — the delay is a statement in its own right that suspends the thread for 10 units. Then the assignment runs. The thread waits, so the delays accumulate: 10, 10+11 = 21, 21+12 = 33, 33+13 = 46.(A) #10 a = 0; —— 這個延遲本身就是一道敘述，會讓執行緒暫停 10 個單位。然後指派才執行。執行緒會等，所以延遲會累加：10、10+11 = 21、21+12 = 33、33+13 = 46。(A) #10 a = 0; —— この遅延はそれ自体が一つの文であり、スレッドを 10 単位中断させる。そのあとで代入が走る。スレッドが待つので遅延は積み上がる：10、10+11 = 21、21+12 = 33、33+13 = 46。
• (B) #10 b <= 0; — the #10 is still a leading delay control, so the thread still waits 10 units. The non-blocking operator only affects what happens after the thread resumes: the RHS is evaluated at t=10 and the update lands in the NBA region of t=10. The visible times are identical to (A): 10, 21, 33, 46.(B) #10 b <= 0; —— #10 仍然是前置的延遲控制，所以執行緒照樣等 10 個單位。非阻斷式運算子只影響執行緒恢復之後的事：右手邊在 t=10 求值，而更新落在 t=10 的 NBA 區域。看得見的時間與 (A) 完全相同：10、21、33、46。(B) #10 b <= 0; —— #10 は依然として先頭の遅延制御なので、スレッドはやはり 10 単位待つ。ノンブロッキング演算子が影響するのはスレッドが再開した後のことだけである：右辺は t=10 で評価され、更新は t=10 の NBA 領域に落ちる。観測される時刻は (A) とまったく同じ：10、21、33、46。
• (C) c = #10 0; — the delay is inside the assignment. The RHS is evaluated immediately, then the assignment itself is postponed by 10. Because the operator is blocking, the thread is not allowed to proceed until the assignment completes, so it still waits: 10, 21, 33, 46.(C) c = #10 0; —— 延遲在指派內部。右手邊立刻求值，然後指派本身被延後 10。因為運算子是阻斷式的，執行緒在指派完成之前不得前進，所以它照樣等：10、21、33、46。(C) c = #10 0; —— 遅延は代入の内部にある。右辺はただちに評価され、代入そのものが 10 だけ先送りされる。演算子がブロッキングなのでスレッドは代入が完了するまで先へ進めず、やはり待つ：10、21、33、46。
• (D) d <= #10 0; — the RHS is evaluated immediately and a future update is scheduled; the thread does not wait. All four statements execute at t=0 and schedule updates at t = 10, 11, 12 and 13 respectively. The thread then finishes.(D) d <= #10 0; —— 右手邊立刻求值，並排程一個未來的更新；執行緒不等。四道敘述全都在 t=0 執行，分別把更新排在 t = 10、11、12、13。然後執行緒就結束了。(D) d <= #10 0; —— 右辺はただちに評価され、将来の更新がスケジュールされる。スレッドは待たない。四つの文はすべて t=0 で実行され、更新をそれぞれ t = 10、11、12、13 に予約する。そしてスレッドは終了する。

TIME =  0 A = x B = x C = x D = x
TIME = 10 A = 0 B = 0 C = 0 D = 0
TIME = 11 A = 0 B = 0 C = 0 D = 1
TIME = 12 A = 0 B = 0 C = 0 D = 0
TIME = 13 A = 0 B = 0 C = 0 D = 1
TIME = 21 A = 1 B = 1 C = 1 D = 1
TIME = 33 A = 0 B = 0 C = 0 D = 1
TIME = 46 A = 1 B = 1 C = 1 D = 1

always @(posedge clk) begin
  stage1 = a & b;
  stage2 = stage1;
  y      = stage2;
end

always @(posedge clk) begin
  stage1 <= a & b;
  stage2 <= stage1;
  y      <= stage2;
end

3. Procedural Continuous Assignment3. 程序性連續指派3. 手続き型連続代入

3.1 Why the construct exists at all3.1 這個構造究竟為什麼存在3.1 そもそもこの構文が存在する理由

Section 1.4 established a clean division: continuous assignments drive nets and live at module level; procedural assignments write variables and live inside behaviors. Procedural continuous assignment (PCA) deliberately breaks that division. A PCA is executed like a procedural statement — it sits inside an always or initial block and runs when the thread reaches it — but once executed it behaves like a continuous assignment: it installs a permanent binding so the target keeps tracking the right-hand expression even when the procedural block is long since suspended.1.4 節定出了一條乾淨的分界：連續指派驅動 net，住在模組層級；程序性指派寫變數，住在行為描述內部。程序性連續指派（PCA）刻意打破這條分界。PCA 的執行方式像一道程序性敘述 —— 它待在 always 或 initial 區塊裡，執行緒走到它才跑 —— 但一旦執行，它的行為就像連續指派：它安裝了一個永久的繫結，使得目標即使在程序區塊早就暫停之後，仍然持續追蹤右手邊的運算式。1.4 節は明快な区分を立てた：連続代入はネットを駆動し、モジュールレベルに置かれる。手続き型代入は変数に書き込み、振る舞いの内部に置かれる。手続き型連続代入（PCA）はこの区分を意図的に壊す。PCA は手続き型文のように実行される——always や initial ブロックの中にあり、スレッドがそこに達したときに走る——が、いったん実行されると連続代入のように振る舞う：恒久的な結び付きを設置し、手続き型ブロックがとうに中断した後も、対象が右辺の式を追い続けるようにする。

The motivation is asynchronous override. Think of a flip-flop with an asynchronous clear. While clear is low, the output must be 0 continuously, independent of the clock, and must ignore anything the clocked behavior tries to do. When clear returns high, the clocked behavior must take back control. That is an override with a beginning and an end, which is awkward to express with ordinary procedural assignments and natural to express with assign ... deassign. Verilog provides two flavours of PCA and they differ in what they can target and in how hard they push.動機是非同步覆寫。想想一個帶非同步清除的正反器。當 clear 為低時，輸出必須持續為 0，與時脈無關，而且必須無視時脈同步行為想做的任何事。當 clear 回到高時，時脈同步行為必須重新取回控制權。那是一個有起點也有終點的覆寫，用普通的程序性指派很難表達，用 assign ... deassign 表達卻很自然。Verilog 提供兩種 PCA，差別在於它們能鎖定什麼目標，以及推得多用力。動機は非同期オーバライドである。非同期クリア付きのフリップフロップを考えてほしい。clear が Low の間、出力はクロックとは無関係に継続的に 0 でなければならず、クロック同期の振る舞いが何をしようと無視しなければならない。clear が High に戻れば、クロック同期の振る舞いが制御を取り戻さねばならない。これは始まりと終わりのあるオーバライドであり、普通の手続き型代入では表しにくく、assign ... deassign では自然に表せる。Verilog は PCA を二種類用意しており、対象にできるものと押しの強さが違う。

3.2 Method 1: assign ... deassign3.2 方法一：assign ... deassign3.2 方法 1：assign ... deassign

The rules from slide 11 of Part 1, with the reasoning attached:以下是第 1 部第 11 張投影片上的規則，並附上理由：以下はパート 1 のスライド 11 にある規則に、理由を添えたものである。

• Target must be a register variable, and a whole one — you may not assign to a bit-select, a part-select or a memory word. A net already has continuous-assignment semantics of its own, so there would be nothing for a PCA to add.目標必須是暫存器類變數，而且必須是完整的一個 —— 你不可以 assign 到位元選取、部分選取或記憶體的某一字。net 本身就已經有連續指派的語意了，所以 PCA 在它身上加不了什麼。対象はレジスタ型変数でなければならず、しかもその全体でなければならない——ビット選択、部分選択、メモリのワードに assign してはならない。ネットはすでに連続代入の意味論を自前で持っているので、PCA が加えるものは何もない。
• The binding is dynamic. It comes into existence when the statement executes and not before, which is what makes it useful for modelling a control signal that is only sometimes active.這個繫結是動態的。它在敘述執行的那一刻才誕生，在那之前並不存在，而這正是它適合用來描述「只在某些時候才作用」的控制訊號的原因。結び付きは動的である。文が実行された時点で生まれ、それ以前には存在しない。これこそ、ときどきしか有効にならない制御信号のモデル化に向いている理由である。
• It overrides all ordinary procedural assignments to that register. While the binding is in place, an always @(posedge clk) q = data; elsewhere in the module will execute and have no visible effect.它會覆寫對該暫存器的所有普通程序性指派。在繫結存在期間，模組裡別處的 always @(posedge clk) q = data; 照樣會執行，但不會有任何看得見的效果。そのレジスタへの通常の手続き型代入をすべてオーバライドする。結び付きが有効な間、モジュール内の別の場所にある always @(posedge clk) q = data; は実行はされるが、目に見える効果を持たない。
• The binding persists until deassign, or until a new PCA to the same register replaces it. deassign is optional in the sense that you are not obliged to write one; it is not optional in the sense that without it the register is permanently captured.繫結會持續到 deassign，或直到對同一暫存器的新 PCA 取代它為止。deassign 在「你沒有義務一定要寫」的意義上是選用的；但在「不寫就等於把那個暫存器永久扣押」的意義上，它一點都不選用。結び付きは deassign まで、あるいは同じレジスタへの新しい PCA がそれを置き換えるまで持続する。deassign は「必ず書かねばならないわけではない」という意味では任意だが、「書かなければそのレジスタを永久に押さえたままになる」という意味ではまったく任意ではない。
• After deassign the register keeps the value it had. It does not revert; it simply becomes writable again, and the next ordinary procedural assignment takes effect.deassign 之後，暫存器保留它當時的值。它不會回復原狀；只是變回可寫，下一個普通程序性指派就會生效。deassign の後、レジスタはその時点の値を保つ。元に戻るのではなく、単に再び書き込み可能になり、次の通常の手続き型代入が効くようになる。
• Synthesis tools might not support it. In practice most do not. Treat PCA as modelling and verification machinery, not RTL.合成工具可能不支援。實務上多數都不支援。請把 PCA 當成建模與驗證的機制，不要當成 RTL。合成ツールは対応していないことがある。実際にはほとんど対応していない。PCA はモデリングと検証のための道具であって RTL ではない、と考えるべきである。

Example 1 — a multiplexer written with PCA範例 1 — 用 PCA 寫出來的多工器例 1 — PCA で書いたマルチプレクサ

module mux4_PCA (a, b, c, d, select, y_out);
  input       a, b, c, d;
  input [1:0] select;
  output      y_out;
  reg         y_out;

  always @ (select) begin              // Caution!!
    if      (select == 0) assign y_out = a;
    else if (select == 1) assign y_out = b;
    else if (select == 2) assign y_out = c;
    else if (select == 3) assign y_out = d;
    else                  assign y_out = 1'b0;
  end
endmodule

Example 2 — flip-flop with asynchronous clear and preset Non-synthesized範例 2 — 帶非同步清除與預設的正反器 不可合成例 2 — 非同期クリアとプリセット付きフリップフロップ 合成不可

module Flop_PCA (preset, clear, q, qbar, clock, data);
  input  preset, clear, clock, data;
  output q, qbar;
  reg    q;

  assign qbar = ~q;                   // ordinary continuous assignment on a net

  always @ (negedge clock)
    q = data;                         // ordinary procedural assignment

  always @ (clear or preset)
    begin
      if      (!clear)  assign q = 0; // PCA: clear dominates
      else if (!preset) assign q = 1; // PCA: preset
      else              deassign q;   // clock regains control
    end
endmodule

Walk through a sequence to see the override in action. Suppose clear and preset are both high and the clock is running; q follows data on every falling edge. Now clear goes low at t=100. The second block wakes, takes the first branch and installs assign q = 0. From t=100 onwards q is 0 and stays 0 — the falling edges still wake the first block, it still executes q = data, and the PCA binding discards the write. At t=200 clear returns high, the second block wakes again, both conditions are false, and deassign q removes the binding. q is now 0 and remains 0 until the next falling clock edge, which is the correct behaviour for a flip-flop coming out of clear.走一段時序，就看得到覆寫在運作。假設 clear 與 preset 都是高電位、時脈在跑；q 在每個下降緣跟隨 data。現在 clear 在 t=100 變低。第二個區塊醒來，走第一個分支，安裝 assign q = 0。從 t=100 起 q 就是 0 而且維持 0 —— 下降緣照樣喚醒第一個區塊，它照樣執行 q = data，而 PCA 繫結把那次寫入丟掉。到 t=200 時 clear 回到高，第二個區塊再度醒來，兩個條件都不成立，於是 deassign q 移除繫結。此刻 q 是 0，而且維持 0 直到下一個時脈下降緣 —— 這正是正反器脫離清除狀態後該有的行為。一連の時刻を追えばオーバライドの働きが見える。clear と preset がともに High でクロックが走っているとする。q は立ち下がりエッジごとに data に追従する。ここで t=100 に clear が Low になる。二つ目のブロックが起きて最初の分岐を取り、assign q = 0 を設置する。t=100 以降 q は 0 であり続ける——立ち下がりエッジは相変わらず一つ目のブロックを起こし、それは相変わらず q = data を実行するが、PCA の結び付きがその書き込みを捨てる。t=200 で clear が High に戻ると二つ目のブロックが再び起き、どちらの条件も成り立たないので deassign q が結び付きを外す。このとき q は 0 であり、次のクロック立ち下がりエッジまで 0 のままである。これはクリアから抜けたフリップフロップの正しい振る舞いである。

Note that qbar is a net driven by an ordinary continuous assignment and is unaffected by any of this — it simply tracks ~q throughout. Note too the priority: clear is tested first, so simultaneous assertion of clear and preset resolves to 0. Real cells generally make that combination illegal rather than giving it a defined answer, which is one reason this model is labelled non-synthesisable.注意 qbar 是一個由普通連續指派驅動的 net，完全不受這一切影響 —— 它自始至終就只是追蹤 ~q。也要注意優先順序：clear 先被測試，所以 clear 與 preset 同時成立時結果是 0。真實的單元通常會把這個組合定為不合法，而不是給它一個有定義的答案，這也是這個模型被標為不可合成的原因之一。qbar は通常の連続代入で駆動されるネットであり、以上のいずれの影響も受けない——終始 ~q を追うだけである。優先順位にも注意したい：clear が先に判定されるので、clear と preset が同時にアサートされた場合の結果は 0 になる。実際のセルはこの組合せに定義された答えを与えるのではなく違法とすることが多く、それがこのモデルが合成不可と記される理由の一つである。

3.3 Method 2: force ... release3.3 方法二：force ... release3.3 方法 2：force ... release

force is the heavier hammer, and the rules from slide 14 differ from assign in exactly the ways that make it a debugging tool rather than a modelling construct:force 是比較重的槌子，而第 14 張投影片上的規則與 assign 的差異，剛好就是讓它成為除錯工具而非建模構造的那幾點：force はより重いハンマーであり、スライド 14 の規則が assign と異なる点は、まさにこれをモデリング構文ではなくデバッグ道具にしている点である。

• The target may be a net or a register. This is the one place in the language where a procedural statement may drive a net.目標可以是 net 或暫存器。這是整個語言裡唯一允許程序性敘述驅動 net 的地方。対象はネットでもレジスタでもよい。手続き型文がネットを駆動してよい、言語中で唯一の場所である。
• On a net it overwrites primitive outputs and continuous assignments. Not "resolves with" — overwrites. The gate keeps computing its output and nobody listens.在 net 上，它會覆蓋基本元件輸出與連續指派。不是「與之解析」—— 是覆蓋。閘繼續算它的輸出，而沒有人在聽。ネットに対しては、プリミティブ出力と連続代入を上書きする。「それらと解決する」のではなく、上書きする。ゲートは出力を計算し続けるが、誰も聞いていない。
• On a register it overrides both procedural assignments and an assign PCA. force therefore sits at the top of the precedence ladder.在暫存器上，它同時覆寫程序性指派與 assign 形式的 PCA。因此 force 坐在優先權階梯的最頂端。レジスタに対しては、手続き型代入と assign 形式の PCA の両方をオーバライドする。したがって force は優先順位のはしごの最上段に座る。
• The binding cannot be removed except by release. Unlike assign, a second force to the same target does not quietly replace the first in a way you can rely on, and nothing else clears it.除了 release，沒有別的方法能移除這個繫結。和 assign 不同，對同一目標再下一次 force，並不會以你可以倚賴的方式悄悄取代前一次，而且也沒有別的東西會清掉它。結び付きは release 以外では外せない。assign と違い、同じ対象への二度目の force が、当てにできる形で最初のものを静かに置き換えてくれるわけではなく、他に解除するものもない。
• What happens on release depends on the target type. A released net immediately reverts to whatever its real drivers say, because the drivers never stopped driving. A released register keeps the forced value until something writes it again. This asymmetry catches people constantly.release 時會發生什麼，取決於目標的型別。被釋放的 net 立刻回到它真正的驅動者所說的值，因為那些驅動者從來沒有停止驅動。被釋放的暫存器則保留被強制的值，直到有東西再寫它為止。這種不對稱性一直在害人。release 時に何が起こるかは対象の型で決まる。解放されたネットは、本来の駆動源が駆動をやめていなかったので、ただちにその値に戻る。解放されたレジスタは、次に何かが書き込むまで強制された値を保つ。この非対称性はつねに人を引っかける。

...
force sig_a = 1;            // internal nodes of the DUT, reached hierarchically
force sig_b = 1;
force sig_c = 0;
sig_in1 = 0;
#5 sig_in1 = 1;
#5 sig_in1 = 0;
// insert code to construct tests
release sig_a;
release sig_b;
release sig_c;
...

The figure on slide 15 explains the use case. Inside the test bench, mod_abc produces sig_a and sig_b, mod_xyz produces sig_c and sig_d, and those feed an AND and an OR gate whose outputs sig_f and sig_g drive mod_def. If you want to test the AND/OR glue and mod_def without first solving the much harder problem of coaxing mod_abc and mod_xyz into producing the pattern you need, you force the three internal nodes directly. Combined with hierarchical names — force top.dut.u1.sig_a = 1; — this lets a test bench reach any node in the design, which is both enormously useful and enormously easy to abuse.第 15 張投影片的圖說明了使用情境。在測試平台裡，mod_abc 產生 sig_a 與 sig_b，mod_xyz 產生 sig_c 與 sig_d，它們餵進一個 AND 與一個 OR 閘，其輸出 sig_f 與 sig_g 再驅動 mod_def。如果你想測 AND/OR 這段黏合邏輯與 mod_def，卻不想先去解「怎麼哄 mod_abc 與 mod_xyz 吐出你要的樣式」這個難得多的問題，你就直接 force 那三個內部節點。再配上階層式名稱 —— force top.dut.u1.sig_a = 1; —— 測試平台就能伸手摸到設計裡任何一個節點，既極其好用，也極其容易被濫用。スライド 15 の図が使いどころを説明している。テストベンチの中で mod_abc が sig_a と sig_b を、mod_xyz が sig_c と sig_d を生み、それらが AND ゲートと OR ゲートに入り、その出力 sig_f と sig_g が mod_def を駆動する。mod_abc と mod_xyz に望みのパターンを吐かせるというはるかに難しい問題を先に解かずに、AND/OR のグルー論理と mod_def を試験したければ、その三つの内部ノードを直接 force すればよい。階層名——force top.dut.u1.sig_a = 1;——と組み合わせれば、テストベンチは設計中のどのノードにも手を伸ばせる。きわめて便利であると同時に、きわめて濫用しやすい。

3.4 The priority ladder3.4 優先權階梯3.4 優先順位のはしご

Putting §3.2 and §3.3 together gives a strict precedence order for a reg that is under attack from several directions at once. Highest wins:把 §3.2 與 §3.3 合起來，就得到一個 reg 同時被好幾個方向攻擊時的嚴格優先順序。最高者勝：§3.2 と §3.3 を合わせると、複数の方向から同時に攻められている reg についての厳密な優先順位が得られる。上位が勝つ。

And on a net:而在 net 上：ネット上では：

The second line is worth a comment. Ordinary net drivers do not override each other — a net with two drivers takes the resolution of the two values, so 0 and 1 together give x on a wire, and a wand/wor/tri resolves differently again (Lecture 3). force does not join that resolution; it bypasses it.第二行值得加個註解。普通的 net 驅動者之間不會互相覆寫 —— 一條有兩個驅動者的 net 取的是兩個值的解析結果，所以 0 與 1 在 wire 上合起來是 x，而 wand／wor／tri 又各自有不同的解析方式（第 3 講）。force 不參加那個解析；它直接繞過去。二行目には註釈をつけておく価値がある。通常のネット駆動源どうしは互いを上書きしない——駆動源が二つあるネットは二つの値の解決結果を取るので、wire 上では 0 と 1 が合わさって x になり、wand／wor／tri はまた別の解決をする（第 3 講）。force はその解決に加わらず、迂回する。

3.5 The assignment-mode table3.5 指派模式對照表3.5 代入モード一覧表

Five of the ten cells follow directly from §1.4. The sixth needs a note: the "Comb — No / Seq — Yes" entry refers to user-defined primitives from Lecture 3. A combinational UDP output must be declared output and is a net. A sequential UDP output must additionally be declared reg, because a sequential UDP has internal state that must be held between table lookups. That is the only situation in which a primitive's output is a register, which is why the cell reads the way it does.十格裡有五格直接由 §1.4 推出。第六格需要加註：「組合 — 不可以／循序 — 可以」那一格講的是第 3 講的使用者自定義基本元件。組合型 UDP 的輸出必須宣告為 output，它是一條 net。循序型 UDP 的輸出則必須額外宣告為 reg，因為循序 UDP 有內部狀態要在兩次查表之間保持住。那是基本元件的輸出唯一會是暫存器的情況，這也就是那一格會那樣寫的原因。十個のセルのうち五個は §1.4 から直接導かれる。六個目には註が要る：「組合せ — 不可／順序 — 可」のセルは第 3 講のユーザ定義プリミティブを指している。組合せ UDP の出力は output と宣言せねばならず、ネットである。順序 UDP の出力はさらに reg と宣言せねばならない。順序 UDP は表引きと表引きの間で保持すべき内部状態を持つからである。プリミティブの出力がレジスタになるのはこの場合だけであり、だからこのセルはこう書かれている。

#1  r = 1;
#1  assign r = 0;
#1  r = 1;
#1  force r = 1;
#1  deassign r;
#1  r = 0;
#1  release r;
#1  r = 0;

4. Procedural Timing Controls4. 程序性時間控制4. 手続き型タイミング制御

A procedural thread runs until it hits something that suspends it. Verilog offers five such mechanisms — delay control #, event control @, the event or list, named events, and wait — and they divide cleanly into time-based (you know when it will resume) and event-based (you do not). Understanding which is which is the whole of this section.一個程序性執行緒會一直跑，直到撞上某個讓它暫停的東西。Verilog 提供五種這樣的機制 —— 延遲控制 #、事件控制 @、事件 or 列表、具名事件，以及 wait —— 它們乾淨地分成以時間為基準的（你知道它何時會恢復）與以事件為基準的（你不知道）。搞清楚哪個是哪個，就是這一節的全部。手続き型スレッドは、自分を中断させる何かにぶつかるまで走り続ける。Verilog はその仕組みを五つ用意している——遅延制御 #、イベント制御 @、イベント or リスト、名前付きイベント、そして wait——これらは時間基準（いつ再開するか分かる）とイベント基準（分からない）にきれいに分かれる。どれがどちらかを理解することが、この節のすべてである。

4.1 Delay control # Non-synthesized4.1 延遲控制 # 不可合成4.1 遅延制御 # 合成不可

#n suspends the thread at the point where the operator appears for exactly n time units, then resumes it. The unit is whatever the enclosing `timescale says it is — #5 under `timescale 1ns/1ps is five nanoseconds, under `timescale 10ps/1ps it is fifty picoseconds. Getting the timescale wrong changes every number in your waveform by a constant factor and is a standard lab-session time sink.#n 在這個運算子出現的位置把執行緒暫停剛好 n 個時間單位，然後讓它恢復。單位是外圍 `timescale 所規定的那個 —— 在 `timescale 1ns/1ps 底下 #5 是五奈秒，在 `timescale 10ps/1ps 底下則是五十皮秒。把 timescale 搞錯，會讓你波形上每一個數字都差一個固定倍數，這是實驗課裡標準的時間黑洞。#n は、この演算子が現れた位置でスレッドをちょうど n 時間単位だけ中断し、その後再開させる。単位は外側の `timescale が定めるものである——`timescale 1ns/1ps の下では #5 は 5 ナノ秒、`timescale 10ps/1ps の下では 50 ピコ秒になる。タイムスケールを取り違えると波形上のすべての数値が一定倍だけずれ、これは実験の時間を食いつぶす定番である。

always
  begin
    #0  clock = 0;
    #50 clock = 1;
    #50;
  end           // period 100

always
  begin
    #clock_period/2;
    clock = ~clock;
  end           // clock must be initialised!

The left-hand generator is self-starting but verbose. Trace it: at t=0 the #0 suspends and resumes within the same time slot (see §6.3), then clock = 0; at t=50 clock = 1; the trailing #50 carries the thread to t=100, where the always loops back and the whole sequence repeats. Period 100, duty cycle 50%.左邊那個產生器會自己啟動，但很囉嗦。追一遍：t=0 時 #0 在同一個時槽內暫停又恢復（見 §6.3），然後 clock = 0；t=50 時 clock = 1；結尾的 #50 把執行緒帶到 t=100，always 在那裡繞回去，整段序列重來。週期 100，工作週期 50%。左の生成器は自己起動するが冗長である。追ってみる：t=0 で #0 が同じタイムスロット内で中断と再開を行い（§6.3 参照）、続いて clock = 0。t=50 で clock = 1。末尾の #50 がスレッドを t=100 まで運び、そこで always がループし、全体が繰り返される。周期 100、デューティ比 50%。

The right-hand generator is the idiom you will actually use, and it has a trap: it inverts clock without ever initialising it. A reg starts at x, and ~x is x, so the clock never leaves the unknown state and every flip-flop in the design stays at x forever. The fix is one line — initial clock = 0; — and the symptom, an entire waveform of red x values with a clock that visibly "toggles" nowhere, is one you should learn to recognise on sight. A second trap: #clock_period/2 parses as (#clock_period)/2 in some readings and is in any case bad style; write #(clock_period/2).右邊那個產生器才是你實際會用的寫法，而它有個陷阱：它反轉 clock，卻從來沒有初始化它。reg 的起點是 x，而 ~x 還是 x，所以時脈永遠離不開未知狀態，設計裡每一個正反器也就永遠停在 x。修法只有一行 —— initial clock = 0; —— 而它的症狀，也就是整片紅色 x 值的波形搭配一個看得出來哪裡都沒「反轉」的時脈，你應該練到一眼就認得出來。第二個陷阱：#clock_period/2 在某些讀法下會解析成 (#clock_period)/2，而且無論如何都是壞風格；請寫 #(clock_period/2)。右の生成器が実際に使う書き方だが、落とし穴がある：clock を反転させるのに一度も初期化していないのである。reg の初期値は x であり、~x もまた x なので、クロックは未知状態から永遠に抜け出せず、設計中のすべてのフリップフロップも永遠に x にとどまる。直し方は一行——initial clock = 0;——であり、その症状、すなわち赤い x だらけの波形と、どこも「トグル」していないクロックの組合せは、一目で見分けられるようになっておくべきである。もう一つの落とし穴：#clock_period/2 は読み方によっては (#clock_period)/2 と解釈され、いずれにせよ悪い書き方である。#(clock_period/2) と書くこと。

Delay controls are not synthesisable. A synthesis tool will either ignore them with a warning — producing a netlist whose behaviour differs from your simulation — or refuse the file. Either way, never put a # in RTL you intend to build.延遲控制不可合成。合成工具要不就是一邊警告一邊忽略它們 —— 產生出行為與你的模擬不同的 netlist —— 要不就是拒收這個檔案。無論哪一種，都不要在你打算做成電路的 RTL 裡放 #。遅延制御は合成できない。合成ツールは警告つきで無視する（シミュレーションと振る舞いの異なるネットリストを生む）か、ファイルを受け付けないかのどちらかである。いずれにせよ、実際に作るつもりの RTL に # を置いてはならない。

4.2 Event control @ Non-synthesized as a statement4.2 事件控制 @ 作為敘述時不可合成4.2 イベント制御 @ 文としては合成不可

@ suspends the thread until a specified event occurs. Unlike #, there is no guarantee it will ever resume: if the event never happens, the thread is suspended forever, which is a perfectly legal and occasionally intentional way for a test bench to deadlock.@ 把執行緒暫停到指定的事件發生為止。與 # 不同，它沒有任何保證說它一定會恢復：如果那個事件永遠不發生，執行緒就永遠暫停，這是完全合法、偶爾也是刻意為之的測試平台死結方式。@ は指定したイベントが起こるまでスレッドを中断する。# と違って再開の保証はない：イベントが決して起こらなければスレッドは永久に中断したままで、これはまったく合法であり、ときにはテストベンチをわざとデッドロックさせる手段にもなる。

...
@ signal_1 a = b;   // wait for any change on signal_1
...

...
@ (event_a) begin
  ...
  @ (event_b) begin
    ...
  end
end
...

Two points about the first example. @ signal_1 with no edge qualifier triggers on any value change of signal_1, including 0→x and 1→z. And the event control is edge-sensitive in the strict sense: it responds to a transition, not to a level. If signal_1 is already 1 and stays 1, the thread waits forever. That is the fundamental difference from wait in §4.6.關於第一個範例有兩點。沒有邊緣修飾字的 @ signal_1 會在 signal_1 任何值變化時觸發，包括 0→x 與 1→z。而且事件控制在嚴格意義上是邊緣敏感的：它回應的是一次轉態，不是一個電位。如果 signal_1 本來就是 1 而且維持 1，執行緒就永遠等下去。這正是它與 §4.6 的 wait 的根本差別。最初の例について二点ある。エッジ修飾子のない @ signal_1 は signal_1 のあらゆる値変化で発火し、0→x や 1→z も含む。そしてイベント制御は厳密な意味でエッジ感応である：応答するのは遷移であってレベルではない。signal_1 がもともと 1 でそのまま 1 であれば、スレッドは永遠に待つ。これが §4.6 の wait との根本的な違いである。

The nested example shows that event controls compose: the thread waits for event_a, does some work, then waits for event_b. This sequential-waiting style is the foundation of the implicit FSM description covered in §11.3, where each state is simply the point in the code between two event controls.巢狀的那個範例顯示事件控制可以串接：執行緒等 event_a，做一些事，然後等 event_b。這種循序等待的寫法，正是 §11.3 所談的隱式有限狀態機描述的基礎 —— 在那裡，每個狀態不過就是程式碼中兩個事件控制之間的那個位置。入れ子の例は、イベント制御を次々に連ねられることを示している：スレッドは event_a を待ち、いくらか仕事をし、それから event_b を待つ。この逐次待ちのスタイルが §11.3 で扱う暗黙的 FSM 記述の基礎であり、そこでは各状態は単にコード中の二つのイベント制御の間の地点にすぎない。

4.3 posedge and negedge4.3 posedge 與 negedge4.3 posedge と negedge

The edge qualifiers narrow an event control from "any change" to "a change in a particular direction". The slide's definition is the standard one and it is wider than most people expect:邊緣修飾字把事件控制從「任何變化」收窄成「朝特定方向的變化」。投影片上的定義是標準定義，而它比多數人想的更寬：エッジ修飾子は、イベント制御を「あらゆる変化」から「特定方向への変化」へ狭める。スライドの定義は標準どおりのものであり、多くの人が思うより範囲が広い。

The rule is simply "the LSB of the signal moved towards the target value", with x and z treated as an intermediate rung on a ladder 0 < x/z < 1. Transitions that stay on the same rung (x→z, z→x) are not edges.規則其實就是「訊號的最低位元朝目標值移動了」，其中 x 與 z 被當成 0 < x/z < 1 這個階梯上的中間一階。停在同一階的轉態（x→z、z→x）不算邊緣。規則は要するに「信号の最下位ビットが目標値のほうへ動いた」であり、x と z は 0 < x/z < 1 というはしごの中間段として扱われる。同じ段にとどまる遷移（x→z、z→x）はエッジではない。

The practical consequence is that a clock which goes 0→x at power-up fires every always @(posedge clk) in the design, loading x into every flip-flop. This is normal and expected; it is why a real design asserts reset for several cycles at the start of simulation before anything meaningful happens. It also means a tri-stated clock line that floats to z will generate spurious edges — one more argument for never gating a clock with a tri-state buffer.實務上的後果是：一個在上電時從 0→x 的時脈，會觸發設計裡每一個 always @(posedge clk)，把 x 載進每一個正反器。這是正常而且預期中的；也正因如此，真正的設計會在模擬一開始先讓重置維持數個週期，之後才做有意義的事。這同時表示一條浮接到 z 的三態時脈線會產生假邊緣 —— 這又是一個「絕不要用三態緩衝器去閘控時脈」的理由。実務上の帰結はこうである：電源投入時に 0→x となるクロックは、設計中のすべての always @(posedge clk) を発火させ、すべてのフリップフロップに x を取り込ませる。これは正常で想定どおりであり、だからこそ実際の設計はシミュレーション開始時にまずリセットを数サイクル保持してから意味のある動作に入る。同時に、z にフロートするトライステートのクロック線は偽のエッジを生むということでもある——クロックをトライステートバッファでゲートしてはならない理由がもう一つ増える。

always @ (posedge clock) begin
  #10 b = a;     // samples a 10 units AFTER the edge
end

This example from slide 20 is a trap worth dissecting. Because the #10 is a leading delay control, the thread wakes at the edge, sleeps 10 units, and only then reads a. It therefore does not model a flip-flop with a 10-unit clock-to-Q delay; it models something that samples the input 10 units late. Worse, the block is busy during those 10 units, so a clock edge arriving at t+5 is missed entirely. The construct that actually models clock-to-Q is the intra-assignment form b <= #10 a;, which reads a at the edge and writes b ten units later — see §5.1.第 20 張投影片的這個例子是值得解剖的陷阱。因為 #10 是前置的延遲控制，執行緒在邊緣醒來，睡 10 個單位，然後才讀 a。所以它描述的不是一個 clock-to-Q 延遲 10 單位的正反器；它描述的是一個晚 10 個單位才取樣輸入的東西。更糟的是，區塊在那 10 個單位裡是忙碌的，所以在 t+5 抵達的時脈邊緣會被完全錯過。真正能描述 clock-to-Q 的構造是指派內形式 b <= #10 a;，它在邊緣讀 a，十個單位之後才寫 b —— 見 §5.1。スライド 20 のこの例は解剖する価値のある落とし穴である。#10 が先頭の遅延制御なので、スレッドはエッジで目覚め、10 単位眠り、そのあとで a を読む。したがってこれはクロック・ツー・Q 遅延 10 単位のフリップフロップを表してはおらず、入力を 10 単位遅れてサンプルする何かを表している。さらに悪いことに、その 10 単位の間ブロックは忙しいので、t+5 に到来するクロックエッジは完全に取り逃される。クロック・ツー・Q を本当に表す構文は代入内形式 b <= #10 a; であり、これはエッジで a を読み、10 単位後に b を書く——§5.1 を参照。

4.4 Event or and the asynchronous flip-flop4.4 事件 or 與非同步正反器4.4 イベント or と非同期フリップフロップ

An event control may list several events separated by or (Verilog-2001 also allows a comma). The thread resumes when any one of them fires — it is a logical OR of trigger conditions, not a Boolean expression, and writing @(a || b) instead of @(a or b) is a different and almost always wrong thing to write.一個事件控制可以用 or 列出好幾個事件（Verilog-2001 也允許用逗號）。只要其中任何一個發動，執行緒就恢復 —— 它是觸發條件的邏輯 OR，不是一個布林運算式，而把 @(a or b) 寫成 @(a || b) 是完全不同、而且幾乎一定是錯的寫法。一つのイベント制御は or で複数のイベントを並べられる（Verilog-2001 ではカンマも使える）。そのうちどれか一つが発火すればスレッドは再開する——これはトリガ条件の論理 OR であってブール式ではなく、@(a or b) の代わりに @(a || b) と書くのはまったく別のこと、しかもほぼ確実に誤ったことである。

always @ (posedge clk or negedge set or negedge rst) begin
  if (rst == 0)
    q = 1'b0;          // reset has highest priority
  else if (set == 0)
    q = 1'b1;
  else if (clk == 1)
    q = data_in;       // woken by the clock edge
  else
    q = q;
end

This is the lecture's model of a positive-edge D flip-flop with active-low asynchronous set and reset. The body is a priority decoder over "why was I woken", and the order encodes the priority: reset beats set beats clock. The branches are the interesting part.這是講義中「帶低電位有效非同步 set 與 reset 的正緣 D 型正反器」的模型。本體是一個對「我為什麼被叫醒」做的優先權解碼器，而順序就編碼了優先權：reset 勝過 set，set 勝過 clock。有趣的是那些分支。これは講義にある「Low アクティブの非同期セットとリセットを持つ立ち上がりエッジ D フリップフロップ」のモデルである。本体は「なぜ起こされたのか」に対する優先順位デコーダであり、その順序が優先順位を符号化している：リセットがセットに勝ち、セットがクロックに勝つ。面白いのは分岐のほうである。

When the block wakes, it cannot ask which event fired — Verilog gives it no such query — so it must deduce it by inspecting the signals. If rst is 0, the wake-up must have been (or must now be subordinate to) the reset. If set is 0, likewise. Otherwise both asynchronous inputs are inactive, so the only remaining explanation is a clock edge, and the clk == 1 test confirms it before sampling data_in.區塊醒來時，它無法詢問是哪個事件發動的 —— Verilog 沒有給它這種查詢手段 —— 所以它必須靠檢查訊號來推斷。如果 rst 是 0，喚醒就一定是（或現在一定從屬於）那個 reset。如果 set 是 0，同理。否則兩個非同步輸入都不作用，於是唯一剩下的解釋就是一個時脈邊緣，而 clk == 1 這個測試會在取樣 data_in 之前先確認一次。ブロックが目覚めたとき、どのイベントが発火したかを問い合わせることはできない——Verilog はそのような問い合わせ手段を与えていない——ので、信号を調べて推定するしかない。rst が 0 なら、目覚めの原因はリセットだった（あるいはいまやリセットに従属する）はずである。set が 0 の場合も同様である。どちらでもなければ非同期入力はどちらも非アクティブなので、残る説明はクロックエッジだけであり、clk == 1 の判定が data_in をサンプルする前にそれを確認する。

Why confirm? Because of the x transitions in §4.3. A negedge rst event can be caused by 1→x, after which rst == 0 evaluates to x, which if treats as false (§7.4). Control falls through to the clock branch even though no clock edge occurred. The clk == 1 guard catches that case and the final else q = q; holds the output. Without the guard, an x glitch on reset would spuriously clock data through.為什麼要確認？因為 §4.3 裡那些 x 轉態。一個 negedge rst 事件可能是 1→x 造成的，而在那之後 rst == 0 求值為 x，if 把它當成假（§7.4）。於是控制權掉進時脈分支，即使根本沒有時脈邊緣發生。clk == 1 這道護欄攔住了這種情況，而最後的 else q = q; 則保住輸出。沒有這道護欄，reset 上的一個 x 毛刺就會假性地把資料打進去。なぜ確認するのか。§4.3 の x 遷移があるからである。negedge rst イベントは 1→x によっても起こりうるが、そのとき rst == 0 は x と評価され、if はそれを偽として扱う（§7.4）。クロックエッジなど起きていないのに、制御はクロックの分岐へ落ちてしまう。clk == 1 のガードがこの場合を捕まえ、最後の else q = q; が出力を保持する。ガードがなければ、リセット上の x グリッチが偽のクロックとしてデータを通してしまう。

always @ (posedge clk or negedge rst_n)
  if (!rst_n) q <= 1'b0;
  else        q <= data_in;

4.5 Named events and the trigger operator Non-synthesized4.5 具名事件與觸發運算子 不可合成4.5 名前付きイベントとトリガ演算子 合成不可

A named event is an abstract synchronisation token with no value, no width and no storage. You declare it with event, you fire it with ->, and you wait for it with @. Its only purpose is to let one part of a design tell another that something happened, without inventing a signal to carry the news.具名事件是一個抽象的同步符記，沒有值、沒有寬度、也沒有儲存。你用 event 宣告它，用 -> 把它發動，用 @ 等它。它唯一的用途，就是讓設計的某一部分告訴另一部分「某件事發生了」，而不必為了傳這個消息去發明一條訊號。名前付きイベントは、値も幅も記憶も持たない抽象的な同期トークンである。event で宣言し、-> で発火させ、@ で待つ。唯一の用途は、知らせを運ぶ信号をわざわざ作らずに、設計のある部分が別の部分に「何かが起きた」と伝えることである。

event up_edge;

always @ (posedge clk)
  -> up_edge;              // fire the event

always @ (up_edge)
  ...                      // woken by the event

Because an event is declared in a module, it can be reached from another module by hierarchical dereferencing, which is what makes the lecture's two-module example work:因為事件是宣告在模組裡的，所以可以用階層式取值從另一個模組伸手取用，而這正是講義中那個雙模組範例能運作的原因：イベントはモジュール内で宣言されるので、階層参照によって別のモジュールから到達できる。講義の二モジュールの例が成り立つのはこのためである。

module top (clk, data, q);
  input  clk, data;
  output q;
  talker   M1 (clk);
  receiver M2 (q, data);
endmodule

module talker (clk);
  input clk;
  event do_it;
  always @ (posedge clk)
    -> do_it;              // trigger
endmodule

module receiver (q, data);
  input  data;
  output q;
  reg    q;
  always @ (top.M1.do_it)  // hierarchical
    q = data;
endmodule

That is also why named events are not synthesisable: there is no wire, so there is nothing to build. They belong in test benches and in abstract transaction-level models, where "the bus master finished a burst" is a cleaner thing to signal than a hand-rolled handshake. One further property matters in practice: a named event is stateless. Triggering it when nobody is waiting does nothing at all, and there is no way to ask afterwards whether it was triggered. Like the bare @ of §4.2, it is a pure edge.這也正是具名事件不可合成的原因：既然沒有線，就沒有東西可以蓋。它們屬於測試平台，以及抽象的交易層模型 —— 在那裡，「匯流排主控完成了一次叢發」比手工打造的握手訊號更乾淨。還有一個性質在實務上很重要：具名事件是無狀態的。沒有人在等的時候把它觸發，什麼都不會發生，而且事後也沒有辦法問它到底有沒有被觸發過。就像 §4.2 裡那個光禿禿的 @ 一樣，它是純粹的邊緣。名前付きイベントが合成できない理由もこれである：配線がないのだから作るものがない。その居場所はテストベンチと抽象的なトランザクションレベルのモデルであり、そこでは「バスマスタがバースト転送を終えた」と伝えるほうが、手作りのハンドシェイクより素直である。実務上もう一つ重要な性質がある：名前付きイベントは状態を持たない。誰も待っていないときに発火させても何も起こらず、後から発火したかどうかを問い合わせる手段もない。§4.2 の裸の @ と同じく、純粋なエッジである。

4.6 The wait statement Non-synthesized4.6 wait 敘述 不可合成4.6 wait 文 合成不可

wait (expr) statement; suspends the thread until expr is true, then executes the statement. The crucial difference from @ is that wait is level-sensitive: it tests the condition first, and if it is already true the thread does not suspend at all.wait (expr) statement; 把執行緒暫停到 expr 為真為止，然後執行那道敘述。與 @ 的關鍵差別在於 wait 是電位敏感的：它先測條件，如果條件本來就為真，執行緒根本不會暫停。wait (expr) statement; は expr が真になるまでスレッドを中断し、それから文を実行する。@ との決定的な違いは wait がレベル感応であることだ：まず条件を判定し、すでに真であればスレッドはまったく中断しない。

data_out = 0;
wait (enable) data_out = data_in;

The slide labels this "level-sensitive behaviour", and it is the natural way to model the enable input of a transparent latch, a FIFO's not-empty flag, or a handshake that may already have completed by the time the consumer looks. Three cautions:投影片把這稱為「電位敏感行為」，而這正是描述透明閂鎖的 enable 輸入、FIFO 的非空旗標，或是一個在消費者去看的時候可能早就完成的握手的自然方式。有三點要注意：スライドはこれを「レベル感応の振る舞い」と呼ぶ。これは透過ラッチの enable 入力、FIFO の非空フラグ、あるいは消費者が見にいった時点ですでに完了しているかもしれないハンドシェイクを表現する自然な方法である。注意すべき点が三つある。

• wait does not re-evaluate after it releases. The example assigns data_out exactly once, at the moment enable first becomes true. It is not a latch; a latch would keep tracking data_in while enable is high. To get latch behaviour you need always @(enable or data_in) if (enable) data_out = data_in; or a PCA as in §3.2.wait 放行之後不會重新求值。範例只在 enable 第一次變為真的那一刻指派 data_out 一次。它不是閂鎖；閂鎖會在 enable 為高的整段期間持續追蹤 data_in。要得到閂鎖行為，你需要 always @(enable or data_in) if (enable) data_out = data_in;，或是 §3.2 那樣的 PCA。wait は解除後に再評価しない。例では enable が初めて真になった瞬間に data_out をちょうど一度代入するだけである。これはラッチではない。ラッチなら enable が High の間ずっと data_in を追い続ける。ラッチの振る舞いが欲しければ always @(enable or data_in) if (enable) data_out = data_in; か、§3.2 のような PCA が要る。
• wait(1) never suspends and wait(0) never releases. The latter inside an always block without any other time control is still a legitimate way to hang, although at least it does not burn CPU.wait(1) 永遠不暫停，wait(0) 永遠不放行。後者放在一個沒有其他時間控制的 always 區塊裡，依然是個名正言順的掛掉方式，不過至少它不會燒 CPU。wait(1) は決して中断せず、wait(0) は決して解除されない。後者を他にタイミング制御のない always ブロックに置けば、これもまた立派なハングの仕方である。ただし少なくとも CPU は焼かない。
• A wait whose condition can only be changed by the same thread is a deadlock. This sounds obvious until you write it inside a task that was supposed to be called from somewhere else.條件只能由同一個執行緒改變的 wait 就是死結。這聽起來理所當然，直到你把它寫在一個本來應該由別處呼叫的任務裡面。条件を同じスレッドしか変えられない wait はデッドロックである。当たり前に聞こえるが、本来は他所から呼ばれるはずのタスクの中にそれを書いてしまうまでの話である。

(a) initial clk = 0;  always #7 clk = ~clk;
(b) always #7 clk = ~clk;
(c) initial begin clk = 0; forever begin #3 clk = 1; #7 clk = 0; end end
(d) always begin clk = 0; #5; clk = 1; #5; end

initial begin #20; @(done)      $display("A at %0t", $time); end
initial begin #20; wait (done)  $display("B at %0t", $time); end

5. Intra- vs Inter-Assignment Delay5. 指派內延遲與指派間延遲5. 代入内遅延と代入間遅延

5.1 Where the delay sits changes what it means5.1 延遲擺的位置會改變它的意義5.1 遅延を置く位置が意味を変える

The slide's slogan is "postpone assignment, not evaluation", and it is one of the few slogans in this lecture that is both short and complete. Verilog lets you write a delay in two places relative to an assignment, and the two mean entirely different things:投影片的口號是「延後的是指派，不是求值」，而這是本講少數既短又完整的口號之一。Verilog 允許你把延遲寫在指派的兩個位置，而這兩個位置的意義完全不同：スライドの標語は「先送りされるのは代入であって評価ではない」であり、この講義では珍しく短くかつ完全な標語である。Verilog は代入に対して二つの位置に遅延を書かせるが、その二つはまったく別の意味を持つ。

• Inter-assignment (#5 a = b;). The #5 is a separate statement that happens to precede the assignment. The thread sleeps 5 units; then, on waking, it evaluates b and writes a. The RHS is read late.指派間（#5 a = b;）。#5 是一道獨立的敘述，只是剛好排在指派前面。執行緒睡 5 個單位；醒來之後才求 b 並寫 a。右手邊是晚讀的。代入間（#5 a = b;）。#5 はそれ自体が独立した文であり、たまたま代入の前に置かれているだけである。スレッドは 5 単位眠り、目覚めてから b を評価して a に書く。右辺は遅く読まれる。
• Intra-assignment (a = #5 b;). The RHS is evaluated now and the value is squirrelled away; the write to a is postponed by 5. The RHS is read early.指派內（a = #5 b;）。右手邊現在就求值，值被藏起來；對 a 的寫入則延後 5。右手邊是早讀的。代入内（a = #5 b;）。右辺はいま評価され、その値が蓄えられる。a への書き込みが 5 だけ先送りされる。右辺は早く読まれる。

The standard defines the intra-assignment form by an exact rewriting, which is the safest way to reason about it:標準用一個精確的改寫來定義指派內形式，而那是最安全的思考方式：標準は代入内形式を厳密な書き換えによって定義している。これがもっとも安全な考え方である。

a = #5 b;
c = d;

begin
  temp = b;      // evaluate NOW
  #5;            // then wait
  a = temp;      // then write the OLD value
end
c = d;           // runs at t+5, because = blocks

The same rewriting works with an event control in place of the delay: e = @(bus) f; reads f immediately, waits for a change on bus, and only then writes e. Slide 25 of Part 1 shows exactly this pair.把延遲換成事件控制，同樣的改寫照樣成立：e = @(bus) f; 會立刻讀 f，等 bus 上的一次變化，然後才寫 e。第 1 部的第 25 張投影片展示的正是這一對。遅延の代わりにイベント制御を置いても同じ書き換えが成り立つ：e = @(bus) f; はただちに f を読み、bus の変化を待ち、それから e に書く。パート 1 のスライド 25 が示しているのはまさにこの対である。

The non-blocking forms differ in one respect only: the thread does not wait for the postponed write, so execution continues at once.非阻斷式形式只在一點上不同：執行緒不等那個被延後的寫入，所以執行會立刻繼續下去。ノンブロッキング形式が違うのは一点だけである：スレッドは先送りされた書き込みを待たず、実行はただちに続く。

initial begin
  @ (posedge clk)
    g <= @ (bus) k;   // sample k at the clock edge, write g at the next bus change
    p <= q;           // executes in the same time slot, not after g is written
end

always begin
  @ (posedge clock)
    g <= @ (bus) k;   // the always block returns to its @ immediately
end

That last block is worth staring at. Because <= does not block, the always returns to the @(posedge clock) at once, ready for the next edge — even though the write to g scheduled by the previous edge may still be outstanding. Several such writes can therefore be in flight simultaneously. That is exactly what a pipeline does, and it is why the non-blocking intra-assignment form is the only correct way to model a propagation delay in a clocked model.最後那個區塊值得盯著看。因為 <= 不阻斷，always 會立刻回到 @(posedge clock)，準備好迎接下一個邊緣 —— 即使上一個邊緣所排程的那次對 g 的寫入可能都還沒兌現。因此好幾次這樣的寫入可以同時在途中。這正是管線在做的事，也正是為什麼在時脈同步模型裡，非阻斷式的指派內形式是唯一能正確描述傳播延遲的寫法。最後のブロックはじっくり眺める価値がある。<= はブロックしないので、always はただちに @(posedge clock) に戻り、次のエッジに備える——前のエッジがスケジュールした g への書き込みがまだ果たされていなくてもである。したがってそうした書き込みが同時に複数、飛行中になりうる。これこそパイプラインのしていることであり、クロック同期モデルで伝搬遅延を正しく表せるのがノンブロッキングの代入内形式だけである理由でもある。

5.2 A worked timeline5.2 時間軸實例5.2 タイムラインの実例

5.3 Six models of the same OR gate5.3 同一個 OR 閘的六種模型5.3 同じ OR ゲートの六つのモデル

Slide 27 of Part 1 puts six one-line models of y = a | b on the screen and asks what the difference is. Two of them are crossed out on the slide as bad practice. Here is the full table with the reasoning.第 1 部的第 27 張投影片把 y = a | b 的六個單行模型全放到畫面上，問差別在哪。其中兩個在投影片上被畫叉，標為壞習慣。以下是完整的表，附上理由。パート 1 のスライド 27 は y = a | b の一行モデルを六つ画面に並べ、違いは何かと問う。そのうち二つはスライド上で悪い書き方として×印をつけられている。以下は理由を添えた完全な表である。

5.4 Inertial versus transport delay5.4 慣性延遲與傳輸延遲5.4 慣性遅延と伝送遅延

Those two words name a real physical distinction and it is worth being precise about them, because they are the reason the table above has two "correct" rows rather than one.這兩個詞指的是一個真實的物理區別，值得講精確一點，因為它們正是上面那張表有兩列「正確」而不是只有一列的原因。この二語は実在する物理的区別を指しており、正確に述べておく価値がある。上の表に「正しい」行が一つではなく二つある理由がこれだからである。

Inertial delay is what a CMOS gate actually exhibits. The gate has capacitance; a pulse at the input shorter than the gate's propagation delay does not deliver enough charge to swing the output, so it is filtered out. Verilog implements this for continuous assignments and gate primitives: when a new output value is scheduled, any previously scheduled output transition that has not yet occurred is cancelled. So in assign #5 y = a|b;, a 0→1 at t=2 schedules y←1 at t=7, and a 1→0 at t=4 cancels that pending event and schedules y←0 at t=9. Since y was already 0, the net result is that nothing happens at all and the 2-unit pulse vanishes.慣性延遲才是 CMOS 閘真正表現出來的行為。閘有電容；輸入端一個比閘傳播延遲還短的脈衝，送不出足夠的電荷去擺動輸出，所以它被濾掉了。Verilog 替連續指派與閘級基本元件實作了這個行為：當一個新的輸出值被排程時，任何先前排好但尚未發生的輸出轉態都會被取消。所以在 assign #5 y = a|b; 裡，t=2 的一次 0→1 會把 y←1 排在 t=7，而 t=4 的一次 1→0 取消那個待處理事件，改把 y←0 排在 t=9。既然 y 本來就是 0，淨結果就是什麼都沒發生，那個 2 單位寬的脈衝消失了。慣性遅延こそ CMOS ゲートが実際に示す振る舞いである。ゲートには容量がある。ゲートの伝搬遅延より短い入力パルスは、出力を振り切るだけの電荷を届けられないので濾し取られる。Verilog は連続代入とゲートプリミティブについてこれを実装している：新しい出力値がスケジュールされると、すでに予約済みでまだ起きていない出力遷移は取り消される。したがって assign #5 y = a|b; では、t=2 の 0→1 が y←1 を t=7 に予約し、t=4 の 1→0 がその保留イベントを取り消して y←0 を t=9 に予約する。y はもともと 0 なので、正味では何も起こらず、幅 2 単位のパルスは消える。

Transport delay is what an ideal lossless transmission line would do: every transition arrives, just later. Verilog has no transport keyword, but y <= #5 expr; gives you exactly this behaviour, because each non-blocking assignment schedules an independent update event and nothing cancels anything. A 2-unit pulse at t = 2 appears faithfully as a 2-unit pulse at t = 7.傳輸延遲則是一條理想無損傳輸線會做的事：每一次轉態都會抵達，只是晚一點。Verilog 沒有 transport 這個關鍵字，但 y <= #5 expr; 給你的正是這個行為，因為每一個非阻斷式指派都排一個獨立的更新事件，而沒有任何東西會取消任何東西。t = 2 的一個 2 單位脈衝，會忠實地在 t = 7 變成一個 2 單位脈衝。伝送遅延は理想的な無損失伝送線路が行うことである：あらゆる遷移が、ただ遅れて到着する。Verilog に transport というキーワードはないが、y <= #5 expr; がまさにこの振る舞いを与える。ノンブロッキング代入はそれぞれ独立した更新イベントを予約し、何も何かを取り消さないからである。t = 2 の幅 2 単位のパルスは、t = 7 に幅 2 単位のパルスとして忠実に現れる。

5.5 Repeated intra-assignment delay Non-synthesized5.5 重複的指派內延遲 不可合成5.5 繰り返し代入内遅延 合成不可

The intra-assignment timing control may be a repeat clause, which waits for a counted number of events rather than a fixed delay.指派內的時間控制也可以是一個 repeat 子句，它等的是「數到幾次事件」而不是一個固定的延遲。代入内のタイミング制御は repeat 節でもよい。これは固定の遅延ではなく、指定回数のイベントを待つ。

reg_a = repeat (5) @ (negedge clock) reg_b;

begin
  temp = reg_b;          // sample NOW
  @ (negedge clock);
  @ (negedge clock);
  @ (negedge clock);
  @ (negedge clock);
  @ (negedge clock);
  reg_a = temp;          // write the sampled value
end

The expansion makes three things obvious that the one-liner hides. First, the value transferred is the one reg_b held when the statement started, five edges ago. Second, the five edges are counted from the moment the statement starts, so an edge occurring at exactly that instant may or may not count depending on ordering within the time slot. Third, the construct is a pure delay line — it is how you say "this value arrives five clocks later" in a test bench without building a shift register.展開式讓三件被單行寫法藏起來的事情變得明顯。第一，被搬運的值是敘述開始時、也就是五個邊緣之前 reg_b 所持有的那個值。第二，那五個邊緣是從敘述開始的那一刻起算的，所以剛好發生在那一瞬間的邊緣算不算得到，要看時槽之內的順序。第三，這個構造就是一條純粹的延遲線 —— 它就是你在測試平台裡說「這個值五個時脈之後抵達」而不必自己搭一個移位暫存器的方法。展開形は、一行の書き方が隠している三つのことを明らかにする。第一に、運ばれる値は文が開始した時点、すなわち五エッジ前に reg_b が保持していた値である。第二に、五つのエッジは文の開始時点から数えられるので、ちょうどその瞬間に起こるエッジが数えられるかどうかはタイムスロット内の順序に依存する。第三に、この構文は純粋な遅延線であり、シフトレジスタを自分で組まずに「この値は五クロック後に届く」とテストベンチで言うための手段である。

module repeater;
  reg clock;
  reg reg_a, reg_b;

  initial clock = 0;
  always #5 clock = ~clock;

  initial begin
    #5  reg_a = 1;
    #10 reg_a = 0;
    #5  reg_a = 1;
    #20 reg_a = 0;
  end

  initial #100 $finish;

  initial begin
    #10 reg_b = repeat (5) @ (posedge clock) reg_a;
  end
endmodule

6. The Simulation Scheduling Model6. 模擬排程模型6. シミュレーションのスケジューリングモデル

6.1 The lecture's six steps, and what they mean6.1 講義中的六個步驟，以及它們的意思6.1 講義の六つのステップとその意味

Slide 30 of Part 1 compresses the whole event queue into six bullets describing one time step. Here they are, annotated with the region of §2.1 that each one corresponds to.第 1 部的第 30 張投影片把整個事件佇列壓縮成描述一個時間步的六個條目。以下就是它們，並標註每一條對應到 §2.1 的哪一個區域。パート 1 のスライド 30 は、イベントキュー全体を一つのタイムステップを述べる六つの箇条に圧縮している。以下にそれらを挙げ、各項が §2.1 のどの領域に対応するかを註記する。

1. Evaluate expressions on the RHS. (Active) This is where every right-hand side in the time slot, blocking or not, is read.求出右手邊的運算式。(Active)這就是時槽內每一個右手邊 —— 不論阻斷與否 —— 被讀取的地方。右辺の式を評価する。(Active)タイムスロット内のあらゆる右辺が、ブロッキングであるか否かを問わず読まれるのがここである。
2. Execute blocking assignments. (Active) The write happens immediately as part of the same event, so steps 1 and 2 interleave rather than running as two separate passes.執行阻斷式指派。(Active)寫入是同一個事件的一部分，立刻發生，所以步驟 1 與 2 是交錯進行的，而不是兩趟分開跑。ブロッキング代入を実行する。(Active)書き込みは同じイベントの一部としてただちに起こるので、ステップ 1 と 2 は二回の別々のパスではなく互い違いに進む。
3. Execute non-blocking assignments that do not have intra-assignment timing control. (NBA) The updates whose values were read in step 1.執行沒有指派內時間控制的非阻斷式指派。(NBA)也就是那些值在步驟 1 被讀走的更新。代入内タイミング制御を持たないノンブロッキング代入を実行する。(NBA)ステップ 1 で値が読まれた更新のことである。
4. Execute past assignments that were scheduled to execute in the current time step. (NBA) These are the a <= #d b; updates scheduled at some earlier time whose delay expires now.執行過去排定要在目前時間步執行的指派。(NBA)這些是早些時候排程、而延遲在此刻到期的 a <= #d b; 更新。現在のタイムステップで実行するよう過去に予約された代入を実行する。(NBA)これは以前にスケジュールされ、いま遅延が満了した a <= #d b; の更新である。
5. Execute $monitor. (Postponed) With the parenthetical note that $display runs where it is encountered, which is to say in the Active region, before the non-blocking updates.執行 $monitor。(Postponed)括號裡還附註說 $display 是在遇到它的地方執行的，也就是在 Active 區域，先於非阻斷式更新。$monitor を実行する。(Postponed)括弧書きで、$display は出会った場所、すなわち Active 領域で、ノンブロッキング更新より前に走ると註記されている。
6. Advance simulation time.推進模擬時間。シミュレーション時間を進める。

6.2 $display versus $monitor versus $strobe6.2 $display、$monitor 與 $strobe 的比較6.2 $display と $monitor と $strobe

These three system tasks exist precisely because of the region structure, and choosing the wrong one is the fastest way to misdiagnose a design.這三個系統任務之所以存在，正是因為區域結構，而選錯一個是誤診設計最快的途徑。この三つのシステムタスクが存在するのはまさに領域構造があるからであり、選択を誤ることは設計を誤診する最短の道である。

initial begin
  a = 1;
  b = 0;
  a <= b;
  b <= a;
  $display("a=%b b=%b", a, b);
end
// display: a=1 b=0

initial begin
  a = 1;
  b = 0;
  a <= b;
  b <= a;
  $monitor("a=%b b=%b", a, b);
end
// monitor: a=0 b=1

Both blocks perform the same swap. The left one prints a=1 b=0 because $display is an Active-region event executed where it stands, at which point the two NBA updates are still pending. The right one prints a=0 b=1 because $monitor is a Postponed-region event executed after the whole time slot has settled.兩個區塊做的是同一個交換。左邊那個印出 a=1 b=0，因為 $display 是一個 Active 區域事件，在它所在的位置就執行，而那時兩個 NBA 更新都還沒兌現。右邊那個印出 a=0 b=1，因為 $monitor 是 Postponed 區域事件，在整個時槽穩定下來之後才執行。二つのブロックは同じスワップを行う。左は a=1 b=0 と印字する。$display が Active 領域のイベントであり、書かれた位置で実行され、その時点で二つの NBA 更新がまだ保留中だからである。右は a=0 b=1 と印字する。$monitor が Postponed 領域のイベントであり、タイムスロット全体が落ち着いた後に実行されるからである。

Two further details that bite in the lab. $monitor is a singleton: arming a second one silently disables the first, and $monitoroff/$monitoron exist to suspend it around noisy phases. And $strobe and $monitor both run after the NBA region, so if a $strobe argument is written by a delayed non-blocking assignment landing in a later time slot, the $strobe will show the old value — being in the Postponed region only protects you against same-slot NBA updates.還有兩個在實驗室裡會咬人的細節。$monitor 是單例：啟動第二個會默默停掉第一個，而 $monitoroff／$monitoron 的存在就是為了在吵雜的階段前後把它暫停。另外 $strobe 與 $monitor 都在 NBA 區域之後才跑，所以如果某個 $strobe 的引數是由一個落在較晚時槽的延遲非阻斷式指派所寫的，那麼 $strobe 顯示的會是舊值 —— 待在 Postponed 區域只保護你不受同一時槽的 NBA 更新所害。実験室で噛みつく細部がさらに二つある。$monitor はシングルトンである：二つ目を起動すると最初のものが黙って無効になり、$monitoroff／$monitoron は騒がしい局面の前後でそれを止めるために存在する。また $strobe と $monitor はどちらも NBA 領域の後に走るので、ある $strobe の引数がより後のタイムスロットに落ちる遅延つきノンブロッキング代入によって書かれる場合、$strobe は古い値を示す——Postponed 領域にいることが守ってくれるのは、同一スロット内の NBA 更新に対してだけである。

6.3 Zero-delay loops and the meaning of #06.3 零延遲迴圈與 #0 的意義6.3 ゼロ遅延ループと #0 の意味

#0 is not "no delay". It is "move this event from the Active region to the Inactive region of the same time slot", which means: run after everything that is currently pending, but before any non-blocking update and without advancing time. It is a way of saying "let the others go first".#0 不是「沒有延遲」。它是「把這個事件從 Active 區域搬到同一時槽的 Inactive 區域」，意思是：在目前所有待處理的東西之後才跑，但在任何非阻斷式更新之前，而且不推進時間。它是一種說「讓別人先走」的方式。#0 は「遅延なし」ではない。「このイベントを Active 領域から同じタイムスロットの Inactive 領域へ移す」という意味であり、すなわち現在保留中のすべての後に走り、しかしどのノンブロッキング更新よりも前に走り、時間は進めない、ということである。「他の者に先に行かせる」と言うための手段である。

The carry look-ahead adder of §7.6 uses it for exactly that reason. The always block computes the carry chain from g and p, which are produced by continuous assignments. When a changes, both the continuous assignments and the always block become active in the same time slot, in unspecified order. Without the #0, the block might read the old g and p and compute a carry chain from stale data, which then gets corrected on the next pass — producing a transient glitch at best, and on some simulators a stable wrong answer. The #0 defers the block until the Active region is empty, by which time g and p have settled.§7.6 的超前進位加法器正是為了這個理由而用它。那個 always 區塊從 g 與 p 算出進位鏈，而 g 與 p 是由連續指派產生的。當 a 改變時，連續指派與 always 區塊在同一個時槽一起變成作用中，順序未定義。沒有 #0 的話，區塊可能讀到舊的 g 與 p，用過時的資料算出一條進位鏈，然後在下一趟才被更正 —— 好一點的情況是產生一個暫態毛刺，在某些模擬器上則是一個穩定的錯誤答案。#0 把這個區塊推遲到 Active 區域空了之後，而那時 g 與 p 已經穩定。§7.6 のキャリー先見加算器はまさにこの理由でこれを使っている。その always ブロックは g と p からキャリーチェーンを計算するが、g と p は連続代入が生む。a が変化すると、連続代入と always ブロックが同じタイムスロットで順序未定義のままアクティブになる。#0 がなければ、ブロックは古い g と p を読んで陳腐なデータからキャリーチェーンを計算し、次のパスで訂正されることになる——よくて一過性のグリッチ、シミュレータによっては安定した誤答が出る。#0 はこのブロックを Active 領域が空になるまで先送りし、その時点では g と p は落ち着いている。

initial begin
  x = 0;
  x <= 1;
  $display("D  x=%b", x);
  $strobe ("S  x=%b", x);
  #0 $display("D0 x=%b", x);
  #1 $display("D1 x=%b", x);
end

D  x=0
D0 x=0
S  x=1
D1 x=1

7. Activity Flow Control7. 活動流程控制7. アクティビティのフロー制御

Everything so far has been about when a thread runs. This section is about which statements it runs: the conditional operator, the three case variants, if ... else, the four loops, and disable. All of them are ordinary structured-programming constructs, and the only reason they need a section of their own is that each one has a synthesis consequence that has no counterpart in software.到目前為止談的都是執行緒什麼時候跑。這一節談的是它跑哪些敘述：條件運算子、三種 case 變體、if ... else、四種迴圈，以及 disable。它們全都是普通的結構化程式設計構造，而它們之所以需要獨立一節，唯一的理由是每一個都帶有一個在軟體裡找不到對應物的合成後果。ここまではスレッドがいつ走るかの話だった。この節はスレッドがどの文を走らせるかの話である：条件演算子、三種類の case、if ... else、四種類のループ、そして disable。どれもありふれた構造化プログラミングの構文であり、これらに独立した節が要る理由はただ一つ、どれもソフトウェアには対応物のない合成上の帰結を伴うことである。

7.1 The conditional operator7.1 條件運算子7.1 条件演算子

cond ? a : b is an expression, so it can appear anywhere an expression can — on the right of a continuous assignment, as a module port connection, inside a bigger expression, and (the point of slide 33) on the right of a procedural assignment.cond ? a : b 是一個運算式，所以它可以出現在任何運算式能出現的地方 —— 連續指派的右邊、模組埠的連接、一個更大的運算式裡面，以及（第 33 張投影片的重點）程序性指派的右邊。cond ? a : b は式なので、式が書ける場所ならどこにでも書ける——連続代入の右辺、モジュールのポート接続、より大きな式の内部、そして（スライド 33 の要点）手続き型代入の右辺である。

always @ (posedge clock)
  q = s ? a : b;

Two behaviours worth knowing. First, if cond evaluates to x or z, the operator does not pick a branch arbitrarily — it evaluates both arms and returns their bitwise merge, where matching bits pass through and differing bits become x. So with s = 1'bx, a = 4'b1100 and b = 4'b1010, the result is 4'b1xx0. That is a genuinely useful property: an unknown select on a mux produces unknowns only on the bits that actually disagree, which keeps x propagation from exploding. Second, synthesis maps a chain of nested ?: to a priority mux, exactly like a chain of else if, so the usual area-versus-depth trade-off applies.有兩個行為值得知道。第一，如果 cond 求值為 x 或 z，這個運算子不會任意挑一邊 —— 它會把兩邊都求出來，然後回傳它們的逐位元合併：相同的位元照樣通過，不同的位元變成 x。所以在 s = 1'bx、a = 4'b1100、b = 4'b1010 時，結果是 4'b1xx0。這是一個真正有用的性質：多工器上一個未知的選擇訊號，只會在真正不一致的位元上產生未知值，這能避免 x 的傳播爆炸開來。第二，合成會把一串巢狀的 ?: 對應成一個優先權多工器，與一串 else if 完全相同，所以通常的面積與深度取捨照樣適用。知っておく価値のある振る舞いが二つある。第一に、cond が x や z と評価された場合、この演算子はどちらかの腕を勝手に選んだりしない——両方を評価し、ビットごとのマージを返す。一致するビットはそのまま通り、食い違うビットは x になる。したがって s = 1'bx、a = 4'b1100、b = 4'b1010 なら結果は 4'b1xx0 である。これは本当に有用な性質である：マルチプレクサの選択線が未知でも、実際に食い違うビットにしか未知値が出ないので、x の伝播が爆発せずに済む。第二に、合成は入れ子になった ?: の連鎖を、else if の連鎖とまったく同じく優先順位マルチプレクサに対応づけるので、通常の面積対段数のトレードオフがそのまま当てはまる。

7.2 The case statement7.2 case 敘述7.2 case 文

case compares the selector expression against each item in turn and executes the first that matches. "Match" means a complete bit-wise identity over all four values: a selector bit of x matches only an item bit of x, and a selector bit of z matches only z.case 把選擇運算式依序與每一個項目比對，執行第一個相符的。「相符」的意思是在四種值上逐位元完全相同：選擇式的某個位元若是 x，就只與項目中同樣是 x 的位元相符；若是 z，就只與 z 相符。case は選択式を各項目と順に比較し、最初に一致したものを実行する。「一致」とは四値すべてにわたるビット単位の完全一致を意味する：選択式のあるビットが x なら項目側の x とだけ一致し、z なら z とだけ一致する。

always @ (a or b or c or d or select)
begin
  case (select)
    0: y = a;
    1: y = b;
    2: y = c;
    3: y = d;
    default: y = 1'bx;
  endcase
end

The slide's first bullet — "expression and case item must have the same bit length" — deserves expansion, because what actually happens is subtler than an error. Verilog zero-extends the narrower operand to the width of the wider, so comparing a 2-bit select against the unsized literal 0 works fine. The trouble starts with x and z: an unsized literal such as 'bx is extended with x, while a sized one such as 2'bx is 2'bxx, and 4'b01 is 4'b0001. Mismatched widths therefore do not produce a compile error; they produce items that can never match. Always size your case items.投影片的第一個條目 ——「運算式與 case 項目必須有相同的位元長度」—— 值得展開，因為實際發生的事比一個錯誤訊息微妙得多。Verilog 會把較窄的運算元零延伸到較寬者的寬度，所以拿一個 2 位元的 select 去比對無尺寸字面值 0 完全沒問題。麻煩從 x 與 z 開始：像 'bx 這種無尺寸字面值會用 x 延伸，而像 2'bx 這種有尺寸的就是 2'bxx，4'b01 則是 4'b0001。所以寬度不符並不會產生編譯錯誤；它產生的是永遠不可能相符的項目。請一律替你的 case 項目標上尺寸。スライドの最初の箇条——「式と case 項目はビット長が同じでなければならない」——は展開しておく価値がある。実際に起きることはエラーよりずっと微妙だからである。Verilog は狭いほうのオペランドを広いほうの幅までゼロ拡張するので、2 ビットの select をサイズなしリテラル 0 と比較するのは問題なく動く。やっかいなのは x と z である：'bx のようなサイズなしリテラルは x で拡張されるが、2'bx のようなサイズ付きは 2'bxx であり、4'b01 は 4'b0001 である。したがって幅の不一致はコンパイルエラーを生まず、決して一致しえない項目を生む。case 項目には必ずサイズを付けること。

The second bullet is the one that matters for the back end. If the case list is incomplete — some selector values hit no item and there is no default — then in a combinational block the variable keeps its previous value for those inputs, and "keeps its previous value" is the definition of a latch. Synthesis duly infers one.第二個條目才是對後端真正重要的。如果 case 列表不完整 —— 有些選擇值對不到任何項目，而且沒有 default —— 那麼在組合邏輯區塊裡，變數就會對那些輸入保留它先前的值，而「保留先前的值」正是閂鎖的定義。合成於是照辦，推斷出一個閂鎖。後段工程にとって本当に重要なのは二つ目の箇条である。case のリストが不完全で——どの項目にも当たらない選択値があり、default もない——場合、組合せ論理ブロックではそれらの入力に対して変数が以前の値を保つ。そして「以前の値を保つ」はラッチの定義である。合成はそのとおりにラッチを推論する。

7.3 casex and casez7.3 casex 與 casez7.3 casex と casez

These two variants relax the matching rule by declaring certain bit values to be "don't care" — and, crucially, the don't-care applies to both sides of the comparison, not just to the items.這兩個變體宣告某些位元值為「不在乎」，藉此放寬比對規則 —— 而關鍵在於，這個「不在乎」適用於比較的兩邊，不是只適用於項目那一邊。この二つの変種は、特定のビット値を「ドントケア」と宣言することで一致規則を緩める——そして肝心なのは、そのドントケアが比較の両辺に適用され、項目側だけではないという点である。

always @ (opcode or a or b or c)
casex (opcode)
  4'b1zzx : begin  // bits 2:0 are don't care
              out = a;
            end
  4'b01?? : begin  // bits 1:0 are don't care
              out = b;
            end
  4'b001? : begin  // bit 0 is don't care
              out = c;
            end
  default : begin
              out = 4'b0;
            end
endcase

Read the items as masks. 4'b1zzx means "bit 3 must be 1, the rest are free"; 4'b01?? means "bits 3:2 must be 01"; 4'b001? means "bits 3:1 must be 001". Because items are tested top to bottom and the first match wins, the three masks are implicitly prioritised, and the design works out to a leading-one detector over the opcode.把這些項目讀成遮罩。4'b1zzx 的意思是「位元 3 必須是 1，其餘自由」；4'b01?? 的意思是「位元 3:2 必須是 01」；4'b001? 的意思是「位元 3:1 必須是 001」。因為項目是由上往下測試、第一個相符者勝出，這三個遮罩就隱含了優先權，而整個設計算下來等於是對 opcode 做一個前導 1 偵測器。項目はマスクとして読むとよい。4'b1zzx は「ビット 3 は 1、残りは自由」、4'b01?? は「ビット 3:2 は 01」、4'b001? は「ビット 3:1 は 001」を意味する。項目は上から順に判定され最初に一致したものが勝つので、三つのマスクには暗黙の優先順位がつき、設計全体としては opcode に対する先行 1 検出器になる。

7.4 if ... else

Two rules from slide 36, both of which have consequences elsewhere in the lecture.第 36 張投影片有兩條規則，兩條都在本講其他地方產生後果。スライド 36 には二つの規則があり、どちらも本講義の他の箇所に帰結を持つ。

• True is the numerical value 1; false is 0, x or z. More precisely, the condition is reduced to a single bit: a non-zero known value is true, zero is false, and anything containing x or z that is not otherwise non-zero is false. This is why the rst == 0 test in §4.4 falls through when rst is x — the comparison yields x, and if treats x as false.真是數值 1；假是 0、x 或 z。更精確地說，條件會被歸約成單一位元：非零的已知值為真，零為假，而任何含有 x 或 z、又不是因其他原因為非零的東西，都是假。這就是為什麼 §4.4 裡 rst == 0 的測試在 rst 為 x 時會掉下去 —— 比較的結果是 x，而 if 把 x 當成假。真は数値の 1 であり、偽は 0、x、z である。より正確には、条件は 1 ビットに縮約される：非零の既知値は真、零は偽、そして x や z を含み他の理由で非零にもならないものは偽である。§4.4 の rst == 0 の判定が rst が x のときに素通りするのはこのためである——比較の結果が x になり、if は x を偽として扱う。
• A dangling else binds to the nearest unmatched if. Exactly as in C. The fix is exactly as in C: use begin ... end.懸空的 else 會繫結到最近的、尚未配對的 if。和 C 完全一樣。修法也和 C 完全一樣：用 begin ... end。宙に浮いた else は、対になっていない直近の if に結び付く。C とまったく同じである。直し方も C とまったく同じで、begin ... end を使う。

always @ (posedge clk) begin
  // if reset is asserted
  if (reset == 1'b0) begin
    counter <= 4'b0000;
  // if counter is enabled and up count is asserted
  end else if (enable == 1'b1 && up_en == 1'b1) begin
    counter <= counter + 1'b1;
  // if counter is enabled and down count is asserted
  end else if (enable == 1'b1 && down_en == 1'b1) begin
    counter <= counter - 1'b1;
  // if counting is disabled
  end else begin
    counter <= counter;   // redundant code
  end
end

Three observations. The final branch is marked "redundant code" on the slide and it is: in a clocked block a register holds its value automatically, so counter <= counter; costs nothing and says nothing. Writing it is harmless and some coding standards require it for symmetry. In a combinational block the same line would be actively harmful — it is the textbook way to write a latch on purpose.三點觀察。最後那個分支在投影片上被標為「多餘的程式碼」，而它確實是：在時脈同步區塊裡，暫存器本來就會自動保住它的值，所以 counter <= counter; 不花成本，也什麼都沒說。寫它無害，而且有些程式碼規範為了對稱還要求寫。但在組合邏輯區塊裡，同樣這一行就會積極地造成傷害 —— 它正是教科書上「故意寫出一個閂鎖」的方法。観察が三つある。最後の分岐はスライドで「冗長なコード」と記されており、実際そのとおりである：クロック同期ブロックではレジスタは自動的に値を保つので、counter <= counter; はコストもかからず何も語らない。書いても害はなく、対称性のためにこれを要求するコーディング規約もある。しかし組合せ論理ブロックでは同じ一行が積極的に害をなす——これは教科書どおりの「わざとラッチを書く」方法だからである。

The chain is a priority structure, not a parallel one: if both up_en and down_en are asserted, up-count wins, and the synthesised logic is a cascade of 2-to-1 muxes whose depth grows with the number of branches. If the conditions are known to be mutually exclusive, a case with a (* parallel_case *)-style structure, or simply a case ({up_en, down_en}), will give the tool permission to build a flat mux instead.這個鏈是一個優先權結構，不是平行結構：如果 up_en 與 down_en 同時成立，上數勝出，而合成出來的邏輯是一串 2 選 1 多工器，其深度隨分支數成長。如果這些條件已知互斥，改用帶 (* parallel_case *) 風格結構的 case，或乾脆寫成 case ({up_en, down_en})，就等於給工具許可去建一個扁平的多工器。この連鎖は並列構造ではなく優先順位構造である：up_en と down_en が同時にアサートされればアップカウントが勝ち、合成される論理は 2 対 1 マルチプレクサの縦続で、その段数は分岐数とともに増える。条件が互いに排他的だと分かっているなら、(* parallel_case *) 風の構造を持つ case にするか、単に case ({up_en, down_en}) と書けば、ツールに平坦なマルチプレクサを作る許可を与えることになる。

Finally, note that reset is tested inside a block sensitive only to posedge clk, so this is a synchronous reset. Moving it to the sensitivity list as always @(posedge clk or negedge reset) would make it asynchronous and change the cell the tool picks. Lecture 6 covers the trade-off.最後要注意，reset 是在一個只對 posedge clk 敏感的區塊裡被測試的，所以這是同步重置。把它搬到敏感度列表裡變成 always @(posedge clk or negedge reset)，就會讓它變成非同步的，也會改變工具挑選的單元。第 6 講會談這個取捨。最後に、reset が posedge clk にしか感応しないブロックの中で判定されている点に注意したい。つまりこれは同期リセットである。これを感度リストへ移して always @(posedge clk or negedge reset) とすれば非同期になり、ツールが選ぶセルも変わる。このトレードオフは第 6 講で扱う。

7.5 The four loops7.5 四種迴圈7.5 四種類のループ

Verilog has repeat, for, while and forever. For simulation they behave as you expect. For synthesis there is exactly one rule that matters: a loop is synthesisable only if the tool can unroll it into a fixed number of iterations at elaboration time. A loop whose bound depends on a signal value is not synthesisable, because hardware has no program counter.Verilog 有 repeat、for、while 與 forever。就模擬而言，它們的行為一如你所預期。就合成而言，真正重要的規則只有一條：一個迴圈只有在工具能夠於展開階段把它攤成固定次數的迭代時，才是可合成的。界限取決於訊號數值的迴圈不可合成，因為硬體沒有程式計數器。Verilog には repeat、for、while、forever がある。シミュレーションでは予想どおりに振る舞う。合成について重要な規則はただ一つ：ループが合成可能なのは、エラボレーション時にツールが固定回数の反復へ展開できる場合だけである。境界が信号の値に依存するループは合成できない。ハードウェアにプログラムカウンタはないからである。

parameter memory_size = 1024;
...
word_address = 0;
repeat (memory_size)
  begin
    memory[word_address] = 0;
    word_address = word_address + 1;
  end

begin
  reg [7:0] temp;
  counter = 0;
  temp = a;
  while (temp)
    begin
      if (temp[0]) counter = counter + 1;
      // or: counter = counter + temp[0];
      temp = temp >> 1;
    end
end

The repeat example is a memory initialiser: 1024 iterations known at compile time, but it writes a memory array, so it belongs in a test bench or in the behavioural model of a RAM, not in RTL. The while example is a population counter and is the more instructive one. Its trip count depends on the position of the most significant 1 in a, so it runs between 0 and 8 times. A synthesis tool cannot unroll it. Rewriting it as a for (i = 0; i < 8; i = i + 1) counter = counter + a[i]; makes the bound static, unrolls to an 8-input adder tree, and synthesises fine.repeat 這個例子是一個記憶體初始化器：1024 次迭代在編譯期就已知，但它寫的是一個記憶體陣列，所以它該待在測試平台或 RAM 的行為模型裡，不該待在 RTL 裡。while 那個例子是一個人口計數器，也更有教育意義。它的迴圈次數取決於 a 裡最高位 1 的位置，所以會跑 0 到 8 次。合成工具攤不開它。把它改寫成 for (i = 0; i < 8; i = i + 1) counter = counter + a[i];，界限就變成靜態的，會攤成一棵 8 輸入的加法樹，合成得很順利。repeat の例はメモリ初期化である：1024 回の反復はコンパイル時に分かっているが、メモリ配列に書き込むので、居場所は RTL ではなくテストベンチか RAM の振る舞いモデルである。while の例はポピュレーションカウンタで、こちらのほうが教育的である。繰り返し回数は a の最上位の 1 の位置に依存し、0 回から 8 回まで変わる。合成ツールはこれを展開できない。for (i = 0; i < 8; i = i + 1) counter = counter + a[i]; と書き直せば境界が静的になり、8 入力の加算器ツリーへ展開されて問題なく合成される。

reg [15:0] data;
integer k;

for (k = 4; k > 0; k = k - 1)
  begin
    data[k+10] = 0;
    data[k+2]  = 1;
  end

reg [3:0] k;

for (k = 0; k <= 15; k = k + 1)
  ...

The right-hand loop never terminates. A 4-bit k can hold 0 through 15, so k <= 15 is a tautology; when k is 15, k + 1 wraps to 0 and the loop starts over. The simulator spins forever at the current simulation time and the run appears to hang. The fix is to widen the index — integer k; gives you 32 bits — or to change the bound to k < 15 and handle the last iteration separately. This failure mode is not specific to loop indices: any comparison between a counter and the maximum value its width can represent is a tautology.右邊那個迴圈永遠不會結束。一個 4 位元的 k 能裝 0 到 15，所以 k <= 15 是恆真式；當 k 是 15 時，k + 1 繞回 0，迴圈重新開始。模擬器在目前的模擬時間上永遠空轉，執行看起來就像當掉了。修法是把索引加寬 —— integer k; 給你 32 位元 —— 或把界限改成 k < 15 再另外處理最後一次迭代。這種失效模式不是迴圈索引獨有的：任何把計數器與它的位寬所能表示的最大值做比較，都是恆真式。右のループは決して終わらない。4 ビットの k は 0 から 15 までしか取れないので k <= 15 は恒真であり、k が 15 のとき k + 1 は 0 に巻き戻ってループが最初からやり直される。シミュレータは現在のシミュレーション時刻のまま永久に空回りし、実行はハングしたように見える。直し方はインデックスを広げる（integer k; なら 32 ビット）か、境界を k < 15 にして最後の反復を別扱いにすることである。この失敗様式はループインデックスに限らない：カウンタとその幅で表せる最大値との比較は、どれも恒真式である。

7.6 Worked example: the 4-bit carry look-ahead adder7.6 實例：4 位元超前進位加法器7.6 実例：4 ビットキャリー先見加算器

A ripple-carry adder's delay grows linearly with width because bit $i$ cannot compute its sum until bit $i-1$ has produced its carry. Carry look-ahead breaks the chain by computing, for each bit position, two signals that depend only on the operands:漣波進位加法器的延遲隨位寬線性成長，因為位元 $i$ 在位元 $i-1$ 產出進位之前算不出自己的和。超前進位打斷這條鏈的方式，是替每一個位元位置算出兩個只相依於運算元的訊號：リプルキャリー加算器の遅延は幅に比例して増える。ビット $i$ はビット $i-1$ がキャリーを出すまで自分の和を計算できないからである。キャリー先見はこの連鎖を断ち切るために、各ビット位置についてオペランドだけに依存する二つの信号を計算する。

In words: position $i$ generates a carry when both operand bits are 1, and propagates an incoming carry when exactly one is. Expanding the recurrence gives each carry as a two-level function of the operands and $c_0$:用文字說：位置 $i$ 在兩個運算元位元都是 1 時產生一個進位，在剛好只有一個是 1 時傳遞進來的進位。把這個遞迴式展開，每一個進位就成為運算元與 $c_0$ 的兩層函數：言葉で言えば、位置 $i$ は両方のオペランドビットが 1 のときキャリーを生成し、ちょうど一方が 1 のとき入ってくるキャリーを伝播する。この漸化式を展開すると、各キャリーはオペランドと $c_0$ の二段の関数として表される。

Every carry is now a sum of products of inputs, so in principle all four are available after two gate delays instead of eight. The cost is fan-in: $c_4$ needs a five-input OR and a five-input AND, which is why real adders use 4-bit look-ahead blocks joined by a second level of look-ahead rather than one 32-bit expansion.現在每一個進位都是輸入的積之和，所以原則上四個進位在兩個閘延遲之後就都可用，而不是八個。代價是扇入：$c_4$ 需要一個五輸入 OR 與一個五輸入 AND，這就是為什麼真實的加法器用的是以第二層超前進位串起來的 4 位元超前進位區塊，而不是一個 32 位元的大展開式。いまや各キャリーは入力の積和なので、原理的には四つとも八ゲート遅延ではなく二ゲート遅延で得られる。代償はファンインである：$c_4$ には 5 入力 OR と 5 入力 AND が要る。実際の加算器が 32 ビットを一気に展開せず、4 ビットの先見ブロックを第二段の先見でつなぐ構成を採るのはこのためである。

module Add_prop_gen (sum, c_out, a, b, c_in);   // 4-bit look-ahead carry adder
  output [3:0] sum;                             // behavioral model
  output       c_out;
  input  [3:0] a, b;
  input        c_in;

  reg  [3:0] carrychain;
  wire [3:0] g = a & b;   // carry generate,  continuous assignment, bitwise and
  wire [3:0] p = a ^ b;   // carry propagate, continuous assignment, bitwise xor

  always @ (a or b or c_in)               // event "or"
    begin : carry_generation              // usage: block name
      integer i;
      #0 carrychain[0] = g[0] + (p[0] & c_in);   // needed for simulation
      for (i = 1; i <= 3; i = i + 1)
        begin
          carrychain[i] = g[i] | (p[i] & carrychain[i-1]);
        end
    end

  wire [4:0] shiftedcarry = {carrychain, c_in};  // concatenation
  wire [3:0] sum   = p ^ shiftedcarry;           // summation
  wire       c_out = shiftedcarry[4];            // carry out, bit select
endmodule

Five details in that code are worth unpicking, because each one is a general technique rather than a trick for adders.那段程式碼裡有五個細節值得拆開來看，因為每一個都是通用技巧，不是加法器專用的花招。このコードには解きほぐす価値のある細部が五つある。どれも加算器専用の小技ではなく、一般的な技法だからである。

• begin : carry_generation is a named block, and you need the name because local declarations — here integer i; — are only legal inside a named block. The name is also the handle that disable would use.begin : carry_generation 是一個具名區塊，而你需要這個名字，因為區域宣告 —— 這裡是 integer i; —— 只有在具名區塊裡才合法。這個名字同時也是 disable 會用到的把手。begin : carry_generation は名前付きブロックである。名前が要るのは、ローカル宣言——ここでは integer i;——が名前付きブロックの中でしか合法でないからである。この名前は disable がつかむ取っ手でもある。
• The first line uses + where the loop uses |. They give the same answer here because $g_i$ and $p_i$ can never both be 1: $g_i = a_i b_i$ requires both operand bits set, $p_i = a_i \oplus b_i$ requires exactly one. With at most one operand of the addition equal to 1, there is no carry out of the 1-bit sum and $g_i + p_i c_i = g_i \,|\, p_i c_i$. Had they been able to coincide, the + would overflow the 1-bit target and produce 0 where the OR gives 1.第一行用 +，而迴圈裡用 |。它們在這裡給出相同的答案，因為 $g_i$ 與 $p_i$ 不可能同時為 1：$g_i = a_i b_i$ 要求兩個運算元位元都成立，$p_i = a_i \oplus b_i$ 要求剛好只有一個成立。既然這個加法最多只有一個運算元等於 1，這個 1 位元加法就不會有進位輸出，於是 $g_i + p_i c_i = g_i \,|\, p_i c_i$。倘若它們有可能同時成立，+ 就會溢出 1 位元的目標，在 OR 給出 1 的地方給出 0。最初の行は + を使い、ループは | を使っている。ここで両者が同じ答えを与えるのは、$g_i$ と $p_i$ が同時に 1 になりえないからである：$g_i = a_i b_i$ は両方のオペランドビットが立つことを要し、$p_i = a_i \oplus b_i$ はちょうど一方が立つことを要する。この加算のオペランドのうち 1 なのは高々一つなので、1 ビットの和からのキャリー出力は生じず、$g_i + p_i c_i = g_i \,|\, p_i c_i$ となる。もし両者が同時に成り立ちえたなら、+ は 1 ビットの対象をあふれさせ、OR が 1 を与える場所で 0 を与えてしまう。
• shiftedcarry = {carrychain, c_in} is the alignment trick. Concatenation puts c_in in bit 0 and carrychain[i] in bit $i+1$, so shiftedcarry[i] is exactly the carry into bit $i$. That turns the per-bit equation $s_i = p_i \oplus c_i$ into the single vector expression sum = p ^ shiftedcarry — with p being 4 bits and shiftedcarry 5, the assignment to a 4-bit sum simply truncates, which is what you want.shiftedcarry = {carrychain, c_in} 是對齊的訣竅。串接把 c_in 放到位元 0，把 carrychain[i] 放到位元 $i+1$，所以 shiftedcarry[i] 剛好就是進入位元 $i$ 的那個進位。這就把逐位元的方程式 $s_i = p_i \oplus c_i$ 變成單一個向量運算式 sum = p ^ shiftedcarry —— p 是 4 位元而 shiftedcarry 是 5 位元，指派給 4 位元的 sum 時就直接截掉，而那正是你想要的。shiftedcarry = {carrychain, c_in} は桁合わせの小技である。連結は c_in をビット 0 に、carrychain[i] をビット $i+1$ に置くので、shiftedcarry[i] はちょうどビット $i$ に入るキャリーになる。これによりビットごとの式 $s_i = p_i \oplus c_i$ が単一のベクタ式 sum = p ^ shiftedcarry になる——p は 4 ビット、shiftedcarry は 5 ビットなので、4 ビットの sum への代入では単に切り捨てられ、それが望みどおりである。
• c_out is bit 4 of the same vector, i.e. carrychain[3], which is $c_4$.c_out 是同一個向量的位元 4，也就是 carrychain[3]，即 $c_4$。c_out は同じベクタのビット 4、すなわち carrychain[3] であり、$c_4$ である。
• The #0 defers the block past the Active region so that g and p have settled — see §6.3, and the warning there about why you should not need it.那個 #0 把區塊推遲到 Active 區域之後，好讓 g 與 p 先穩定 —— 見 §6.3，以及那裡關於「你本來就不該需要它」的警告。この #0 はブロックを Active 領域の後まで先送りし、g と p を先に落ち着かせる——§6.3 と、そこにある「本来これは要らないはず」という警告を参照。

always @* begin
  carrychain[0] = g[0] | (p[0] & c_in);
  for (i = 1; i <= 3; i = i + 1)
    carrychain[i] = g[i] | (p[i] & carrychain[i-1]);
end

7.7 forever and disable7.7 forever 與 disable7.7 forever と disable

initial
  begin : clock_loop
    clock = 0;
    forever
      #10 clock = ~clock;
  end

initial
  #100 disable clock_loop;

module find_first_one (a, trigger, i);
  input  [15:0] a;
  input         trigger;
  output [4:0]  i;
  reg    [4:0]  i;

  always @ trigger
    begin : search
      for (i = 0; i < 16; i = i + 1)
        if (a[i] == 1) disable search;
    end
endmodule

The left pair answers the slide's question "what is the difference between always and forever?". always is a module-level construct: it starts at time 0, cannot be preceded by setup code, and cannot be stopped. forever is a statement: it can appear anywhere inside a procedural block, so it can be preceded by initialisation (here clock = 0;, which is why this version does not need a separate initial), it can be entered conditionally, and because it sits inside a named block it can be terminated with disable. For a clock generator you want forever whenever you intend to stop the clock partway through a test.左邊那一對回答了投影片的問題「always 與 forever 有什麼差別？」。always 是模組層級的構造：它在時間 0 啟動，前面不能放設定用的程式碼，而且停不下來。forever 是一道敘述：它可以出現在程序區塊內的任何地方，所以前面可以放初始化（這裡是 clock = 0;，這也是為什麼這個版本不需要另外一個 initial），它可以被有條件地進入，而且因為它待在一個具名區塊裡，可以用 disable 終止。對時脈產生器來說，只要你打算在測試中途把時脈停掉，你要的就是 forever。左の対はスライドの問い「always と forever の違いは何か」に答えている。always はモジュールレベルの構文である：時刻 0 に起動し、前に準備コードを置けず、止めることもできない。forever は文である：手続き型ブロック内のどこにでも書けるので前に初期化を置け（ここでは clock = 0;。この版に別途 initial が要らないのはこのためである）、条件つきで入ることもでき、名前付きブロックの中にあるので disable で終了させられる。クロック生成器については、テストの途中でクロックを止めるつもりなら forever を使うべきである。

The right-hand module answers the second question, "what is the difference between disable and $finish?". disable name; terminates the named block or task, discarding whatever it was doing, and execution resumes at the statement following the block — the rest of the simulation is unaffected. $finish ends the entire simulation run and returns control to the shell. $stop is the third member of the family: it suspends the run and drops into the simulator's interactive prompt, which is what you want in a debug session and never what you want in a regression.右邊那個模組回答第二個問題：「disable 與 $finish 有什麼差別？」。disable name; 終止指定的具名區塊或任務，把它正在做的事全部丟掉，執行從該區塊之後的那道敘述繼續 —— 模擬的其餘部分不受影響。$finish 結束整段模擬執行，把控制權交回殼層。$stop 是這一家族的第三個成員：它暫停執行，掉進模擬器的互動提示符，那是除錯時你想要的，而在回歸測試裡永遠不是你想要的。右のモジュールは二つ目の問い「disable と $finish の違いは何か」に答えている。disable name; は指定した名前付きブロックまたはタスクを終了させ、途中の処理を破棄し、そのブロックの次の文から実行が再開される——シミュレーションの他の部分には影響しない。$finish はシミュレーションの実行全体を終わらせ、制御をシェルへ返す。$stop はこの一族の三人目である：実行を中断してシミュレータの対話プロンプトに落とす。デバッグ中には望ましく、回帰テストでは決して望ましくない。

8. Parallel Activity Flow and Race Conditions8. 平行活動流程與競爭條件8. 並列アクティビティフローと競合状態

8.1 fork ... join

Everything inside begin ... end executes sequentially in one thread. Everything inside fork ... join executes as separate concurrent threads, all starting at the same instant, and the join does not complete until every one of them has finished. The construct is not supported by synthesis — there is no way to build "a thread" — and lives entirely in test benches.begin ... end 裡的一切都在同一個執行緒裡循序執行。fork ... join 裡的一切則以各自獨立的並行執行緒執行，全部在同一瞬間啟動，而 join 要等到它們每一個都結束才算完成。這個構造不被合成支援 —— 根本沒有辦法蓋出「一條執行緒」—— 它完全活在測試平台裡。begin ... end の中はすべて一つのスレッドで逐次実行される。fork ... join の中はすべて別個の並行スレッドとして実行され、全部が同じ瞬間に起動し、join はそのすべてが終わるまで完了しない。この構文は合成では扱えず——「スレッド」を作る方法などない——完全にテストベンチの住人である。

fork
  #50  a = 1;
  #100 a = 0;
  #150 a = 1;
  #200 a = 0;
join

begin
  #50 a = 1;
  #50 a = 0;
  #50 a = 1;
  #50 a = 0;
end

Both produce the same waveform, and the slide pairs them to make exactly that point: inside a fork every delay is measured from the moment the fork was entered, so the numbers are absolute times; inside a begin each delay is measured from the previous statement, so the numbers are increments. The fork version is often more readable for a stimulus schedule, because you can read the firing time of each line directly instead of running a mental sum. Both complete at t = 200: the begin because 50×4 = 200, the fork because join waits for the slowest thread.兩者產生相同的波形，而投影片把它們配成一對，要講的正是這一點：在 fork 裡，每一個延遲都是從進入 fork 的那一刻起算的，所以那些數字是絕對時間；在 begin 裡，每一個延遲都是從上一道敘述起算的，所以那些數字是增量。就一份激勵時程表而言，fork 版本往往比較好讀，因為你可以直接讀出每一行的發動時間，不必在心裡做加總。兩者都在 t = 200 完成：begin 是因為 50×4 = 200，fork 是因為 join 要等最慢的那條執行緒。どちらも同じ波形を生み、スライドが両者を並べているのはまさにこの点を言うためである：fork の中では各遅延が fork に入った瞬間から測られるので、数値は絶対時刻である。begin の中では各遅延が直前の文から測られるので、数値は増分である。刺激のスケジュールとしては fork 版のほうが読みやすいことが多い。各行の発火時刻を暗算の足し算なしに直接読めるからである。どちらも t = 200 で完了する：begin は 50×4 = 200 だから、fork は join が最も遅いスレッドを待つからである。

Three properties of fork that the slide lists and that follow from the event-queue model of §2.1:投影片列出的 fork 三個性質，它們都可以從 §2.1 的事件佇列模型推出來：スライドが挙げる fork の三つの性質。いずれも §2.1 のイベントキューのモデルから導かれる。

• No ordering among threads. All four statements become Active events in the same time slot when their delays expire. If two of them expire simultaneously, the order is undefined.執行緒之間沒有順序。四道敘述在各自的延遲到期時，都成為同一時槽裡的 Active 事件。如果其中兩個同時到期，順序就未定義。スレッド間に順序はない。四つの文は、それぞれの遅延が満了したときに同じタイムスロットの Active イベントになる。そのうち二つが同時に満了すれば順序は未定義である。
• The join waits for all of them. There is no "first one wins" in IEEE 1364; that is join_any, a SystemVerilog addition.join 會等它們全部。IEEE 1364 裡沒有「第一個到的獲勝」；那是 join_any，是 SystemVerilog 的追加功能。join はそのすべてを待つ。IEEE 1364 に「最初の一つが勝つ」はない。それは join_any であり、SystemVerilog の追加機能である。
• Interaction between threads can be ambiguous — which is the subject of the rest of this section.執行緒之間的互動可能有歧義 —— 這正是本節其餘部分的主題。スレッド間の相互作用は曖昧になりうる——これがこの節の残りの主題である。

8.2 Anatomy of a race8.2 競爭的解剖8.2 競合の解剖

The lecture's definition is good: a race condition exists when the value of a target signal is ambiguous because different assignment statements occur simultaneously. The operative word is simultaneously — in the same time slot and in the same region, where the standard imposes no order.講義的定義不錯：當不同的指派敘述同時發生，使得某個目標訊號的值變得有歧義時，就存在一個競爭條件。關鍵字是同時 —— 在同一個時槽、同一個區域裡，而標準在那裡沒有規定順序。講義の定義は良い：異なる代入文が同時に起こることで、ある目標信号の値が曖昧になるとき、競合状態が存在する。効いている語は同時にである——同じタイムスロットの同じ領域の中であり、そこに標準は順序を課していない。

fork
  #150 a = b;
  #150 c = a;
join

fork
  a = #150 b;
  c = #150 a;
join

In the left version, both threads sleep until t = 150 and then both become Active events in the same time slot. If the simulator picks the first thread first, a takes the value of b and then c takes the new a, i.e. c ends up equal to b. If it picks the second first, c takes the old a. Both are legal simulations of the same source, and nothing in the language lets you predict or control which you get. Different simulators give different answers; the same simulator with optimisation on and off can give different answers.在左邊的版本裡，兩條執行緒都睡到 t = 150，然後兩者都在同一個時槽成為 Active 事件。如果模擬器先挑第一條執行緒，a 取到 b 的值，接著 c 取到新的 a，也就是 c 最後等於 b。如果它先挑第二條，c 取到的是舊的 a。兩者都是同一份原始碼的合法模擬，而語言裡沒有任何東西能讓你預測或控制你會拿到哪一個。不同的模擬器給不同的答案；同一個模擬器開不開最佳化也可能給不同的答案。左の版では、二つのスレッドがどちらも t = 150 まで眠り、そこで同じタイムスロットの Active イベントになる。シミュレータが一つ目のスレッドを先に選べば、a は b の値を取り、続いて c は新しい a を取る。つまり c は最終的に b と等しくなる。二つ目を先に選べば、c は古い a を取る。どちらも同じソースの合法なシミュレーションであり、どちらになるかを予測したり制御したりする手段は言語にない。シミュレータが違えば答えも違い、同じシミュレータでも最適化の有無で答えが変わりうる。

In the right version, both RHS are evaluated by the intra-assignment rule at t = 0, long before either write. c therefore receives the value a held at t = 0, deterministically, and the pair behaves like a one-deep shift. The order in which the two writes land at t = 150 no longer matters, because neither write feeds the other's read.在右邊的版本裡，兩個右手邊都依指派內規則在 t = 0 就求好了值，遠早於任何一次寫入。因此 c 確定地收到 a 在 t = 0 所持有的值，這一對的行為就像一級移位。兩次寫入在 t = 150 落地的先後不再重要，因為兩次寫入都不餵給對方的讀。右の版では、二つの右辺がどちらも代入内の規則に従って t = 0 に評価されており、どちらの書き込みよりはるかに早い。したがって c は t = 0 に a が保持していた値を確定的に受け取り、この対は一段のシフトのように振る舞う。二つの書き込みが t = 150 に落ちる順序はもはや問題にならない。どちらの書き込みも相手の読み出しに供給していないからである。

8.3 Three ways to kill a race8.3 消除競爭的三種方法8.3 競合を消す三つの方法

Generalising from that example, there are exactly three mechanisms, and it is worth knowing all three because they apply in different situations.從那個例子推廣出去，機制剛好有三種，而三種都值得知道，因為它們適用於不同的情境。あの例から一般化すると、機構はちょうど三つある。三つとも知っておく価値がある。それぞれ別の状況に当てはまるからである。

1. Separate the reads from the writes in time. That is what intra-assignment delay does above: all the reads happen in one time slot and all the writes in a later one, so the order within each slot is irrelevant.在時間上把讀與寫分開。這就是上面指派內延遲所做的事：所有的讀都發生在一個時槽，所有的寫都發生在較晚的另一個時槽，於是每個時槽內部的順序都無關緊要。読み出しと書き込みを時間的に分ける。上の代入内遅延がしているのがこれである：すべての読み出しが一つのタイムスロットで、すべての書き込みがより後のタイムスロットで起こるので、各スロット内の順序は無関係になる。
2. Separate the reads from the writes by region. That is what non-blocking assignment does. fork #150 a <= b; #150 c <= a; join has both reads in the Active region of t = 150 and both writes in the NBA region, so c gets the old a regardless of thread order. This is the same mechanism that makes a bank of flip-flops well-defined, and it is why RTL written with <= throughout is race-free by construction.用區域把讀與寫分開。這就是非阻斷式指派所做的事。fork #150 a <= b; #150 c <= a; join 的兩次讀都在 t = 150 的 Active 區域，兩次寫都在 NBA 區域，所以不論執行緒順序如何，c 拿到的都是舊的 a。這和讓一排正反器定義良好的機制是同一個，也正是為什麼通篇用 <= 寫出來的 RTL 在構造上就不會有競爭。読み出しと書き込みを領域で分ける。ノンブロッキング代入がしているのがこれである。fork #150 a <= b; #150 c <= a; join では二つの読み出しが t = 150 の Active 領域に、二つの書き込みが NBA 領域に入るので、スレッドの順序にかかわらず c は古い a を得る。これはフリップフロップ群を well-defined にする機構と同じであり、全体を <= で書いた RTL が構造的に競合を持たない理由でもある。
3. Impose an explicit order. Replace the fork with a begin, or add a handshake — a named event, a wait on a flag — so that one thread cannot proceed until the other has finished. This is the right answer when the two threads really do have a dependency rather than merely coinciding.明確規定一個順序。把 fork 換成 begin，或加上一個握手 —— 一個具名事件、一個對旗標的 wait —— 讓其中一條執行緒在另一條結束之前無法前進。當兩條執行緒之間真的有相依性、而不是只是碰巧同時發生時，這才是正確的答案。明示的に順序を課す。fork を begin に替えるか、ハンドシェイク——名前付きイベント、フラグに対する wait——を加えて、一方のスレッドが他方の終了まで進めないようにする。二つのスレッドが単に時刻を共有しているのではなく本当に依存関係を持つ場合は、これが正しい答えである。

fork
  #10 x = 1;
  begin #5 y = 2; #10 y = 3; end
  #20 z = x + y;
join

9. Tasks and Functions9. 任務與函式9. タスクと関数

Part 2 of the lecture opens with the two subprogram constructs. Their purpose is the same as in any language — execute a common procedure from several places, and give it a readable name — but the two differ in a set of rules that is small, rigid, and almost entirely motivated by one question: may this subprogram consume simulation time?講義的第 2 部以這兩個副程式構造開場。它們的目的和任何語言裡的一樣 —— 從好幾個地方執行同一段共用程序，並給它一個好讀的名字 —— 但兩者在一組又小又死板的規則上不同，而那組規則幾乎完全出自同一個問題：這個副程式可不可以消耗模擬時間？講義のパート 2 はこの二つのサブプログラム構文から始まる。目的はどの言語でも同じ——共通の手続きを複数の場所から実行し、読みやすい名前を与える——だが、両者は小さく厳格な規則の集合によって異なり、その規則はほぼすべて一つの問いに由来する：このサブプログラムはシミュレーション時間を消費してよいか。

9.1 The two constructs side by side9.1 兩種構造並排比較9.1 二つの構文を並べて見る

Every row of that table follows from the last one but two. A function is invoked from inside an expression, and an expression has to produce a value now — there is no way to suspend the evaluation of y = f(a) + g(b) halfway through and resume it at the next clock edge. So a function may not contain a timing control, may not call a task, and necessarily completes in zero simulation time. A task, by contrast, is invoked as a statement from a thread that is perfectly capable of suspending, so it may contain anything a procedural block may contain.那張表的每一列，都是從倒數第三列推出來的。函式是從運算式內部被呼叫的，而運算式必須當下就產出一個值 —— 沒有辦法把 y = f(a) + g(b) 的求值做到一半暫停，下一個時脈邊緣再接下去。所以函式不得含有時間控制、不得呼叫任務，而且必然在零模擬時間內完成。任務則相反，它是以一道敘述的形式、從一條完全有能力暫停的執行緒裡被呼叫的，所以它可以含有程序區塊所能含有的任何東西。この表の各行は、下から三番目の行から導かれる。関数は式の内部から呼ばれ、式はいま値を出さねばならない——y = f(a) + g(b) の評価を途中で中断して次のクロックエッジで再開する方法はない。だから関数はタイミング制御を含めず、タスクを呼べず、必然的にシミュレーション時間ゼロで完了する。対してタスクは、中断する能力を十分に備えたスレッドから文として呼ばれるので、手続き型ブロックが含みうるものは何でも含んでよい。

That same distinction decides what each construct means to a synthesis tool. A function describes a combinational computation: inputs in, one value out, no time elapsed, so it is a cone of logic and nothing more. A task may or may not be synthesisable depending on what is inside it — a task containing only assignments is just an inlined block of logic, while a task containing @(posedge clk) is a multi-cycle behaviour that most tools reject.同樣這個區別也決定了兩種構造對合成工具的意義。函式描述的是一個組合邏輯運算：輸入進去，一個值出來，沒有時間流逝，所以它就是一個邏輯錐，如此而已。任務可不可合成則取決於裡面放了什麼 —— 只含指派的任務不過是一塊被內嵌進來的邏輯，而含有 @(posedge clk) 的任務是一個跨週期的行為，多數工具會拒絕。この同じ区別が、両構文が合成ツールにとって何を意味するかも決める。関数は組合せ演算を記述する：入力が入り、値が一つ出て、時間は流れない。だから論理コーンそのもの以上の何物でもない。タスクが合成可能かどうかは中身次第である——代入だけのタスクはインライン展開される論理の塊にすぎないが、@(posedge clk) を含むタスクは複数サイクルにわたる振る舞いであり、ほとんどのツールが拒否する。

9.2 Task characteristics9.2 任務的特性9.2 タスクの特性

• Declared within a module, and must be named. There are no anonymous tasks.宣告在模組內部，而且必須具名。沒有匿名任務這種東西。モジュール内で宣言され、名前を持たねばならない。無名タスクというものはない。
• Called from a procedural statement. You cannot call a task from a continuous assignment.從程序性敘述呼叫。你不能從連續指派呼叫任務。手続き型文から呼び出す。連続代入からタスクを呼ぶことはできない。
• Local variables may be declared inside the task body, in addition to the arguments.可以宣告區域變數，就在任務本體裡，除了引數之外。ローカル変数を宣言できる。引数とは別に、タスク本体の中で宣言する。
• Arguments keep the type they have in the calling environment. A task does not convert or re-interpret what you hand it.引數保持它們在呼叫端環境裡的型別。任務不會轉換或重新詮釋你交給它的東西。引数は呼び出し側の環境で持っている型をそのまま保つ。タスクは渡されたものを変換したり解釈し直したりしない。
• Arguments are passed by value, and associated positionally, in the order the ports were declared. Inputs are copied in when the task is entered; outputs are copied back when it returns. There is no pass-by-reference in IEEE 1364, which has a consequence people trip over: if a task contains a delay, the caller's output variable is not updated until the task finishes, not at the moment the task writes it internally.引數以傳值方式傳遞，並依照埠宣告的順序按位置對應。輸入在進入任務時被複製進去；輸出在返回時被複製回來。IEEE 1364 裡沒有傳參考，而這有一個會絆倒人的後果：如果任務裡含有延遲，呼叫端的 output 變數要等任務結束才會更新，不是在任務內部寫它的那一刻。引数は値渡しであり、ポート宣言の順に位置で対応づけられる。入力はタスクに入るときにコピーされ、出力は戻るときにコピーし返される。IEEE 1364 に参照渡しはなく、これは人がつまずく帰結を持つ：タスクが遅延を含む場合、呼び出し側の output 変数が更新されるのは、タスクが内部でそれに書き込んだ瞬間ではなく、タスクが終了したときである。

9.3 Function characteristics9.3 函式的特性9.3 関数の特性

• Declared within a module. Same as a task.宣告在模組內部。和任務一樣。モジュール内で宣言される。タスクと同じである。
• May implement only combinational behaviour. This is the consequence, not an extra rule.只能實作組合邏輯行為。這是推論出來的後果，不是額外的規則。組合せ的な振る舞いしか実装できない。これは帰結であって追加の規則ではない。
• Referenced in an expression — the right-hand side of a continuous assignment, a procedural assignment, a condition, an argument to another call.在運算式裡被引用 —— 連續指派的右手邊、程序性指派、一個條件，或另一次呼叫的引數。式の中で参照される——連続代入の右辺、手続き型代入、条件、別の呼び出しの引数などである。
• Local variables may be declared.可以宣告區域變數。ローカル変数を宣言できる。
• The value is returned by the function's name. Declaring function [7:0] align; implicitly creates a register variable called align, 8 bits wide, and whatever that variable holds when the body ends is the returned value. You must assign to it on every path, or the function returns x.回傳值由函式的名字帶出。宣告 function [7:0] align; 會隱含地建立一個叫 align 的暫存器變數，寬 8 位元，而本體結束時那個變數持有的值就是回傳值。你必須在每一條路徑上都對它指派，否則函式會回傳 x。戻り値は関数の名前で返す。function [7:0] align; という宣言は、幅 8 ビットの align という名のレジスタ変数を暗黙に作り、本体が終わったときにその変数が保持している値が戻り値になる。すべての経路でそれに代入しなければ、関数は x を返す。

9.4 Example: a task that counts ones9.4 範例：一個數 1 的任務9.4 例：1 を数えるタスク

module bit_counter (data, count);
  input  [7:0] data;
  output [3:0] count;
  reg    [3:0] count;

  always @ (data)
    count_ones_in_data (data, count);

  task count_ones_in_data;
    input  [7:0] a;
    output [3:0] c;
    reg    [3:0] c;
    reg    [7:0] tmp;

    begin c = 0; tmp = a;
      while (tmp)
        begin
          c = c + tmp[0];
          tmp = tmp >> 1;
        end
    end
  endtask
endmodule

This is the while loop of §7.5 wrapped in a task. The call count_ones_in_data (data, count); associates data with the first declared port a and count with the second, c, purely by position. On entry data is copied into a; on exit c is copied back into count. The local tmp exists only to be destroyed by the shifting, leaving the caller's data untouched — which is the point of pass-by-value.這就是 §7.5 那個 while 迴圈包成任務的樣子。呼叫 count_ones_in_data (data, count); 時，純粹依位置把 data 對應到第一個宣告的埠 a，把 count 對應到第二個埠 c。進入時 data 被複製進 a；離開時 c 被複製回 count。區域變數 tmp 的存在只是為了被移位毀掉，讓呼叫端的 data 毫髮無傷 —— 這正是傳值的意義。これは §7.5 の while ループをタスクで包んだものである。呼び出し count_ones_in_data (data, count); は、純粋に位置によって data を最初に宣言されたポート a に、count を二番目の c に対応づける。入るときに data が a へコピーされ、出るときに c が count へコピーし返される。ローカル変数 tmp はシフトによって壊されるためだけに存在し、呼び出し側の data は無傷のまま残る——これが値渡しの要点である。

9.5 Example: a function in a continuous assignment9.5 範例：在連續指派裡使用函式9.5 例：連続代入の中で関数を使う

module word_aligner (w_in, w_out);
  input  [7:0] w_in;
  output [7:0] w_out;

  assign w_out = align (w_in);          // function call in an expression

  function [7:0] align;
    input [7:0] word;
    begin
      align = word;
      if (align != 0)
        while (align[7] == 0)
          align = align << 1;
    end
  endfunction
endmodule

The function normalises a byte by shifting it left until the most significant bit is 1 — the integer half of a floating-point normalisation step. Three things to notice.這個函式把一個位元組左移到最高位元為 1 為止，藉此做正規化 —— 這是浮點數正規化步驟的整數部分。有三點要注意。この関数は 1 バイトを最上位ビットが 1 になるまで左シフトして正規化する——浮動小数点の正規化ステップの整数部分にあたる。注意すべき点が三つある。

• It is called from a continuous assignment, which is only possible because it is a function. The whole module is therefore combinational: whenever w_in changes, the continuous assignment re-evaluates, which re-runs the function from scratch in zero time.它是從連續指派呼叫的，而這只有因為它是函式才有可能。因此整個模組是組合邏輯的：只要 w_in 改變，連續指派就重新求值，也就在零時間內從頭重跑一次這個函式。連続代入から呼ばれている。これは関数だからこそ可能である。したがってモジュール全体が組合せ論理である：w_in が変化するたびに連続代入が再評価され、関数がゼロ時間で最初から走り直す。
• The if (align != 0) guard is load-bearing. Without it, an input of 8'b0 gives a while loop in which align[7] is 0 forever and shifting a zero produces another zero — an infinite loop at zero simulation time, i.e. a hang. Any while inside a zero-time context needs a proof of termination, and here the proof is "the word is non-zero and each shift moves the leading 1 one place left, so at most seven shifts are needed".if (align != 0) 這道護欄是承重的。沒有它的話，輸入 8'b0 會得到一個 align[7] 永遠是 0 的 while 迴圈，而把零移位還是零 —— 零模擬時間上的無窮迴圈，也就是當掉。任何在零時間情境裡的 while 都需要一個終止性的證明，而這裡的證明是「這個字非零，而每次移位把前導的 1 往左挪一格，所以最多需要七次移位」。if (align != 0) のガードは荷重を支えている。これがなければ、入力 8'b0 に対して align[7] が永遠に 0 の while ループになり、零をシフトしても零のままである——シミュレーション時間ゼロのままの無限ループ、つまりハングである。ゼロ時間の文脈にある while には終了性の証明が要る。ここでの証明は「語は非零であり、各シフトが先頭の 1 を一桁左へ動かすので、シフトは高々七回で済む」である。
• Synthesis will probably refuse it as written. The trip count depends on the data, so the loop cannot be unrolled. Rewriting the body as a for (i = 0; i < 7; i = i + 1) if (align[7] == 0) align = align << 1; gives a statically bounded seven-stage conditional shifter that synthesises into a barrel shifter. The function wrapper itself costs nothing — it is inlined.依原樣來看，合成大概會拒絕它。迴圈次數相依於資料，所以攤不開。把本體改寫成 for (i = 0; i < 7; i = i + 1) if (align[7] == 0) align = align << 1;，就得到一個靜態有界的七級條件移位器，會合成成一個桶形移位器。函式這層包裝本身不花成本 —— 它會被內嵌。書かれたままでは合成はおそらく拒否する。繰り返し回数がデータに依存するのでループを展開できない。本体を for (i = 0; i < 7; i = i + 1) if (align[7] == 0) align = align << 1; と書き直せば、静的に有界な七段の条件シフタとなり、バレルシフタに合成される。関数という包み自体にコストはない——インライン展開される。

9.6 Example: a linear feedback shift register9.6 範例：線性回授移位暫存器9.6 例：線形帰還シフトレジスタ

An LFSR is a shift register whose serial input is formed by XOR-ing selected taps of its own state. With the right tap set it visits all $2^N - 1$ non-zero states before repeating, which makes it the standard cheap pseudo-random pattern generator for built-in self test — the application the slide cites.LFSR 是一個移位暫存器，它的序列輸入是由自己狀態中若干個選定抽頭 XOR 出來的。只要抽頭組選得對，它會在重複之前走遍全部 $2^N - 1$ 個非零狀態，這使它成為內建自我測試裡標準的廉價偽隨機樣式產生器 —— 也就是投影片所引用的應用。LFSR は、自分自身の状態から選んだタップを XOR した値を直列入力とするシフトレジスタである。タップの組を正しく選べば、繰り返すまでに $2^N - 1$ 個のすべての非零状態を巡る。これが、組込み自己テストにおける標準的で安価な擬似乱数パターン生成器となる理由であり、スライドが挙げている用途である。

The lecture's structure is the external-XOR (Fibonacci) form drawn right-to-left. Using the slide's 1-based labels: $c_N = 1$ always, meaning the bit shifted out at $Y[0]$ is fed back to the leftmost stage; and for $j = 1 \ldots N-1$, if $c_j = 1$ the input of stage $j-1$ is $Y[j] \oplus Y[0]$, otherwise it is simply $Y[j]$.講義裡的結構是右到左畫出來的外部 XOR（Fibonacci）形式。沿用投影片以 1 起算的標號：$c_N = 1$ 恆成立，意思是從 $Y[0]$ 移出去的位元被回授到最左邊那一級；而對 $j = 1 \ldots N-1$，若 $c_j = 1$，則第 $j-1$ 級的輸入是 $Y[j] \oplus Y[0]$，否則就只是 $Y[j]$。講義の構成は右から左へ描かれた外部 XOR（フィボナッチ）形式である。スライドの 1 始まりのラベルに従うと、$c_N = 1$ はつねに成り立ち、$Y[0]$ から出ていくビットが最左段へ帰還することを意味する。そして $j = 1 \ldots N-1$ について、$c_j = 1$ なら段 $j-1$ の入力は $Y[j] \oplus Y[0]$、そうでなければ単に $Y[j]$ である。

module Autonomous_LFSR1 (Clock, Reset, Y);
  parameter             Length = 8;
  parameter             initial_state  = 8'b1001_0001;
  parameter [Length-1:1] Tap_Coefficient = 7'b100_1111;
  input                 Clock, Reset;
  output [Length-1:0]   Y;
  reg    [Length-1:0]   Y;

  always @ (posedge Clock)
    begin
      if (!Reset) Y = initial_state;       // synchronous, active-low reset
      else        Y = LFSR_Value (Y);      // function call
    end

  function [Length-1:0] LFSR_Value;
    input   [Length-1:0] LFSR_state;
    integer Cell_ptr;
    begin
      for (Cell_ptr = Length-2; Cell_ptr >= 0; Cell_ptr = Cell_ptr - 1)
        if (Tap_Coefficient [Cell_ptr + 1] == 1)      // same as c in the figure
          LFSR_Value [Cell_ptr] = LFSR_state [Cell_ptr + 1] ^ LFSR_state [0];
        else
          LFSR_Value [Cell_ptr] = LFSR_state [Cell_ptr + 1];
      LFSR_Value [Length-1] = LFSR_state [0];
    end
  endfunction
endmodule

The function is a pure next-state computation: give it the current state, it returns the next one. Several teaching points are packed into eleven lines.這個函式是一個純粹的次態運算：給它目前的狀態，它回傳下一個。十一行裡塞進了好幾個教學重點。この関数は純粋な次状態計算である：現在の状態を与えれば次の状態を返す。十一行の中に教育上の要点がいくつも詰め込まれている。

• The function reads a module-level parameter. Tap_Coefficient is not an argument; a function may freely reference items declared in the enclosing module. That is convenient, and it is also the reason a function is not a closed, reusable object the way a module is.函式讀取了一個模組層級的參數。Tap_Coefficient 不是引數；函式可以自由引用外圍模組裡宣告的項目。這很方便，但這也正是為什麼函式不像模組那樣是一個封閉、可重用的物件。関数がモジュールレベルのパラメータを読んでいる。Tap_Coefficient は引数ではない。関数は外側のモジュールで宣言された項目を自由に参照できる。便利であるが、関数がモジュールのような閉じた再利用可能オブジェクトではない理由でもある。
• The implicit return variable is written bit by bit. The loop writes LFSR_Value[Cell_ptr] for Cell_ptr from Length-2 down to 0, then the line after the loop supplies the top bit. Every bit is covered, so the function never returns x.隱含的回傳變數是一個位元一個位元寫進去的。迴圈對 Cell_ptr 從 Length-2 數到 0，寫 LFSR_Value[Cell_ptr]，然後迴圈之後那一行補上最高位元。每一個位元都被涵蓋了，所以這個函式永遠不會回傳 x。暗黙の戻り値変数にはビットごとに書き込んでいる。ループは Cell_ptr を Length-2 から 0 まで下げながら LFSR_Value[Cell_ptr] に書き、ループの後の行が最上位ビットを補う。すべてのビットが埋まるので、この関数が x を返すことはない。
• The index arithmetic hides an off-by-one. Tap_Coefficient is declared [Length-1:1], i.e. there is no bit 0, which matches the figure's claim that $c_N$ is fixed at 1 and only $c_1 \ldots c_{N-1}$ are programmable. Bit Cell_ptr of the result is controlled by tap Cell_ptr + 1.索引的算術藏了一個差一錯誤的陷阱。Tap_Coefficient 宣告為 [Length-1:1]，也就是沒有位元 0，這與圖上「$c_N$ 固定為 1，只有 $c_1 \ldots c_{N-1}$ 可程式化」的說法一致。結果的第 Cell_ptr 位元是由抽頭 Cell_ptr + 1 控制的。添字の算術に off-by-one が潜んでいる。Tap_Coefficient は [Length-1:1] と宣言されており、ビット 0 がない。これは図の「$c_N$ は 1 に固定で、プログラム可能なのは $c_1 \ldots c_{N-1}$ だけ」という主張と一致する。結果のビット Cell_ptr を制御するのはタップ Cell_ptr + 1 である。
• The reset is synchronous — Reset is not in the sensitivity list — and active low.重置是同步的 —— Reset 不在敏感度列表裡 —— 而且是低電位有效。リセットは同期式であり——Reset は感度リストにない——Low アクティブである。
• Blocking assignment is used in a clocked block. Y = LFSR_Value(Y) happens to be safe because the function is pure and completes in zero time before the write, so there is no stage-skipping of the kind in §2.5. It is still the wrong habit: Y <= LFSR_Value(Y); says the same thing and removes any possibility of a race with another process reading Y on the same edge.時脈同步區塊裡用了阻斷式指派。Y = LFSR_Value(Y) 剛好是安全的，因為這個函式是純的，而且在寫入之前就在零時間內跑完，所以不會發生 §2.5 那種跳級。但它仍然是壞習慣：Y <= LFSR_Value(Y); 說的是同一件事，而且消除了與另一個在同一邊緣讀 Y 的行程發生競爭的任何可能。クロック同期ブロックでブロッキング代入を使っている。Y = LFSR_Value(Y) はたまたま安全である。関数が純粋で、書き込みより前にゼロ時間で完了するので、§2.5 のような段飛ばしは起きない。それでも習慣としては誤りである：Y <= LFSR_Value(Y); は同じことを述べ、同じエッジで Y を読む別プロセスとの競合の可能性を取り除く。

9.7 automatic versus static storage9.7 automatic 與靜態儲存9.7 automatic と静的記憶

The slides do not mention this, but it is the single most common way a task or function goes wrong in a real test bench, so it belongs in any honest treatment.投影片沒有提到這件事，但它是真實測試平台裡任務或函式出錯最常見的單一原因，所以任何誠實的講法都該把它寫進來。スライドはこれに触れていないが、実際のテストベンチでタスクや関数がおかしくなる最も多い単一の原因なので、誠実な解説なら必ず含めるべきである。

By default, a Verilog task or function is static. Its arguments and local variables are allocated once, at elaboration time, and every call uses the same storage. For a function called from one continuous assignment that is irrelevant. For a task called from two concurrent threads it is fatal: thread A writes tmp, suspends at a delay, thread B overwrites tmp, thread A resumes and reads thread B's value. The failure is intermittent and depends on timing, which makes it exactly the kind of bug that survives a whole lab session.預設情況下，Verilog 的任務或函式是靜態的。它的引數與區域變數在展開階段就配置一次，而每一次呼叫都用同一塊儲存。對一個只從單一連續指派呼叫的函式而言，這無關緊要。對一個從兩條並行執行緒呼叫的任務而言，這是致命的：執行緒 A 寫 tmp，在某個延遲處暫停，執行緒 B 覆蓋 tmp，執行緒 A 恢復後讀到的是執行緒 B 的值。這種失效是間歇性的，而且相依於時序，所以它正是那種能撐過一整堂實驗課的臭蟲。既定では Verilog のタスクや関数はstatic である。引数とローカル変数はエラボレーション時に一度だけ確保され、どの呼び出しも同じ記憶域を使う。一つの連続代入からしか呼ばれない関数なら、これはどうでもよい。二つの並行スレッドから呼ばれるタスクでは致命的である：スレッド A が tmp に書き、遅延で中断し、スレッド B が tmp を上書きし、スレッド A は再開してスレッド B の値を読む。この故障は間欠的でタイミングに依存するため、実験の一コマを丸ごと生き延びる類のバグになる。

IEEE 1364-2001 added the automatic keyword, which allocates the arguments and locals afresh on each call, as a stack frame:IEEE 1364-2001 加入了 automatic 關鍵字，它會在每次呼叫時重新配置引數與區域變數，就像一個堆疊框：IEEE 1364-2001 は automatic キーワードを追加した。これは呼び出しごとに引数とローカル変数を、スタックフレームのように新たに確保する。

task send_byte;
  input [7:0] d;
  integer i;
  begin
    for (i = 0; i < 8; i = i + 1)
      begin
        sdo = d[i];
        @(posedge sclk);
      end
  end
endtask

task automatic send_byte;
  input [7:0] d;
  integer i;
  begin
    for (i = 0; i < 8; i = i + 1)
      begin
        sdo = d[i];
        @(posedge sclk);
      end
  end
endtask

The left task takes eight clock cycles. Call it from two threads inside a fork and both share i and d: the loop counter advances twice per cycle, the data byte is whatever the later caller supplied, and the transaction is garbage. The right task gives each call its own i and d and behaves correctly.左邊那個任務要跑八個時脈週期。從一個 fork 裡的兩條執行緒呼叫它，兩者就共用 i 與 d：迴圈計數器每週期前進兩次，資料位元組是後呼叫者給的那個，整筆交易是垃圾。右邊那個任務讓每次呼叫各有自己的 i 與 d，行為正確。左のタスクは八クロックかかる。fork の中の二つのスレッドから呼べば両者が i と d を共有する：ループカウンタは 1 サイクルに二回進み、データバイトは後から呼んだ側のものになり、トランザクションはでたらめになる。右のタスクは呼び出しごとに自分の i と d を持ち、正しく振る舞う。

The rule of thumb is short: make every task and function in a test bench automatic unless you have a specific reason not to. The only common reasons not to are that you want a local variable to persist between calls (a call counter, say) or that you want to probe a local hierarchically from a monitor.經驗法則很短：測試平台裡的每一個任務與函式都寫成 automatic，除非你有特定理由不這麼做。常見的不這麼做的理由只有兩個：你想讓某個區域變數在兩次呼叫之間保留下來（例如一個呼叫次數計數器），或你想從某個監看器以階層式名稱去探測那個區域變數。経験則は短い：テストベンチのタスクと関数はすべて automatic にせよ。そうしない特別な理由がない限り。そうしない一般的な理由は二つだけである：ローカル変数を呼び出しの間で保持させたい（たとえば呼び出し回数のカウンタ）、あるいはモニタからそのローカル変数を階層名で覗きたい、である。

9.8 Choosing between a task, a function and a module9.8 任務、函式與模組之間如何取捨9.8 タスク・関数・モジュールの選び分け

The third row is worth emphasising because tasks and functions are flattened — they do not create hierarchy, they do not create separately named instances, and a function used twice becomes two independent copies of the logic, not one shared block. If you want sharing, instantiate a module and multiplex its inputs.第三列值得強調，因為任務與函式是會被攤平的 —— 它們不產生階層，不產生各自具名的實例，而一個被用兩次的函式會變成兩份獨立的邏輯，不是一個共用的區塊。如果你想要共用，就實例化一個模組並對它的輸入做多工。三行目は強調しておく価値がある。タスクと関数は平坦化されるからである——階層を作らず、個別に名前の付いたインスタンスも作らず、二度使われた関数は共有される一つのブロックではなく独立した二つの論理になる。共有したいならモジュールをインスタンス化し、その入力をマルチプレクサで切り替えること。

(a) function [3:0] f; input [3:0] x; begin #5 f = x; end endfunction
(b) task t; output [3:0] y; begin y = 4'h3; end endtask
(c) function f2; begin f2 = 1'b1; end endfunction
(d) assign w = my_task(a);
(e) always @* my_task(a, w);
(f) function [7:0] g; input [7:0] x; begin g = h(x) + 1; end endfunction
    function [7:0] h; input [7:0] x; begin h = x << 1; end endfunction
(g) function automatic integer fact; input integer n;
      begin if (n <= 1) fact = 1; else fact = n * fact(n-1); end
    endfunction

10. Timing Analysis and Timing Checks10. 時序分析與時序檢查10. タイミング解析とタイミングチェック

10.1 Static versus dynamic timing analysis10.1 靜態時序分析與動態時序分析10.1 静的タイミング解析と動的タイミング解析

Having a functionally correct netlist is half the job; the other half is proving that every signal arrives in time. There are two ways to do it, and the lecture contrasts them because they fail in opposite directions.有一份功能正確的 netlist 只完成了一半工作；另一半是證明每一個訊號都及時抵達。做這件事有兩種方法，而講義把它們對比起來，因為它們是往相反方向失效的。機能的に正しいネットリストがあるのは仕事の半分であり、残りの半分はすべての信号が間に合って到着することの証明である。その方法は二つあり、講義が両者を対比させているのは、失敗の向きが互いに逆だからである。

Dynamic timing analysis means running a gate-level simulation with real cell delays back-annotated from an SDF file, and watching for violations. Its strength is that it only reports paths the stimulus actually exercises, so it never complains about a path the design can never take. Its weakness is the same sentence read the other way: if your stimulus fails to exercise a functional path, a violation on that path is simply never seen. You cannot write enough vectors to cover every path in a modern block, so dynamic analysis alone can never sign off timing.動態時序分析指的是用從 SDF 檔案反標註進來的真實單元延遲跑一次閘級模擬，並盯著有沒有違規。它的強項是只會回報激勵真正走過的路徑，所以它絕不會抱怨一條設計根本走不到的路徑。它的弱點就是同一句話反過來讀：如果你的激勵沒有走過某條功能路徑，那條路徑上的違規就根本不會被看見。你不可能為現代區塊裡的每一條路徑寫出足夠的向量，所以光靠動態分析永遠不可能簽掉時序。動的タイミング解析とは、SDF ファイルからバックアノテートした実際のセル遅延でゲートレベルシミュレーションを走らせ、違反を見張ることである。強みは、刺激が実際に通った経路しか報告しないため、設計が決して取りえない経路について文句を言わない点である。弱点は同じ文を裏返したものである：刺激がある機能経路を通らなければ、その経路上の違反は決して見えない。現代のブロックのすべての経路を覆うベクタを書くことは不可能なので、動的解析だけでタイミングをサインオフすることはできない。

Static timing analysis (STA) does not simulate at all. It walks the netlist as a graph, propagates arrival times forward from every start point and required times backward from every end point, and reports the worst slack. Because it ignores logic function entirely, it is exhaustive: every path is examined and nothing can be missed. Its weakness is the mirror image: it also examines paths that can never be sensitised — false paths — and reports violations on them.靜態時序分析（STA）根本不做模擬。它把 netlist 當成一張圖來走，從每一個起點把到達時間往前傳，從每一個終點把需求時間往後傳，然後回報最差的餘裕。因為它完全不管邏輯功能，所以它是窮盡的：每一條路徑都會被檢查，什麼都漏不掉。它的弱點正是這面鏡子的另一側：它同樣會檢查那些永遠無法被激發的路徑 —— 偽路徑 —— 並回報它們上面的違規。静的タイミング解析（STA）はシミュレーションを一切行わない。ネットリストをグラフとしてたどり、各始点から到着時間を前向きに、各終点から要求時間を後ろ向きに伝播させ、最悪のスラックを報告する。論理機能を完全に無視するので網羅的である：すべての経路が調べられ、見落としは起こらない。弱点はその鏡像である：決して活性化されえない経路——フォルスパス——も調べてしまい、そこでの違反を報告する。

The slide's false-path example is the standard one. Two multiplexers, Mux1 and Mux2, are driven by the same select signal Sel. A path that enters Mux1 on In0 and leaves Mux2 on In1 requires Sel to hold two different values at once, so no input vector can ever activate it. STA counts it anyway, and if it happens to be the longest path in the block you will spend a week optimising something that does not exist. The remedy is to tell the tool: set_false_path constraints are how a designer injects the functional knowledge that STA structurally lacks.投影片的偽路徑例子是標準的那一個。兩個多工器 Mux1 與 Mux2 由同一個選擇訊號 Sel 驅動。一條從 In0 進入 Mux1、從 In1 離開 Mux2 的路徑，要求 Sel 同時持有兩個不同的值，所以沒有任何輸入向量能激發它。STA 照樣把它算進去，而萬一它剛好是這個區塊裡最長的路徑，你就會花一週去最佳化一個不存在的東西。對策是去告訴工具：set_false_path 約束就是設計者把 STA 在結構上欠缺的功能知識注入進去的方式。スライドのフォルスパスの例は定番のものである。二つのマルチプレクサ Mux1 と Mux2 が同一の選択信号 Sel で駆動されている。In0 から Mux1 に入り In1 から Mux2 を出る経路は、Sel が同時に二つの異なる値を持つことを要求するので、どんな入力ベクタでも活性化できない。STA はそれでも数え上げるので、それがたまたまブロック中で最長の経路だったなら、存在しないものの最適化に一週間を費やすことになる。対策はツールに教えることである：set_false_path 制約こそ、STA が構造的に欠いている機能的知識を設計者が注入する手段である。

In an industrial flow you use both: STA for sign-off on timing, gate-level simulation for sign-off on function and on things STA cannot model — asynchronous interfaces, reset release, and the X-propagation behaviour of uninitialised state.在業界流程裡兩者都用：時序簽核用 STA，功能簽核以及 STA 無法建模的東西 —— 非同步介面、重置釋放，以及未初始化狀態的 X 傳播行為 —— 則用閘級模擬。産業用のフローでは両方を使う：タイミングのサインオフには STA を、機能のサインオフと STA がモデル化できないもの——非同期インタフェース、リセット解除、未初期化状態の X 伝播の振る舞い——にはゲートレベルシミュレーションを使う。

10.2 Arrival time, required time, slack10.2 到達時間、需求時間、餘裕10.2 到着時間・要求時間・スラック

STA annotates every node of the netlist graph with three numbers, written on the slide in the order arrival / required / slack:STA 替 netlist 圖的每一個節點標上三個數字，投影片上按照到達／需求／餘裕的順序寫出來：STA はネットリストグラフの各ノードに三つの数値を註記する。スライドでは到着／要求／スラックの順に書かれている。

• Arrival time is computed forward from the start points. At a node fed by several paths, the arrival time is the maximum over the incoming paths, because the node is not stable until the slowest contribution has landed.到達時間是從起點往前算出來的。在一個由好幾條路徑餵進來的節點上，到達時間取各條來路的最大值，因為要等最慢的那份貢獻落地，這個節點才穩定。到着時間は始点から前向きに計算される。複数の経路が流れ込むノードでは、到着時間は入ってくる経路の最大値を取る。最も遅い寄与が届くまでノードは安定しないからである。
• Required arrival time is computed backward from the end points, where it is set by the clock period minus the setup time of the capturing flop. At a node feeding several paths, the required time is the minimum over the outgoing paths, because it must satisfy the tightest consumer.需求到達時間是從終點往後算出來的，而終點上的值由時脈週期減去捕捉正反器的建立時間決定。在一個往外餵好幾條路徑的節點上，需求時間取各條去路的最小值，因為它必須滿足最緊的那個消費者。要求到着時間は終点から後ろ向きに計算され、終点では、クロック周期から取り込み側フリップフロップのセットアップ時間を引いた値で定まる。複数の経路へ出ていくノードでは、要求時間は出ていく経路の最小値を取る。最も厳しい消費者を満たさねばならないからである。
• Slack is the margin. Zero or positive means the path meets its budget; negative means it violates, and the magnitude is how much faster the logic must become.餘裕就是那個邊際。零或正值代表這條路徑符合它的預算；負值代表違規，而其絕對值就是邏輯必須再快上多少。スラックは余裕である。零または正ならその経路は予算を満たしており、負なら違反であり、その大きさは論理がどれだけ速くならねばならないかを表す。

The critical path is the path along which the slack is most negative (or, if everything passes, least positive). Note that slack is a property of a node, not only of a path: the same negative number propagates along the whole critical path, which is exactly how you read a timing report to find where to optimise.關鍵路徑是餘裕最負的那條路徑（若全部都過關，就是餘裕最不正的那條）。要注意餘裕是節點的性質，不只是路徑的性質：同一個負數會沿著整條關鍵路徑傳播，而這正是你讀一份時序報告、找出該往哪裡最佳化的方法。クリティカルパスはスラックが最も負である経路（すべて合格していれば最も正でない経路）である。スラックが経路だけでなくノードの属性でもある点に注意したい：同じ負の数がクリティカルパス全体に沿って伝播し、まさにそれがタイミングレポートを読んでどこを最適化すべきかを探す方法である。

10.3 A worked static timing analysis10.3 一個靜態時序分析實例10.3 静的タイミング解析の実例

The slide's example is a four-gate cone. Work it yourself before reading the arithmetic.投影片的例子是一個四個閘的邏輯錐。在看下面的算式之前，先自己算一遍。スライドの例は四つのゲートからなるコーンである。以下の計算を読む前に、まず自分で解いてみてほしい。

10.4 System tasks for timing checks10.4 時序檢查用的系統任務10.4 タイミングチェック用のシステムタスク

Dynamic timing analysis needs somewhere to express the constraint being checked. Verilog provides a family of system tasks that may be invoked from a behavior in a test bench, or — the usual place — inside a specify ... endspecify block in a cell model.動態時序分析需要一個地方來表達它要檢查的那個約束。Verilog 提供了一族系統任務，可以從測試平台裡的一個行為描述呼叫，或者 —— 更常見的位置 —— 放在單元模型的 specify ... endspecify 區塊裡。動的タイミング解析には、検査する制約を書く場所が必要である。Verilog はそのためのシステムタスク群を用意しており、テストベンチの振る舞い記述から呼び出すことも、より一般的にはセルモデルの specify ... endspecify ブロックの中に置くこともできる。