給開司一罐啤酒

昨天是回到以前辦公室的第一天，畢竟我在那個空間也待了 10 年有，昨天上完廁所常常不自覺地走回以前位子XD

既然是回去的第一天，不買罐咖啡給自己說不過去，但該解決的事還是得解決。

查了一個星期多的訊號後，個人猜測失敗原因是因為不能滿足文件要求，如果要一個一個訊號自己慢慢初始化不太實際，也不能一股腦用 force 和 release 給足訊號，於是這兩天便先往下一階段邁進。

坦白說要用人工重新拉線很容易寫錯，即使對 Vim 略懂略懂的我，還是覺得太花時間了！

昨天趁著中午及下午上班後，簡單寫個小程式，可以幫我宣告 wire、增加註解以及加上一個 MUX。

雖然可以做到上述的事，但一個下午試用的結果，我的函數參數增加到 9 個，即使我呼叫 add_mux 的程式也是使用 sed parse 出 initialize instance 的 pin 所組成，但還是覺得很辛苦。

加上加班時間，大概快 9 個小時只加完 95 組 wire，大部分時間都是一個一個人工比對參數是否合理，中間還有開過 3 次 Tessent 確認連線是否有問題，大概一個小時加完 10 組訊號又多一點。

今天因為要出去，出門前還是稍微修改了一下 add_mux 參數，讓他跟原本客戶的名字及 index 比較能 match 得上。

明天不出門應該可以把剩下的加完。

這樣的需求就是要寫 config 檔餵進程式，雖然還是要比對 config 檔，但應該是比人工 coding 快，只是這樣的流程如何設計還是需要好好規劃才會好用。

畢竟 9 個參數的函數扣掉 2 個 default value 也還是有 7 個參數要加，自己用無所謂，要給人用就有點麻煩，但我也不認為這些參數可以省略就是了。

另一個方式就是只複製 top module，這樣 pyverilog parsing 應該就不會太慢，不過還是少不了 config 檔就是。

順帶一提，我這裡的 config 檔就是產生呼叫 add_mux 的語法，也就是使用 sed 產生出 code。

好久沒看 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 的訊號，同理可證。

工作站注意事項

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

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

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

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

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

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

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

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

詠春三板斧

一代宗師的武術界曾提到這樣一句話：詠春來來去去就是那三板斧！

今天不知為何在工作時想到這句話？

突然發現，其實我現在的工作每天也是只有用到三板斧XD

我目前工作的三板斧為：Vim、grep、sed。

Vim 不用多說，我自己就寫了一堆 Vim script functions，即使不算自己的 Vim function，我每天用到的 Vim 功能至少就 10 個以上起跳XD

不誇張的說，沒有 Vim，我大概沒辦法工作了！

其次是 grep，很多時候我要解決的問題或是完成手上的工作，說穿了就是在一堆資料中找東東！有了 grep 的幫助，真的節省我很多時間。

最後則是 sed，grep 找到的資料透過 sed 可以輕易的切出任何我要的片段，只要下對 regex，大概事情就完成一半了XD

如果硬要加上第四板斧，我想這道板斧應該就是 find 指令無誤！

Linux 與 Vim 的世界就是這樣的樸實無華，每天都能發現新玩意？

就像是我請教我主管問題一樣，不管何時都是如沐春風！

2024 week 37 新玩意

01. 不要太相信 EDA 文件

我是不知道 EDA 授權金額多少錢，但 EDA 文件普遍寫得不好倒是真的，看起來寫了很多，但對解決問題沒啥幫助，不然就是文件寫的跟指令實際行為有時候會對不起來。

不過前提是文件要先從頭到尾認真看一遍，最好要看 2 ~ 3 遍，如果還是覺得哪邊怪，那恭喜你，你不孤單XD

02. 除非特例，少用 GUI mode，不然容易當機

我們跑的設計應該很小，但我這星期就遇到當機 2 ~ 3 次了，原本都以為是該指令要跑很久，後來越想越不對勁，去 EDA license 頁面確認，果然該 license 已經沒有被占用，資源是已釋放的狀態。

我猜，EDA 應該有另一個 thread 定期回報授權主機，避免當機占用 license，畢竟授權不便宜。

因此，不管是在哪個模式下，如果覺得 EDA 好像當機了，給它個面子等個 30 分鐘左右，如果從授權主機看不到你的使用授權，就可以放心地使用 kill 砍掉該 process。

印象中，top 指令看到都還是 run，而不是 zombie？

03. EDA 相關工作要建立 SOP

EDA 動不動就要跑很久，錯了再來一次的時間成本很寶貴。

要做什麼之前最好先想好，檢查再檢查，最好有 check list 可以檢查。

Vim、Shell Script、grep 各種技巧要不斷精進，這都是可以提高工作效率的投資。

要建立自己的工作模式，比如開幾個工作視窗，要不要用分頁，視窗要擺在哪邊，養成下意識的動作，做起事來會比較流暢。