ORFS PAD Placement

終於搞定了，腦細胞都不知道死多少了XD

這一行太多知識待補充，自己一個人摸索確實有些緩不濟急。

忘記在哪個對岸網站看到有人說過的話：「IC Design 比數學好的地方就是，學過了就是會了，剩下只是經驗累積的問題。」

這兩年剛好都有略微涉獵到這些主題，我只能說，我學到的是：

01. 小老婆怎麼這麼可愛？

02. 如何用 Vim 取代常用的 UltraEdit！

gcd 和 jpeg design 看起來都給過，我對 ORFS PAD 的認知應該是對的吧？至少 PIN 和 CTS 看起來都比較符合我的預期。

看 CTS 的小技巧

01. Ctrl + F，clk* Net

02. select -type Net -name clk* + select -type Net -name XX （synthesis name 不是 clk* 的情況）

2024 week 43 新玩意

01. Find OpenROAD message

本來以為 place_pad 任務應該算告一段落，無意間發現 CTS 都沒有被建立起來，於是一個下午都在反覆查找相關資料。

順便記錄一下如何從 message number 找到 OpenROAD source code 的地方。

2024 week 42 新玩意

01. nl tool 自動加上數字編號

之前用 Vim 功能將備份小老婆歌單檔案前面加上數字編號，昨天無意間在鳥哥 sed 教學文章中學到 nl 這一個 tool，不只能加上編號，數字要不要補 0 或是後面要不要加上逗號等，這個 tool 都可以搞定。

原本還以為要用 sed 再組織一次字串好方便加上後面的逗號，沒想到 nl 開發者早就想好，果然 Linux tool 的哲學就是一次只做一件事，但把那件事做好！

nl -n 'rz' -w 2 xxx.txt

02. 還在跟 PAD 奮鬥

大概是這個星期一還是星期二就把兩個星期前主管交辦事項的簡報補充的差不多了，連 PAD CELL 的方向我都找到圖片做補充了。

既然 ORFS 沒有範例，乾脆自己來試看看吧，本來是用 gcd，但這個 chip 實在太小，為了放置 IO PAD 整個面積會變很大，但 core 只佔一咪咪，重點也是會死在 global route，錯誤原因是 congestion 太高。

後來改用 jpeg_encoder，這次的 core 大小就比較合適，話雖如此，但一樣會死在 global route。

今天是難得的休假日，下午外出回來本想先不加 IO CELL，看看 pin 是如何擺放的，我再來決定 IO PAD 的位置，看看這樣是否就能解決問題，沒想到居然看不到 pin？

感覺自己沒招了，ORFS issue 列表都翻爛了也沒有 fu。

2024/11/02 更新

雖然颱風假當天的嘗試還是以失敗告終，但在知道問題出在 netlist 後，隔天終於能對症下藥，也順利的在 gcd 和 jpeg 產出結果。

2024 week 41 新玩意

01. Linux Group By 功能

Linux 實在是一個很強大的作業系統，應該是說它的生態系很強大，什麼工具早就有人開發好了，根本不需要你寫半行 code 來解決問題。

就拿最近我在整理的一份 PAD 資料，突然想要做個表格放進簡報裡，regex + sort 取出資料常常在做，但要如何 group by 來加總一時還想不出來，隨便拿個程式語言做這些事當然很簡單，但人會被慣壞，有更簡單的方法當然更好囉。

老樣子，Google 一下，原來這麼簡單，我常用的 uniq 工具就可以了，加上 -c 選項即可。之後再用 sed 取出加總並調整一下順序，就可以在 Power Point 裡面用 "插入 -> 物件 -> Word"，然後在跳出來的 Word 浮動視窗貼上 sed 整理好的文字，然後選 "插入 -> 表格 -> 文字轉換成表格"，這樣就可以一氣呵成了。

2024/10/16 更新

忘了先前用 sed 取出 Verilog module 的技巧了，這樣才對呀！還要另存 components.txt 太 low 了XD

cat skywater130_coyote_tc.defok | sed -n '/COMPONENTS/,/END COMPONENTS/p' | grep '-' | awk '{print $3}' | sort | uniq -c

02. Tmux

以前就知道 Screen 的替代品 Tmux（嚴格說起來應該是比 Screen 功能還多），但一直沒有機會使用，工作站也沒有這個軟體可以使用，但自從在公司電腦安裝了 WSL2 後，應該是時候試用 Tmux 了。

它跟 Vim 一樣，有很多設定值可以調整，為了跟 Vim 使用體驗一致，除了前置組合按鍵外，應該要讓設定值盡量跟 Vim 看齊。

沒關係，慢慢來即可，畢竟工作環境不是一蹴可幾的事。

有試有機會

雖然昨天就知道 PAD example 在 ORFS 裡面有點混亂，應該是說 OpenROAD 裡面，所以今天也沒打算使用最新 commit 來測試。

不過早上在整理資料的過程中無意間發現原來有一個跟 PAD 有關的範例，但公司的舊版本 ORFS 會死在 FloorPlan 的階段，找了一下 issues，看起來應該有問題？但還是想用最新的 commit 來試試。

不過手上沒有實體 Linux 主機了，雖然我有自己的私人 VM，但我需要 GUI 環境。

既然昨天在家使用 WSL2 開啟 GUI 非常方便，於是便發個 request 詢問 IT 公司資安政策是否允許安裝 WSL2，沒想到居然 OK，只要額外安裝一個監控軟體即可。

果然是有問有機會呀XD

以後工作更方便了，不用等到回家才能繼續測試。

但公司 10 年前的電腦似乎有些慢，第一次開啟 Ubuntu 22.04 都沒有反應，後來改用系統管理員執行一下子就進去了，但帳號會變成 root，還好可以用 wsl 指令更改預設使用者。

據我實測的結果，好像什麼都不用設定就能使用 GUI 了？也許這是 WSL2 預設的選項？

應該就是下面圖片的那個選項吧。

目前使用 VM 價錢備忘

去年為了開發 Kobo EInk Bro 開了一個 VM，後來因為工作關係便不了了之！但為了已安裝的東西不用再重新下載編譯，於是只有做停止 VM 這個動作，目前一個月約要 NT $170 左右。

由於昨天在 WSL2 安裝 OpenROAD-flow-scripts 不是很順利，於是今天又開啟一年未用的 VM，看看是否是 WSL2 的問題導致安裝失敗？

到現在環境都還沒準備好，放假想先確認一些疑點的打算看來也是有點抖，目前只能確認 PAD 流程似乎不在正常的流程中，而是放在 test 當中？ 

放假到現在也不是一無是處，至少喚起我對這個 VM 的記憶，原本以為是儲存映像檔故要重新建立 VM，搞了半天，只要把停止的 VM 個體重新啟動即可，為了這個即插即用的便利，每個月要花 NT $170 還真是有點貴XD

也順便記錄一下，目前用的 VM 價錢，一個小時約莫要 NT $6 左右（含 Disk），如果單獨計算只看 Compute Engine 一個小時則是 NT $5 左右。

2024/10/06 晚上更新

OpenROAD-flow-scripts 在 VM 編譯一切正常，想了一下，直接切到 OpenROAD-flow-scripts/tools/OpenROAD/build 資料夾並依照 OpenROAD Tool Guide 去編譯，而不是在 OpenROAD-flow-scripts 裡面執行 local build，反正我執行的 local build 第一階段 yosys 是正常，我單獨編譯完 OpenROAD 後，將 OpenROAD 安裝到 OpenROAD-flow-scripts/tools/install/OpenROAD 即可。

之前因為 OpenROAD-flow-scripts 不成功，第二次 build 我好像有用 sudo 執行？導致某些產出都是 root 的所有權，將相關檔案砍完後，在 OpenROAD 的資料夾編譯一切正常。

那為什麼在 OpenROAD-flow-scripts 編譯一直有問題？我到現在也還不能解釋？目前只能確認 OpenROAD-flow-scripts 在編譯時，會單獨下載 OpenROAD 並切到 OpenROAD 資料夾去編譯，中間有用到 CMake，其他我就未詳細追究了。

因為我最主要是要看 layout 檔案，本想照此網友文章建置 X 環境，但我發現似乎在 WSL2 裡的 GUI Application 可以直接在 Windows 本機開啟，該網友文章我只做了 "勾選Windows子系統Linux版與虛擬機器平台" 這個步驟而已。

順便記錄一下工作站 OpenROAD-flow-scripts 版本，我就不用每次放假都要連回公司確認，為了這個電腦還不能關機，算是有點小麻煩。

2024/10/07 更新

下午詢問 IT 後，確定公司也可以安裝 WSL2，編譯 ORFS 果然跟家裡遇到的問題一樣，但因為公司電腦還在安裝中，等跑完再來更新解決辦法。

晚上 11 點多吹完頭髮後，VPN 連回公司確認 ORFS 是否有安裝成功，果然跟我想的一樣，不知道為什麼用 sudo ./setup.sh 執行的過程，會產生沒辦法寫入所有權為 root 的檔案？setup.sh 有起別的 shell 跑東東？但印象中這樣還是會帶到 sudo 的權限才對吧？

總之，按照下面步驟執行即可，step 2 就是執行會報錯的檔案，因為這個檔案的內容好像跟 build 有關，在後面還會用到，我也懶得研究 setup.sh 相關變數的值，故 setup.sh 只好浪費時間執行兩次。

step 4 是再一次確認是否還有 root 所有權的檔案，檢查結果只有這個檔案。

順便記錄一下 coyote_tc 的錯誤，本想靠它來確認 PAD 流程，但應該跟 issue 說明一樣，是不能執行的沒錯。

2024/10/11 更新

雖然知道 designs/sky130hd/coyote_tc 是不能跑的範例，但還是釐清一下相關的 issues，免得以後又要查找一次。

如果是直接跑範例，錯誤就如上張圖一樣，使用 "Command terminated by signal 9" 關鍵字去搜尋，看到的是這個 issue #1621。

這個 #1621 有提到另外一個 issue #1082，裡面有明確提到，這個 coyote_tc example 是不能跑的，而且應該被移除才對，因為這樣會讓使用者誤會。

#1621 最後面有提到問題是出在 Routing congestion？其 issue 為 #1630。

（但怎麼跑到那一步，我還看不出來，理論上已經到 stage 5 了？）

總之，目前 ORFS 沒有一個範例是有包含 PAD，以上。