Synthesis of Combinational Logic — Explained組合邏輯的合成 — 詳解組合せ論理の合成 — 詳解

1. Logic Synthesis in the Design Flow1. 設計流程中的邏輯合成1. 設計フローにおける論理合成

1.1 The HDL-based design flow, and why it is drawn as a loop1.1 以 HDL 為核心的設計流程，以及它為什麼被畫成一個迴圈1.1 HDL ベースの設計フローと、それがループとして描かれる理由

The first slide of this lecture is a block diagram that most students glance at and forget, because it looks like an organisation chart. It is worth slowing down on, because every rule that follows in the lecture is a consequence of the shape of this diagram. Design entry produces an HDL behavioural model. That model goes two places. It goes forward into physical optimisation and implementation, and it goes sideways into design verification by functional simulation. The implemented design then comes back to design verification a second time, now by timing simulation. The diagram is a loop, not a pipeline, and the loop is the whole point: the behavioural model is simultaneously the thing you are building and the specification against which the thing you built is checked.本講的第一張投影片是一張方塊圖，多數學生看一眼就忘了，因為它長得像一張組織架構圖。但值得停下來細看，因為這一講後面的每一條規則，都是這張圖形狀的必然結果。設計輸入產生一份 HDL 行為模型。這份模型往兩個方向走：一是往前進入實體最佳化與實作，二是往旁邊進入以功能模擬進行的設計驗證。實作完成的設計接著第二次回到設計驗證，這次用的是時序模擬。這張圖是一個迴圈，不是一條管線，而這個迴圈正是重點所在：行為模型同時是你正在打造的東西，也是用來檢查你所造之物的規格書。この講義の最初のスライドはブロック図で、組織図のように見えるため多くの学生は一瞥して忘れてしまう。しかし立ち止まる価値がある。この講義で以降に登場するすべての規則は、この図の形から必然的に導かれるからだ。設計入力は HDL 行動モデルを生む。そのモデルは二方向へ進む。前方へは物理最適化と実装へ、横方向へは機能シミュレーションによる設計検証へ進む。実装された設計はもう一度設計検証へ戻り、今度はタイミングシミュレーションにかけられる。この図はパイプラインではなくループであり、そのループこそが要点である。行動モデルは、作ろうとしている対象であると同時に、作った対象を検証するための仕様書でもあるのだ。

That dual role is unusual and it is the source of most of the discipline this lecture tries to teach. In a software project the specification and the implementation are different documents written by different people. In an RTL project they are the same file. The synthesiser reads your always block and produces gates; the simulator reads the same always block and produces waveforms; and nothing in the universe guarantees that those two readings agree. They agree only if you confine yourself to a subset of the language on which the simulator's semantics and the synthesiser's semantics coincide. That subset is what the lecture calls "synthesisable", and everything in Section 2 is the definition of that subset.這種雙重身分並不尋常，而本講試圖教的紀律大多源自於此。在軟體專案裡，規格與實作是由不同的人寫的不同文件。在 RTL 專案裡，它們是同一個檔案。合成器讀你的 always 區塊而產生邏輯閘；模擬器讀同一個 always 區塊而產生波形；而世上沒有任何東西保證這兩種讀法會一致。只有當你把自己限制在一個子集合裡——在這個子集合上，模擬器的語意與合成器的語意恰好重合——它們才會一致。那個子集合就是本講所說的「可合成」，而第 2 節的全部內容，就是這個子集合的定義。この二重の役割は珍しく、本講義が教えようとする規律のほとんどはここに由来する。ソフトウェアのプロジェクトでは、仕様と実装は別々の人が書いた別々の文書である。RTL のプロジェクトでは、両者は同じファイルである。合成器はあなたの always ブロックを読んでゲートを生成し、シミュレータは同じ always ブロックを読んで波形を生成する。そしてこの二つの読み方が一致することを保証するものは何もない。一致するのは、シミュレータの意味論と合成器の意味論が重なり合う言語の部分集合に自分を限定したときだけである。その部分集合こそが本講義のいう「合成可能」であり、第 2 節の全体はその部分集合の定義にほかならない。

The bottom of the flow diagram splits into three target technologies, and the split matters because the words change meaning. For a PLD the implementation steps are partition, map and interconnect. For an FPGA or a masked gate array they are map, place and route. For standard cells they are place and route — there is no separate "map" step listed because mapping happened inside synthesis, against a cell library. This course is a standard-cell course, so when the lecture says "technology mapping" it means: choose, from a library of a few hundred physical cells with known area, delay, input capacitance and drive strength, a set of cells whose interconnection realises the optimised Boolean network. That is a covering problem, and it is solved approximately, which is why the slide's footnote — final synthesis results depend on the synthesis tool — is not a disclaimer but a statement of fact.流程圖的下半部分岔成三種目標技術，這個分岔很重要，因為同樣的詞在不同技術下意義不同。對 PLD 而言，實作步驟是分割、映射與互連。對 FPGA 或光罩式閘陣列而言，是映射、擺放與繞線。對標準元件而言，則是擺放與繞線——之所以沒有列出獨立的「映射」步驟，是因為映射已經在合成階段對著元件庫完成了。本課程是標準元件的課程，所以當本講說「技術映射」時，意思是：從一座有幾百個實體元件、每個元件都有已知面積、延遲、輸入電容與驅動能力的元件庫中，挑出一組元件，使它們的互連實現經過最佳化的布林網路。那是一個覆蓋問題，而且只能近似求解，這也是為什麼投影片的註腳——final synthesis results depend on the synthesis tool——不是免責聲明，而是在陳述事實。フロー図の下部は三つのターゲット技術へ分岐する。この分岐は重要で、分岐の先で言葉の意味が変わるからだ。PLD では実装の工程は分割・マッピング・相互接続である。FPGA やマスク型ゲートアレイではマッピング・配置・配線である。標準セルでは配置・配線だけであり、独立した「マッピング」の工程が挙がっていないのは、マッピングがセルライブラリを相手に合成の内部で済んでいるからである。本講義は標準セルの講義なので、「テクノロジマッピング」といえば次を意味する。面積・遅延・入力容量・駆動能力が既知の数百個の物理セルからなるライブラリから、その相互接続が最適化済みのブール・ネットワークを実現するようなセルの集合を選び出すこと。これは被覆問題であり、近似的にしか解けない。だからこそスライドの脚注 final synthesis results depend on the synthesis tool は免責事項ではなく事実の記述なのである。

1.2 Simulation-based verification: why the same test bench runs twice1.2 以模擬為基礎的驗證：為什麼同一份測試平台要跑兩次1.2 シミュレーションによる検証：なぜ同じテストベンチを二度走らせるのか

The second slide shows a test bench with two devices under test. One is the Verilog behavioural description, the other is the gate-level description produced by logic synthesis. A stimulus generator drives both; a response comparator watches both sets of outputs; a check signal fires on any mismatch. This arrangement has a name in industry — it is a gate-level regression — and the lecture is right to put it on page three, because the whole of the rest of the lecture is a list of ways to make this comparison fail.第二張投影片畫的是一個測試平台，裡面有兩個待測元件。一個是 Verilog 行為描述，另一個是邏輯合成產生的閘級描述。一個激勵產生器同時驅動兩者；一個回應比較器同時監看兩組輸出；只要有任何不一致，檢查訊號就會觸發。這種安排在業界有個名字——它叫做閘級回歸測試——本講把它放在第三頁是對的，因為這一講接下來的全部內容，就是一張「有哪些方法會讓這個比較失敗」的清單。二枚目のスライドには、二つの被測定デバイスを持つテストベンチが描かれている。一方は Verilog の行動記述、もう一方は論理合成が生成したゲートレベル記述である。刺激生成器が両者を駆動し、応答比較器が両方の出力を監視し、不一致があればチェック信号が立つ。この構成には業界での呼び名があり、ゲートレベル・リグレッションという。これを三ページ目に置いた講義の判断は正しい。以降の講義全体が、この比較を失敗させる方法の一覧だからである。

It is worth being precise about what this check does and does not prove. It proves that for the stimulus you applied, the netlist and the RTL produce the same outputs. It does not prove functional equivalence, because the stimulus is finite and the input space is not. Formal equivalence checking, which proves the stronger statement by comparing the Boolean cones of logic between corresponding registers, is the tool actually used for sign-off in a modern flow; simulation-based comparison is used to catch the things equivalence checking cannot see, such as timing violations with back-annotated delays, or an initialisation sequence that leaves the netlist in a state the RTL never reaches.值得精確地說清楚這個檢查證明了什麼、又沒有證明什麼。它證明的是：對你所施加的激勵而言，網表與 RTL 產生相同的輸出。它並沒有證明功能等價，因為激勵是有限的，而輸入空間不是。形式等價驗證（formal equivalence checking）藉由比較對應暫存器之間的布林邏輯錐，證明的是更強的命題，那才是現代流程中真正用來簽核的工具；而以模擬為基礎的比較，則用來抓等價驗證看不見的東西，例如反標註延遲後的時序違規，或是一段初始化序列讓網表停在 RTL 永遠到不了的狀態。この検査が何を証明し、何を証明しないのかは正確に述べておく価値がある。証明するのは、与えた刺激に対してネットリストと RTL が同じ出力を出すということだけである。機能的等価性は証明しない。刺激は有限だが入力空間は有限ではないからだ。対応するレジスタ間のブール論理コーンを比較することでより強い命題を証明する形式等価検証こそ、現代のフローでサインオフに実際に使われるツールである。シミュレーションによる比較は、等価検証では見えないもの、たとえば遅延をバックアノテートしたときのタイミング違反や、RTL が決して到達しない状態にネットリストを置いてしまう初期化シーケンスなどを捕まえるために使う。

The reason this matters for a combinational-logic lecture is subtle. Most of the mistakes catalogued in Sections 6 and 7 do not make the netlist wrong in a way that equivalence checking catches, because the netlist is a faithful implementation of what you wrote. The mistake is that what you wrote is not what you meant. An inferred latch is a perfectly correct implementation of an incomplete case; equivalence checking will cheerfully confirm that the latch matches the RTL. It is the simulation comparison, with realistic stimulus, that shows the output holding a stale value when you expected it to update — and even then only if your stimulus happens to walk into the uncovered branch. This is precisely why the lecture insists on the coding rules rather than relying on downstream checks: the cheapest place to catch an inferred latch is in the lint report, before a single gate exists.這件事對一堂組合邏輯的課為什麼重要，理由很微妙。第 6 節與第 7 節列出的大部分錯誤，並不會讓網表以等價驗證抓得到的方式出錯，因為網表忠實地實現了你所寫的東西。錯的是：你寫的不是你想的。被推論出來的鎖存器，是對一個不完整 case 完全正確的實現；等價驗證只會高高興興地確認這個鎖存器與 RTL 相符。真正會顯示輸出在你期待它更新時卻抱著舊值不放的，是帶有真實激勵的模擬比較——而且還得你的激勵剛好走進那個沒被涵蓋的分支才行。這正是為什麼本講堅持寫碼規則，而不是倚賴下游檢查：抓到推論鎖存器最便宜的地方是 lint 報告，在任何一個邏輯閘誕生之前。これが組合せ論理の講義にとってなぜ重要なのかは微妙な話である。第 6 節と第 7 節に並ぶ誤りの大半は、等価検証が捕まえられる形でネットリストを誤らせはしない。ネットリストは書かれたとおりを忠実に実装しているからだ。誤っているのは、書いたものが意図したものではないという点である。推論されたラッチは、不完全な case の完全に正しい実装であり、等価検証はそのラッチが RTL と一致することを嬉々として確認する。更新されるはずの出力が古い値を保持したままであることを示してくれるのは、現実的な刺激を与えたシミュレーション比較だけであり、しかも刺激がたまたま未カバーの分岐に踏み込んだ場合に限られる。講義が下流の検査に頼らずコーディング規則を強く求めるのはまさにこのためである。推論ラッチを捕まえる最も安上がりな場所は、ゲートが一つも存在しないうちの lint レポートなのだ。

1.3 Three engines: translation, optimisation, mapping1.3 三個引擎：翻譯、最佳化、映射1.3 三つのエンジン：翻訳・最適化・マッピング

The slide's one-line definition is the one to memorise: logic synthesis operates on Boolean equations and produces optimised combinational logic. The accompanying diagram unpacks that into three engines in series, with two external inputs.投影片上那句一行定義值得背下來：邏輯合成在布林方程式上運作，並產生經過最佳化的組合邏輯。隨附的圖把這句話拆成串接的三個引擎，外加兩個外部輸入。スライドの一行の定義は暗記する価値がある。論理合成はブール方程式を対象に動作し、最適化された組合せ論理を生成する。付随する図はこれを直列につながった三つのエンジンと、二つの外部入力に分解して示している。

The translation engine is a compiler front end. It parses your Verilog, elaborates parameters and generate blocks, and converts each procedural block into a set of Boolean equations over the block's inputs. This is where "inference" happens: the tool recognises patterns in your code and decides, for each variable assigned in a block, whether that variable is a wire, a latch or a flip-flop. The output of this stage is a technology-independent network, conventionally in sum-of-products form, often called a GTECH or generic netlist. It is already a circuit, but a circuit made of imaginary gates with no area and no delay.翻譯引擎就是編譯器的前端。它剖析你的 Verilog，展開參數與 generate 區塊，並把每一個程序式區塊轉換成一組以該區塊輸入為變數的布林方程式。「推論」就發生在這裡：工具辨識你程式碼中的樣式，並為區塊中每一個被賦值的變數決定，它到底是一條 wire、一個鎖存器，還是一個正反器。這個階段的輸出是一個與技術無關的網路，慣例上以積項和的形式表示，常被稱為 GTECH 網表或泛用網表。它已經是一個電路了，但這個電路是由沒有面積也沒有延遲的想像邏輯閘組成的。翻訳エンジンはコンパイラのフロントエンドである。Verilog を構文解析し、パラメータと generate ブロックを展開し、各手続きブロックをそのブロックの入力を変数とするブール方程式の集合へ変換する。「推論」が起きるのはここである。ツールはコード中のパターンを認識し、ブロック内で代入される各変数について、それが wire なのかラッチなのかフリップフロップなのかを決める。この段階の出力はテクノロジ非依存のネットワークで、慣例的に積和形で表され、しばしば GTECH ネットリストあるいは汎用ネットリストと呼ばれる。すでに回路ではあるが、面積も遅延も持たない想像上のゲートでできた回路である。

The optimisation engine restructures that network. It does not know what cells exist; it works on literal counts and logic depth as proxies for area and delay. The five multi-level operations in Section 3 are its vocabulary. It is also the stage that exploits don't-cares, which is why Section 10's 4'bx trick produces a visibly smaller circuit.最佳化引擎重新架構這個網路。它並不知道有哪些元件存在；它用文字數（literal count）與邏輯深度來當作面積與延遲的代理指標。第 3 節的五個多層操作就是它的詞彙。它也是利用不在意項的那個階段，這就是為什麼第 10 節的 4'bx 手法會產生一個肉眼可見地更小的電路。最適化エンジンはそのネットワークを再構成する。どんなセルが存在するかは知らず、面積と遅延の代理としてリテラル数と論理段数の上で働く。第 3 節の五つの多段操作がその語彙である。ドントケアを活用するのもこの段階であり、第 10 節の 4'bx の技が目に見えて小さい回路を生むのはそのためである。

The mapping engine finally covers the optimised network with real cells. It is guided by the technology library, which for each cell gives area in square microns or in grid units, and a delay model — in a modern library, a two-dimensional non-linear table indexed by input transition time and output load capacitance. Mapping is where the constraint you supplied (a clock period, a maximum area, a maximum transition time) first bites, because it is the first stage that can compute a number comparable with the constraint.映射引擎最後用真實的元件去覆蓋最佳化後的網路。引導它的是技術元件庫，庫中每個元件都給出以平方微米或格點單位表示的面積，以及一個延遲模型——在現代的元件庫裡，那是一張以輸入轉態時間與輸出負載電容為索引的二維非線性表格。你所提供的約束（一個時脈週期、一個面積上限、一個轉態時間上限）第一次真正咬人就是在映射階段，因為這是第一個能算出可與約束相比較之數字的階段。マッピングエンジンが最後に、最適化されたネットワークを実在のセルで被覆する。これを導くのはテクノロジライブラリで、各セルについて平方マイクロメートルまたはグリッド単位の面積と、遅延モデルを与える。現代のライブラリでは、遅延モデルは入力遷移時間と出力負荷容量を索引とする二次元の非線形テーブルである。与えた制約（クロック周期、面積の上限、遷移時間の上限）が最初に効いてくるのはマッピングの段階である。制約と比較できる数値を計算できる最初の段階だからだ。

1.4 What logic synthesis is not1.4 邏輯合成不是什麼1.4 論理合成ではないもの

Three negatives are worth stating explicitly, because the lecture assumes them without saying them.有三件「不是」值得明說，因為本講預設了它們卻沒有講出來。明示する価値のある三つの否定がある。講義はこれらを前提にしながら口に出さないからだ。

Synthesis is not a compiler in the sense that a C compiler is. A C compiler is allowed to assume a single thread of control stepping through statements. A synthesiser is producing a structure that has no thread of control at all; every gate is live simultaneously. The sequencing you see in an always block is a description device, not an execution model. When you write y = a; y = b; inside a combinational block, the synthesiser does not build two assignments; it notices that the first value is dead and builds only the second. That dead-value elimination is exactly what makes the "default assignment at the top of the block" cure in Section 6.5 free of cost.合成不是 C 編譯器那種意義下的編譯器。C 編譯器可以假設有一條控制流一步步走過各個敘述。合成器產生的是一個根本沒有控制流的結構；每一個邏輯閘都同時活著。你在 always 區塊裡看到的順序是一種描述手段，不是執行模型。當你在一個組合邏輯區塊裡寫 y = a; y = b; 時，合成器不會造出兩個賦值；它注意到第一個值是死的，於是只造出第二個。這種死值消去正是第 6.5 節「在區塊頂端放一個預設賦值」的解法之所以不花半點代價的原因。合成は、C コンパイラのような意味でのコンパイラではない。C コンパイラは文を順に辿る単一の制御の流れを前提にしてよい。合成器が生むのは制御の流れをまったく持たない構造であり、すべてのゲートが同時に生きている。always ブロックに見える順序は記述のための道具であって、実行モデルではない。組合せブロックの中で y = a; y = b; と書いたとき、合成器は二つの代入を作らない。最初の値が死んでいることに気づき、二つ目だけを作る。この死値除去こそ、第 6.5 節の「ブロック冒頭でデフォルト代入をする」対処がまったくコストを伴わない理由である。

Synthesis is not a timing-accurate model of your code. Delays you write (#5) are ignored, sometimes silently. This is the single most common source of the pathological situation where RTL simulation passes and gate simulation fails: a testbench-like delay crept into the design code and the simulator honoured it while the synthesiser discarded it.合成不是你程式碼的時序精確模型。你寫的延遲（#5）會被忽略，有時候還是無聲無息地忽略。這是「RTL 模擬通過、閘級模擬失敗」這種病態狀況最常見的單一來源：一個像測試平台裡才會有的延遲混進了設計碼，模擬器尊重它，合成器丟掉它。合成はコードのタイミング精密なモデルでもない。書いた遅延（#5）は無視され、しかも黙って無視されることがある。RTL シミュレーションは通るのにゲートシミュレーションが落ちるという病的な状況の、最も多い単一の原因がこれである。テストベンチに属すべき遅延が設計コードに紛れ込み、シミュレータはそれを尊重し、合成器は捨てたのだ。

Synthesis does not preserve your module hierarchy or your signal names unless you ask it to. By default a tool will flatten small modules into their parents and rename internal nets. If you are hunting for a latch in a netlist and cannot find a signal called alu_reg, that is why. The netlist name of an inferred latch is derived from the library cell, not from your variable: you will see instance names like alu_reg_reg[3] driving a cell type like LATQ_X1 or, in the slide's older library, latrnb_a.除非你特別要求，否則合成不會保留你的模組階層或你的訊號名稱。工具預設會把小模組攤平進它的母模組，並把內部連線改名。如果你正在網表裡追捕一個鎖存器，卻找不到一條叫 alu_reg 的訊號，原因就在這裡。被推論出來的鎖存器，它在網表裡的名字是從元件庫元件衍生的，不是從你的變數來的：你會看到像 alu_reg_reg[3] 這樣的實體名稱，驅動著一個 LATQ_X1 型別的元件，或者在投影片那座比較老的元件庫裡，叫 latrnb_a。明示的に頼まない限り、合成はモジュール階層も信号名も保存しない。既定ではツールは小さなモジュールを親に平坦化し、内部ネットを改名する。ネットリストの中でラッチを探しているのに alu_reg という信号が見つからないのはこのためである。推論されたラッチのネットリスト上の名前は、変数名ではなくライブラリセルに由来する。alu_reg_reg[3] のようなインスタンス名が LATQ_X1 のようなセル型を、あるいはスライドの古いライブラリでは latrnb_a を駆動しているのが見えるはずだ。

2. Synthesisable and Un-synthesisable Constructs2. 可合成與不可合成的構件2. 合成可能な構文要素と不可能な構文要素

2.1 The supported list, and the single principle behind it2.1 支援清單，以及它背後唯一的原則2.1 サポートされる一覧と、その背後にあるただ一つの原則

The lecture gives two long lists, one headed "commonly supported" and one headed "not generally supported". Memorising two lists is a poor use of a graduate student's memory. There is one principle that generates almost all of both lists, and once you have it you can classify a construct you have never seen before.本講給了兩張長長的清單，一張標題是「通常支援」，另一張是「一般不支援」。背兩張清單，對研究生的記憶力是很糟的用法。其實有一條原則幾乎能生成這兩張清單的全部內容，而一旦你掌握它，就能把你從沒見過的構件也分類出來。講義は「一般にサポートされる」と「一般にサポートされない」という二つの長い一覧を示す。二つの一覧を丸暗記するのは大学院生の記憶力の使い道として拙い。両方の一覧をほぼすべて生成できる原則が一つあり、それを握れば見たこともない構文要素でも分類できる。

Run the three clauses over the supported list and watch them account for it. Module declarations, port modes, parameters, port binding by name or position — all pure structure, fixed at elaboration. Nets (wire, tri, wand, wor, supply0, supply1) and registers (reg, integer) are storage for values, with the caveat that wand and wor correspond to wired-AND and wired-OR structures that only some technologies provide. Integer literals in any radix, scalar and vector nets, subranges on the right-hand side of an assignment — again, value plumbing with a fixed shape. Continuous assignments are Boolean equations by definition. Shift, conditional, concatenation, arithmetic, bitwise, reduction, logical and relational operators all have direct combinational realisations: a shift by a constant is a rewiring, a shift by a variable is a barrel shifter, a + is an adder, a < is a magnitude comparator.把這三個子句拿去跑一遍支援清單，看它們如何逐一交代過去。模組宣告、埠的方向、參數、依名稱或依位置的埠綁定——全是純結構，在展開時就固定了。網路型別（wire、tri、wand、wor、supply0、supply1）與暫存器型別（reg、integer）是值的儲存處，但要注意 wand 與 wor 對應的是線接 AND 與線接 OR 結構，只有某些技術提供。任何進位制的整數字面值、純量與向量網路、賦值右手邊的子範圍——同樣都是形狀固定的值的管路。連續賦值依定義就是布林方程式。位移、條件、串接、算術、位元、歸約、邏輯與關係運算子全都有直接的組合邏輯實現：位移常數是重新接線，位移變數是桶式移位器，+ 是加法器，< 是大小比較器。この三つの節をサポート一覧に当てはめ、どう説明がつくか見てみよう。モジュール宣言、ポートの方向、パラメータ、名前または位置によるポート結合——すべて純粋な構造であり、エラボレーション時に確定する。ネット（wire、tri、wand、wor、supply0、supply1）とレジスタ（reg、integer）は値の格納場所である。ただし wand と wor はワイヤード AND・ワイヤード OR の構造に対応し、それを備える技術は限られる。任意の基数の整数リテラル、スカラおよびベクタのネット、代入の右辺の部分範囲——これも形の決まった値の配管にすぎない。連続代入は定義からしてブール方程式である。シフト・条件・連接・算術・ビット単位・リダクション・論理・関係の各演算子はいずれも直接の組合せ回路実現を持つ。定数シフトは配線の付け替え、変数シフトはバレルシフタ、+ は加算器、< は大小比較器である。

The procedural entries are where the principle starts doing real work. begin ... end is just grouping. if, if/else, if/else if, and case, casex, casez with default are selection, which becomes a multiplexer or a priority chain depending on whether the conditions overlap — that is the whole of Section 8. for loops are supported because the tool unrolls them, which requires the bounds to be constant at elaboration time; a loop whose bound depends on a signal value has no fixed shape and is therefore not synthesisable, which is why "data-dependent loops" appears on the forbidden list. disable of the enclosing procedural block is supported because, after unrolling, it is equivalent to a cascade of conditions guarding the remaining statements — the slide's and4_behav and comparator examples in Section 4.5 rely on exactly this. Tasks and functions are supported because they are, for synthesis purposes, macro expansion with argument binding; the asterisk on the slide's task ... endtask entry says "no timing or event control allowed", which is the principle's first clause again.程序式的那些條目，才是這條原則真正開始出力的地方。begin ... end 只是分組。if、if/else、if/else if，以及帶 default 的 case、casex、casez 都是選擇，而它會變成多工器還是優先權鏈，取決於條件是否重疊——第 8 節講的就是這整件事。for 迴圈之所以被支援，是因為工具會把它展開，而展開要求迴圈界限在展開時就是常數；界限取決於訊號值的迴圈沒有固定形狀，因此不可合成，這也是「資料相依迴圈」出現在禁止清單上的原因。disable 所在的那個程序式區塊之所以被支援，是因為展開之後，它等價於一串條件把後續敘述一層層擋住——第 4.5 節投影片上的 and4_behav 與 comparator 例子靠的正是這一點。task 與 function 之所以被支援，是因為就合成而言，它們不過是帶引數綁定的巨集展開；投影片 task ... endtask 那一條上的星號寫著「不得含時序或事件控制」，那又是這條原則的第一個子句。原則が本当に働き始めるのは手続き系の項目である。begin ... end は単なるグループ化。if、if/else、if/else if、および default 付きの case・casex・casez は選択であり、条件が重なるかどうかによってマルチプレクサにも優先順位チェーンにもなる。第 8 節はまるごとその話である。for ループがサポートされるのはツールがこれを展開するからで、展開には境界がエラボレーション時に定数であることが要る。境界が信号値に依存するループは形が定まらず、したがって合成できない。「データ依存ループ」が禁止リストに載るのはこのためである。囲っている手続きブロックの disable がサポートされるのは、展開後にはそれが残りの文を守る条件のカスケードと等価になるからで、第 4.5 節のスライドにある and4_behav と comparator の例はまさにこれに依拠している。task と function がサポートされるのは、合成の立場からは引数結合つきのマクロ展開にすぎないからである。スライドの task ... endtask の項に付いたアスタリスクは「タイミングやイベント制御は不可」と述べており、これは原則の第一節の言い換えである。

One entry on the supported list deserves suspicion: procedural continuous assignment, assign ... deassign. It appears in the lecture's "simulation efficient" mux of Section 5.2. It is listed as supported because the tools of that era accepted it and produced a mux. Modern tools frequently reject it or warn heavily, and the construct was deprecated in later standards. Treat it as something to recognise in an exam question and never to write.支援清單上有一個條目值得懷疑：程序式連續賦值 assign ... deassign。它出現在第 5.2 節那個本講稱為「模擬效率佳」的多工器裡。它被列為支援，是因為那個年代的工具接受它並產生一個多工器。現代工具經常拒絕它或大聲警告，而這個構件在後來的標準中已被廢止。把它當成考題裡要認得、但永遠不要寫出來的東西。サポート一覧の中で疑ってかかるべき項目が一つある。手続き的連続代入 assign ... deassign である。これは第 5.2 節の講義でいう「シミュレーション効率のよい」マルチプレクサに登場する。サポートされると書かれているのは、当時のツールがこれを受け付けてマルチプレクサを生成したからだ。現代のツールはこれを拒否するか強く警告することが多く、この構文は後の規格で廃止された。試験問題で見分けられればよく、自分では決して書かないものと心得よ。

2.2 The unsupported list, grouped by which clause it violates2.2 不支援清單，依它違反哪一個子句分組2.2 サポートされない一覧を、違反する節ごとに分類する

Every row below carries the not synthesisable badge in spirit; the badge is used throughout this page to mark a construct you must keep out of design code.下表每一列在精神上都掛著 not synthesisable 徽章；本頁全篇都用這個徽章標示那些你必須擋在設計碼之外的構件。下表の各行は、精神としては not synthesisable のバッジを掲げている。このバッジは本ページ全体で、設計コードから締め出さねばならない構文要素を示すために使う。

Two items on that list are worth a second look because students meet them constantly. The first is ===. Its attraction is obvious: you want to test "is this bus still unknown?" and == will not do it, because x == 1'b0 evaluates to x, not to false. But the hardware question is meaningless. Every physical node has a voltage. If you find yourself wanting === in design code, what you actually want is a valid bit — an explicit signal that says whether the data is meaningful — which is precisely the role of valid_data in the priority encoder of Section 8.3. That is the design pattern the lecture is quietly teaching by including that output.清單上有兩個項目值得再看一眼，因為學生不斷遇到它們。第一個是 ===。它的吸引力很明顯：你想測試「這條匯流排還是未知的嗎？」，而 == 辦不到，因為 x == 1'b0 的結果是 x，不是 false。但這個問題在硬體上沒有意義。每一個實體節點都有電壓。如果你發現自己在設計碼裡想用 ===，你真正想要的是一個 valid 位元——一條明確說明資料是否有意義的訊號——那正是第 8.3 節優先權編碼器裡 valid_data 扮演的角色。本講把那個輸出放進來，其實就是在默默教這個設計樣式。この一覧の中で、学生が絶えず出会う二つの項目はもう一度見ておく価値がある。一つ目は === である。魅力は明らかで、「このバスはまだ不定か」を調べたいのに == では足りない。x == 1'b0 は false ではなく x になるからだ。しかしハードウェアとしてはこの問いに意味がない。物理的なノードにはすべて電圧がある。設計コードで === が欲しくなったとき、本当に欲しいのは valid ビット、すなわちデータが有意かどうかを明示する信号であり、それこそが第 8.3 節のプライオリティエンコーダにおける valid_data の役割である。あの出力を含めることで、講義は静かにこの設計パターンを教えている。

The second is initial. In an FPGA flow initial often does synthesise, because the configuration bitstream can set a LUT's register at load time. In a standard-cell ASIC flow it does not, because there is no mechanism to put a flop into a known state except a reset input tied to a reset network. Students who learned Verilog on an FPGA board carry this habit into an ASIC course and are surprised when a register comes up unknown. The lecture's list is the ASIC list; believe it.第二個是 initial。在 FPGA 流程裡 initial 常常真的能合成，因為組態位元流可以在載入時設定 LUT 的暫存器。在標準元件 ASIC 流程裡則不行，因為除了接到重置網路的重置輸入之外，沒有任何機制能把一個正反器放進已知狀態。在 FPGA 板子上學會 Verilog 的學生把這個習慣帶進 ASIC 課程，然後對暫存器上電後是未知值感到驚訝。本講的清單是 ASIC 的清單；請相信它。二つ目は initial である。FPGA のフローでは initial が実際に合成されることが多い。コンフィギュレーションのビットストリームがロード時に LUT のレジスタを設定できるからだ。標準セル ASIC のフローではそうはいかない。リセット網につながったリセット入力以外に、フリップフロップを既知の状態に置く手段がないからである。FPGA ボードで Verilog を覚えた学生はこの習慣を ASIC の講義に持ち込み、レジスタが不定で立ち上がることに驚く。本講義の一覧は ASIC の一覧である。信じてよい。

2.3 How a violation actually shows up2.3 違規實際上是怎麼浮現的2.3 違反は実際にどう現れるか

Knowing the lists is examinable; knowing what the tool prints when you break them is what saves you an afternoon. There are three distinct failure modes and they look nothing alike.知道這些清單是考得出來的；知道你違反它們時工具會印出什麼，才是替你省下一個下午的東西。失效模式有三種，彼此長得完全不一樣。一覧を知っていることは試験に出る。だが午後を一つ節約してくれるのは、それを破ったときツールが何を出力するかを知っていることである。失敗の形は三つあり、互いにまったく似ていない。

A hard error. The tool refuses to elaborate. This is what you get for fork ... join, for a while loop with a non-constant bound, or for a sequential UDP. The message names the file and line. This is the best outcome, because it is impossible to ignore.硬錯誤。工具拒絕展開。fork ... join、界限非常數的 while 迴圈，或序向 UDP 都會得到這個結果。訊息會指出檔名與行號。這是最好的結果，因為你不可能忽略它。ハードエラー。ツールがエラボレーションを拒否する。fork ... join、境界が定数でない while ループ、順序 UDP などがこれに当たる。メッセージはファイル名と行番号を示す。無視しようがないので、これが最良の結末である。

A warning plus silent removal. This is what you get for delays and for most system tasks. Design Compiler emits something in the family of "Delays are ignored for synthesis" and carries on. Your netlist is now a different circuit from your RTL in a way nothing downstream will flag, because formal equivalence checking also ignores delays. The only thing that catches this is a human reading the log, which is why mature projects treat the synthesis log as a build artefact and fail the build on unexpected warning categories.警告加上無聲移除。延遲與大部分系統任務會得到這個結果。Design Compiler 會吐出類似「Delays are ignored for synthesis」這一類的訊息，然後繼續跑下去。此刻你的網表已經是一個與你的 RTL 不同的電路，而且下游不會有任何東西標示出來，因為形式等價驗證同樣忽略延遲。唯一能抓到這件事的，是一個讀 log 的人，這就是為什麼成熟的專案把合成 log 當成建置產物，並在出現非預期的警告類別時讓建置失敗。警告つきの暗黙の削除。遅延と大半のシステムタスクがこれに当たる。Design Compiler は「Delays are ignored for synthesis」の類のメッセージを出して先へ進む。この時点でネットリストはすでに RTL とは別の回路になっているが、下流の誰もそれを指摘しない。形式等価検証も遅延を無視するからだ。これを捕まえられるのはログを読む人間だけであり、だからこそ成熟したプロジェクトは合成ログをビルド成果物として扱い、想定外の警告カテゴリが出たらビルドを落とす。

A warning plus an unintended structure. This is the dangerous one, and it is the subject of Sections 6 and 7. The tool does not fail and does not remove anything; it builds something. An incomplete case produces a latch and a message of the form Warning: ... is being inferred as a latch, or in Design Compiler's dialect an entry in the "Inferred memory devices" table in the elaboration report, with a column headed Latch containing a tick. A self-assignment produces a combinational loop and a message about a feedback path that cannot be analysed. In both cases the design proceeds, builds, places, routes, and fails much later and much more expensively.警告加上非預期的結構。這個才危險，也正是第 6 節與第 7 節的主題。工具不失敗，也不移除任何東西；它造了一個東西出來。一個不完整的 case 會產生一個鎖存器，以及形如 Warning: ... is being inferred as a latch 的訊息，或者用 Design Compiler 的方言，是展開報告裡「Inferred memory devices」表格中的一列，Latch 欄位打了勾。一個自我賦值會產生組合迴路，以及一則關於「有一條無法分析的回授路徑」的訊息。這兩種情況下，設計都會繼續往下走，建置、擺放、繞線，然後在很久以後、以貴得多的代價失敗。警告つきの意図しない構造。これが危険なものであり、第 6 節と第 7 節の主題である。ツールは失敗もせず、何も削除せず、何かを作ってしまう。不完全な case はラッチと Warning: ... is being inferred as a latch の形のメッセージを生む。Design Compiler の方言では、エラボレーションレポートの「Inferred memory devices」表に一行が現れ、Latch の欄にチェックが入る。自己代入は組合せループと、解析できないフィードバック経路に関するメッセージを生む。いずれの場合も設計はそのまま進み、ビルドされ、配置され、配線され、ずっと後で、ずっと高い代償を伴って失敗する。

3. Logic Minimisation: Two-Level and Multi-Level3. 邏輯最小化：兩層式與多層式3. 論理最小化：二段と多段

3.1 The objective function: area, delay, power3.1 目標函數：面積、延遲、功耗3.1 目的関数：面積・遅延・消費電力

The slide says the synthesis target is to minimise area, delay or power. The word "or" is doing a lot of work. These three quantities are not independent, and they are not simultaneously minimisable; what the tool actually solves is a constrained optimisation, almost always of the form minimise area subject to meeting a delay constraint. You supply the delay constraint as a clock period and a set of input and output delays; the tool treats it as a hard requirement until it proves it cannot be met, and spends every remaining degree of freedom on area.投影片說合成的目標是最小化面積、延遲或功耗。這個「或」字擔了很重的責任。這三個量並不獨立，也不可能同時最小化；工具實際求解的是一個有約束的最佳化問題，而且幾乎一定是在滿足延遲約束的前提下把面積最小化這種形式。你以一個時脈週期加上一組輸入與輸出延遲提供延遲約束；工具把它當成硬性要求，直到它證明自己做不到為止，剩下的所有自由度全都花在面積上。スライドは合成の目標を面積・遅延・消費電力の最小化だと述べる。この「または」という語は重い仕事をしている。三つの量は独立ではなく、同時に最小化することもできない。ツールが実際に解いているのは制約付き最適化であり、ほぼ必ず遅延制約を満たしたうえで面積を最小化するという形をとる。遅延制約はクロック周期と入出力遅延の集合として与える。ツールはそれを満たせないと証明するまで厳格な要求として扱い、残る自由度をすべて面積に注ぎ込む。

It helps to have concrete units in mind. In a standard-cell library, area is reported in square microns, but it is more useful to think in gate equivalents: one GE is the area of a minimum-drive two-input NAND. A two-input NAND is 1 GE by definition, an inverter is about 0.67 GE, a two-input XOR about 2 GE, a 2:1 multiplexer about 2.3 GE per bit, a D flip-flop about 5 GE, and a D latch about 3.5 GE. Delay is reported in nanoseconds or picoseconds through characterised arcs, but for reasoning at the RTL level it is enough to count levels of logic, where one level is roughly one simple gate delay. Power splits into dynamic power, proportional to $\alpha C V^2 f$ where $\alpha$ is the switching activity, and leakage, which is proportional to total transistor width and therefore, to first order, to area.腦中有具體的單位會很有幫助。在標準元件庫裡，面積以平方微米回報，但更有用的想法是用閘當量（gate equivalent, GE）：1 GE 是一個最小驅動力的二輸入 NAND 的面積。依定義二輸入 NAND 是 1 GE，反相器約 0.67 GE，二輸入 XOR 約 2 GE，2:1 多工器每位元約 2.3 GE，D 正反器約 5 GE，D 鎖存器約 3.5 GE。延遲透過特徵化的時序弧以奈秒或皮秒回報，但在 RTL 層級推理時，數邏輯層數就夠了，一層大致就是一個簡單閘的延遲。功耗分成動態功耗，與 $\alpha C V^2 f$ 成正比，其中 $\alpha$ 是切換活動率；以及漏電，它與電晶體總寬度成正比，因此一階來說也就與面積成正比。具体的な単位を頭に入れておくとよい。標準セルライブラリでは面積は平方マイクロメートルで報告されるが、ゲート等価（gate equivalent, GE）で考えるほうが役に立つ。1 GE は最小駆動力の 2 入力 NAND の面積である。定義により 2 入力 NAND は 1 GE、インバータは約 0.67 GE、2 入力 XOR は約 2 GE、2:1 マルチプレクサは 1 ビットあたり約 2.3 GE、D フリップフロップは約 5 GE、D ラッチは約 3.5 GE である。遅延は特性化されたアークを通じてナノ秒やピコ秒で報告されるが、RTL のレベルで考えるには論理の段数を数えれば十分で、1 段はおよそ単純なゲート 1 個の遅延に当たる。消費電力は、$\alpha C V^2 f$ に比例する動的電力（$\alpha$ はスイッチング活性度）と、トランジスタの総幅に比例し、したがって一次近似では面積に比例するリークとに分かれる。

This is why minimising area usually also minimises leakage, while minimising delay often costs both: the fast version of a function uses more parallel structure (more cells, more area, more leakage) and higher-drive cells (wider transistors, more leakage and more dynamic power). The three objectives in the slide are really one objective with two constraints, and your job as the RTL author is to make sure the structure you describe does not force the tool into a corner where no good trade-off exists.這就是為什麼把面積最小化通常也會把漏電最小化，而把延遲最小化卻常常兩頭都付代價：同一個函數的快速版本會用上更多平行結構（更多元件、更多面積、更多漏電）以及驅動力更強的元件（更寬的電晶體、更多漏電、也更多動態功耗）。投影片上的三個目標其實是一個目標加上兩個約束，而身為 RTL 作者，你的工作是確保你所描述的結構不會把工具逼進一個不存在好取捨的死角。面積の最小化がたいていリークの最小化も兼ねるのに対し、遅延の最小化はしばしば両方を犠牲にする理由がここにある。同じ関数の高速版は、より並列な構造（セルが増え、面積が増え、リークが増える）と、駆動力の高いセル（トランジスタが広く、リークも動的電力も増える）を使うからだ。スライドの三つの目標は、実際には一つの目標と二つの制約である。RTL を書く者の仕事は、記述した構造がツールを「良いトレードオフが存在しない隅」へ追い込まないようにすることである。

3.2 Two-level minimisation and why it stopped being enough3.2 兩層式最小化，以及它為何不再夠用3.2 二段の最小化と、それが足りなくなった理由

Two-level minimisation puts a function into sum-of-products form with the fewest product terms and the fewest literals. You met the algorithms in an earlier logic design course: Karnaugh maps for up to about five variables, Quine–McCluskey for exact minimisation at small scale, and Espresso-style heuristics for anything real. The result is a two-level AND-OR structure, which has exactly two levels of logic and is therefore as fast as a given function can be made in that style.兩層式最小化把一個函數化成乘積項最少、文字數最少的積項和形式。這些演算法你在更早的邏輯設計課上見過：五個變數以內用卡諾圖，小規模的精確最小化用 Quine–McCluskey，實際規模的東西則用 Espresso 式的啟發法。結果是一個兩層的 AND-OR 結構，它恰好有兩層邏輯，因此在那種風格下已經是一個函數能做到的最快。二段の最小化は、関数を積項数とリテラル数が最小の積和形にする。アルゴリズムは以前の論理設計の講義で習っているはずだ。変数が 5 個程度までならカルノー図、小規模な厳密最小化なら Quine–McCluskey、現実的な規模なら Espresso 系のヒューリスティックである。得られるのは 2 段の AND-OR 構造で、論理段数がちょうど 2 段しかないため、そのスタイルで作れる限り最速である。

Two-level form is the natural target for a PLA or a PLD, where the hardware physically is an AND plane feeding an OR plane. For standard cells it is nearly always wrong. Consider the parity of eight bits, $P = x_0 \oplus x_1 \oplus \cdots \oplus x_7$. Its minimal sum of products has 128 product terms of eight literals each — 1024 literals — because every odd-parity minterm is a prime implicant and none of them merge. The multi-level form is seven XOR gates, about 14 GE, with three levels of delay if you balance the tree. The ratio between the two implementations is roughly a hundred to one. Parity is an extreme case, but the direction of the effect is universal: two-level minimisation optimises the wrong cost function for cell-based design.兩層形式對 PLA 或 PLD 是自然的目標，因為那裡的硬體實體上就是一個 AND 平面餵給一個 OR 平面。對標準元件而言，它幾乎永遠是錯的。考慮八個位元的奇偶校驗 $P = x_0 \oplus x_1 \oplus \cdots \oplus x_7$。它的最小積項和有 128 個乘積項，每項八個文字——總共 1024 個文字——因為每一個奇同位最小項都是質蘊涵項，而且彼此無法合併。多層形式則是七個 XOR 閘，大約 14 GE，如果把樹配平，延遲是三層。兩種實作的比值大約是一百比一。奇偶校驗是極端案例，但效應的方向是普遍的：對 cell-based 設計而言，兩層式最小化最佳化的是錯誤的成本函數。二段形式は PLA や PLD にとっては自然な目標である。そこではハードウェアが物理的に AND 面と OR 面でできているからだ。標準セルに対しては、ほぼ常に誤りである。8 ビットのパリティ $P = x_0 \oplus x_1 \oplus \cdots \oplus x_7$ を考えよう。その最小積和形は 8 リテラルの積項を 128 個、合計 1024 リテラル持つ。奇パリティの最小項はすべて主項であり、どれも併合できないからだ。多段形式なら XOR ゲート 7 個、約 14 GE で、木をバランスさせれば遅延は 3 段である。二つの実装の比はおよそ 100 対 1 になる。パリティは極端な例だが、効果の向きは普遍的である。セルベース設計にとって、二段の最小化は誤った費用関数を最適化している。

This is the practical reason the slide's flow diagram puts "two-level logic functions" as the output of translation and "optimised multi-level logic" as the output of optimisation. Two-level form is an intermediate representation — a canonical starting point that is easy to produce from the parse tree and easy to manipulate — not a goal.這就是投影片的流程圖為什麼把「兩層邏輯函數」放在翻譯的輸出、把「最佳化後的多層邏輯」放在最佳化的輸出的實務理由。兩層形式是一種中間表示法——一個容易從剖析樹產生、也容易操作的標準起點——而不是目標。スライドのフロー図が「二段の論理関数」を翻訳の出力とし、「最適化された多段論理」を最適化の出力としている実務上の理由はここにある。二段形式は中間表現であり、構文木から作りやすく扱いやすい正準的な出発点であって、目標ではない。

3.3 The five multi-level operations, worked3.3 多層的五個操作，實際演練3.3 多段の五つの操作を実際にやってみる

Multi-level minimisation is a sequence of local rewrites on a Boolean network, where a network is a directed acyclic graph of nodes, each node holding a Boolean expression over the primary inputs and over other nodes. The cost function is usually literal count, because literal count correlates well with transistor count in a static CMOS library. The lecture lists five rewrite operations. Each one is a move in a search; the tool applies them repeatedly, accepting a move when it improves the cost and sometimes when it does not, in the manner of any local-search optimiser.多層最小化是在一個布林網路上進行的一連串區域改寫，其中網路是一個有向無環圖，每個節點持有一個以主要輸入與其他節點為變數的布林運算式。成本函數通常是文字數，因為在靜態 CMOS 元件庫裡，文字數與電晶體數相關性很好。本講列出五個改寫操作。每一個都是搜尋中的一步棋；工具反覆施加它們，當一步棋改善成本時接受它，有時即使沒改善也接受——就像任何區域搜尋最佳化器一樣。多段の最小化は、ブール・ネットワーク上の局所的な書き換えの列である。ネットワークとは有向非巡回グラフで、各ノードが主入力と他ノードを変数とするブール式を保持する。費用関数は通常リテラル数である。静的 CMOS のライブラリではリテラル数がトランジスタ数とよく相関するからだ。講義は五つの書き換え操作を挙げる。どれも探索における一手であり、ツールはこれらを繰り返し適用して、費用が改善すれば受け入れ、ときには改善しなくても受け入れる。局所探索型の最適化器がどれもそうするのと同じである。

Decomposition — one node becomes several分解（Decomposition）—— 一個節點變成好幾個分解（Decomposition）—— 一つのノードが複数になる

Decomposition takes a single complicated node and replaces it with a small expression over new intermediate nodes. The slide's example:分解把一個複雜的單一節點，換成一個以新的中間節點為變數的小運算式。投影片的例子：分解は、一つの複雑なノードを、新しい中間ノードを変数とする小さな式に置き換える。スライドの例を示す。

The algebra is worth doing by hand, because this is a standard exam question. The first two terms give $abc + abd = ab(c+d) = XY$. The last two give $a'c'd' + b'c'd' = (a'+b')c'd'$. Now apply De Morgan twice: $a'+b' = (ab)' = X'$, and $c'd' = (c+d)' = Y'$. So the last two terms are $X'Y'$, and $F = XY + X'Y'$, which is the XNOR $X \odot Y$. Count the cost. Before: four products, twelve literals, and if you build it flat you need four AND gates (three of width three, counting inversions) and one four-input OR — call it nine or ten gate equivalents. After: one two-input AND for $X$, one two-input OR for $Y$, one two-input XNOR for $F$ — about 4 GE. The literal count went from twelve to six, and the gate count more than halved.這段代數值得親手算一遍，因為這是標準的考題。前兩項給出 $abc + abd = ab(c+d) = XY$。後兩項給出 $a'c'd' + b'c'd' = (a'+b')c'd'$。接著用兩次笛摩根定律：$a'+b' = (ab)' = X'$，而 $c'd' = (c+d)' = Y'$。所以後兩項就是 $X'Y'$，於是 $F = XY + X'Y'$，也就是 XNOR $X \odot Y$。算一下成本。之前：四個乘積項、十二個文字，若攤平建造需要四個 AND 閘（其中三個是三輸入，含反相計入）加一個四輸入 OR——算九到十個閘當量。之後：一個二輸入 AND 產生 $X$、一個二輸入 OR 產生 $Y$、一個二輸入 XNOR 產生 $F$——大約 4 GE。文字數從十二降到六，閘數減少超過一半。この代数は手で一度追ってみる価値がある。標準的な試験問題だからだ。最初の二項は $abc + abd = ab(c+d) = XY$ を与える。後の二項は $a'c'd' + b'c'd' = (a'+b')c'd'$ となる。ここでド・モルガンを二度使うと、$a'+b' = (ab)' = X'$、$c'd' = (c+d)' = Y'$ である。よって後の二項は $X'Y'$ となり、$F = XY + X'Y'$、すなわち XNOR $X \odot Y$ である。コストを数えよう。前：積項 4 個、リテラル 12 個。平坦に作れば AND ゲート 4 個（うち 3 個は反転を数えて 3 入力）と 4 入力 OR 1 個、おおよそ 9〜10 ゲート等価である。後：$X$ のための 2 入力 AND 1 個、$Y$ のための 2 入力 OR 1 個、$F$ のための 2 入力 XNOR 1 個で、約 4 GE。リテラル数は 12 から 6 に、ゲート数は半分以下になった。

Notice what decomposition cost: a logic level. The flat form was two levels (AND then OR). The decomposed form is two levels to produce $X$ and $Y$, then one more for the XNOR — three levels. This is the universal trade in multi-level work and it is why the tool needs a delay constraint before it can decide whether a decomposition is a good idea.注意分解付出了什麼代價：一層邏輯。攤平的形式是兩層（先 AND 後 OR）。分解後的形式是兩層產生 $X$ 與 $Y$，再一層做 XNOR——三層。這是多層工作中普遍存在的交易，也是為什麼工具必須先拿到延遲約束，才能決定一次分解是不是好主意。分解が何を支払ったかに注目したい。論理が 1 段増えている。平坦な形は 2 段（AND のあと OR）であった。分解後は $X$ と $Y$ を作るのに 2 段、XNOR にもう 1 段で 3 段になる。これは多段最適化における普遍的な取引であり、ある分解が良い手かどうかを決める前にツールが遅延制約を必要とする理由でもある。

Extraction — several nodes share a new one抽出（Extraction）—— 多個節點共用一個新節點抽出（Extraction）—— 複数のノードが新しい一つを共有する

Extraction is decomposition applied across functions: find a sub-expression that appears in more than one function and factor it out once. The slide's example has three outputs.抽出就是跨函數施行的分解：找出一個在一個以上函數中出現的子運算式，把它提出來只做一次。投影片的例子有三個輸出。抽出は、関数をまたいで適用する分解である。複数の関数に現れる部分式を見つけ、一度だけ作るようくくり出す。スライドの例には出力が三つある。

Count literals. Before: $F$ has five ($a, b, c, d, e$), $G$ has three, $H$ has three — eleven in total, with the OR $(a+b)$ built twice and the AND $cd$ built twice. After: $X$ has two, $Y$ has two, $F$ has three, $G$ has two, $H$ has two — eleven literals again, but the structure now contains one OR gate and one AND gate instead of two of each. Literal count is a crude proxy; what extraction really bought is sharing, which literal counting on the flattened form does not see. This is the single most valuable optimisation in real designs, because real designs are full of repeated address decodes, repeated comparisons against the same constant, and repeated enable terms.數一數文字。之前：$F$ 有五個（$a, b, c, d, e$），$G$ 有三個，$H$ 有三個——總共十一個，而且 OR $(a+b)$ 造了兩次，AND $cd$ 也造了兩次。之後：$X$ 有兩個，$Y$ 有兩個，$F$ 有三個，$G$ 有兩個，$H$ 有兩個——還是十一個文字，但結構裡現在只有一個 OR 閘與一個 AND 閘，而不是各兩個。文字數是個粗糙的代理指標；抽出真正買到的是共用，而在攤平形式上數文字數是看不到共用的。這是真實設計中最有價值的單一最佳化，因為真實設計裡滿是重複的位址解碼、對同一個常數重複的比較，以及重複的致能項。リテラルを数えよう。前：$F$ は 5 個（$a, b, c, d, e$）、$G$ は 3 個、$H$ は 3 個で合計 11 個。しかも OR $(a+b)$ を 2 回、AND $cd$ を 2 回作っている。後：$X$ が 2 個、$Y$ が 2 個、$F$ が 3 個、$G$ が 2 個、$H$ が 2 個で、やはり 11 リテラルである。しかし構造の側では OR ゲートと AND ゲートがそれぞれ 2 個から 1 個になっている。リテラル数は粗い代理指標にすぎない。抽出が本当に買ったのは共有であり、平坦形のリテラルを数えるだけではそれが見えない。これは実際の設計で最も価値のある単一の最適化である。現実の設計は、繰り返し現れるアドレスデコード、同じ定数との繰り返しの比較、繰り返しのイネーブル項であふれているからだ。

Extraction is also the reason you should not hand-optimise your RTL into unreadable Boolean algebra. If you write the same comparison in five places, the tool will extract it once. If you write it once into a named wire, it is extracted by construction and your code is readable. Both get the same netlist; only one gets reviewed successfully.抽出也是你不該把自己的 RTL 手動最佳化成難讀的布林代數的理由。如果你在五個地方寫同一個比較，工具會把它抽出成一個。如果你把它寫一次成為一條具名的 wire，那它在構造上就已經被抽出了，而且你的程式碼可讀。兩種寫法得到同一份網表；但只有一種能順利通過程式碼審查。抽出は、RTL を読めないブール代数へ手で最適化すべきでない理由でもある。同じ比較を五か所に書けば、ツールはそれを一つに抽出する。名前付きの wire に一度だけ書けば、構成上すでに抽出されており、しかもコードは読める。どちらも同じネットリストになるが、レビューを通るのは片方だけである。

Factoring — flat SOP becomes a nested product因式分解（Factoring）—— 攤平的 SOP 變成巢狀的乘積因数分解（Factoring）—— 平坦な SOP が入れ子の積になる

Nine literals become five. Structurally, four two-input ANDs plus a five-input OR (about 7–8 GE) become two two-input ORs, one two-input AND and one two-input OR (about 4 GE). Delay goes from two levels to three. Factoring is the move that most directly converts area into delay, and it is the move whose result most resembles what a human would have written in the first place — which is the point of the next callout.九個文字變成五個。結構上，四個二輸入 AND 加一個五輸入 OR（約 7–8 GE）變成兩個二輸入 OR、一個二輸入 AND 與一個二輸入 OR（約 4 GE）。延遲從兩層變三層。因式分解是最直接把面積換成延遲的一步棋，也是結果最像人類一開始就會寫出來的那種形式的一步棋——這正是下一個提示框的重點。9 リテラルが 5 リテラルになる。構造的には、2 入力 AND 4 個と 5 入力 OR 1 個（約 7〜8 GE）が、2 入力 OR 2 個、2 入力 AND 1 個、2 入力 OR 1 個（約 4 GE）になる。遅延は 2 段から 3 段へ増える。因数分解は面積を遅延に換える最も直接的な一手であり、その結果が、そもそも人間なら最初からこう書いたであろう形に最もよく似た一手でもある。次のコールアウトの要点はそこにある。

Substitution — reuse a function that already exists代入（Substitution）—— 重用一個已經存在的函數代入（Substitution）—— すでにある関数を再利用する

Substitution differs from extraction in that the shared node already exists; the tool is noticing that an existing output happens to be a useful sub-function of another output. The literal count of $F$ drops from three to two and the three-input OR becomes a two-input OR. In a real design this move is what makes a carry chain reusable, or lets a comparator's equality output feed a greater-than-or-equal output. Its risk is that it lengthens the path through $G$: whatever drove $G$ now also drives $F$, so $G$'s fanout grows and its arrival time now appears on $F$'s path. If $G$ is on the critical path, substitution into $F$ can make $F$ critical too.代入與抽出的差別在於，那個被共用的節點已經存在了；工具注意到的是某個既有輸出碰巧是另一個輸出的有用子函數。$F$ 的文字數從三降到二，三輸入 OR 變成二輸入 OR。在真實設計中，這一步棋讓進位鏈可以被重用，或讓一個比較器的相等輸出去餵它的大於等於輸出。它的風險是會拉長穿過 $G$ 的路徑：原本驅動 $G$ 的東西現在也驅動 $F$，所以 $G$ 的扇出變大，而且它的到達時間現在出現在 $F$ 的路徑上。如果 $G$ 在關鍵路徑上，把它代入 $F$ 可能讓 $F$ 也變成關鍵路徑。代入が抽出と異なるのは、共有されるノードがすでに存在している点である。ツールは、既存の出力がたまたま別の出力の有用な部分関数になっていることに気づくのだ。$F$ のリテラル数は 3 から 2 に減り、3 入力 OR が 2 入力 OR になる。実際の設計では、この一手によってキャリーチェーンが再利用できるようになったり、比較器の等価出力が「以上」の出力を駆動できるようになったりする。リスクは $G$ を通る経路が長くなることである。$G$ を駆動していたものが $F$ も駆動するようになるので $G$ のファンアウトが増え、その到着時刻が $F$ の経路に現れる。$G$ がクリティカルパス上にあれば、$F$ への代入は $F$ までクリティカルにしかねない。

Elimination — the inverse move消去（Elimination）—— 反向的一步棋消去（Elimination）—— 逆向きの一手

Elimination collapses a node back into its users. Verify it: $Ga = (c+d)a = ac+ad$, and $G'b = (c+d)'b = c'd'b$ by De Morgan, giving $F = ac + ad + bc'd'$. Literal count went from four (in $F$) plus two (in $G$) to seven. Area got worse. What got better is depth: $F$ no longer waits for $G$. Elimination is the tool's main weapon against a critical path, and it is applied selectively — eliminate the node that sits on the worst path, keep the others shared.消去把一個節點塌回它的使用者裡。驗證一下：$Ga = (c+d)a = ac+ad$，而由笛摩根定律 $G'b = (c+d)'b = c'd'b$，於是 $F = ac + ad + bc'd'$。文字數從（$F$ 裡的）四個加上（$G$ 裡的）兩個，變成七個。面積變差了。變好的是深度：$F$ 不再等 $G$。消去是工具對付關鍵路徑的主要武器，而且是有選擇性地施加——消去那個落在最差路徑上的節點，其餘的保持共用。消去はノードをその利用者の中へ畳み込む。検算しよう。$Ga = (c+d)a = ac+ad$ であり、ド・モルガンにより $G'b = (c+d)'b = c'd'b$ なので、$F = ac + ad + bc'd'$ となる。リテラル数は（$F$ の）4 個と（$G$ の）2 個の計 6 個から 7 個に増えた。面積は悪化した。良くなったのは深さである。$F$ はもう $G$ を待たない。消去はクリティカルパスに対するツールの主力武器であり、選択的に適用される。最悪経路に乗っているノードを消去し、それ以外は共有したまま残すのだ。

3.4 A worked optimisation session3.4 一次完整的最佳化演練3.4 最適化セッションの実演

Two lessons from that session carry into every design. First, the mapper prefers inverting cells, so your mental model of "AND gate, OR gate" overestimates both area and delay; a NAND-NAND implementation of an AND-OR function is faster and smaller, and the mapper will find it. Second, the win came from extraction across the three outputs, not from clever algebra on one of them. Write all related outputs in one module and let the tool share; splitting them into three modules and disabling cross-boundary optimisation would have cost you three XNORs.這次演練有兩個教訓貫串每一個設計。第一，映射器偏好反相元件，所以你腦中「AND 閘、OR 閘」的模型會同時高估面積與延遲；以 NAND-NAND 實現一個 AND-OR 函數更快也更小，而映射器會找到它。第二，贏面來自跨三個輸出的抽出，不是來自對其中一個輸出耍聰明的代數。把所有相關的輸出寫在同一個模組裡，讓工具去共用；把它們拆成三個模組並關掉跨邊界最佳化，會讓你多付三個 XNOR。この実演から、どの設計にも通じる教訓が二つ得られる。第一に、マッパは反転セルを好むので、「AND ゲート、OR ゲート」という頭の中のモデルは面積も遅延も過大評価する。AND-OR 関数の NAND-NAND 実装のほうが速く小さく、マッパはそれを見つける。第二に、勝ちをもたらしたのは三つの出力にまたがる抽出であって、どれか一つに対する巧妙な代数ではない。関連する出力はすべて同じモジュールに書き、共有はツールに任せること。三つのモジュールに分割して境界越えの最適化を切れば、XNOR を三つ余計に払うことになる。

4. Five Ways to Describe Combinational Logic4. 描述組合邏輯的五種方式4. 組合せ論理を記述する五つの方法

The lecture lists six synthesisable description styles: a netlist of Verilog primitives, a combinational UDP, a continuous assignment, a behavioural always block, a function, and a task without delay or event control — plus, trivially, any interconnection of modules built from these. It then demonstrates five of them on the same tiny function, which is the pedagogically important part: five different-looking source files, one identical netlist.本講列出六種可合成的描述風格：Verilog 原件組成的網表、組合邏輯 UDP、連續賦值、行為式 always 區塊、function，以及不含延遲或事件控制的 task——另外還有一個顯而易見的：由這些東西組成的任何模組互連。接著它在同一個極小的函數上示範其中五種，而這才是教學上重要的部分：五份長得完全不同的原始檔，一份一模一樣的網表。講義は合成可能な記述スタイルを六つ挙げる。Verilog プリミティブのネットリスト、組合せ論理 UDP、連続代入、行動記述の always ブロック、function、そして遅延やイベント制御を含まない task である。さらに自明なものとして、これらから作ったモジュールの任意の相互接続もある。続いて講義は、そのうち五つを同じごく小さな関数で実演する。教育的に重要なのはそこで、見た目のまるで違う五つのソースから、同一のネットリストが出てくるのだ。

The point being made is that synthesis is not transliteration. The tool does not emit one gate per operator you typed. It extracts the Boolean function, optimises it, and maps it. Five syntactically different descriptions of the same function therefore converge on the same cells. If you take one thing from this section, take that: the style you choose affects readability, simulation speed and your own error rate, but — within the synthesisable subset, for a function with no state — it does not affect the hardware.這裡要講的重點是合成不是逐字轉寫。工具不會為你打的每一個運算子吐出一個閘。它抽取布林函數、最佳化它、再映射它。因此同一個函數的五種語法上不同的描述，會收斂到同一組元件。如果你從本節只帶走一件事，請帶走這件：你選的風格會影響可讀性、模擬速度與你自己的出錯率，但是——在可合成子集內、對一個沒有狀態的函數而言——它不影響硬體。ここでの要点は合成は逐語的な書き換えではないということである。ツールはあなたが打った演算子ごとにゲートを一つ出力したりはしない。ブール関数を抽出し、最適化し、マッピングする。したがって同じ関数の構文的に異なる五つの記述は、同じセルの集合に収束する。本節から一つだけ持ち帰るなら、これにしてほしい。選んだスタイルは可読性・シミュレーション速度・自分のミス率には効くが、合成可能な部分集合の中で状態を持たない関数に対しては、ハードウェアには効かない。

4.1 Netlist of primitives: the structural floor4.1 原件組成的網表：結構的地板4.1 プリミティブのネットリスト：構造の最下層

module or_nand_1 (enable, x1, x2, x3, x4, y);
  input  enable, x1, x2, x3, x4;
  output y;
  wire   w1, w2, w3;
  or   (w1, x1, x2);
  or   (w2, x3, x4);
  or   (w3, x3, x4);              // redundant: identical to w2
  nand (y, w1, w2, w3, enable);
endmodule

Gate primitives take the output first and the inputs after, so or (w1, x1, x2) means w1 = x1 | x2. This module describes a circuit with four gates. The synthesised result has two cells.邏輯閘原件把輸出寫在前、輸入寫在後，所以 or (w1, x1, x2) 的意思是 w1 = x1 | x2。這個模組描述的是一個有四個閘的電路。合成的結果有兩個元件。ゲートプリミティブは出力を先に、入力を後に書く。したがって or (w1, x1, x2) は w1 = x1 | x2 を意味する。このモジュールが記述しているのはゲート 4 個の回路である。合成結果はセル 2 個になる。

What happened to the other two? The w3 gate computes exactly what w2 computes, and both feed the same NAND. The optimiser recognises $w_2 \cdot w_3 = w_2$ by idempotence and deletes the duplicate; this is an elementary redundancy removal that happens in the first sweep. Then the remaining structure, $\overline{\text{enable}\cdot w_1 \cdot w_2}$ with $w_1 = x_1+x_2$ and $w_2 = x_3+x_4$, is matched against the library. A library almost always contains an OAI22 cell, which computes $\overline{(A_1+A_2)(B_1+B_2)}$ in a single stack of transistors, so the mapper produces $\overline{(x_1+x_2)(x_3+x_4)}$ in one cell and then needs $y = \overline{\text{enable} \cdot \overline{\text{OAI22 output}}}$, which is a two-input NAND with one inverted input — the slide's nand2i_a.另外兩個跑去哪了？w3 那個閘算的東西與 w2 完全一樣，而且兩者餵進同一個 NAND。最佳化器依冪等律認出 $w_2 \cdot w_3 = w_2$，於是刪掉重複的那個；這是第一輪掃描就會做掉的基本冗餘移除。接著剩下的結構 $\overline{\text{enable}\cdot w_1 \cdot w_2}$（其中 $w_1 = x_1+x_2$、$w_2 = x_3+x_4$）拿去與元件庫比對。元件庫幾乎一定含有一個 OAI22 元件，它以單一組電晶體堆疊算出 $\overline{(A_1+A_2)(B_1+B_2)}$，所以映射器用一個元件產生 $\overline{(x_1+x_2)(x_3+x_4)}$，然後還需要 $y = \overline{\text{enable} \cdot \overline{\text{OAI22 output}}}$，那是一個有一個反相輸入的二輸入 NAND——也就是投影片上的 nand2i_a。残る二つはどこへ行ったのか。w3 のゲートは w2 とまったく同じものを計算し、両者は同じ NAND を駆動している。最適化器は冪等律により $w_2 \cdot w_3 = w_2$ を認識して重複を削除する。これは最初のスイープで起きる初歩的な冗長性除去である。残った構造 $\overline{\text{enable}\cdot w_1 \cdot w_2}$（$w_1 = x_1+x_2$、$w_2 = x_3+x_4$）がライブラリと照合される。ライブラリはほぼ必ず OAI22 セルを備えており、これは $\overline{(A_1+A_2)(B_1+B_2)}$ を一つのトランジスタスタックで計算する。そこでマッパは $\overline{(x_1+x_2)(x_3+x_4)}$ を 1 セルで作り、続いて $y = \overline{\text{enable} \cdot \overline{\text{OAI22 output}}}$ が必要になる。これは入力が一つ反転した 2 入力 NAND、すなわちスライドの nand2i_a である。

Writing at primitive level is almost never a good idea in modern RTL, for three reasons. It is verbose, it is unreadable, and — the one that actually costs money — it prevents nothing. People reach for primitives believing they are "telling the tool exactly what to build", but as this example shows, the tool rewrites primitives as freely as it rewrites expressions. The only places structural primitives earn their keep are clock-gating cells and other instances you must not let the optimiser touch, and those you instantiate explicitly from the library with a dont_touch attribute, not as generic Verilog primitives.在現代 RTL 裡以原件層級書寫幾乎永遠不是好主意，理由有三。它囉嗦、它難讀，而且——真正花錢的那一點——它什麼也防不了。人們伸手去抓原件，以為自己是在「精確告訴工具要造什麼」，但正如這個例子所示，工具改寫原件就跟改寫運算式一樣自由。結構式原件唯一值得用的地方，是時脈閘控元件以及其他你不想讓最佳化器碰的實體，而那些你應該用 dont_touch 屬性從元件庫明確實體化，而不是寫成泛用的 Verilog 原件。現代の RTL でプリミティブのレベルで書くのは、ほぼ常に悪手である。理由は三つ。冗長で、読めず、そして実際にコストを生むのは、それで何も防げないことである。プリミティブに手を伸ばす人は「ツールに何を作るかを正確に伝えている」と信じているが、この例が示すとおり、ツールはプリミティブも式と同じくらい自由に書き換える。構造的プリミティブが元を取れる場所は、クロックゲーティングセルや、最適化器に触らせたくないその他のインスタンスだけである。そしてそれらは汎用の Verilog プリミティブではなく、dont_touch 属性を付けてライブラリから明示的にインスタンス化すべきものである。

4.2 Combinational UDP: a truth table as a module4.2 組合邏輯 UDP：把真值表寫成一個模組4.2 組合せ論理 UDP：真理値表をモジュールとして書く

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

A user-defined primitive declares one output and up to ten inputs and lists its behaviour as a table. The ? in an input column means "any of 0, 1 or x" — it is a don't care for matching purposes, not a value. Read the four rows: when $a=0$ the output follows $b$; when $a=1$ it follows $c$. That is $y = a'b + ac$, a 2:1 multiplexer with $a$ as the select. The slide's synthesis result is two AND gates and an OR, which is the textbook mux; a real library would use a transmission-gate MUX2 cell at about 2.3 GE.一個使用者自定原件宣告一個輸出與最多十個輸入，並以一張表格列出它的行為。輸入欄位裡的 ? 意思是「0、1 或 x 皆可」——它是比對用的不在意項，不是一個值。讀這四列：當 $a=0$ 時輸出跟著 $b$；當 $a=1$ 時跟著 $c$。那就是 $y = a'b + ac$，一個以 $a$ 為選擇線的 2:1 多工器。投影片的合成結果是兩個 AND 閘加一個 OR，也就是教科書上的多工器；真實的元件庫會用一個傳輸閘式的 MUX2 元件，約 2.3 GE。ユーザー定義プリミティブは出力を一つと最大 10 個の入力を宣言し、その振る舞いを表として列挙する。入力欄の ? は「0、1、x のいずれでもよい」を意味し、照合のためのドントケアであって値ではない。四つの行を読もう。$a=0$ のとき出力は $b$ に従い、$a=1$ のとき $c$ に従う。すなわち $y = a'b + ac$、$a$ を選択線とする 2:1 マルチプレクサである。スライドの合成結果は AND ゲート 2 個と OR 1 個、教科書どおりのマルチプレクサであるが、実際のライブラリなら約 2.3 GE のトランスミッションゲート型 MUX2 セルを使う。

Two rules make a UDP combinational rather than sequential, and both matter for the exam. First, the output must not be declared reg. Second, no row may contain an edge specifier such as (01) or r or f, and no row may have a three-field form with a current-state column. A table with either feature is a sequential UDP, which is explicitly on the un-synthesisable list, because it encodes arbitrary state-holding behaviour that no inference template matches.有兩條規則決定一個 UDP 是組合邏輯而不是序向的，而且兩條都會考。第一，輸出不得宣告為 reg。第二，任何一列都不得含有像 (01)、r 或 f 這類邊緣指定子，也不得出現帶有「現態」欄位的三欄形式。只要具備其中任一特徵，這張表就是序向 UDP，而它明確落在不可合成清單上，因為它編碼的是任何推論範本都比對不上的任意狀態保持行為。UDP が順序ではなく組合せになる条件は二つあり、どちらも試験に出る。第一に、出力を reg と宣言してはならない。第二に、どの行にも (01)、r、f のようなエッジ指定子があってはならず、現在状態の欄を持つ 3 欄形式の行があってもならない。どちらかの特徴を持つ表は順序 UDP であり、明確に合成不可の一覧に入る。どの推論テンプレートとも照合できない任意の状態保持の振る舞いを符号化しているからである。

UDPs are a legacy construct. They are worth understanding because they appear on exams and in old libraries, and because the combinational-versus-sequential distinction is a clean illustration of the inference principle. They are not worth writing: a case statement expresses the same table, is readable, simulates faster, and does not risk the sequential-UDP cliff.UDP 是遺留下來的構件。值得理解它們，因為它們出現在考題裡、也出現在老的元件庫裡，而且組合與序向之分是推論原則的一個乾淨示範。但不值得寫它們：一個 case 敘述能表達同一張表，可讀性更好，模擬更快，而且不會有掉下序向 UDP 懸崖的風險。UDP は遺産的な構文である。試験や古いライブラリに登場し、組合せと順序の区別が推論の原則をきれいに例示するので、理解しておく価値はある。だが自分で書く価値はない。case 文で同じ表を表現でき、読みやすく、シミュレーションも速く、順序 UDP の崖から落ちる危険もない。

4.3 Continuous assignment: the natural style for combinational logic4.3 連續賦值：組合邏輯最自然的風格4.3 連続代入：組合せ論理にとって自然なスタイル

module or_nand_2 (enable, x1, x2, x3, x4, y);
  input  enable, x1, x2, x3, x4;
  output y;
  assign y = ~(enable & (x1 | x2) & (x3 | x4));
endmodule

This is six lines instead of nine and it is impossible to misread. A continuous assignment drives a net from an expression, permanently; there is no sensitivity list to get wrong, no variable to leave unassigned on some path, and therefore no way to infer a latch. For any combinational function that fits comfortably in one expression, assign is the correct choice and the rest of this section is about when it stops fitting.這是六行而不是九行，而且不可能看錯。連續賦值用一個運算式永久地驅動一條網路；沒有敏感度列表可以寫錯，沒有變數會在某條路徑上沒被賦值，因此也就沒有辦法推論出鎖存器。任何一個組合邏輯函數只要能舒服地塞進一個運算式，assign 就是正確的選擇，而本節其餘部分談的是它什麼時候塞不下。こちらは 9 行ではなく 6 行で、読み違えようがない。連続代入は式でネットを恒久的に駆動する。間違えるセンシティビティリストはなく、どこかの経路で代入し忘れる変数もなく、したがってラッチが推論される余地もない。一つの式に無理なく収まる組合せ関数なら assign が正解であり、本節の残りは、それが収まらなくなるのはいつかという話である。

Two details are worth pinning down because they generate exam questions. First, the target of a continuous assignment must be a net (wire), never a reg. Second, the operators here are bitwise: ~, &, |. For the one-bit signals in this module, bitwise and logical operators coincide. For vectors they do not, and the difference is a classic source of silent bugs. If a is 4'b0010, then ~a is 4'b1101 but !a is 1'b0; and a & b is a four-bit AND while a && b is a single bit saying "both are non-zero". The slide's task version in Section 4.6 uses ! where the others use ~, which is harmless there and would be a bug on a vector.有兩個細節值得釘牢，因為它們會變成考題。第一，連續賦值的目標必須是一條 net（wire），絕不可以是 reg。第二，這裡的運算子是位元運算子：~、&、|。對這個模組裡的一位元訊號而言，位元運算子與邏輯運算子一致。對向量而言則不然，而這個差異是無聲錯誤的經典來源。如果 a 是 4'b0010，那麼 ~a 是 4'b1101，但 !a 是 1'b0；而 a & b 是四位元的 AND，a && b 卻是一個位元，說的是「兩者皆非零」。第 4.6 節投影片的 task 版本在其他版本用 ~ 的地方用了 !，在那裡無害，但對向量就會是錯誤。押さえておくべき細部が二つある。どちらも試験問題になる。第一に、連続代入の対象はネット（wire）でなければならず、reg であってはならない。第二に、ここで使われている演算子はビット単位の ~、&、| である。このモジュールの 1 ビット信号ではビット単位演算子と論理演算子は一致する。ベクタでは一致せず、その違いは静かなバグの古典的な原因である。a が 4'b0010 なら ~a は 4'b1101 だが !a は 1'b0 であり、a & b は 4 ビットの AND、a && b は「両方とも非ゼロ」を表す 1 ビットである。第 4.6 節のスライドの task 版は、他の版が ~ を使う箇所で ! を使っている。そこでは無害だが、ベクタならバグになる。

4.4 The always block, and the three rules4.4 always 區塊，以及那三條規則4.4 always ブロックと三つの規則

The always block is the general-purpose description style, and it is general-purpose precisely because it introduces sequencing, selection and variables — which is also why it is the only style in this section that can go wrong. The lecture states three rules. Here they are with their real justifications.always 區塊是通用的描述風格，而它之所以通用，正是因為它引入了順序、選擇與變數——這也正是為什麼它是本節唯一會出錯的風格。本講陳述了三條規則。以下是它們以及它們真正的理由。always ブロックは汎用の記述スタイルであり、汎用であるのはまさに順序・選択・変数を持ち込むからである。そしてそれこそが、本節で唯一おかしくなりうるスタイルである理由でもある。講義は三つの規則を述べる。以下にそれらと、その本当の根拠を示す。

Here is the lecture's first always example, the same function once more:以下是本講第一個 always 例子，還是同一個函數：以下は講義の最初の always の例であり、やはり同じ関数である。

module or_nand_3 (enable, x1, x2, x3, x4, y);
  input  enable, x1, x2, x3, x4;
  output y;
  reg    y;                       // assigned procedurally, so it must be reg

  always @ (enable or x1 or x2 or x3 or x4)
    begin
      y = ~(enable & (x1 | x2) & (x3 | x4));
    end
endmodule

Note reg y. A variable assigned inside a procedural block must be declared reg (or in later standards logic). The keyword is one of Verilog's worst naming decisions: reg does not mean "register". It means "a variable that holds its value between assignments inside a simulator", which is a statement about the simulation data model, not about hardware. This block has no state and synthesises to no state. The slide's own netlist is two gates. Students who believe reg implies a flip-flop go looking for storage that is not there, and — worse — students who believe the converse assume that because they declared something wire they are safe from inferring storage, which is true only because you cannot assign a wire procedurally in the first place.注意 reg y。在程序式區塊內被賦值的變數必須宣告為 reg（或在後來的標準中宣告為 logic）。這個關鍵字是 Verilog 最糟糕的命名決定之一：reg 不代表「暫存器」。它的意思是「一個在模擬器內部於兩次賦值之間保住自己的值的變數」，那是關於模擬資料模型的陳述，不是關於硬體的。這個區塊沒有狀態，也合成不出狀態。投影片自己的網表是兩個閘。相信 reg 蘊涵正反器的學生，會去找一個根本不存在的儲存元件；而更糟的是，相信反向命題的學生會以為自己既然宣告了 wire 就不會推論出儲存，但那之所以成立，只是因為你一開始就無法對 wire 做程序式賦值。reg y に注目してほしい。手続きブロック内で代入される変数は reg（後の規格では logic）と宣言しなければならない。このキーワードは Verilog 最悪の命名の一つである。reg は「レジスタ」を意味しない。意味するのは「シミュレータの中で代入と代入の間、自分の値を保持する変数」であり、これはシミュレーションのデータモデルについての記述であって、ハードウェアについての記述ではない。このブロックは状態を持たず、状態に合成されもしない。スライド自身のネットリストはゲート 2 個である。reg がフリップフロップを含意すると信じる学生は、存在しない記憶素子を探し回る。さらに悪いのは逆を信じる学生で、wire と宣言したから記憶の推論は起きないはずだと考える。それが成り立つのは、そもそも wire には手続き的な代入ができないからにすぎない。

4.5 Loops, disable, and how unrolling works4.5 迴圈、disable，以及展開是怎麼運作的4.5 ループ、disable、そして展開の仕組み

The lecture's second and third always examples both use a for loop with a disable as an early exit. These are worth working through, because the way the tool handles them is genuinely non-obvious.本講第二與第三個 always 例子都用了一個 for 迴圈，並以 disable 作為提前離開的手段。它們值得逐步走過一遍，因為工具處理它們的方式真的不直觀。講義の二つ目と三つ目の always の例は、どちらも for ループと、早期脱出としての disable を使う。ツールの扱い方が本当に直観に反するので、順を追って見る価値がある。

module and4_behav (y, x_in);
  parameter word_length = 4;
  input  [word_length - 1:0] x_in;
  output y;
  reg    y;
  integer k;

  always @ x_in
    begin: check_for_0
      y = 1;
      for (k = 0; k <= word_length - 1; k = k + 1)
        if (x_in[k] == 0)
          begin
            y = 0;
            disable check_for_0;       // early exit from the named block
          end
    end
endmodule

Read it as software and it is a linear scan that stops at the first zero. Read it as hardware and there is no scanning, because there is no time inside a combinational block. The tool unrolls the loop into four copies of the body, then converts the disable into guards: statement $i$ executes only if no earlier iteration took the exit. The unrolled, guarded form is把它當軟體讀，那是一個線性掃描，碰到第一個零就停。把它當硬體讀，則根本沒有掃描，因為組合邏輯區塊內部沒有時間。工具把迴圈展開成本體的四份副本，再把 disable 轉換成守衛條件：第 $i$ 個敘述只在沒有任何更早的迭代走過離開路徑時才執行。展開並加上守衛之後的形式是ソフトウェアとして読めば、これは最初のゼロで止まる線形走査である。ハードウェアとして読めば、走査などない。組合せブロックの内部には時間が無いからだ。ツールはループを本体 4 個分のコピーに展開し、disable をガード条件に変換する。第 $i$ の文は、それより前の反復が脱出していない場合にのみ実行される。展開してガードを付けた形は次のようになる。

// what the tool actually optimises
y = 1;
if (x_in[0] == 0) y = 0;
else if (x_in[1] == 0) y = 0;
else if (x_in[2] == 0) y = 0;
else if (x_in[3] == 0) y = 0;

and since every branch assigns the same constant, the whole chain collapses to $y = x_3x_2x_1x_0$ — a single four-input AND gate, exactly as the slide's figure shows. The disable cost nothing and saved nothing in hardware; it only shortens the simulator's work.而既然每一個分支都賦同一個常數，整條鏈就塌成 $y = x_3x_2x_1x_0$——一個四輸入 AND 閘，正如投影片的圖所示。disable 在硬體上既沒花錢也沒省錢；它只縮短了模擬器的工作量。そしてどの枝も同じ定数を代入するので、チェーン全体は $y = x_3x_2x_1x_0$ に潰れる。スライドの図のとおり、4 入力 AND ゲート 1 個である。disable はハードウェア上で何のコストも生まず、何も節約しない。縮めたのはシミュレータの仕事量だけである。

Three structural facts make this legal. The loop bound is a parameter, so it is known at elaboration. The loop variable k is used only as a constant index after unrolling, so no variable bit select survives. And the disable targets the enclosing named block, which is the only form on the supported list; disabling some other block from here would be an "external disable" and is forbidden.有三個結構上的事實讓這件事合法。迴圈界限是一個參數，所以在展開時就已知。迴圈變數 k 在展開後只被當成常數索引使用，所以沒有可變位元選擇殘留下來。而那個 disable 的目標是包住它的具名區塊，那是支援清單上唯一允許的形式；從這裡去 disable 別的區塊就會是「外部 disable」，是被禁止的。これを合法にしている構造的な事実が三つある。ループの境界はパラメータなのでエラボレーション時に既知である。ループ変数 k は展開後は定数の添字としてしか使われないので、可変ビット選択は残らない。そして disable の対象はそれを囲む名前付きブロックであり、これがサポート一覧で唯一許される形である。ここから別のブロックを disable すれば「外部からの disable」になり、禁止される。

Notice also always @ x_in — a bare signal name with no parentheses, which is legal Verilog-1995 for a single-signal event control. It is complete here because x_in is the only input. It is also exactly the style that becomes a bug the moment someone adds a second input and forgets to extend the list, which is the practical argument for @*.也請注意 always @ x_in——一個沒有括號的裸訊號名稱，這在 Verilog-1995 裡對單一訊號的事件控制是合法的。這裡它是完整的，因為 x_in 是唯一的輸入。而它也正是那種一旦有人加了第二個輸入卻忘了擴充列表就變成錯誤的寫法，這就是支持 @* 的實務理由。always @ x_in にも注目したい。括弧のない裸の信号名で、単一信号のイベント制御としては Verilog-1995 で合法である。x_in が唯一の入力なので、ここでは完全である。しかしこれはまさに、誰かが二つ目の入力を加えてリストの拡張を忘れた瞬間にバグになる書き方であり、@* を支持する実務上の論拠になっている。

The comparator example is more interesting because its branches assign different values:比較器的例子更有趣，因為它的各分支賦的是不同的值：比較器の例はもっと面白い。枝ごとに異なる値を代入するからである。

module comparator (a, b, a_gt_b, a_lt_b, a_eq_b);
  parameter size = 2;
  input  [size:1] a, b;
  output a_gt_b, a_lt_b, a_eq_b;
  reg    a_gt_b, a_lt_b, a_eq_b;
  integer k;

  always @ (a or b)
    begin: compare_loop
      for (k = size; k > 0; k = k - 1)      // MSB first
        begin
          if (a[k] != b[k])
            begin
              a_gt_b = a[k];
              a_lt_b = ~a[k];
              a_eq_b = 0;
              disable compare_loop;
            end
        end
      a_gt_b = 0;                           // reached only if no bit differed
      a_lt_b = 0;
      a_eq_b = 1;
    end
endmodule

The algorithm is the standard one: scan from the most significant bit; the first position where the operands differ decides the comparison, because that bit outweighs everything below it. If a[k] is the one that is 1, then $a > b$.演算法是標準的那個：從最高有效位元往下掃描；運算元第一個不同的位置決定比較結果，因為那個位元的份量壓過它底下的一切。如果是 a[k] 為 1，那麼 $a > b$。アルゴリズムは標準的なものである。最上位ビットから走査し、オペランドが最初に異なる位置で比較結果が決まる。そのビットの重みが、それより下のすべてを上回るからだ。1 になっているのが a[k] のほうなら、$a > b$ である。

After unrolling with size = 2 the body becomes a two-level priority structure. Let $d_k = a_k \oplus b_k$ be "bit $k$ differs". Then在 size = 2 下展開之後，本體變成一個兩層的優先權結構。令 $d_k = a_k \oplus b_k$ 表示「第 $k$ 位元不同」。則size = 2 で展開すると、本体は 2 段の優先順位構造になる。$d_k = a_k \oplus b_k$ を「ビット $k$ が異なる」とおくと、次のようになる。

which matches the slide's synthesis figure exactly: XOR gates producing the $d_k$ terms, a NOR or AND producing a_eq_b from their complements, and two small muxes selecting between $a_2$ and $a_1$ under the control of $d_2$. The muxes are the priority: $d_2$ chooses whether bit 2 or bit 1 decides. This is the same mux-chain-equals-priority-structure idea that Section 8 formalises, arriving here as a by-product of the disable.這與投影片的合成圖完全相符：XOR 閘產生各個 $d_k$ 項，一個 NOR 或 AND 由它們的補數產生 a_eq_b，再加上兩個小多工器在 $d_2$ 的控制下於 $a_2$ 與 $a_1$ 之間做選擇。那些多工器就是優先權：$d_2$ 決定由第 2 位元還是第 1 位元來做主。這與第 8 節正式化的「多工器鏈等於優先權結構」是同一個想法，只是在這裡以 disable 的副產品形式出現。これはスライドの合成図と完全に一致する。XOR ゲートが各 $d_k$ の項を作り、NOR か AND がそれらの補数から a_eq_b を作り、$d_2$ の制御で $a_2$ と $a_1$ を選ぶ小さなマルチプレクサが二つ付く。このマルチプレクサこそが優先順位である。$d_2$ がビット 2 とビット 1 のどちらに決めさせるかを選ぶのだ。これは第 8 節で定式化される「マルチプレクサの連鎖は優先順位構造である」という考えと同じものが、ここでは disable の副産物として現れたにすぎない。

Crucially, every one of the three outputs is assigned on every path — either inside the if or in the three statements after the loop — so despite all the control flow, no latch appears. The final three assignments are not dead code; they are the fall-through that makes the description complete. Delete them and you get three latches.最關鍵的是，三個輸出每一個在每一條路徑上都被賦值了——不是在 if 裡面，就是在迴圈之後的那三個敘述裡——所以儘管控制流這麼複雜，並沒有鎖存器出現。最後那三個賦值不是死碼；它們是讓描述完整的「落下去」路徑。把它們刪掉，你就得到三個鎖存器。決定的に重要なのは、三つの出力のいずれもがすべての経路で代入されていることである。if の中か、ループの後ろの三つの文のどちらかで代入される。だから制御の流れがこれだけ入り組んでいてもラッチは現れない。末尾の三つの代入は死んだコードではない。記述を完全にするフォールスルーである。消せばラッチが三つできる。

4.6 Function and task4.6 function 與 task4.6 function と task

Functions and tasks are the reuse mechanism inside a module. For synthesis they are inlined — expanded at each call site with the arguments substituted — so they produce no hierarchy and no extra hardware, only less typing and fewer copy-paste errors.function 與 task 是模組內部的重用機制。就合成而言它們會被內聯——在每個呼叫點展開並代入引數——所以它們不產生階層，也不產生額外硬體，只是讓你少打字、少犯複製貼上的錯。function と task はモジュール内部の再利用の仕組みである。合成の立場ではインライン展開され、各呼び出し地点で引数を代入して展開されるので、階層も余分なハードウェアも生まない。生むのはタイプ量の減少とコピー＆ペーストのミスの減少だけである。

module or_nand_4 (enable, x1, x2, x3, x4, y);
  input  enable, x1, x2, x3, x4;
  output y;

  assign y = or_nand(enable, x1, x2, x3, x4);

  function or_nand;
    input enable, x1, x2, x3, x4;
    begin
      or_nand = ~(enable & (x1 | x2)
                         & (x3 | x4));
    end
  endfunction
endmodule

module or_nand_5 (enable, x1, x2, x3, x4, y);
  input  enable, x1, x2, x3, x4;
  output y;
  reg    y;

  always @ (enable or x1 or x2 or x3 or x4)
    or_nand(enable, x1, x2, x3, x4, y);

  task or_nand;
    input  enable, x1, x2, x3, x4;
    output y;
    begin
      y = !(enable & (x1 | x2) & (x3 | x4));
    end
  endtask
endmodule

The structural differences between the two are what the exam asks about. A function has at least one input and no outputs; it returns a value by assignment to its own name, so it can be called from an expression, including from a continuous assignment. A task may have inputs, outputs and inouts, returns nothing, and must therefore be called as a statement — which means from inside a procedural block, which is why or_nand_5 needs an always block and a reg y that or_nand_4 does not. A function may not contain timing or event control at all; a task may contain them in simulation but must not if it is to be synthesised.兩者之間結構上的差異，正是考試會問的。function 至少有一個輸入，而且沒有輸出；它以對自己名字賦值的方式回傳一個值，所以可以在運算式中被呼叫，包括在連續賦值裡。task 可以有輸入、輸出與 inout，不回傳任何東西，因此必須以敘述的形式被呼叫——也就是說必須從程序式區塊內部呼叫，這就是為什麼 or_nand_5 需要一個 always 區塊與一個 reg y，而 or_nand_4 不需要。function 完全不得含有時序或事件控制；task 在模擬中可以含有它們，但若要被合成就不得含有。両者の構造上の違いこそ試験で問われる点である。function は少なくとも一つの入力を持ち、出力は持たない。自分自身の名前への代入によって値を返すので、連続代入を含め式の中から呼べる。task は入力・出力・inout を持ちうるが何も返さず、したがって文として呼ばねばならない。つまり手続きブロックの中から呼ぶことになり、だからこそ or_nand_5 には always ブロックと reg y が必要で、or_nand_4 には不要なのである。function はタイミングやイベント制御を一切含んではならない。task はシミュレーションでは含みうるが、合成するなら含んではならない。

The restriction the lecture emphasises — no incomplete case statements or conditionals inside a function — is the latch rule wearing a different hat. A function's return variable is a variable like any other; if some path through the function body leaves it unassigned, the inlined code leaves it unassigned, and you get a latch at the call site. Because the function may be called from a continuous assignment, where you would swear no storage could possibly appear, this is a particularly confusing way to meet your first inferred latch.本講強調的那條限制——function 內部不得有不完整的 case 敘述或條件式——其實就是鎖存器規則換了一頂帽子。function 的回傳變數跟其他變數沒兩樣；如果穿過 function 本體的某條路徑讓它未被賦值，那麼內聯之後的程式碼同樣讓它未被賦值，於是你在呼叫點得到一個鎖存器。由於 function 可能是從一個連續賦值裡被呼叫的——在那裡你會發誓不可能冒出任何儲存元件——這會是一種特別令人困惑的初次邂逅推論鎖存器的方式。講義が強調する制限、すなわち function の中に不完全な case 文や条件文を置いてはならない は、ラッチの規則が帽子をかぶり替えたものにすぎない。function の戻り値の変数も他の変数と変わらない。本体を通るどこかの経路でそれが未代入のままなら、インライン展開されたコードでも未代入のままであり、呼び出し地点にラッチができる。しかも function は連続代入の中から呼ばれることがあり、そこには記憶素子など現れようがないと誓いたくなる場所なので、推論ラッチとの初対面としてはとりわけ混乱させられる形になる。

One last detail: the task writes ! where the function writes ~. On the one-bit operand here they agree. The habit of using ! for "not" is a C reflex and it will eventually bite you on a vector, where !v is one bit and ~v is the full width. Use ~ for data, ! for conditions.最後一個細節：task 寫 ! 的地方，function 寫的是 ~。在這裡的一位元運算元上兩者一致。用 ! 當「not」是 C 的反射動作，而它終究會在某個向量上咬你一口，因為 !v 是一個位元，~v 是整個寬度。資料用 ~，條件用 !。最後に細かい点を一つ。task が ! と書く箇所で function は ~ と書いている。ここの 1 ビットのオペランドでは両者は一致する。「not」に ! を使う癖は C の反射であり、いずれベクタで痛い目を見る。!v は 1 ビット、~v は全幅だからだ。データには ~、条件には ! を使うこと。

5. Multiplexer Coding Styles5. 多工器的寫法風格5. マルチプレクサの記述スタイル

The multiplexer is the single most important structure in RTL, for a reason that is easy to miss: it is the hardware realisation of choice, and every if, every case, and every ?: in your design becomes one. Control logic for a multiplexed datapath — the slide's title — means exactly this: the datapath holds the adders and registers, and the control logic is the collection of muxes that decides which operands reach them this cycle. Get the mux coding right and most of RTL falls into place.多工器是 RTL 中最重要的單一結構，理由很容易被忽略：它是選擇這件事的硬體實現，而你設計裡的每一個 if、每一個 case、每一個 ?: 最後都會變成一個多工器。投影片標題說的「多工化資料路徑的控制邏輯」，講的正是這件事：資料路徑裡放著加法器與暫存器，而控制邏輯就是那一堆決定這個週期哪些運算元送進去的多工器。把多工器的寫法弄對，RTL 的大半就各就各位了。マルチプレクサは RTL で最も重要な単一の構造である。その理由は見落とされやすい。これは選択のハードウェア実現であり、設計中のあらゆる if、case、?: は最後にはこれになる。スライドの題にある「多重化されたデータパスの制御論理」が指すのはまさにこれである。データパスには加算器とレジスタが並び、制御論理とは、今サイクルどのオペランドがそこへ届くかを決めるマルチプレクサの集まりである。マルチプレクサの書き方を正せば、RTL の大半は所定の位置に収まる。

5.1 Three styles, one mux5.1 三種寫法，同一個多工器5.1 三つのスタイル、一つのマルチプレクサ

The lecture describes a 4-channel, 4-bit mux three ways. The three modules are syn1_mux_4bits (nested conditional operator in a continuous assignment), syn2_mux_4bits (case in an always block) and syn3_mux_4bits (if/else if chain in an always block). The slide notes after the third that the synthesis result is the same as the second.本講以三種方式描述一個四通道、四位元的多工器。三個模組是 syn1_mux_4bits（連續賦值裡的巢狀條件運算子）、syn2_mux_4bits（always 區塊裡的 case）與 syn3_mux_4bits（always 區塊裡的 if/else if 串）。投影片在第三個之後註明，合成結果與第二個相同。講義は 4 チャネル 4 ビットのマルチプレクサを三通りに記述する。三つのモジュールは syn1_mux_4bits（連続代入の中の入れ子条件演算子）、syn2_mux_4bits（always ブロック内の case）、syn3_mux_4bits（always ブロック内の if/else if の連鎖）である。スライドは三つ目のあとに、合成結果は二つ目と同じだと注記している。

module syn1_mux_4bits (y, sel, a, b, c, d);
  input  [3:0] a, b, c, d;
  input  [1:0] sel;
  output [3:0] y;

  assign y = (sel == 0) ? a :
             (sel == 1) ? b :
             (sel == 2) ? c :
             (sel == 3) ? d : 4'bx;
endmodule

module syn2_mux_4bits (y, sel, a, b, c, d);
  input  [3:0] a, b, c, d;
  input  [1:0] sel;
  output [3:0] y;
  reg    [3:0] y;

  always @ (sel or a or b or c or d)
    case (sel)
      0: y = a;
      1: y = b;
      2: y = c;
      3: y = d;
      default: y = 4'bx;
    endcase
endmodule

module syn3_mux_4bits (y, sel, a, b, c, d);      // if/else if version
  input  [3:0] a, b, c, d;
  input  [1:0] sel;
  output [3:0] y;
  reg    [3:0] y;

  always @ (sel or a or b or c or d)
    if      (sel == 0) y = a;
    else if (sel == 1) y = b;
    else if (sel == 2) y = c;
    else if (sel == 3) y = d;
    else               y = 4'bx;
endmodule

The conditional-operator version reads as a priority chain: "if sel is 0 take a, otherwise if sel is 1 take b, otherwise …". The if chain reads the same way. Yet both produce the same flat four-input multiplexer as the case, with no priority structure at all. This surprises people, and the reason is the rule the lecture states in Section 8: when the branch conditions are mutually exclusive, the tool detects it and builds a mux, not a chain.條件運算子版本讀起來像一條優先權鏈：「如果 sel 是 0 就取 a，否則如果 sel 是 1 就取 b，否則……」。if 串讀起來也一樣。然而兩者都產生與 case 相同的扁平四輸入多工器，完全沒有優先權結構。這會讓人驚訝，而理由就是本講在第 8 節陳述的那條規則：當各分支條件互斥時，工具會偵測到，並建出一個多工器而不是一條鏈。条件演算子版は優先順位チェーンのように読める。「sel が 0 なら a、そうでなく 1 なら b、そうでなければ…」。if の連鎖も同じように読める。それでも両者は case と同じ平坦な 4 入力マルチプレクサを生み、優先順位構造はまったく現れない。これは驚かれるところだが、理由は講義が第 8 節で述べる規則にある。分岐条件が互いに排他的であれば、ツールはそれを検出し、チェーンではなくマルチプレクサを作る。

Detecting mutual exclusivity here is easy, because the conditions are equality tests of one variable against distinct constants. Two of them cannot be true at once; this is provable by inspection and every tool does it. What the optimiser then builds is the canonical selection function在這裡偵測互斥性很容易，因為那些條件是把同一個變數拿去跟相異常數做相等比較。其中任兩個不可能同時成立；這用看的就能證明，而且每個工具都做得到。接著最佳化器建出來的，是標準的選擇函數ここで排他性を検出するのは容易である。条件は一つの変数を相異なる定数と等価比較しているからだ。そのうち二つが同時に真になることはありえず、これは一見して証明でき、どのツールもそれを行う。そのうえで最適化器が作るのは、正準的な選択関数である。

which is a two-level AND-OR per output bit, fed by a 2-to-4 decode of sel that is extracted once and shared by all four bits. That shared decode is visible in the slide's synthesis figure: two inverters and a handful of NOR gates at the bottom left, feeding four identical per-bit slices.這是每個輸出位元一個兩層的 AND-OR，由一個對 sel 的 2 對 4 解碼餵進去，而那個解碼只抽出一次、四個位元共用。那個共用的解碼在投影片的合成圖裡看得見：左下角的兩個反相器與一小把 NOR 閘，餵進四個一模一樣的每位元切片。これは出力ビットごとの 2 段 AND-OR であり、sel の 2 対 4 デコードから駆動される。そのデコードは一度だけ抽出され、4 ビットすべてで共有される。共有されたデコードはスライドの合成図に見てとれる。左下のインバータ 2 個といくつかの NOR ゲートが、同一のビットスライス 4 本に供給している。

The 4'bx in the final branch deserves attention. Since sel is two bits, all four values are already covered and the default is logically unreachable. Writing it anyway serves two purposes. It makes the statement syntactically complete, which removes any question of latch inference and silences lint. And by naming the unreachable output x rather than a concrete value, it tells the optimiser "I do not care what you produce here", which costs nothing when the branch is unreachable but matters a great deal when it is not — see Section 10.最後一個分支的 4'bx 值得注意。既然 sel 是兩位元，四個值早就都被涵蓋了，這個 default 在邏輯上不可到達。即使如此還是把它寫出來，有兩個用處。它讓敘述在語法上是完整的，這就排除了任何鎖存器推論的疑慮，也讓 lint 閉嘴。而且把那個不可到達的輸出命名為 x 而非一個具體值，等於告訴最佳化器「我不在意你在這裡產生什麼」，當分支不可到達時這不花任何代價，但當它可到達時關係重大——見第 10 節。最後の枝の 4'bx は注目に値する。sel は 2 ビットなので四つの値はすでにすべて網羅されており、この default は論理的に到達不能である。それでも書く理由は二つある。文を構文的に完全にし、ラッチ推論の疑いを消して lint を黙らせること。そして到達不能な出力を具体値ではなく x と名づけることで、最適化器に「ここで何を出そうと構わない」と伝えること。枝が到達不能ならこれは無料だが、到達可能なら大きな意味を持つ。第 10 節を参照のこと。

5.2 The "simulation efficient" style, and why it is a museum piece5.2 「模擬效率佳」的寫法，以及它為什麼是博物館展品5.2 「シミュレーション効率のよい」スタイルと、それが博物館行きである理由

The slides present each mux twice, side by side, labelled "simulation efficient" and "simulation and synthesis friendly". The left-hand version looks like this:投影片把每個多工器並排呈現兩次，分別標示「simulation efficient」與「simulation and synthesis friendly」。左邊那個版本長這樣：スライドは各マルチプレクサを二つ並べ、「simulation efficient」と「simulation and synthesis friendly」と見出しを付けている。左側の版は次のようなものである。

always @ (sel)                    // sensitive to sel only
  case (sel)
    0: assign y = a;             // procedural continuous assignment
    1: assign y = b;
    2: assign y = c;
    3: assign y = d;
    default: assign y = 4'bx;
  endcase

The trick is the procedural continuous assignment. An ordinary procedural assignment y = a samples a once, at the moment the statement executes. A PCA assign y = a establishes a continuous drive that persists after the block finishes, so y keeps tracking a until a later deassign or a later PCA overrides it. That is why the sensitivity list can contain only sel: the data inputs are followed continuously by the drive, not by re-execution of the block.訣竅在於程序式連續賦值。一個普通的程序式賦值 y = a 只在敘述執行的那一刻取樣 a 一次。而一個 PCA assign y = a 建立的是一個在區塊結束後仍然持續的連續驅動，所以 y 會一直跟著 a，直到後來的 deassign 或後來的 PCA 蓋過它為止。這就是為什麼敏感度列表裡可以只放 sel：那些資料輸入是被驅動持續跟隨的，不是靠區塊重新執行。仕掛けは手続き的連続代入にある。ふつうの手続き代入 y = a は、文が実行された瞬間に a を一度サンプルするだけである。一方 PCA の assign y = a はブロック終了後も続く連続的な駆動を確立するので、後の deassign か後の PCA が上書きするまで y は a に追従し続ける。だからこそセンシティビティリストには sel だけを書けばよい。データ入力はブロックの再実行ではなく駆動によって連続的に追われているからだ。

The efficiency claim is real for an event-driven simulator. With full sensitivity, every transition on any of a, b, c, d wakes the block, re-evaluates the case, and assigns — four times the event traffic for no change in result when the unselected inputs move. With the PCA version only sel transitions wake the block. On a large datapath with wide buses this was a measurable win in 1995.對事件驅動的模擬器而言，效率的宣稱是真的。若敏感度完整，a、b、c、d 任何一個的轉態都會喚醒區塊、重新求值 case、再賦值——當未被選中的輸入動的時候，結果毫無改變卻付出四倍的事件流量。用 PCA 版本，就只有 sel 的轉態會喚醒區塊。在 1995 年，對一條有寬匯流排的大型資料路徑而言，這是可測量的收益。イベント駆動のシミュレータにとって、効率の主張は本当である。センシティビティが完全なら、a・b・c・d のどれが遷移してもブロックが起き、case を再評価し、代入する。選ばれていない入力が動いたときも、結果は変わらないのにイベントの量は 4 倍になる。PCA 版なら sel の遷移だけがブロックを起こす。1995 年当時、バス幅の広い大きなデータパスではこれは計測できる利得だった。

5.3 Reading the mux netlist, and the cost of select decoding5.3 讀懂多工器的網表，以及選擇線解碼的代價5.3 マルチプレクサのネットリストを読む、そして選択デコードのコスト

The slide shows two different synthesis results for what is, functionally, the same mux. The conditional-operator version came out as four AND-OR-invert groups with output inverters and some small muxes; the case version came out as four explicit mux blocks with a shared NOR-based decoder. Both are correct and the difference is a mapping artefact: the tool was free to choose, and the two runs landed in different local optima. The slide's footnote about results depending on the tool is doing honest work here.投影片對功能上同一個多工器展示了兩個不同的合成結果。條件運算子版本出來的是四組 AND-OR-invert 加上輸出反相器與一些小多工器；case 版本出來的是四個明確的 mux 區塊，加上一個共用的 NOR 式解碼器。兩者都正確，差別是映射的產物：工具有選擇的自由，而兩次執行落進了不同的區域最佳解。投影片那句「結果取決於工具」的註腳，在這裡是在誠實地幹活。スライドは、機能的には同一のマルチプレクサについて二つの異なる合成結果を示す。条件演算子版は AND-OR-invert が四組、出力インバータといくつかの小さなマルチプレクサを伴って現れた。case 版は明示的な mux ブロックが四つと、共有された NOR ベースのデコーダになった。どちらも正しく、違いはマッピングの産物である。ツールには選ぶ自由があり、二度の実行が別々の局所最適に着地したのだ。「結果はツールに依存する」というスライドの脚注は、ここで正直に働いている。

What is stable across tools is the cost model, and it is worth having at your fingertips.跨工具穩定的是成本模型，值得隨手就能調出來。ツールをまたいで安定しているのはコストモデルであり、手元にすぐ出せるようにしておく価値がある。

Two practical consequences follow. First, a 4:1 mux costs roughly three times a 2:1 mux, not twice: selection cost grows with the number of inputs, and an $N$:1 mux built as a balanced tree costs about $N-1$ two-input muxes with $\log_2 N$ levels. A 16:1 mux is fifteen 2:1 muxes and four levels — about 35 GE per bit, so a 32-bit 16:1 mux is over a thousand gate equivalents, which is why large crossbars are expensive and why designers go to some trouble to avoid them.有兩個實務後果。第一，一個 4:1 多工器的代價大約是 2:1 多工器的三倍，不是兩倍：選擇的代價隨輸入數成長，而一個以平衡樹建成的 $N$:1 多工器，大約要 $N-1$ 個二輸入多工器、$\log_2 N$ 層。一個 16:1 多工器是十五個 2:1 多工器、四層——每位元約 35 GE，所以一個 32 位元的 16:1 多工器超過一千個閘當量，這就是為什麼大型交叉開關很貴，也是為什麼設計者寧可費一番功夫避開它們。実務上の帰結が二つある。第一に、4:1 マルチプレクサのコストは 2:1 の 2 倍ではなく、およそ 3 倍である。選択のコストは入力数とともに増え、平衡木として作った $N$:1 マルチプレクサは 2 入力マルチプレクサ約 $N-1$ 個、$\log_2 N$ 段を要する。16:1 なら 2:1 が 15 個で 4 段、1 ビットあたり約 35 GE であり、32 ビットの 16:1 マルチプレクサは 1000 ゲート等価を超える。大きなクロスバーが高価である理由であり、設計者がそれを避けるために骨を折る理由でもある。

Second, the select path and the data path have different delays, and which one matters depends on your architecture. If sel comes straight from a register and the data comes from a long arithmetic chain, the data path dominates and a tree is right. If sel is itself computed by a slow comparison and the data is already stable, you want the select decode moved as early as possible — which is the same insight that makes resource sharing a delay question as well as an area question in Section 11.第二，選擇路徑與資料路徑的延遲不同，而哪一個重要取決於你的架構。如果 sel 直接來自一個暫存器，而資料來自一條長長的算術鏈，那麼資料路徑佔主導，用樹是對的。如果 sel 本身是由一個很慢的比較算出來的，而資料早就穩定了，那你會希望選擇線的解碼盡可能提早——這與第 11 節讓資源共用同時成為延遲問題與面積問題的，是同一個洞見。第二に、選択経路とデータ経路では遅延が異なり、どちらが効くかはアーキテクチャ次第である。sel がレジスタから直接来て、データが長い算術チェーンから来るならデータ経路が支配的で、ツリーが正解である。sel 自体が遅い比較で計算され、データはとうに安定しているなら、選択のデコードをできるだけ早い段階へ移したい。これは第 11 節でリソース共有を面積の問題であると同時に遅延の問題にしている洞察と同じものである。

// (a)
always @* case (sel)  2'b00: y=a; 2'b01: y=b; 2'b10: y=c; 2'b11: y=d; endcase
// (b)
always @* begin
  if      (req_a) y = a;
  else if (req_b) y = b;
  else if (req_c) y = c;
  else            y = d;
end
// (c)
always @* begin
  if      (sel == 2'd0) y = a;
  else if (sel == 2'd1) y = b;
  else if (sel == 2'd2) y = c;
  else                  y = d;
end
// (d)
always @* begin
  y = d;
  if (req_c) y = c;
  if (req_b) y = b;
  if (req_a) y = a;
end

6. Unwanted Latches — The Long Version6. 非預期的鎖存器 — 完整版6. 意図しないラッチ — 詳細版

If you remember one thing from Lecture 5, make it this section. Inferred latches are the most common RTL defect in student projects and one of the more common in industry, they are trivially avoidable, and they cause damage out of all proportion to the typo that produces them. This section works through where the latch comes from, which exact code shapes produce one, what the resulting netlist contains, why a latch in a nominally combinational block is a disaster for static timing analysis rather than merely untidy, and the four standard cures with their respective caveats.如果你只從第 5 講記住一件事，就記住這一節。推論鎖存器是學生專題中最常見的 RTL 缺陷，在業界也名列前茅，它們極易避免，而它們造成的損害與產生它們的那個小筆誤完全不成比例。本節會一路走過：鎖存器從哪裡來、確切是哪些程式碼形狀會產生一個、結果的網表裡有什麼、為什麼一個名義上組合邏輯區塊裡的鎖存器對靜態時序分析是災難而不只是不整潔，以及四種標準解法與各自的但書。第 5 講から一つだけ覚えるなら、この節にしてほしい。推論ラッチは学生のプロジェクトで最も多い RTL の欠陥であり、産業界でも上位に入る。避けるのは造作もないのに、それを生む些細な打ち間違いとはまるで釣り合わない損害をもたらす。本節では、ラッチがどこから来るのか、正確にどのコードの形がそれを生むのか、できあがるネットリストに何が入るのか、名目上は組合せのブロックにあるラッチがなぜ単に不潔なだけでなく静的タイミング解析にとって災厄なのか、そして四つの標準的な対処とそれぞれの但し書きを順に見ていく。

6.1 Where the latch comes from: completeness, not sensitivity6.1 鎖存器從哪裡來：是完整性，不是敏感度6.1 ラッチはどこから来るか：完全性の問題であって、センシティビティの問題ではない

The lecture's definition is: a case statement or conditional that does not include all possible cases or conditions is incompletely specified, and incompletely specified statements may lead to the synthesis of unwanted latches. That is accurate but it describes the symptom rather than the mechanism. The mechanism is a single requirement that falls out of Verilog's own semantics.本講的定義是：一個沒有涵蓋所有可能情況或條件的 case 敘述或條件式是不完整指定的，而不完整指定的敘述可能導致合成出非預期的鎖存器。這說法正確，但它描述的是症狀而不是機制。機制是一個從 Verilog 自身語意直接掉出來的單一要求。講義の定義はこうである。ありうるすべての場合や条件を含まない case 文や条件文は不完全に指定されているといい、不完全に指定された文は意図しないラッチの合成につながりうる。これは正確だが、述べているのは機構ではなく症状である。機構は Verilog 自身の意味論からそのまま落ちてくる一つの要請である。

Everything follows from that. The latch's data input is the multiplexed value that the assigned paths produce. The latch's enable is the Boolean condition "some path assigned v this time". The latch is transparent when the enable is high and holds when it is low. And the number of latch bits equals the width of v — a 32-bit variable with one uncovered path gives you 32 latch cells, not one.其餘一切都從這裡推出來。鎖存器的資料輸入是那些有賦值的路徑所產生的、經過多工的值。鎖存器的致能是布林條件「這次有某條路徑賦值給 v」。致能為高時鎖存器透通，為低時保持。而鎖存器的位元數等於 v 的寬度——一個 32 位元變數若有一條路徑沒涵蓋，給你的是 32 個鎖存器元件，不是一個。あとはすべてここから導かれる。ラッチのデータ入力は、代入が行われる経路が生む多重化された値である。ラッチのイネーブルは「今回どこかの経路が v に代入した」というブール条件である。イネーブルが高ければラッチは透過し、低ければ保持する。そしてラッチのビット数は v の幅に等しい。32 ビットの変数に未カバーの経路が一つあれば、得られるのはラッチセル 32 個であって 1 個ではない。

It is worth stressing the quantifier in that sentence: there exists any assignment of input values. The tool reasons over the Boolean space of inputs, not over the paths your testbench happens to exercise. A branch you believe is unreachable because of a protocol guarantee elsewhere in the chip is, to the synthesiser, perfectly reachable, and it will build the latch. This is why "but that opcode never happens" is not a defence, and why the correct response is to tell the tool it never happens — which is what a default: y = 'bx; does.那句話裡的量詞值得強調：存在任何一組輸入值。工具是在輸入的布林空間上推理，不是在你的測試平台碰巧走過的路徑上推理。某個你相信因為晶片別處的協定保證而不可到達的分支，在合成器眼裡完全可達，它就會把鎖存器造出來。這就是為什麼「可是那個 opcode 根本不會出現」不是辯護理由，也是為什麼正確的回應是去告訴工具它不會出現——那正是 default: y = 'bx; 所做的事。この文の量化子は強調しておきたい。入力値の割り当てが一つでも存在すればである。ツールは入力のブール空間上で推論するのであって、テストベンチがたまたま踏んだ経路の上で推論するのではない。チップの別の場所のプロトコル保証によって到達不能だとあなたが信じている分岐も、合成器にとっては完全に到達可能であり、ツールはラッチを作る。「でもその opcode は決して来ない」が弁明にならない理由であり、正しい応答がそれをツールに伝えることである理由でもある。default: y = 'bx; がやっているのはまさにそれだ。

6.2 The exact shapes that leave a variable unassigned6.2 讓變數未被賦值的確切形狀6.2 変数を未代入のまま残す具体的な形

There are five distinct shapes. Learning to recognise them by silhouette is faster than reasoning about each block from first principles.共有五種不同的形狀。學會用剪影認出它們，比每次都從頭推理一個區塊要快得多。異なる形が五つある。シルエットで見分けられるようになるほうが、毎回ブロックを原理から推論するより速い。

Shape 1 — if with no else形狀 1 — 沒有 else 的 if形 1 — else のない if

always @* if (en) q = d;        // en == 0 leaves q unassigned

The canonical case. The enable is en; the data is d. This is also the standard way to write an intentional D latch, which is why the tool does not treat it as an error: the construct is legitimate, it is only usually unintended.最經典的一個。致能是 en；資料是 d。這也是寫一個刻意的 D 鎖存器的標準方式，這就是為什麼工具不把它當成錯誤：這個構件是正當的，只是通常不是你想要的。典型例である。イネーブルは en、データは d である。これは意図的な D ラッチを書く標準的な方法でもあり、だからこそツールはこれをエラー扱いしない。構文としては正当で、ただたいてい意図されていないだけである。

Shape 2 — if/else if chain with no final else形狀 2 — 沒有最後 else 的 if/else if 串形 2 — 最後の else がない if/else if の連鎖

always @ (a1 or a2)
  begin
    if      ({a2, a1} == 2'b11) y = 1;
    else if ({a2, a1} == 2'b01) y = 0;
    else if ({a2, a1} == 2'b10) y = 0;   // 2'b00 is not covered
  end

This is the slide's incomplete_and module. Three of four possible values of the concatenation are listed; {a2,a1} == 2'b00 falls off the end. The intended function is an AND gate, so the correct result would be y = 0 for that input — but the tool has no way to know that, and builds a latch whose enable is $a_2 + a_1$. The slide's figure shows exactly that: two inverters, a NOR producing the data term, a NAND producing the enable, and a latrnb_a cell. The repair is one word: make the last branch a plain else.這是投影片的 incomplete_and 模組。那個串接的四個可能值裡列了三個；{a2,a1} == 2'b00 從末端掉了出去。原本想要的函數是一個 AND 閘，所以對那個輸入正確的結果應該是 y = 0——但工具沒有辦法知道這件事，於是造了一個致能為 $a_2 + a_1$ 的鎖存器。投影片的圖畫的就是這個：兩個反相器、一個產生資料項的 NOR、一個產生致能的 NAND，加上一個 latrnb_a 元件。修法只要一個字：把最後一個分支改成單純的 else。これはスライドの incomplete_and モジュールである。連接の取りうる四つの値のうち三つが列挙され、{a2,a1} == 2'b00 が末尾からこぼれ落ちる。意図された関数は AND ゲートなので、その入力に対する正しい結果は y = 0 のはずだが、ツールにそれを知る術はなく、イネーブルが $a_2 + a_1$ のラッチを作る。スライドの図はまさにそれを描いている。インバータ 2 個、データ項を作る NOR、イネーブルを作る NAND、そして latrnb_a セルである。修正は一語で済む。最後の分岐を素の else にすればよい。

Shape 3 — case without default and without all items形狀 3 — 沒有 default、也沒有列出所有項目的 case形 3 — default もなく全項目も列挙しない case

always @ (sel_a or sel_b or data_a or data_b)
  case ({sel_a, sel_b})
    2'b10: y_out = data_a;
    2'b01: y_out = data_b;
  endcase                       // 2'b00 and 2'b11 are not covered

The slide's mux_latch. Two of four selector values are listed. The enable is $\text{sel\_a} \oplus \text{sel\_b}$ — true exactly when one and only one select is high — and the slide's own caption states the consequence: "When (sel_a, sel_b) = 00, 11, y_out keeps the old value."投影片的 mux_latch。四個選擇值裡列了兩個。致能是 $\text{sel\_a} \oplus \text{sel\_b}$——恰在有且僅有一個選擇線為高時為真——而投影片自己的圖說寫出了後果：「When (sel_a, sel_b) = 00, 11, y_out keeps the old value.」スライドの mux_latch である。四つのセレクタ値のうち二つが列挙されている。イネーブルは $\text{sel\_a} \oplus \text{sel\_b}$、すなわち選択線がちょうど一本だけ高のときに真となる。そしてスライド自身のキャプションが帰結を述べている。「When (sel_a, sel_b) = 00, 11, y_out keeps the old value.」

Shape 4 — case covering all items of a wider expression than you think形狀 4 — case 涵蓋了一個比你以為的更寬的運算式的所有項目形 4 — 思っているより幅の広い式の全項目を case が覆っている場合

reg [1:0] op;
always @* case (op)
  2'b00: y = a;  2'b01: y = b;  2'b10: y = a & b;
endcase                         // 2'b11 missing: one value, still a latch

A near-miss that students make constantly: three of four values listed. It is a latch for one input combination out of four, and it will pass most testbenches.學生不斷犯的一種差一點點的錯：四個值裡列了三個。四種輸入組合中有一種會產生鎖存器，而且它會通過大部分的測試平台。学生が絶えずやる惜しい誤りである。四つの値のうち三つを列挙している。四通りの入力の組合せのうち一つでラッチになり、しかもたいていのテストベンチは通ってしまう。

Shape 5 — multiple variables, only some assigned per branch形狀 5 — 多個變數，每個分支只賦值其中一部分形 5 — 複数の変数があり、枝ごとに一部しか代入しない

always @* begin
  case (state)
    IDLE: begin  start = 0;  busy = 0;  done = 0;  end
    RUN:  begin  start = 0;  busy = 1;              end   // done not assigned here
    FIN:  begin             busy = 0;  done = 1;  end     // start not assigned here
    default: begin start = 0; busy = 0; done = 0; end
  endcase
end

This is by far the most common shape in real code and the hardest to spot by eye, because the case is complete. The incompleteness is per-variable. busy is assigned in all four arms and is fine. done is unassigned in RUN, so it latches with enable $\overline{\text{RUN}}$. start is unassigned in FIN, so it latches with enable $\overline{\text{FIN}}$. One complete case, two latches. Any output-decode block of a finite state machine with more than three outputs will do this to you sooner or later, which is why the "default assignment at the top" cure in Section 6.5 exists.這是真實程式碼裡遠遠最常見的形狀，也是最難用肉眼看出來的，因為那個 case 確實是完整的。不完整是逐變數發生的。busy 在四個分支裡都有賦值，沒問題。done 在 RUN 裡沒被賦值，所以它鎖存，致能是 $\overline{\text{RUN}}$。start 在 FIN 裡沒被賦值，所以它鎖存，致能是 $\overline{\text{FIN}}$。一個完整的 case，兩個鎖存器。任何有三個以上輸出的有限狀態機輸出解碼區塊，遲早都會這樣對你，這就是第 6.5 節「在頂端放預設賦值」那個解法存在的理由。これは実際のコードで断然最も多い形であり、目で見つけるのが最も難しい形でもある。case 自体は完全だからだ。不完全なのは変数ごとである。busy は四つの枝すべてで代入されており問題ない。done は RUN で代入されないので、イネーブル $\overline{\text{RUN}}$ のラッチになる。start は FIN で代入されないので、イネーブル $\overline{\text{FIN}}$ のラッチになる。完全な case 一つに、ラッチが二つである。出力が三つを超える有限状態機械の出力デコードブロックは、遅かれ早かれあなたにこれをやる。第 6.5 節の「冒頭でデフォルト代入」という対処が存在する理由である。

6.3 What the netlist actually looks like6.3 網表實際上長什麼樣子6.3 ネットリストは実際どう見えるか

Take Shape 3, the slide's mux_latch, and derive the netlist by hand so that you can recognise it in a schematic viewer.拿形狀 3，也就是投影片的 mux_latch，親手推導出網表，這樣你就能在電路圖檢視器裡認出它。形 3、すなわちスライドの mux_latch を取り上げ、ネットリストを手で導いてみよう。回路図ビューアで見分けられるようになる。

module mux_latch (y_out, sel_a, sel_b, data_a, data_b);
  input  sel_a, sel_b, data_a, data_b;
  output y_out;
  reg    y_out;

  always @ (sel_a or sel_b or data_a or data_b)
    case ({sel_a, sel_b})
      2'b10: y_out = data_a;
      2'b01: y_out = data_b;      // incomplete case list
    endcase
endmodule

Write $s_a$, $s_b$, $d_a$, $d_b$. The two assigning conditions are $C_a = s_a\overline{s_b}$ and $C_b = \overline{s_a}s_b$. Applying the mechanism:寫下 $s_a$、$s_b$、$d_a$、$d_b$。兩個有賦值的條件是 $C_a = s_a\overline{s_b}$ 與 $C_b = \overline{s_a}s_b$。套用機制：$s_a$、$s_b$、$d_a$、$d_b$ と書く。代入が行われる条件は $C_a = s_a\overline{s_b}$ と $C_b = \overline{s_a}s_b$ の二つである。機構を当てはめると次のようになる。

So the netlist is: an XOR (or an AND-NOR pair) producing the enable, a 2:1 mux producing the data, and one D-latch cell. Three cells where you expected one mux. The slide's figure draws it with inverters and AND gates rather than an XOR, which is the same function in a different cover.所以網表是：一個 XOR（或一對 AND-NOR）產生致能，一個 2:1 多工器產生資料，加上一個 D 鎖存器元件。你本來預期一個多工器，結果是三個元件。投影片的圖是用反相器與 AND 閘而不是 XOR 畫的，那是同一個函數的另一種覆蓋方式。したがってネットリストは、イネーブルを作る XOR（あるいは AND と NOR の対）、データを作る 2:1 マルチプレクサ、そして D ラッチセル 1 個である。マルチプレクサ 1 個のつもりが、セル 3 個になる。スライドの図は XOR ではなくインバータと AND ゲートで描かれているが、同じ関数を別の被覆で表したものである。

In a netlist text file you recognise the damage by the cell type. Latch cells are named with a recognisable stem in every library: LATQ, DLH, LHQ, latrnb, LN. Flip-flops carry DFF, SDFF, FD. If a module you believe is combinational contains any instance of the former, you have found an inferred latch. The instance name is usually the RTL variable with _reg appended and the bit index in brackets, which is how you trace it back to the offending always block.在網表文字檔裡，你靠元件型別認出災情。鎖存器元件在每個元件庫裡都有可辨識的字根：LATQ、DLH、LHQ、latrnb、LN。正反器帶的是 DFF、SDFF、FD。如果一個你認為是組合邏輯的模組裡出現前者的任何實體，你就找到一個推論鎖存器了。實體名稱通常是 RTL 變數加上 _reg 字尾，再用中括號帶位元索引，這就是你把它追回到那個惹禍的 always 區塊的方式。ネットリストのテキストファイルでは、セルの型で被害を見分ける。ラッチセルはどのライブラリでも見分けのつく語幹を持つ。LATQ、DLH、LHQ、latrnb、LN などである。フリップフロップは DFF、SDFF、FD を帯びる。組合せだと思っていたモジュールに前者のインスタンスが一つでもあれば、推論ラッチを見つけたことになる。インスタンス名はたいてい RTL の変数名に _reg を付け、角括弧でビット添字を付けたものであり、それを辿れば問題の always ブロックに戻れる。

The same information arrives much earlier and much more cheaply in the elaboration report. Design Compiler prints a block headed "Inferred memory devices in process" with a table listing the register name, type, width, and whether it has async set, async reset, sync set, sync reset. A latch row shows Latch in the type column and has blanks where a flip-flop would show a clock. Genus prints an equivalent table. Reading that table is the thirty-second habit that prevents everything in this section.同樣的資訊在展開報告裡會更早、也更便宜地送到你面前。Design Compiler 會印出一個標題為「Inferred memory devices in process」的區塊，表中列出暫存器名稱、型別、寬度，以及它有沒有非同步設定、非同步重置、同步設定、同步重置。鎖存器那一列在型別欄顯示 Latch，而且在正反器會顯示時脈的地方是空白。Genus 印的是一張等效的表。讀那張表，就是能防掉本節一切的那個三十秒習慣。同じ情報は、エラボレーションレポートならもっと早く、もっと安く手に入る。Design Compiler は「Inferred memory devices in process」という見出しのブロックを印字し、表にレジスタ名・種別・幅、そして非同期セット／非同期リセット／同期セット／同期リセットの有無を並べる。ラッチの行は種別の欄に Latch と出て、フリップフロップならクロックが表示される欄が空になる。Genus も同等の表を出す。この表を読むことこそ、本節のすべてを防ぐ 30 秒の習慣である。

6.4 Why a latch in a combinational block wrecks static timing analysis6.4 為什麼組合邏輯區塊裡的鎖存器會毀掉靜態時序分析6.4 なぜ組合せブロック内のラッチが静的タイミング解析を壊すのか

Most students accept "latches are bad" as a rule of thumb without knowing why, and then quietly assume that since a latch has about the area of two NANDs, the cost is small. The area cost is small. The cost is in timing closure, and it is large. Here is the chain of reasoning.多數學生把「鎖存器不好」當成經驗法則接受下來，卻不知道為什麼，然後默默假設既然一個鎖存器大約只有兩個 NAND 的面積，代價應該很小。面積代價確實很小。代價在時序收斂上，而且很大。以下是推理的鏈條。多くの学生は「ラッチは良くない」を経験則として受け入れるが、理由は知らない。そして、ラッチの面積は NAND 二個分程度なのだからコストは小さいはずだと静かに思い込む。面積のコストは確かに小さい。コストはタイミングクロージャにあり、そちらは大きい。以下がその推論の鎖である。

Static timing analysis works by decomposing the design into timing paths, each running from a startpoint to an endpoint. Startpoints are primary inputs and clock pins of sequential cells; endpoints are primary outputs and data pins of sequential cells. For an edge-triggered design every path begins at one clock edge and ends before the next, so the analysis is a straightforward comparison of the longest path delay against the clock period minus setup time. This is why synchronous design is popular: timing verification is a shortest-and-longest-path problem on a DAG, and it is exact.靜態時序分析的做法，是把設計分解成一條條時序路徑，每一條從一個起點跑到一個終點。起點是主要輸入與序向元件的時脈腳；終點是主要輸出與序向元件的資料腳。對一個邊緣觸發的設計而言，每一條路徑都從一個時脈邊緣開始、在下一個邊緣之前結束，所以分析就是把最長路徑延遲拿去跟「時脈週期減去建立時間」比大小，很直接。這就是為什麼同步設計這麼受歡迎：時序驗證是一個有向無環圖上的最長與最短路徑問題，而且是精確的。静的タイミング解析は、設計をタイミングパスに分解して行う。各パスは始点から終点まで走る。始点は主入力と順序セルのクロックピン、終点は主出力と順序セルのデータピンである。エッジトリガの設計ではどのパスも一つのクロックエッジで始まり次のエッジまでに終わるので、解析は最長パス遅延とクロック周期からセットアップ時間を引いた値との単純な比較になる。同期設計が好まれる理由がこれである。タイミング検証は DAG 上の最長・最短経路問題であり、しかも厳密なのだ。

A level-sensitive latch breaks this decomposition in a specific way. While a latch is transparent, a signal arriving at its D pin propagates straight through to Q — the path does not end at the latch. The analyser must therefore consider time borrowing (also called cycle stealing): a path that arrives late at a transparent latch can continue into the next stage, borrowing time from the following cycle, provided the total still closes. Latch-based timing is legitimate and is used deliberately in some high-performance designs for exactly this reason. But it converts the timing problem from "check each path independently" into "solve a system of constraints over chains of latches", which is more expensive, less intuitive, and — the real killer — non-local: whether a path closes now depends on paths several stages away.一個準位敏感的鎖存器以一種特定的方式破壞這個分解。當鎖存器透通時，抵達它 D 腳的訊號會直接穿過去到 Q——路徑不會在鎖存器結束。因此分析器必須考慮借時（time borrowing，也叫 cycle stealing）：一條較晚抵達透通鎖存器的路徑可以繼續進入下一級，向下一個週期借時間，只要總量仍然收斂就行。以鎖存器為基礎的時序是正當的，某些高效能設計正是為此刻意採用它。但它把時序問題從「獨立檢查每一條路徑」變成「在一串鎖存器鏈上解一組約束系統」，那更昂貴、更不直觀，而且——真正要命的是——非區域性：一條路徑現在能不能收斂，取決於好幾級之外的路徑。レベルセンシティブなラッチは、この分解を特定の形で壊す。ラッチが透過している間、D ピンに届いた信号はそのまま Q へ抜ける。パスはラッチで終わらないのだ。したがって解析器はタイムボローイング（サイクルスチールとも呼ぶ）を考慮しなければならない。透過中のラッチに遅れて到着したパスは次段へ進み、全体として収まる限り、次サイクルから時間を借りられる。ラッチベースのタイミングは正当な手法であり、一部の高性能設計はまさにこの理由で意図的に採用する。しかしそれはタイミングの問題を「各パスを独立に検査する」ものから「ラッチの鎖にまたがる制約系を解く」ものへ変える。高価で、直観に反し、そして本当に厄介なのは非局所的なことである。あるパスが収まるかどうかが、数段離れたパスに依存するようになる。

Set against all that, the functional damage is often the least of it: the output holds a stale value on the uncovered input combination. If that combination genuinely never occurs, the design works. It is the timing, test and verification consequences that make a latch expensive even when it is functionally harmless — and that is the part the one-line rule in the study guide does not convey.相對於上面這些，功能上的損害往往是最輕的：在沒涵蓋到的輸入組合上，輸出抱著一個舊值。如果那個組合真的從不出現，設計就會動。真正讓一個鎖存器變貴的，是時序、測試與驗證上的後果，即使它在功能上無害——而這正是學習指南裡那一行規則傳達不出來的部分。これらに比べれば、機能上の損害はしばしば最も軽い。未カバーの入力の組合せで出力が古い値を保持する、それだけである。その組合せが本当に決して現れないなら、設計は動く。ラッチを高価にするのはタイミング・テスト・検証上の帰結であり、機能的に無害な場合でもそれは変わらない。そしてそこが、スタディガイドの一行の規則では伝わらない部分である。

6.5 The four standard cures6.5 四種標準解法6.5 四つの標準的な対処

All four cures do the same thing — guarantee that every variable receives a value on every path — and they differ in style, in robustness, and in what they imply about your intent.這四種解法做的是同一件事——保證每一個變數在每一條路徑上都拿到一個值——它們的差別在風格、在穩健度，以及在它們對你的意圖暗示了什麼。四つの対処はどれも同じことをする。すべての変数がすべての経路で値を受け取ることを保証するのだ。違いはスタイル、頑健さ、そして自分の意図について何を暗に示すかにある。

Cure 1 — default assignment at the top of the block解法 1 — 在區塊頂端放預設賦值対処 1 — ブロックの冒頭にデフォルト代入を置く

always @* begin
  case (state)
    IDLE: begin start=0; busy=0; done=0; end
    RUN:  begin start=0; busy=1;         end
    FIN:  begin          busy=0; done=1; end
    default: begin start=0; busy=0; done=0; end
  endcase
end
// done latches on RUN, start latches on FIN

always @* begin
  start = 1'b0;  busy = 1'b0;  done = 1'b0;
  case (state)
    IDLE: ;
    RUN:  busy = 1'b1;
    FIN:  done = 1'b1;
    default: ;
  endcase
end
// every variable assigned on every path

This is the strongest cure and the one to adopt as a default habit. It is immune to Shape 5 because the assignment happens before any branching; it survives someone adding a new case arm or a new output six months later; and it makes the code shorter and clearer, because each arm now states only what is different about it.這是最強的解法，也是應該當成預設習慣採用的那一個。它對形狀 5 免疫，因為賦值發生在任何分支之前；它在半年後有人加了一個新的 case 分支或一個新輸出時依然成立；而且它讓程式碼更短也更清楚，因為每個分支現在只陳述它有什麼不同。これが最も強い対処であり、既定の習慣として採用すべきものである。代入が分岐より前に起きるので形 5 に対して免疫があり、半年後に誰かが新しい case の枝や新しい出力を加えても生き残る。しかも各枝は何が違うかだけを述べればよくなるので、コードは短く明快になる。

The obvious objection — "does the first assignment not cost a mux?" — is answered by the dead-value elimination mentioned in Section 1.4. The tool observes that on a path where a later assignment occurs, the earlier value never reaches an output, and it simply does not build it. The structure synthesised is identical to the fully-explicit version. There is no area penalty whatsoever.一個顯而易見的反對意見——「第一個賦值不會多花一個多工器嗎？」——答案就是第 1.4 節提到的死值消去。工具觀察到：在一條後面還有賦值的路徑上，前面那個值永遠到不了輸出，於是它根本不把它造出來。合成出來的結構與完全明寫的版本一模一樣。完全沒有任何面積代價。当然の反論、「最初の代入でマルチプレクサが一つ増えるのでは」には、第 1.4 節で触れた死値除去が答えになる。後で代入がある経路では先の値が出力に届かないことをツールは見抜き、そもそもそれを作らない。合成される構造は完全に明示した版と同一であり、面積のペナルティは一切ない。

Cure 2 — a final, unconditional else解法 2 — 一個最後的、無條件的 else対処 2 — 最後に無条件の else を置く

always @ (a1 or a2) begin
  if      ({a2,a1} == 2'b11) y = 1;
  else if ({a2,a1} == 2'b01) y = 0;
  else if ({a2,a1} == 2'b10) y = 0;
end
// {a2,a1} == 2'b00 falls through

always @ (a1 or a2) begin
  if      ({a2,a1} == 2'b11) y = 1;
  else if ({a2,a1} == 2'b01) y = 0;
  else                       y = 0;
end
// or simply: assign y = a1 & a2;

The slide's annotation — "the last statement should be else condition" — is exactly right. Note how much better the one-line continuous assignment is than either version: four lines of latch-prone procedural code describing an AND gate. When the function fits in an expression, assign removes the entire class of bug.投影片的註解——「the last statement should be else condition」——完全正確。也請注意那一行連續賦值比兩個版本都好得多：四行容易長鎖存器的程序式程式碼，只為了描述一個 AND 閘。當函數塞得進一個運算式時，assign 把這一整類錯誤都消掉了。スライドの注記「the last statement should be else condition」はまったく正しい。そして、1 行の連続代入がどちらの版よりはるかに優れている点にも注目したい。AND ゲート一つを記述するために、ラッチを生みやすい手続きコードを 4 行も書いているのだ。関数が一つの式に収まるなら、assign はこの種のバグを丸ごと消し去る。

Cure 3 — a default: arm in every case解法 3 — 每個 case 都要有 default: 分支対処 3 — すべての case に default: の枝を置く

The slide's alu_complete is the model, and it is dissected in Section 6.7. The rule is absolute: every case statement gets a default, with no exceptions, even when you have enumerated all values of the selector. The reason for the no-exceptions form is maintenance. Today sel is two bits and you listed four arms; next month someone widens it to three bits and you have eight values, four of them unhandled, and a latch appears in code nobody edited. A default arm makes that impossible.投影片的 alu_complete 就是範本，第 6.7 節會逐行解剖它。規則是絕對的：每一個 case 敘述都要有 default，沒有例外，就算你已經把選擇線的所有值都列出來了也一樣。之所以要寫成「沒有例外」，理由是維護。今天 sel 是兩位元，你列了四個分支；下個月有人把它加寬成三位元，於是有八個值，其中四個沒被處理，而一個鎖存器出現在沒有人編輯過的程式碼裡。一個 default 分支讓這件事不可能發生。スライドの alu_complete が手本であり、第 6.7 節で逐行解剖する。規則は絶対である。すべての case 文に default を置く。例外なし。セレクタの値をすべて列挙済みの場合でも置く。例外なしとする理由は保守にある。今日の sel は 2 ビットで枝を四つ書いた。来月だれかがそれを 3 ビットに広げると値は八つになり、うち四つが未処理となって、誰も編集していないコードにラッチが現れる。default の枝はそれを不可能にする。

What value should the default produce? Three sensible answers, in order of preference:default 應該產生什麼值？三個合理的答案，依偏好排序：default は何を出すべきか。妥当な答えが三つあり、好ましい順に挙げる。

• A safe concrete value (zero, or an "idle" encoding) when the uncovered inputs can occur. Costs a little logic, behaves predictably, and matches between RTL and gates.一個安全的具體值（零，或一個「閒置」編碼），當那些沒涵蓋的輸入真的可能發生時。會花一點邏輯，行為可預測，而且 RTL 與閘級一致。安全な具体値（ゼロ、あるいは「アイドル」の符号）。未カバーの入力が実際に起こりうる場合に使う。多少の論理を要するが、振る舞いは予測でき、RTL とゲートが一致する。
• 'bx when the uncovered inputs genuinely cannot occur. Costs nothing — it saves logic, as Section 10 shows — but introduces a controlled RTL-versus-netlist divergence, because the netlist will produce some definite value where the RTL produced x.'bx，當那些沒涵蓋的輸入真的不可能發生時。不花代價——如第 10 節所示，它反而省邏輯——但引入一個受控的 RTL 與網表分歧，因為網表會在 RTL 產生 x 的地方產生某個確定的值。'bx。未カバーの入力が本当に起こりえない場合に使う。コストはかからず、第 10 節が示すとおり論理を減らす。ただし制御された RTL とネットリストの乖離を持ち込む。RTL が x を出すところで、ネットリストは何らかの確定値を出すからである。
• A repeat of the most common arm, which sometimes lets the optimiser merge branches. Rarely worth the loss of clarity.重複最常用的那個分支，有時能讓最佳化器合併分支。很少值得犧牲清晰度。最も頻度の高い枝の繰り返し。最適化器が枝を併合できることがある。明快さを失う代償に見合うことはまれである。

What the default must never be is y = y;. That is Section 7's combinational loop, and it is strictly worse than the latch you were trying to avoid.default 絕對不可以是 y = y;。那是第 7 節的組合迴路，而且嚴格來說比你原本想避開的那個鎖存器更糟。default が決してなってはならないのは y = y; である。それは第 7 節の組合せループであり、避けようとしていたラッチより厳密に悪い。

Cure 4 — casez / casex and the full_case directive解法 4 — casez / casex 與 full_case 指示詞対処 4 — casez / casex と full_case ディレクティブ

The fourth approach is to tell the tool that the case is complete even though it does not look complete. Verilog gives you two mechanisms and they are not equivalent.第四種做法是告訴工具這個 case 其實是完整的，即使它看起來不完整。Verilog 給你兩種機制，而它們並不等價。四つ目の方法は、見た目は完全でなくとも case は完全だとツールに伝えることである。Verilog は二つの仕組みを用意しているが、両者は等価ではない。

The honest one is to use casez (or casex) with wildcard patterns that genuinely cover the whole space. If your selector is eight bits but only the top three matter, then casez with items like 8'b000????? covers thirty-two values per arm, and eight such arms cover all 256 — the statement really is complete, and no latch appears. This is the technique behind the casex priority encoder in Section 8.3, and it is entirely legitimate.誠實的那一種，是用 casez（或 casex）搭配真的覆蓋整個空間的萬用字元樣式。如果你的選擇線有八位元但只有最高三位有意義，那麼用 casez 搭配像 8'b000????? 這樣的項目，每個分支覆蓋三十二個值，八個這樣的分支就覆蓋全部 256 個——這個敘述真的是完整的，不會出現鎖存器。這就是第 8.3 節 casex 優先權編碼器背後的技巧，完全正當。誠実なほうは、空間を本当に覆うワイルドカードのパターンを casez（または casex）で使う方法である。セレクタが 8 ビットでも上位 3 ビットしか意味を持たないなら、8'b000????? のような項目を使う casez は 1 枝で 32 個の値を覆い、そうした枝が八つあれば 256 個すべてを覆う。文は本当に完全であり、ラッチは現れない。これが第 8.3 節の casex プライオリティエンコーダの背後にある技であり、まったく正当である。

The dangerous one is the synthesis pragma // synopsys full_case, which asserts to the tool — without proof — that the unlisted values never occur, so no latch is needed. It is attached as a comment and therefore invisible to the simulator.危險的那一種，是合成用的 pragma // synopsys full_case，它在沒有任何證明的情況下向工具宣稱：那些沒列出的值永遠不會出現，所以不需要鎖存器。它是以註解的形式附加的，因此對模擬器而言是隱形的。危険なほうは合成用のプラグマ // synopsys full_case である。これは証明なしに「列挙していない値は決して現れないのでラッチは不要だ」とツールに宣言する。コメントとして付けられるため、シミュレータからは見えない。

6.6 A worked comparison: the same bug fixed four ways6.6 一次完整的對照：同一個錯誤的四種修法6.6 比較の実演：同じバグを四通りに直す

6.7 The slide's ALU case study, line by line6.7 投影片的 ALU 個案研究，逐行看6.7 スライドの ALU ケーススタディを一行ずつ

The lecture gives three versions of the same ALU and the comparison between them makes a point that is easy to miss.本講給了同一個 ALU 的三個版本，而它們之間的對照帶出一個很容易被忽略的重點。講義は同じ ALU の三つの版を示す。その比較が、見落とされやすい論点を突きつける。

module alu_incomplete1a (alu_out, data_a,
                   data_b, enable, opcode);
  input  [2:0] opcode;
  input  [3:0] data_a, data_b;
  input        enable;
  output       alu_out;    // scalar
  reg    [3:0] alu_reg;

  assign alu_out = (enable == 1) ? alu_reg : 4'b0;

  always @ (opcode)          // defect B
    case (opcode)
      3'b001: alu_reg = data_a | data_b;
      3'b010: alu_reg = data_a ^ data_b;
      3'b110: alu_reg = ~data_b;
    endcase                 // defect A
endmodule

module alu_incomplete2a (alu_out, data_a,
                   data_b, enable, opcode);
  input  [2:0] opcode;
  input  [3:0] data_a, data_b;
  input        enable;
  output       alu_out;
  reg    [3:0] alu_reg;

  assign alu_out = (enable == 1) ? alu_reg : 4'b0;

  always @ (opcode or data_a or data_b)
    case (opcode)
      3'b001: alu_reg = data_a | data_b;
      3'b010: alu_reg = data_a ^ data_b;
      3'b110: alu_reg = ~data_b;
    endcase                 // defect A remains
endmodule

Version 1a has both defects from Section 4.4: the sensitivity list omits data_a and data_b (Defect B, a mismatch), and the case omits five opcodes (Defect A, a latch). Version 2a fixes the sensitivity list and nothing else. Both synthesise to exactly the same netlist, latch included. That is the pedagogical point of putting them side by side: fixing the sensitivity list does nothing for the latch, because the latch was never about sensitivity.版本 1a 同時有第 4.4 節的兩個缺陷：敏感度列表漏了 data_a 與 data_b（缺陷 B，不匹配），而 case 漏了五個 opcode（缺陷 A，鎖存器）。版本 2a 只修了敏感度列表，其餘不動。兩者合成出來的網表完全相同，鎖存器照樣在裡面。把它們並排放在一起的教學意義就在這裡：修敏感度列表對鎖存器毫無幫助，因為鎖存器從頭到尾就不是敏感度的問題。版 1a には第 4.4 節の二つの欠陥が揃っている。センシティビティリストから data_a と data_b が抜けており（欠陥 B、不一致）、case が五つの opcode を落としている（欠陥 A、ラッチ）。版 2a はセンシティビティリストだけを直し、他は変えていない。両者は完全に同じネットリストに合成され、ラッチもそのまま残る。この二つを並べる教育的な意味はそこにある。センシティビティリストを直してもラッチには何の効果もない。ラッチはそもそもセンシティビティの問題ではなかったからだ。

The slide's synthesis figure for 2a shows the structure predicted by Section 6.3: NAND and NOR cells computing the three data functions, two muxes selecting between them under the opcode decode, a latrnb_a cell holding the result, and a final NAND gating with enable. There is also an esdpupd block in the corner — an ESD pull-up device, an artefact of that particular library's I/O handling, not part of the logic.投影片為 2a 畫的合成圖，顯示的正是第 6.3 節預測的結構：NAND 與 NOR 元件算出三個資料函數，兩個多工器在 opcode 解碼的控制下在它們之間選擇，一個 latrnb_a 元件保住結果，最後一個 NAND 用 enable 做閘控。角落裡還有一個 esdpupd 區塊——那是一個 ESD 上拉元件，是那座特定元件庫 I/O 處理的產物，不是邏輯的一部分。スライドが 2a について描く合成図は、第 6.3 節が予測した構造そのものである。NAND と NOR のセルが三つのデータ関数を計算し、opcode のデコードに制御された二つのマルチプレクサがその中から選び、latrnb_a セルが結果を保持し、最後の NAND が enable でゲートする。隅には esdpupd のブロックもあるが、これは ESD プルアップ素子で、そのライブラリ特有の I/O 処理の産物であり論理の一部ではない。

module alu_complete (alu_out, data_a, data_b, enable, opcode);
  input  [2:0] opcode;
  input  [3:0] data_a, data_b;
  input        enable;
  output       alu_out;
  reg    [3:0] alu_reg;

  assign alu_out = (enable == 1) ? alu_reg : 4'b0;

  always @ (opcode or data_a or data_b)
    case (opcode)
      3'b001:  alu_reg = data_a | data_b;
      3'b010:  alu_reg = data_a ^ data_b;
      3'b110:  alu_reg = ~data_b;
      default: alu_reg = 4'b0;          // completes the case list
    endcase
endmodule

One line removes the latch. The slide's figure for alu_complete shows pure gates and one mux feeding the output NAND — no rectangular latch symbol anywhere.一行就能移除鎖存器。投影片為 alu_complete 畫的圖顯示的是純邏輯閘加上一個多工器餵進輸出的 NAND——任何地方都沒有那個長方形的鎖存器符號。一行でラッチは消える。スライドの alu_complete の図には、純粋なゲートと出力 NAND を駆動するマルチプレクサ 1 個が描かれ、長方形のラッチ記号はどこにもない。

// (a)
always @ (a or b or s) if (s) y = a; else y = b;
// (b)
always @ (en or d) if (en) q = d;
// (c)
always @ (s or a or b) begin y = b; if (s) y = a; end
// (d)  op is 2 bits, y is 8 bits
always @ (op or a or b)
  case (op) 2'b00: y = a; 2'b01: y = b; 2'b10: y = a & b; endcase
// (e)  op is 2 bits
always @ (op or a or b)
  case (op) 2'b00: y=a; 2'b01: y=b; 2'b10: y=a&b; 2'b11: y=a|b; endcase
// (f)  g, h are 4 bits; mode is 2 bits
always @* case (mode)
  2'b00: begin g = 4'd1; h = 4'd2; end
  2'b01: begin g = 4'd3;           end
  2'b10: begin           h = 4'd4; end
  2'b11: begin g = 4'd5; h = 4'd6; end
endcase
// (g)
always @* begin
  y = 1'b0;
  casez (sel)
    4'b1???: y = 1'b1;
    4'b01??: y = 1'b1;
  endcase
end

7. Combinational Feedback Loops7. 組合邏輯回授迴路7. 組合せフィードバックループ

7.1 The shape: a complete statement, completed by self-assignment7.1 形狀：一個被自我賦值補完的完整敘述7.1 その形：自己代入で完成させられた完全な文

Section 6 established that an incompletely specified statement infers a latch. A natural but wrong reaction is: "fine, I will complete it — I will just write the variable back to itself on the leftover path." The lecture devotes four slides to showing why that is worse, and the slides are worth taking seriously because the reasoning is not obvious.第 6 節確立了「不完整指定的敘述會推論出鎖存器」。一個自然但錯誤的反應是：「好，那我把它補完——我就在剩下的那條路徑上把變數寫回它自己。」本講用四張投影片說明為什麼那樣更糟，而這些投影片值得認真看，因為推理並不顯而易見。第 6 節は、不完全に指定された文がラッチを推論させることを確立した。自然だが誤った反応はこうである。「よし、完全にしよう。残った経路で変数を自分自身に書き戻せばいい」。講義はそれがなぜ悪手なのかの説明に四枚のスライドを割いており、推論は自明ではないので真面目に読む価値がある。

module latch_case1 (latch_out, latch_in,
                    set, clear, enable);
  input  latch_in, set, clear, enable;
  output latch_out;
  reg    latch_out;

  always @ (enable or set or clear or latch_in)
    case ({enable, set, clear})
      3'b000: latch_out = latch_in;  // transparent
      3'b110: latch_out = 1'b1;      // set
      3'b010: latch_out = 1'b1;      // set
      3'b101: latch_out = 1'b0;      // clear
      3'b001: latch_out = 1'b0;      // clear
      default: latch_out = latch_out; // holds residual value
    endcase
endmodule

module latch_if1 (data_out, data_in,
                  latch_enable);
  input  [3:0] data_in;
  output [3:0] data_out;
  input        latch_enable;
  reg    [3:0] data_out;

  always @ (latch_enable or data_in)
    if (latch_enable) data_out = data_in;
    else data_out = data_out;
endmodule

Syntactically both statements are now complete — every path assigns the variable — so Section 6's latch-inference rule does not fire. What fires instead is Rule 3 from Section 4.4: the target of an assignment appears as an operand on the right-hand side. The tool builds precisely what you wrote: a multiplexer whose 0 input is the multiplexer's own output.語法上這兩個敘述現在都完整了——每一條路徑都賦值給該變數——所以第 6 節的鎖存器推論規則不會觸發。觸發的是第 4.4 節的規則 3：賦值的目標以運算元的身分出現在右手邊。工具精確地造出你寫的東西：一個多工器，它的 0 輸入是這個多工器自己的輸出。構文上、どちらの文もいまや完全である。すべての経路が変数に代入しているので、第 6 節のラッチ推論の規則は発火しない。発火するのは第 4.4 節の規則 3、すなわち代入の対象が右辺にオペランドとして現れていることである。ツールは書かれたとおりのものを正確に作る。0 入力が自分自身の出力であるマルチプレクサである。

7.2 Why the tool cannot map it7.2 為什麼工具映射不了它7.2 なぜツールはこれをマッピングできないのか

The slides annotate both synthesis results with the same blunt note: "Can't be synthesized to the gates." That is correct, and there are three independent reasons, any one of which is sufficient.投影片在兩個合成結果上都加了同一句直白的註解：「Can't be synthesized to the gates.」那是對的，而理由有三個彼此獨立，任何一個都足夠。スライドは二つの合成結果のどちらにも同じそっけない注記を付けている。「Can't be synthesized to the gates.」これは正しく、理由は互いに独立に三つあり、どれ一つでも十分である。

The optimiser's data structure is a DAG. Every algorithm in Section 3 — decomposition, factoring, substitution, elimination — assumes it can traverse the network from inputs to outputs in topological order. A cycle has no topological order. The tool must either refuse the structure or break the cycle arbitrarily, and most tools report a combinational feedback loop and stop optimising that cone.最佳化器的資料結構是一個有向無環圖。第 3 節的每一個演算法——分解、因式分解、代入、消去——都假設它可以依拓樸順序從輸入走到輸出。一個環沒有拓樸順序。工具要嘛拒絕這個結構，要嘛任意把環切開，而大多數工具會回報一個組合回授迴路，並停止最佳化那個邏輯錐。最適化器のデータ構造は DAG である。第 3 節のアルゴリズムはどれも——分解・因数分解・代入・消去——ネットワークを入力から出力へトポロジカル順に辿れることを前提とする。閉路にトポロジカル順序はない。ツールはその構造を拒むか、恣意的に閉路を切るかで、多くのツールは組合せフィードバックループを報告し、そのコーンの最適化をやめる。

Static timing analysis cannot close a cycle. A path through a feedback loop has no end; computing arrival times requires iterating around the loop, which does not converge. STA tools detect loops and break them by disabling one timing arc — the choice of arc is heuristic and is reported as a warning. The disabled arc means some real path is no longer being checked.靜態時序分析無法收斂一個環。穿過回授迴路的路徑沒有終點；計算到達時間需要繞著環迭代，而那不會收斂。STA 工具會偵測到環，並藉由停用某一條時序弧來切開它——選哪一條弧是啟發式的，並會以警告回報。被停用的那條弧意味著某條真實路徑不再被檢查。静的タイミング解析は閉路を収束させられない。フィードバックループを通る経路には終点がない。到着時刻の計算はループを回る反復を要し、それは収束しない。STA ツールはループを検出し、タイミングアークを一本無効にして断ち切る。どのアークを選ぶかはヒューリスティックで、警告として報告される。無効にされたアークは、実在するどこかの経路がもう検査されないことを意味する。

The physical behaviour is a race, not a function. A mux whose output feeds its own input is, electrically, a bistable element: when the enable is low, the loop sustains whatever value is on the wire. That is a latch built from a mux rather than from a characterised latch cell, with three serious differences. It has no guaranteed setup or hold window, because nobody characterised it. Its hold time against the enable's own transition depends on the mux's internal delays, so a slow enable edge can cause it to catch a new value. And it is vulnerable to any glitch on the loop, with no restoring feedback designed in. In marginal silicon such a structure can oscillate rather than hold.物理行為是一場競賽，不是一個函數。一個輸出餵回自己輸入的多工器，在電性上是一個雙穩態元件：當致能為低時，這個環維持住導線上原本是什麼值。那是一個用多工器而不是用特徵化鎖存器元件造出來的鎖存器，有三個嚴重的差別。它沒有保證的建立或保持視窗，因為沒有人特徵化過它。它相對於致能自身轉態的保持時間，取決於多工器的內部延遲，所以一個很慢的致能邊緣可能讓它抓到一個新值。而且它對環上的任何毛刺都毫無抵抗力，因為裡面沒有設計任何恢復性回授。在體質邊緣的矽片上，這種結構可能振盪而不是保持。物理的な振る舞いは関数ではなく競合である。出力が自分の入力に戻るマルチプレクサは、電気的には双安定素子である。イネーブルが低のとき、ループは配線上にあった値をそのまま維持する。それは特性化されたラッチセルではなくマルチプレクサで作ったラッチであり、三つの重大な違いがある。誰も特性化していないので、保証されたセットアップやホールドのウィンドウがない。イネーブル自身の遷移に対するホールド時間がマルチプレクサ内部の遅延に依存するので、イネーブルのエッジが遅いと新しい値を取り込んでしまうことがある。そしてループ上のどんなグリッチにも無防備で、復元のためのフィードバックが設計されていない。歩留まりぎりぎりのシリコンでは、この構造は保持する代わりに発振しうる。

The lecture's phrase "un-synthesised" is best read as: the tool will produce something — the slide's own figures show four muxes with their outputs looped back — but that something is not a mapped, characterisable circuit, and no downstream tool will treat it as one.本講那句「un-synthesised」最好讀成：工具會產生某個東西——投影片自己的圖就畫出四個輸出繞回去的多工器——但那個東西不是一個已映射、可特徵化的電路，而且下游不會有任何工具把它當成一個電路看待。講義の「un-synthesised」という語はこう読むのがよい。ツールは何かを出力する——スライド自身の図が出力をループバックさせたマルチプレクサを四つ描いている——が、その何かはマッピング済みで特性化できる回路ではなく、下流のどのツールもそれを回路として扱わない。

7.3 The irony: the honest latch is strictly better7.3 諷刺之處：誠實的鎖存器嚴格來說更好7.3 皮肉なこと：正直なラッチのほうが厳密に優れている

Here is the result worth remembering. The author of latch_if1 wanted a latch — it is in the module name. The self-assignment was an attempt to express "hold" explicitly, because leaving it implicit felt sloppy. The outcome is a structure that is functionally a latch, electrically a worse latch, and administratively a disaster.這裡有個值得記住的結果。latch_if1 的作者想要一個鎖存器——模組名字就這麼寫著。自我賦值是想把「保持」明白地表達出來的嘗試，因為把它留成隱含的感覺很邋遢。結果是一個在功能上是鎖存器、在電性上是更差的鎖存器、在行政上是一場災難的結構。ここに覚えておく価値のある結果がある。latch_if1 の作者はラッチが欲しかった。モジュール名にそう書いてある。自己代入は「保持」を明示的に表そうとした試みで、暗黙のままにしておくのがだらしなく感じられたのだ。その結果は、機能的にはラッチ、電気的にはより劣悪なラッチ、そして運用上は災厄である構造だった。

always @ (latch_enable or data_in)
  if (latch_enable) data_out = data_in;
  else              data_out = data_out;
// -> mux with feedback; not mappable

always @ (latch_enable or data_in)
  if (latch_enable) data_out = data_in;
// -> four LATQ cells from the library

Omitting the else matches the tool's latch-inference template. Templates are how synthesisers recognise storage: a fixed set of code shapes that the front end knows how to replace with a library cell. An if with no else in a level-sensitive block is the latch template; always @(posedge clk) is the flip-flop template, which is Lecture 6's subject. Writing the hold explicitly steps outside the template, and outside the template the tool has no replacement to offer — it falls back to building literally what you said.省略 else 剛好符合工具的鎖存器推論範本。範本就是合成器辨識儲存元件的方式：一組固定的程式碼形狀，前端知道該用哪個元件庫元件去替換它們。準位敏感區塊裡一個沒有 else 的 if，就是鎖存器範本；always @(posedge clk) 是正反器範本，那是第 6 講的主題。把保持明白地寫出來，就踏出了範本之外，而在範本之外工具沒有任何替換品可以提供——它只好退回去，照你說的字面意思造。else を省くことは、ツールのラッチ推論テンプレートに一致する。テンプレートこそ合成器が記憶素子を認識する仕組みであり、フロントエンドがライブラリセルに置き換える方法を知っている、固定されたコードの形の集合である。レベルセンシティブなブロックで else のない if がラッチのテンプレートであり、always @(posedge clk) がフリップフロップのテンプレートで、こちらは第 6 講の主題である。保持を明示的に書けばテンプレートの外へ出てしまい、外ではツールに差し出す置き換えがない。書かれた文字どおりのものを作る以外になくなるのだ。

Note also the second-order lesson about latch_case1. That module's case lists five of eight values of {enable, set, clear} and closes with the self-assigning default. Replace the default with default: latch_out = 1'b0; and you get clean combinational logic that forces zero on the three unlisted combinations. Delete the default entirely and you get a clean inferred latch whose enable is the OR of the five listed conditions. Both are mappable. Only the self-assignment is not. The construct that looks safest is the only unusable one.也請注意關於 latch_case1 的第二層教訓。那個模組的 case 列出 {enable, set, clear} 八個值裡的五個，並以自我賦值的 default 收尾。把那個 default 換成 default: latch_out = 1'b0;，你得到乾淨的組合邏輯，在三個沒列出的組合上強制為零。把 default 整個刪掉，你得到一個乾淨的推論鎖存器，致能是那五個列出條件的 OR。兩者都可映射。只有自我賦值不行。看起來最安全的那個構件，是唯一不能用的。latch_case1 についての二次的な教訓にも注目したい。このモジュールの case は {enable, set, clear} の八つの値のうち五つを列挙し、自己代入の default で締めくくっている。その default を default: latch_out = 1'b0; に置き換えれば、列挙されていない三つの組合せでゼロを強制する、きれいな組合せ論理が得られる。default を丸ごと削れば、列挙された五条件の OR をイネーブルとする、きれいな推論ラッチが得られる。どちらもマッピングできる。できないのは自己代入だけである。最も安全に見える構文が、唯一使えないものなのだ。

// (a-i) intentional latch: match the template, no else
always @ (latch_enable or data_in)
  if (latch_enable) data_out = data_in;

// (a-ii) pure combinational: every path gets a new value
always @ (latch_enable or data_in)
  if (latch_enable) data_out = data_in;
  else              data_out = 4'b0;
// equivalently: assign data_out = latch_enable ? data_in : 4'b0;

// (a-iii) edge-triggered register (Lecture 6)
always @ (posedge clk)
  if (latch_enable) data_out <= data_in;   // non-blocking

8. Priority Structures, Encoders and Decoders8. 優先權結構、編碼器與解碼器8. 優先順位構造・エンコーダ・デコーダ

8.1 Mutually exclusive conditions give a mux; overlapping ones give a chain8.1 互斥條件給出多工器；重疊條件給出鏈8.1 排他的な条件はマルチプレクサを、重なる条件はチェーンを生む

The lecture states the rule in three bullets and it is the most useful single fact in the whole lecture, because it tells you how to control the shape of your logic without writing structural code.本講用三個要點陳述這條規則，而它是整堂課裡最有用的單一事實，因為它告訴你如何在不寫結構式程式碼的情況下控制你邏輯的形狀。講義はこの規則を三つの箇条書きで述べる。構造的なコードを書かずに論理の形を制御する方法を教えてくれるので、これは講義全体で最も有用な単一の事実である。

The reason is pure Boolean algebra. An if/else if chain means, formally, $y = C_1 v_1 + \overline{C_1}C_2 v_2 + \overline{C_1}\,\overline{C_2}C_3 v_3 + \cdots$. If the conditions are pairwise exclusive — that is, $C_iC_j = 0$ for $i \neq j$ — then $\overline{C_1}C_2 = C_2$, $\overline{C_1}\,\overline{C_2}C_3 = C_3$, and so on. The guard terms vanish identically and the expression collapses to the flat one-hot selection $y = C_1v_1 + C_2v_2 + C_3v_3 + \cdots$, which is a multiplexer. No special analysis is needed; the ordinary optimiser discovers it while simplifying.理由是純粹的布林代數。一個 if/else if 串在形式上的意思是 $y = C_1 v_1 + \overline{C_1}C_2 v_2 + \overline{C_1}\,\overline{C_2}C_3 v_3 + \cdots$。如果這些條件兩兩互斥——也就是對 $i \neq j$ 有 $C_iC_j = 0$——那麼 $\overline{C_1}C_2 = C_2$、$\overline{C_1}\,\overline{C_2}C_3 = C_3$，依此類推。那些守衛項恆等地消失，運算式塌成扁平的 one-hot 選擇 $y = C_1v_1 + C_2v_2 + C_3v_3 + \cdots$，那就是一個多工器。不需要任何特殊分析；普通的最佳化器在化簡的過程中就會發現它。理由は純粋なブール代数である。if/else if の連鎖は形式的には $y = C_1 v_1 + \overline{C_1}C_2 v_2 + \overline{C_1}\,\overline{C_2}C_3 v_3 + \cdots$ を意味する。条件が対ごとに排他的、すなわち $i \neq j$ に対し $C_iC_j = 0$ なら、$\overline{C_1}C_2 = C_2$、$\overline{C_1}\,\overline{C_2}C_3 = C_3$ と続く。ガード項は恒等的に消え、式は平坦なワンホット選択 $y = C_1v_1 + C_2v_2 + C_3v_3 + \cdots$ に潰れる。これがマルチプレクサである。特別な解析は要らず、ふつうの最適化器が簡約の途中でこれを見つける。

When the conditions overlap, those guard terms are not redundant, and each one costs a gate on the path. That is what a priority chain is: the accumulated "none of the higher-priority conditions were true" terms. The slide's mux_4pri makes this concrete:當條件重疊時，那些守衛項就不是冗餘的，而且每一個都在路徑上花掉一個閘。優先權鏈就是這個東西：那些累積起來的「所有更高優先權的條件都不成立」的項。投影片的 mux_4pri 把這件事具體化：条件が重なるとき、ガード項は冗長ではなくなり、一つ一つが経路上でゲートを消費する。優先順位チェーンとはそれのことである。積み重なった「より優先度の高い条件はどれも成り立たなかった」という項の列だ。スライドの mux_4pri がそれを具体的に示す。

module mux_4pri (y, a, b, c, d, sel_a, sel_b, sel_c);
  input  a, b, c, d, sel_a, sel_b, sel_c;
  output y;
  reg    y;

  always @ (sel_a or sel_b or sel_c or a or b or c or d)
    begin                       // conditions are NOT mutually exclusive
      if      (sel_a == 1) y = a;
      else if (sel_b == 0) y = b;
      else if (sel_c == 1) y = c;
      else                 y = d;
    end
endmodule

The slide's figure draws this as three cascaded 2:1 muxes with sel_c at the far left and sel_a at the far right, labelled "low" and "high". That ordering is the thing to internalise: the first condition tested is the last mux before the output, because it is the one that overrides everything else. Students routinely draw it backwards.投影片的圖把這畫成三個串接的 2:1 多工器，sel_c 在最左邊、sel_a 在最右邊，標示為「low」與「high」。那個順序是必須內化的事：第一個被判斷的條件，是輸出前的最後一個多工器，因為它是會蓋過其他一切的那一個。學生經常畫反。スライドの図はこれを縦続接続した 2:1 マルチプレクサ三つとして描き、sel_c を左端、sel_a を右端に置いて「low」「high」と注記している。この順序こそ体に入れておくべきことである。最初に判定される条件が、出力の直前の最後のマルチプレクサになる。それが他のすべてを上書きする条件だからだ。学生はたいてい逆に描く。

The timing consequence is direct. Each condition in the chain adds one mux level to the data inputs beneath it, so the worst-case path is from the lowest-priority data input through $N-1$ muxes. For a sixteen-way priority chain that is fifteen levels — likely to be your critical path. The standard remedies are to reduce the chain to a mux by making the conditions exclusive (for example, by pre-decoding the requests into a one-hot vector), or to build a balanced tree of smaller priority blocks, which gives $O(\log N)$ depth at the cost of extra "any request below me" terms. Both are architecture decisions, and both are expressed by changing the conditions, not by adding directives.時序後果很直接。鏈上的每一個條件都為它底下的資料輸入多加一層多工器，所以最差情況的路徑是從優先權最低的資料輸入穿過 $N-1$ 個多工器。對一個十六路的優先權鏈那就是十五層——很可能就是你的關鍵路徑。標準的補救方法，是讓條件互斥以把鏈化成多工器（例如把請求預先解碼成一個 one-hot 向量），或者建一棵由較小優先權區塊組成的平衡樹，以多出一些「我底下有任何請求」的項為代價，把深度降到 $O(\log N)$。兩者都是架構決策，而且兩者都是靠改變條件來表達，不是靠加指示詞。タイミング上の帰結は直接的である。チェーンの各条件は、その下のデータ入力に対しマルチプレクサを 1 段追加するので、最悪経路は最も優先度の低いデータ入力から $N-1$ 個のマルチプレクサを通る。16 路の優先順位チェーンなら 15 段であり、たいていそれがクリティカルパスになる。標準的な改善策は、条件を排他的にして（たとえば要求をワンホットのベクタに事前デコードして）チェーンをマルチプレクサに変えるか、より小さな優先順位ブロックの平衡木を組み、「自分より下に要求があるか」の項を追加する代償で深さを $O(\log N)$ にすることである。どちらもアーキテクチャの決定であり、どちらも条件を変えることで表現する。ディレクティブを足すことではない。

8.2 The 8:3 encoder: exclusive inputs, OR gates only8.2 8:3 編碼器：互斥的輸入，只要 OR 閘8.2 8:3 エンコーダ：排他的な入力、OR ゲートだけ

The lecture gives the plain encoder twice — as an if chain and as a case — and marks them "Equivalent!!".本講把一般編碼器寫了兩次——一次是 if 串，一次是 case——並標註「Equivalent!!」。講義は素のエンコーダを二度示す。一度は if の連鎖として、一度は case として。そして「Equivalent!!」と注記する。

module encoder (Data, Code);
  input  [7:0] Data;
  output [2:0] Code;
  reg    [2:0] Code;

  always @ (Data)
    begin
      if      (Data == 8'b00000001) Code = 0;
      else if (Data == 8'b00000010) Code = 1;
      else if (Data == 8'b00000100) Code = 2;
      else if (Data == 8'b00001000) Code = 3;
      else if (Data == 8'b00010000) Code = 4;
      else if (Data == 8'b00100000) Code = 5;
      else if (Data == 8'b01000000) Code = 6;
      else if (Data == 8'b10000000) Code = 7;
      else                          Code = 3'bx;
    end
endmodule

module encoder (Data, Code);
  input  [7:0] Data;
  output [2:0] Code;
  reg    [2:0] Code;

  always @ (Data)
    case (Data)
      8'b00000001 : Code = 0;
      8'b00000010 : Code = 1;
      8'b00000100 : Code = 2;
      8'b00001000 : Code = 3;
      8'b00010000 : Code = 4;
      8'b00100000 : Code = 5;
      8'b01000000 : Code = 6;
      8'b10000000 : Code = 7;
      default     : Code = 3'bx;
    endcase
endmodule

They are equivalent because the eight patterns are equality tests against distinct constants — mutually exclusive by construction — so Section 8.1's collapse applies and both become flat selection logic. What makes this example remarkable is how far the optimiser then goes.它們等價，是因為那八個樣式是對相異常數的相等比較——在構造上就互斥——所以第 8.1 節的塌陷適用，兩者都變成扁平的選擇邏輯。這個例子真正了不起的地方，是最佳化器接下來走得有多遠。等価であるのは、八つのパターンが相異なる定数との等価比較であり、構成上すでに排他的だからである。したがって第 8.1 節の潰れが適用され、どちらも平坦な選択論理になる。この例が注目に値するのは、そのあと最適化器がどこまで踏み込むかである。

The default: Code = 3'bx declares that all 248 non-one-hot values of Data are don't-cares. The optimiser is therefore free to produce anything for them, and it uses that freedom to discard the equality comparators entirely. Consider $Code[2]$: it must be 1 for the four one-hot patterns $D_4, D_5, D_6, D_7$ and 0 for $D_0 \ldots D_3$; everywhere else it does not matter. The cheapest function meeting that is simply $D_4 + D_5 + D_6 + D_7$.default: Code = 3'bx 宣告了 Data 的 248 個非 one-hot 值全都是不在意項。因此最佳化器可以自由地為它們產生任何東西，而它用這份自由把那些相等比較器整個丟掉。考慮 $Code[2]$：對四個 one-hot 樣式 $D_4, D_5, D_6, D_7$ 它必須是 1，對 $D_0 \ldots D_3$ 必須是 0；其他地方都無所謂。滿足這個條件最便宜的函數，就只是 $D_4 + D_5 + D_6 + D_7$。default: Code = 3'bx は、Data のワンホットでない 248 個の値すべてがドントケアであると宣言する。したがって最適化器はそれらに対して何を出してもよく、その自由を使って等価比較器をまるごと捨てる。$Code[2]$ を考えよう。四つのワンホットパターン $D_4, D_5, D_6, D_7$ では 1、$D_0 \ldots D_3$ では 0 でなければならず、それ以外はどうでもよい。これを満たす最も安い関数は、単に $D_4 + D_5 + D_6 + D_7$ である。

Three or4 cells — about 6 GE for an eight-input function, which matches the slide's synthesis figure exactly. Compare that with what you would get if the default had been Code = 3'b000 instead: the tool would then have to distinguish one-hot inputs from non-one-hot ones, which requires eight 8-bit equality comparators, perhaps 60 GE. A single choice of default value changes the area by a factor of ten. Section 10 returns to this.三個 or4 元件——一個八輸入函數約 6 GE，與投影片的合成圖完全相符。拿它跟 default 改成 Code = 3'b000 的情況比較：那時工具就必須分辨哪些輸入是 one-hot、哪些不是，而那需要八個 8 位元相等比較器，大概 60 GE。一個 default 值的選擇讓面積差了十倍。第 10 節會回到這件事。or4 セル 3 個、8 入力の関数で約 6 GE であり、スライドの合成図と完全に一致する。default が Code = 3'b000 だった場合と比べてみよう。その場合ツールはワンホットの入力とそうでない入力を区別しなければならず、8 ビットの等価比較器が八つ、おそらく 60 GE を要する。default の値の選択一つで面積が 10 倍違う。第 10 節でこの話に戻る。

The price of that bargain is a deliberate RTL-versus-netlist divergence, and it is the subject of Practice 9: feed the netlist a non-one-hot input and it produces a definite, plausible-looking, and completely meaningless code, where the RTL would have produced xxx and alerted you.這筆划算交易的代價，是刻意製造的 RTL 與網表分歧，而那正是練習 9 的主題：餵給網表一個非 one-hot 的輸入，它會產生一個確定的、看起來很合理、卻完全沒有意義的編碼，而 RTL 本來會產生 xxx 來警告你。この好取引の代価は、意図的に作る RTL とネットリストの乖離であり、それが演習 9 の主題である。ワンホットでない入力をネットリストに与えると、確定していてもっともらしく見え、まったく無意味なコードが出てくる。RTL なら xxx を出して警告してくれたはずのところである。

8.3 The 8:3 priority encoder, and the role of valid_data8.3 8:3 優先權編碼器，以及 valid_data 的角色8.3 8:3 プライオリティエンコーダと valid_data の役割

module priority (Data, Code, valid_data);
  input  [7:0] Data;
  output [2:0] Code;
  output       valid_data;
  reg    [2:0] Code;

  assign valid_data = |Data;    // reduction or

  always @ (Data)
    begin
      if      (Data[7]) Code = 7;
      else if (Data[6]) Code = 6;
      else if (Data[5]) Code = 5;
      else if (Data[4]) Code = 4;
      else if (Data[3]) Code = 3;
      else if (Data[2]) Code = 2;
      else if (Data[1]) Code = 1;
      else if (Data[0]) Code = 0;
      else              Code = 3'bx;
    end
endmodule

module priority (Data, Code, valid_data);
  input  [7:0] Data;
  output [2:0] Code;
  output       valid_data;
  reg    [2:0] Code;

  assign valid_data = |Data;

  always @ (Data)
    casex (Data)
      8'b1xxxxxxx : Code = 7;
      8'b01xxxxxx : Code = 6;
      8'b001xxxxx : Code = 5;
      8'b0001xxxx : Code = 4;
      8'b00001xxx : Code = 3;
      8'b000001xx : Code = 2;
      8'b0000001x : Code = 1;
      8'b00000001 : Code = 0;
      default     : Code = 3'bx;
    endcase
endmodule

Now the conditions overlap: several bits of Data can be high at once, and the specification is that the highest index wins. The if chain expresses that by ordering. The casex expresses it by patterns whose leading zeros encode "no higher bit is set" — note that the wildcard positions are below the leading one in each pattern, never above it. If you wrote 8'bxxxxxxx1 : Code = 0; as the first arm you would have a completely different (and wrong) priority order, because case arms are evaluated top to bottom and the first match wins.現在條件重疊了：Data 的好幾個位元可能同時為高，而規格是最高索引者勝。if 串用順序表達這件事。casex 則用樣式表達，每個樣式前導的零編碼了「沒有更高的位元被設起來」——注意萬用字元的位置在每個樣式中前導的那個 1 底下，絕不在它上面。如果你把 8'bxxxxxxx1 : Code = 0; 寫成第一個分支，你會得到一個完全不同（而且錯誤）的優先權順序，因為 case 的分支是由上往下求值，第一個匹配者勝。今度は条件が重なる。Data の複数ビットが同時に高になりうるのに、仕様は最上位の添字が勝つというものだ。if の連鎖はそれを順序で表現する。casex はパターンで表現し、各パターンの先頭の 0 が「より上のビットは立っていない」を符号化する。ワイルドカードの位置が各パターンの先頭の 1 の下にあり、決してその上にないことに注意したい。最初の枝に 8'bxxxxxxx1 : Code = 0; と書けば、まったく異なる（そして誤った）優先順位になる。case の枝は上から下へ評価され、最初に一致したものが勝つからである。

Unlike the plain encoder, these guard terms do not cancel, so real logic appears:與一般編碼器不同，這裡的守衛項不會被消掉，所以真的會出現邏輯：素のエンコーダと違い、ここではガード項が消えないので、実際に論理が現れる。

The structure is visible in the equations: each lower-priority term is gated by the complements of the higher-priority bits that would override it. That masking is why the slide's synthesis figure for the priority encoder is substantially larger than the one for the plain encoder — inverters and NOR gates appear where the plain version had only ORs.結構在方程式裡看得見：每一個較低優先權的項，都被那些會蓋過它的較高優先權位元的補數閘控。這層遮罩就是為什麼投影片給優先權編碼器的合成圖，比給一般編碼器的那張大得多——一般版本只有 OR 的地方，這裡出現了反相器與 NOR 閘。構造は方程式に見てとれる。優先度の低い項はどれも、それを上書きするより上位のビットの補数でゲートされている。このマスキングこそ、プライオリティエンコーダの合成図が素のエンコーダの図よりかなり大きい理由である。素の版では OR しかなかったところに、インバータと NOR ゲートが現れる。

The valid_data output is not decoration. A priority encoder with no inputs asserted has no meaningful code to report; the RTL says 3'bx and the netlist says something arbitrary. valid_data = |Data — the reduction OR, one bit saying "at least one request is present" — is the signal that lets the consumer distinguish "request from source 0" from "no request at all". This is the general pattern already mentioned in Section 2.2: when you are tempted to encode "unknown" in the data, add a valid bit instead. Every real arbiter, interrupt controller and leading-zero counter does this.valid_data 這個輸出不是裝飾品。一個沒有任何輸入被設起來的優先權編碼器，沒有任何有意義的編碼可回報；RTL 說 3'bx，網表說某個任意的東西。valid_data = |Data——歸約 OR，一個位元說「至少有一個請求存在」——就是讓消費端能分辨「來源 0 的請求」與「根本沒有請求」的那條訊號。這就是第 2.2 節已經提過的通用樣式：當你想把「未知」編碼進資料裡時，改成加一個 valid 位元。每一個真實的仲裁器、中斷控制器與前導零計數器都這麼做。valid_data という出力は飾りではない。入力が一つも立っていないプライオリティエンコーダには、報告すべき意味のあるコードがない。RTL は 3'bx と言い、ネットリストは何か任意のものを言う。valid_data = |Data、すなわち「要求が少なくとも一つある」ことを示す 1 ビットのリダクション OR こそ、受け手が「ソース 0 からの要求」と「要求がまったくない」を区別できるようにする信号である。これは第 2.2 節で既に触れた一般的なパターンである。「不明」をデータに符号化したくなったら、代わりに valid ビットを足すこと。現実のアービタ、割り込みコントローラ、先行ゼロカウンタはどれもそうしている。

8.4 casex, casez and the trouble with x in a pattern8.4 casex、casez，以及樣式裡出現 x 的麻煩8.4 casex・casez と、パターン中の x の厄介さ

Verilog gives three case flavours and the difference is in what counts as a match.Verilog 給了三種 case 口味，差別在於什麼算是匹配。Verilog は case を三種類用意しており、違いは何を一致とみなすかにある。

The asymmetry in the third column is the trap. Wildcarding is bidirectional: casex treats an x on either side as "don't care". So if a bit of Data is unknown in simulation — because a register came up uninitialised, or because a bus is momentarily floating — then casex (Data) will happily match the very first arm, and the priority encoder will report Code = 7 with complete confidence. The x that should have propagated and exposed the uninitialised register is swallowed instead. This is the classic "casex hides x-propagation bugs" problem, and it is the reason most modern coding standards ban casex outright.第三欄的不對稱就是陷阱。萬用匹配是雙向的：casex 把任一邊的 x 都當成「不在意」。所以如果模擬中 Data 的某個位元是未知的——因為某個暫存器上電時沒初始化，或因為某條匯流排暫時浮接——那麼 casex (Data) 會高高興興地匹配到第一個分支，而優先權編碼器會滿懷信心地回報 Code = 7。那個本該傳播出去、揭露未初始化暫存器的 x，反而被吞掉了。這就是經典的「casex 會藏起 x 傳播錯誤」問題，也是大多數現代寫碼規範乾脆禁用 casex 的理由。三列目の非対称さこそが落とし穴である。ワイルドカード照合は双方向で、casex はどちら側の x も「ドントケア」として扱う。だからシミュレーション中に Data のあるビットが不定なら——レジスタが未初期化で立ち上がった、あるいはバスが一時的に浮いている——casex (Data) は嬉々として最初の枝に一致し、プライオリティエンコーダは自信満々に Code = 7 と報告する。伝播して未初期化のレジスタを暴くはずだった x は、代わりに飲み込まれてしまう。これが古典的な「casex は x 伝播のバグを隠す」問題であり、現代のコーディング規約の大半が casex を端的に禁ずる理由である。

One more detail that catches people: wildcards in a case item are a synthesis-visible construct and are fine, but an x or z appearing in the selector is a simulation-only phenomenon. Synthesis reasons only over 0 and 1. So all of the behaviour described in this subsection is behaviour of your RTL simulation; the netlist is the same either way. That is precisely what makes it dangerous — the mismatch is in the direction that makes the RTL look healthier than the hardware.還有一個細節會絆倒人：case 項目裡的萬用字元是合成看得見的構件，沒有問題；但出現在選擇運算式裡的 x 或 z 純粹是模擬現象。合成只在 0 與 1 上推理。所以本小節描述的所有行為，都是你 RTL 模擬的行為；兩種寫法的網表都一樣。而這正是它危險的原因——這個不匹配的方向，剛好讓 RTL 看起來比硬體更健康。もう一つ、人をつまずかせる細部がある。case の項目側のワイルドカードは合成から見える構文であり問題ない。しかしセレクタ式に現れる x や z は純粋にシミュレーション上の現象である。合成は 0 と 1 の上でしか推論しない。したがって本小節で述べた振る舞いはすべて RTL シミュレーションの振る舞いであり、ネットリストはどちらでも同じである。そしてそれこそが危険な理由である。この不一致は、RTL をハードウェアより健康そうに見せる向きに働く。

8.5 The 3:8 decoder: the encoder run backwards8.5 3:8 解碼器：把編碼器倒過來跑8.5 3:8 デコーダ：エンコーダを逆に回す

module decoder (Code, Data);
  output [7:0] Data;
  input  [2:0] Code;
  reg    [7:0] Data;

  always @ (Code)
    begin
      if      (Code == 0) Data = 8'b00000001;
      else if (Code == 1) Data = 8'b00000010;
      else if (Code == 2) Data = 8'b00000100;
      else if (Code == 3) Data = 8'b00001000;
      else if (Code == 4) Data = 8'b00010000;
      else if (Code == 5) Data = 8'b00100000;
      else if (Code == 6) Data = 8'b01000000;
      else if (Code == 7) Data = 8'b10000000;
      else                Data = 8'bx;
    end
endmodule

  always @ (Code)
    case (Code)
      0 : Data = 8'b00000001;
      1 : Data = 8'b00000010;
      2 : Data = 8'b00000100;
      3 : Data = 8'b00001000;
      4 : Data = 8'b00010000;
      5 : Data = 8'b00100000;
      6 : Data = 8'b01000000;
      7 : Data = 8'b10000000;
      default: Data = 8'bx;
    endcase

Each output bit is a single minterm of the three code bits: $Data[i] = m_i(Code)$. Written out, $Data[0] = \overline{c_2}\,\overline{c_1}\,\overline{c_0}$, $Data[1] = \overline{c_2}\,\overline{c_1}c_0$, through to $Data[7] = c_2c_1c_0$. A naive implementation is eight three-input AND gates plus three inverters, about 15 GE.每一個輸出位元都是三個編碼位元的一個最小項：$Data[i] = m_i(Code)$。寫開來就是 $Data[0] = \overline{c_2}\,\overline{c_1}\,\overline{c_0}$、$Data[1] = \overline{c_2}\,\overline{c_1}c_0$，一直到 $Data[7] = c_2c_1c_0$。天真的實作是八個三輸入 AND 閘加三個反相器，約 15 GE。各出力ビットは 3 本のコードビットの一つの最小項である。$Data[i] = m_i(Code)$。書き下せば $Data[0] = \overline{c_2}\,\overline{c_1}\,\overline{c_0}$、$Data[1] = \overline{c_2}\,\overline{c_1}c_0$、…、$Data[7] = c_2c_1c_0$ となる。素朴な実装は 3 入力 AND ゲート 8 個とインバータ 3 個、約 15 GE である。

The slide's synthesis figure shows something smarter, and it is worth understanding because it is a pattern you will meet in every memory address decoder. The tool builds a two-stage pre-decode: first it forms the four combinations of the two low bits using two inverters and a pair of NAND/AND cells, then it combines each of those with $c_2$ or $\overline{c_2}$. Because static CMOS implements inverting functions natively, NOR and NAND cells appear where you expected AND and OR. The result in the figure is two inverters, two nand2, one and2, one more inverter, then a mixture of nor2, nor3 and and3 cells driving the eight outputs — fewer transistors and a shallower worst-case path than the flat version, and the four shared pre-decode terms are extracted exactly once. This is Section 3's extraction doing its job on a structure you would not have thought to factor by hand.投影片的合成圖顯示了更聰明的東西，值得理解，因為這是你在每一個記憶體位址解碼器裡都會遇到的樣式。工具建了一個兩階段預解碼：先用兩個反相器與一對 NAND／AND 元件形成低兩位的四個組合，再把其中每一個與 $c_2$ 或 $\overline{c_2}$ 結合。因為靜態 CMOS 原生實現的是反相函數，所以你預期是 AND 與 OR 的地方出現的是 NOR 與 NAND 元件。圖中的結果是兩個反相器、兩個 nand2、一個 and2、再一個反相器，然後是一組混用的 nor2、nor3 與 and3 元件驅動那八個輸出——電晶體比扁平版本少，最差路徑也更淺，而那四個共用的預解碼項恰好只被抽出一次。這就是第 3 節的抽出，在一個你不會想到要親手因式分解的結構上發揮作用。スライドの合成図はもっと賢いものを示しており、理解しておく価値がある。あらゆるメモリアドレスデコーダで出会うパターンだからだ。ツールは二段のプリデコードを組む。まずインバータ 2 個と NAND／AND のセル対で下位 2 ビットの四つの組合せを作り、次にそれぞれを $c_2$ または $\overline{c_2}$ と結合する。静的 CMOS は反転関数をそのまま実装するので、AND と OR を予想した場所に NOR と NAND のセルが現れる。図の結果はインバータ 2 個、nand2 2 個、and2 1 個、さらにインバータ 1 個、そして nor2・nor3・and3 を混ぜたセル群が八つの出力を駆動するというものである。平坦版よりトランジスタが少なく、最悪経路も浅く、共有される四つのプリデコード項はちょうど一度だけ抽出されている。これは第 3 節の抽出が、手では因数分解しようと思いつかない構造の上で働いている姿である。

The general lesson is that an $n$-to-$2^n$ decoder built as a tree of pre-decodes costs about $2^n$ small gates with $\log n$ levels, rather than $2^n$ wide gates with one level. For a 7-to-128 address decoder the difference is the whole design.一般性的教訓是：一個以預解碼樹建成的 $n$ 對 $2^n$ 解碼器，代價大約是 $2^n$ 個小閘、$\log n$ 層，而不是 $2^n$ 個寬閘、一層。對一個 7 對 128 的位址解碼器而言，這個差別就是整個設計。一般的な教訓はこうである。プリデコードのツリーとして組んだ $n$ 対 $2^n$ のデコーダは、1 段の幅広ゲート $2^n$ 個ではなく、$\log n$ 段の小さなゲート約 $2^n$ 個で済む。7 対 128 のアドレスデコーダでは、この違いが設計そのものを決める。

9. Tri-State Drivers and Bidirectional Buses9. 三態驅動器與雙向匯流排9. トライステートドライバと双方向バス

The lecture defines a bus as a structure used to transport multi-bit data and a buffer as a structure used to store or drive data with or without control signals, then lists four implementation concerns: tri-state buffers, bidirectional buses, bus loading, and tri-state outputs with don't cares. The first three are this section; the fourth is Section 10.本講把匯流排定義為用來傳輸多位元資料的結構，把緩衝器定義為用來儲存或驅動資料（有或沒有控制訊號）的結構，接著列出四個實作上的考量：三態緩衝器、雙向匯流排、匯流排負載，以及帶不在意項的三態輸出。前三個是本節的內容；第四個是第 10 節。講義はバスを多ビットのデータを運ぶための構造、バッファを制御信号の有無にかかわらずデータを蓄えたり駆動したりするための構造と定義し、続いて実装上の論点を四つ挙げる。トライステートバッファ、双方向バス、バスの負荷、そしてドントケアを伴うトライステート出力である。最初の三つが本節の内容で、四つ目は第 10 節である。

A tri-state driver is the one place in combinational design where the value z is not merely a simulation artefact but a request for specific hardware. A normal CMOS output stage always drives: either the pull-up network or the pull-down network conducts. A tri-state output stage adds an enable that turns both off, leaving the output node floating at high impedance so that some other driver may take the wire. This is a real cell in every library, usually named with a BUFT, TBUF or TRI stem, and it has its own timing arcs: a data-to-output delay as usual, plus enable-to-output ("turn on") and output-to-Z ("turn off") arcs.三態驅動器是組合邏輯設計中唯一一個地方，z 這個值不只是模擬的產物，而是對特定硬體的要求。一個正常的 CMOS 輸出級永遠在驅動：不是上拉網路導通，就是下拉網路導通。三態輸出級加上一個致能，把兩者都關掉，讓輸出節點浮接在高阻抗狀態，好讓別的驅動器接管這條導線。這在每一座元件庫裡都是一個真實存在的元件，通常以 BUFT、TBUF 或 TRI 為字根命名，而且它有自己的時序弧：照例有一條資料到輸出的延遲，再加上致能到輸出（「打開」）與輸出到 Z（「關閉」）兩條弧。トライステートドライバは、組合せ回路設計において z という値が単なるシミュレーションの産物ではなく、特定のハードウェアへの要求になる唯一の場所である。通常の CMOS 出力段は常に駆動している。プルアップ網かプルダウン網のどちらかが導通する。トライステート出力段はイネーブルを加えて両方を切り、出力ノードを高インピーダンスで浮かせ、別のドライバがその配線を取れるようにする。これはどのライブラリにも実在するセルで、ふつう BUFT、TBUF、TRI を語幹として名づけられ、独自のタイミングアークを持つ。通常のデータから出力への遅延に加え、イネーブルから出力への「オン」と、出力から Z への「オフ」のアークである。

9.1 The tri-state template9.1 三態範本9.1 トライステートのテンプレート

module stuff_to_bus1 (data_to_bus, bus_enabled, clk);
  input         bus_enabled, clk;
  output [31:0] data_to_bus;
  reg    [31:0] ckt_output_to_bus;

  assign data_to_bus = (bus_enabled) ? ckt_output_to_bus : 32'bz;
  // Description of the core circuit that drives ckt_output_to_bus goes here
endmodule

The template is exact and worth memorising: a conditional expression, driving a net, whose "false" branch is a vector of z of the right width. The front end recognises this shape and instantiates one tri-state driver per bit — thirty-two of them here — all sharing the enable.這個範本很精確，值得背下來：一個條件運算式，驅動一條 net，而它的「假」分支是一個寬度正確的 z 向量。前端辨識這個形狀，並為每一個位元實體化一個三態驅動器——這裡是三十二個——全都共用那個致能。テンプレートは厳密で、暗記する価値がある。条件式がネットを駆動し、その「偽」の枝が正しい幅の z のベクタであること。フロントエンドはこの形を認識し、ビットごとにトライステートドライバを一つ、ここでは 32 個、すべて同じイネーブルを共有する形でインスタンス化する。

Three details decide whether you get the cell you wanted:有三個細節決定你拿不拿得到想要的那個元件：望んだセルが得られるかどうかを決める細部が三つある。

• The target must be a net, driven by a continuous assignment. You can write the same conditional inside an always block with a reg target and most tools will still infer the driver, but the continuous-assignment form is universally supported and unambiguous.目標必須是一條 net，而且由連續賦值驅動。你也可以在一個 always 區塊裡對一個 reg 目標寫同樣的條件式，大多數工具仍然會推論出那個驅動器，但連續賦值的形式是普遍被支援而且沒有歧義的。対象はネットでなければならず、連続代入で駆動すること。同じ条件式を always ブロック内で reg を対象に書いても、たいていのツールはドライバを推論する。しかし連続代入の形は普遍的にサポートされ、曖昧さがない。
• The z branch must be the whole value, not part of one. 32'bz is thirty-two z bits. Writing 1'bz and relying on extension is a width bug waiting to happen; writing {16'bz, data[15:0]} asks for sixteen tri-state drivers and sixteen ordinary ones, which is legal but almost certainly not what you meant.z 分支必須是整個值，不能只是其中一部分。32'bz 是三十二個 z 位元。寫 1'bz 然後倚賴位元擴展，是一個等著發生的寬度錯誤；寫 {16'bz, data[15:0]} 則是要求十六個三態驅動器加十六個普通驅動器，合法，但幾乎可以確定不是你的本意。z の枝は値全体でなければならず、その一部であってはならない。32'bz は z が 32 ビットである。1'bz と書いて拡張に頼るのは、起きるのを待っている幅のバグである。{16'bz, data[15:0]} と書けば、トライステートドライバ 16 個とふつうのドライバ 16 個を要求することになる。合法だが、まず意図とは違う。
• Exactly one branch may be z. A conditional with z on both sides is a permanently disabled driver; the tool will optimise the entire cone away and tell you about it.只能有恰好一個分支是 z。兩邊都是 z 的條件式是一個永遠停用的驅動器；工具會把整個邏輯錐最佳化掉，並且告訴你。z の枝はちょうど一つだけ。両辺が z の条件式は恒久的に無効なドライバであり、ツールはコーン全体を最適化で消し去り、そのことを報告する。

Within a chip, tri-state buses have fallen out of favour and you should know why, since the lecture presents them neutrally. Internal tri-state nets have no defined value when no driver is enabled — the node floats, and a floating CMOS input dissipates crowbar current and may oscillate, so real designs need bus keepers (weak cross-coupled inverters) to hold the last value. They are hard to test, because ATPG must prove that exactly one driver is on for every pattern. They are hard to time, because the "turn off" arc of one driver and the "turn on" arc of the next must not overlap, which requires a non-overlap margin that eats into the cycle. And they are hard to debug, because a contention produces x in simulation and heat in silicon. The modern practice is to use tri-states only at chip I/O pads, where they are unavoidable, and to replace every internal bus with the multiplexer of Section 9.3.在晶片內部，三態匯流排已經不受青睞，而你應該知道為什麼，因為本講是中性地呈現它們的。內部三態網路在沒有任何驅動器被致能時沒有定義值——節點浮接，而一個浮接的 CMOS 輸入會消耗貫穿電流而且可能振盪，所以真實設計需要 bus keeper（弱交叉耦合反相器）來保住上一個值。它們難以測試，因為 ATPG 必須對每一個樣式證明恰好只有一個驅動器開著。它們難以做時序，因為前一個驅動器的「關閉」弧與下一個驅動器的「打開」弧不得重疊，那需要一段不重疊的餘裕，而那會吃掉週期。而且它們難以除錯，因為競爭在模擬中產生 x、在矽片上產生熱。現代的做法是只在晶片 I/O 焊墊上用三態（那裡避不掉），並把每一條內部匯流排換成第 9.3 節的多工器。チップ内部では、トライステートバスはすでに好まれない。講義は中立に紹介しているので、理由は知っておくべきである。内部のトライステートネットは、どのドライバも有効でないとき値が定義されない。ノードは浮き、浮いた CMOS 入力は貫通電流を消費し発振しうるので、実際の設計は直前の値を保持するバスキーパ（弱い交差結合インバータ）を必要とする。テストも難しい。ATPG はすべてのパターンについて、ちょうど一つのドライバだけがオンであることを証明せねばならない。タイミングも難しい。あるドライバの「オフ」のアークと次のドライバの「オン」のアークは重なってはならず、そのための非重複マージンがサイクルを食う。デバッグも難しい。競合はシミュレーションでは x を、シリコンでは熱を生む。現代の実務は、避けようのないチップ I/O パッドでのみトライステートを使い、内部バスはすべて第 9.3 節のマルチプレクサに置き換えることである。

9.2 Bidirectional buses and the inout port9.2 雙向匯流排與 inout 埠9.2 双方向バスと inout ポート

module stuff_to_bus2 (data_to_from_bus, clk, send_data, rcv_data);
  input         clk, send_data, rcv_data;
  inout  [31:0] data_to_from_bus;
  reg    [31:0] reg_to_bus;
  wire   [31:0] data_to_from_bus, inbound_data;

  assign inbound_data     = (rcv_data)  ? data_to_from_bus : 32'bz;
  assign data_to_from_bus = (send_data) ? reg_to_bus       : 32'bz;
  // Behaviour using inbound_data goes here
endmodule

An inout port is the Verilog model of a bidirectional pad. It is always a net, never a reg — note the explicit wire [31:0] data_to_from_bus; in the declaration list, which is redundant but harmless and makes the point. The module contains two drivers that share the pad: an outbound one gated by send_data, and an inbound path gated by rcv_data.inout 埠是雙向焊墊在 Verilog 裡的模型。它永遠是一條 net，絕不是 reg——注意宣告清單裡那句明寫的 wire [31:0] data_to_from_bus;，它是多餘的但無害，而且把重點講清楚了。這個模組裡有兩個共用這個焊墊的驅動器：一個由 send_data 閘控的對外驅動器，與一條由 rcv_data 閘控的對內路徑。inout ポートは双方向パッドの Verilog 上のモデルである。常にネットであり、決して reg ではない。宣言リストにある明示的な wire [31:0] data_to_from_bus; に注意したい。冗長だが無害で、要点をはっきりさせている。このモジュールにはパッドを共有するドライバが二つある。send_data でゲートされた外向きのものと、rcv_data でゲートされた内向きの経路である。

The inbound assignment deserves a second look, because at first sight it is odd: why gate the input with a tri-state rather than just reading the pad? The reason is modelling discipline. Making inbound_data go to z when rcv_data is low means that any logic which consumes it while the receiver is disabled will see z rather than stale bus traffic, and z propagating into arithmetic produces x, which shows up loudly in simulation. It is a deliberate "fail noisily" choice. In synthesis the inbound gate usually optimises away to a plain wire or a simple AND, because nothing downstream can use high impedance as an input.對內那個賦值值得再看一眼，因為乍看很奇怪：為什麼要用三態去閘控輸入，而不是直接讀那個焊墊？理由是建模紀律。讓 inbound_data 在 rcv_data 為低時變成 z，意味著任何在接收器停用期間消費它的邏輯會看到 z 而不是陳舊的匯流排資料，而 z 傳進算術運算會產生 x，那在模擬中會很大聲地現形。這是刻意的「吵著失敗」選擇。在合成中，對內的那個閘通常會被最佳化成一條單純的 wire 或一個簡單的 AND，因為下游沒有東西能把高阻抗當成輸入來用。内向きの代入はもう一度見る価値がある。一見すると奇妙だからだ。なぜパッドをそのまま読まず、入力をトライステートでゲートするのか。理由はモデリングの規律である。rcv_data が低のとき inbound_data を z にしておけば、受信器が無効な間にそれを消費する論理は、古いバスの内容ではなく z を見る。そして z が算術に伝播すれば x になり、シミュレーションで大きな音を立てて現れる。これは意図的な「派手に失敗する」選択である。合成では、内向きのゲートはたいてい単なる配線か単純な AND に最適化される。下流に高インピーダンスを入力として使えるものがないからだ。

The structural risk of inout is contention, and the Verilog gives you no protection against it. If send_data is high while a device at the other end of the board is also driving, the two drivers fight: in simulation the net resolver returns x on every bit where they disagree and the agreeing bits keep their value, while in silicon you have a direct path from supply to ground through two output stages, which is a current spike and, sustained, a reliability failure. The discipline is to make the enable conditions provably exclusive at the protocol level, and — in a real project — to add an assertion that fires if more than one driver is ever enabled.inout 的結構性風險是競爭，而 Verilog 完全不保護你。如果 send_data 為高，而板子另一端的某個裝置同時也在驅動，兩個驅動器就會打架：在模擬中，網路仲裁器會對每一個它們不一致的位元回傳 x，一致的位元則保住原值；而在矽片上，你會得到一條從電源直通地、穿過兩個輸出級的路徑，那是一道電流尖峰，若持續下去就是可靠度失效。紀律是：在協定層級讓致能條件可證明地互斥，而且——在真實專案裡——加上一條斷言，只要有超過一個驅動器被致能就觸發。inout の構造的リスクは競合であり、Verilog は何も守ってくれない。send_data が高のときにボードの反対側のデバイスも駆動していれば、二つのドライバは衝突する。シミュレーションではネットの解決器が、両者が食い違うビットごとに x を返し、一致するビットは値を保つ。シリコンでは電源から接地まで二つの出力段を貫く経路ができ、電流スパイクとなり、持続すれば信頼性の故障になる。規律は、イネーブル条件をプロトコルのレベルで証明可能に排他的にすること、そして実プロジェクトでは、二つ以上のドライバが有効になったら発火するアサーションを加えることである。

9.3 Bus loading, and the mux that replaces the bus9.3 匯流排負載，以及取代匯流排的那個多工器9.3 バスの負荷と、バスを置き換えるマルチプレクサ

module stuff_to_bus3 (data_to_from_bus, enab_a, enab_b, clk, rcv_data);
  input         enab_a, enab_b, rcv_data, clk;
  inout  [31:0] data_to_from_bus;
  reg    [31:0] reg_a_to_bus, reg_b_to_bus;

  assign data_to_from_bus = (enab_a) ? reg_a_to_bus :
                            (enab_b) ? reg_b_to_bus : 32'bz;
endmodule // not showing other logic

This is the single most useful idea in the section and the slide passes over it in one line. Compare it with the obvious alternative, two separate continuous assignments to the same net:這是本節最有用的單一想法，而投影片用一行就帶過去了。拿它跟顯而易見的替代方案比較：對同一條 net 做兩個分開的連續賦值：これは本節で最も有用な単一の着想だが、スライドは一行で通り過ぎる。明白な代替案、すなわち同じネットへの二つの別個の連続代入と比べてみよう。

assign data_to_from_bus =
         enab_a ? reg_a_to_bus : 32'bz;
assign data_to_from_bus =
         enab_b ? reg_b_to_bus : 32'bz;
// 64 tri-state cells, 2 loads on the net,
// and nothing stops both enables going high

assign data_to_from_bus =
         (enab_a) ? reg_a_to_bus :
         (enab_b) ? reg_b_to_bus : 32'bz;
// 32 mux cells + 32 tri-state cells,
// 1 load, contention impossible by construction

The nested form synthesises to a 2:1 multiplexer selected by enab_a, followed by a single tri-state driver whose enable is enab_a | enab_b — exactly the structure in the slide's figure, which shows a Mux block with a sel input tied to enab_a and an OR gate feeding the driver's control. Four consequences follow, and all of them are improvements:巢狀形式合成出一個由 enab_a 選擇的 2:1 多工器，後面接單一一個三態驅動器，其致能是 enab_a | enab_b——正是投影片圖中的結構，那張圖畫了一個 sel 輸入接到 enab_a 的 Mux 區塊，以及一個 OR 閘餵進驅動器的控制端。接著有四個後果，而且全都是改善：入れ子の形は、enab_a で選択される 2:1 マルチプレクサと、その後ろに置かれた単一のトライステートドライバ（イネーブルは enab_a | enab_b）に合成される。スライドの図の構造そのもので、そこには sel 入力を enab_a につないだ Mux ブロックと、ドライバの制御端子へ入る OR ゲートが描かれている。帰結が四つあり、どれも改善である。

• One load instead of two. Each driver attached to a bus contributes output capacitance even when disabled. Halving the driver count halves that parasitic, which directly improves the bus's transition time and the dynamic power spent charging it. This is what the slide's title "bus loading" refers to.一個負載而不是兩個。每一個掛在匯流排上的驅動器，即使停用也會貢獻輸出電容。把驅動器數目減半就把那個寄生電容減半，直接改善匯流排的轉態時間與為它充電所花的動態功耗。這就是投影片標題「bus loading」所指的事。負荷が二つから一つに。バスにつながるドライバは、無効のときでも出力容量を寄与する。ドライバ数を半分にすればその寄生容量も半分になり、バスの遷移時間と、それを充電するための動的電力が直接改善する。スライドの見出し「bus loading」が指しているのはこれである。
• Contention is structurally impossible. The nested conditional gives enab_a priority; if both are high, source A wins and source B is simply not selected. There is no combination of enables that produces two active drivers.競爭在結構上不可能發生。巢狀條件式給 enab_a 優先權；如果兩者都為高，來源 A 勝，來源 B 單純就是沒被選中。沒有任何致能組合能產生兩個作用中的驅動器。競合が構造的に起こりえない。入れ子の条件式は enab_a に優先権を与える。両方が高ならソース A が勝ち、ソース B は単に選ばれない。二つのドライバが同時に有効になるイネーブルの組合せは存在しない。
• The mux is cheaper than the second driver. A 2:1 mux is about 2.3 GE per bit; a tri-state driver is comparable or larger because it needs the enable logic in both the pull-up and pull-down stacks. You save area as well as risk.多工器比第二個驅動器便宜。一個 2:1 多工器每位元約 2.3 GE；一個三態驅動器相當或更大，因為它在上拉與下拉兩個堆疊裡都需要致能邏輯。你省下的是面積，也是風險。マルチプレクサは二つ目のドライバより安い。2:1 マルチプレクサは 1 ビットあたり約 2.3 GE、トライステートドライバは同等かそれ以上である。プルアップとプルダウンの両方のスタックにイネーブル論理が要るからだ。面積もリスクも同時に節約できる。
• It scales. Add a third source by adding one more nested conditional, which is one more mux level and no more drivers.它可以擴展。加入第三個來源只要再加一層巢狀條件式，那是多一層多工器，而驅動器一個也不用多。拡張できる。三つ目のソースを足すには入れ子の条件式を一段足せばよい。マルチプレクサが 1 段増えるだけで、ドライバは増えない。

Generalise this and you have the reason internal tri-state buses have disappeared from modern design: a multiplexer tree does everything a bus does, with defined values at all times, no floating nodes, no contention, full testability, and conventional timing arcs. The only place you genuinely need tri-states is at the chip boundary, where the wire is shared with devices you do not control.把這件事推廣，你就得到內部三態匯流排從現代設計中消失的理由：一棵多工器樹能做到匯流排能做的一切，而且在任何時刻都有定義值、沒有浮接節點、沒有競爭、完全可測試，而且有常規的時序弧。真正需要三態的地方只有晶片邊界，那裡的導線是與你控制不到的裝置共用的。これを一般化すれば、内部のトライステートバスが現代の設計から消えた理由になる。マルチプレクサのツリーはバスにできることをすべてこなし、しかも常に値が定義され、浮くノードがなく、競合がなく、完全にテスト可能で、ふつうのタイミングアークを持つ。本当にトライステートが要るのはチップの境界だけで、そこでは配線を自分の制御外のデバイスと共有しているからである。

assign data_to_from_bus = enab_a ? reg_a_to_bus : 32'bz;
assign data_to_from_bus = enab_b ? reg_b_to_bus : 32'bz;

10. Don't Cares as an Optimisation Resource10. 把不在意項當成最佳化資源10. 最適化資源としてのドントケア

10.1 The slide's experiment: alu_with_z1 versus alu_with_z210.1 投影片的實驗：alu_with_z1 對上 alu_with_z210.1 スライドの実験：alu_with_z1 対 alu_with_z2

The lecture ends its bus material with a controlled experiment, and it is the most quantitatively instructive page in the whole deck. Two modules are identical except for one literal in the default arm.本講以一個受控實驗結束匯流排的材料，那也是整份投影片中量化上最具教育意義的一頁。兩個模組除了 default 分支裡的一個字面值以外完全相同。講義はバスの話題を制御された実験で締めくくる。これはスライド全体で最も定量的に有益な一ページである。二つのモジュールは default の枝のリテラル一つを除いて完全に同一である。

module alu_with_z1 (alu_out, data_a, data_b, enable, opcode);
  input  [2:0] opcode;
  input  [3:0] data_a, data_b;
  input        enable;
  output       alu_out;           // scalar for illustration
  reg    [3:0] alu_reg;

  assign alu_out = (enable == 1) ? alu_reg : 4'bz;

  always @ (opcode or data_a or data_b)
    case (opcode)
      3'b001:  alu_reg = data_a | data_b;
      3'b010:  alu_reg = data_a ^ data_b;
      3'b110:  alu_reg = ~data_b;
      default: alu_reg = 4'b0;    // alu_with_z2 writes 4'bx here instead
    endcase
endmodule

Both versions are latch-free: the case is complete in both. Both have a tri-state output, because the conditional's false branch is 4'bz. The only difference is what the five unlisted opcodes produce.兩個版本都沒有鎖存器：兩者的 case 都是完整的。兩者都有三態輸出，因為條件式的假分支是 4'bz。唯一的差別是那五個沒列出的 opcode 會產生什麼。どちらの版もラッチを持たない。case はどちらも完全である。どちらもトライステート出力を持つ。条件式の偽の枝が 4'bz だからだ。唯一の違いは、列挙されていない五つの opcode が何を生むかである。

In alu_with_z1 they produce zero. That is a requirement, and the optimiser must meet it. It needs logic that detects "opcode is not one of 001, 010, 110" and forces the output to zero, which means the opcode decode must be built in full and an extra selection stage added. The slide's figure (a) shows the result: an inverter, three NAND/NOR cells computing the data functions, two multiplexers, a NAND and an inverter driving alu_out.在 alu_with_z1 裡它們產生零。那是一個要求，最佳化器必須達成。它需要能偵測「opcode 不是 001、010、110 其中之一」並把輸出強制為零的邏輯，也就是說 opcode 解碼必須完整建出來，再加上一級額外的選擇。投影片的圖 (a) 顯示的結果是：一個反相器、三個算出資料函數的 NAND／NOR 元件、兩個多工器，以及一個 NAND 加一個反相器驅動 alu_out。alu_with_z1 ではそれらがゼロを出す。これは要求であり、最適化器は満たさねばならない。「opcode が 001、010、110 のいずれでもない」ことを検出して出力をゼロに強制する論理が要る。つまり opcode のデコードを完全に作り、さらに選択段を一つ追加することになる。スライドの図 (a) が示す結果は、インバータ 1 個、データ関数を計算する NAND／NOR セル 3 個、二つのマルチプレクサ、そして alu_out を駆動する NAND 1 個とインバータ 1 個である。

In alu_with_z2 they produce x. That is a permission. The optimiser may output whatever is cheapest for those five opcodes, and it exploits this to merge them into whichever listed branch costs least to extend. The slide's figure (b) shows the result: one AND, one inverter, one NOR, one multiplexer, and the output inverter — captioned "with don't cares". Perhaps 40 % less logic for the price of one character in the source.在 alu_with_z2 裡它們產生 x。那是一個許可。最佳化器可以對那五個 opcode 輸出任何最便宜的東西，而它利用這一點，把它們併進最便宜擴張的那個已列分支裡。投影片的圖 (b) 顯示的結果是：一個 AND、一個反相器、一個 NOR、一個多工器，以及輸出的反相器——圖說寫著「with don't cares」。用原始碼裡一個字元的代價，換來大概少 40 % 的邏輯。alu_with_z2 ではそれらが x を出す。これは許可である。最適化器はその五つの opcode に対し最も安いものを何でも出してよく、その自由を使って、拡張するのが最も安く済む既出の枝へそれらを併合する。スライドの図 (b) が示す結果は、AND 1 個、インバータ 1 個、NOR 1 個、一つのマルチプレクサ、そして出力のインバータである。キャプションには「with don't cares」とある。ソースのたった一文字の代価で、論理がおよそ 40 % 減る。

10.2 Why don't cares are the cheapest optimisation you will ever apply — and the riskiest10.2 為什麼不在意項是你用過最便宜的最佳化 —— 也是風險最高的10.2 ドントケアが最も安い最適化であり、同時に最も危険である理由

The mechanism is worth understanding because it generalises far beyond this example. A Boolean function with $k$ don't-care minterms is not one function but a family of $2^k$ functions, all of which satisfy the specification. The optimiser is free to pick any member of the family, and it picks the one with the lowest cost. Every don't-care you declare doubles the search space and can only ever reduce the cost, never increase it. That is why the same trick produced the ten-to-one area reduction in the plain 8:3 encoder of Section 8.2: declaring 248 of 256 input patterns as don't-cares left the optimiser with so much freedom that the equality comparators dissolved into three OR gates.這個機制值得理解，因為它的適用範圍遠遠超出這個例子。一個有 $k$ 個不在意最小項的布林函數不是一個函數，而是一族 $2^k$ 個函數，它們全都滿足規格。最佳化器可以自由挑這一族裡的任何一個，而它挑成本最低的那個。你每宣告一個不在意項，搜尋空間就加倍一次，而且只可能降低成本，絕不可能提高。這就是為什麼同樣的手法在第 8.2 節一般 8:3 編碼器上造成了十比一的面積縮減：把 256 個輸入樣式中的 248 個宣告成不在意項，留給最佳化器的自由度大到那些相等比較器直接溶解成三個 OR 閘。この機構は理解する価値がある。この例をはるかに超えて一般化するからだ。$k$ 個のドントケア最小項を持つブール関数は一つの関数ではなく、仕様を満たす $2^k$ 個の関数からなる族である。最適化器はその族の任意の一つを自由に選べ、最も費用の低いものを選ぶ。ドントケアを一つ宣言するたびに探索空間は倍になり、費用は下がることはあっても上がることは決してない。第 8.2 節の素の 8:3 エンコーダで同じ手口が 10 対 1 の面積削減をもたらした理由がこれである。256 個の入力パターンのうち 248 個をドントケアと宣言したことで、最適化器に与えられた自由度が大きすぎて、等価比較器が OR ゲート三つに溶けてしまったのだ。

The risk is equally mechanical. You have told the tool "I promise these inputs never occur." If the promise is false, two things go wrong at once. The hardware produces a value you did not choose and cannot predict from the source; and your RTL simulation produces x, so the two disagree — which means the mismatch will not be caught by the gate-level regression of Section 1.2 unless your stimulus happens to drive the forbidden input.風險同樣是機械式的。你已經告訴工具「我保證這些輸入永遠不會出現」。如果這個保證是假的，有兩件事會同時出錯。硬體產生一個不是你挑的、也無法從原始碼預測的值；而你的 RTL 模擬產生 x，所以兩邊不一致——這意味著除非你的激勵剛好驅動那個被禁止的輸入，否則第 1.2 節的閘級回歸測試抓不到這個不匹配。リスクも同じく機械的である。あなたはツールに「これらの入力は決して現れないと約束する」と告げた。その約束が偽なら、二つのことが同時に狂う。ハードウェアは、自分が選んだのでもソースから予測できるのでもない値を出す。そして RTL シミュレーションは x を出すので両者は食い違う。つまり、刺激がたまたまその禁じた入力を与えない限り、第 1.2 節のゲートレベル・リグレッションはこの不一致を捕まえない。

One further subtlety that the slides do not mention. Assigning 'bx and asserting the full_case pragma (Section 6.5) produce the same netlist, because both tell the optimiser the same thing. They differ entirely in what the simulator sees. With 'bx the simulator also produces x, so the RTL warns you loudly at the first forbidden input. With full_case the simulator holds the previous value and says nothing. Given identical hardware and strictly better observability, default: y = 'bx; dominates full_case in every respect — which is the whole argument for the pragma's obsolescence.還有一個投影片沒提到的微妙之處。賦值 'bx 與宣告 full_case pragma（第 6.5 節）會產生相同的網表，因為兩者告訴最佳化器的是同一件事。它們完全不同的地方在於模擬器看到什麼。用 'bx，模擬器同樣產生 x，所以在第一個被禁止的輸入出現時 RTL 就大聲警告你。用 full_case，模擬器保住前一個值而且什麼也不說。既然硬體一模一樣而可觀測性嚴格更好，default: y = 'bx; 在每一方面都壓過 full_case——這就是那個 pragma 該被淘汰的全部論據。スライドが触れていない微妙な点をもう一つ。'bx の代入と full_case プラグマの宣言（第 6.5 節）は同じネットリストを生む。最適化器に同じことを伝えるからだ。まったく違うのはシミュレータに何が見えるかである。'bx ならシミュレータも x を出すので、最初の禁じられた入力で RTL が大声で警告する。full_case ならシミュレータは前の値を保持し、何も言わない。ハードウェアが同一で可観測性は厳密に良いのだから、default: y = 'bx; はあらゆる点で full_case を上回る。これがプラグマが廃れるべき論拠のすべてである。

always @* case (sel)
  4'b0001: y = w;
  4'b0010: y = x;
  4'b0100: y = v;
  4'b1000: y = u;
  default: y = ???;
endcase

11. Resource Sharing and the Area/Speed Trade-off11. 資源共用與面積／速度的取捨11. リソース共有と面積・速度のトレードオフ

The last slide of the lecture carries an instruction in italics: before RTL coding, do the resource sharing first — it can make the hardware own the low-cost property. The wording is awkward but the advice is sound and it is worth taking seriously, because resource sharing is the one optimisation in this lecture that you must perform yourself. Latch avoidance is a coding rule; minimisation is the tool's job; mux-versus-priority follows automatically from your conditions. Operator sharing, by contrast, depends on an architectural judgement that the tool can make only in narrow circumstances.本講最後一張投影片帶著一句斜體的指示：before RTL coding, do the resource sharing first — it can make the hardware own the low-cost property。措辭有點彆扭，但建議是對的，值得認真看待，因為資源共用是本講唯一一個你必須親自動手的最佳化。避免鎖存器是一條寫碼規則；最小化是工具的工作；多工器對優先權鏈會從你的條件自動跟著走。相對地，運算子共用取決於一個架構判斷，而工具只在很窄的情況下才做得出這個判斷。講義の最後のスライドにはイタリックの指示が添えられている。before RTL coding, do the resource sharing first — it can make the hardware own the low-cost property。言い回しはぎこちないが助言は妥当で、真面目に受け取る価値がある。リソース共有は本講義で唯一、自分の手で行わねばならない最適化だからだ。ラッチの回避はコーディング規則であり、最小化はツールの仕事であり、マルチプレクサか優先順位かは条件から自動的に決まる。これに対し演算子の共有はアーキテクチャ上の判断に依存し、ツールがその判断を下せるのは限られた状況だけである。

11.1 One adder instead of two11.1 用一個加法器取代兩個11.1 加算器を二つから一つへ

module res_share (y_out, sel, data_a, data_b, accum);
  input  [3:0] data_a, data_b, accum;
  input        sel;
  output [4:0] y_out;

  // Before: two adders and a 5-bit output mux
  // assign y_out = sel ? (data_a + accum) : (data_a + data_b);

  // After: one 4-bit input mux and one adder
  assign y_out = data_a + (sel ? accum : data_b);
endmodule

The transformation is nothing more than factoring applied to arithmetic rather than to Boolean algebra. Both branches add data_a; only the second operand differs. Pull the common operand out of the conditional and the choice moves to the input side, where it selects between two 4-bit values instead of between two 5-bit sums. The slide's note is blunt and correct: only 1 adder, instead of 2 adders.這個轉換不過就是把因式分解用在算術上，而不是用在布林代數上。兩個分支都加 data_a；只有第二個運算元不同。把共同的運算元從條件式裡提出來，選擇就移到輸入端，在那裡它是在兩個 4 位元值之間選，而不是在兩個 5 位元的和之間選。投影片的註記直白而正確：only 1 adder, instead of 2 adders。この変換は、因数分解をブール代数ではなく算術に適用しただけのものである。どちらの枝も data_a を加えており、違うのは第二のオペランドだけである。共通のオペランドを条件式から外へ出せば、選択は入力側へ移り、5 ビットの和二つの間ではなく 4 ビットの値二つの間で選ぶことになる。スライドの注記はそっけなく、そして正しい。only 1 adder, instead of 2 adders。

11.2 Doing the arithmetic honestly11.2 誠實地算一算11.2 正直に計算する

Hand-waving about "saving an adder" is not enough; you need to be able to decide a sharing question with numbers. Use these per-bit figures, which are representative of a mature standard-cell library at any node:光是揮手說「省下一個加法器」不夠；你得有能力用數字去決定一個共用問題。請用以下這些每位元的數據，它們足以代表任何製程節點上一座成熟的標準元件庫：「加算器が一つ減る」と手を振るだけでは足りない。共有の是非を数値で決められなければならない。以下のビットあたりの数値を使うとよい。どのプロセスノードでも成熟した標準セルライブラリを代表する値である。

That last point generalises into the only honest summary of the trade-off: sharing moves the multiplexer from after the operator to before it. Everything else follows. Area improves whenever the operator is bigger than the extra muxing. Delay improves if the select signal arrives early and worsens if it arrives late, because a mux in front of an operator serialises with it while a mux behind it does not.最後這一點可以推廣成對這個取捨唯一誠實的總結：共用是把多工器從運算子之後搬到運算子之前。其餘一切都從這裡跟著走。只要運算子比多出來的多工代價大，面積就改善。延遲則在選擇訊號來得早時改善、來得晚時變差，因為放在運算子前面的多工器會與它串接，放在後面的則不會。この最後の点は、このトレードオフの唯一正直な要約へと一般化できる。共有とはマルチプレクサを演算子の後ろから前へ移すことである。他はすべてそこから従う。演算子が追加のマルチプレクサより大きければ面積は改善する。遅延は、選択信号が早く届けば改善し、遅く届けば悪化する。演算子の前に置かれたマルチプレクサはそれと直列になるが、後ろに置かれたものはならないからだ。

Read the inequality and two regimes fall out. If the operator is width-preserving — an adder, a subtractor, a shifter, an ALU, where $W_{\text{out}} \approx W_{\text{in}}$ or where one operand is shared so $W_{\text{in}}$ is small — the right-hand side is near zero or negative and sharing essentially always wins on area. If the operator is compressing — an equality comparator, a reduction, a priority encoder, anything that turns many bits into few — then $W_{\text{in}} \gg W_{\text{out}}$, the right-hand side is large, and sharing can easily cost more than it saves. That asymmetry is the single most useful thing to carry away from this section, and Practice 14 makes it concrete.讀這個不等式，兩種情況就掉出來。如果運算子是保寬的——加法器、減法器、移位器、ALU，那些 $W_{\text{out}} \approx W_{\text{in}}$ 的，或是有一個運算元被共用因而 $W_{\text{in}}$ 很小的——那麼右邊接近零或為負，共用在面積上基本上永遠贏。如果運算子是壓縮型的——相等比較器、歸約、優先權編碼器，任何把很多位元變成很少位元的東西——那麼 $W_{\text{in}} \gg W_{\text{out}}$，右邊很大，共用很容易賠得比省得多。那個不對稱是本節最值得帶走的一件事，而練習 14 會把它具體化。この不等式を読むと二つの領域が現れる。演算子が幅を保つもの——加算器、減算器、シフタ、ALU のように $W_{\text{out}} \approx W_{\text{in}}$ であるもの、あるいは片方のオペランドが共通で $W_{\text{in}}$ が小さいもの——なら右辺はほぼゼロか負になり、面積の面では共有がほぼ常に勝つ。演算子が圧縮型——等価比較器、リダクション、プライオリティエンコーダなど、多くのビットを少数のビットに変えるもの——なら $W_{\text{in}} \gg W_{\text{out}}$ となって右辺は大きく、共有は節約以上に損をしやすい。この非対称性こそ本節から持ち帰るべき最も有用なことであり、演習 14 がそれを具体化する。

11.3 When sharing is wrong11.3 什麼時候共用是錯的11.3 共有が誤りになるとき

Four situations where the italic advice on the slide should be ignored.有四種情況，投影片上那句斜體建議應該被忽略。スライドのイタリックの助言を無視すべき状況が四つある。

When the operations are not mutually exclusive. This is the hard precondition and it is easy to forget. Sharing works because only one of the two results is needed at a time; the multiplexer encodes that choice. If your design needs a+b and c+d in the same cycle, there is nothing to share, and writing the expression as though there were simply produces a wrong answer. In a multi-cycle design you can create the exclusivity deliberately — schedule the two additions into different cycles and share the adder across them — but that is a datapath-plus-controller restructuring, not an expression rewrite, and it belongs to Lecture 8's design-example material.當那些運算不互斥時。這是硬性前提，而且很容易忘記。共用之所以成立，是因為一次只需要兩個結果中的一個；多工器編碼的就是那個選擇。如果你的設計在同一個週期裡同時需要 a+b 與 c+d，那就沒有東西可以共用，而把運算式寫成好像可以共用的樣子，只會產生錯誤答案。在多週期設計裡你可以刻意製造出互斥性——把兩個加法排程到不同週期，並讓它們共用一個加法器——但那是資料路徑加控制器的重構，不是運算式改寫，而且它屬於第 8 講的設計範例材料。演算が互いに排他的でないとき。これは厳格な前提条件であり、忘れやすい。共有が成り立つのは、一度に必要なのが二つの結果のうち一方だけだからである。マルチプレクサはその選択を符号化している。同じサイクルで a+b と c+d の両方が必要な設計なら共有できるものはなく、できるかのように式を書けば誤った答えを生むだけである。マルチサイクルの設計なら排他性を意図的に作り出せる。二つの加算を別々のサイクルにスケジュールし、加算器を跨いで共有すればよい。だがそれはデータパスと制御器の再構成であって式の書き換えではなく、第 8 講の設計例の題材に属する。

When the select arrives late. As the costing above shows, sharing puts the mux on the critical path ahead of the operator. If sel is the output of a comparator that is itself slow, the shared version can lose several hundred picoseconds, which on a tight clock is the whole margin. The usual fix is to compute the select one cycle early and register it, which restores the sharing win.當選擇訊號來得晚時。如上面的成本計算所示，共用把多工器放到運算子前面的關鍵路徑上。如果 sel 是某個本身就很慢的比較器的輸出，共用版本可能損失好幾百皮秒，而在一個緊的時脈下那就是全部的餘裕。常見的修法是提早一個週期算出選擇訊號並把它暫存起來，這樣就把共用的好處救回來了。選択信号が遅く届くとき。上のコスト計算が示したとおり、共有はマルチプレクサを演算子の手前のクリティカルパス上に置く。sel がそれ自体遅い比較器の出力なら、共有版は数百ピコ秒を失いかねず、厳しいクロックではそれが全マージンである。よくある対処は、選択信号を 1 サイクル早く計算してレジスタに入れることで、こうすれば共有の利点が戻る。

When one branch would have optimised to something much cheaper. Consider y = sel ? (a + b) : (a + 1). Unshared, the tool builds one full adder and one incrementer, and an incrementer is roughly a third of the cost of an adder because one operand is a constant and most of the carry logic folds away. Share it as y = a + (sel ? b : 1) and the constant is gone — the second operand is now a variable, so you must build a full adder. You saved an incrementer and paid for a mux plus the upgrade from incrementer to adder. Constant folding is a bigger lever than sharing, and sharing can destroy it.當其中一個分支本來會被最佳化成便宜得多的東西時。考慮 y = sel ? (a + b) : (a + 1)。不共用時，工具建出一個完整的加法器與一個遞增器，而遞增器大約只有加法器三分之一的成本，因為它有一個運算元是常數，大部分進位邏輯會摺疊掉。把它共用成 y = a + (sel ? b : 1)，常數就消失了——第二個運算元現在是變數，所以你必須建一個完整的加法器。你省下一個遞增器，卻付了一個多工器外加「從遞增器升級成加法器」的差價。常數摺疊是比共用更大的槓桿，而共用可能把它毀掉。片方の枝が本来ずっと安いものに最適化されたはずのとき。y = sel ? (a + b) : (a + 1) を考えよう。共有しなければ、ツールは完全な加算器一つとインクリメンタ一つを作る。インクリメンタは片方のオペランドが定数でキャリー論理の大半が畳み込まれるため、加算器のおよそ三分の一の費用で済む。これを y = a + (sel ? b : 1) として共有すると定数が消える。第二オペランドが変数になるので完全な加算器を作らねばならない。インクリメンタ一つを節約した代わりに、マルチプレクサ一つと、インクリメンタから加算器への格上げ分を払ったことになる。定数畳み込みは共有より大きな梃子であり、共有はそれを壊しうる。

When it costs power rather than saving it. Two dedicated adders, each fed by operands that change only when their branch is active, toggle half as often as one shared adder whose inputs change on every select flip. Shared logic concentrates switching activity. Where leakage dominates, sharing wins; where dynamic power dominates and the operands are wide, two quiet units can beat one busy one. Modern flows mitigate this with operand isolation — gating the unused operator's inputs so it stops toggling — which, interestingly, is sharing's opposite: it keeps two units and makes them quiet.當它花掉功耗而不是省下功耗時。兩個專用的加法器，各自由只在自己分支作用時才變動的運算元餵入，其切換次數只有一個共用加法器的一半，因為後者的輸入在每次選擇線翻轉時都會變。共用的邏輯會把切換活動集中起來。在漏電主導的場合共用贏；在動態功耗主導而運算元又很寬的場合，兩個安靜的單元可能勝過一個忙碌的單元。現代流程用運算元隔離（operand isolation）來緩解這件事——把沒在用的運算子輸入閘控住，讓它停止切換——有趣的是，那正是共用的反面：它保留兩個單元，並讓它們安靜。電力を節約するどころか消費するとき。専用の加算器を二つ置き、それぞれ自分の枝が有効なときだけ変化するオペランドを与えれば、トグル回数は共有加算器の半分で済む。共有加算器の入力は選択が反転するたびに変わるからだ。共有された論理はスイッチング活性を一点に集中させる。リークが支配的なら共有が勝ち、動的電力が支配的でオペランドが幅広なら、静かな二つのユニットが忙しい一つのユニットに勝ちうる。現代のフローはオペランド分離でこれを緩和する。使っていない演算子の入力をゲートしてトグルを止めるのだ。興味深いことに、これは共有の正反対である。ユニットを二つ保ったまま、静かにさせるのだから。

11.4 What the tool will do for you, and what it will not11.4 工具會替你做什麼，不會做什麼11.4 ツールがやってくれること、くれないこと

Modern synthesisers do perform automatic resource sharing, within limits, and knowing those limits tells you where your own effort is needed.現代合成器確實會在一定限度內執行自動資源共用，而知道那些限度在哪裡，就知道你自己的力氣該花在哪裡。現代の合成器は一定の範囲で自動的なリソース共有を行う。その範囲を知れば、自分の労力をどこに割くべきかが分かる。

They will share arithmetic operators that appear in different arms of the same conditional expression or case statement, because mutual exclusivity is then syntactically evident. Design Compiler's datapath extraction will rewrite sel ? (a+b) : (a+c) into the shared form without being asked. They will also merge operators across an if/else inside one always block, for the same reason.它們會共用出現在同一個條件運算式或 case 敘述不同分支裡的算術運算子，因為此時互斥性在語法上就看得出來。Design Compiler 的資料路徑抽取會自動把 sel ? (a+b) : (a+c) 改寫成共用形式，不用你開口。基於同樣的理由，它們也會跨越單一 always 區塊內的 if/else 合併運算子。同一の条件式や case 文の別々の枝に現れる算術演算子は共有してくれる。その場合、排他性が構文上すぐ分かるからだ。Design Compiler のデータパス抽出は、頼まなくても sel ? (a+b) : (a+c) を共有形に書き換える。同じ理由で、一つの always ブロック内の if/else をまたいだ演算子の併合も行う。

They will not share across module boundaries unless you enable cross-boundary optimisation, and even then only tentatively. They will not share across clock cycles — that requires a controller and a state register, which is an architectural decision no synthesiser will make. They will not share when the exclusivity is a property of your protocol rather than of your code: if two adders are in different always blocks and you happen to know that only one is ever used per cycle, the tool cannot know it and will build both.它們不會跨模組邊界共用，除非你啟用跨邊界最佳化，而且即使啟用了也只會很保守地做。它們不會跨時脈週期共用——那需要一個控制器與一個狀態暫存器，那是任何合成器都不會做的架構決策。當互斥性是你協定的性質而不是你程式碼的性質時，它們也不會共用：如果兩個加法器在不同的 always 區塊裡，而你剛好知道每個週期只會用到其中一個，工具無從得知，它會把兩個都建出來。モジュール境界を越えた共有はしてくれない。境界越えの最適化を有効にした場合でも、やるのは控えめである。クロックサイクルをまたいだ共有もしない。それには制御器と状態レジスタが要り、どの合成器も下さないアーキテクチャ上の判断だからである。排他性がコードの性質ではなくプロトコルの性質である場合も共有しない。二つの加算器が別々の always ブロックにあり、各サイクルで使われるのは一方だけだとあなたが知っていても、ツールには知る術がなく、両方を作る。

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

12.1 The exam checklist12.1 考前檢查表12.1 試験前チェックリスト

always @*                       // complete sensitivity, compiler-built
  begin
    y     = DEFAULT_Y;          // every variable gets a value before any branch
    valid = 1'b0;
    case (sel)
      ...                       // each arm states only what differs
      default: ;                // present even when unreachable
    endcase
  end

12.2 Where this lecture sits in the course12.2 這一講在課程中的位置12.2 本講義が科目全体のどこに位置するか

Lecture 5 is the hinge of the course: everything before it is about describing and simulating, everything after it is about building. It is worth being explicit about the connections, because several of the rules here only make full sense once you have seen what comes next.第 5 講是整門課的樞紐：它之前的一切都在講描述與模擬，它之後的一切都在講建造。把這些連結明白講出來是值得的，因為這裡好幾條規則，要等你看過後面的內容才完全說得通。第 5 講は科目全体の蝶番である。これより前はすべて記述とシミュレーションの話で、これより後はすべて作ることの話になる。ここにある規則のいくつかは後続の内容を見て初めて完全に腑に落ちるので、そのつながりを明示しておく価値がある。