作者expiate (彎曲屎殼郎)
看板Soft_Job
標題Re: [討論] GPU加速Transistor層的模擬器
時間Sat Jan 2 04:25:01 2021
我有把你下面推文的兩個連結看了以確定我盡量能理解你的目的。
文中你提到transistor-level與邏輯閘層(gate-level)模擬，
這兩個用詞在你的語境下所代表的意思有點模糊，
我用我的理解以及上篇crossbar的觀點來定義一下：
- transistor-level:
我認為你指的是電晶體電路，也就是layout或是spice
模擬用來跑電氣特性，像是增益，匹配或是SNR
裡面的基本元素就是半導體的材料物理模型(非我專長請專家補充)
- gate-level:
邏輯閘電路，我這邊理解的話就會指cell-based design
裡面的電路表示會由boolean operator或是更複雜的像是
AOI (And-Or-Inverter)，基本上世界上的IC design house
的design flow主要都是走這條。
/*** 我假設你有unlimited resources，要多快有多快的CPU，GPU和memory ***/
然後我只就數位電路作為我的目標，類比電路我是覺得更難就不深入了
基本上transistor-level的模擬我覺得要行得通，必須半導體物理材料模型要準
以及RC (resistance capacitance) model要準。也就是內部電氣特性與外部
routing的特性都要有準確的模型去計算才有可能實現。
如果你只是對於前幾代製程的產品，我猜也許會有已經很成熟及準確的模型可以使用
但我很懷疑是否有公開的資訊你可以拿到，因為基本上這都是foundry的know how。
也許學校有資源可以讓你接觸，或是真的有很老亦或教學的的模型供你使用
假設你有了，其實就是把transistor-level的電路用這些模型表示
然後把彼此的輸入/輸出 接好跑模擬即可。最後在針對電氣數值判斷0/1
這是我覺得最困難的部分，完成後就都是0/1世界了。
Gate-level的模擬跟對應的library有很深的相依性，也就是foundary所提供。
而且所需的電氣特性都包含在每個cell裡的table，所以像是slack或是slew
都可以快速查表得知。而EDA公司提供的sign-off product就是保證他們的驗證
結果跟foundry廠生產出來的晶片會是一樣的。
這就間接的指出其實可以透過gate-level模擬來實現你的目標。
然後這也是為什麼FPGA會作為驗證工具的原因。只要在FPGA功能驗證完成，
剩下的就是跑flow然後tapeout，不用太擔心會不一樣。而且跟模擬比起來快太多了
你可以試試用VCS或是NCVerilog跑個一百萬cycle就可以感覺為什麼唯快不破了
通常IC design house在tapeout之前都可以估自己只能跑幾次模擬。
也就是說bug或是timing issue如果不能在這幾次模擬中解決就等著被X吧
以上是我覺得可以實現你目標的方法，如果真的能reverse回來的話。
下面是我覺得為什麼GPU無法幫助太多的理由。
就我所知，目前沒有EDA公司的產品裡有使用GPU做加速，也許有功能但可能賣不出去XD
大部分都還是仰賴CPU及memory作為計算的主力。
這是因為GPU主要的計算典範是SIMD (Single Instruction Multiple Data)。
拿現今最流行的深度學習做例子，訓練的步驟很明確feedforward，backpropagation
底下的計算主要都是矩陣運算，只是每次要做運算的data不一樣。
回過頭看gate-level電路模擬，如果把電路看成神經網路不也可以用GPU加速？
嗯其實GPU加速電路模擬真的是很容易想到，cuda已經出來十幾年了，所以我想
肯定有人嘗試但是沒成功或是效果不如預期。這也是大家噴這麼凶的原因。
不過我覺得大家太嚴苛了，難得有人正經問問題其實可以多點耐心分享所學的。
所以問題就該是為什麼GPU不能像神經網路一樣很好地加速電路模擬？
我個人思考的結果是：大部分的電路模擬不是線性的
我的思路是把combinational logic電路當作是神經網路，
而暫存器就是神經網路的layer。我能用矩陣來表示combinational logic嗎？
我覺得光是處理gate個數與gate該在矩陣哪個位置我就覺得不好處理
當然你可能有別的思路，可是本質上你還是會受限於GPU計算的本質：
不擅長做複雜(heavy control dependency)的計算。
這也是我覺的目前EDA公司還是以cpu為主要算力的原因。
如果你有興趣，你可以試著朝high performance computing/parallel computing
做更深入的理解。
最後，我只是拋磚引玉吸引炮火。
大家不要為難原po，我其實很欣賞這樣願意花時間苦幹的人了
所以歡迎大家來噴我吧！最好發戰文，大家一起學習！
也期許原po日後有什麼進展歡迎分享給大家。
※ 引述《erspicu (.)》之銘言：
: 不想走冤枉路.... 雖然有找過資料
: 但找到的資料似乎是一些大學教授和硬體大廠的研界成果發表 論文也有
: 感覺有很高的技術門檻 門檻高就算了 主要是怕結果實際上也沒如同想像中好
: 想問看看有沒有已經走過這條路了 不知道通不通或是值不值得
: 模擬器最傳統的做法是cpu指令層的模擬 這種模擬方式好實作
: 但正確度要拉高到一個水準 就需要很高代價
: 尤其是cycle accurate的模擬問題
: 要100%正確 就要層邏輯閘層去模擬運算結果
: 但邏輯閘層運算量遠大於指令模擬 主要是因為邏輯閘層運算都是同時間平行的
: 這種特性很適合GPU 如果像是紅白機MOS 6502的話邏輯閘數大概有4千5百多
: 目前看到用一般cpu去計算邏輯閘模擬計算 非常多秒才能算出一張frame
: 用指令集模擬的方式 每一秒可以算出好幾百張frame 差異非常巨大
: 不知道用gpu來模擬FPGA那種陣列 先不提有沒有商用價值
: 效率能不能提升到實用價值 不知道有沒有人公司剛好有做過這研究
: 之前移植專案做到一半 想研究一下改用GPU平行處理來處理邏輯閘模擬
: 寫一寫 還沒到改寫的部分 還在JS PORTING到C#的階段就丟著
: 如過是死路 就算了
: PS.我的理想是靠GPU模擬一張FPGA 拆晶片用放大鏡把內部邏輯描繪出來
: 然後燒到FPGA上 有一些骨灰迷是有在做這事情
: 像這網站 http://www.visual6502.org
: 但目前還沒看到靠GPU模擬FPGA 把電路燒進去的
: 現在還在移植 http://www.visual6502.org/JSSim/index.html 到C#版本
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 98.207.101.195 (美國)
※ 文章網址: https://webptt.com/m.aspx?n=bbs/Soft_Job/M.1609532709.A.E5C.html
1F：推 mmonkeyboyy: 他其實想做的就是gate level functional simulation 01/02 07:59
2F：→ mmonkeyboyy: 一般做完synthesis 再拿去的那一道 01/02 07:59
3F：→ mmonkeyboyy: 啊.... 免費的話拿個什麼iverilog都能跑的 01/02 08:00
4F：→ mmonkeyboyy: 那個速度就慢到爆炸而已 跑跑小顆的還可以 大顆那 01/02 08:00
5F：→ mmonkeyboyy: 個記憶體爆炸狀態是要跑個鬼....更別提gpu本身架構也 01/02 08:02
6F：→ mmonkeyboyy: 不太適合做要cache的計算@_@~ 解數值的還可以 01/02 08:03
7F：→ mmonkeyboyy: 做functional的不用一堆fpu (如果不解 timing) 01/02 08:04
8F：→ mmonkeyboyy: 做模擬器要做全系統的的 這個連cycle-accurate的 01/02 08:05
9F：→ mmonkeyboyy: 都算慢的@_@~ 更別提更往下的 .... 有時gem5 qemu 01/02 08:07
10F：→ mmonkeyboyy: 這種上層一點的跑個應用下去都可以等死了 01/02 08:08
11F：推 mmonkeyboyy: gate-level 講的是說你synthesis 後有 and or等 01/02 08:12
12F：→ mmonkeyboyy: 出現後再去跑 到不一定是要有tech file 01/02 08:12
13F：→ mmonkeyboyy: transistor-level 就是nmos pmos 下去 有lib的 01/02 08:13
14F：→ mmonkeyboyy: 這個其實有 gpu 加速了@_@~ (沒用過 不知效果) 01/02 08:13
15F：推 comaniac: 同意對於目前EDA tool 很少用GPU加速的分析。不過不要 01/02 09:02
16F：→ comaniac: 說GPU，目前CAD tool 連CPU 平行運算都不是用得很好了， 01/02 09:02
17F：→ comaniac: 距離用加速器還有很長一段路要走 01/02 09:02
18F：→ erspicu: Transistor和Gate level稱呼有時候在網路上會被混用 01/02 12:55
19F：→ erspicu: 而我的概念的確是GATE LEVEL稱呼比較正確 01/02 12:55
21F：→ erspicu: Visual Transistor-level Simulation of the 6502 CPU 01/02 12:57
22F：→ erspicu: 實際上我看它專案sources是gate-level關係的模擬 01/02 12:57
23F：→ erspicu: 程式裡面有一些節點關係和連接關係的定義檔 01/02 12:59
24F：→ erspicu: 以後如果用英文 我會用GATE-LEVEL稱呼避免混淆 01/02 12:59
25F：推 Neistpoint: Gate level simulation 的最小單位是cell library 01/02 13:53
26F：→ Neistpoint: 裡的 邏輯閘，每個邏輯閘對應到一個或多個transis 01/02 13:53
27F：→ Neistpoint: tor. 所以 virtual transistor 這樣的命名是沒錯的 01/02 13:53
28F：→ Neistpoint: 。 01/02 13:53
29F：→ freef1y3: Gate level 如果連flip-flop都拆成gate了,那就算只是 01/02 14:33
30F：→ freef1y3: 做functional 也是要考慮timing了吧? 01/02 14:33
31F：→ freef1y3: 不然連shift register都沒辦法正確模擬 01/02 14:37
32F：→ MT6797: 看了這篇才看懂原PO想做什麼XD 01/02 14:44
33F：→ MT6797: 硬體運作關鍵是同步，他把同步解讀為平行這就有問題了。 01/02 14:48
34F：推 mmonkeyboyy: FF自己就是一個gate (實做上可以當trigger 當記憶體 01/02 15:02
35F：→ mmonkeyboyy: 更新資料的起終點 這有點cycle accurate的概念 01/02 15:03
36F：→ mmonkeyboyy: 在dv的fv中 或是emu中這是一個方法簡化transition 01/02 15:04
37F：→ mmonkeyboyy: 達到降低資料量提升速度 所以不用timing也行的 01/02 15:04
38F：→ mmonkeyboyy: SCM三個做DV的都有這個功能(應該說沒timing時就這樣) 01/02 15:06
39F：→ freef1y3: 原來如此 感謝回答 01/02 15:14
40F：→ Holysml: 關鍵是dig需要control多於數值運算;真要加速也是cpu farm 01/02 22:42
41F：推 SkyFluid: 更新一點, EDA廠是有用gpu加速的,如cadence/rocketick 01/03 01:49
42F：→ SkyFluid: 但在實務上這個做法會有不少問題,所以並沒有大規模採用. 01/03 01:50
43F：→ mmonkeyboyy: 做spice的才有在商用 我朋友開的公司才剛浮出來了 01/03 04:26
44F：→ javatea: 你人真好, 台灣放假應該很多事情做啊 無聊才去回那種文 01/03 13:19