gtkwave 待驗證事項

gtkwave 什麼都好，就是使用滑鼠滾輪時，作動的是移動時間軸而不是像 Verdi 是調整訊號欄位的上下滾動。

看文件是有一個 use_scrollwheel_as_y 的選項可以使用，但不論是在家裡還是工作站都無法生效？

改天有空再來翻翻 source code 確定是否誤會了文件的意思。

2025/07/26 更新

稍微翻了一下 README，似乎在某個版本後就拿掉這個選項？

電路是個很神奇的東東

雖然 debug 很煩，很多時候會找不到方向，還有問題一直無法收斂，但多少還是可以從中學到一點新知識。

電路是個很神奇的東東，可能只是某一個 bit 不對，就導致整個 simulation 不如預期。

昨天剛好跟同事討論到 $display 出現了 xX 的字眼，查了一下，才知道這兩者是有細微的不同。

簡單來說，當訊號中有一部分是 unknown，就會看到大寫的 X。

反之，如果訊號全部 unknown，便是小寫的 x。

長知識了XD

下面是一個簡單的例子以及規格書描述。

好久沒看 Vim 的書了

最近都在連工作站測試，放假除了出去外，有想法都會進工作站試個幾局XD

原本下班前覺得妥當的東西，剛剛連回去看的結果居然不如預期？

無奈之下，還是先 dump fsdb 好了，根據我星期日的測試，雖然因為缺少 license 無法開啟，但還是可以透過 fsdb2vcd 得到 VCD 檔案，如果我們又無聊的透過 vcd2fsdb，這個 fsdb 就可以解除封印，不過不排除是我星期日測太多眼花了XD

唯一可以確定的是 VCD 轉 fsdb 就沒有 license 問題。

目前網路上找的到的解釋就是下面這張圖，感覺很像 Synopsys 會做的事XD

不知不覺小老婆演唱會也過去好幾個星期了，這次雖然準時登入還是搶不到票，不過我喜歡的歌演唱會也不會唱就是了！

現在有點懷疑是否真的要用 VCS 才能順利跑成功？

我果然還是太嫩了？以為憑我 SW 的經驗可以無往不利？

幸好之前投資 Vim 的點數沒有白費，不需要找阿卡拉重置點數！

如果這一年多來沒有投資 Vim，我估計我跑過的測試應該會少 1/3 以上！

很多時候要改一堆東西，Vim 不熟都很難搞定XD

2025/07/15 更新

成也蕭何，敗也蕭何。

就是對自己的 Vim 技巧太有信心，沒想到居然少給了某個 hard macro 電，還好同事有幫忙看到，不然我應該找不出來，該段 code 看了至少 10 次以上有。

這告訴我們一件事，EDA 工具已經告訴我們哪個訊號有問題，第一件事一定是去檢查那根訊號，而不是把整段 code 又看一次。

另外，fsdb2vcd 有點愚蠢，從上班轉到下班回到家遠端連線都還沒轉完，那還不如直接 dump VCD 都沒那麼慢！

EDA 工作每件事都很花時間，還是盡量不要犯蠢較好，不過好像很難避免？

這應該不是什麼 SOP 可以解決的！

我能想到的就是可以用程式檢查的就寫在 Testbench 內檢查，越早出錯越早離開越好。

$display 想看的訊號，如果可以用程式產生 $display 的檢查語法，還是要利用程式來產生，才不會像我一樣敗在那個 bit。

force 的訊號，同理可證。

Linux + Vim 真是絕配

想要得到一份兩個目錄下的檔案內容差異又不想包含 soft-link，Google 一下可以知道 diff 就有這樣的選項可以使用。

diff -r --no-dereference

為什麼要排除 soft-link？假設路徑中前後各有一個 soft-link，則比較出來的差異數量會膨脹成 4 倍。

排除了重複的資料後，diff 結果可以很容易的再用 sed 切出我們要的內容，也就是不同目錄的差異檔案清單。

如果我們把查詢出來的清單再加工成另一份清單，簡單加上一個 Vim Function，我們就可以快速的隨時瀏覽該檔案的差異項目。

diff -r --no dereference Dir1 Dir2 > diff.log

cat diff.log | sed -En 's/diff -r --no-dereference (.*) (.*)/gvim -d \1 \2/p' > diff_file_list.txt

function! CallExternalCmd()

    let l:line = getline(".")

    execute ":!" . l:line

endfunction

這是我在工作站沒有 WinMerge 這樣的軟體情況下，能夠想出的最佳解法。

當然最佳解一定是在工作站安裝 WinMerge 類似的軟體，雖然在 Linux 上 command line 才是王道，如果偶爾也有 GUI 可用，那也是個不錯的休閒時光XD

人的記憶力很不可取

早上連回工作站確認昨天測試結果，順便試一下還沒測試的參數。

突然無意間發現，似乎有一段 code 沒有整理到之前簡報？

馬上回去 review power point，沒想到我當初就有寫進去？

完全不計得有這回事？

最近測試很不順利，從上星期四晚上 debug 到今天還不能跑過所有的 PHY test！雖然這星期又多過了 2 個測試項，但還是覺得很阿雜。

我想應該要靜下心來好好重頭看過所有的文件，不要先入為主的認為沒用就心不在焉的看過！

就從我整理的 power point 及 word 文件開始好了，畢竟就連我有寫過的我都忘記了XD

動態改變 Verilog 選項

很多時候，工作就是一連串的取捨。

以 Verilog 來說，`ifdef 是編譯時期決定的，可以用這個來決定 Verilog 的行為。

但如果我們想要增加功能，我們就必須重新 define 新的 macro 並重新編譯才行。

想要動態改變 Verilog 選項，就必須使用 $test$plusargs 或是 $value$plusargs，前者類似 `ifdef，我們想要知道的是某個值是否有定義，後者則是我們想知道某個值是什麼。

下面便是一個簡單的例子。

值得注意的是，使用 `ifef 或是 `$test$plusargs 並沒有什麼準則，端看你的需求是什麼？

動態改變某個選項，意味 simulation 必須一直做判斷求值的動作，我想這多少也會增加 simulation 的時間？

假設不考慮效能的話，動態一定是比 `ifdef 好，至少你可以一眼看出程式在幹嗎！

當然我們可以用前置處理器展開的手法得到沒有 `ifdef 的原始碼。

自己寫的 Verilog 還好搞，像是 vendor 的 Testbench，它的各個 define 散落各地，光要把他們集合起來餵給 iverilog 就是個大工程。

純軟的人真倒楣，走到哪都要看到爛 code，10 幾年前我看高通以及微軟的 AK 已經覺得夠爛了，沒想到現在看到 Synopsys 的 code，我才知道人外有人，天外有天。

一爛還有一爛爛，連文件跟 Testbench 都對不起來是怎樣？

工作站注意事項

已經好幾天下班後或放假時都會連回工作站確認測試結果及做更多的測試。

今天早上外出回來後，就在確認上一次測試的結果時，不知為何 Vim 操作變得很慢，於是只好先離開再進入工作站。結果回來時居然看不到原本的 session 階段，只好忍痛新開 session。

進入新工作階段後，第一件事當然是確認原本的 simulation 是否還在，如果還在要把它 kill 掉，不然最近工作站空間吃緊，測試可能會無法順利完成。

果不其然，上一個 session 的 simulation 還在，當下也沒想太多就 kill 了。

後來為了測試工作站 save session 是否正常，便先離開再進來。

不料，卻看到兩個 session，原本以為已 crash 的 session 居然又在了？進去一看，開啟的 shell 視窗都在，難怪先前 ps 還可以看到原本的 simulation。

我想我想相反了，只要 ps 可以看到 process id，那就表示 session 沒有失效，只是不知為何當初登入時看不到，很可能重新連線就可以看到了！

可恨我的測試只好又重頭再來一遍XD