cmodel模拟器开发
作者:互联网
cmodel模拟器开发
对于一个公司来说,产品的设计周期就是生命线,一般来说都会在设计功能级仿真的c-model后直接转向RTL设计。
在目前的技术下,做cycle-by-cycle的设计和直接RTL设计的时间,感觉是差不太多的。nVidia同时维护functional and timing 的simulators。
第一个model是否能跑流行的game也是一个问题。
需要快速的开发,debug,不然就又到下一代产品了。
维护一个好的team,做算法,做架构的,做电路的,做实现的,互相讨论,互相了解彼此的领域。
用什么语言倒是无所谓,在大家讨论出结果时,各个工作组都有实现方案了,而且每组都可以用自己最熟悉的工具。
对于一个公司来说,产品的设计周期就是生命线,一般来说都会在设计功能级仿真的c-model后直接转向RTL设计。
对于GPU性能分析(Graphics Pipeline Performance Turing),就不一样了。用RTL来跑的话,不但占用License,而且比较耗费时间。对于一个不是特别大的公司来说,License还是比较贵的。如果RTL跑起来比较浪费时间的话,做性能分析的,一定会多开几个不同参数的RTL同时运行,一般来说,开个七八个任务同时运行测试场景是很正常的,如果一个组有好几个Performance Turing工程师,就要占用好几十个NCverilog License,而且还要占用相同数量的CPU时间。除了NV/AMD/Intel这种不在乎license数量的公司以外,小公司里别人还干不干活了。
Cmodel又不带时序,需要一个带有时序的Cmodel,对于公司内部某些特定需求的团队(比如性能调优相关的项目组)还是有意义的。
如果只是function 验证,可以用 verilator 来跑, 可用 systemc 来加速模拟 verilog 的行为, 之后再根据synthesis RTL 后的結果,分析出 critical path 部份. 就可以根据這结果修改 RTL verilog 再模拟. 其实就是不断的模拟验证..... ps: 不过也先要有前端的design 跟验证。
如果只是function 验证,可以用 verilator 来跑, 可用 systemc 来加速模拟 verilog 的行为。
对verilator很久经验么?跟别的工程师说过verilator,可能更相信carbon,更愿意花10w块美刀去买license……。
在传统的HW Design上,不外乎通过verilog 验证,跑跑RTL 的Function Check, 等Function 确定好后,用Design Compiler 转出Gate Level, 在验证Time 是否满足 setup time and hold time, 如不符合,就改Design,或者是改变設定的 constrain,就一直不断的Try and Test。相对的,会花很多时间在Debug上面。软件不像硬件一样,可以由断点分析,用software break 的方式,做Inside Register的 Debug。除非在HW中加入JTAG的机制。用ICE 来Emulator HW內部的flip-flop所暂存的值, 但在HW Design 初期, 根本不可能会把JTAG做进去,能不要每天加班就好了。在初期只能用NC-SIM 来模拟,看看Waveform写些TestBench去测。这样一来一往就话费了不少时间,如果能够用更快速的验证方式,通过软件来验证硬件的结果, 就可以减少在Design所花费的时间。
性能模型用处不大。
在设计中考虑性能的地方主要有:
1.设计方案的时候,这时候是要把性能计算好的。如果这里没有计算好,后期就麻烦大了。
2.开发时候,严格按照方案来做,可能会有一些方案没有想到的地方,及时反馈,修改。这时候按照方案里面的计算框架应该对开发有指导意义的。
3.测试的时候。在功能测试完毕后,但是这时候对于性能已经几乎没有什么能改进的了。
所以做方案的时候一定要把性能计算好。越到后期修改的可能性越小。
在上面三个阶段中,第一阶段主要是计算(计算可以用模型来仿真,觉得得不偿失,超大逻辑除外)。第二阶段是没有时间和精力来做性能仿真的。第三阶段应该fpga/asic已经完成了,性能仿真模型其实没有什么意义了,在实际的芯片上测试,比仿真模型要真实/快速/实际多了。
随着GPU可编程越来越灵活,人工计算的静态性能评估已经不那么有用了。很多时候性能和程序的特性相关,必须要针对主流应用来做优化,没有统计的方法,很难量化这个数据。只有拿到了主流应用的量化数据,才能优化和分配流水线上的资源。比如大多数应用对于“存储器访问”和“数据计算”比例是平均访问一次存储器后计算50条指令,那就要分配计算资源和缓存资源的比例,包括考虑到Cache尺寸多大才能满足一个合适的命中率,要支持多深的Non-blocking Cache访问才能隐藏延迟,并且不至于耗费太多的带宽,而这些都和应用的特性有关。如果这个比例在未来的主流应用中改变了行为,那还要变换参数。这个通过手工没有办法算出来,只能实际测试。
如果非常容易手工计算的话,那么像NV这样的公司,有上千个GPU架构师(GPU Architect)。设计的第一代卡性能也是非常不靠谱的,往往要等到第二代第三代卡的时候才能有一个比较满意的设计,包括功耗和性能权衡。而这种优化离不开性能模拟器。
对很多GPU供应商来说,同样如此,比如客户需要更高性能的芯片,那好,为了使性能提高一倍,需要把流水线宽度(注意是宽度不是长度)增加4倍,并且显存带宽(bandwidth of video memory)增加数倍才可以。但是这里面就有一个落差,就是性能不能随着并行度的增加线性增长,这里面必然有瓶颈。那此时怎么办?怎么调整流水线的负载平衡(load banlance),靠手算么?流水线上每一级都是程序控制的,如果不分析程序在不同Stage都耗费了多少Cycle的话,那怎么知道哪里是瓶颈呢?首先,第一步要找到性能瓶颈,然后第二步才是改进。
怎么找?用手上的ASIC来找性能瓶颈,也许可以,但是这需要足够数量的performance counter,这个在设计制造之初有么?现在就算假设有,那么第二步,怎么知道那种改进方案是最优的呢?可能需要不断地尝试,比如,增加或者减少不同片上资源的数量,比如某个Cache的尺寸,某个FIFO的深度,或者是BUS上某个Local memory的容量,等等。从而调节流水线的负载平衡。而ASIC都是定制好的,怎么调?怎么观察性能的改变?难道用加速器么,加速器的编译时间本身就是很长。也许可以增量编译。但是加速器大家都在抢,首先要保证功能验证的需求,可能分给性能调试组的机时都非常少了,根本不够用。 如果在服务器上面仿真还要占用License,会导致很多麻烦,仿真时间长不说,而且七八不同参数尝试的实例同时跑,性能调试组N个人一起这么干,别人就别干活了。
性能模拟器就是为了完善这个而产生的,第一代产品只是为了抢市场,而第二代和第N代等后续产品,才是真正成熟的产品。而凭经验给参数的做法,在可编程器件上不那么好使,虽然不到和拍脑袋的那个级别,但是也是不够用的。架构级别不优化,结果产品出来功耗性能差,上面要发飙的。所以,做精细的性能模拟器,也是不得已而为之的事情。因为这是真正的可编程设备(programmable device),不是一个视频编解码那种不可编程的专用集成电路设计(ASIC Design)。
之前以为靠流片来改进性能很笨拙,一个MP4的公司,改进性能/验证性能改善结果的做法是频繁流片,疯狂的时候一个月流一次。
(又是一个不用C Model来改进性能的例子)
不过,比较好奇这种做法:
1. 每次流片的成本大概多少?
2. 对项目来说,实际效果如何?(毕竟理论上ASIC的可见度,没有C Model可见度高,也许通过分析算法,在ASIC的某些关键点做performance统计)。
首先,直接silicon级别的性能统计?那需要插很多性能计数器(performance counter)吧,不然怎么观测呢?分析方法是什么呢?
其次,投片(tape-out)一次最快流程也要1个月,但是这需要大晶圆厂才可以,比如SIMC或者TSMC,小的成本更低的晶圆厂往往都走三个月的流程。
以前还有门海(gate-sea)技术实现的投片,就是在衬底上吧晶体管都预先排列好,然后在没有客户的情况下预先生产,最后不同的客户只需要在预先准备好的衬底上,光刻出来不同的金属连线就可以了(就好像蛋糕店预先生产好蛋糕坯子,不同的客户就挤出来不同的奶油图案一样),所以流程更快(比一个月还要短),不过貌似在深亚微米级别好像没见过了,是不是因为线延迟增加的缘故。
最后,投片成本,5平方毫米的MPW一般五万到十万,能到0.18个工艺吧(不知道最近行情怎么样)。不过还有封装费用(如果管脚不多,可以直接封装在版子上降低成本),
另外,觉得如果需要2次MPW投片才能调整出来一个好的性能,那也就是2个月时间。有两个月时间,都可以直接调好C model性能模拟了,从而改进RTL了。并且方法学可以集成到下个项目中,好处多多。除非大这个项目组身兼好几个项目,所以这样做是为了省时间,破财免灾,不然老板就冤大头了。
性能模拟器能不能得到正确的书性能分析数据,这个在CPU性能模拟器这个问题中很常见。的确是需要按照需求来设计。
比如,对于传统的OGL ES1.1来说,没有复杂的数据回路,流水线基本都是生产者-消费者关系,那么首先对于一个新项目而言,要解决的问题就是在这些Stage 之间插入多少深度FIFO,才能做到流水线复杂均衡(load balance),这就是需求。像之前Cqq大牛描述那种私有框架,在基本的需求就在于此。
而现代GPU越来越复杂,如果用学术名词描述GPU架构的话,基本上可以说是“多核心的多线程向量处理器阵列”,不再像传统图形流水线,大大增加了性能模拟器的设计难度。从复杂性角度来说,的确在这种情况下就应该把性能模拟器和功能模拟器完全分开做。但两者不见得是文件级的数据传递。从项目进度的角度考虑,还是推崇由性能模拟器调用功能模拟器的方式。对于一个粗粒度的性能仿真来说,也许这需要在功能模拟器中多放置一些bool变量,这些只能标志位用于告诉性能模拟器,那些运算功能被使用到了。
最近考虑这个问题,主要是针对一款芯片更早的性能调整和性能分析(performance analyzing & tuning)。在传统的固定功能图形水流线(fixed function graphics pipeline)上,可以依照简单的带宽计算公式和经验来设计芯片,而不需要更多的测量流水线之间是否满足于性能平衡。因为在固定管线下,图形API调用程序的行为变换是很有限的,而存储器带宽和固定功能的计算公式就可以获得很好的预估精度。
但是在当前GPGPU的角度越来越近的情况下,这一情况发生了很大变化,面向通用计算(或是说流计算)后,无论是OCL还是Shader程序行为不再像固定功能图形流水线API那样的死板,变得非常灵活,从而使得可编程图形流水线(programmable graphcis pipeline),使得程序可以写出千变万化的效果。这导致传统的靠手工静态计算的性能分析,变得不再可靠。必须更细致的更量化的考虑当前大部分程序的行为,以及未来可能出现的程序行为,从而决定如何改进GPU,如何分配片上门电路资源(resource of gate-level circuit on-chip)给不同的流水线阶段(pipeline stage)。这就使得设计一个性能模拟器,在编写下一个版本的RTL之前是非常有必要的事情,对于IP供应商来说,这也有助于在制作好RTL释放包(release package)后,针对客户不同应用,给出不同的IP配置建议。
但是这里又有一个新问题,就是传统来说,在设计GPU C-Model的时候一般都不会加cycle信息在上面,传统的GPU c-model主要就是作为验证流程(verification flows)中黄金参考模型(golden reference model)来使用,验证平台(testbench)只需要针对不同的流水线阶段(或是模块)写出来不同的无周期行为级模型(或是硬件算法模型)就可以,不需要带有任何周期信息。所以,一般来说当前部分GPU设计公司都指挥维护一个不带有周期信息的GPU c-model。但是这个cmodel只能做功能仿真(functional simulation),并不不能做性能仿真(performance simulation)。
对于一个公司来说,产品的设计周期就是生命线,一般来说都会在设计功能级仿真的c-model后直接转向RTL设计,而不是在进行一个时钟精确(cycle-accurate cmodel)的性能模拟器设计,在产品进度上这是不允许的。而且维护两个c-model这也会导致公司运营的成本增加,并且项目管理的难度也大大增长!所以需要一个快速的性能模拟器方案。使用功能模拟器跟踪(trace)出来每个GPU独立模块模块,所接受到的图形软件程序的代码流,比如那些三角形触发了切割(cliping)操作哪些触发了剔除(culling)操作。这个trace出来的信息被送入一个单独的性能模拟器,这个性能模拟器不能执行程序,只能根据trace出来的代码流来积累时钟周期,从而计算出来流水线延迟和瓶颈。这样,就可以在原有的c-model上利用原有的资源来最小程度上获得一个早期的性能分析数据。并且把管理和维护成本做到最小。
这个性能模拟器可以使用systemc来实现,就是相当于一个大的计数器,针对不同的执行来累加不同的时钟消耗,而不需要填写任何与时序和执行流水线无关的 无关的功能算法。systemc的TLM可以很容易的实现这个功能。
标签:RTL,性能,cmodel,开发,设计,流水线,GPU,模拟器 来源: https://www.cnblogs.com/wujianming-110117/p/14798009.html