[C++] covariance / contravariance

covariance / contravariance 是跟繼承有密切關聯的產物，而且與語言規範有關。然而這邊雖然要講這兩項性質，實際上 C++ 的語言規範上是 invariance，因此若要達到類似效果，在 C++ 必須要在類別設計時就加以考量。

 covariance / contravariance 簡單來說，就是在特性情況下，子型別與父型別之間能否接受互相轉換。這個特定情況舉例來說，就是放在 container 內的狀況。

[食譜] 簡易版番茄香菇菜飯

新分類，用來記錄曾經煮過的菜的方法

---------------------------------------------------

嘛，簡易版的原因在於是直接用電鍋的懶人煮法，所以有很多可加強的地方 XD
因為不想一次煮太少很難備料，所以都是抓 2 ~ 3 人份

[C++] A Polygon to Rectangle Conversion Tool

偶然間需要用到把直角多邊形 (rectilinear polygon) 切割成數個互相不重疊的矩形 (沒有其他最佳化要求)，因為大多數找到的方法有最佳化的需求 (像是用最少的矩形或是舉行要盡可能大之類的)，所以實作起來都還挺煩的，不過今天偶然間找到一篇方法超簡單的論文，雖然有點久了，不過已經滿合乎我需求了，就把它實作出來了

我已經放上 github 了，連帶相關的論文跟方法簡介
https://github.com/shininglion/rectirization

[EDA] Pin Accessibility Evaluation Model for Improving Routability of VLSI Designs

其實這就是我在日本一個月做出來的成果。探討的是 standard cell design 的 pin accessibility 的影響

[EDA] Negotiation-Based Maze Routing 的部分困擾

Negotiation-based maze routing 可以說是現在 router 的基礎架構了，這個主要因素來自於當有許多 Net 要共同競爭相同的路徑以便縮短線長時，這個機制會讓競爭激烈的地區有相對大的成本，讓有其他選擇的 Net 可以轉而選擇相對較差但仍能完成繞線的路徑。當然，這種機制聽起來很單純美好，實作起來時總是會有其他許許多多衍伸的問題

[EDA] Transmission Gate (傳輸閘) - Logic Switch using CMOS design

目前數位 IC 設計上所用到的電晶體分成兩種型態 P-type MOSFET (P-MOS) & N-type MOSFET (N-MOS)，兩者在數位 IC 設計上的功用都是當做開關 (switch)，用以控制電流是否能通過。另外由於 MOSFET 本身的特性：電壓要低於一定閥值 (threshold voltage) 才能導通，同時這個閥值不是固定的，會受到源極 (source) 訊號以及汲極 (drain) 訊號的電壓影響 (好像是叫 body effect，先進製程應該會有更多會影響 threshold voltage 的問題)，因此 P-MOS 跟 N-MOS 在啟動開關跟傳輸電流上各有差異：

[C++] boost::geometry::overlaps 的檢查與預期不符

目前的程式因為需要大量的多邊形操作，所以現在是直接用 boost::geometry 來做相關的運算，其中很常用的是要檢查 2 個多邊形是否重疊到，在 boost::geometry 中有提供 2 種操作：intersects & overlaps，兩者差異如下：

• intersects：2 個多邊形只要有 "一個點" 重疊到就算有相交
• overlaps：2 個多邊形必須要有重疊到 "一塊面" 才算

所以如果今天要檢查 2 個多邊形是否只有重疊到 "一條邊" 就必須自己想辦法兜出來，但這不是這次的重點，這次的重點在 overlaps 有另一個隱藏的細節：

其中一個多邊形不能完全包含住另一個多邊形

這種情形下，overlaps 的回傳值是 false，然後我 TMD 踩到這狀況結果問題找超久阿阿阿阿

舉個例子，下面這隻程式的 p1 被包在 p2 裡，但是這情況 overlaps 的回傳值是 false (也就是沒有重疊)：

#include <boost/geometry.hpp>
#include <boost/geometry/geometries/point_xy.hpp>
#include <boost/geometry/geometries/polygon.hpp>
typedef boost::geometry::model::point<int, 2, boost::geometry::cs::cartesian> point_t;
typedef boost::geometry::model::box<point_t> box_t;
// point should be in clockwise order
typedef boost::geometry::model::polygon<point_t> polygon_t;

int main()
{
    const polygon_t p1 {{{0, 0}, {0, 2}, {2, 2}, {2, 0}, {0, 0}}};
    const polygon_t p2 {{{0, 0}, {0, 3}, {3, 3}, {3, 0}, {0, 0}}};
    printf("is overlap? %d\n", boost::geometry::overlaps(p2, p1));
    return 0;
}

boost geometry 的實作從 document 來看應該是有遵照一定的規範在處理，不過我到現在還沒仔細看過，搞不好那規範裡面有一些跟一般預期不同的結果...Orz

[EDA] Routing Resource Estimation & Planning - Pattern Routing

• Resource Estimation: 重點主要是放在估算可用的 routing resource

• Resource Planning: 重點偏向粗略規劃 routing 的結果

其實這兩者現在很少有人分開來講，原因在於 planning 的結果先決條件就是估算可用的 routing resource 這一步算得有多準；相對的，estimation 做得再好，沒有 planning 就沒有意義，因此就我的經驗來說，目前沒有人會特地把這二步分開來講，而是提出一套完整的方法同時包含這二個步驟。這次就先整理最簡單、也最常被使用的一個方法：pattern routing，概念是來自於 [1] 這篇論文。

[EDA] Routing Estimation / Planning - 前言

不知道大家有沒有玩過 (或看過) 一個遊戲叫做 "Flow Free"？遊戲畫面長得像下面這樣

這遊戲簡單來說就是給你一堆點且有各自的顏色，目標就是把相同顏色的二個點連接起來，次要目標則是盡可能的填滿所有格子 (所以會看到有些線, ex: 白色的線, 很明顯地有更短的連法)，限制則是線段之間不能重疊 / 接觸到。

[隨筆] 日本短期研究一個月的簡單紀錄

說到博士研究生涯，完全沒出過國的機率很低，國內的大學也有機率會提供碩博士有短期出國研究(不是交換學生)的補助讓你可以出國深造。雖然這個補助說實在的比起國外的生活費還有大學註冊費之類的實在不夠看，其實教育部也有所謂的千里馬計畫是補助你長期出國研究 (我印象中是至少要 10 個月) 的經費，而且這經費其實不低，一個月有 5 萬台幣供你使用，說實在的就算是不夠用還需要自行貼補，但這也很大程度的降低負擔，其實是真的滿不錯的 (雖然我個人對於那個申請流程感到十分繁瑣與厭倦...)。我當初會想念博班也有一小部分 (真的是滿小的一部分...) 是因為可以有常常出國的機會，就到目前來說，確實有達到我當初的期望。

話是這麼說拉，出國幾次之後對於出國的感想除了可以看到一些在臺灣見不到的東西之外，對於一個生性就怕麻煩的人來說，出國還真的是麻煩到有剩的一件事，特別是窮學生想出國必定得想辦法生出補助之類的，看到那些補助辦法的規定什麼的，真的會想把各種知道的髒話通通罵出來...well，所以其實現在對於出國沒啥感想，大多剩下把事情盡快地辦完之後回國懶散的休息當阿宅 XDD

這次會出國短期研究一個月起因來自於老闆到日本學者參訪 2 個月後，在那邊接洽的實驗室談好了一個計畫。在講這個計畫前，先來簡單講一下日本那邊的教授制度：日本那邊的制度跟臺灣差異其實很大，首先教授的名額是有限制的，要升上教授前必須要先有教授退休；其次，副教授還有助理教授這些都會掛在一個正教授底下，而這些由同一個教授率領的團隊會共享所有資源。印象中，在日本那邊的教授主要負責的會比較像是接洽計畫、找實驗室的經費與研究方向之類的，底下的副教授跟助理教授大概就會是負責管理實驗室的運作。像我這次去日本，管理實驗室機器的就是一個副 (?) 教授。所以他們那邊一個實驗室其實都會挺大的，運作方式也會跟台灣這邊的實驗室差異相當大，研究主題也因此會相對廣泛。

在上一段提到的那個計畫，當初老闆跟那邊的實驗室接洽完之後，回國後老闆正式的找了一個碩班的學弟跟他們開始合作，合作的方式是他們那邊會提供他們在設計上遇到的困擾以及想要解決的方案；而我們這邊則是根據他們的問題將解決方案自動化。說穿了，其實可以把他們那邊當成 designer，而我們這邊就是設計 CAD tool，我們要做的就是把他們本來必須反覆人工處理的事情通通自動化，如此而已。聽起來好像很簡單，就是一般 EDA 在搞的事情，不過我一直覺得這個領域最麻煩的地方就在於你很難避免去觸碰到業界的商業機密所衍伸的各種保密措施。像我們這次做的計畫，如果不拿業界實際的製程資料來做，那麼整個研究計畫會變成問題過度簡化，得到的結論也會因此不切實際無法實際運用；相對的，因為用到了業界實際的製程資料，這就導致要合作、重製與驗證實驗上窒礙難行。沒錯，這就是當初我們要合作時遇到的最大困擾：我們無法存取他們的製程資料，所以有些他們設計上遇到的困擾我們這邊無從了解並處理；如果只套用我們這邊能存取的製程資料來設計，兩邊溝通上常常會出現雞同鴨講或設計處理上無法套用的問題。畢竟，不同公司的製程資料如果一樣，我看那些公司彼此之間就先開始搞保密防諜跟上法院了，我們要拿來做研究也必定通通暫停 (攤) 尼們看看當初梁孟松跑到三星後弄出了多大的風波就知道 XD。

結果，當初搞了幾個月之後，整個計畫宣布終止，因為完全弄不下去 XD，老闆也因此在前陣子寫了個計畫準備去日本來個一個月的超短期研究，目的就是要把當初這個不得不中止的計畫弄出點成果並畫下句點。然後因為這計畫的研究方向跟我目前的研究有關，所以我就被抓來了 XD 如果要問我說這次短期研究有甚麼最重要的心得...大概就是這個吧：

千千萬萬不要欠技術債，不然他哪天陰魂不散的找上你時你會死得很難看 (咚—)

以上，切身之痛...所以當你欠下技術債時，趕快丟給下一個倒楣鬼就好 (欸)

不過這次來日本剛好遇上櫻花季 (雖然比往年慢了不少) 以下有圖有真相

這張是在我宿舍前面的櫻花樹，剛好在我住的最後一周開始開花

這張是在大阪城公園拍的，櫻花樹下的步道還真的滿有 fu 的