Simulation & Testbench — Explained模擬與測試平台 — 詳解シミュレーションとテストベンチ — 詳解

1. The Testbench and the Verification Problem1. 測試平台與驗證問題1. テストベンチと検証という問題

1.1 What verification actually buys you1.1 驗證究竟為你買到了什麼1.1 検証は実際に何をもたらすか

In Lecture 1 you learned to write a module that describes hardware. Nothing in that module tells you whether the hardware is correct. A Verilog compiler will happily accept a four-bit adder that computes a - b, an FSM that never leaves its reset state, or a FIFO whose full flag asserts one cycle late. Those are not syntax errors; they are design errors, and the only tool that finds them before silicon is simulation driven by a testbench.在第 1 講中，你學會了寫一個描述硬體的模組。但那個模組本身完全不會告訴你硬體是否正確。Verilog 編譯器會毫不猶豫地接受一個其實在算 a - b 的四位元加法器、一個永遠離不開重置狀態的有限狀態機，或是一個 full 旗標晚一個週期才拉起的 FIFO。那些都不是語法錯誤，而是設計錯誤；在進矽之前唯一能找出它們的工具，就是由測試平台（testbench）所驅動的模擬。第 1 講では、ハードウェアを記述するモジュールの書き方を学んだ。しかしそのモジュール自体は、そのハードウェアが正しいかどうかを一切教えてくれない。Verilog コンパイラは、実際には a - b を計算する 4 ビット加算器も、リセット状態から永遠に出ない FSM も、full フラグが 1 サイクル遅れて立つ FIFO も、平然と受け入れる。これらは構文エラーではなく設計エラーであり、シリコンになる前にそれを見つけられる唯一の道具が、テストベンチによって駆動されるシミュレーションである。

It is worth being blunt about the economics, because this is the reason the course spends a whole lecture on something that produces no gates. A modern cell-based ASIC tape-out costs a mask set in the high six figures and three to four months of turnaround. A bug found in simulation costs an afternoon. A bug found at wafer probe costs a respin. The industry rule of thumb is that verification consumes between half and two thirds of the total engineering effort on a chip, and that ratio has been getting worse, not better, for thirty years. When a lecture slide says “a testbench verifies the functionality of a design”, the subtext is that the testbench is where most of your working life as an IC designer will actually be spent.在此不妨把經濟面講白，因為這正是本課程願意花整整一講去談一個「產生不出任何閘」的主題的理由。現代 cell-based ASIC 的一次 tape-out，光光罩組就要數十萬美元等級，外加三到四個月的週轉時間。在模擬中找到的臭蟲，代價是一個下午。在晶圓針測時才找到的臭蟲，代價是一次重跑（respin）。業界的經驗法則是：驗證耗掉一顆晶片總工程投入的一半到三分之二，而且這個比例三十年來只有變糟、沒有變好。當投影片上寫著「測試平台用來驗證設計的功能」時，它的潛台詞是：身為 IC 設計者，你職業生涯的大部分時間其實都會花在測試平台上。ここでは経済性についてはっきり言っておく価値がある。ゲートを一つも生まないテーマに本講義が丸ごと一回分を割く理由がそこにあるからだ。現代のセルベース ASIC のテープアウトは、マスクセットだけで数十万ドル規模、さらに 3〜4 か月のターンアラウンドを要する。シミュレーションで見つかったバグの代償は午後一回分。ウェハプローブで見つかったバグの代償は再試作（respin）である。業界の経験則では、検証はチップ全体のエンジニアリング工数の半分から三分の二を消費し、その比率はこの 30 年間、改善どころか悪化し続けてきた。講義スライドが「テストベンチは設計の機能を検証する」と書くとき、その裏の意味は、IC 設計者としての職業人生の大半は実際にはテストベンチの上で費やされる、ということだ。

A second, quieter benefit: a testbench is an executable specification. If you can write a checker that says “after n cycles of this input stream the output must equal this value”, you have written down, unambiguously and in a form a machine can police, what the block is supposed to do. Natural-language specifications rot; testbenches fail loudly when the design drifts away from them.還有第二個比較低調的好處：測試平台是一份可執行的規格書。如果你能寫出一個檢查器，說「在這串輸入流經過 n 個週期之後，輸出必須等於這個值」，那你就已經把這個區塊該做什麼，用毫不含糊、而且機器能夠稽核的形式寫下來了。自然語言寫的規格會腐壞；測試平台則會在設計偏離它時大聲失敗。もう一つ、地味だが重要な利点がある。テストベンチは実行可能な仕様書だという点だ。「この入力列を n サイクル与えた後、出力はこの値に等しくなければならない」と述べるチェッカを書けたなら、そのブロックが何をすべきかを、曖昧さなく、しかも機械が取り締まれる形で書き下したことになる。自然言語の仕様は腐る。テストベンチは、設計がそこから離れたときに声を上げて失敗する。

1.2 Anatomy of a testbench1.2 測試平台的解剖1.2 テストベンチの構造

The canonical picture is a box that wraps the design. The design under test — universally abbreviated DUT, occasionally UUT for “unit under test” — sits inside a top-level module that has no ports at all. That portlessness is the structural signature of a testbench: there is nothing above it to connect to, because it is the root of the simulation hierarchy. Everything the DUT needs comes from inside the wrapper.標準的圖像是一個把設計包起來的盒子。受測設計 —— 業界一律縮寫成 DUT（design under test），偶爾寫成 UUT（unit under test）—— 坐在一個完全沒有任何埠的頂層模組裡面。沒有埠正是測試平台的結構性特徵：它上面沒有東西可以接，因為它就是模擬階層的根。DUT 需要的一切，都來自這層包裝的內部。典型的な図は、設計を包み込む一つの箱である。被試験設計 —— 業界では一律に DUT（design under test）と略し、ときに UUT（unit under test）とも書く —— は、ポートをまったく持たないトップレベルモジュールの中に置かれる。ポートがないことこそテストベンチの構造上の目印である。上位に接続すべきものが何も無いからであり、それ自体がシミュレーション階層のルートだからだ。DUT が必要とするものはすべて、このラッパーの内側から供給される。

Four jobs are visible in the figure, and it is worth naming them separately because real testbenches separate them in code too:圖中可以看到四項工作，值得分別命名，因為真實的測試平台在程式碼上也會把它們分開：図には四つの仕事が見える。実際のテストベンチはコード上でもこれらを分離するので、別々に名前を付けておく価値がある。

• Stimulus generation. Something must wiggle the DUT’s inputs. In the simplest testbench this is a single initial block with a list of delayed assignments. In a serious one it is a constrained random generator, a file reader, or a transaction-level driver.激勵產生。必須有東西去撥動 DUT 的輸入。在最簡單的測試平台裡，這就是一個 initial 區塊，裡面列著一串帶延遲的指定。在認真一點的測試平台裡，它會是一個受限隨機產生器、一個檔案讀取器，或一個交易層級的 driver。刺激の生成。DUT の入力を動かすものが必要である。最も単純なテストベンチでは、遅延付き代入を並べた initial ブロック一つがそれにあたる。本格的なものでは、制約付きランダム生成器、ファイルリーダ、あるいはトランザクションレベルのドライバになる。
• The golden reference. Something must know what the right answer is. For a combinational block you may be able to compute it inline; for a communications block — an FIR filter, a Viterbi decoder, a turbo decoder — the reference is nearly always a bit-accurate C or MATLAB model whose output has been dumped to a text file and is read back by the testbench with $readmemh or $fscanf.黃金參考。必須有東西知道正確答案是什麼。對組合邏輯區塊，你也許可以就地算出來；對通訊類區塊 —— FIR 濾波器、Viterbi 解碼器、turbo 解碼器 —— 參考答案幾乎一定是一個位元精確的 C 或 MATLAB 模型，其輸出被傾印成文字檔，再由測試平台用 $readmemh 或 $fscanf 讀回來。ゴールデンリファレンス。正解を知っているものが必要である。組合せ回路なら直接その場で計算できることもあるが、通信系のブロック —— FIR フィルタ、ビタビ復号器、ターボ復号器 —— では、リファレンスはほぼ必ずビット精度の C または MATLAB モデルであり、その出力をテキストファイルにダンプして、テストベンチが $readmemh や $fscanf で読み戻す。
• Checking. Something must compare observed against expected and shout when they differ. The comparison is where the time alignment lives: the DUT has latency, so the checker must delay the golden stream by the same number of cycles, or hold results in a queue.檢查。必須有東西把觀測值與期待值比對，並在兩者不同時大聲抗議。時間對齊就住在這個比較裡：DUT 有延遲（latency），所以檢查器必須把黃金資料流延後同樣的週期數，或是把結果先存進佇列。チェック。観測値と期待値を比較し、食い違ったら声を上げるものが必要である。時間合わせはこの比較の中にある。DUT にはレイテンシがあるので、チェッカはゴールデン側のストリームを同じサイクル数だけ遅らせるか、結果をキューに保持しなければならない。
• Observation. Something must record what happened so a human can debug the failure: $monitor text output, and a value-change dump for the waveform viewer.觀察。必須有東西記錄下發生了什麼，好讓人類能除錯失敗的案例：$monitor 的文字輸出，以及給波形檢視器用的值變化傾印（value-change dump）。観測。何が起きたかを記録し、人間が失敗をデバッグできるようにするものが必要である。$monitor によるテキスト出力と、波形ビューア用の値変化ダンプ（value-change dump）である。

1.3 Why a testbench cannot be synthesised1.3 為什麼測試平台不能被合成1.3 なぜテストベンチは合成できないのか

The slide states flatly: Can’t be synthesized!! (Only for behavioral modeling). That is correct, but it is worth understanding why, because the same reasoning tells you which constructs are forbidden inside the DUT as well — a distinction Lecture 7 will make formal.投影片講得很乾脆：Can’t be synthesized!! (Only for behavioral modeling)。這沒錯，但值得弄懂為什麼，因為同一套推理也告訴你哪些語法結構在 DUT 內同樣是禁忌 —— 這個分野會由 Lecture 7 正式確立。スライドはそっけなくこう述べている。Can’t be synthesized!! (Only for behavioral modeling)。それは正しいが、なぜかを理解しておく価値がある。同じ理屈が、DUT の中で禁じられる構文がどれかも教えてくれるからだ。この線引きは Lecture 7 で正式に扱われる。

A synthesis tool reads Verilog and emits a netlist of standard cells. To do that it must be able to answer one question about every statement: what combinational function, and what storage, does this imply? A testbench is deliberately full of statements for which that question has no answer. Consider:合成工具讀進 Verilog，吐出一份標準元件的網表（netlist）。要做到這件事，它必須能對每一條敘述回答同一個問題：這暗示了什麼組合函數、又暗示了什麼儲存元件？而測試平台刻意寫滿了對這個問題無解的敘述。看看以下這些：合成ツールは Verilog を読み、標準セルのネットリストを出力する。そのためには、すべての文について一つの問いに答えられなければならない。これはどんな組合せ関数と、どんな記憶素子を意味するのか？ テストベンチは、その問いに答えが存在しない文で意図的に埋め尽くされている。たとえば次のようなものだ。

The practical consequence is a discipline, not a prohibition: you are encouraged to use all of this in the testbench and forbidden to use any of it in the DUT. Keep the two in separate files, give testbench files a recognisable prefix such as tb_ or test_, and never add a testbench file to the synthesis script. Many groups enforce this by putting the DUT sources in one directory and the verification environment in another.實務上的後果是一條紀律，而不是一道禁令：在測試平台裡，你被鼓勵使用上述全部；在 DUT 裡，你被禁止使用其中任何一項。把兩者分開放在不同檔案，給測試平台檔案一個一眼認得出的前綴，例如 tb_ 或 test_，而且永遠不要把測試平台檔案加進合成腳本。許多團隊的做法是把 DUT 原始碼放一個目錄、驗證環境放另一個目錄，以制度強制這條界線。実務上の帰結は禁止令ではなく規律である。テストベンチの中ではこれらをすべて使うことが推奨され、DUT の中ではそのいずれも使うことが禁止される。両者は別ファイルに分け、テストベンチのファイルには tb_ や test_ のような一目でわかる接頭辞を付け、合成スクリプトにテストベンチのファイルを決して加えない。多くのグループは、DUT のソースを一つのディレクトリに、検証環境を別のディレクトリに置くことでこれを強制している。

Throughout this guide a not synthesisable badge marks any construct that belongs on the testbench side of that wall.本指南全篇會用一個 not synthesisable 標記，標出任何屬於這道牆的測試平台那一側的語法結構。本ガイドでは全体を通して、この壁のテストベンチ側に属する構文に not synthesisable のバッジを付けて示す。

1.4 Stimulus, observation and checking in practice1.4 實務上的激勵、觀察與檢查1.4 実務における刺激・観測・チェック

The slides show the simplest possible testbench: one initial block that lists stimulus with # delays, one that calls $monitor, one that calls $finish. That is a directed testbench with visual checking — a human reads the printout or the waveform and decides whether it is right. It is the correct starting point and completely inadequate as an end point, for two reasons.投影片展示了最簡單的測試平台：一個 initial 區塊用 # 延遲列出激勵，一個呼叫 $monitor，一個呼叫 $finish。那是一個採視覺檢查的指向式（directed）測試平台 —— 由人去讀印出結果或波形，再判斷對不對。它是正確的起點，但作為終點則完全不夠，理由有兩個。スライドが示すのは考えうる最も単純なテストベンチである。# 遅延で刺激を並べた initial ブロックが一つ、$monitor を呼ぶものが一つ、$finish を呼ぶものが一つ。これは目視チェックによる指向型（directed）テストベンチであり、人間が出力や波形を読んで正しいかを判断する。出発点としては正しいが、終着点としてはまったく不十分である。理由は二つある。

First, visual checking does not scale. A four-bit adder has $2^9 = 512$ input combinations including carry-in; you can eyeball those. A sixteen-bit multiplier has $2^{32}$, about four billion. Nobody reads four billion lines of $monitor output. The moment the input space is larger than a screenful you need a self-checking testbench, one that computes or looks up the expected value and prints only on mismatch. The end of the run then prints a single line: 0 errors in 4294967296 vectors — or it prints the first failing vector and stops.第一，目視檢查無法擴展。四位元加法器含進位輸入共有 $2^9 = 512$ 種輸入組合，這你還看得完。十六位元乘法器有 $2^{32}$ 種，約四十億。沒有人會去讀四十億行 $monitor 輸出。只要輸入空間大過一個螢幕，你就需要自我檢查（self-checking）的測試平台：自己算出或查出期待值，只在不符時才印東西。這樣跑完時只印一行：0 errors in 4294967296 vectors —— 或者印出第一個失敗的向量然後停下來。第一に、目視チェックはスケールしない。4 ビット加算器はキャリー入力を含めて $2^9 = 512$ 通りの入力組合せしかなく、これなら目で追える。16 ビット乗算器は $2^{32}$ 通り、約 40 億である。40 億行の $monitor 出力を読む者はいない。入力空間が画面一枚を超えた瞬間、自己チェック型（self-checking）のテストベンチ、すなわち期待値を計算するか参照して、不一致のときだけ表示するものが必要になる。そうすれば実行の最後に 0 errors in 4294967296 vectors の一行だけが出るか、最初に失敗したベクタを表示して止まるかのどちらかになる。

Second, directed stimulus only finds bugs you already thought of. The vectors you write are the cases you had in mind when you wrote the design, which are exactly the cases the design handles. Bugs live in the cases you did not think of: the FIFO that is read and written in the same cycle while full, the state machine that receives an abort during the last byte of a packet. This is why industrial flows add constrained-random stimulus and functional coverage. Those are SystemVerilog topics and outside this course, but you should know the shape of the ladder you are standing on the first rung of.第二，指向式激勵只能找到你已經想到的臭蟲。你寫下的向量，正是你寫設計時心裡想著的狀況，而那也正是設計處理得了的狀況。臭蟲住在你沒想到的狀況裡：那個在滿的時候同一週期同時被讀與被寫的 FIFO、那個在封包最後一個位元組時收到 abort 的狀態機。這正是業界流程要加上受限隨機激勵與功能覆蓋率的原因。那些屬於 SystemVerilog 的題目，不在本課程範圍內，但你應該知道自己正站在哪一座梯子的第一階上。第二に、指向型の刺激は自分がすでに思いついたバグしか見つけられない。書いたベクタは設計時に念頭にあったケースであり、それはまさに設計が扱えるケースである。バグは思いつかなかったケースに潜む。満杯の状態で同一サイクルに読みと書きが来る FIFO、パケットの最終バイト中に abort を受け取るステートマシンなどだ。産業的なフローが制約付きランダム刺激と機能カバレッジを加えるのはこのためである。それらは SystemVerilog の話題で本講義の範囲外だが、自分がどんな梯子の一段目に立っているのかは知っておくべきである。

1.5 Design mindset versus testbench mindset1.5 設計心態 vs 測試平台心態1.5 設計の思考法とテストベンチの思考法

Slide 12 of the deck draws a distinction that is easy to read past and important to internalise. The two halves of a simulation are written in the same language but describe fundamentally different kinds of object.投影片第 12 頁畫出一個很容易讀過去、卻很重要該內化的區別。模擬的兩半是用同一種語言寫的，描述的卻是根本不同種類的東西。スライド 12 枚目は、読み飛ばしやすいが身につけるべき重要な区別を示している。シミュレーションの二つの半分は同じ言語で書かれるが、記述している対象の種類は根本的に異なる。

A concrete symptom of mixing the two mindsets: students write a testbench that describes the stimulus as if it were hardware — a counter, a shift register, a state machine to sequence the inputs. It works, but it takes four times as long to write and is far harder to change. Conversely, students write a DUT as if it were a program — a long initial block, blocking assignments in sequence, delays to “wait for the result” — and are baffled when synthesis rejects it or, worse, accepts it and produces a circuit that bears no resemblance to the simulation.把兩種心態混在一起的具體症狀：學生寫出一個把激勵當成硬體來描述的測試平台 —— 用計數器、移位暫存器、狀態機去排出輸入順序。它會動，但寫起來要花四倍時間，而且改起來困難得多。反過來，學生把 DUT 當成程式來寫 —— 一個長長的 initial 區塊、一連串阻塞式指定、用延遲去「等結果出來」—— 然後在合成拒絕它時一頭霧水，或者更糟，合成接受了它，卻產生出一個跟模擬毫無相似之處的電路。二つの思考法を混ぜたときの具体的な症状はこうだ。学生は刺激をあたかもハードウェアのように記述したテストベンチを書く。入力を順序づけるためのカウンタ、シフトレジスタ、ステートマシン。動きはするが、書くのに 4 倍の時間がかかり、変更ははるかに難しい。逆に、学生は DUT をプログラムのように書く。長い initial ブロック、順に並んだブロッキング代入、「結果を待つ」ための遅延。そして合成がそれを拒否したとき、あるいはもっと悪いことに受理してシミュレーションとは似ても似つかない回路を出したとき、途方に暮れる。

2. The Event-Driven Simulation Algorithm2. 事件驅動模擬演算法2. イベント駆動シミュレーションのアルゴリズム

2.1 What an event really is2.1 事件到底是什麼2.1 イベントとは実際には何か

The slide definition is one line: a change in the value of a signal during simulation is referred to as an event. That is true but it hides a distinction the rest of this section depends on. Inside the simulator there are actually two kinds of thing on the queue, and conflating them is the single most common source of confusion about Verilog scheduling.投影片的定義只有一行：模擬過程中某個訊號值的改變，稱為一個事件。這沒錯，但它藏起了本節其餘部分所仰賴的一個區別。模擬器內部的佇列上其實有兩種東西，而把它們混為一談，正是 Verilog 排程相關混淆中最常見的單一來源。スライドの定義は一行である。シミュレーション中の信号値の変化をイベントと呼ぶ。それは正しいが、本節の残りが依存している区別を隠している。シミュレータ内部では、キューに載っているものは実は二種類あり、それらを混同することが Verilog のスケジューリングに関する混乱の最大の原因である。

• An update event changes the value stored in a net or a variable. “Set C to 0 at time 13.” This is the event the slide is describing.更新事件（update event）改變儲存在連線或變數中的值。「在時刻 13 把 C 設為 0。」這就是投影片在描述的那種事件。更新イベント（update event）は、ネットまたは変数に格納された値を変える。「時刻 13 で C を 0 にする」。スライドが述べているのはこちらのイベントである。
• An evaluation event runs a piece of the model: it evaluates a gate’s function, computes the right-hand side of a continuous assignment, or resumes a procedural block that was waiting on a sensitivity list.求值事件（evaluation event）執行模型的一部分：求出一個閘的函數值、計算一條連續指定的右手邊，或是喚醒一個正等在敏感度列表上的程序區塊。評価イベント（evaluation event）はモデルの一部を実行する。ゲートの関数を評価し、連続代入の右辺を計算し、あるいは感度リストで待っていた手続きブロックを再開させる。

The two alternate. An update event changes a value; the simulator then looks up every process that is sensitive to that value and schedules an evaluation event for each; those evaluations compute new values and schedule further update events. Simulation is this loop, running until the queue runs dry. Once you see it as update → evaluate → update → evaluate, the rest of Verilog’s timing semantics — non-blocking assignments, delta cycles, races — stops being arbitrary and becomes mechanical.兩者交替出現。更新事件改變一個值；模擬器接著查出所有對該值敏感的程序，為每一個排一個求值事件；那些求值算出新值，又排出更多更新事件。模擬就是這個迴圈，一直跑到佇列乾掉為止。一旦你把它看成更新 → 求值 → 更新 → 求值，Verilog 其餘的時序語意 —— 非阻塞指定、delta 週期、競爭 —— 就不再任意武斷，而變成機械性的了。両者は交互に現れる。更新イベントが値を変え、シミュレータはその値に感応するすべてのプロセスを調べて各々に評価イベントを予約する。それらの評価が新しい値を計算し、さらに更新イベントを予約する。シミュレーションとはこのループであり、キューが空になるまで回り続ける。いったん更新 → 評価 → 更新 → 評価として見えるようになれば、Verilog の残りのタイミング意味論 —— ノンブロッキング代入、デルタサイクル、レース —— は恣意的なものではなく機械的なものになる。

2.2 Why event-driven rather than time-stepped2.2 為何採事件驅動而非時間步進2.2 なぜ時間刻みでなくイベント駆動なのか

The obvious way to simulate a circuit is to pick a time step, advance the clock by that step, and re-evaluate every gate. This is how SPICE works, and it is how a naive digital simulator would work. Verilog does not do this, and the reason is arithmetic.模擬電路最直覺的作法是：挑一個時間步長，讓時鐘前進一步，然後重新求值每一個閘。SPICE 就是這樣運作的，一個天真的數位模擬器也會這樣做。Verilog 不這麼做，理由是算術。回路をシミュレートする素朴な方法は、時間刻みを決め、その刻みだけ時刻を進め、すべてのゲートを再評価することである。SPICE はこの方式であり、素朴なディジタルシミュレータもそうするだろう。Verilog はそうしない。理由は算術にある。

Take a modest block: $N = 10^6$ gates, simulated for $T = 10^{-3}$ seconds of circuit time with a resolution of 1 ps, so $10^9$ time steps. A time-stepped simulator performs $N \times 10^9 = 10^{15}$ gate evaluations. At a hopeful $10^8$ evaluations per second that is $10^7$ seconds, or four months, for one millisecond of circuit activity.取一個規模不大的區塊：$N = 10^6$ 個閘，模擬 $T = 10^{-3}$ 秒的電路時間，解析度 1 ps，也就是 $10^9$ 個時間步。時間步進式模擬器要執行 $N \times 10^9 = 10^{15}$ 次閘求值。以樂觀的每秒 $10^8$ 次求值計算，那是 $10^7$ 秒，也就是四個月，只為了一毫秒的電路活動。控えめな規模のブロックを考える。$N = 10^6$ 個のゲートを、分解能 1 ps で回路時間 $T = 10^{-3}$ 秒ぶんシミュレートすると、時間刻みは $10^9$ 回になる。時間刻み型シミュレータは $N \times 10^9 = 10^{15}$ 回のゲート評価を行う。楽観的に毎秒 $10^8$ 回評価できるとしても $10^7$ 秒、すなわち 4 か月かかる。たった 1 ミリ秒の回路動作のためにである。

Now count the evaluations an event-driven simulator performs. In a synchronous design clocked at $f = 500$ MHz, one millisecond is $5\times10^5$ cycles. The activity factor $\alpha$ — the fraction of nodes that toggle in a given cycle — is typically between 0.05 and 0.2 for real logic. Taking $\alpha = 0.1$, the number of update events is現在來數事件驅動模擬器要做幾次求值。在一個 $f = 500$ MHz 的同步設計中，一毫秒是 $5\times10^5$ 個週期。活動率（activity factor）$\alpha$ —— 在某個週期中會翻轉的節點比例 —— 對真實邏輯而言通常介於 0.05 與 0.2 之間。取 $\alpha = 0.1$，更新事件的數目為次に、イベント駆動シミュレータが行う評価回数を数える。$f = 500$ MHz で動く同期設計では、1 ミリ秒は $5\times10^5$ サイクルである。活性化率（activity factor）$\alpha$ —— あるサイクルでトグルするノードの割合 —— は実際の論理では通常 0.05 から 0.2 の間にある。$\alpha = 0.1$ を取れば、更新イベント数は

Each update event triggers a handful of downstream evaluations, so call it $2\times10^{11}$ evaluations — still four orders of magnitude less work than the time-stepped approach, and the gap widens as the time resolution gets finer, because event-driven cost does not depend on resolution at all. That is the whole argument, and it is why every digital simulator since the 1960s has been event-driven. It also tells you something practical: simulation speed is proportional to activity. A testbench that toggles a 32-bit bus every picosecond for no reason will be slow; clock gating that is modelled faithfully will make your simulations faster as well as your chip cooler.每個更新事件會觸發少數幾個下游求值，所以就算它 $2\times10^{11}$ 次求值 —— 仍然比時間步進法少了四個數量級的工作量，而且時間解析度越細，差距越大，因為事件驅動的成本根本不取決於解析度。這就是整個論證，也是為什麼自 1960 年代以來每一個數位模擬器都是事件驅動的。它還告訴你一件很實用的事：模擬速度取決於活動量。一個毫無理由每皮秒就翻一次 32 位元匯流排的測試平台會很慢；而忠實建模的時脈閘控（clock gating）不只會讓你的晶片更涼，也會讓你的模擬更快。更新イベント一つがいくつかの下流評価を引き起こすので、$2\times10^{11}$ 回の評価としておこう。それでも時間刻み方式より 4 桁少ない仕事量であり、時間分解能を細かくするほど差は開く。イベント駆動のコストは分解能にまったく依存しないからだ。これが議論のすべてであり、1960 年代以降のあらゆるディジタルシミュレータがイベント駆動である理由でもある。さらに実用的なことも分かる。シミュレーション速度は活性度に左右される。理由もなく 32 ビットバスを 1 ピコ秒ごとにトグルさせるテストベンチは遅い。忠実にモデル化されたクロックゲーティングは、チップを涼しくするだけでなくシミュレーションも速くする。

The slide states the rule in its two halves: new values are computed only for signals affected by events that have already occurred (spatial locality — do not touch gates whose inputs did not move) and only at those times when changes can occur (temporal locality — do not visit times at which nothing is scheduled).投影片把這條規則分成兩半陳述：新值只針對受到已發生事件影響的訊號計算（空間局部性 —— 不要去碰輸入沒動的閘），而且只在可能發生變化的那些時刻計算（時間局部性 —— 不要走訪沒有排任何事件的時刻）。スライドはこの規則を二つの半分として述べている。新しい値はすでに起きたイベントの影響を受ける信号についてのみ計算され（空間的局所性 —— 入力が動かなかったゲートには触れない）、変化が起こりうる時刻においてのみ計算される（時間的局所性 —— 何も予約されていない時刻は訪れない）。

2.3 The time-ordered event list2.3 依時間排序的事件串列2.3 時刻順のイベントリスト

The simulator’s central data structure is a list of events ordered by the time at which they are to occur. Classically this is drawn as a wheel — the slide’s figure shows a rotating “current simulation time” pointer with a bucket of events hanging off each time stamp. Each bucket holds every event scheduled for that instant; an event executing at time $t$ may append new events to buckets at $t$, $t+1$, $t+2$ and so on, never to a bucket in the past.模擬器的核心資料結構，是一份依事件預定發生時刻排序的事件串列。傳統上畫成一個輪子 —— 投影片的圖顯示一個旋轉的「目前模擬時間」指標，每個時間戳上掛著一桶事件。每一桶裝著排定在那一瞬間的所有事件；在時刻 $t$ 執行的事件可以把新事件附加到 $t$、$t+1$、$t+2$ 等等的桶上，但永遠不能加到過去的桶裡。シミュレータの中心的なデータ構造は、発生予定時刻で順序づけられたイベントのリストである。古典的には車輪として描かれ、スライドの図では回転する「現在シミュレーション時刻」のポインタと、各タイムスタンプにぶら下がるイベントのバケツが示されている。各バケツにはその瞬間に予約されたすべてのイベントが入る。時刻 $t$ で実行されるイベントは $t$、$t+1$、$t+2$ などのバケツに新たなイベントを追加できるが、過去のバケツには決して追加できない。

Three consequences follow immediately, and all three are examinable:由此立刻得到三個推論，三個都會考：ここから直ちに三つの帰結が出る。いずれも試験に出る。

1. Simulation time never runs backwards. You cannot schedule an event in the past, which is why a negative delay is an error and why $time is monotonically non-decreasing.模擬時間永不倒退。你無法把事件排在過去，這就是為什麼負延遲是錯誤，也是為什麼 $time 是單調不遞減的。シミュレーション時刻は決して逆戻りしない。過去にイベントを予約することはできない。負の遅延がエラーである理由も、$time が単調非減少である理由もここにある。
2. The initial contents of the list come from the stimulus. The slide says “initial events on the list consist of input changes”. In Verilog those come from the initial blocks in the testbench, which are all made runnable at $t_{sim} = 0$. If your testbench has no initial and no always, the list is empty at time zero and the simulation ends before it starts — a real and surprisingly common bug when a stimulus file is left out of the compile list.串列的初始內容來自激勵。投影片說「串列上的初始事件由輸入變化組成」。在 Verilog 中，它們來自測試平台裡的 initial 區塊，這些區塊全都在 $t_{sim} = 0$ 變成可執行。如果你的測試平台既沒有 initial 也沒有 always，那麼時刻零時串列就是空的，模擬還沒開始就結束了 —— 當某個激勵檔案被漏掉在編譯清單之外時，這是一個真實而且出奇常見的臭蟲。リストの初期内容は刺激から来る。スライドは「リスト上の初期イベントは入力変化からなる」と述べている。Verilog ではそれらはテストベンチの initial ブロックから来て、いずれも $t_{sim} = 0$ で実行可能になる。テストベンチに initial も always も無ければ、時刻ゼロでリストは空であり、シミュレーションは始まる前に終わる。刺激ファイルをコンパイルリストに入れ忘れたときに実際によく起きるバグである。
3. Simulation stops when the list becomes empty. Note what this does not say: it does not say the simulation stops at a fixed end time. A free-running clock generator (always #5 clk = ~clk;) schedules a new event every time it fires, so the list never empties and the run would continue forever. This is precisely why the slide’s testbench contains a third initial block whose only job is #60 $finish;. Forgetting it is the classic “my simulation hangs” bug.當串列變空時，模擬停止。請注意它沒有說的部分：它並沒有說模擬會在某個固定的結束時刻停止。一個自由跑的時脈產生器（always #5 clk = ~clk;）每次觸發都會排一個新事件，所以串列永遠不會空，模擬會一直跑下去。這正是投影片的測試平台為何包含第三個 initial 區塊、而它唯一的工作就是 #60 $finish; 的原因。忘了它，就是經典的「我的模擬卡住了」臭蟲。リストが空になるとシミュレーションは止まる。これが言っていないことに注意せよ。固定の終了時刻で止まるとは言っていない。フリーランのクロック生成器（always #5 clk = ~clk;）は発火するたびに新しいイベントを予約するので、リストは決して空にならず、実行は永遠に続く。スライドのテストベンチに、#60 $finish; だけを仕事とする三つ目の initial ブロックがあるのはまさにこのためである。これを忘れるのが、古典的な「シミュレーションが終わらない」バグである。

2.4 The stratified event queue2.4 分層事件佇列2.4 層化イベントキュー

So far, so simple. The complication — and the part the slides do not cover, but which you cannot avoid once you write anything with non-blocking assignments — is that the events scheduled for a single time stamp are not one undifferentiated bag. IEEE 1364 divides each time slot into ordered regions. This is called the stratified event queue, and it is the formal reason Verilog is usable at all for synchronous design.到這裡為止都很單純。複雜之處 —— 也是投影片沒講、但你一旦寫下任何含非阻塞指定的程式碼就無法迴避的部分 —— 在於：排在同一個時間戳上的事件，並不是一袋不分彼此的東西。IEEE 1364 把每個時間槽切成有先後次序的區域（region）。這稱為分層事件佇列（stratified event queue），也是 Verilog 之所以能用於同步設計的形式上理由。ここまでは単純である。複雑になるのは —— スライドでは触れられていないが、ノンブロッキング代入を含むものを一度でも書けば避けられない部分だが —— 同一のタイムスタンプに予約されたイベントが、区別のない一つの袋ではないという点である。IEEE 1364 は各タイムスロットを順序づけられた領域（region）に分割する。これを層化イベントキュー（stratified event queue）と呼び、Verilog が同期設計に使える形式的な根拠となっている。

The regions, in the order the simulator drains them:各區域，依模擬器排乾它們的順序：領域を、シミュレータが空にしていく順に並べると次のようになる。

There is also a conceptual future region holding everything scheduled for later times; it is not part of the current slot.另外還有一個概念上的未來區域，裝著所有排在較晚時刻的東西；它不屬於目前這個時間槽。さらに、より後の時刻に予約されたすべてを保持する概念上の未来領域もあるが、これは現在のスロットの一部ではない。

2.5 The reference algorithm, written out2.5 把參考演算法完整寫出來2.5 参照アルゴリズムを書き下す

IEEE 1364 gives the scheduler as pseudo-code. Stripped to its essentials it reads like this:IEEE 1364 以虛擬碼的形式給出排程器。剝到只剩骨幹的話，它讀起來像這樣：IEEE 1364 はスケジューラを擬似コードとして与えている。本質だけを残すと次のように読める。

T = 0;
// make every initial / always block runnable
while (event queue is not empty) begin

  if (ACTIVE is empty) begin
    if      (INACTIVE non-empty) move all INACTIVE events into ACTIVE;
    else if (NBA      non-empty) move all NBA      events into ACTIVE;
    else if (MONITOR  non-empty) move all MONITOR  events into ACTIVE;
    else begin
      T = time of the earliest event still scheduled;   // time finally advances
      move every event scheduled at T into ACTIVE;
    end
  end

  E = any event from ACTIVE;          // <-- the standard says "any"
  remove E from ACTIVE;

  if (E is an update event) begin
    write the new value into the net or variable;
    for (every process sensitive to it)
      schedule an evaluation event in ACTIVE;
  end
  else begin                          // E is an evaluation event
    execute the process until it blocks;
    it may schedule update events now or in the future;
  end
end

Read the highlighted line again. “Any” is normative. The standard deliberately refuses to specify the order in which simultaneous active events are processed, because pinning it down would forbid perfectly reasonable implementations — and because a design whose behaviour depends on that order is broken anyway. Everything in §2.7 follows from this single word.再讀一次標示出來的那一行。「任意」是規範性的用語。標準刻意拒絕規定同時發生的 active 事件的處理順序，因為把它釘死會禁掉完全合理的實作方式 —— 也因為行為取決於那個順序的設計，本來就是壞的。§2.7 的所有內容都源自這一個詞。強調された行をもう一度読んでほしい。「任意（any）」は規範的な語である。標準は、同時に存在するアクティブイベントの処理順序を定めることを意図的に拒んでいる。それを固定すればまったく妥当な実装を禁じることになるからであり、またその順序に振る舞いが依存する設計はそもそも壊れているからである。§2.7 の内容はすべてこの一語から導かれる。

Notice also where time advances: in exactly one place, at the bottom of the region cascade, and only when all four regions of the current slot are empty. Within one value of $time the simulator may loop around the region cascade an unbounded number of times.也請注意時間在哪裡前進：只在一個地方，在區域串級的最底部，而且只有在目前時間槽的四個區域全都空了的時候。在同一個 $time 值之內，模擬器可以在區域串級上繞無上限多圈。時刻がどこで進むかにも注意せよ。進むのはただ一か所、領域カスケードの最下部であり、しかも現在のスロットの四つの領域がすべて空になったときだけである。同じ $time の値の中で、シミュレータは領域カスケードを何周でも回りうる。

2.6 Delta cycles2.6 Delta 週期2.6 デルタサイクル

Each pass around that cascade at a fixed simulation time is a delta cycle. Delta cycles are how a zero-delay model propagates a value through a chain of logic without time advancing.在固定模擬時刻上繞那個串級一圈，就是一個 delta 週期。delta 週期正是零延遲模型在時間不前進的情況下，把一個值傳遞過一串邏輯的方式。固定されたシミュレーション時刻でそのカスケードを一周することが、一つのデルタサイクルである。デルタサイクルは、時刻を進めずに値を論理の連鎖に伝播させる、ゼロ遅延モデルのやり方である。

Take the slide’s own circuit with no delays: C = A & B feeding D = ~C. At $t_{sim} = 10$ the testbench writes A = 1. That is one update event. Draining the queue:取投影片自己的電路，不含延遲：C = A & B 餵給 D = ~C。在 $t_{sim} = 10$ 時測試平台寫入 A = 1。那是一個更新事件。把佇列排乾：スライド自身の回路を遅延なしで取る。C = A & B が D = ~C に入る。$t_{sim} = 10$ でテストベンチが A = 1 を書く。これが一つの更新イベントである。キューを空にしていくと：

Five delta cycles, all at $t_{sim} = 10$. $time returns 10 throughout; a waveform viewer shows A, C and D all changing at exactly 10. The deltas are invisible in the waveform but they are the reason the order of changes is still well defined: C genuinely does change before D, in delta order if not in time order.五個 delta 週期，全都在 $t_{sim} = 10$。$time 從頭到尾都回傳 10；波形檢視器會顯示 A、C、D 全都剛好在 10 變化。這些 delta 在波形中看不見，但它們正是變化順序依然有明確定義的原因：C 確實在 D 之前改變 —— 就算不是在時間順序上，也是在 delta 順序上。デルタサイクルは五つ、いずれも $t_{sim} = 10$ である。$time は終始 10 を返し、波形ビューアでは A、C、D がすべてちょうど 10 で変化しているように見える。デルタは波形には現れないが、変化の順序が依然として明確に定まっている理由がそこにある。C は確かに D より先に変わる。時刻の順序ではないにせよ、デルタの順序ではそうなのだ。

assign a = ~a;    // zero-delay oscillator: the simulator hangs at t = 0

2.7 Races, and why two simulators may legitimately disagree2.7 競爭，以及為何兩個模擬器可以合法地不一致2.7 レース、そしてなぜ二つのシミュレータが正当に食い違いうるのか

Because the standard says “any event from ACTIVE”, two conforming simulators can produce different — and both correct — answers for the same source. A design with that property contains a race. The exam-relevant canonical case:因為標準說的是「ACTIVE 中的任意事件」，兩個符合標準的模擬器可以對同一份原始碼產生不同的 —— 而且兩者都正確的 —— 答案。具備這種性質的設計含有一個競爭（race）。與考試相關的經典案例：標準が「ACTIVE の中の任意のイベント」と述べている以上、標準に準拠した二つのシミュレータが、同じソースに対して異なる、しかもどちらも正しい答えを出しうる。その性質を持つ設計にはレースが含まれている。試験に出る典型例を示す。

always @(posedge clk) b = a;
always @(posedge clk) c = b;

always @(posedge clk) b <= a;
always @(posedge clk) c <= b;

Suppose before the edge a = 1, b = 0, c = 0. The clock rises. Both always blocks become active evaluation events at the same time stamp, and the simulator may take them in either order.假設邊緣之前 a = 1、b = 0、c = 0。時脈上升。兩個 always 區塊在同一個時間戳上都成為 active 的求值事件，而模擬器可以用任一順序處理它們。エッジの前に a = 1、b = 0、c = 0 だったとする。クロックが立ち上がる。二つの always ブロックは同じタイムスタンプでアクティブな評価イベントになり、シミュレータはどちらの順でも処理してよい。

Both are legal executions of that source. The synthesised netlist, meanwhile, is unambiguously a two-stage shift register — real flip-flops all sample simultaneously. So the blocking version can produce a simulation that disagrees with the silicon, which is the worst failure mode in the business: your testbench passes and your chip does not work.兩者都是那份原始碼的合法執行結果。然而合成出來的網表毫無疑義就是一個兩級移位暫存器 —— 真實的正反器全都同時取樣。所以阻塞式的版本可能產生出與矽不一致的模擬結果，而這是業界最糟的失效模式：你的測試平台通過了，你的晶片卻不會動。どちらもそのソースの合法な実行である。一方、合成されたネットリストは疑いなく二段シフトレジスタである。実際のフリップフロップはすべて同時にサンプルするからだ。つまりブロッキング版は、シリコンと食い違うシミュレーション結果を生みうる。これは業界で最悪の故障モードである。テストベンチは通るのにチップは動かない。

The non-blocking version has no such freedom. Both right-hand sides are evaluated in the active region, reading the old b and the old a; both writes happen later in the NBA region. Whichever order the simulator picks, the answer is b = 1, c = 0. The rule that follows — non-blocking assignments for sequential logic, blocking for combinational — is the most quoted rule in Verilog, and this is where it comes from.非阻塞的版本沒有這種自由度。兩條右手邊都在 active 區域求值，讀到的是舊的 b 與舊的 a；兩次寫入都稍後才在 NBA 區域發生。無論模擬器挑哪個順序，答案都是 b = 1、c = 0。由此得出的規則 —— 循序邏輯用非阻塞指定，組合邏輯用阻塞指定 —— 是 Verilog 中被引用最多的規則，而它的出處就在這裡。ノンブロッキング版にはその自由度が無い。両方の右辺はアクティブ領域で評価され、古い b と古い a を読む。書き込みはいずれも後の NBA 領域で起きる。シミュレータがどちらの順序を選んでも、答えは b = 1、c = 0 である。ここから出てくる規則 —— 順序回路にはノンブロッキング代入、組合せ回路にはブロッキング代入 —— は Verilog で最も多く引用される規則であり、その出所がこれである。

The testbench side of that last sentence deserves its own warning, because it bites every year. If your stimulus block is always @(posedge clk) data = data + 1; and the DUT samples data on the same posedge clk, you have built exactly the race above with the stimulus playing the part of block 1. Three standard cures, in order of preference: drive stimulus with non-blocking assignments; drive it off the opposite clock edge; or offset it by an explicit small delay (@(posedge clk) #1 data = ...;) so the DUT’s sample point and the stimulus change are in different time slots.最後那句話的測試平台面向值得單獨警告，因為它每年都咬人。如果你的激勵區塊是 always @(posedge clk) data = data + 1;，而 DUT 又在同一個 posedge clk 取樣 data，那你就造出了上面那個競爭，只是由激勵扮演區塊 1 的角色。三個標準解法，依偏好排序：用非阻塞指定驅動激勵；用相反的時脈邊緣驅動它；或是用一個明確的小延遲把它錯開（@(posedge clk) #1 data = ...;），讓 DUT 的取樣點與激勵的變化落在不同的時間槽。最後の一文のテストベンチ側は、毎年必ず誰かを噛むので単独で警告しておく価値がある。刺激ブロックが always @(posedge clk) data = data + 1; で、DUT が同じ posedge clk で data をサンプルしているなら、刺激がブロック 1 の役を演じる形で、まさに上のレースを作ったことになる。標準的な対処は三つ、好ましい順に挙げる。刺激をノンブロッキング代入で駆動する。反対のクロックエッジで駆動する。あるいは明示的な小さい遅延でずらし（@(posedge clk) #1 data = ...;）、DUT のサンプル点と刺激の変化を別のタイムスロットに置く。

2.8 Hand-simulating a circuit, step by step2.8 一步一步手工模擬一個電路2.8 回路を一歩ずつ手でシミュレートする

Being able to produce a timing diagram with a pencil, from the event list, is an exam skill and a debugging skill. Here is the full procedure on the slide’s own example so that §3 can reuse it.能夠拿著鉛筆、從事件串列畫出時序圖，既是一項考試技能，也是一項除錯技能。以下用投影片自己的例子走完整個程序，好讓 §3 可以沿用。鉛筆を手に、イベントリストからタイミング図を描けることは、試験の技能であると同時にデバッグの技能でもある。§3 で再利用できるよう、スライド自身の例で手順を最後まで示す。

The discipline to copy is: (i) write down the current value of every net; (ii) apply the input change; (iii) re-evaluate only the gates fed by what changed; (iv) schedule an event only where the computed value differs from the present value; (v) repeat for the newly changed nets. Four lines of bookkeeping, and it generalises directly to the delayed case in §3.值得照抄的紀律是：(i) 寫下每條連線目前的值；(ii) 套用輸入變化；(iii) 只重新求值被變化餵到的閘；(iv) 只在算出的值與現值不同時才排事件；(v) 對新變化的連線重複以上步驟。四行帳就記完了，而且可以直接推廣到 §3 的有延遲情形。まねるべき規律はこうだ。(i) すべてのネットの現在値を書き出す。(ii) 入力変化を適用する。(iii) 変化したものに駆動されるゲートだけを再評価する。(iv) 計算値が現在値と異なるときだけイベントを予約する。(v) 新たに変化したネットについて繰り返す。帳簿は四行で済み、そのまま §3 の遅延ありの場合へ一般化できる。

always @(posedge clk) begin a = b; end      // version A, two separate blocks
always @(posedge clk) begin b = a; end

always @(posedge clk) begin a <= b; end     // version B
always @(posedge clk) begin b <= a; end

3. Delay Models, Inertial Delay and Pulse Rejection3. 延遲模型、慣性延遲與脈衝抑制3. 遅延モデル・慣性遅延・パルス除去

3.1 Simulation without delay3.1 無延遲的模擬3.1 遅延なしのシミュレーション

A gate written without a delay specification — and (C, A, B); — has zero delay. Its output changes in the same time slot as its input, separated only by delta cycles. The slide calls this “generate the results immediately (no response time)”.一個寫出來沒有延遲規格的閘 —— and (C, A, B); —— 延遲為零。它的輸出與輸入在同一個時間槽內變化，兩者之間只隔著 delta 週期。投影片稱之為「立刻產生結果（沒有反應時間）」。遅延指定なしで書かれたゲート —— and (C, A, B); —— は遅延ゼロである。出力は入力と同じタイムスロットで変化し、両者を隔てるのはデルタサイクルだけだ。スライドはこれを「結果を即座に生成する（応答時間なし）」と呼んでいる。

Zero-delay modelling is not a simplification that will be fixed later; it is the correct and intended style for RTL, the level at which you will write everything from Lecture 4 onwards. The reason is a division of labour. RTL describes what the logic computes; a static timing analysis tool, run after synthesis against the standard-cell library, decides how long it takes. Putting delays in RTL would be stating a timing answer before the implementation that determines it exists, and the numbers would be wrong. Delays belong in two places only: the cell models of a vendor library (back-annotated from SDF after place-and-route), and teaching examples like this lecture’s.零延遲建模並不是一個日後要修正的簡化；它正是 RTL 這個層次上正確而且刻意採用的風格，而從 Lecture 4 起你寫的一切都在這個層次。理由在於分工。RTL 描述邏輯算什麼；至於要花多久，則由合成之後針對標準元件庫執行的靜態時序分析工具決定。把延遲放進 RTL，等於在決定延遲的實作存在之前就先宣布時序答案，而那些數字一定是錯的。延遲只屬於兩個地方：廠商元件庫的 cell 模型（在繞線之後由 SDF 反標註回來），以及像本講這樣的教學範例。ゼロ遅延のモデル化は、後で直すべき簡略化ではない。RTL、すなわち Lecture 4 以降に書くすべてのものが属するレベルにおける、正しく意図されたスタイルである。理由は分業にある。RTL は論理が何を計算するかを記述し、どれだけ時間がかかるかは、合成後に標準セルライブラリに対して走らせる静的タイミング解析ツールが決める。RTL に遅延を書くことは、それを決める実装が存在する前にタイミングの答えを宣言することであり、その数値は誤っている。遅延が属する場所は二つだけだ。ベンダライブラリのセルモデル（配置配線後に SDF から逆注釈される）と、本講のような教育用の例である。

The one thing zero delay costs you is the ability to see glitches. In a zero-delay model a combinational network reaches its final value in delta cycles, so hazards that a real circuit would exhibit as narrow spikes never appear. That is usually what you want in RTL simulation — you do not care about a hazard that will be swallowed by a flip-flop’s setup window — but it is why gate-level simulation with real delays is still run before tape-out.零延遲唯一讓你失去的，是看見毛刺（glitch）的能力。在零延遲模型中，組合網路在幾個 delta 週期內就到達最終值，所以真實電路會表現成窄尖波的冒險（hazard）根本不會出現。在 RTL 模擬中這通常正是你要的 —— 你不在乎一個會被正反器建立時間視窗吞掉的 hazard —— 但這也正是為什麼在 tape-out 之前仍要跑帶真實延遲的閘級模擬。ゼロ遅延で失われるものは一つだけ、グリッチを見る能力である。ゼロ遅延モデルでは組合せ回路網がデルタサイクルのうちに最終値へ到達するので、実回路なら細いスパイクとして現れるハザードがまったく出てこない。RTL シミュレーションではたいていそれが望ましい —— フリップフロップのセットアップ窓に飲み込まれるハザードなど気にしない —— が、テープアウト前に実遅延つきのゲートレベルシミュレーションを依然として走らせる理由もそこにある。

3.2 Simulation with gate delay3.2 含閘延遲的模擬3.2 ゲート遅延つきのシミュレーション

Attach a delay and the structure of the event list changes. and #3 (C, A, B); means: whenever the output of this gate would change, schedule that change three time units into the future rather than now.一旦加上延遲，事件串列的結構就變了。and #3 (C, A, B); 的意思是：每當這個閘的輸出將要改變時，就把那個改變排在未來三個時間單位，而不是現在。遅延を付けるとイベントリストの構造が変わる。and #3 (C, A, B); の意味は、このゲートの出力が変化しようとするたびに、その変化を今ではなく 3 時間単位先に予約する、ということである。

The slide’s example is the same AND/NOT chain with AND = 3 ns and inverter = 2 ns. Work it with the five-step discipline from §2.8, adding one line: schedule at $t+d$, not at $t$.投影片的例子是同一條 AND/NOT 鏈，AND = 3 ns、反相器 = 2 ns。用 §2.8 的五步紀律去做，只要加一行：排在 $t+d$，不是排在 $t$。スライドの例は同じ AND/NOT の連鎖で、AND = 3 ns、インバータ = 2 ns である。§2.8 の五段階の規律でそのまま解き、一行だけ加える。$t$ ではなく $t+d$ に予約する。

Two features of the delayed waveform are worth dwelling on. First, the x region at the beginning is longer for the deeper node: C′ leaves x at 13, D′ only at 15. Unknown values propagate with the same delay as known ones. In a large design this produces the familiar phenomenon of an x “wavefront” sweeping through the logic for several hundred nanoseconds after power-up until reset has flushed it out.有延遲的波形有兩個特徵值得多停留一下。第一，開頭的 x 區域對越深的節點越長：C′ 在 13 離開 x，D′ 要到 15。未知值傳播的延遲與已知值相同。在大型設計中，這會造成大家熟悉的現象：通電後有一道 x「波前」橫掃整個邏輯好幾百奈秒，直到重置把它沖乾淨為止。遅延つき波形には、立ち止まって見る価値のある特徴が二つある。第一に、冒頭の x 領域は深いノードほど長い。C′ は 13 で x を抜け、D′ は 15 まで抜けない。不定値は既知値と同じ遅延で伝播する。大規模設計では、電源投入後に x の「波面」が数百ナノ秒にわたって論理を掃いていき、リセットがそれを洗い流すまで続く、というおなじみの現象になる。

Second, at $t = 40$ nothing happens at all. The AND gate is re-evaluated — B changed, so the simulator must look — but the computed value equals the present value, so no event is created and the inverter is never visited. An event-driven simulator can tell you it did almost no work here; a time-stepped one could not.第二，在 $t = 40$ 時什麼也沒發生。AND 閘確實被重新求值了 —— B 變了，模擬器必須去看 —— 但算出的值等於現值，所以沒有建立事件，反相器也完全不會被走訪。事件驅動模擬器能告訴你它在這裡幾乎沒做事；時間步進式的則做不到。第二に、$t = 40$ では何も起きない。AND ゲートは確かに再評価される —— B が変わったのでシミュレータは見に行かねばならない —— が、計算値が現在値と等しいのでイベントは作られず、インバータは一度も訪れられない。イベント駆動シミュレータはここでほとんど仕事をしなかったと言える。時間刻み型にはそれができない。

3.3 Inertial delay, defined properly3.3 把慣性延遲好好定義一遍3.3 慣性遅延をきちんと定義する

So far delay has looked like a simple shift to the right. It is not, and the difference is the subject of the slide titled Simulation with Inertial Delay.到目前為止，延遲看起來就像單純往右平移。其實不是，而這個差別正是那張標題為 Simulation with Inertial Delay 的投影片的主題。ここまで遅延は単に右へ平行移動するだけに見えてきた。実際はそうではなく、その違いこそ Simulation with Inertial Delay と題されたスライドの主題である。

The physical motivation comes from the gate itself. A CMOS gate’s output node has capacitance; switching it means moving charge through a finite-conductance transistor. If the input pulse is removed before enough charge has moved, the output never reaches the switching threshold of the next stage and the pulse simply does not propagate. The circuit has inertia: an input disturbance must persist for some minimum time to have any effect.物理上的動機來自閘本身。CMOS 閘的輸出節點有電容；要切換它，就必須透過一個導通度有限的電晶體搬移電荷。如果輸入脈衝在足夠的電荷搬完之前就被撤掉，輸出就永遠到不了下一級的切換門檻，脈衝也就根本不會傳下去。電路具有慣性：輸入的擾動必須持續某個最短時間，才會產生任何效果。物理的な動機はゲート自身にある。CMOS ゲートの出力ノードには容量があり、それを切り替えるには有限のコンダクタンスのトランジスタを通して電荷を動かさねばならない。十分な電荷が動く前に入力パルスが取り除かれれば、出力は次段のスイッチング閾値に届かず、パルスはそもそも伝播しない。回路には慣性がある。入力の擾乱は、何らかの効果を持つために最小限の時間だけ持続しなければならない。

The mechanism in the event queue is a cancellation. Each driver keeps at most one pending output event. When the driver re-evaluates at time $t$ and computes a new value $v$:事件佇列裡的機制是一次取消。每個驅動源最多保留一個待處理的輸出事件。當驅動源在時刻 $t$ 重新求值並算出新值 $v$ 時：イベントキュー上の仕組みはキャンセルである。各ドライバは未成熟の出力イベントを高々一つだけ保持する。ドライバが時刻 $t$ に再評価して新しい値 $v$ を計算したとき：

1. If there is a pending output event that has not yet matured, and its value differs from $v$, that pending event is cancelled.如果存在一個尚未到期的待處理輸出事件，而且它的值與 $v$ 不同，那個待處理事件就會被取消。まだ成熟していない保留中の出力イベントがあり、その値が $v$ と異なるなら、その保留イベントはキャンセルされる。
2. If $v$ differs from the output’s current value, a fresh event ($v$ at $t+d$) is scheduled.如果 $v$ 與輸出的現值不同，就排一個新的事件（在 $t+d$ 的 $v$）。$v$ が出力の現在値と異なるなら、新しいイベント（$t+d$ における $v$）を予約する。
3. If $v$ equals the current value, nothing is scheduled — and because step 1 already removed the pending event, the output never moves at all.如果 $v$ 等於現值，就什麼也不排 —— 而因為步驟 1 已經把待處理事件移除了，輸出根本不會動。$v$ が現在値と等しいなら何も予約しない —— そしてステップ 1 ですでに保留イベントを取り除いているので、出力はまったく動かない。

Step 1 followed by step 3 is pulse rejection. It is not a special case bolted on; it falls out of “one pending event per driver, replaced on every re-evaluation”.步驟 1 接著步驟 3，就是脈衝抑制。它不是硬加上去的特例；它是「每個驅動源一個待處理事件，每次重新求值都換掉」這條規則自然掉出來的結果。ステップ 1 に続いてステップ 3 が起きる、それがパルス除去である。後付けの特例ではなく、「ドライバごとに保留イベントは一つ、再評価のたびに置き換える」という規則から自然に落ちてくる。

3.4 Worked pulse rejection3.4 脈衝抑制實作演練3.4 パルス除去の計算例

3.5 Transport delay, and how to get it when you need it3.5 傳輸延遲，以及需要時怎麼得到它3.5 伝送遅延と、必要なときの手に入れ方

The opposite model is transport delay: every input change produces a corresponding output change $d$ later, no matter how close together they are. This is the right model for an ideal wire or a transmission line, where narrow pulses do propagate. VHDL offers both models with keywords (after versus transport ... after); Verilog gives you inertial delay by default on gates and continuous assignments, and makes you build transport delay out of non-blocking assignment.相反的模型是傳輸延遲（transport delay）：每一次輸入變化都會在 $d$ 之後產生一次對應的輸出變化，不管它們靠得多近。對理想導線或傳輸線而言這才是正確的模型，因為窄脈衝確實會傳過去。VHDL 用關鍵字提供兩種模型（after 對上 transport ... after）；Verilog 則在閘與連續指定上預設給你慣性延遲，而要傳輸延遲就得自己用非阻塞指定去搭。反対のモデルが伝送遅延（transport delay）である。入力変化はどれだけ近接していても、$d$ 後に対応する出力変化を必ず生む。狭いパルスも実際に伝播する理想的な配線や伝送線にはこちらが正しいモデルである。VHDL は両方のモデルをキーワードで提供する（after と transport ... after）。Verilog はゲートと連続代入では既定で慣性遅延を与え、伝送遅延はノンブロッキング代入で自分で組み立てさせる。

assign #5 out = in;

// one pending event; every
// re-evaluation replaces it

always @(in)
  out <= #5 in;

// each trigger queues its own
// independent NBA update

Why does the second form behave differently? Because of where the two halves of a non-blocking assignment live (§2.4). out <= #5 in; evaluates in immediately and then queues an independent update for five units later. A second trigger one unit afterwards queues a second independent update. Nothing cancels anything, so every input edge comes out the other end. The continuous assignment, by contrast, has exactly one driver with exactly one pending event, and replacing that event is what produces the inertial filtering.為什麼第二種寫法行為不同？因為非阻塞指定的兩半住在哪裡（§2.4）。out <= #5 in; 會立刻求出 in 的值，然後把一次獨立的更新排到五個單位之後。一個單位後的第二次觸發，會排出第二個獨立更新。沒有任何東西取消任何東西，所以每個輸入邊緣都會從另一端出來。相對地，連續指定只有一個驅動源、只有一個待處理事件，而替換那個事件正是產生慣性濾波的機制。なぜ二つ目の書き方は挙動が違うのか。ノンブロッキング代入の二つの半分がどこにあるかによる（§2.4）。out <= #5 in; は in を直ちに評価し、5 単位後に独立した更新を予約する。その 1 単位後に再び発火すれば、二つ目の独立した更新が予約される。何も何かをキャンセルしないので、入力のすべてのエッジが反対側から出てくる。対照的に連続代入はドライバが一つ、保留イベントも一つだけであり、そのイベントを置き換えることが慣性フィルタを生んでいる。

always @(in) out = #5 in;   // blocks for 5 units: input changes during
                            // that window are MISSED entirely

If you need genuine control over pulse behaviour on a timing-annotated path — the situation in a real sign-off gate-level simulation — the mechanism is the specify block, where a module path can be given a separate rejection limit and error limit via PATHPULSE$ specparams. Below the rejection limit a pulse is filtered; above the error limit it passes; in between the output goes to x to flag that the real circuit’s behaviour is unpredictable. That three-way treatment is what vendor cell libraries actually ship with, and it is the honest answer to “what happens at $w = d$” in an industrial flow.如果你需要在一條有時序標註的路徑上真正控制脈衝行為 —— 也就是真實 sign-off 閘級模擬的情境 —— 機制是 specify 區塊：模組路徑可以透過 PATHPULSE$ specparam 被賦予獨立的抑制門檻（rejection limit）與錯誤門檻（error limit）。低於抑制門檻的脈衝會被濾掉；高於錯誤門檻的會通過；介於兩者之間時，輸出會變成 x，以標示真實電路的行為不可預測。這種三段式處理才是廠商元件庫真正隨附的作法，也是在業界流程中對「$w = d$ 會怎樣」最誠實的回答。タイミング注釈された経路でパルスの挙動を本当に制御する必要があるなら —— 実際のサインオフ用ゲートレベルシミュレーションがその状況だ —— 仕組みは specify ブロックである。モジュールパスには PATHPULSE$ specparam によって独立した除去限界（rejection limit）とエラー限界（error limit）を与えられる。除去限界より狭いパルスは濾され、エラー限界より広いものは通る。その間では出力が x になり、実回路の挙動が予測不能であることを示す。この三段構えこそベンダのセルライブラリが実際に備えているものであり、産業フローにおける「$w = d$ では何が起きるか」への正直な答えである。

3.6 Rise, fall, turn-off and min:typ:max3.6 上升、下降、關斷與 min:typ:max3.6 立ち上がり・立ち下がり・ターンオフと min:typ:max

Verilog’s delay specification is richer than the single number in the slides, and the full syntax turns up constantly in library models, so it is worth recognising.Verilog 的延遲規格比投影片上那個單一數字豐富得多，而完整語法在元件庫模型裡隨處可見，所以值得認得。Verilog の遅延指定はスライドの単一の数値よりはるかに豊かであり、完全な構文はライブラリモデルに絶えず現れるので、見分けられるようにしておく価値がある。

Delays may also be attached to a continuous assignment (assign #5 y = a & b;) and to a net declaration (wire #5 y;, or with a range, wire [7:0] #5 y = a ^ b; — the range comes first, the delay second). They may not be attached to a module instantiation: myblock #5 U1 (...) does not mean “delay”, it means “parameter override”, which is the subject of §7 and a notorious source of silent mis-elaboration.延遲也可以掛在連續指定上（assign #5 y = a & b;）與連線宣告上（wire #5 y;，或帶位元範圍時寫成 wire [7:0] #5 y = a ^ b; —— 範圍在前，延遲在後）。但它們不可以掛在模組實例化上：myblock #5 U1 (...) 的意思不是「延遲」，而是「參數覆寫」，那是 §7 的主題，也是惡名昭彰的無聲誤展開來源。遅延は連続代入（assign #5 y = a & b;）やネット宣言（wire #5 y;、ビット範囲を伴うなら wire [7:0] #5 y = a ^ b; —— 範囲が先、遅延が後）にも付けられる。しかしモジュールのインスタンス化に付けることはできない。myblock #5 U1 (...) は「遅延」ではなく「パラメータのオーバーライド」を意味する。これは §7 の主題であり、黙って誤ったエラボレーションを引き起こす悪名高い原因でもある。

4. Testbench Structure and the System Tasks4. 測試平台結構與系統任務4. テストベンチの構造とシステムタスク

4.1 The skeleton4.1 骨架4.1 骨組み

The slide is candid: there is no firm rule for testbench editing. True — but there is a conventional layout that every testbench you will read follows, and deviating from it without reason costs the reader time. In order:投影片說得很坦白：測試平台的寫法沒有硬性規則。確實如此 —— 但有一套慣用的排版，你將讀到的每一個測試平台都依循它，而無故偏離它會浪費讀者的時間。依序是：スライドは率直にこう述べている。テストベンチの書き方に確たる規則は無い。その通りだが、これから読むどのテストベンチも従っている慣例的な構成はあり、理由なくそこから外れると読み手の時間を奪う。順に示す。

`timescale 1ns / 1ps                     // 1. time unit / precision

module test_Nand_Latch_1;                // 2. no port list

  reg  preset, clear;                    // 3. reg  for everything the TB drives
  wire q, qbar;                          //    wire for everything the TB observes

  Nand_Latch_1 M1 (q, qbar, preset, clear);   // 4. instantiate the DUT

  initial begin                          // 5. observation
    $monitor($time, " preset=%b clear=%b q=%b qbar=%b", preset, clear, q, qbar);
  end

  initial begin                          // 6. stimulus
    #10 preset = 0; clear = 1;
    #10 preset = 1;
    #10 clear  = 0;
    #10 clear  = 1;
    #10 preset = 0;
  end

  initial #60 $finish;                   // 7. the stop watch

endmodule

Step 3 is the rule students most often get backwards, and it is not arbitrary. The testbench assigns to the DUT’s inputs from inside initial blocks, i.e. procedurally — and §6.1 will show that only a reg can be a procedural assignment target. The DUT’s outputs, conversely, are driven by the DUT itself, so from the testbench’s point of view they are connections to be watched, i.e. wires. Memorise it as: reg in, wire out, from the testbench’s perspective — which is precisely the mirror image of the DUT’s own declarations.步驟 3 是學生最常弄反的規則，而它並不武斷。測試平台是從 initial 區塊內部、也就是以程序性的方式去指定 DUT 的輸入 —— 而 §6.1 會說明只有 reg 才能當程序性指定的目標。反過來，DUT 的輸出是由 DUT 自己驅動的，所以從測試平台的角度看，它們是「要被觀察的連接」，也就是 wire。請這樣背：從測試平台的角度，輸入用 reg、輸出用 wire —— 正好是 DUT 自己宣告的鏡像。ステップ 3 は学生が最も逆に覚えやすい規則だが、恣意的なものではない。テストベンチは DUT の入力に initial ブロックの中から、すなわち手続き的に代入する —— そして §6.1 で示すように、手続き代入の代入先になれるのは reg だけである。逆に DUT の出力は DUT 自身が駆動するので、テストベンチから見ればそれは観測すべき接続、すなわち wire である。テストベンチの視点で入力は reg、出力は wireと覚えること。DUT 自身の宣言のちょうど鏡像になっている。

Step 7 is the one most often omitted. Without it a testbench containing a free-running clock never terminates (§2.3).步驟 7 是最常被省略的一步。少了它，含自由跑時脈的測試平台永遠不會終止（§2.3）。ステップ 7 は最も省かれやすい。これが無いと、フリーランのクロックを含むテストベンチは決して終了しない（§2.3）。

4.2 `timescale, time units and time precision4.2 `timescale、時間單位與時間精度4.2 `timescale・時間単位・時間精度

Everything in §3 was expressed in “time units”. The compiler directive that gives them meaning is§3 裡的一切都用「時間單位」來表達。賦予它們意義的編譯指示是§3 の内容はすべて「時間単位」で表現されていた。それに意味を与えるコンパイラ指示子が次である。

The unit is what a bare number in a delay means: with `timescale 1ns/1ps, #5 is 5 ns. The precision is the granularity to which delays are rounded and the resolution at which the simulator keeps time: with 1 ps precision, #5.3721 becomes 5.372 ns. Precision must be no coarser than the unit. Both are written as 1, 10 or 100 followed by s, ms, us, ns, ps or fs.單位決定延遲中一個裸數字的意思：在 `timescale 1ns/1ps 下，#5 就是 5 ns。精度是延遲被四捨五入到的粒度，也是模擬器記錄時間的解析度：在 1 ps 精度下，#5.3721 會變成 5.372 ns。精度不可以比單位粗。兩者都寫成 1、10 或 100，後面接 s、ms、us、ns、ps 或 fs。単位は遅延に書かれた裸の数値の意味を決める。`timescale 1ns/1ps のもとでは #5 は 5 ns である。精度は遅延が丸められる粒度であり、シミュレータが時刻を保持する分解能でもある。精度 1 ps なら #5.3721 は 5.372 ns になる。精度は単位より粗くてはならない。どちらも 1、10、100 のいずれかに s、ms、us、ns、ps、fs を続けて書く。

Three practical points that cause real confusion:三個會造成真實困惑的實務要點：実際に混乱を招く実務上の要点が三つある。

• The timescale is per compilation unit, not per module. A `timescale applies to every module compiled after it until the next one. If one file has it and the next does not, the next inherits the previous file’s — so the behaviour of your design can depend on the order of files on the compiler command line. The fix is to put an identical `timescale at the top of every file, or none at all and set it globally with a tool switch.timescale 的作用範圍是編譯單元，不是模組。一個 `timescale 會套用到它之後編譯的每一個模組，直到下一個 `timescale 為止。如果某個檔案有而下一個沒有，下一個就繼承前一個檔案的 —— 於是你設計的行為可能取決於編譯器命令列上檔案的順序。解法是在每個檔案開頭放一個完全相同的 `timescale，或是乾脆都不放、改用工具開關全域設定。timescale の有効範囲はモジュールではなくコンパイル単位である。一つの `timescale は、その後にコンパイルされるすべてのモジュールに、次の `timescale まで適用される。あるファイルにあって次のファイルに無ければ、次のファイルは前のファイルのものを引き継ぐ。つまり設計の挙動がコンパイラのコマンドラインにおけるファイルの順序に左右されうる。対策は、全ファイルの先頭に同一の `timescale を置くか、まったく置かずにツールのスイッチでグローバルに設定することである。
• The finest precision anywhere in the design sets the simulator’s global tick. If one cell library model declares 1ps/1fs, the whole simulation runs with femtosecond resolution and the event queue grows accordingly. This is a measurable performance problem in large gate-level runs.設計中任何一處最細的精度，決定模擬器的全域時間刻度。只要有一個元件庫模型宣告 1ps/1fs，整個模擬就會以飛秒解析度執行，事件佇列也隨之膨脹。在大型閘級模擬中，這是一個可以量到的效能問題。設計のどこかにある最も細かい精度が、シミュレータのグローバルな時間刻みを決める。セルライブラリのモデルが一つでも 1ps/1fs を宣言していれば、シミュレーション全体がフェムト秒分解能で走り、イベントキューもそれに応じて膨らむ。大規模なゲートレベル実行では、これは計測できる性能問題になる。
• Rounding happens at elaboration, not at run time, and it is round-to-nearest. With 1ns/1ns, #0.5 becomes #1 and #0.4 becomes #0 — a delay that silently vanishes into the inactive region. A clock written as always #0.5 clk = ~clk; under a 1 ns precision becomes a 2 ns clock, not a 1 ns one, and nobody notices until the frequency is wrong.四捨五入發生在展開期（elaboration），不是執行期，而且是四捨五入到最近值。在 1ns/1ns 下，#0.5 會變成 #1，而 #0.4 會變成 #0 —— 一個無聲消失進 inactive 區域的延遲。在 1 ns 精度下寫成 always #0.5 clk = ~clk; 的時脈會變成 2 ns 的時脈，而不是 1 ns 的，而且在頻率算錯之前沒有人會注意到。丸めは実行時ではなくエラボレーション時に起き、しかも最近接への丸めである。1ns/1ns のもとでは #0.5 は #1 になり、#0.4 は #0 になる —— インアクティブ領域へ黙って消える遅延である。精度 1 ns で always #0.5 clk = ~clk; と書いたクロックは 1 ns ではなく 2 ns のクロックになり、周波数が合わないと気づくまで誰も見落とす。

4.3 The display family: $display, $write, $strobe, $monitor4.3 顯示家族：$display、$write、$strobe、$monitor4.3 表示系の四つ：$display、$write、$strobe、$monitor

Four tasks print formatted text, and the differences between them are almost entirely about when in the event queue they run.有四個任務會印出格式化文字，而它們之間的差異幾乎完全在於它們在事件佇列的哪個時機執行。書式つきテキストを表示するタスクは四つあり、その違いはほぼすべて、イベントキューのどの時点で実行されるかにある。

The $display-versus-$strobe distinction is not academic. Consider a flip-flop model and a print placed just after it:$display 與 $strobe 的區別並非只是學術問題。考慮一個正反器模型，以及緊接在它後面的一次列印：$display と $strobe の違いは机上の話ではない。フリップフロップのモデルと、その直後に置かれた表示を考えてみる。

always @(posedge clk) begin
  q <= d;
  $display("display: t=%0t q=%b", $time, q);   // prints the OLD q
  $strobe ("strobe : t=%0t q=%b", $time, q);   // prints the NEW q
end

$display executes in the active region, where the NBA write to q has been scheduled but not performed, so it sees the previous value. $strobe is deferred to the monitor region, after the NBA region has been drained, so it sees the updated value. Students chasing an “off by one cycle” print are usually looking at this and not at a design bug.$display 在 active 區域執行，那時對 q 的 NBA 寫入已排入但尚未執行，所以它看到的是前一個值。$strobe 則被推遲到 monitor 區域，在 NBA 區域排乾之後，所以它看到的是更新後的值。學生在追一個「差一個週期」的列印時，通常看到的是這件事，而不是設計上的臭蟲。$display はアクティブ領域で実行され、その時点で q への NBA 書き込みは予約済みだが実行されていないので、前の値を見る。$strobe は NBA 領域が空になった後のモニタ領域に遅延されるので、更新後の値を見る。「1 サイクルずれた」表示を追っている学生が見ているのはたいていこれであって、設計のバグではない。

Key facts about $monitor specifically, all of which are examinable:關於 $monitor 的幾個關鍵事實，每一條都會考：$monitor に固有の重要な事実を挙げる。いずれも試験に出る。

• There is only one. A second $monitor call replaces the first; it does not add a second trace. If you need several, build one call with all the signals, or use $strobe inside an always block.它只有一個。第二次呼叫 $monitor 會取代第一次，而不是加上第二條追蹤。如果你需要好幾條，就把所有訊號寫進同一次呼叫，或是在 always 區塊裡用 $strobe。一つしか存在しない。二度目の $monitor 呼び出しは一つ目を置き換えるのであって、二本目のトレースを追加するのではない。複数必要なら、すべての信号を一つの呼び出しにまとめるか、always ブロックの中で $strobe を使う。
• It prints immediately when first invoked, which is why the slide’s printout begins with a line at $t = 0$ showing all four signals as x.第一次被呼叫時會立刻印出，這就是為什麼投影片的輸出以 $t = 0$ 的一行開頭，顯示四個訊號全是 x。最初に呼ばれた時点で直ちに表示する。スライドの出力が $t = 0$ の行で始まり、四つの信号がすべて x になっているのはこのためである。
• It does not trigger on $time. Simulation time changes constantly; if $time counted as an argument, the monitor would fire at every time step. The standard explicitly excludes $time, $stime and $realtime from the trigger set — they are printed but not watched.它不會被 $time 觸發。模擬時間時時刻刻在變；如果 $time 也算引數，監看就會在每個時間步觸發。標準明確把 $time、$stime 與 $realtime 排除在觸發集合之外 —— 它們會被印出，但不被監看。$time ではトリガされない。シミュレーション時刻は絶えず変化する。$time が引数として数えられるなら、モニタは毎タイムステップで発火してしまう。標準は $time、$stime、$realtime をトリガ集合から明示的に除外している。これらは表示されるが監視されない。
• It fires once per time step, in the monitor region, no matter how many of its arguments changed or how many delta cycles occurred. You therefore never see intermediate values.每個時間步只觸發一次，在 monitor 區域，無論有幾個引數變化、或經過了幾個 delta 週期。因此你永遠看不到中間值。1 タイムステップにつき一度だけ、モニタ領域で発火する。引数がいくつ変化しようと、デルタサイクルがいくつあろうと変わらない。したがって途中の値を見ることは決してない。
• $monitoroff / $monitoron suspend and resume it — useful to silence the trace during a long reset sequence.$monitoroff / $monitoron 可以暫停與恢復它 —— 在冗長的重置序列期間讓追蹤安靜下來時很有用。$monitoroff / $monitoron で一時停止と再開ができる。長いリセットシーケンスの間トレースを黙らせるのに便利である。

Format specifiers are C-like: %b binary, %d decimal, %h hex, %o octal, %c character, %s string, %e %f %g real, %m the hierarchical name of the current scope, %t time. Prefixing with 0 — %0d, %0t, %0b — suppresses the default field width, which is otherwise sized for the widest possible value and produces columns of leading spaces.格式指定子沿用 C 的寫法：%b 二進位、%d 十進位、%h 十六進位、%o 八進位、%c 字元、%s 字串、%e %f %g 實數、%m 目前範圍的階層式名稱、%t 時間。在前面加 0 —— %0d、%0t、%0b —— 可以關掉預設欄寬，否則欄寬會依最寬可能值決定，印出一整排前導空白。書式指定子は C 風である。%b 二進、%d 十進、%h 十六進、%o 八進、%c 文字、%s 文字列、%e %f %g 実数、%m 現在スコープの階層名、%t 時刻。前に 0 を付けると —— %0d、%0t、%0b —— 既定のフィールド幅が抑制される。付けなければ幅は最大値に合わせて取られ、先頭に空白の列が並ぶ。

4.4 $time, $stop and $finish4.4 $time、$stop 與 $finish4.4 $time・$stop・$finish

Three time functions exist and they differ in ways that matter:有三個時間函數，而它們的差異很要緊：時刻に関する関数は三つあり、その違いは重要である。

Because the scaling is per-module, the same instant prints as different numbers in two modules with different `timescale directives. That is not a bug, and it is a good reason to use one timescale everywhere.因為縮放是以模組為單位的，同一個瞬間在兩個 `timescale 不同的模組中會印出不同的數字。這不是臭蟲，而且它是「整個設計統一用一種 timescale」的好理由。スケーリングがモジュールごとであるため、同じ瞬間でも `timescale の異なる二つのモジュールでは別の数値として表示される。これはバグではないが、全体で単一の timescale を使うべき十分な理由である。

Ending a run:結束一次模擬：実行の終わらせ方：

• $finish terminates the simulation and returns control to the operating system. It takes an optional diagnostic level: 0 prints nothing, 1 (the default) prints the simulation time and location, 2 adds CPU-time and memory statistics.$finish 終止模擬並把控制權交還作業系統。它接受一個選用的診斷層級：0 什麼都不印，1（預設）印出模擬時間與位置，2 再加上 CPU 時間與記憶體統計。$finish はシミュレーションを終了し、制御をオペレーティングシステムに返す。省略可能な診断レベルを取る。0 は何も表示せず、1（既定）はシミュレーション時刻と位置を表示し、2 はさらに CPU 時間とメモリの統計を加える。
• $stop suspends the simulation and drops into the simulator’s interactive prompt, leaving the full state alive for inspection. In the slide’s testbench the comment “Enter . to proceed” refers to the old Verilog-XL interactive command for continuing. In a batch regression $stop is a menace — it hangs the job waiting for a keystroke nobody will type — so most groups ban it from checked-in code and use it only while debugging at a terminal.$stop 暫停模擬並落到模擬器的互動提示符，讓完整狀態留著可供檢視。投影片測試平台裡的註解「Enter . to proceed」指的是舊 Verilog-XL 用來繼續執行的互動指令。在批次回歸測試中 $stop 是個禍害 —— 它會讓工作卡住，等一個沒有人會敲的按鍵 —— 所以多數團隊禁止它出現在簽入的程式碼裡，只在終端機前除錯時使用。$stop はシミュレーションを中断してシミュレータの対話プロンプトに落ち、状態をすべて生かしたまま調べられるようにする。スライドのテストベンチにある「Enter . to proceed」というコメントは、実行を継続するための古い Verilog-XL の対話コマンドを指している。バッチのリグレッションでは $stop は災いである —— 誰も打たないキー入力を待ってジョブを止めてしまう —— ので、多くのグループはチェックインするコードでの使用を禁じ、端末でデバッグするときだけ使う。

4.5 $dumpvars and the VCD file4.5 $dumpvars 與 VCD 檔4.5 $dumpvars と VCD ファイル

Text output tells you what happened; a waveform shows you when, which is what you actually need for a timing bug. The standard, tool-independent mechanism is the Value Change Dump, a plain-text file that records the initial value of every selected signal and then every subsequent change. Two tasks create it:文字輸出告訴你發生了什麼；波形則顯示何時發生，而後者才是抓時序臭蟲真正需要的。標準且與工具無關的機制是 Value Change Dump（值變化傾印），一個純文字檔，記錄每個被選中訊號的初值，以及之後的每一次變化。有兩個任務負責產生它：テキスト出力は何が起きたかを教え、波形はいつ起きたかを見せる。タイミングのバグに本当に必要なのは後者である。標準的でツール非依存の仕組みが Value Change Dump であり、選択した各信号の初期値と、その後のすべての変化を記録するプレーンテキストファイルである。これを作るタスクは二つある。

initial begin
  $dumpfile("wave.vcd");       // name the file; call this FIRST, once
  $dumpvars(0, test_Nand_Latch_1);   // what to record
end

The first argument of $dumpvars is a depth, and its encoding is the part everyone misremembers:$dumpvars 的第一個引數是深度，而它的編碼方式正是大家都會記錯的部分：$dumpvars の第一引数は深さであり、その符号化こそ誰もが覚え違いをする部分である。

Companion tasks: $dumpoff and $dumpon suspend and resume recording, $dumpall forces a checkpoint of every value, $dumplimit(n) caps the file at n bytes, and $dumpflush forces buffered data to disk so the file is readable even if the simulation later crashes. All of them are not synthesisable, like everything else in this section.相關的配套任務：$dumpoff 與 $dumpon 暫停與恢復記錄，$dumpall 強制把每個值做一次檢查點，$dumplimit(n) 把檔案上限壓在 n 位元組，$dumpflush 強制把緩衝資料寫入磁碟，讓模擬之後就算崩潰檔案仍然讀得出來。它們全都not synthesisable，跟本節其他東西一樣。関連タスク：$dumpoff と $dumpon は記録の一時停止と再開、$dumpall はすべての値のチェックポイントを強制、$dumplimit(n) はファイルを n バイトで打ち切り、$dumpflush はバッファのデータをディスクへ書き出して、後でシミュレーションがクラッシュしてもファイルを読めるようにする。いずれも本節の他のものと同じくnot synthesisableである。

4.6 The NAND latch, traced to the last event4.6 NAND 閂鎖，追到最後一個事件4.6 NAND ラッチを最後のイベントまで追う

The slide’s worked example is an SR latch built from two cross-coupled NAND gates, each with one unit of delay:投影片的實作演練是一個由兩個交叉耦合 NAND 閘搭成的 SR 閂鎖，每個閘都有一個單位的延遲：スライドの計算例は、遅延 1 単位の NAND ゲート二つを交差結合して作った SR ラッチである。

module Nand_Latch_1 (q, qbar, preset, clear);
  output q, qbar;
  input  preset, clear;

  nand #1 G1 (q,    preset, qbar),
          G2 (qbar, clear,  q);
endmodule

Both inputs are active low: driving preset to 0 forces q high, driving clear to 0 forces qbar high, and holding both at 1 makes the pair hold its state. Driving both to 0 simultaneously is the forbidden input, since it drives both outputs to 1 and the subsequent behaviour depends on which input is released first.兩個輸入都是低電位有效：把 preset 驅動到 0 會強制 q 為高，把 clear 驅動到 0 會強制 qbar 為高，而把兩者都維持在 1 則讓這對閘保持狀態。同時把兩者都驅動到 0 是禁止輸入，因為那會把兩個輸出都驅到 1，而後續行為取決於哪一個輸入先被釋放。どちらの入力もローアクティブである。preset を 0 に駆動すると q がハイに強制され、clear を 0 に駆動すると qbar がハイに強制され、両方を 1 に保てばこの対は状態を保持する。両方を同時に 0 に駆動するのは禁止入力である。両出力が 1 になり、その後の振る舞いがどちらの入力を先に解放するかに依存するからだ。

Note also a subtlety in the stimulus. The line #10 preset = 0; clear = 1; contains two statements. The #10 delays only the first; the assignment to clear then executes with no further delay, in the same time slot. Both changes therefore land at $t = 10$. This is the single most common misreading of the slide’s testbench.激勵裡還有一個細節要注意。#10 preset = 0; clear = 1; 這一行包含兩條敘述。#10 只延遲第一條；對 clear 的指定接著在沒有額外延遲的情況下執行，落在同一個時間槽。因此兩個變化都發生在 $t = 10$。這是對投影片測試平台最常見的誤讀。刺激にはもう一つ細かい点がある。#10 preset = 0; clear = 1; という行には文が二つある。#10 が遅らせるのは最初の文だけで、clear への代入はさらなる遅延なしに同じタイムスロットで実行される。したがって両方の変化が $t = 10$ に起きる。スライドのテストベンチで最もよくある読み違いがこれである。

Now apply the inertial-delay bookkeeping of §3.3 one time stamp at a time. Remember the NAND identity that does all the work: any 0 input forces the output to 1, regardless of the other input, even if the other input is x. That is what lets the latch escape from the all-unknown start-up state.現在一次一個時間戳地套用 §3.3 的慣性延遲記帳法。記住那個撐起一切的 NAND 恆等式：任何一個輸入為 0，就把輸出強制為 1，與另一個輸入無關，就算另一個輸入是 x 也一樣。正是它讓閂鎖得以逃離全未知的開機狀態。ここで §3.3 の慣性遅延の帳簿付けを、タイムスタンプごとに一つずつ適用する。すべてを支える NAND の恒等式を覚えておくこと。入力のどれか一つが 0 なら、他方の入力が何であれ、たとえ x であっても、出力は 1 に強制される。ラッチが全不定の起動状態から脱出できるのはこれのおかげである。

Two lessons live in that one-unit gap. First, a cross-coupled latch is not instantaneous: the second output always follows the first by a gate delay, and during that window q and qbar are not complementary. Any logic that samples both and assumes they disagree will see an illegal state. Second, the x at start-up is cleared not by an initial block but by asserting an active-low input — which is exactly what reset does in a real chip, and exactly why every synchronous design in this course has one.那一個單位的落差裡藏著兩個教訓。第一，交叉耦合的閂鎖不是瞬時的：第二個輸出永遠比第一個晚一個閘延遲，而在那段窗口內 q 與 qbar 並不互補。任何同時取樣兩者、又假設它們必然相異的邏輯，都會看到非法狀態。第二，開機時的 x 不是靠 initial 區塊清掉的，而是靠致能一個低電位有效輸入 —— 那正是真實晶片裡重置所做的事，也正是本課程中每個同步設計都有重置的原因。その 1 単位のずれには教訓が二つある。第一に、交差結合ラッチは瞬時ではない。二つ目の出力は常に一つ目よりゲート遅延 1 個分遅れ、その窓の間 q と qbar は相補ではない。両方をサンプルして必ず食い違うと仮定している論理は、不正な状態を見ることになる。第二に、起動時の x は initial ブロックではなく、ローアクティブ入力をアサートすることで消える。それはまさに実チップでリセットが行うことであり、本講義のすべての同期設計にリセットがある理由でもある。

4.7 Clock generation and self-checking4.7 時脈產生與自我檢查4.7 クロック生成と自己チェック

Almost every testbench you write after this lecture needs a clock. The idiom, and the trap:本講之後你寫的幾乎每一個測試平台都需要時脈。寫法與陷阱如下：本講以降に書くテストベンチはほぼすべてクロックを必要とする。定石と罠を示す。

reg clk;
always #5 clk = ~clk;

// clk starts at x.
// ~x is x. It stays x
// for the whole run, and
// every posedge never
// happens.

reg clk;
initial clk = 1'b0;
always #5 clk = ~clk;

// or, in one block:
// initial begin
//   clk = 0;
//   forever #5 clk = ~clk;
// end

The failure mode of the left-hand version is characteristic and worth recognising instantly: the waveform viewer shows clk as a solid red or hatched band, every flip-flop output is x, and the whole design is dark. Whenever an entire design is x from time zero, suspect an uninitialised reg that is being inverted or incremented, because x is a fixed point of both operations.左邊版本的失效模式很有特徵，值得一眼認出：波形檢視器把 clk 顯示成一條實心紅色或斜線的帶子，每個正反器輸出都是 x，整個設計一片黑。每當整個設計從時刻零開始就是 x，就懷疑是某個沒初始化的 reg 正被取反或遞增，因為 x 是這兩種運算的不動點。左側の版の壊れ方は特徴的で、即座に見分けられるようにしておく価値がある。波形ビューアでは clk が赤一色か斜線の帯として表示され、すべてのフリップフロップ出力が x になり、設計全体が真っ暗になる。設計全体が時刻ゼロから x のときは、初期化されていない reg が反転または加算されているのを疑うこと。x はどちらの演算の不動点でもあるからだ。

A self-checking skeleton, which is what you should be writing by the end of this course:一個自我檢查的骨架，也就是你在本課程結束時應該寫得出來的樣子：自己チェック型の骨組み。本講義を終えるころには、これを書けるようになっているべきである。

integer errors = 0;

task check;
  input [7:0] got, exp;
  begin
    if (got !== exp) begin                 // note !== , not != : see 8.5
      $display("ERROR at %0t: got %h expected %h", $time, got, exp);
      errors = errors + 1;
    end
  end
endtask

initial begin
  // ... stimulus and checks ...
  if (errors == 0) $display("PASS: no mismatches");
  else             $display("FAIL: %0d mismatches", errors);
  $finish;
end

The !== rather than != is deliberate and is the single most important detail in that fragment. With !=, a DUT output of 8'hxx compared against an expected 8'h3c yields x, which an if treats as false — so the check silently passes on a completely broken output. !== compares x literally and returns a hard 1, so the mismatch is caught. Every checker in a real testbench uses the four-state comparison operators; §8.5 explains why.用 !== 而不是 != 是刻意的，而且是那段程式碼中最重要的一個細節。用 != 時，DUT 輸出 8'hxx 與期待值 8'h3c 相比會得到 x，而 if 會把它當成假 —— 於是在輸出完全壞掉的情況下，檢查無聲地通過了。!== 會照字面比較 x 並回傳確實的 1，所以不符會被抓到。真實測試平台裡的每一個檢查器都用四值比較運算子；§8.5 會說明原因。!= ではなく !== を使うのは意図的であり、この断片で最も重要な一点である。!= では、DUT 出力 8'hxx を期待値 8'h3c と比べると結果は x になり、if はそれを偽として扱う。つまり出力が完全に壊れているのにチェックが黙って通る。!== は x を文字どおり比較して確かな 1 を返すので、不一致が捕まる。実際のテストベンチのチェッカはどれも四値比較演算子を使う。理由は §8.5 で説明する。

(a) module tb (input clk);  reg d;  dut u1(.clk(clk), .d(d));  ...

(b) initial begin  $monitor("a=%b", a);  $monitor("b=%b", b);  end

(c) initial begin  #10 a = 1;  #10 a = 0;  end
    always  #5 clk = ~clk;
    // no $finish anywhere

(d) wire start;  initial begin  start = 1'b0;  #20 start = 1'b1;  end

5. The Four-Value Logic System5. 四值邏輯系統5. 四値論理システム

5.1 Why four values and not two5.1 為什麼是四個值而不是兩個5.1 なぜ二値ではなく四値なのか

Verilog nets and variables take one of four values: 0, 1, x and z. Boolean algebra needs only two; the other two exist because a simulator has to model situations that Boolean algebra has no vocabulary for.Verilog 的連線與變數可以取四個值之一：0、1、x 與 z。布林代數只需要兩個；另外兩個之所以存在，是因為模擬器必須模擬一些布林代數根本沒有詞彙可以描述的情況。Verilog のネットと変数は 0、1、x、z の四値のいずれかを取る。ブール代数に必要なのは二つだけだ。残り二つが存在するのは、シミュレータがブール代数に語彙を持たない状況までモデル化しなければならないからである。

The distinction between x and z trips people up because both are “not 0 or 1”. They are not alike. z is a known physical state — the node is floating, and that is a definite, deliberate and often correct condition. x is an admission of ignorance: the simulator is telling you it does not know, and it is almost always a symptom. A floating node that is then read by an ordinary gate becomes x, because a real CMOS input presented with a floating wire produces an output nobody can predict.x 與 z 的區別常讓人絆倒，因為兩者都是「不是 0 也不是 1」。它們其實不像。z 是一個已知的物理狀態 —— 節點處於浮接，而那是明確的、刻意的，而且常常是正確的狀況。x 則是承認無知：模擬器在告訴你它不知道，而這幾乎永遠是一個症狀。一個浮接節點若被普通的閘讀取，會變成 x，因為真實 CMOS 輸入接上浮接導線時，產生的輸出誰也預測不了。x と z の区別は、どちらも「0 でも 1 でもない」ために人をつまずかせる。両者は似ていない。z は既知の物理状態であり、ノードが浮いているという明確で意図的な、しばしば正しい状態である。x は無知の告白である。シミュレータが分からないと告げているのであり、ほぼ常に何らかの症状である。浮いたノードを通常のゲートが読めば x になる。実際の CMOS 入力に浮いた配線をつなげば、出力は誰にも予測できないからだ。

5.2 Truth tables for the primitives5.2 基本元件的真值表5.2 プリミティブの真理値表

The deck shows the AND table; here are all the ones you need. The pattern to learn rather than memorise is controlling values dominate: a 0 on an AND forces 0 whatever the other input is, a 1 on an OR forces 1, and only when no input is controlling does the unknown leak through.投影片給了 AND 的表；這裡把你需要的全都列出來。要學的是模式而不是死背：控制值會壓過一切 —— AND 上的 0 不管另一個輸入是什麼都強制為 0，OR 上的 1 強制為 1，只有在沒有任何輸入是控制值時，未知才會滲透出去。スライドには AND の表がある。ここでは必要なものをすべて挙げる。丸暗記ではなく覚えるべきパターンは支配値が優先することだ。AND の 0 は他方の入力が何であれ出力を 0 に強制し、OR の 1 は 1 に強制する。どの入力も支配値でないときにだけ、不定が漏れ出る。

XOR has no controlling value at all — the result depends on both inputs — so any x or z on either input makes the output x. Parity trees therefore turn a single unknown bit into a completely unknown result, which is why a lone uninitialised bit in a CRC generator blackens the whole checksum.XOR 根本沒有控制值 —— 結果取決於兩個輸入 —— 所以任一輸入上的 x 或 z 都會讓輸出變成 x。因此同位元樹會把單一個未知位元變成完全未知的結果，這也是為什麼 CRC 產生器裡孤零零一個未初始化的位元，就能把整個檢查碼都塗黑。XOR には支配値がまったく無く、結果は両方の入力に依存するので、どちらかの入力の x や z は出力を x にする。したがってパリティツリーは単一の不定ビットを完全に不定な結果へ変える。CRC 生成器の中のたった一つの未初期化ビットが、チェックサム全体を黒く塗りつぶす理由である。

The NAND case in §4.6 is worth restating because it is the reason the latch starts up at all: nand(0, x) is 1, not x. The 0 is controlling for the AND part, forcing 0, and the inversion makes it 1 — the unknown input never gets a vote.§4.6 的 NAND 情形值得重述一次，因為它正是閂鎖之所以能開機的原因：nand(0, x) 是 1，不是 x。那個 0 對 AND 的部分是控制值，強制為 0，再經反相變成 1 —— 未知的那個輸入根本沒有投票權。§4.6 の NAND の場合は繰り返す価値がある。ラッチがそもそも起動できる理由だからだ。nand(0, x) は x ではなく 1 である。0 は AND 部分にとって支配値で出力を 0 に強制し、反転して 1 になる。不定の入力には投票権が無い。

5.3 Net resolution: what happens with several drivers5.3 連線解析：多個驅動源時會發生什麼5.3 ネットの解決：複数のドライバがあるとき

The tables above describe a gate. A different set of tables describes what happens when two or more drivers fight over the same net. The net’s declared type chooses the resolution function, which is the real reason Verilog has more than one net type.上面那些表描述的是一個閘。另外一組表則描述兩個以上的驅動源爭奪同一條連線時會發生什麼。連線宣告的型別決定了採用哪個解析函數，而這才是 Verilog 擁有不只一種連線型別的真正理由。上の表が記述しているのはゲートである。二つ以上のドライバが同じネットを取り合うときに何が起きるかは、別の一組の表が記述する。ネットの宣言された型が解決関数を選び、これこそ Verilog にネット型が複数ある本当の理由である。

This is why an unexpected x on a bus is nearly always a multiple-driver bug. Two always blocks assigning the same net, a tri-state bus with two enables accidentally asserted together, or a module output accidentally connected to another module output: all produce x on a plain wire, and the x then spreads downstream through §5.2’s tables until half the design is dark.這就是為什麼匯流排上出現意料之外的 x，幾乎一定是多驅動源的臭蟲。兩個 always 區塊指定同一條連線、三態匯流排上兩個致能不小心同時拉起、或是一個模組輸出不小心接到另一個模組輸出：在單純的 wire 上全都會產生 x，而那個 x 接著循著 §5.2 的表往下游擴散，直到半個設計一片黑。バス上に予期しない x が出たら、ほぼ必ず多重ドライバのバグである。二つの always ブロックが同じネットに代入している、トライステートバスで二つのイネーブルがうっかり同時にアサートされている、あるいはモジュール出力が別のモジュール出力につながっている。素の wire ではいずれも x を生み、その x が §5.2 の表に従って下流へ広がり、設計の半分が真っ暗になる。

5.4 Strengths, briefly5.4 驅動強度，簡述5.4 駆動強度について手短に

Verilog actually tracks more than four values internally: each of 0 and 1 carries one of eight drive strengths (supply, strong, pull, large, weak, medium, small, highz), giving 120 distinct states. The resolution tables above are the special case in which every driver is strong, which is what gate primitives and continuous assignments produce by default.Verilog 內部實際追蹤的值不只四個：0 與 1 各自帶有八種驅動強度之一（supply、strong、pull、large、weak、medium、small、highz），總共給出 120 個相異狀態。上面那些解析表是每個驅動源都是 strong 的特例，而那正是閘基本元件與連續指定預設產生的強度。Verilog が内部で追跡している値は実は四つより多い。0 と 1 はそれぞれ八段階の駆動強度（supply、strong、pull、large、weak、medium、small、highz）のいずれかを帯びており、合わせて 120 の異なる状態になる。上の解決表は、すべてのドライバが strong である特別な場合であり、それがゲートプリミティブと連続代入が既定で生成する強度である。

Strengths matter for switch-level and mixed-signal modelling — a pullup on an open-drain bus is pull1, so a strong0 from an active driver overrides it and the node reads 0 without becoming x. For RTL and cell-based design you will almost never write a strength specification, and synthesis ignores them. Know that they exist, recognise supply0 and supply1 (nets permanently tied to ground and supply, used for tie cells and for the power pins of library models), and move on.強度在開關層級與混合訊號建模時才重要 —— 開汲極匯流排上的 pullup 是 pull1，所以作用中驅動源送出的 strong0 會蓋過它，節點讀起來是 0 而不會變成 x。對 RTL 與 cell-based 設計而言，你幾乎永遠不會去寫強度規格，合成也會忽略它們。知道它們存在、認得 supply0 與 supply1（永久接到地與電源的連線，用於 tie cell 與元件庫模型的電源腳），然後就往下走。強度が意味を持つのはスイッチレベルやミックスドシグナルのモデル化のときである。オープンドレインバス上の pullup は pull1 なので、アクティブなドライバの strong0 がそれを上書きし、ノードは x にならずに 0 と読める。RTL やセルベース設計で強度指定を書くことはまず無く、合成もそれを無視する。存在することを知り、supply0 と supply1（グラウンドと電源に恒久的に接続されたネットで、タイセルやライブラリモデルの電源ピンに使う）を見分けられれば十分である。

5.5 x-optimism and x-pessimism5.5 x 樂觀與 x 悲觀5.5 x 楽観性と x 悲観性

Four-value simulation is an approximation of reality, and it is wrong in both directions. Knowing which way it is wrong in a given construct is what separates a debugger from someone who stares at a waveform.四值模擬是對現實的一個近似，而且它在兩個方向上都會出錯。知道某個語法結構是往哪個方向錯，正是除錯者與只會盯著波形發呆的人之間的差別。四値シミュレーションは現実の近似であり、しかも両方向に誤る。ある構文でどちら向きに誤るかを知っていることが、デバッグできる人と波形を眺めるだけの人を分ける。

x-pessimism is the four-value system reporting x when the real circuit has a definite value. Example: assign y = sel ? a : a; with sel = x. A real multiplexer outputs a whichever way it is steered, but the bitwise merge rule of §8.8 compares a with a bit by bit and yields a — in this case the model is right. Change it to y = sel ? 1'b1 : 1'b1 and it still gives 1. But (a & ~x) | (a & x) written out as gates gives x, because the simulator evaluates each gate independently and cannot see that the two unknowns are the same unknown. This is the structural reason gate-level simulation is more pessimistic than RTL: reconvergent unknowns are treated as independent.x 悲觀（x-pessimism）是指真實電路有確定值時，四值系統卻回報 x。例子：assign y = sel ? a : a; 且 sel = x。真實的多工器無論被導向哪一邊都輸出 a，而 §8.8 的逐位元合併規則會把 a 與 a 一位一位比較，得到 a —— 在這個情況下模型是對的。把它改成 y = sel ? 1'b1 : 1'b1 仍然得到 1。但把 (a & ~x) | (a & x) 攤成閘來寫就會得到 x，因為模擬器是獨立求值每個閘的，看不出那兩個未知其實是同一個未知。這就是閘級模擬比 RTL 更悲觀的結構性理由：重新匯合的未知被當成互相獨立。x 悲観性（x-pessimism）とは、実回路には確定値があるのに四値システムが x を報告することである。例：sel = x のもとでの assign y = sel ? a : a;。実際のマルチプレクサはどちらに切り替わっても a を出力し、§8.8 のビットごとのマージ規則は a と a をビット単位で比較して a を返す。この場合モデルは正しい。y = sel ? 1'b1 : 1'b1 に変えてもやはり 1 を返す。しかし (a & ~x) | (a & x) をゲートに展開して書くと x になる。シミュレータは各ゲートを独立に評価するので、二つの不定が同じ不定であることを見抜けないからだ。これがゲートレベルシミュレーションが RTL より悲観的になる構造的な理由である。再収束する不定が互いに独立として扱われる。

x-optimism is the opposite and is far more dangerous: the model produces a clean 0 or 1 where the real circuit is genuinely unpredictable. The classic source is a behavioural if or case:x 樂觀（x-optimism）則相反，而且危險得多：真實電路確實不可預測，模型卻給出乾淨的 0 或 1。最典型的來源是行為式的 if 或 case：x 楽観性（x-optimism）はその逆で、はるかに危険である。実回路は本当に予測不能なのに、モデルはきれいな 0 か 1 を出す。典型的な発生源は振る舞い記述の if や case である。

always @(*) if (sel) y = a; else y = b;   // sel = x  ==>  takes the ELSE branch,
                                          // y = b, a confident and wrong answer

An if treats x as false, so the unknown is laundered into a definite result and the x stops propagating. The design appears to work in RTL simulation; the equivalent gate-level netlist, which propagates the x faithfully, then fails, and the two simulations disagree. This mismatch is a routine cause of “RTL passes, gates fail” tickets. The remedy is discipline: initialise properly, reset everything, and never let a selector be x in the first place. Lecture 5 adds full_case/parallel_case and the synthesis-side consequences.if 把 x 當成假，於是未知被漂白成一個確定結果，x 的傳播就此中止。設計在 RTL 模擬中看起來能動；而忠實傳播 x 的等價閘級網表卻會失敗，兩個模擬結果不一致。這種不匹配是「RTL 過、閘級掛」這類工單的常見成因。解方是紀律：好好初始化、把每個東西都重置，而且一開始就別讓選擇訊號變成 x。Lecture 5 會補上 full_case/parallel_case 以及合成端的後果。if は x を偽として扱うので、不定は確定した結果へと漂白され、x の伝播はそこで止まる。設計は RTL シミュレーションでは動くように見えるが、x を忠実に伝播する等価なゲートレベルネットリストは失敗し、二つのシミュレーションが食い違う。この不一致は「RTL は通るのにゲートで落ちる」という報告の定番の原因である。対処は規律である。きちんと初期化し、すべてをリセットし、そもそもセレクタを x にしないこと。Lecture 5 では full_case/parallel_case と合成側への影響が加わる。

6. Nets, Registers and Memories6. 連線、暫存器與記憶體6. ネット・レジスタ・メモリ

6.1 Nets versus registers6.1 連線 vs 暫存器6.1 ネットとレジスタ

Verilog has two families of declarable object and the distinction is the most consequential piece of syntax in the language. The slide puts it in one line each — nets: structural connectivity; registers: abstraction of storage — and then adds the warning that matters: may or may not be physical storage.Verilog 有兩大類可宣告的物件，而這個區別是整個語言中後果最重大的一項語法。投影片各用一行帶過 —— net：結構性連接；register：儲存的抽象 —— 然後加上那句真正要緊的警告：可能是、也可能不是實體儲存元件。Verilog には宣言できるオブジェクトが二系統あり、この区別は言語中で最も影響の大きい構文である。スライドはそれぞれ一行で済ませている —— ネット：構造的な接続、レジスタ：記憶の抽象 —— そして肝心の注意書きを添える。物理的な記憶素子であることも、そうでないこともある。

Both families are informally called signals, and both may be scalar (one bit) or vector (a declared range).這兩類都被非正式地稱為訊號（signal），而且都可以是純量（一個位元）或向量（有宣告範圍）。この二系統はどちらも非公式に信号（signal）と呼ばれ、どちらもスカラ（1 ビット）にもベクタ（範囲を宣言したもの）にもなれる。

6.2 Port connection rules6.2 埠連接規則6.2 ポート接続の規則

The table on slide 15 is short and entirely mechanical, but it explains the shape of every testbench you will write.第 15 頁投影片上的表很短，而且完全是機械性的，但它解釋了你將寫出的每一個測試平台的形狀。スライド 15 枚目の表は短く、まったく機械的だが、これから書くすべてのテストベンチの形を説明している。

The underlying principle is a single sentence: a port is a continuous connection, and a continuous connection can only drive a net. An input port is driven from outside, so inside it must be a net. An output port drives the outside, so outside it must be a net. Whatever is doing the driving on the far side may be a register, because a register can perfectly well be the source of a continuous connection — it just cannot be its destination.背後的原則只有一句話：埠是一種持續的連接，而持續的連接只能驅動 net。input 埠是從外面被驅動的，所以在裡面它必須是 net。output 埠驅動外面，所以在外面它必須是 net。至於另一側負責驅動的東西，可以是 register，因為 register 完全可以是持續連接的來源 —— 它只是不能當它的目的地。背後の原則は一文で言える。ポートは継続的な接続であり、継続的な接続はネットしか駆動できない。input ポートは外から駆動されるので、内側ではネットでなければならない。output ポートは外を駆動するので、外側ではネットでなければならない。その反対側で駆動している当のものはレジスタでよい。レジスタは継続的接続の源には何の問題も無くなれる。なれないのは行き先の方だけである。

Two direct consequences you will use constantly:兩個你會不斷用到的直接推論：絶えず使うことになる直接の帰結が二つある。

• A testbench declares DUT inputs as reg (it drives them procedurally) and DUT outputs as wire (it only watches them). The “reg in, wire out” rule from §4.1 is this table read from the parent’s side.測試平台把 DUT 輸入宣告成 reg（它以程序性方式驅動它們），把 DUT 輸出宣告成 wire（它只是看著它們）。§4.1 的「輸入 reg、輸出 wire」規則，就是從上層那一側來讀這張表。テストベンチは DUT の入力を reg と宣言し（手続き的に駆動するから）、DUT の出力を wire と宣言する（見ているだけだから）。§4.1 の「入力は reg、出力は wire」という規則は、この表を親側から読んだものである。
• Inside the DUT, an output assigned in an always block must be declared output ... ; reg ...; (or, in Verilog-2001 ANSI style, output reg ...). An output assigned by assign stays a net.在 DUT 內部，一個在 always 區塊中被指定的輸出必須宣告成 output ... ; reg ...;（或在 Verilog-2001 的 ANSI 風格中寫成 output reg ...）。由 assign 指定的輸出則維持為 net。DUT の内部では、always ブロックで代入される出力は output ... ; reg ...;（Verilog-2001 の ANSI 形式なら output reg ...）と宣言しなければならない。assign で代入される出力はネットのままである。
• A bidirectional pad is inout, net on both sides, driven by a tri-state buffer from inside — this is the only time you will write tri deliberately.雙向接腳是 inout，兩側都是 net，由內部的三態緩衝器驅動 —— 這是你唯一會刻意寫 tri 的場合。双方向パッドは inout で、両側ともネットであり、内側のトライステートバッファから駆動される。意図して tri と書くのはこのときだけである。

6.3 Scope of a variable6.3 變數的範圍6.3 変数のスコープ

The scope of a variable is the module, task, function or named begin...end block in which it is declared. Within that scope you refer to it by its bare identifier; from outside, only by a hierarchical path name (§9).變數的範圍（scope）是它被宣告所在的模組、task、function 或具名的 begin...end 區塊。在那個範圍之內，你用裸識別字指涉它；從外面則只能用階層式路徑名稱（§9）。変数のスコープは、それが宣言されたモジュール、タスク、関数、または名前付き begin...end ブロックである。そのスコープの内側では裸の識別子で参照し、外側からは階層パス名でしか参照できない（§9）。

The named-block case is the one students forget. begin : loop_body integer i; ... end gives i a scope limited to that block, which is how you get a loop counter that does not collide with one in a neighbouring block. An unnamed begin...end cannot contain declarations at all, which is why the compiler rejects a declaration dropped in the middle of a procedural block.具名區塊那一項是學生最常忘記的。begin : loop_body integer i; ... end 讓 i 的範圍侷限在該區塊內，這就是你如何得到一個不會跟鄰近區塊撞名的迴圈計數器。未具名的 begin...end 根本不能包含宣告，這也正是為什麼編譯器會拒絕被塞在程序性區塊中間的宣告。名前付きブロックの場合は学生が忘れやすい。begin : loop_body integer i; ... end と書けば i のスコープはそのブロック内に限られ、隣のブロックのものと衝突しないループカウンタが得られる。名前の無い begin...end は宣言をまったく含められない。手続きブロックの途中に置かれた宣言をコンパイラが拒否するのはこのためである。

Verilog has no block-nested scoping in the C sense and no shadowing by default: a module-level reg count and a task-level reg count are two different objects, and inside the task the inner one wins — but there is no “inner block” scope inside an if or a for unless you name it. Tasks and functions declared in a module can see the module’s variables directly, which is both convenient and a classic source of accidental shared state when a task is called from two places at once.Verilog 沒有 C 意義下的區塊巢狀範圍，預設也沒有遮蔽（shadowing）：模組層級的 reg count 與 task 層級的 reg count 是兩個不同的物件，而在 task 內部是內層那個勝出 —— 但 if 或 for 裡面並沒有「內層區塊」範圍，除非你替它命名。宣告在模組中的 task 與 function 可以直接看見該模組的變數，這既方便，也是當一個 task 同時被兩處呼叫時、意外共享狀態的經典來源。Verilog には C の意味でのブロック入れ子スコープも、既定のシャドーイングも無い。モジュールレベルの reg count とタスクレベルの reg count は別のオブジェクトで、タスク内では内側が勝つ —— しかし名前を付けない限り if や for の中に「内側のブロック」スコープは存在しない。モジュール内で宣言されたタスクと関数はそのモジュールの変数を直接見られる。これは便利であると同時に、タスクが二か所から同時に呼ばれたときの偶発的な状態共有という古典的な原因でもある。

6.4 The net types6.4 連線型別6.4 ネットの型

Declaration examples from the slides, with what each one means:取自投影片的宣告範例，以及各自的意思：スライドから取った宣言の例と、それぞれの意味。

wire        x;                 // scalar net
wand        y;                 // wired-AND scalar net
wire [15:0] data;              // 16-bit vector, bit 15 is the MSB
                               //   data[5]   : bit-select  -> 1 bit
                               //   data[5:3] : part-select -> 3 bits, MSB = bit 5
wire [0:7]  array_a;           // ASCENDING range: bit 0 is the MSB
                               //   array_a[0:3] : 4 bits, MSB = bit 0
wire [7:0]  array_2d_p [0:31]; // 32 nets, each 8 bits wide
                               //   array_2d_p[2] : an 8-bit vector
wire        a = b + c;         // net declaration + implicit continuous assign

The last form is a convenience: wire a = b + c; is exactly wire a; assign a = b + c;. It is compact and perfectly synthesisable, and it is where a net delay would go if you wanted one: wire [7:0] #5 sum = b + c; — range first, delay second.最後一種形式是便利寫法：wire a = b + c; 完全等於 wire a; assign a = b + c;。它簡潔而且完全可合成，而且如果你要給連線延遲，位置就在那裡：wire [7:0] #5 sum = b + c; —— 範圍在前，延遲在後。最後の形式は便宜的な書き方である。wire a = b + c; は wire a; assign a = b + c; とまったく同じだ。簡潔で完全に合成可能であり、ネット遅延を付けたいならその位置がここである。wire [7:0] #5 sum = b + c; —— 範囲が先、遅延が後。

6.5 Initial values and implicit nets6.5 初始值與隱含連線6.5 初期値と暗黙のネット

At $t_{sim} = 0$, before anything has been assigned:在 $t_{sim} = 0$、任何東西被指定之前：$t_{sim} = 0$ で、まだ何も代入されていない時点では：

• A net that has a driver — a primitive output, a continuous assignment, a module output port — takes whatever that driver produces. Since the driver’s own inputs are themselves unknown, this is almost always x.有驅動源的連線 —— 基本元件輸出、連續指定、模組輸出埠 —— 取到該驅動源產生的值。由於驅動源自己的輸入也還是未知，這幾乎永遠是 x。ドライバを持つネット —— プリミティブの出力、連続代入、モジュールの出力ポート —— は、そのドライバが出す値を取る。ドライバ自身の入力もまだ不定なので、これはほぼ常に x である。
• A net with no driver at all is z. Not x — nothing is driving it, which is a known condition.完全沒有驅動源的連線是 z。不是 x —— 沒有東西在驅動它，而那是一個已知的狀況。ドライバがまったく無いネットは z である。x ではない。何も駆動していないというのは既知の状態だからだ。
• A register is x.暫存器是 x。レジスタは x である。

That z-versus-x split is a genuinely useful diagnostic. If a DUT input shows as z in the waveform, the testbench forgot to connect or declare it. If it shows as x, it is connected to something that has not produced a value yet. Two different bugs, distinguished at a glance.z 與 x 的這個分界是一項真正好用的診斷。如果某個 DUT 輸入在波形上顯示為 z，就是測試平台忘了接它或忘了宣告它。如果顯示為 x，那它是接到了某個還沒產生出值的東西。兩個不同的臭蟲，一眼就能分辨。この z と x の違いは、実によく効く診断材料である。DUT の入力が波形で z と表示されるなら、テストベンチが接続か宣言を忘れている。x と表示されるなら、まだ値を出していない何かにつながっている。二つの異なるバグが一目で区別できる。

The second half of the slide is a hazard: an undeclared identifier used in a port connection or on the right-hand side of an expression is silently created as a 1-bit wire. This is a Verilog-1995 compatibility rule and it is a bug factory:投影片的後半是一個危害：在埠連接或運算式右手邊用到一個未宣告的識別字，會無聲地被建立成一條 1 位元的 wire。這是 Verilog-1995 的相容性規則，而它是個臭蟲工廠：スライドの後半は危険の話である。ポート接続や式の右辺で未宣言の識別子を使うと、黙って 1 ビットの wire が作られる。これは Verilog-1995 との互換性規則であり、バグ製造機である。

wire [7:0] data_bus;
dut u1 (.d(data_buss));   // typo: creates a 1-bit implicit wire, no error,
                          // the real bus is never connected, d reads z

Symptom: the DUT input sits at z or shows only one meaningful bit, with no warning anywhere. The cure is one line at the top of every file:症狀：DUT 輸入停在 z，或只顯示出一個有意義的位元，而且到處都沒有任何警告。解方是每個檔案開頭的一行：症状：DUT の入力が z のままになるか、意味のあるビットが 1 本しか出てこない。しかもどこにも警告は出ない。対策はどのファイルの先頭にも置く一行である。

`default_nettype none      // now every net must be declared explicitly
// ... your modules ...
`default_nettype wire      // restore before including third-party code

Turning this on converts a class of silent wrong-behaviour bugs into compile errors. Note the restore at the end: the directive is global and persists across file boundaries, so leaving it set to none will break any library file that relies on implicit nets.打開它，就能把一整類無聲的錯誤行為臭蟲轉成編譯錯誤。注意結尾的還原：這個指示子是全域的，而且會跨檔案持續生效，所以把它留在 none 狀態會弄壞任何依賴隱含連線的函式庫檔案。これを有効にすると、黙って挙動を誤らせる一群のバグがコンパイルエラーに変わる。末尾で元に戻していることに注意せよ。この指示子はグローバルでファイル境界を越えて持続するので、none のままにしておくと暗黙のネットに依存するライブラリファイルを壊してしまう。

A related note: an undeclared identifier used as a procedural assignment target is not implicitly created — it is an error, because the implicit object would be a net and a net cannot be assigned procedurally. The slide states this as “illegal within a behavior”.相關的一點：被當成程序性指定目標的未宣告識別字不會被隱含建立 —— 那是錯誤，因為隱含建立出來的物件會是 net，而 net 不能被程序性指定。投影片把這件事寫成「illegal within a behavior」。関連する注意点として、手続き代入の代入先に使われた未宣言の識別子は暗黙には作られない。これはエラーになる。暗黙に作られるオブジェクトはネットであり、ネットには手続き代入ができないからだ。スライドはこれを「illegal within a behavior」と述べている。

6.6 Register types6.6 暫存器型別6.6 レジスタの型

reg        a, b;              // two scalar regs
reg [15:0] counter;           // one 16-bit reg
reg [7:0]  shift_reg [0:15];  // SIXTEEN 8-bit regs: an array, not a 128-bit value
integer    c;                 // signed, >= 32 bits

The difference between lines 2 and 3 is the one to be sure of. reg [15:0] counter is a single object sixteen bits wide: you can add to it, shift it, pass it as a port. reg [7:0] shift_reg [0:15] is sixteen separate eight-bit objects: you can index it, and that is almost all you can do with it. §6.8 spells out the consequences.第 2 列與第 3 列的差別是必須弄清楚的。reg [15:0] counter 是一個十六位元寬的單一物件：你可以對它做加法、位移，把它當埠傳遞。reg [7:0] shift_reg [0:15] 則是十六個分開的八位元物件：你可以對它做索引，而你能做的也差不多就只有這樣。§6.8 會把後果講清楚。2 行目と 3 行目の違いは必ず押さえておくこと。reg [15:0] counter は幅 16 ビットの単一オブジェクトであり、加算もシフトもでき、ポートとして渡せる。reg [7:0] shift_reg [0:15] は 8 ビットのオブジェクト 16 個であり、添字で選べるだけで、できることはほぼそれだけである。その帰結は §6.8 で詳しく述べる。

6.7 Bit-select and part-select6.7 位元選擇與部分選擇6.7 ビット選択と部分選択

The rules, from the slide, with the reasoning:取自投影片的規則，附上理由：スライドから取った規則と、その理由。

• In a part-select v[m:n], the left index is the MSB of the result and the right index is the LSB. This holds regardless of whether the declared range is ascending or descending — but the part-select’s direction must match the declaration, so for reg [7:0] v you may write v[5:1] and not v[1:5].在部分選擇 v[m:n] 中，左索引是結果的 MSB，右索引是 LSB。無論宣告範圍是遞增或遞減都成立 —— 但部分選擇的方向必須與宣告一致，所以對 reg [7:0] v 你可以寫 v[5:1]，不能寫 v[1:5]。部分選択 v[m:n] では、左の添字が結果の MSB、右が LSB である。これは宣言された範囲が昇順でも降順でも成り立つ —— ただし部分選択の向きは宣言と一致していなければならない。reg [7:0] v に対して v[5:1] は書けるが v[1:5] は書けない。
• The indices in a part-select must be constant expressions in Verilog-1995. A variable index is legal only for a single bit-select, or via the Verilog-2001 indexed part-selects v[base +: width] and v[base -: width], whose width is constant even though the base is not. This is the construct to reach for when you want a variable byte lane out of a wide bus.在 Verilog-1995 中，部分選擇的索引必須是常數運算式。變數索引只能用於單一位元選擇，或透過 Verilog-2001 的索引式部分選擇 v[base +: width] 與 v[base -: width]，其中 width 是常數，base 則不必是。當你想從一條寬匯流排取出可變的位元組通道時，就該伸手拿這個語法。Verilog-1995 では部分選択の添字は定数式でなければならない。変数の添字が使えるのは単一ビット選択か、Verilog-2001 のインデックス付き部分選択 v[base +: width] と v[base -: width] を経由する場合だけである。後者は base が変数でも width は定数である。広いバスから可変のバイトレーンを取り出したいときに使う構文がこれだ。
• An out-of-bounds index returns x rather than raising an error, and a write to an out-of-bounds index is silently discarded.越界索引回傳 x，而不是引發錯誤；對越界索引的寫入則被無聲丟棄。範囲外の添字はエラーにならず x を返す。範囲外の添字への書き込みは黙って捨てられる。

Worked from the slide, with word[7:0] = 8'b1100_0100:依投影片演練，取 word[7:0] = 8'b1100_0100：スライドに沿って、word[7:0] = 8'b1100_0100 として計算する。

6.8 Memories6.8 記憶體6.8 メモリ

A memory in Verilog-1995 is simply an array of regs:在 Verilog-1995 中，記憶體就只是一個 reg 的陣列：Verilog-1995 におけるメモリは、単に reg の配列である。

reg [31:0] cache [0:1023];    // 1024 words of 32 bits = 1 K x 32
reg [31:0] one_word;
reg        one_bit;

one_word = cache[1022];       // read a whole word
one_bit  = one_word[31];      // then select a bit from it

Read the declaration carefully, because the two ranges mean different things and sit on different sides of the name. The range before the identifier is the word width; the range after it is the address space. reg [31:0] cache [0:1023] is a thousand-and-twenty-four-entry array of thirty-two-bit words, and reversing the two gives you a completely different object.仔細讀這個宣告，因為兩個範圍意思不同，而且分別落在名稱的兩側。識別字前面的範圍是字寬；後面的範圍是位址空間。reg [31:0] cache [0:1023] 是一個有一千零二十四個項目、每項三十二位元的陣列，而把兩者對調會得到一個完全不同的物件。この宣言は注意して読むこと。二つの範囲は意味が異なり、名前の反対側に置かれている。識別子の前の範囲は語長、後の範囲はアドレス空間である。reg [31:0] cache [0:1023] は 32 ビット語を 1024 個持つ配列であり、二つを入れ替えるとまったく別のオブジェクトになる。

The restriction the slide highlights is that individual bits of a memory cannot be addressed directly in Verilog-1995: cache[1022][31] is a syntax error, and you must copy the word into a temporary first, as above. IEEE 1364-2001 relaxed this and permits a bit-select or part-select of an array element, so cache[1022][31] and cache[1022][15:8] are legal in any modern tool. Both forms appear in real code; the two-step version is still worth knowing because it is what the slide shows and what older code does.投影片強調的限制是，在 Verilog-1995 中無法直接定址記憶體的個別位元：cache[1022][31] 是語法錯誤，你必須像上面那樣先把整個字複製到一個暫時變數。IEEE 1364-2001 放寬了這點，允許對陣列元素做位元選擇或部分選擇，所以 cache[1022][31] 與 cache[1022][15:8] 在任何現代工具上都合法。真實程式碼裡兩種寫法都看得到；兩步驟的版本仍值得知道，因為投影片就是那樣寫，舊程式碼也是那樣寫。スライドが強調する制限は、Verilog-1995 ではメモリの個々のビットを直接アドレスできないことである。cache[1022][31] は構文エラーで、上のようにいったん語を一時変数へコピーしなければならない。IEEE 1364-2001 はこれを緩め、配列要素のビット選択・部分選択を許したので、cache[1022][31] も cache[1022][15:8] も現代のツールでは合法である。実際のコードには両方の書き方が現れる。二段階の版も、スライドがそう書いており古いコードもそうしている以上、知っておく価値がある。

Other limitations that are still true in 2001 and catch people out:其他在 2001 版仍然成立、而且常坑人的限制：2001 年版でも依然として成り立ち、人をはめる他の制限。

• A memory cannot be a port. To pass one between modules you pass an address and a data word, which is what a real memory interface looks like anyway.記憶體不能當埠。要在模組之間傳遞記憶體，你得傳位址與資料字，而真實的記憶體介面本來就長這樣。メモリはポートにできない。モジュール間で受け渡すにはアドレスとデータ語を渡す。実際のメモリインタフェースはもともとそういう形である。
• A memory cannot be used as a whole in an expression: if (cache == 0) is meaningless. Only an element is an operand.記憶體不能整個當成運算式中的運算元：if (cache == 0) 毫無意義。只有單一元素才是運算元。メモリは全体を式の中で使えない。if (cache == 0) は無意味である。オペランドになれるのは要素だけである。
• You cannot assign the whole array at once. Initialise with a for loop, or with $readmemb / $readmemh, which load a text file of binary or hex values into an array and are the standard way to preload a ROM or a golden-vector table: $readmemh("golden.hex", expected); not synthesisable for ASIC, though many FPGA flows honour it for block-RAM initialisation.你無法一次指定整個陣列。請用 for 迴圈初始化，或用 $readmemb / $readmemh，它們會把一個裝著二進位或十六進位值的文字檔載進陣列，是預載 ROM 或黃金向量表的標準作法：$readmemh("golden.hex", expected); 對 ASIC 而言not synthesisable，不過許多 FPGA 流程會尊重它來做 block-RAM 的初始化。配列全体を一度に代入することはできない。for ループで初期化するか、$readmemb / $readmemh を使う。これらは二進または十六進の値を並べたテキストファイルを配列に読み込むもので、ROM やゴールデンベクタ表をプリロードする標準的な方法である。$readmemh("golden.hex", expected); ASIC ではnot synthesisableだが、多くの FPGA フローはブロック RAM の初期化のためにこれを尊重する。
• Arrays of nets are legal too (wire [7:0] bus_array [0:31];) but far rarer; the slide’s array_2d_p is an example.net 的陣列也是合法的（wire [7:0] bus_array [0:31];），但罕見得多；投影片的 array_2d_p 就是一例。ネットの配列も合法だが（wire [7:0] bus_array [0:31];）はるかに珍しい。スライドの array_2d_p がその例である。

Finally, a scale warning. A behavioural array costs the simulator a full four-valued word per entry — on the order of eight bytes per 32-bit word plus overhead. A 1 K×32 cache is trivial; a 1 G×64 main-memory model is not, and this is why testbenches for processors model memory sparsely with an associative structure rather than a dense array. For the DUT side, a memory this size would never be synthesised from reg anyway — it would be a compiled SRAM macro instantiated from the foundry memory compiler, with the behavioural array used only in the simulation model.最後是一個關於規模的警告。行為式陣列每一項都要花掉模擬器一個完整的四值字 —— 一個 32 位元字大約八個位元組再加上額外開銷。1 K×32 的快取不算什麼；1 G×64 的主記憶體模型就很可觀了，這也是為什麼處理器的測試平台會用關聯式結構稀疏地模擬記憶體，而不是用密集陣列。至於 DUT 那一側，這種規模的記憶體本來也絕不會由 reg 合成出來 —— 它會是由晶圓廠記憶體編譯器產生、再實例化進來的 SRAM 巨集，行為式陣列只用在模擬模型裡。最後に規模についての警告。振る舞いレベルの配列は、1 要素あたり完全な四値の語をシミュレータに消費させる。32 ビット語ならおよそ 8 バイトに加えてオーバーヘッドがかかる。1 K×32 のキャッシュは取るに足らないが、1 G×64 の主記憶モデルはそうではない。プロセッサのテストベンチが密な配列ではなく連想的な構造でメモリを疎にモデル化するのはこのためである。DUT 側については、この規模のメモリがそもそも reg から合成されることはない。ファウンドリのメモリコンパイラが生成した SRAM マクロをインスタンス化し、振る舞い配列はシミュレーションモデルの中だけで使う。

7. Parameters and Parameter Override7. 參數與參數覆寫7. パラメータとパラメータ・オーバーライド

7.1 Why a design has constants7.1 設計為什麼需要常數7.1 設計に定数がある理由

A parameter is a named constant whose value is fixed at elaboration — after parsing, before simulation starts — and which may be given a different value for each instance of the module that declares it.parameter 是一個具名常數，其值在展開期（elaboration）確定 —— 在剖析之後、模擬開始之前 —— 而且可以為宣告它的那個模組的每個實例給不同的值。parameter は名前付きの定数であり、その値はエラボレーション時、すなわち構文解析の後、シミュレーション開始の前に確定する。そして、それを宣言したモジュールのインスタンスごとに別の値を与えられる。

parameter size     = 16;
reg [size-1:0] a;                              // width follows the parameter
parameter num_b    = 2'b01;                    // sized constant
parameter av_delay = (min_delay + max_delay) / 2;   // computed from other parameters

The slide’s three motivations are worth expanding, because the third is the one that changes how you work:投影片列的三個動機值得展開，因為第三個會改變你的工作方式：スライドが挙げる三つの動機は展開する価値がある。三つ目は働き方そのものを変えるからだ。

• Flexible hardware: design once, reuse. A parameterised FIFO is written once and instantiated as 8×32, 16×8 and 64×128 in the same chip. Without parameters you copy the file three times, and three copies drift apart the moment one bug is fixed in only two of them.彈性的硬體：設計一次，重複使用。一個參數化的 FIFO 只寫一次，就能在同一顆晶片裡被實例化成 8×32、16×8 與 64×128。沒有參數，你就得把檔案複製三份，而三份副本在某個臭蟲只被修好其中兩份的那一刻就開始分歧。柔軟なハードウェア：一度設計して再利用する。パラメータ化された FIFO は一度書けば、同じチップの中で 8×32、16×8、64×128 としてインスタンス化できる。パラメータが無ければファイルを 3 つコピーすることになり、3 つのコピーは、あるバグが 2 つにしか修正されなかった瞬間から食い違い始める。
• Maintainability. The width of a bus appears in a dozen declarations, a dozen port connections and every loop bound. Changing one number instead of thirty is the difference between a five-minute edit and an afternoon of hunting.可維護性。一條匯流排的寬度會出現在十幾個宣告、十幾個埠連接，以及每一個迴圈邊界裡。改一個數字而不是三十個，就是五分鐘的編輯與一整個下午的搜捕之間的差別。保守性。バスの幅は十数か所の宣言、十数か所のポート接続、そしてすべてのループ境界に現れる。30 か所ではなく 1 か所の数値を変えれば済むというのは、5 分の編集と午後いっぱいの捜索の差である。
• Readability. if (state == IDLE) says something; if (state == 3'b000) says nothing. State encodings, opcode values, FIFO depths and address map boundaries should all be named.可讀性。if (state == IDLE) 說了一件事；if (state == 3'b000) 什麼也沒說。狀態編碼、opcode 值、FIFO 深度與位址對映邊界，全都應該取名字。可読性。if (state == IDLE) は何かを語るが、if (state == 3'b000) は何も語らない。状態の符号化、オペコードの値、FIFO の深さ、アドレスマップの境界は、すべて名前を付けるべきである。

Verilog-2001 added localparam, which behaves identically but cannot be overridden. Use it for anything derived rather than chosen — localparam ADDR_W = $clog2(DEPTH); — so that an override of DEPTH cannot leave ADDR_W inconsistent. Treat parameter as the module’s public interface and localparam as its private constants.Verilog-2001 加入了 localparam，行為完全相同，但不能被覆寫。凡是衍生出來、而非由人挑選的量都該用它 —— localparam ADDR_W = $clog2(DEPTH); —— 這樣覆寫 DEPTH 就不會讓 ADDR_W 變得不一致。把 parameter 當成模組的公開介面，把 localparam 當成它的私有常數。Verilog-2001 は localparam を追加した。挙動は同じだがオーバーライドできない。選ぶものではなく導かれるものにはこちらを使う —— localparam ADDR_W = $clog2(DEPTH); —— そうすれば DEPTH のオーバーライドが ADDR_W を不整合のまま残すことはない。parameter をモジュールの公開インタフェース、localparam をその私的な定数と考えるとよい。

7.2 Approach I — direct substitution with #( )7.2 作法 I —— 用 #( ) 直接替換7.2 方法 I —— #( ) による直接置換

The parameter values are supplied at the point of instantiation, in the instantiating module.參數值在實例化的位置、在實例化它的那個模組裡提供。パラメータ値は、インスタンス化する側のモジュールの、インスタンス化のその場で与える。

module modXnor (y_out, a, b);
  parameter size = 8, delay = 15;
  output [size-1:0] y_out;
  input  [size-1:0] a, b;
  wire   [size-1:0] #delay y_out = a ~^ b;    // bitwise xnor, net delay = delay
endmodule

module Param;
  wire [7:0] y1_out;
  wire [3:0] y2_out;
  reg  [7:0] b1, c1;
  reg  [3:0] b2, c2;

  modXnor         G1 (y1_out, b1, c1);   // defaults: size = 8, delay = 15
  modXnor #(4, 5) G2 (y2_out, b2, c2);   // override: size = 4, delay = 5
endmodule

Three mechanical facts about #(4, 5):關於 #(4, 5) 的三個機械性事實：#(4, 5) についての機械的な事実が三つある。

• The values are matched to parameters in declaration order, exactly like positional port connections. size is declared first, so it gets 4.這些值是依宣告順序對應到參數的，和位置式埠連接完全一樣。size 宣告在前，所以它拿到 4。値は宣言順にパラメータへ対応づけられる。位置によるポート接続とまったく同じである。size が先に宣言されているので 4 を受け取る。
• You cannot skip one. To override only the second parameter positionally you must restate the first with its default value, which means a change to that default silently stops reaching this instance.你不能跳過其中一個。要用位置式只覆寫第二個參數，你就得把第一個連同它的預設值再寫一次，這代表那個預設值日後有變動時，會無聲地傳不到這個實例。一つを飛ばすことはできない。位置指定で二つ目だけをオーバーライドするには、一つ目をその既定値のまま書き直さねばならない。つまり、その既定値が後に変わっても、このインスタンスには黙って届かなくなる。
• Supplying more values than there are parameters is an error; supplying fewer leaves the trailing ones at their defaults.給的值比參數個數多是錯誤；給得少則尾端那些維持預設值。パラメータ数より多くの値を与えるのはエラーであり、少なく与えた場合は後ろのものが既定値のまま残る。

Verilog-2001 added named parameter override, which removes both hazards and is what you should write:Verilog-2001 加入了具名參數覆寫，它消除了上述兩個危害，也是你該寫的形式：Verilog-2001 は名前付きパラメータ・オーバーライドを追加した。上の二つの危険をともに取り除くもので、書くべきはこちらである。

modXnor #(.size(4), .delay(5)) G2 (.y_out(y2_out), .a(b2), .b(c2));

Named overrides are order-independent, self-documenting, and skipping a parameter is trivial. Combined with named port connections, as above, an instantiation becomes immune to someone reordering the module’s declarations — which is worth a great deal when the module is maintained by somebody else.具名覆寫與順序無關、自我說明，而且要跳過某個參數也很容易。再如上面那樣搭配具名埠連接，實例化就對「有人重排了模組宣告順序」免疫 —— 當那個模組由別人維護時，這一點的價值非常高。名前付きオーバーライドは順序に依存せず、自己文書的であり、パラメータを飛ばすのも容易である。上のように名前付きポート接続と組み合わせれば、インスタンス化は「誰かがモジュールの宣言順を並べ替えた」ことに対して免疫を持つ。そのモジュールを他人が保守しているとき、この価値は非常に大きい。

Notice how the parameter reaches into the declarations: output [size-1:0] y_out; means the port width itself depends on the override. G1’s y_out is eight bits and G2’s is four, from the same source text. That is the whole point, and it is why parameters must be resolved at elaboration: the shape of the netlist depends on them.注意參數如何伸進宣告裡：output [size-1:0] y_out; 意味著埠寬度本身取決於覆寫值。G1 的 y_out 是八位元，G2 的是四位元，而兩者出自同一份原始碼。這正是重點所在，也是為什麼參數必須在展開期就解析完畢：網表的形狀取決於它們。パラメータが宣言の中にまで及ぶことに注目せよ。output [size-1:0] y_out; はポート幅そのものがオーバーライドに依存することを意味する。同一のソーステキストから、G1 の y_out は 8 ビット、G2 のそれは 4 ビットになる。これこそが要点であり、パラメータがエラボレーション時に解決されなければならない理由でもある。ネットリストの形がそれに依存するからだ。

7.3 Approach II — indirect substitution with defparam7.3 作法 II —— 用 defparam 間接替換7.3 方法 II —— defparam による間接置換

The alternative keeps the instantiation clean and puts the overrides somewhere else entirely, addressing each parameter by its hierarchical path name.另一種作法讓實例化保持乾淨，把覆寫完全放到別的地方，並以階層式路徑名稱指名每一個參數。もう一つの方法はインスタンス化を綺麗なまま保ち、オーバーライドをまったく別の場所に置いて、各パラメータを階層パス名で指す。

module hdref_Param;                    // a top-level module
  wire [7:0] y1_out;
  wire [3:0] y2_out;
  reg  [7:0] b1, c1;
  reg  [3:0] b2, c2;

  modXnor G1 (y1_out, b1, c1),
          G2 (y2_out, b2, c2);         // no overrides written here
endmodule

module annotate;                       // a separate annotation module
  defparam
    hdref_Param.G2.size  = 4,          // hierarchical reference name
    hdref_Param.G2.delay = 5;
endmodule

The appeal is obvious: every configuration choice for a whole design can be collected in one file, and the design source stays generic. Historically this is how timing annotation and configuration management were done before SDF and before Verilog-2001 configurations existed.它的吸引力很明顯：整個設計的每一項組態選擇都能集中在同一個檔案裡，而設計原始碼維持泛用。在歷史上，這正是 SDF 出現之前、Verilog-2001 configuration 出現之前，時序標註與組態管理的作法。魅力は明らかだ。設計全体の構成上の選択を一つのファイルに集められ、設計ソースは汎用のままでいられる。歴史的には、SDF 以前、Verilog-2001 の configuration 以前には、タイミング注釈と構成管理をこうやって行っていた。

The appeal is also a trap, and modern practice is firmly against it:但這份吸引力同時是個陷阱，現代實務堅決反對它：しかしその魅力は同時に罠でもあり、現代の実務はこれに断固として反対している。

• Synthesis tools generally reject defparam, or accept it only with restrictions. Anything you cannot synthesise cannot be in the DUT.合成工具一般會拒絕 defparam，或只在有限制的情況下接受。任何不能合成的東西都不該出現在 DUT 裡。合成ツールは一般に defparam を拒否するか、制限付きでしか受け付けない。合成できないものは DUT に入れてはならない。
• It is order-sensitive in a way nobody can see. If two defparams in different files target the same parameter, IEEE 1364 does not define which wins; the answer depends on compilation order.它以一種沒人看得見的方式對順序敏感。如果兩個不同檔案中的 defparam 指向同一個參數，IEEE 1364 並未定義誰勝出；答案取決於編譯順序。誰にも見えない形で順序に依存する。異なるファイルの二つの defparam が同じパラメータを指した場合、どちらが勝つかを IEEE 1364 は定義していない。答えはコンパイル順に依存する。
• It breaks locality. Reading the instantiation tells you nothing about the instance’s actual configuration, because the override lives in a file you may not have opened.它破壞了局部性。讀實例化那一行完全看不出這個實例實際的組態，因為覆寫住在一個你可能根本沒打開過的檔案裡。局所性を壊す。インスタンス化を読んでも、そのインスタンスの実際の構成は何も分からない。オーバーライドは開いてすらいないかもしれないファイルの中にあるからだ。
• It interacts badly with generate blocks and with any tool that flattens or replicates hierarchy, since the path name it targets may not exist after transformation.它與 generate 區塊、以及任何會攤平或複製階層的工具相處得很差，因為它指名的路徑名稱在轉換後可能已經不存在。generate ブロックや、階層を平坦化・複製するあらゆるツールとの相性が悪い。指している階層パス名が変換後には存在しないかもしれないからだ。
• It was formally deprecated in IEEE 1364-2005 and is a candidate for removal from the language.它在 IEEE 1364-2005 中被正式標記為不建議使用，而且是未來可能從語言中移除的候選。IEEE 1364-2005 で正式に非推奨とされ、言語からの削除候補になっている。

Know it, recognise it in legacy code, be able to state what it does in an exam — and write #(.name(value)) in anything you ship.認識它、能在舊程式碼裡認出它、考試時說得出它的作用 —— 然後在你要交付的東西裡一律寫 #(.name(value))。知っておき、レガシーコードの中で見分けられ、試験でその働きを説明できるようにしておくこと —— そして出荷するものには必ず #(.name(value)) と書くこと。

7.4 Pitfalls worth rehearsing7.4 值得演練一遍的陷阱7.4 一度は通しておきたい落とし穴

8. Operators and Expressions8. 運算子與運算式8. 演算子と式

8.1 The operator classes8.1 運算子的分類8.1 演算子の分類

Verilog’s operators split into classes by how many operands they take and what shape of result they produce. That second column is the one to learn: it tells you whether you get a word back or a single bit, which determines whether the result is usable as a bus or only as a condition.Verilog 的運算子依照它們取幾個運算元、以及產生什麼形狀的結果而分類。第二欄才是要學的：它告訴你拿回來的是一個字還是單一位元，而那決定了結果能不能當匯流排用，還是只能當條件用。Verilog の演算子は、取るオペランドの数と、生み出す結果の形によって分類される。学ぶべきは二列目である。返ってくるのが語か 1 ビットかを教えてくれ、それが結果をバスとして使えるのか条件としてしか使えないのかを決める。

Note the symbol collisions, which are the richest source of beginner bugs in the language: & is bitwise AND and reduction AND; ^~ is bitwise XNOR and reduction XNOR; & versus && and | versus || differ by one character and by everything else. The parser tells them apart by arity: one operand means reduction, two means bitwise.注意符號的衝突，它們是這個語言中初學者臭蟲最豐富的來源：& 既是逐位元 AND 也是縮減 AND；^~ 既是逐位元 XNOR 也是縮減 XNOR；& 與 &&、| 與 || 只差一個字元，其餘全都不同。剖析器是靠運算元個數來區分它們的：一個運算元就是縮減，兩個就是逐位元。記号の衝突に注意せよ。これは本言語における初学者のバグの最も豊かな供給源である。& はビットごとの AND でもありリダクション AND でもある。^~ はビットごとの XNOR でもリダクション XNOR でもある。& と &&、| と || は 1 文字しか違わないが、それ以外はすべて違う。パーサはオペランドの数で区別する。1 個ならリダクション、2 個ならビット演算である。

8.2 Arithmetic8.2 算術運算8.2 算術演算

assign sum  = A + B;
assign diff = A - B;
assign neg  = -A;        // unary minus: two's complement negate
assign q    = A / B;     // integer division, truncates toward zero
assign r    = A % B;     // modulus; the sign follows the FIRST operand

Four points that matter in hardware:在硬體上要緊的四點：ハードウェア上で重要な点が四つある。

• Any x or z bit in either operand makes the whole result x. Arithmetic has no controlling values — a carry can propagate from the bottom to the top — so the simulator refuses to guess any bit. One unknown bit in a 32-bit addend blackens all 32 output bits. This is the most common way an x explodes across a datapath.任一運算元中只要有一個 x 或 z 位元，整個結果就是 x。算術沒有控制值 —— 進位可以從最低位一路傳到最高位 —— 所以模擬器拒絕猜測任何一個位元。一個 32 位元加數裡的一個未知位元，就會把 32 個輸出位元全都塗黑。這是 x 在資料路徑上爆開最常見的方式。どちらかのオペランドに x か z のビットが一つでもあれば、結果全体が x になる。算術に支配値は無い —— 桁上げが最下位から最上位まで伝わりうる —— ので、シミュレータはどのビットも推測することを拒む。32 ビットの加数に不定ビットが一つあれば、出力 32 ビットすべてが黒くなる。データパス上で x が爆発する最も一般的な経路がこれである。
• Division by zero yields all x, silently. Not an error, not a trap.除以零得到全部 x，而且是無聲的。不是錯誤，也不會觸發例外。ゼロ除算はすべて x になる。しかも黙ってそうなる。エラーでもトラップでもない。
• / and % with non-constant operands synthesise to enormous combinational dividers, or are rejected outright. Division by a power of two is a right shift and costs nothing; everything else needs a multi-cycle divider you write yourself. The same is true of %. * is fine — it maps to a Booth or Wallace multiplier.運算元非常數的 / 與 % 會合成出巨大的組合除法器，或是直接被拒絕。除以 2 的冪次就是右移，不花成本；其餘全都需要你自己寫一個多週期除法器。% 也一樣。* 則沒問題 —— 它會對應到 Booth 或 Wallace 乘法器。オペランドが定数でない / と % は巨大な組合せ除算器に合成されるか、そのまま拒否される。2 の冪による除算は右シフトであり費用はかからないが、それ以外は自分で書く多サイクルの除算器が要る。% も同じである。* は問題ない。Booth 乗算器や Wallace 乗算器に対応づけられる。
• Signedness comes from the operand types. reg is unsigned, integer is signed. -A where A is reg [3:0] holding 3 gives 4'b1101, which as an unsigned value is 13, not −3 — and comparing it with anything will use that interpretation. §8.11 returns to this.有號性來自運算元的型別。reg 是無號的，integer 是有號的。當 A 是存著 3 的 reg [3:0] 時，-A 得到 4'b1101，作為無號值是 13，不是 −3 —— 而把它拿去跟任何東西比較，都會採用那個解讀。§8.11 會回到這一點。符号性はオペランドの型から来る。reg は符号なし、integer は符号つきである。A が 3 を保持する reg [3:0] のとき、-A は 4'b1101 になり、符号なし値としては −3 ではなく 13 である。そして何かと比較すればその解釈が使われる。§8.11 でこの話に戻る。

8.3 Bitwise8.3 位元運算8.3 ビット演算

Bitwise operators pair up the bits of their two operands and apply the four-value table of §5.2 to each pair independently. The result is as wide as the wider operand; the shorter operand is zero-extended on the left to match.位元運算子把兩個運算元的位元一一配對，對每一對獨立套用 §5.2 的四值表。結果寬度等於較寬的那個運算元；較短的運算元會在左側補零以對齊。ビット演算子は二つのオペランドのビットを一対一で組にし、各組に独立に §5.2 の四値表を適用する。結果の幅は広い方のオペランドに等しく、短い方は左側にゼロが詰められて長さを合わせる。

That last row is the zero-extension rule biting. Masking a wide bus with a short literal silently clears the top of the bus. Write the mask at full width, or use a replication: {4{1'b1}}.最後那一列正是補零規則在咬人。用一個短字面值去遮罩一條寬匯流排，會無聲地把匯流排的高位清掉。請把遮罩寫成完整寬度，或是用複製寫法：{4{1'b1}}。最後の行はまさにゼロ拡張の規則が噛みついているところである。短いリテラルで広いバスをマスクすると、バスの上位が黙って消える。マスクは完全な幅で書くか、繰り返し記法 {4{1'b1}} を使うこと。

8.4 Reduction8.4 縮減運算8.4 リダクション演算

Reduction operators take one operand and fold all of its bits together with the named operation, producing a single bit. &v is the AND of every bit of v; ^v is the parity of v.縮減運算子取一個運算元，用指名的運算把它所有位元摺疊在一起，產生單一位元。&v 是 v 每個位元的 AND；^v 是 v 的同位元。リダクション演算子はオペランドを一つ取り、その全ビットを指定された演算で畳み込み、1 ビットを生む。&v は v の全ビットの AND であり、^v は v のパリティである。

These are extremely useful and under-used. &addr is a one-line all-ones detector; |data tests “any bit set” and is the idiomatic non-zero test; ^data is a parity tree; ~|flags is “no flags set”. Each synthesises to a balanced tree of gates with depth $\lceil \log_2 n \rceil$, which is exactly what you would have drawn by hand.這些運算子極為好用，卻被用得太少。&addr 是一行寫成的全 1 偵測器；|data 測試「有任何位元被設起」，是慣用的非零測試；^data 是同位元樹；~|flags 是「沒有任何旗標被設起」。每一個都會合成成一棵深度為 $\lceil \log_2 n \rceil$ 的平衡閘樹，而那正是你手畫會畫出來的東西。これらは極めて有用でありながら十分に使われていない。&addr は 1 行で書けるオール 1 検出器、|data は「どれかのビットが立っているか」を調べる定番の非ゼロ判定、^data はパリティツリー、~|flags は「フラグが一つも立っていない」である。いずれも深さ $\lceil \log_2 n \rceil$ のバランスしたゲートツリーに合成される。手で描いたとしてもそうなるものだ。

The ambiguity with the bitwise operators is resolved by arity alone. In a & b the & is bitwise; in &b it is reduction; and in a & &b — legal, if unpleasant — the first is bitwise and the second reduction.與位元運算子之間的歧義，僅靠運算元個數就解決了。在 a & b 中 & 是逐位元；在 &b 中是縮減；而在 a & &b 中 —— 合法，雖然不討喜 —— 第一個是逐位元，第二個是縮減。ビット演算子との曖昧さは、オペランドの数だけで解消される。a & b の & はビット演算、&b ではリダクション、そして a & &b では —— 合法だが気持ちのよい書き方ではない —— 最初がビット演算、二つ目がリダクションである。

8.5 Logical and equality operators8.5 邏輯運算子與相等運算子8.5 論理演算子と等価演算子

Logical operators treat each operand as a single truth value: an operand is true if any of its bits is 1, false if all bits are 0, and unknown if it contains x or z and no 1. They always return one bit.邏輯運算子把每個運算元當成單一真值：只要有任一位元是 1，運算元就為真；所有位元都是 0 則為假；若含有 x 或 z 而且沒有 1，則為未知。它們一律回傳一個位元。論理演算子は各オペランドを単一の真理値として扱う。いずれかのビットが 1 なら真、すべてのビットが 0 なら偽、x または z を含み 1 が無ければ不定である。戻り値は常に 1 ビットである。

if ((b != c) && (index == 0)) ...
if ((inword == 1) || (a != d)) ...

The pair of tables below is the single most examinable thing in this section.下面這一對表，是本節最會考的單一項目。以下の二つの表は、本節で最も試験に出る項目である。

== asks “are these the same value?” and honestly answers “I cannot tell” when an operand contains an unknown. === asks “are these the same bit patterns, treating x and z as ordinary symbols?” and always returns a hard 0 or 1. The consequences:== 問的是「這兩個是同一個值嗎？」，當運算元含有未知時，它誠實地回答「我沒辦法判斷」。=== 問的是「這兩個是同一組位元樣式嗎？把 x 與 z 當成一般符號看待」，而且永遠回傳確實的 0 或 1。後果是：== は「これらは同じ値か」と問い、オペランドに不定が含まれるときは正直に「判断できない」と答える。=== は「これらは同じビットパターンか。x と z も普通の記号として扱って」と問い、常に確定した 0 か 1 を返す。その帰結は次のとおりである。

• 4'b1x01 == 4'b1x01 is x, because the x bits might be anything and might differ. 4'b1x01 === 4'b1x01 is 1.4'b1x01 == 4'b1x01 的結果是 x，因為那兩個 x 位元可能是任何值，也可能彼此不同。4'b1x01 === 4'b1x01 的結果是 1。4'b1x01 == 4'b1x01 は x である。二つの x ビットは何であってもよく、互いに異なるかもしれないからだ。4'b1x01 === 4'b1x01 は 1 である。
• if (a == b) with an x anywhere takes the false branch, because an if treats x as false. The check silently passes or silently fails depending on which way round you wrote it. This is the x-optimism of §5.5 and it is why §4.7 insisted on !== in a checker.當任何地方有 x 時，if (a == b) 會走假的那一支，因為 if 把 x 當成假。檢查會無聲地通過或無聲地失敗，取決於你把條件寫成哪一邊。這就是 §5.5 的 x 樂觀，也是 §4.7 堅持在檢查器中用 !== 的原因。どこかに x があると、if (a == b) は偽の枝を取る。if が x を偽として扱うからだ。条件をどちら向きに書いたかによって、チェックは黙って通りもすれば黙って落ちもする。これが §5.5 の x 楽観性であり、§4.7 がチェッカで !== を使えと念を押した理由である。
• === and !== are not synthesisable. There is no gate that can distinguish x from 0 — x does not exist in hardware. They belong in testbenches and assertions only.=== 與 !== 是not synthesisable的。沒有任何一個閘能分辨 x 與 0 —— x 在硬體裡並不存在。它們只屬於測試平台與斷言。=== と !== はnot synthesisableである。x と 0 を区別できるゲートは存在しない。x はハードウェアには存在しないからだ。これらはテストベンチとアサーションにのみ属する。

Also note != is the logical inequality (x-contagious) and !== the case inequality; and that !a is a one-bit logical negation while ~a is a full-width bitwise complement. !4'b0100 is 1'b0; ~4'b0100 is 4'b1011. Substituting one for the other in an if usually still “works”, which is what makes the bug durable.另外請注意：!= 是邏輯不等（會被 x 傳染），!== 是 case 不等；以及 !a 是單一位元的邏輯否定，而 ~a 是全寬度的逐位元補數。!4'b0100 是 1'b0；~4'b0100 是 4'b1011。在 if 裡把其中一個換成另一個，通常還是「會動」，而這正是這類臭蟲難以根除的原因。さらに注意すべき点。!= は論理不等（x に伝染される）、!== はケース不等である。また !a は 1 ビットの論理否定で、~a は全幅のビット単位の補数である。!4'b0100 は 1'b0、~4'b0100 は 4'b1011 である。if の中で一方を他方に置き換えてもたいてい「動いてしまう」ので、この種のバグはしぶとい。

8.6 Relational8.6 關係運算8.6 関係演算

< <= > >= compare magnitudes and return one bit, or x if either operand contains an unknown bit. The operands are compared as unsigned unless both are signed — see §8.11, because this rule causes real bugs.< <= > >= 比較大小並回傳一個位元；若任一運算元含有未知位元則回傳 x。除非兩個運算元都是有號的，否則一律以無號比較 —— 見 §8.11，因為這條規則會造成真實的臭蟲。< <= > >= は大小を比較して 1 ビットを返す。どちらかのオペランドに不定ビットがあれば x を返す。両方が符号つきでない限り、オペランドは符号なしとして比較される —— §8.11 を参照。この規則は実際にバグを生む。

if ((a < size - 1) || (b >= 3)) ...

Watch the precedence in that line: - binds tighter than <, so it reads a < (size-1) as intended. But < binds tighter than ||, which is also what you want — and tighter than &, which frequently is not. See §8.10.注意那一行裡的優先順序：- 比 < 結合得更緊，所以它如你所願地讀成 a < (size-1)。但 < 比 || 結合得更緊，這也是你要的 —— 而且比 & 更緊，那就常常不是你要的了。見 §8.10。その行の優先順位に注意せよ。- は < より強く結合するので、意図どおり a < (size-1) と読まれる。しかし < は || より強く結合し、これも望みどおりである一方、& よりも強く結合する。こちらはしばしば望みどおりではない。§8.10 を参照。

8.7 Shift8.7 位移8.7 シフト

result = (a << 3);     // left  3; vacated bits filled with 0
result = (a >> 2);     // right 2; vacated bits filled with 0 (LOGICAL shift)
result = (a >>> 2);    // Verilog-2001 ARITHMETIC right shift: sign-extends
                       //   ... but only if 'a' is declared signed

Both << and >> fill with zeros, always, regardless of signedness. The arithmetic forms <<< and >>> were added in Verilog-2001; >>> replicates the sign bit only when the left operand is of a signed type, which is the detail people miss when they write >>> on a plain reg and get a logical shift anyway.<< 與 >> 一律補零，與有號性無關。算術形式 <<< 與 >>> 是 Verilog-2001 新增的；>>> 只有在左運算元是有號型別時才會複製符號位元，而這正是有人在普通的 reg 上寫 >>>、結果還是拿到邏輯位移時漏掉的細節。<< と >> は符号性に関係なく常にゼロを詰める。算術形式の <<< と >>> は Verilog-2001 で追加された。>>> が符号ビットを複製するのは左オペランドが符号つきの型のときだけであり、素の reg に >>> と書いて結局論理シフトになる人が見落とすのがこの点である。

A shift by a constant is free in hardware — it is wiring. A shift by a variable amount is a barrel shifter, roughly $n\log_2 n$ multiplexers; still cheap, but not free. If the shift amount is x, the whole result is x.位移常數量在硬體上是免費的 —— 它就是接線。位移可變量則是一個桶形位移器，大約 $n\log_2 n$ 個多工器；仍然便宜，但不是免費。如果位移量是 x，整個結果就是 x。定数によるシフトはハードウェアでは無料である。単なる配線だからだ。可変量のシフトはバレルシフタになり、おおむね $n\log_2 n$ 個のマルチプレクサを要する。安くはあるが無料ではない。シフト量が x なら結果全体が x になる。

8.8 The conditional operator8.8 條件運算子8.8 条件演算子

This is the only ternary operator in the language and the workhorse of RTL multiplexing:這是這個語言中唯一的三元運算子，也是 RTL 多工的主力：これは本言語で唯一の三項演算子であり、RTL のマルチプレクサの主力である。

wire [1:0]  select;
wire [15:0] D1, D2, D3, D4;
wire [15:0] bus = (select == 2'b00) ? D1 :
                  (select == 2'b01) ? D2 :
                  (select == 2'b10) ? D3 :
                  (select == 2'b11) ? D4 : 16'bx;

Chained like this it is a priority multiplexer, and the trailing 16'bx is the default arm. Writing x rather than 0 there is deliberate: it marks the case as unreachable, lets the unknown propagate if it ever is reached, and tells synthesis that it may treat the case as a don’t-care and optimise the logic.像這樣串起來，它就是一個優先權式多工器，而結尾的 16'bx 是預設分支。在那裡寫 x 而不是 0 是刻意的：它標示這個情況不可到達，萬一真的到達了就讓未知傳播下去，同時告訴合成工具可以把這個情況視為 don't-care 而去最佳化邏輯。このように連ねれば優先順位付きマルチプレクサになり、末尾の 16'bx が既定の枝である。そこに 0 ではなく x と書くのは意図的である。その場合が到達不能であることを示し、万一到達したら不定を伝播させ、同時に合成ツールにはその場合をドントケアとして論理を最適化してよいと伝える。

The behaviour with an ambiguous condition is the slide’s main point and a favourite exam question. If the condition evaluates to x, the simulator does not pick a branch. It evaluates both expressions and merges them bit by bit:條件為不明確值時的行為是投影片的主要重點，也是考試的最愛。如果條件求值為 x，模擬器不會挑任何一支。它會把兩個運算式都求值，然後逐位元合併：条件が曖昧なときの振る舞いはスライドの主眼であり、試験でも好まれる。条件が x に評価された場合、シミュレータはどちらの枝も選ばない。両方の式を評価し、ビットごとにマージする。

The slide also states that z is not allowed in the condition. In practice a z in the condition is treated exactly like an x and triggers the same bitwise merge — the point of the rule is that you must not rely on it, because a floating selector has no defined meaning.投影片也說條件中不允許 z。實務上條件裡的 z 會被完全當成 x 對待，觸發同樣的逐位元合併 —— 這條規則的重點在於你不可以依賴它，因為浮接的選擇訊號沒有任何已定義的意義。スライドは条件に z は許されないとも述べている。実際には条件中の z は x とまったく同じに扱われ、同じビットごとのマージが起きる。この規則の要点は、それに依存してはならないということである。浮いたセレクタには定義された意味が無いからだ。

Contrast this with the behavioural if, which treats x as false and picks the else branch (§5.5). The conditional operator is more faithful to the hardware: a real multiplexer with an undefined select does output something unpredictable on the bits where the inputs differ, and something predictable where they agree.把這個拿去跟行為式的 if 對照，後者把 x 當成假而走 else 分支（§5.5）。條件運算子更忠實於硬體：一個選擇訊號未定義的真實多工器，在兩個輸入不同的位元上確實會輸出不可預測的東西，而在兩者相同的位元上輸出可預測的東西。これを、x を偽として else の枝を取る振る舞い記述の if（§5.5）と対比してほしい。条件演算子のほうがハードウェアにより忠実である。セレクトが未定義の実際のマルチプレクサは、入力が食い違うビットでは確かに予測不能なものを出力し、一致するビットでは予測可能なものを出力する。

8.9 Concatenation and replication8.9 串接與複製8.9 連結と繰り返し

{a, b}                       // join: width = width(a) + width(b)
{4{a}}                       // replicate: {a, a, a, a}
{{3{a}}, {2{b}}, {4{c}}}     // correct nesting of several replications
{1'b0, byte_in}              // zero-extend to 9 bits before adding
{byte_in[0], byte_in[7:1]}   // rotate right by one — pure wiring

Two further rules. First, every operand of a concatenation must have a known width, so an unsized constant such as 'b0 or a plain 5 is illegal inside braces; write 1'b0 or 4'd5. Second, the replication count must be a constant expression — it determines the width of a wire, so it must be known at elaboration.還有兩條規則。第一，串接的每個運算元都必須有已知的寬度，所以像 'b0 這種未指定寬度的常數、或是裸寫的 5，在大括號裡都是不合法的；請寫 1'b0 或 4'd5。第二，複製次數必須是常數運算式 —— 它決定一條線的寬度，所以必須在展開期就已知。規則がさらに二つある。第一に、連結のオペランドはすべて既知の幅を持たねばならないので、'b0 のような幅なし定数や裸の 5 は波括弧の中では不正である。1'b0 や 4'd5 と書くこと。第二に、繰り返し回数は定数式でなければならない。配線の幅を決めるので、エラボレーション時に既知でなければならないからだ。

A concatenation is also a legal assignment target, which is often the neatest way to unpack a result: {carry_out, sum} = a + b; captures the carry and the sum in one statement, and is far clearer than widening the operands by hand.串接也是合法的指定目標，這常常是拆解結果最漂亮的方式：{carry_out, sum} = a + b; 一條敘述就同時接住進位與和，比起自己手動把運算元加寬要清楚得多。連結は合法な代入先でもあり、結果を分解するのに最も美しい方法であることが多い。{carry_out, sum} = a + b; は 1 文でキャリーと和の両方を受け取る。自分で手作業でオペランドを広げるよりはるかに明快である。

8.10 Precedence8.10 優先順序8.10 優先順位

The slide gives six levels. The real table has fifteen, and the levels it omits — the bitwise and logical operators — are exactly where mistakes happen. Here is the whole thing, highest first:投影片給了六個層級。真正的表有十五個，而它省略掉的那些層級 —— 位元運算子與邏輯運算子 —— 正是出錯的地方。以下是完整的表，由高到低：スライドは 6 段階を示している。本当の表は 15 段階あり、省かれた段 —— ビット演算子と論理演算子 —— こそ間違いが起きる場所である。以下に全体を高い順に示す。

Three traps live in this table:這張表裡住著三個陷阱：この表には三つの罠が潜んでいる。

• Bitwise & binds looser than ==. So a & b == c parses as a & (b == c) — almost certainly not what you meant. This is inherited from C and is the most notorious precedence bug in both languages.逐位元 & 比 == 結合得更鬆。所以 a & b == c 會被剖析成 a & (b == c) —— 幾乎肯定不是你的本意。這是從 C 繼承來的，也是兩種語言中最惡名昭彰的優先順序臭蟲。ビット単位の & は == より弱く結合する。したがって a & b == c は a & (b == c) と構文解析される —— ほぼ確実に意図とは違う。これは C から受け継いだもので、両言語で最も悪名高い優先順位のバグである。
• Unary operators bind tightest. ~a & b is (~a) & b, and -a ** b is (-a) ** b.單元運算子結合得最緊。~a & b 是 (~a) & b，而 -a ** b 是 (-a) ** b。単項演算子が最も強く結合する。~a & b は (~a) & b であり、-a ** b は (-a) ** b である。
• ?: is right-associative and lowest. That is what makes the chained multiplexer in §8.8 parse correctly without parentheses around each arm.?: 是右結合，而且最低。這正是 §8.8 那個串接式多工器不必在每一支外面加括號也能正確剖析的原因。?: は右結合で、しかも最も弱い。§8.8 の連ねたマルチプレクサが各枝を括弧で囲まなくても正しく解析されるのはこのためである。

The slide’s advice — if unsure, use parentheses — is the correct professional habit, not a confession of weakness. Nobody has ever been criticised in a code review for parenthesising an expression that did not need it; people are criticised weekly for the opposite.投影片的建議 —— 不確定就加括號 —— 是正確的專業習慣，不是示弱的自白。從來沒有人在程式碼審查中因為替一個不必加括號的運算式加了括號而被批評；因為相反的理由被批評的人，倒是每週都有。スライドの助言 —— 自信が無ければ括弧を使え —— は弱さの告白ではなく、正しい職業上の習慣である。要らない括弧を付けたせいでコードレビューで批判された者はいない。その逆で批判される者なら毎週いる。

8.11 Expression width: the rule that silently changes your answer8.11 運算式寬度：那條會無聲改掉你答案的規則8.11 式のビット幅：答えを黙って変えてしまう規則

This is not on the slides and it causes more real bugs than everything that is. Verilog computes the width of an expression before evaluating it, and the left-hand side of the assignment participates in that calculation.這一節不在投影片上，而它造成的真實臭蟲比投影片上所有東西加起來都多。Verilog 會在求值之前先算出運算式的寬度，而且指定式的左手邊也參與這個計算。これはスライドには無いが、スライドにあるすべてを合わせたより多くの実際のバグを生んでいる。Verilog は式を評価する前にその幅を計算し、しかも代入の左辺もその計算に加わる。

Operands come in two kinds:運算元分成兩種：オペランドには二種類ある。

• Context-determined: the operand is widened to the width of the largest participant in the surrounding expression, including the assignment target. This applies to the operands of arithmetic and bitwise operators, both arms of ?:, and the left operand of a shift.由上下文決定（context-determined）：運算元會被加寬到周圍運算式中最大參與者的寬度，包含指定目標在內。這適用於算術與位元運算子的運算元、?: 的兩支，以及位移的左運算元。文脈依存（context-determined）：オペランドは、周囲の式の中で最大の参加者の幅まで広げられる。代入先も含めてである。これは算術演算子とビット演算子のオペランド、?: の両方の枝、シフトの左オペランドに当てはまる。
• Self-determined: the operand is evaluated at its own natural width, whatever surrounds it. This applies to the operands of reduction, logical and relational operators, the right operand of a shift, the condition of ?:, and everything inside a concatenation or replication.自身決定（self-determined）：運算元以自己天然的寬度求值，不管周圍是什麼。這適用於縮減、邏輯與關係運算子的運算元、位移的右運算元、?: 的條件，以及串接或複製裡面的一切。自己決定（self-determined）：オペランドは周囲に関係なく自身の自然な幅で評価される。これはリダクション・論理・関係演算子のオペランド、シフトの右オペランド、?: の条件、そして連結や繰り返しの中身すべてに当てはまる。

Work through the classic case. wire [3:0] a, b; with a = 4'd12 and b = 4'd10:把經典案例走一遍。wire [3:0] a, b;，其中 a = 4'd12、b = 4'd10：典型例を通して見る。wire [3:0] a, b; で a = 4'd12、b = 4'd10 とする。