# Physically-Aware-HLS-DF 備忘錄

### Abstract 2

+ 高階合成，也就是HLS因為只需要處理behavorial level的東西，tool就會根據指定的需求自動生成RTL，可以省下很多設計時間。
+ 但是在後端的IC開發也就是佈線的時候會遇到Routing congestion（繞線壅塞）的問題（等一下再提），這個問題通常會需要回到前端去解決，就需要花很多時間。所以就會想要在最一開始的HLS就解決這個問題，但是很難一開始就被看出來。
+ 所以這篇paper提出了一個方法，就是在HLS的時候就去考慮Routing congestion的問題，這樣就可以省下很多時間。這個方法還有一個好處，就是在大部分情況下可以省面積還有時間。

### Intro 2
+ Routing Congestion，在之後會簡稱RC，是指過多的線路想要穿越某區域，但是該區域沒辦法容納的現象。
+ 如果沒有辦法容納，那就只能讓線繞更遠的路，最後會造成delay的增加，這樣就會影響整個電路的效能。
+ 圖片是有一個R.C.也就是壅塞的區域，可以看到他cell利用率特別低，因為都是線所以cell根本擺不進去。

### Intro 3
+ 因為會影響整個電路的效能，所以RC一直是很嚴重的問題，但是在傳統的RTL設計流程中，都只能到後端，也就是佈線的時候才會發現。這樣就會花很多多餘的時間回到前端解決。
+ 可以看到右邊，虛線以前是前端，以後是後端，現在引入了HLS，也就是高階合成之後，設計的過程離實際硬體更遠，這個問題就變得更糟。
+ 現在其實有Physically aware邏輯合成工具可以解決RC的問題，但是他只是用於一開始就用RTL的設計上，但現在都是從HLS，開始，所以這個方法就不適用了。
+ 現在其實也有一些方法可以在HLS的時候就在嘗試解決RC，但這些方法都只有在真正Physically implementation之後用feedback去做調整後重新生成設計，不是很有效率。

### Intro 4
+ 研究者發現許多RC問題是在HLS之前，也就是在用SystemC做系統設計的時候就產生的了。
+ 同時，也有許多問題是之後HLS的directive，也就是指令產生的。這些指令包含常見的pipelining, loop unrolling, function inlining等等。
+ 但是，以現有的HLS tool來說，沒辦法在HLS的階段就處理這些問題。
+ 我們可以看看右邊這張圖，這是一個systemC產生RC的例子，可以看到上面有一個switch case，是看index的值決定下面陣列引數的start end，雖然我們現在都知道這是個很爛的coding style，但是原作者說這是從實際的系統設計來的。

### Intro 5
+ 那為什麼會產生RC呢？因為在產生RTL的時候不知道要指定到陣列的哪個引數，也就是不知道要存到第幾個register，於是就只好套三個超大的demux。這種超大的demux呢，因為針腳非常密集，所以很容易就產生RC，線路太多了。

### RCAHLSDF 2
+ 這篇paper提出了一個新的方法，叫做Physically Aware HLS Design Flow，也就是在一般的HLS Design Flow中加入了兩個新的步驟。
+ 這兩個步驟分別是在RTL生成之後、邏輯和成之前先做一個Congestion Detection；如果發現有壅塞現象，再回到Hardware Refinement或是High Level Synthesis的階段去做一些調整，稱作Congestion Improvement。

### RCAHLSDF 3
+ 首先要介紹他們怎麼做Congestion Detection。研究者發現絕大部分的RC都來自非常大的MUX還有DEMUX。
+ 所以他們就想了一些辦法，從SystemC階段就開始做追蹤。高階合成生成RTL之後，如果發現RTL一些部件會造成Congestion，就開始追本溯源去找是SystemC的哪個部分讓這個部件產生。

### RCAHLSDF 4
+ 這個是他們Congestion Detection的方法，他們把HLS Tool和Physically Aware Logic Synthesis Tool包在他們的Package裡面，這個Package會生成Report，給後續的Congestion Improvement使用。

### RCAHLSDF 5
+ 這個是找尋造成Congestion的MUX和DEMUX的psuedo code，他們會在physically aware logic sythesis tool跑完之後把congestion area的cell找出來，然後再把經過這些cell的path列出來，再把經過這些path的MUX列出來，並印成報告。

### RCAHLSDF 6
+ 這個就是Congestion summary，除了一些統計數據外，還可以看到水平方向和垂直風向的Congestion Overflow，通常要在1%以內才能叫做沒有壅塞。另外，Congestion還有另外一個指標，就是total net length。如果異常的長，那可能就是有Congestion

### RCAHLSDF 7
+ 除了印出summary以外，他們也會印出MUX的資訊，甚至告訴你這是在你寫的systemC的哪個檔案的第幾行code產生的，方便你去做修改。

### RCAHLSDF 8
+ 在經過Congestion分析之後，就需要Designer自行決定怎麼修改。稱作Congestion Improvement。
+ 現有的Improvement包括重新在高階合成階段做reallocating registers還有rescheduling，可是這些效果有限，因為一開始硬體的系統模型就做爛了，再做改善當然沒有什麼用。

### RCAHLSDF 9
+ 所以，就要從之前提到的Congestion報告去做修改。下面這個是之前那個Coding style很爛的人，經過修改後的結果。我們可以看到do while loop不見了，改成for迴圈在switch case裡面，這樣引數start和end就很明確，在做RTL的時候就不會有看到剛剛的巨大的DEMUX產生。

### RCAHLSDF 10
+ 除了改剛剛的SystemC code以外，還可以透過改高階合成的指令來改善Congestion。下圖是一個例子，把原本HLS tool的使用最少register的選項改成使用最少的MUX，congestion就幾乎完全解決了。當然，因為register增多，需要付出多19%的面積做代價。

### ER 2
+ 這是他們的實驗結果，可以看到他們的方法在congestion overflow上都有很大的改善，變成幾乎是0。
+ 另外，還觀察到net length ratio都小於1，cell area ratio也幾乎都小於1。剛剛說有面積代價的是model 2，也犧牲不多。

### Thanks
謝謝大家。