不知道有沒有人像我一樣，長久以來將verilog中的有符號數視為不敢觸碰的禁區。不過俗話說啊解決恐懼的最好辦法就是直面恐懼，又有俗話說要想工其事必先利其器，還有俗話說磨刀不誤砍柴工，也有俗話說The only thing we have to fear is fear itself，所以今天咱們就嘗試對verilog中數據的符號屬性（有符號數和無符號數）探究根源。

本文的驗證環境基于VCS通過auto_testbench生成，相關的vcs命令行細節請在auto_testbench工程目錄下查詢。

先說明一個大前提，有符號數即補碼表示，無符號數即原碼表示或者說必然是整數的補碼表示，因此有符號數和無符號數均可以認為是數值的補碼。

為了省流，還是先甩結論。有符號數和無符號數的最本質區別就是：符號位的識別和高位拓展。除此之外，另一個區別就是從人的角度如何如何讀這個數，或者說$display(%d)打印時打印的值是什么（而從機器的角度它壓根就不區分signed和unsigned)。也就是說，如果不涉及到位寬拓展的事，有符號數和無符號數在verilog運算中可以說毫無差別。

所以先給出兩個結論，verilog中數據的符號屬性會影響兩件事：

1.符號位的識別和位寬拓展，有符號數最高位被識別為符號位，高位拓展時拓展符號位，無符號數高位拓展0；

2.數據的實際值（人的角度如何如何讀這個數）；

顯然，這個這個結論和固有的認知出入有點大，不急咱們先看一個實驗。下面的代碼是一段不涉及到位寬拓展的運算，t0_va0為有符號數-1，也就是16'hffff：

仿真的結果如下：

可以看到所有的結果都是一致的。而如果將va0信號改成無符號數：

其仿真結果也是一致的：

而一旦涉及到運算結果位寬拓展結果就有所差別了，比如將結果的位寬都改成18bit：

看到的波形就是這樣：

這個事就有些神奇了，所以后面就是說明下這里面的區別，或者說在完成運算后工具是如何識別這個數的符號性以決定位寬拓展的結果的。在開始之前必須明確下一個有符號數（補碼），'h1fffe和'hfffe對于機器是沒有區別的，都是-2。

仿真工具在對一個運算結果進行位寬拓展時，會先識別這個數的符號屬性，那么具體是怎么識別的呢？

1.有符號數和有符號數運算，結果為有符號數；

2.有符號數和無符號數運算，結果為無符號數；

3.無符號數和無符號數運算，結果為無符號數；

4.運算結果外又通過signed和unsigned定向指定時，最終的符號屬性遵照指定結果；

5.等號左側信號聲明中的signed/unsigned不影響右側運算結果的符號數屬性；

好，咱們一個一個看。

有符號數和有符號數運算，結果為有符號數。

很顯然，兩個有符號數進行操作結果是有符號數，位寬拓展時拓展符號位。同時這個波形還說明了等號左側信號聲明中的signed/unsigned不影響右側運算結果的符號數屬性。

有符號數和無符號數運算，結果為無符號數。

顯然結果是無符號數，高位拓展時拓展的都是0。

無符號數和無符號數運算，結果為無符號數。這個不說了，顯而易見的事情。

運算結果外又通過signed和unsigned定向指定時，最終的符號屬性遵照指定結果。

因為在運算之后又通過signed和unsigned指定了符號屬性，所以后面的位寬拓展就按照對應的屬性來了。再次進一步的佐證，等號左側信號聲明中的signed/unsigned不影響右側運算結果的符號數屬性。

好了現在我們再把前文的結論翻出來，verilog中的符號屬性會影響兩件事情：

1.符號位的識別和位寬拓展，有符號數最高位被識別為符號位，高位拓展時拓展符號位，無符號數高位拓展0；

2.數據的實際值（人的角度如何如何讀這個數）；

再看這個測試就很好解釋了：

再來補充一個，大家看看結果應該是啥：

顯然結果應該是18'h3fffe，因為左側的運算結果是有符號數的16'hfffe，拓展成18bit時拓展符號位1：

最后呢再看一組額外的實驗，感興趣的可以分析一下結果：

仿真的結果為：