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 我就不予置評了！

The pointer in EDA flow

EDA 世界中，一些 command 拿到的變數，我們可以把他想成是一個指向 object 的 pointer。

因此，如果直接用 puts command 印出該變數，我們只會得到一個類似指標的位置。

DC 可以使用 get_object_name 得到字串。

Tessent 則是使用 get_name_list 得到字串。

認真過每一天

下班前一個百思不解的問題，沒想到在洗澡時就讓我無意間想出來了？

前幾天在中央集權的框架中加入了一個地方自治的機制，雖然改動的不多，但我還真的蠻佩服我自己，當初只是為了不要大改別人家的專案才這樣設計，沒想到居然還有保留彈性的副作用，差點都以為自己是天才了，誰說一定要善用設計模式才是高手，只要認真過每一天，每天勤練感謝的正拳，總有一天，我們也能成為獵人協會會長XD

這個問題就是，雖然加入了地方自治的機制，但因為 DC license 有限，我也沒時間測試原本框架的功能是否正常，早上跑完自己想知道的頻率數據後，下午想說就來跑看看原始流程吧，沒想到還是出事了！

Tcl 變數其實跟 C 語言很像，使用前要先宣告。

前天為了兩者兼容，加了一段 if else 語法，下面是該語法示意：

if {"$::env(variable)" == "1") {

    set file_name "file_name_${varable}.log"

} else {

    set file_name "file_name.log"

}

殊不知當 variable 不存在時，此段語法會報錯，但不會影響 DC 繼續往下跑下去。

只要工作不會中斷，一切都好辦，將 else 往上提變成預設值，因為地方自治一定會有該變數，故不會有問題，而當跑中央集權框架時，因為有著預設值的關係，故變數不存在報錯也無妨。

雖然無妨，但那 Error 的字眼就掛在 DC log 中也是很礙眼，故下班前有稍微找一下如何檢查 Tcl 變數，但一直不懂為什麼要拿掉 $ 符號？

原來 info exists variable 的用法，variable 本來就不用加上 $，既然我們要檢查的是 env，當然就要從 $::env(variable) 變成 ::env(variable) 才行。

2024 week 36 新玩意

01. 跳板工作站顯目提醒

前幾天自己耍笨，以為工作站沒有安裝相關軟體，又麻煩老闆重傳一次檔案XD

但這樣下去不行，下次搞不好又會忘記跌股？年紀大了，不能依賴自己的記憶。

原本想要加一個 dispatcher，就是 shell 收到指令，都要先攔截進到這個 dispatcher，就可以趁機檢查工作站名稱並提醒自己，但不知道有沒有這種東西？

還好昨天突然想到可以用 prompt，就是那個 shell 提示。

Bash 要設定 $PS1，C Shell 則是要設定 $prompt，兩者顏色語法好像也不一樣？

02. DC 獨立男人

DC 可能因為一直改版，有些指令參數跟以前不一樣，一般都是進到 dc_shell，再用 man 指令查詢。不過，部門只有一套授權，所以當在 log 發現 Error 時，只能等到 DC 跑完才能查XD

前天因為沒什麼睡，昨天下午在完成老闆交代的任務後，就不勉強自己繼續看 Spec，而是上網查詢一下 csh 相關知識，終於讓我無意間看到好東東。

alias dcman "man -M $SYNOPSYS/doc/syn/man"

之後就可以直接打 dcman create_clock 查詢了。

03. DC check tcl 語法

也是從同一個網站看來，前天加入自動化 build 不同參數 DC 時，很多錯誤都要等到執行到那邊才會知道，這也是將流程拆分成不同檔案的缺點，無法一目了然的看到並發現錯誤。我們可以用 DC 自帶的 tool 來檢查，只是不知道能不能從進入點 tcl 一直檢查到所有 tcl 檔案？早上進辦公室後在確認一下。

dcprocheck xxx.tcl