醉裡挑燈看Code

2025年5月22日星期四

今年我看過的騷操作

今天在試跑一個 IP 的 testbench，第一次看到這樣的騷操作XD

首先，在預設 c shell 的環境下，呼叫一個 c shell 語法的 script 來設定相關變數，接著再跑一個有指定 shell 的 bash script 來跑 testbench。

由於我不是在工作站，故我不能在預設的 bash shell 下另外用 tcsh xxxx script 的方式來設定變數，除非我把呼叫 bash script 的 command 寫在 c shell script。

我個人是這樣覺得啦，既然 EDA 跑在 bash shell 不會有問題，事實上御三家的一些 gen 出來的 tool 也是用 bash 語法寫的，這樣大家都統一使用 bash script 不就好了，何必把問題搞到那樣複雜？

即便是號稱一天上班就用了 5 種程式語言來工作的我，還是很討厭一直在 context switch，人生呀，輕輕鬆鬆簡單過不好嗎XD

2025年5月18日星期日

又到了一年一度清潔冷氣的日子

前一陣子感冒，拖到今天才有空清潔冷氣，下星期老婆應該就可以爽爽吹了XD

去年因為被排線兩邊卡榫誤導，一直無法順利退出排線，只能一手扶住外框，一手伸進出風口擦拭，今年不理兩邊卡榫，硬用暴力演算法解題，終於順利退出排線？

整個外框拆除後，整體清潔容易多了，一台去年才換的冷氣，看起來跟新的一樣，鼓風輪稍微用紙巾接觸的結果也沒有明顯髒污，而另外一台 2021 年疫情時換的冷氣，保麗龍就有明顯的發霉，因為去年有擦過，故知道是去年怎麼擦都擦不掉的汙垢，目前也只能就我能清潔的清潔，不管怎樣，一定是比只能從外面擦拭乾淨。

去年換掉的那台窗型變頻舊冷氣，只過了 7 年就因為底盤卡住髒汙而滴水，考慮了一下整台換新比較快搞定，不然去年夏天就沒有冷氣可吹了，這樣看來，窗型變頻冷氣大概也是要 5 年就找人清潔較好，不然就會因為底盤卡住髒污而滴水。

日立變頻只有雙吹才是日本製壓縮機，台製明顯的聲音大聲多了，變頻的好處就是稍微安靜，但即使是日立也不用覺得會多安靜，不過我也只有窗型能夠選擇，不論是書房還是臥室，大概就是選擇 3 萬多的機型即可，再上去就會因為太大而裝不下，其實我可以選擇型號 28 的，選大一號的好處就是哪邊冷氣出了狀況，還可以用另一台將氣流導到另一個房間，至少撐過炎熱的夏天是沒問題的，根據去年實測的結果XD

房間：RA-36 NR（3.69 KW）

書房：RA-36 HV1（3.69 KW）

順便拍個圖記錄一下，外框拆除要看此篇記錄。

2025年5月17日星期六

不枉費我放假幾個小時的努力

在一個 netlist 中，想要追蹤一個信號是件很痛苦的事XD

如果是可以開啟 EDA 的環境，比如說透過 Tessent Visualizer，只要準備好相關 library，滑鼠點擊幾下，就可以看到來龍去脈。

但很多時候，我可能只有 Vim 可用。

之前為了這種情況，寫了一個 map 自動將某個 module code 複製起來，使用 tab 開啟複製到新分頁，這樣查詢時就不會過頭，避免已經跳到別的 module 而不自知。

早上出門前突然想到，是否可以在按下 n 跳下一個位置時，顯示目前位置所在的 module name 以及行號呢？

下午回家洗完澡後，扣掉晚上吃飯時間，大概也寫了 3 ~ 4 個小時有吧？

終於在剛剛完成了，雖然只有不到 100 行 code，但卻遭遇到很多問題。

比如在 statusline 顯示變數，怎樣用 regex subgroup 切出我要的 module name，還有如果 map key 還是用 n 會一直進入無限遞迴的問題，以及針對 statusline 的修改即使是對的，但還是會報錯，必須重新出去 Vim 再進入一次才會正常的問題等等。

真的是得來不易呀，也不知道是否真能有點幫助？

但不得不說，完成的那一瞬間，爽度真是一百分有XD

2025年5月16日星期五

好像會又好像都不會

Vim script 寫到現在，有時候會覺得好像自己什麼都不會XD

早上因為一直咳嗽，很早就起來了，想要為自己的 Netrw 加一個功能，加到剛剛都還不成功。

快要上班了，只好先用 patch 搞定，留下 echom debug 訊息，之後有空再來尋求正規解法XD

2025/05/17 更新

目前先用個變數記住 current buffer number，每次進到我的 Netrw，只要現在 buffer number 跟之前不一樣就可以放心的砍下去，好像還可以。

至於遇到 C:\..\ 這樣的路徑，也就是一直按 - 鍵，已經切到根目錄的情況，多一道檢查手續的 patch，好像也還行，暫時先這樣解決吧。

現在只差到底是否要針對 Windows 與 Linux 區分目錄符號？感覺說明看起來是不用？

目前我的 .vimrc 可以用在

Windows gVim

Windos Git Bash

工作站 Vim

嚴格來說，也可以用在不管是公司還是家裡電腦的 WSL2 Unbuntu，但是因為工作站 Vim 版本比較舊，我的 Netrw 一些函數無法呼叫，只好還是用 Vim 內建的 Netrw。

我也懶得再去區分了XD

2025年5月14日星期三

dcman

之前在某篇文章學到 dcman 的用法，讓我可以在沒有 DC license 的情況下還是可以查詢指令說明。

不過，對於 message ID 形式的訊息，比如 VER-970 這樣的 ID，只能在 dc_shell 下用 man 查詢。

雖然辦公室的人很少用 DC，但只是想查個東西，還要等待 DC 啟動，少說也要好幾秒，更別提為了不讓到處都是 DC 的 command.log，個人習慣還是先切換到我自己的 temp 目錄才去啟動 dc_shell。

雖然我有設定 alias 不用打那一長串指令，但還是覺得不開心XD

昨天研究了一下，終於知道為什麼原來的 dcman 不起作用！

man -M 指定的資料夾中，man database 需要符合一定的結構，就我初步看來 DC message ID 形式的 man database 多了一層資料夾，難怪都會查無資料。

解決方式也很簡單，另外寫一個簡單的 bash script，遇到像是 VER-970 這樣的查詢，使用 - 割出前後字串，前面字串就是那多了一層的資料夾名稱，接著再接上 VER-970 以及後面的副檔名即可。

str=$(echo $1 | sed -En 's/([a-zA-Z]+)-(.*)/\1 \2/p')

str=($str)

folder=${str[0]}

整個查詢會變成下面這個樣子

man -l xxxxxxx/VER/VER-970.n

測試了一下，果然如我想像中一樣可以順利執行，也順便測了 C2 C3 C9 等 DFT 錯誤訊息，目前看來都還可以正常工作。

另外，跟這個主題無關，為了讓自己的 bash script 更有彈性，有些跟著 script 的設定檔，最好還是指定 script 所在的 folder 變成絕對路徑，這樣的好處是當你使用 alias 執行自己的 bash script，我們可以切到要傳遞檔案的那個路徑，這時就不會有找不到設定檔的錯誤發生。

還有要傳遞的檔案，最好也是使用絕對路徑，這樣傳進去 EDA Tool 裡面也不會找不到檔案。

其實不管是 Python 或是 Go 也是如此，畢竟我們會希望把工具放到某個路徑，而不是把檔案複製到工具路徑再去執行，這樣一來，執行路徑就會很清爽，工作起來也更開心XD

SCRIPT_DIR=$( cd -- "$( dirname -- "${BASH_SOURCE[0]}" )" &> /dev/null && pwd )

file1=$(realpath $1)

2025/05/15 更新

據我所知，DC 有幾份文件是關於指令、變數以及錯誤訊息，如果習慣查詢 PDF 的話，也可以不用像我一樣使用 man 來查詢。

不過，兩邊的內容都是一樣的，坦白說，都一樣爛XD

個人覺得御三家中，文件寫得最好的是 Cadence，至少 LEC 是我覺得讀起來最順的，其次是 Simens，至於 Synopsys 我就不予置評了！