[EDA] Standard Cell Layout Design Guideline

筆記一下在畫 standard cell layout 時要注意的幾點事項，不過因為我做的主要是 digital high performance standard cell，其他類型的應該會有截然不同的綱要

[python] 限制 subprocess 的 CPU & memory 使用量

暑假到了，又一批要進入研究所的新生要來報到，由於實驗室的傳統是所有新生都要接受 programming training project，而我們實驗室的 training 是老闆會幾篇經典的論文要新生實做出來，雖然標準年年都會調整，不過今年老闆明確的說他要檢查新生寫的程式，然後通過的標準除了要檢驗結果的正確性，也要檢查執行時間 & 記憶體使用量。而這次的 training project 老闆指定其中一題要把我現在做的東西切割一小塊出來讓他們實做看看，所以這次我必須要寫一個 verifier 去做自動化的驗證

[隨筆] 學術與實務間的巨大差異

做了幾年研究，從碩班做的單一面項的研究，到現在博班做一個領域的研究，雖然還不敢說已經能不負眾望的承接 "博士" 這個稱呼，但確實有比較了解所謂做研究這檔事。即便是對於有經歷過完整碩士研究的人，我想我還是有更深一層的體認的。不過我想這也是正常的，畢竟對於只有兩年，其中有大約一年的心力幾乎都要投入修課所以只剩一年的時間，的碩士研究生來說，一年內要能完整做出一個學術研究，要嘛題目很單純，要嘛老闆很仁慈，不然就是運氣不錯很快的就找出突破點，如果不是運氣那通常只有在該領域已經浸淫多年有些心得的人才有可能辦得到，否則老實說一年內要能做出有突破性的學術研究說實在有點短。所以近幾年 (以前我就不知道了) 碩士研究我覺得教授們大部分都是把重心放在訓練學生如何做一個學術研究，至於成果應該只要別太糟都沒事的，畢竟只是來混碩士學歷的學生很多。

通常在碩士訓練中，老闆都會給一個研究方向讓學生找出自己想做的題目，有的甚至會直接指定題目 (恩，我知道有的教授會裝死，畢竟我認識的教授中就有這種 XD)。如果最後題目是自己決定的，而且老闆也有用心指導的話，姑且不論題目本身是否具有實務上的價值，那或多或少也會經歷過一段找出具有學術研究價值的研究題目。不過當過研究生的人一定知道，就算沒當過研究生的可能也有聽過：很多研究其實一文不值 (如果是碩士論文那機率更高 XD)。舉凡像是論文中提出來的論點是假議題到實務上根本不可行 ... 等等，一篇論文就算能被刊在優質期刊/會議上，最後經不起檢驗的也所在多有，特別是審稿者不見得熟悉投稿者所做的方向 (想必有很多研究生都曾經幫教授審過論文吧 XD)。當然，如果做得是純理論的研究就沒道理拿實務上的困境來檢驗，不過因為我自己的研究領域是 EDA，不考慮現實的可行性實在說不過去，所以偶而會對於為了發論文而做的研究感到不能諒解。當然，有些是為了畢業或是為了升等之類的現實困境而不得不為之，但也會為此感到悲哀。

比起其他研究生，我比較幸運的地方碩班與博班期間都接了業界計劃，而且都是具有學術價值且是有實務上困境的題目。不過也正因此會發現有相當大量的學術論文一旦搬到實務上來其實都很不堪一擊。原因其實也不難猜，學術論文對於實驗結果要求的是證明提出來的方法是確實有效的，所以只要能做到這點就是個成功的實驗。而讓學術論文不堪一擊的實務上困境有很大因素來自於學術研究上不會想去處理的細節，也可以說是就算做了也不會提升論文價值的麻煩困擾。這類因素輕則降低實驗宣稱的成效 (但不減低學術價值，因為可能只是一些不常出現的特例，也沒有討論的必要性)，重則我認為是能從根本上否定一篇論文的。當然有時是來自於資源的問題，畢竟有些實務上的困境，特別是做 EDA 這行的，沒有業界實際的經驗與資源輔助，只靠學界自身的資源要做出能同時兼具學術價值與實務價值的研究是真的有難度的。比方說先進製程相關的研究有一大堆內容是業界機密，如果不知道那些機密還真不會知道自己做的研究到底有沒有用 (不過這幾年發現有接露出來的還只是冰山的一角，還有一大堆不能說的秘密 XD)。這也是很多人問我未來是否要當教授時我一律回應我要先去業界打滾幾年再說，畢竟老是待在象牙塔裡對於從事這領域來說實在不是件好事。

不過這幾年最有感的地方應該還是投論文吧，特別是當你發現自己辛苦了老半天也用了業界的資料做了套應該還滿完整的實驗，卻比不上一篇很會說但沒啥參考價值的論文時，那沮喪感確實是滿大的。但最近靜下心來想根本原因何在時，我想除了我自認能用 "過往的相似研究均無法解決一個實務上的困境" 來說服審稿者外，我發現會議論文的審稿者其實更喜歡看到一些新穎的題材，我想有部分原因應該跟會議中可以跟發表者互相討論這類新穎的題材，順便從中找出一些做研究的靈感有關，不過這點確實提醒了我行銷故事的重要性。

 下一個研究題目已經開始了，但是望著寥寥無幾能用的參考論文，說實在的還是會覺得相當無力阿。有些論文即便方法沒有參考價值，提出來的問題與論點確實有其參考價值，但也有為數不少根據已知的問題提出的新方法看似比舊方法好，但實際要套用就發現一大堆問題 (攤)

[C++] virtual destructor

C++ 在設計 class 時，virtual destructor 會是個在設計時必須要謹慎考量的點 (特別是在 class 會被繼承以及有 dynamic binding 的狀況時)， stack overflow 上或者 google "virtual destructor" 其實都可以找到相當多的文章說明為何需要 virtual destructor。不過其實大多數的文章會把重點放在 memory leak 上的問題，今天才發現原來這是 undefined behavior

標準上有這麼一句話

In the first alternative (delete object), if the static type of the object to be deleted is different from its dynamic type, the static type shall be a base class of the dynamic type of the object to be deleted and the static type shall have a virtual destructor or the behavior is undefined.

換言之雖然確實是有問題，但如果是 undefined behavior 的話，我個人會認為要假設程式在此時不能正常運作，是個必須嚴格避免的狀況。

[遊記] 臺東三日遊 - 大武觀海步道、三仙臺、知本森林遊樂區、臺東海濱公園、初鹿牧場

這次趁著 5/1 勞動節的連假，跟朋友約了一起出遊
起因也很簡單，純粹是清明連假沒出去玩朋友覺得悶，所以提議了趁著勞動節連假出去散心這樣 XD

這次出遊的地點最後決定去我們兩個都很少去、也比較麻煩的臺東
比較麻煩的原因來自於交通：
臺東的位置不論何種交通工具都很花時間，所以不趁著連假去的話會有大半的時間都花在交通上

基於這段時間我們兩個都很忙，沒辦法仔細的規畫行程，所以最後去的景點都是些比較常見的點
以下是我們這次的行程：

第一天：
8:00 高雄出發 -> 枋寮 7-11 山海關門市休息 -> 臺 9 線南迴 -> 大武觀海步道 (休息兼散步) -> 臺東市區 (中餐兼休息) -> 三仙臺 -> 臺東市區晚餐

第二天：
9:00 臺東市區出發 -> 知本森林遊樂區 (約 30 分鐘車程) -> 臺東海濱公園 ->晚餐

第三天：
10:00 民宿出發 -> 初鹿牧場 (約 30 分鐘車程) -> 高雄

第一天其實大多數時間都在開車 XD
三仙臺是我個人想去的點，所以當時就請朋友讓我安排這個距離其他景點都有點遠的地方
三仙臺位在成功鎮，從臺東市區過去的話車程約 1 小時
所以第一天朋友開了大約有 5 ~ 6 小時的車，中途雖然每隔一小時就會找個點休息一下
不過這樣開還是挺傷神的就是了

 大武觀海步道

 簡單來說就是一個在臺 9 線附近的制高點，由鄉公所 (還是林務局有點忘了) 開闢出來的一個只有長約一公里的步道
步道頂點有觀景亭可以眺望太平洋，入口附近是林務局的工作站，所以也可以在那邊稍作休息
這次會到這邊一來是這邊在剛出南迴不遠處，是個可以暫時停歇的地方
興致來了也可以走一小段步道看看風景轉換一下心情
是個不錯的小景點
不過這次我們只有在林務局工作站前面的停車常稍微休息散步，沒有上去走步道就是 XD

三仙臺

而我個人最想去的三仙臺呢，主要就是這個拉

這個八拱橋連接到對面的那做小島，小島本身是珊瑚礁地形
從找到的一些資料來看，以前好像有相連過，後來被沖刷斷掉後才變成小島
現在只靠著這個八拱橋連接
個人想到三仙臺是因為這邊是少數我很喜歡的海景
可惜這次天氣不佳，有陽光的話整體景色會很有活力、也很亮眼
而且因為我們這次是下午去的，所以本來期望可以看到一些不錯的雲彩 XD
可惜老天不賞臉

小島因為是珊瑚礁地形，除了鋪設的水泥路外，靠近海邊的路都不是很好走
不過島的另一邊有個燈塔，可以上到燈塔處看海景

當時跟朋友在走這一段時發現其實有不少人特地跑到這邊來釣魚
不過這邊如果漲潮或是有海浪之類的其實滿危險的就是了
但是風景不錯，值得走一趟
這邊完整的走一圈大約 2 小時，小客車的停車費是 $60 (沒有門票)
環境也都有在維護，可惜人多了點，特別是海灘附近

知本森林遊樂區

這邊就是一些森林步道 XD
我們這次的走法就是直接每個步道走一遍，剛好繞一圈迴遊客中心

不過這次因為好漢坡步道在維修，所以森林浴步道有一段沒有走
維修的地方是遊客中心到十字路口那段
所以我們最後的路線是
森林浴步道 -> 十字路口 -> 榕蔭步道 -> 景觀步道
值得注意的話這次榕蔭步道上的觀海亭也在施工中

森林浴步道就真的像是一般登山健行會走的路

不過可能之前有大雨、地震之類的，這次路上可以看到有許多的落石
施工中的步道也大多是這個原因在維修中

從十字路口往回看好漢坡步道

 

好漢坡步道約有 300 公尺，平常沒在運動的人應該會覺得很吃力 XD
另外瀑布那段也被擋住了過不去，估計都需要等到施工完畢才能靠進吧

基於朋友喜歡悠哉的行程，這次我們在這邊待了約 5 小時
(9:30 左右到知本森林遊樂區，約 15:00 左右離開)
包含中午吃飯時間，所以其實走得滿悠哉的，邊走邊聊天
不過大概是夏天快到了，蟬叫聲超級吵
聊著聊著就調到了這些蟬到底是用 TCP 還是 UDP 在傳輸訊息
↑ 兩個阿宅在發神經

這邊如果走快一點的話其實大約 2 ~ 3 小時就走的完了
不過因為園區內沒有食物，所以這次我們是買麥當當帶進去吃 XD
出園區後因為知本市區就在附近，所以用餐到是很方便

知本森林遊樂區附近沒有停車場，所以要自己找個路邊的空位停
門票的畫則是全票 $100，優惠票 (軍警、學生 ...) 是 $50

臺東海濱公園 + 臺東森林公園

這 2 個點某種程度上就是大安森林公園這一類的地區
算是當地居民休閒散步的地區，不過佔地非常大
因為遊客也非常多，所以附近有很多腳踏車的出租店
我們這次去有看到大約 5 ~ 6 臺的遊覽車
另外還有不少自行出車前來的散客
所以其實人潮非常多，不過因為我跟朋友都不喜歡人多的地方
雖然是個很適合租臺腳踏車閒逛的點，但最後我們小走一圈後就離開了
不過有看到一個很神奇的國際地標

其實我不懂為何是國際地標就是 XD

本來因為這邊相當大，預計可以逛個幾小時，最後因為人多，大約一小時不到我們就離開了
結果就是我們提早吃了晚餐，晚上沒事做就開車亂繞
然後就跑去逛了大潤發 XDD
朋友因為車子的雨刷清潔劑用完了，就到大潤發買了一小罐回去民宿自己處理
然後還因為兩個人都沒開過汽車引擎蓋，看了說明書後好不容易打開了
結果處理完畢後確發現怎樣都蓋不回去 XDDD
後來朋友打電話回去求救後才知道我們兩個都太秀氣
引擎蓋要很大力的蓋上去，但我們兩個只有輕輕的蓋回去，所以才會怎樣都蓋不上 XD
最後因為太晚了怕吵到人，我們是到了隔天早上才把引擎蓋恢復原狀
以上是由兩個神經病在第二天引發的小插曲

初鹿牧場

這是我們在 booking.com 上訂完民宿後，booking.com 推薦的景點之一
是臨時起意的，加上這邊雖然能簡單體驗銀之匙的生活，不過逛不了太久
所以安排在第三天

當時朋友看到一大片草皮有想躺上去睡覺的衝動 XD

這片草皮其實是滑草場，不過雖然有設備，附近卻沒有工作人員
估計是不打算繼續營業這個項目了

初鹿牧場包含這次的話我應該來過至少三次了
不過這次跟朋友來是第一次去餵食動物，其實還滿有趣的
雖然馬除了你餵食之外都不會理你
袋鼠是根本就被隔絕
牛大概是被太多人餵，有幾隻好像已經吃飽了
除此之外都還挺有意思的

這次也有發生一個小插曲：
我們因為懶得把整捆牧草拆開，所以就整捆牧草送過去給牛咬
結果沒想到牛的力氣超級大，牛一咬我們就整個人被拉過去撞護欄了 XDD
然後最後就演變成我們在跟牛拔河
是個有趣的初體驗

初鹿牧場的門票平日是 $100，假日是 $180
我們這次雖然是在星期一去的，不過因為是連假最後一天，所以還是算假日
小客車的停車費則是 $50
裡面有景觀餐廳賣一些饅頭、關東煮一類的輕食
想吃其他食物的話就必須出去到市區了

不過這邊要來最好要避開星期六
當時我們在紀念品店有問過店員人潮的問題
他說這次星期六有 4 臺還 5 臺遊覽車到那邊
人潮爆炸多 XD

住宿 

這次住宿的地點我們是在 booking.com 上看到米蟲民宿在特價
住兩晚的雙人套房是 $3400
床是加大的雙人床、有提供 wifi 與飲水機
沒有附早餐 (不過附近有早餐店)
沒有專屬停車位 (不過附近巷子很好停車)
因為在巷子內，所以還滿安靜的，我跟我朋友睡覺時都怕吵
所以對於這點很滿意
另外因為是新裝潢好的民宿，整體來說都很乾淨漂亮

民宿地點位在市區跟火車站中間，交通還算方便
不過如果晚上臨時想出門吃東西的話還是要到市區
所以會建議回民宿前預先買好想要的東西

民宿內有提供許多旅遊簡介，我們在房間內還看到他們推薦的市區食物分佈圖
幫我們解決了用餐地點的困擾 XD
也因此對他們的印象還不錯

結論

雖然臺東能逛的地方還有不少，不過基於交通問題，要怎麼規畫其實還是頗頭痛的
這次也有跟一個做旅遊業的老闆聊到
基本上像花東這些地方他比較建議找當地人做司機兼導遊
一來是他們比較清楚有哪些景點可以走，行程怎麼安排比較順
他們也有一些私人景點可以逛、什麼季節有哪些活動可以參加...等等
我想這是個我之後出遊會考慮的方式之一
不過這種方法需要參加的人夠多，費用分擔起來才會划算
但不失為一個好方法

[隨筆] 研究的實驗結果這回事

最近看了許多跟系統架構相關的文章，讓我想到剛升碩一時不知天高地厚的跑去修了虛擬機器這門課，然後因為各種聽不懂大受打擊的事情 XD 當時這門課的期末專題是要想辦法找出 QEMU 中可以改善的地方，然後做實驗說明改善的結果跟幅度，現在想想當初能順利做完這個專題還拿到高分實在是運氣破表 XD

[筆記] 最佳化演算法 (Optimization Algorithm) 的使用與誤用

(這篇的數學式有用到 javascript 來顯示，請不要檔掉 JS，不然顯示上會很奇怪 XD)

最佳化演算法簡單來說就是個搜尋演算法，這類演算法的再做的事情是給定一個問題，定義合法的解集合 (或是空間，英文是 solution space)，再給一個函數用以判別一個解的好壞 (objective function)，這類最佳化演算法就會在解集合中找出符合要求的一個解。

有點難懂？舉個例子：假設我想要再一個 2D 的平面座標中找到一個點使得 $f(x, y) = (x - 5)^2 + (y + 3)^2$ 得值最小，求 (x, y) 為？在這個例子中，solution space 就是 2D 平面上所有可能的點座標，而 objective function 就是 $f(x, y) = (x - 5)^2 + (y + 3)^2$。而最佳化演算法就是針對 "任何" 這樣的問題，找出一個盡可能滿足 objective function 也合法的解給你。沒錯，就是任何這類需要在一個 solution space 中找解的問題都行。所以這類演算法很萬用，但也因此容易被誤用。

[EDA] Steiner Tree v.s. Spanning Tree

一般演算法講到 greedy method 時都會用 spanning tree (生成樹) 當範例，因為 spanning tree 有 O(n log n) 的 greedy method 可以找到最佳解。相對於 spanning tree，某些情況人們會更偏好 Steiner tree (中文好像是翻成史坦納樹)，兩者雖然都是要找一個方法把給定的點連成一顆樹，並且一般都會要求 cost 要最低，但是一個很大的差別在於 steiner tree 允許連線時增加多餘的點，但 spanning tree 不行。有多餘的點可連差異會很大嗎？我想可以參考 wikipedia 這篇的圖例就會知道這差異有多大。簡單的一個結論是 minimum steiner tree 的 cost 是小於、最多等於 minimum spanning tree。

[隨筆] 簡潔而精準 與 冗長但易懂 都幾?

在 FB 上看到朱家安 (哲學哲學雞蛋糕的作者，最近有上去臺灣吧介紹哲學的那位) 的這篇詢問文時，想到了剛開始寫論文的一些事情，當時也被老闆告誡過跟這篇文章想問的事情有關的原則。

我相信其實不只哲學論文，一般學界的論文都會為了要求精準而簡潔而使用了大量的符號去避免冗餘的文字還有錯誤的解讀，因為自然語言很常出現同樣的一個句子可以有 2 種以上的解讀方式。像那篇文章中的 A1、B1 就用了一些代號去代表一個特定的事件、情境等等的現像。相較於 A2、B2 來說，因為可以大量減少文字中所需要的代名詞，而且因為符號所代表的事情是固定的，因此可以減少讀者在解讀上的困擾。比方說，如果文章的某個段落提到 "該事件"、"此方法" ... 等等之類的用詞時，讀者通常必須要能緊緊的跟住文章的脈絡才能正確的理解這些名詞在指涉哪些內容；相對的，姪皆使用代號的話就沒有這個問題，比方說我上面的 A1、A2 只要有看到原文的都會知道我在指甚麼。

當然，依照情境優點也是會變成缺點的：當今天代號過多時，一般人會難以將大量的代號與其所代表的意義迅速的連結，因此下場就會變成讀者會需要常常翻閱每個代號的意義，反而增添閱讀上的困擾與意願。我想應該沒有人喜歡閱讀文章時還需要常常往回翻每個代號的用意吧？就我自己的想法，適量的使用代號有助於理解文章的內容，當然何謂適量就是另一個問題了。我的看法是當作者自己本身都必須往回翻翻看有多少代號然後哪些是甚麼含義時就是個警訊了。另一個可以著力的點是使用代號時也盡量都使用默認常用的符號，別自創新符號。

備註：

有看到推文有人提到數學式子，但我覺得數學式子跟代號又有一點微妙的不同，因為複雜的數學式子會有理解困難的問題，但代號應該沒有複雜的代號這回事 XD

[閒聊] 人際關係

最近因為發生了點事情，所以比較常跟人聊到人際關係這回事，一個可以簡單可以複雜的問題