作者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/cn.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