幾個星期前的 ORFS，應該是因為 OpenROAD 參照的某個東東版本緣故，如果是選擇 local build 的人，會出現一個很奇怪的 C++ CMake 編譯錯誤。
坦白說，我們不是開發者，實在很難一眼看出 CMake 哪邊有問題？原本以為是要用 g++ 13 的緣故，還好後來看到 issue 列表，確定不是環境的問題。
昨天晚上覺得應該已經修復，於是便嘗試編譯最新 commit，順便確認
Yosys 強者的修改，沒想到就是這個決定，搞到快一點才睡。
一開始編譯到一半的時候，WSL2 環境便沒有反應，連要叫出工作管理員都很費力！其實這就是第一個警告了，代表記憶體已經快被用盡。
還好後來想到是這個原因，重開機後，稍微 review script，簡單修改 build_openroad.sh 檔案，讓 PROC = 1， 雖然編譯速度變慢，但至少不會吃光記憶體，其中好幾次，看到記憶體幾乎增加到我安裝 16GB 的水位，還好後來都有順利挺過，終於在晚上 12 點多得到一個新的 ORFS 環境。
不過，現在的版本已經跟我當初看得差了很多，從 Makefile 到 synth.tcl 甚至是各 design 的 config.mk 都不太一樣，試了一下才找到 hierarchy 的 synthesis 方法，但一時還是看不出來如何讓 instance name 不要出現 escaped identifier 的修改，於是便上床睡了。
今早起床，一時還是不知道要如何加到原本 ORFS 的流程裡，但我知道如何單獨用 Yosys 拿掉 escaped identifier，只要依序執行下面命令即可。
read_verilog design.v
rename -unescape
write_verilog -noattr -nohex -nodec design_unescape.v
奇怪的是，明明 jpeg design 沒有變，但新版本的 ORFS 合成出來的跟以前卻不一樣了？
算了，不深究了，我也只是想確認拿掉 escaped identifier 後，看起來會變得怎樣？
最後，查了一下，原來我的筆電，一開機後就吃掉 8G Ram，我的 WSL2 也允許吃到 8G Ram，難怪昨天電腦完全不能動彈！
Windows 11 真是吃 Ram 的怪獸，似乎之前公司舊電腦 Windows 10 開機完只吃到 5 G 多而已？
2025/10/11 更新
答案原來這樣簡單，Yosys rename 跟 Tcl 內建的指令衝突，故 Yosys rename 要改成 renames，同理，Yosys proc 也要改成 procs。
