寫了這么多年RTL帶過不少剛入門的同學我發(fā)現(xiàn)關于 wire 和 reg 這個問題的出現(xiàn)頻率高得有點離譜。幾乎每隔一陣子就有人在群里問一遍“這個信號到底該定義成 reg 還是 wire”面試的時候十個人里也有七八個會在這上面被繞進去。今天干脆把這件事徹底講透從硬件本質、仿真模型、綜合行為到真實工程里的選擇習慣一次性掰開揉碎。先給一句話結論wire 描述的是“物理連線”或“組合邏輯的連續(xù)驅動”reg 描述的是“always 塊內部的過程賦值目標”兩者在仿真模型里的角色完全不同但綜合出來的硬件未必是你想的那樣。至于“什么時候用哪個”說到底就一條最實用的判斷準則你先想清楚要用 assign 連續(xù)賦值還是要用 always 過程賦值前者聲明成 wire后者聲明成 reg。1. 先搞懂本質wire 是“線”reg 是“變量”很多初學者在學 Verilog 的時候腦子里的第一反應是“wire 就是導線reg 就是寄存器。”這個說法在八成的情況下能對付作業(yè)但一旦接觸到真實工程會翻車翻得很難看。原因在于這個說法混淆了仿真層面的數(shù)據(jù)類型和綜合后的硬件邏輯這兩件事不是一回事。1.1 從硬件視角看 wire它就是一根物理連線wire 這個詞的本意就是“導線”在語言標準里屬于net type網(wǎng)絡類型。網(wǎng)絡類型描述的是一個信號值由某個驅動源持續(xù)驅動的連接關系它本身不存儲任何狀態(tài)。你把一個 wire 想成一塊電路板上的一截銅線就行了當前時刻這根線上是什么電平完全取決于現(xiàn)在誰在驅動它。在 RTL 設計里wire 最典型的出現(xiàn)位置有幾個模塊與模塊之間的端口連接。assign 連續(xù)賦值的左側。頂層文件里把子模塊輸出接到另一個子模塊輸入的中間信號。你寫assign led cnt[3];的時候左側的 led 就必須是 wire。這句話翻譯成硬件行為是把計數(shù)器第 3 位這根線的電平直接連到 led 引腳上。它不是某一時刻賦值一次而是每一時刻都被持續(xù)驅動這也是連續(xù)賦值這四個字的含義。還有個容易忽略的小細節(jié)wire 這類網(wǎng)絡類型的默認值是高阻態(tài) z。在仿真里如果一個 wire 沒有被任何驅動源驅動它讀出來是 z 而不是 0。這個特性在某些總線模擬場景下很關鍵。1.2 從硬件視角看 reg它是一種“會記住”的存儲行為reg 在語言標準里屬于variable type變量類型。它描述的是一個過程賦值procedural assignment的目標也就是說它的值是在 always、initial、task、function 這些過程塊內部通過賦值語句在某一時刻被更新然后保持這個值直到下一次被更新。你寫always (posedge clk) begin cnt cnt 1b1; end這里的 cnt 必須聲明成 reg。如果把電路行為翻譯成自然語言時鐘上升沿來的時候把 cnt 更新成新值其他時間它保持不動。這種保持的行為天然適合用變量類型去建模。所以從仿真模型上看reg 更像程序語言里的變量它是內存里的一個值可以被賦值可以保持可以在被賦值之前讀取雖然這樣會讀到未知態(tài) x。1.3 最容易踩的坑reg 并不等于硬件寄存器這是整個問題里最經(jīng)典的認知偏差。很多人以為 reg 類型綜合出來就一定是觸發(fā)器wire 綜合出來就一定是連線這個想法錯得非常徹底。reg 只是一個仿真語義層面的變量類型。一個 reg 信號綜合出來到底變成什么硬件完全取決于你對它做了什么。always (posedge clk)塊里賦值的 reg綜合成 D 觸發(fā)器。always (*)塊里賦值的 reg如果賦值完整綜合成純組合邏輯。always (*)塊里賦值不完整綜合成鎖存器latch。在initial塊里使用的 reg只在仿真里存在綜合時往往被直接優(yōu)化掉。我用一個更直白的例子幫你建立感覺。下面這段代碼reg result; always (*) begin if (sel) result a b; else result a - b; endresult 聲明的是 reg但它綜合出來是純組合邏輯實現(xiàn)的是一個二選一的加減法器沒有時鐘、沒有觸發(fā)器。因為 always 塊是 level sensitive電平敏感的且在 if 和 else 兩個分支里都賦值了信號每個時刻都是被驅動的所以不需要存儲。反過來看如果你寫wire out; assign out din_reg;out 是 wire但它接的實際連過去的是寄存器輸出。綜合后硬件上out 可能就是某個觸發(fā)器輸出引腳連出來的一小段金屬線。所以別再背reg 就是寄存器這種簡化口訣了。reg 描述的是賦值方式不是硬件結構。2. 什么時候用 wire核心場景拆解講完本質現(xiàn)在落實到具體工程里到底怎么選。一個信號聲明成 wire就意味著這個信號會出現(xiàn)在 assign 語句左側、模塊實例化的輸出端口、或者連續(xù)賦值產(chǎn)生的表達式中。2.1 結構建模與端口連接wire 是模塊間通信的管線數(shù)字系統(tǒng)設計到一定規(guī)模幾乎逃不開自頂向下、模塊化這套方法。當你例化一個子模塊的時候子模塊的輸出端口在父模塊這一側連接它的一定是 wire。來看一個典型的例子// 子模塊并轉串發(fā)送器 module uart_tx( input wire clk, input wire rst_n, input wire tx_start, input wire [7:0] tx_data, output reg txd ); // ... endmodule // 頂層模塊例化 uart_tx module top( input wire clk, input wire rst_n, input wire send_en, input wire [7:0] data_in, output wire uart_txd ); wire tx_start_w; assign tx_start_w send_en; uart_tx u_uart_tx ( .clk (clk), .rst_n (rst_n), .tx_start (tx_start_w), .tx_data (data_in), .txd (uart_txd) ); endmodule父模塊聲明的連接線 tx_start_w 和輸出端口 uart_txd 都是 wire。原因很簡單這些信號是“別人驅動的”當前模塊只需要讀取它的值或者把它繼續(xù)連出去不需要在某個時刻捕獲并保持它。從硬件意義上說它們就是一根根真實存在的連線。2.2 組合邏輯的數(shù)據(jù)流建模assign 連續(xù)賦值的黃金搭配assign 語句是 Verilog 里描述組合邏輯最基本的手段而任何 assign 語句的左側目標信號都必須是 wire 類型。這算是語法上的硬性規(guī)定。組合邏輯什么時候優(yōu)先用 assign而不是用 always我的習慣是當邏輯可以用一條或幾條布爾表達式直接描述清楚時用 assign 更簡潔、更不容易出錯。比如wire flag_valid (byte_cnt 4d8) (state BUSY); wire [7:0] next_data (fifo_empty) ? 8h00 : fifo_dout;這兩個信號的硬件含義就是一堆與門、或門、比較器和多路選擇器的組合沒有任何“時序狀態(tài)”在里面。我在做滑動窗口濾波或者累加求和這類純粹的組合運算時也偏好用 assign 把中間結果鋪開。好處是一眼能看出數(shù)據(jù)的流向不用去翻 always 塊的端口列表仿真排錯的時候非常直觀。2.3 多驅動與總線場景wire 才能掛多個驅動源wire 類型還有個 reg 不具備的特性它允許多個驅動源共同驅動雖然這在行為級建模時要非常小心。真實工程里典型的場景是三態(tài)門和雙向 IO。// 雙向數(shù)據(jù)線由讀寫控制信號決定驅動方向 inout wire sda; assign sda (wr_en) ? tx_data_reg : 1bz; assign sda (rd_en) ? 1bz : tx_data_reg;這種用高阻態(tài) z 釋放總線的寫法本質是在說“我不驅動這根線的時候把它讓給別人?！边@種能力只有網(wǎng)絡類型wire具備。如果你把一個 inout 引腳內部信號聲明成 reg綜合工具會直接報錯因為 reg 是有狀態(tài)保持的變量無法實現(xiàn)掛起釋放。需要再補一句多個 assign 同時驅動同一個 wire 時如果兩個驅動源同時有效并且電平相反仿真結果取決于驅動強度硬件上則可能燒毀。所以設計內最好避免邏輯上的多驅動沖突總線場景請用三態(tài)控制或仲裁邏輯。2.4 一個小結看到這些信號就用 wire綜合多年工程經(jīng)驗下面這些信號我基本上是閉眼聲明成 wire模塊端口里聲明的 input 信號input 天然只能是 wire。模塊例化時連接輸出的外部連線。assign 語句左側的組合邏輯目標。三態(tài)總線、雙向 IO 的內部信號。由子模塊輸出經(jīng)過簡單邏輯立即作為另一個子模塊輸入的中間信號。判斷的底層邏輯是**如果一個信號不需要在 always 塊里被賦值那么它就是 wire。**反過來只要它出現(xiàn)在任何 always 塊左側就必須是 reg。3. 什么時候用 reg核心場景拆解3.1 always 塊中的過程賦值必須用 reg 的硬性規(guī)則Verilog 語法規(guī)定過程賦值語句在 always、initial、task、function 內賦值的目標變量必須聲明為變量類型也就是 reg、integer 等。所以判斷一個信號該不該用 reg最快的方法是看它有沒有出現(xiàn)在 always 塊里。這里我多說一點“為什么”。因為 reg 變量類型的仿真語義是“存儲并保持”在某一個仿真時間點被賦值后直到下一次被賦值之前它的值都保持不變。而 always 塊天然就是事件觸發(fā)、執(zhí)行一次、然后等待下一個事件這種執(zhí)行模型兩者正好天然匹配。wire 則是持續(xù)驅動的把它放進 always 里賦值語義上就矛盾了。3.2 時序邏輯的建模計數(shù)器、分頻器與狀態(tài)機時序邏輯是 reg 最重要的主戰(zhàn)場。凡是要在每個時鐘沿更新值的信號必須聲明為 reg。計數(shù)器是最直觀的例子reg [7:0] cnt; always (posedge clk or negedge rst_n) begin if (!rst_n) cnt 8d0; else if (cnt_en) cnt cnt 1b1; else cnt cnt; endcnt 是 reg。它在時鐘上升沿更新時鐘沒來的時候就保持舊值綜合后就是 8 個 D 觸發(fā)器級聯(lián)成的計數(shù)器。類似地做 UART 多字節(jié)收發(fā)、SPI 時序控制、出租車計價器的金額累加這些從熱詞看都是大家經(jīng)常練手的工程案例核心都繞不開狀態(tài)機和計數(shù)器而這些狀態(tài)寄存器、計數(shù)值寄存器統(tǒng)統(tǒng)都是 reg?？梢赃@么說只要設計里有時鐘就一定有 reg。再提一句三段式狀態(tài)機。三段式寫法里第一段是狀態(tài)轉移用 always 時序邏輯狀態(tài)寄存器 current_state 聲明成 reg次態(tài)判斷 next_state 可以在第二段組合邏輯里聲明成 reg第三段輸出邏輯用 assign 接 wire 或直接在 always 里輸出 reg 都可以。整體上只要邏輯在 always 塊內就繞不開 reg。3.3 組合邏輯的 always 建模reg 處理組合邏輯的典型場景這是很多人的第二個知識盲區(qū)。我面試的時候特別喜歡問一個問題always (*) 塊里賦值的信號聲明成 reg綜合出來是什么答案經(jīng)常讓人意外純組合邏輯。當一個 always 塊是電平敏感(*) 或 (a or b)、而且所有分支都對目標變量完成了賦值時綜合工具會把它優(yōu)化成組合邏輯。沒有任何存儲的必要的條件下reg 這個名字就只是個仿真變量名而已。舉個例子一個很常見的組合邏輯建模方式reg [7:0] alu_out; always (*) begin case (op_code) 2b00: alu_out a b; 2b01: alu_out a - b; 2b10: alu_out a b; default: alu_out a ^ b; endcase endalu_out 聲明成 reg但它綜合出來是一個 8 位多路選擇器加運算組合邏輯沒有時鐘也沒有寄存器。這里用 always 而不用 assign 的原因是 if/else 和 case 分支邏輯寫起來更靠近 C 語言思維多人協(xié)作時更好讀。不過我要提醒一句組合邏輯用 always 寫最大的風險是分支覆蓋不完全導致推斷出鎖存器。這個坑后面專門講。3.4 又一個陷阱always 塊里別亂用 wire見過不少新手把模塊輸出端口明明聲明成 output reg然后在頂層連接時卻發(fā)現(xiàn)綜合報錯。還有更常見的毛病// 錯誤示范 reg [7:0] data_bus; wire foo; always (*) begin foo data_bus[0]; // 編譯報錯foo 是 wire不能在過程賦值里賦值 end這個錯誤信息大概是說 foo is not a reg or integer解決方式就是要么把 foo 改成 reg要么把賦值語句改成 assign。語法層面的原因在上面已經(jīng)說過回歸到思維層面就是第一反應要先分清**我是要寫 always 還是 assign。**定了語句形式數(shù)據(jù)類型就跟著定了。4. 仿真與綜合wire 和 reg 在“兩個世界”的行為差異如果你只想寫作業(yè)到第 3 節(jié)就夠了。但如果你想做真實的 FPGA 開發(fā)、ASIC 設計或者準備秋招面試這里才是真正拉開差距的部分仿真模型的規(guī)則和綜合工具的行為在很多細節(jié)上并不一致。4.1 仿真模型wire 是事件驅動的信號reg 是程序變量在仿真器內部wire 和 reg 的數(shù)據(jù)更新機制是不同的。wire 的更新遵循 net 類型的事件驅動規(guī)則當它的任何一個驅動源assign 右側表達式、門原語輸出、模塊輸出端口發(fā)生變化時仿真器會重新計算 wire 的值事件傳遞到下一級。這種模型對應的是硬件里電平信號的連續(xù)傳播。reg 的更新則像普通編程語言的變量賦值在 always 塊被觸發(fā)時執(zhí)行塊內語句把計算結果賦給 reg。在非阻塞賦值時這種更新還要分成“計算 RHS”和“更新 LHS”兩個階段這也是仿真器能模擬出真實觸發(fā)器采樣行為的底層機制。理解這個差異對你寫 testbench 很有幫助。比如在 initial 塊里你是可以給 reg 賦值的reg clk_tb; initial begin clk_tb 0; forever #5 clk_tb ~clk_tb; end但你不能在 initial 里給 wire 賦值除非你把它聲明成 wire 并用 force / assign 之類的方式來驅動。很多人在 testbench 里把輸入信號聲明成 wire 然后直接賦值一編譯就報錯核心原因就是沒分清楚這種仿真層面的差異。4.2 綜合映射硬件上兩者到底變成了什么綜合工具做的是把 RTL 語言描述的行為變成結構。它關注的是你的賦值邏輯、分支結構、時序約束而不是信號名字里帶的是 wire 還是 reg。所以綜合之后的 netlist 里基本上全是 wire——因為網(wǎng)表本身就是用連線連接各個單元的描述。原來的 reg 信號如果最后映射成觸發(fā)器網(wǎng)表里是一個 DFF 單元的 Q 輸出如果映射成組合邏輯那就是一堆邏輯門的輸出如果被優(yōu)化掉那網(wǎng)表里甚至找不到這個名字?？偨Y一張表幫你把 仿真語言類型 和 綜合硬件結果 這兩套思維徹底分開聲明類型賦值方式綜合結果通常情況wireassign 連續(xù)賦值組合邏輯連線與門、或門、多路器等regalways 時序塊賦值D 觸發(fā)器、寄存器堆、計數(shù)器regalways 組合塊完整賦值純組合邏輯無存儲單元regalways 組合塊不完整賦值鎖存器latch需盡量避免reginitial 塊賦值不可綜合僅仿真使用這張表建議直接背下來。面試里要是能把這個完整講清楚基本上就把一半的人甩在后面了。4.3 一道經(jīng)典面試題為什么同樣的 always有時是觸發(fā)器有時是鎖存器說到鎖存器這是組合邏輯 always 建模最經(jīng)典的坑也是面試官最愛用來篩選候選人的點。reg q; always (*) begin if (enable) q d; end這個代碼里q 聲明成 regalways 是電平敏感的。但問題是當 enable 為 0 的時候q 沒有被賦值。從仿真語義說reg 會保持原有值從硬件映射說要在 enable 為 0 時把值記住就必須引入一個電平敏感的存儲單元——這就是鎖存器。很多數(shù)字設計規(guī)范尤其是 ASIC 風格是強烈不建議在組合邏輯中不必要地產(chǎn)生鎖存器的因為鎖存器對時序收斂和 DFT可測性設計都不友好。正確做法是給齊所有分支reg q; always (*) begin if (enable) q d; else q 0; // 或者 q q; 但要明白區(qū)別 end加上 else 分支后q 在每個輸入組合下都有確定的賦值路徑綜合工具就能放心地把它變成多路選擇器了。同理case 語句里的 default 分支也是絕對不能少的。5. 實戰(zhàn)案例在一個 UART 發(fā)送模塊里wire 和 reg 怎么各司其職前面講完理論現(xiàn)在用一個完整的工程實例串一遍。就拿大家非常熟悉的 UART 發(fā)送模塊來當例子這種模塊在握手、協(xié)議解析、多字節(jié)收發(fā)項目里幾乎都會用到。5.1 模塊端口劃分輸入輸出到底用 wire 還是 reg寫任何模塊第一步就是定義端口。這里有個實用經(jīng)驗**input 端口一律是 wireoutput 端口默認也是 wire只有當你確定要在 always 塊里給它賦值時才把它額外聲明成 output reg。**在 Verilog-2001 時端口類型和數(shù)據(jù)類型是可以寫在一行的。module uart_tx ( input wire clk, // 系統(tǒng)時鐘 input wire rst_n, // 低電平復位 input wire tx_start, // 發(fā)送使能 input wire [7:0] tx_data, // 待發(fā)送數(shù)據(jù) output reg txd, // 串行輸出需要在 always 中賦值 output wire tx_busy // 忙標志用 assign 給出 );txd 是串行輸出信號根據(jù)發(fā)送狀態(tài)機在每個時鐘沿移位更新所以必須是 output reg。tx_busy 是忙標志它只是把內部一個狀態(tài)寄存器的值或組合邏輯結果簡單輸出用 assign 就能搞定因此是 output wire。其實這里也可以讓 tx_busy 直接等于內部狀態(tài)assign tx_busy (state ! IDLE);這句話的含義是只要當前不在 IDLE 狀態(tài)就對外拉高忙信號。它是典型的數(shù)據(jù)流組合邏輯用 wire 非常合適。5.2 內部信號規(guī)劃哪些該 wire、哪些該 reg進入模塊內部規(guī)劃起來就更有章法了。我的做法是先畫信號列表分成“狀態(tài)類信號”和“連接類信號”兩大陣營狀態(tài)類信號必須用 reg因為它們需要在時鐘沿被一次次更新state當前發(fā)送狀態(tài)三段式狀態(tài)機的第一段必用非阻塞賦值。clk_div_cnt波特率分頻計數(shù)器。bit_cnt當前發(fā)送的第幾個 bit。txd_reg實際串行發(fā)送的移位寄存器。連接類信號用 wire它們是組合邏輯的中間產(chǎn)物tx_start_pulsetx_start 的上升沿脈沖。tick波特率時鐘脈沖。byte_done一字節(jié)發(fā)送完成的標志。舉個例子波特率時鐘脈沖 tick 是這樣產(chǎn)生的wire tick (clk_div_cnt DIV_CNT_MAX);tick 是指定分頻計數(shù)達到最大值時的譯碼結果每一時刻都被連續(xù)驅動決定當然是 wire。接著狀態(tài)機可以用 tick 來驅動數(shù)據(jù)移位這就在多個 always 塊之間建立了清晰的信號通路。5.3 用 wire 把子模塊拼起來FIFO 與狀態(tài)機的連接如果這個 UART 發(fā)送模塊再往上做成一個多字節(jié)收發(fā)系統(tǒng)往往前面還要接一個發(fā)送 FIFO。FIFO 的讀數(shù)據(jù)端口、空標志、讀請求信號在頂層就是用 wire 互連的。wire [7:0] fifo_dout; wire fifo_empty; wire fifo_rd_en; uart_fifo u_fifo ( .clk (clk), .rst_n (rst_n), .wr_en (byte_recv_done), .din (rx_byte), .rd_en (fifo_rd_en), .dout (fifo_dout), .empty (fifo_empty) ); uart_tx u_uart_tx ( .clk (clk), .rst_n (rst_n), .tx_start (~fifo_empty), .tx_data (fifo_dout), .txd (txd) );這里幾乎全是 wire。原因很直接在頂層這個抽象層次你看到的不是“某段邏輯的賦值行為”而是“各個黑盒模塊之間的信號連線”。頂層的職責是連好線而不是描述內部邏輯所以 wire 就是頂層的主旋律。5.4 綜合后的實際硬件結果把上述模塊做完綜合你大概率會看到txd 對應的區(qū)域推斷出一組 D 觸發(fā)器移位寄存器和狀態(tài)寄存器。tx_busy、tick、byte_done 這些 wire 在網(wǎng)表里對應的是組合邏輯門比較器、與門。FIFO 內部的 RAM 和讀寫地址計數(shù)器分別映射成存儲陣列和寄存器堆。硬件不會管你代碼里寫的是 wire 還是 reg它只關心“你有沒有在時鐘沿保存狀態(tài)”和“你的組合邏輯是否完備”。所以我的建議很明確**寫代碼的時候把心思放在賦值場景上而不是數(shù)據(jù)類型上。**assign 就用 wirealways 就用 reg這樣寫出來的 RTL綜合工具最省心后端也不會半夜給你打電話。6. 常見問題與排查技巧實錄最后分享一些我在實際工程中反復遇到過的報錯和排查經(jīng)驗。這些問題基本是初學者的高頻雷區(qū)一個個過一遍。6.1 典型報錯reg 被連續(xù)賦值了錯誤信息類似Error (10170): Verilog HDL syntax error ... object xx is not a wire或者更常見的是reg cannot be driven by continuous assignment這個場景一般是你聲明的信號是 reg但又不小心寫了assign xx ...。修復方案很簡單把自己問一遍這個信號是組合邏輯的多路選擇結果還是時序狀態(tài)如果是前者看看能不能用 wire 表達如果實在要用 always 寫就把賦值語句刪掉、搬到 always 塊里。6.2 典型報錯wire 被過程賦值了錯誤信息類似Error (10028): Cant resolve xx to a reg or integer這個場景最常見的發(fā)生在寫 testbench 時wire clk_tb; initial clk_tb 0; // 報錯因為 clk_tb 是 wire不能在 initial 里被賦值。改成 reg clk_tb; 就對了?；蛘吣阏娴南胗?wire就得用 assign 或 force 來驅動。測試激勵這塊的解決思路是激勵信號用 reg因為它是在某個時間點改變的變量被測模塊輸出的檢測信號用 wire因為你只需要監(jiān)控它的變化。6.3 組合邏輯的鎖存器警告怎么處理綜合工具Quartus、Vivado、Design Compiler一般都會報 latch 警告比如 Vivado 里是[Synth 8-327] inferring latch for variable xx處理思路按優(yōu)先級排序檢查是否每個分支都給目標變量賦值了。if 要有 elsecase 要有 default。檢查變量是不是在多個 always 塊里被賦值。同一個 reg 不能被兩個 always 驅動這是語法錯誤。檢查是不是把組合邏輯塊誤寫成了電平敏感且分支不全的結構。如果確實需要鎖存器比如總線保持之類也要寫成顯式的 latch 風格并在注釋里說明理由別讓工具“偷偷”推斷。再補充個我自己常用的檢查技巧寫組合邏輯 always 時上電仿真把所有使能信號分別跑一遍 0 和 1觀察輸出是否有異常保持。如果某個輸入組合下輸出一直不變化十有八九就是分支缺了。6.4 wire 和 reg 實戰(zhàn)避坑清單這幾條是我自己在多輪項目里總結出來的“肌肉記憶”每一條背后都有真實踩坑經(jīng)歷分享給大家頂層連接信號全部用 wire。頂層不是寫邏輯的地方它是畫圖紙的地方。讓子模塊自己處理 reg 的內部邏輯頂層只負責把線連對。output 默認為 wire要往 always 里塞才聲明成 output reg。反過來input 永遠不可能聲明成 reg否則編譯直接罷工。testbench 里給 DUT 輸入的激勵信號用 reg檢測 DUT 輸出的信號用 wire。這個規(guī)則百試不爽。不要出現(xiàn) “assign always 同時驅動一個信號” 的代碼。無論是仿真還是綜合多驅動都是災難。組合邏輯 always 里一定要寫 else 和 default。哪怕你覺得條件全覆蓋了也要寫。一方面防工具推斷 latch另一方面也是給別人讀代碼時留個明確的邏輯閉環(huán)。如果發(fā)現(xiàn)仿真波形里某個 reg 輸出是 x優(yōu)先查復位邏輯和初始化賦值。reg 在仿真里默認值是 x這跟 wire 的 z 不一樣很多新手第一次跑仿真看到滿屏 x 會慌其實這只是仿真模型的初始值。不要把 reg 和寄存器劃等號。我在帶人評審代碼的時候最怕聽到有人介紹說“這個信號是 reg所以它是寄存器”。正確說法應該是“這個信號在 always 時序塊里賦值所以綜合后是寄存器”。再補一句關于綜合和仿真不一致的問題。有些新手會問為什么我仿真的時候 reg 輸出能保持下載到板子上就不對了這通常不是 reg 本身的問題而是代碼里復用組合邏輯 / 時序邏輯時不小心把應該搭的時序關系寫錯了或者復位方式、時鐘域跨域出了問題。建議排查的時候先用在線邏輯分析儀抓內部寄存器的信號看狀態(tài)機是否按要求走再看對應 wire 的組合邏輯輸出是否符合預期。把兩者分開看問題就縮小一半了。聊到這里關于 wire 和 reg 的內容基本就完整了。說句心里話這個知識點本身并不難難的是很多人一開始就陷入“wire 就是線、reg 就是寄存器”這種簡化模型里后面越學越別扭。我個人的建議是**每次寫代碼前先默念一遍assign 對應 wirealways 對應 reg然后放手去寫。**寫多了形成肌肉記憶你自然就理解為什么這種語法規(guī)則是合理的了。