pretty code

2026年10月22日 星期四

舊愛還是最美

昨天終於有時間來觀察客戶自行設計的記憶體修復流程。

話雖如此,真正的實作是客戶請我跟 AI 討論後設計出來的。

客戶要修復的記憶體不算太多,但要透過 GUI 一個一個訊號拉出來觀察也是有些沒勁?

還好上個星期已經有寫一個簡單的 Tcl,將要觀察的訊號轉成 Tcl 餵入 Simvision 軟體。

但最困難的還是這個無中生有的訊號如何定義?都怪那該死的 Escaped Identifier Verilog 語法,我實在無法簡單的從 RTL 轉成最後網表看到的訊號名稱?再加上有些訊號是 for loop gen 出來的,也大大的增加難度!

這次不像上星期我可以從 error log 中 parse 出我要的 instance,沒辦法,只好先找到一個 instance,再用其他程式語言組合出訊號名稱,然後餵進我的 Tcl(理論上應該在 Tcl 直接用 3 層迴圈,但懶得找語法了XD)。

沒想到 Python f string 要跳脫 Escaped Identifier 不是那樣直觀?試了 Google 前面幾篇文章的辦法還是不成功?

C 語言就沒那樣奇奇怪怪的講究,還好客戶工作站還是有 gcc,3 層迴圈,蛋糕一塊,重點是我根本不需要 Google 都還記得住語法!

果然是我學軟體以來用得最多的程式語言,小孩愛吃已回購。

2026年10月18日 星期日

我閱故我在

先前因為事情太多,一個終端機執行起來後,便馬不停蹄的開啟下一個終端機,繼續下一個任務,如此周而復始。

也不能說這樣不好,但以時間管理的角度來說,我們還是應該關注那隻最重要的青蛙!

雖然越晚執行的終端機表示越不重要,但以前一陣子所處的階段來說,每一個終端機都不保證能順利執行完畢,因此還是需要花費時間去 debug。

既然越晚執行的終端機越不重要,這也表示執行的時間有可能較短,當任務執行完畢有錯誤需要 debug 時,也是要花費一定的心力去處理。

結果就是第一重要的終端機已經跑完,也有錯誤需要花時間 debug,但我們卻被困在第 5 或第 6 不重要的任務上。

這個星期學乖了,不跑超過 3 個以上的終端機,且跑起來第 3 個終端機後便把焦點移回到第 1 個終端機畫面上,拿著我的 X3 邊閱讀邊想下一步計畫,重點是持續關注第一個終端機畫面。

也因為這樣,才讓我發現 xrun 編譯的盲點,也想到要處理增量編譯的問題。

如果你不用眼睛用心觀察,你根本不會意識到這有問題。

下面是我最後搞定增量編譯的比較時間,雖然只看 log 建立時間有點不準,但我們在意的是相對性。

左邊是使用增量編譯的版本,可以看出整整節省了 2 個小時的時間,更何況右邊還是使用砍掉編譯資料夾加速的方法,如果是我最早的版本,我想編譯浪費的時間一定更多。


購買 X3 的決定果然是對的XD

2026年10月12日 星期一

X3 國際版使用一天心得

在知道正確的字型設定後,目前用起來沒啥大問題。

昨天因為 X4 沒貨才退而求其次購買 X3,沒想到整體感覺還不錯,比我想像的好。

這也是我第一台白色閱讀器,同樣尺寸下,黑色看起來有點像玩具?

除了字型外,我只把左右按鍵對調,電源鍵選擇短按,還有看書的字距與段距,其他都使用原始設定。

至少對我來說,應該沒有刷其他韌體的必要了。

另外,我從 Kindle 拿出來的圓體,試了兩個線上轉檔軟體都會失敗,一樣的字型直接丟到 Kobo 機器閱讀是沒有問題的。

2026/10/13 更新

羅技 R500 翻頁器,雖然 X3 可以認得,但無法連接成功。

2026/10/14 更新

把前幾天拍的照片放大,感覺兩者的閱讀設定相差無幾?


另外一種字體的感覺。


2026/10/17 更新

今天載老婆去加班,難得北上台北,先去天龍一趟,買了兩本書。

接著從天龍走到三創,約花了 35 分鐘。

詢問店員的結果,依舊還是沒有 X4,看起來目前應該是停產了?

加碼又買了 X3 一般版,感覺沒啥差異?但是一般版的按鍵似乎比較鬆或是說不扎實?整體按起來國際版比較舒服?(晚上回家後,機器未更新前,書籍設定頁面跟國際版不同,但更新系統後,目前兩邊看起來一致)

離開三創後,走回老婆公司附近,等老婆加班完畢在路邊餵蚊子時,隨手又拍了一張國際版照片,此時已經快接近傍晚 5 點。


2026/10/18 更新

不知為啥,如果單從正面看,總覺得國際板的機器比較厚?而且似乎稍大了些?

左邊是一般版,右邊是國際版。

2026年10月11日 星期日

水清魚讀月

記得剛入伍時,我們的內衣後面都會用黑色簽字筆寫些字做記號。

一開始,因為大四才組電腦,於是便用 K6-266 這樣的 CPU 名稱當標記,當時 AMD K6 只有 233 頻率,266 是超頻上去的,故應該不會有人跟我一樣?畢竟那時的主流是購買 Intel CPU。

後來看久了也覺得無聊,於是便用起了【水清魚讀月】這個名字,靈感應該是來自於當初天宇布袋戲的一個反派角色名稱,但因為這個原出處的詩句我很喜歡,故也顧不上壞人不壞人。

唸起來感覺就很有先天人的氣勢,但又不像一頁書那樣的霸氣外漏?

就像如果要幫我的書房取個名字,我應該會毫不猶豫使用【詩海石硯台】這個名字!

原來我也是個儒家門生呀?


2026/11/11 晚上更新

中午去了一趟三創,可惜的是熊老闆沒有 X4 國際版現貨!

有鑑於我就是要敗家,故還是購買了 X3 國際版與 Kobo Libra Colour。

也不知道是太久沒 Google 還是怎樣?沒有看到有哪一篇文章有清楚說明字型尺寸各自代表的意義?

最後終於在網友分享的字型中,知道了 3 個數字的代表意義。

比如說 48 48x64,就是對應這個線上轉檔軟體的這裡。


如果是用原生系統,行距 2.0,段距 1.50。

對應 IBM 鍵盤的小紅點,大概是這樣,我覺得是最適合老年人的閱讀字型大小。


跟今天購買的 Kobo Libra Colour 對比。


真搞不懂,到底是我沒認真找還是怎樣?幾行字加個圖片就能說清楚的事,居然一個也找不到?

2026/11/12 更新

昨天之所以要購買 Libra,不只是想要敗家而已,2023/06 購買的 Clara 2,10 次點擊翻頁中約莫有 3 ~ 4 次會觸發最近閱讀書籍,不然就是變選取,實在是很破壞讀書節奏。

當然還是可以再撐一下,但我就是要敗家呀XD

2026年10月7日 星期三

牽一髮而動全身

感覺沒完沒了?

客戶改 RTL,影響我原本 constraint,視情況我也可能會有問題!

我同事的項目更糟糕,跟 designer 彼此之間還會互相影響!

難怪 PD 同事快抓狂,工作時間都被壓縮了。

有比較好的方式來解決嗎?

坦白說我也不知道!

我只是個浪跡天涯的工程師呀XD

2026年10月3日 星期六

做人不要手賤

我可能有潔癖?

剛才在跟 Claude 討論一些問題,覺得 AI 講得很好,於是便想把它釘選起來。

後來又看到一個 project 的設定,感覺可以拿來歸類,於是便把它連結起來。

想想還是不要,想要把它刪掉,又怕會一起連動,故有先選擇 unpin。

沒想到刪了 project 後,還是被一起刪掉了。

辛苦了半小時的討論,現在都沒了。

先不論 AI 說得對不對,感覺現在工作很多東西,可以跟 Claude 討論了?至少也可以給我一些啟發。

2026/10/07 更新

詢問 Claude 的結果,原來正解要移出專案,我英文果然差呀,當初都沒注意到這個選項?

另外,目前已經可以從設定看到使用量,可惜的是只有百分比。

2026年9月24日 星期四

氣泡排序法

規矩,規矩,得以成方圓。

雖然已經快接近專案尾聲,但復盤自己的缺失還是很不錯的。

理論上在工作站應該要用 tmux 之類的工具,好讓自己工作方便,但因為自家工作站沒有這個工具,導致雖然客戶工作站有,但怕影響專案順暢度,故也未貿然改變自己的工作流程。

Q1. 當初真的用 tmux 會比較好嗎?

取而代之的是使用多個 Workspace,數了一下,我大概開了 12 個有。

應該要使用氣泡排序法概念,比如將重要已經跑起來的工作往右邊放,左邊放目前人正在執行的終端機,這樣比較清楚,甚麼時候可以驗收工作結果,還有哪些工作未完成。

總之,工作也要像進入心流一樣,假設可以如雲朵般絲滑,工作也會更輕鬆。

2026/10/03 更新

使用氣泡排序法還有個好處,將工作分左右歸類後,中間一定還會剩下幾個 Workspace 可用,當跟客戶開會時,臨時需要 review script,便可以清楚知道剛才開的終端機在哪個 Workspace,才不會一時找不到。