做逻辑的难点不在于RTL级代码的设计,而在于系统结构设计和仿真验证方面。仿真验证的难点主要在于怎么建模才能完全和准确地去验证设计的正确性(主要是提高代码覆盖),验证速度也是很重要的。验证说白了也就是怎么产生足够覆盖率的激励源,然后怎么去检测错误。
刚去公司的时候BOSS就和我讲,做逻辑的难点不在于RTL级代码的设计,而在于系统结构设计和仿真验证方面。目前国内对可综合的设计强调的比较多,而对系统结构设计和仿真验证方面似乎还没有什么资料,这或许也从一个侧面反映了国内目前的设计水平还比较低下吧。
以前在学校的时候,总是觉得将RTL级代码做好就行了,仿真验证只是形式而已,所以对HDL的行为描述方面的语法不屑一顾,对testbench也一直不愿意去学--因为觉得画波形图方便;对于系统结构设计更是一点都不懂了。到了公司接触了些东西才发现完全不是这样。
其实在国外,花在仿真验证上的时间和人力大概是花在RTL级代码上的两倍,现在仿真验证才是百万门级芯片设计的关键路径。仿真验证的难点主要在于怎么建模才能完全和准确地去验证设计的正确性(主要是提高代码覆盖),在这过程中,验证速度也是很重要的。
验证说白了也就是怎么产生足够覆盖率的激励源,然后怎么去检测错误。我个人认为,在仿真验证中,最基本就是要做到验证的自动化。这也是为什么我们要写testbench的原因。在我现在的一个设计中,每次跑仿真都要一个小时左右(这其实算小设计)。由于画波形图无法做到验证自动化,如果用通过画波形图来仿真的话,一是画波形会画死(特别是对于算法复杂的、输入呈统计分布的设计),二是看波形图要看死,三是检错率几乎为零。
那么怎么做到自动化呢?我个人的水平还很有限,只能简单地谈下BFM(bus function model,总线功能模型)。
以做一个MAC的core为例(背板是PCI总线),那么我们需要一个MAC_BFM和PCI_BFM及PCI_BM(PCI behavior model)。MAC_BFM的主要功能是产生以太网帧(激励源),随机的长度和帧头,内容也是随机的,在发送的同时也将其复制一份到PCI_BM中;PCI_BFM 的功能则是仿PCI总线的行为,比如被测收到了一个正确帧后会向PCI总线发送一个请求,PCI_BFM则会去响应它,并将数据收进来;PCI_BM的主要功能是将MAC_BFM发送出来的东西与PCI_BFM接收到的东西做比较,由于它具有了MAC_BFM的发送信息和PCI_BFM的接收信息,只要设计合理,它总是可以自动地、完全地去测试被测是否工作正常,从而实现自动检测。
华为在仿真验证方面估计在国内来说是做的比较好的,他们已建立起了比较好的验证平台,大部分与通信有关的BFM都做好了,听我朋友说,现在他们只需要将被测放在测试平台中,并配置好参数,就可以自动地检测被测功能的正确与否。
在功能仿真做完后,由于我们做在是FPGA的设计,在设计时已经基本保证RTL级代码在综合结果和功能仿真结果的一致性,只要综合布局布线后的静态时序报告没有违反时序约束的警告,就可以下到板子上去调试了。事实上,在华为中兴,他们做FPGA的设计时也是不做时序仿真的,因为做时序仿真很花时间,且效果也不见得比看静态时序分析报告好。
当然了,如果是ASIC的设计话,它们的仿真验证的工作量要大一些,在涉及到多时钟域的设计时,一般还是做后仿的。不过在做后仿之前,也一般会先用形式验证工具和通过静态时序分序报告去查看有没有违反设计要求的地方,这样做了之后,后仿的工作量可以小很多。
在HDL语言方面,国内语言很多人都在争论VHDL和verilog哪个好,其实我个人认为这并没有多大的意义,外面的大公司基本上都是用verilog在做RTL级的代码,所以还是建议大家尽量学verilog。在仿真方面,由于VHDL在行为级建模方面弱于verilog,用VHDL做仿真模型的很少,当然也不是说verilog就好,其实verilog在复杂的行为级建模方面的能力也是有限的,比如目前它还不支持数组。在一些复杂的算法设计中,需要高级语言做抽象才能描述出行为级模型。在国外,仿真建模很多都是用System C和E语言,用verilog的都算是很落后的了,国内华为的验证平台好像是用System C写。
在系统结构设计方面,由于我做的设计还不够大,还谈不上什么经验,只是觉得必须要具备一些计算机系统结构的知识才行。划分的首要依据是功能,之后是选择合适的总线结构、存储结构和处理器架构,通过系统结构划分要使各部分功能模块清晰,易于实现。这一部分我想过段时间有一点体会了再和大家分享,就先不误导大家了。
关闭
站长推荐
/3
文章评论(0条评论)
登录后参与讨论