极说・IC圆桌派复盘笔记之闲话DV

说实话，我们都希望疫情可以很快过去，但真不知道何时能过去，焦虑和恐慌仍然笼罩在每个家庭的心头，2/10号复工，几家欢喜几家愁，自上班以来就没放过这么长的假，但苦了企业主们，工资照发，房租照缴，这些都是成本。

两天前，科比意外离世，世间再无黑曼巴，往日热闹的IC圆桌派群里，一片寂静，大家都被悲伤的情绪笼罩。但我们也做不了什么，宅在家里，努力学习，化悲痛为力量。

给大家介绍一下，IC圆桌派是由IC极客和陌上风骑驴看IC拟联合发起的一档谈话类视频节目。邀请IC领域技术专家、行业明星、创业者、老得有故事的人、年轻有想法的人谈天说地，畅聊IC技术江湖。预计节目春节后上线，每月双更。

IC圆桌派微信群是视频节目的线下技术交友群，我们会随机选择话题，发起每周1-7次的社群技术沙龙。春节期间保持每天组织一次技术交流的频率，至2/10号复工。

前几天我们组织讨论了职场，架构，DV，低功耗，中后端，EDA上云等一系列话题的线上研讨。内容过于丰富，大量的复盘工作仍在紧张继续。请还没有加群的同学扫码入群，更多信息参考文末链接。

IC圆桌派的第一场，大家一起探讨了一些架构相关的话题，整理如下：

极说・与IC圆桌派过大年之闲话架构

隔天对话某位才华与颜值齐飞的大神，内容作为前文的补充，此处隐去姓名，以Master为代号

Master ：架构师被神化，被捧上神坛，然后就是被鄙视，被不合理的批判。

Alice ：把架构师三个字换成敏捷研发这句话也很正确

Master : 架构设计的黄金时代，我相信应该是从大量架构师走下神坛开始。我认为这两者可以结合

Alice : 应该是的吧，技术进步总是要把过去的难题一一解掉的。

Master : 架构设计和研发管理其实很有意思。高科技所有神话都应该和数学打上勾。这俩和数学只有一毛钱关系，所以我更想说这俩都是“伪科学”

Alice : 也没那么玄，研发管理的每个分支都有经典模型和框架在的，太玄了咨询师怎么干活儿

Master : 回到架构和流程管理上，架构设计的的迭代太难了。一旦迭代，无数流程问题，牵一发动全身。这种项目，怎么敏捷？怎么让它迭代起来？这个问题还在我之前问你的，硬件implementation 如何敏捷？

Alice : 我一再强调切分小闭环，架构跟模型自己敏捷，DV自己敏捷，后端的主力在流程开发就是个流程中台，当服务平台做。从没说过也从没见过SOC全流程敏捷

Master ：好，我们就讨论小闭环好了。

Alice ：把坑先填了，你指的是什么坑？

Master ：闭环的前提条件是什么?

Alice ：高内聚低耦合

Master ：对，你提到坑，架构设计的坑就是低内聚高耦合。

所以我想要解决的就是提高架构设计的内部自我反馈，提高可迭代性，就是你说的内聚。我只关心一个问题，提高内聚，降低对外耦合还有没有其他解决方案。

Alice：我不懂芯片架构，但工作流程我们从这几个角度捋一遍

• 我一再强调流程梳理是研发管理最为重要的事，没有之一。流程之下都有模型在
• 架构师是在怎么做架构设计的，或者架构设计关注点是什么，工作步骤是什么
• 理解了第二点，后面就是model怎么为架构师决策方案提供指导，如何提升架构设想验证效率？
• 敏捷其实就是从流程中提取可并行可迭代的因素进行加速开发，实际上是某个milestone内的方法优化

进到了DV的主场

我们来看看大家在聊什么

什么样的RTL算好的RTL

终于有人问到了一个很有趣的问题，什么样的RTL算是好的RTL，这个问题算前端同学最重要的问题了吧，听听过来人怎么说

A1 : RTL除了算法架构的考虑，还要考虑最后的实现，才是好的RTL

A2 : 对中后端友好，PPA好的，具体来说就是，formal 容易过，对后端flow要友好，pr 实现相对简单

A3 : 别人看的时候没有一句一句的WTF，但RTL有时候可能走向两个极端，太好的RTL你也会WTF（充分利用可综合语言特性及辅助综合指令，极致精简的实现），太差的是满屏ctrl cv的痕迹，同样会WTF

A4 : 最恶心的代码就是用软件思维来写

A5 : 对于代码的理解不透彻所有程序都强套几个或几个编程范式的永远不是好程序员

A6 : 个人感觉，真正有硬件思维，适合写RTL的人不多，很多人写了挺多年，基本也只会加减乘除。最难的是硬件思维

A7 : 写rtl不光要有硬件思维，还需要思维缜密，才能经得起验证，基本功能正常，bug太多验证很难收敛

A8 : 一般工艺或者库变化后，我都会对比看看，主要的逻辑gate的时序怎么样。写的时候有数，不该省的不要省，后期要少很多事情。

A9 : HLS如果想写出很高质量的代码，还需要加速pragam，感觉也是硬件思维，还不够灵活，HLS更合适软件或者CS

A10 : 通常面试一个刚毕业的,你问他"你觉得设计环节什么最重要",八九不离十的答案都是"写好codes(无论是rtl, perl.)"

A11 : 如果广义定义为"可以给architecture足够的support,能够参与讨论; 可以写很好的spec, 在spec阶段,基本就把design构思完成了，并有很大一部分是已经具体细化了；能够很好的和VE沟通cover corner case"，在这种广义定义下，写代码才算比较有竞争力的吧

A12 : 反过来，一个能兼顾硬件实现的算法 ，可以带来一个顺畅的rtl design。遇到一个算法 ，从某大厂抄过来的面向二十年前的场景的算法，非要硬套到现在的需求。当时的场景是个好算法，挪到现在的场景，throughput完全跟不上，最后inst了7个core. 整个流程 带来300多cycle的latency

A13 : rtl 设计主要还是经验，大概能预测之后可能的问题。我碰到sram的模型工艺不一样，接口就搞了很麻烦，是接口输入和输出的时延模型定义不一样，导致之前的设计，时序就变得很紧张。总之，rtl如果能多考虑以后的时序问题，以后就会少麻烦，改流水线容易，改loop难

引战的话题就得这么拉

有人跳“我一直觉得前端写RTL是最简单的，翻译spec难在哪里？验证做得好，必须要懂rtl。后端做得好，必须要懂rtl。但是写rtl的人只懂rtl（所以以前公司写rtl的都是刚毕业的年轻娃。”

这下爆了土拨鼠的窝了。

A1 : RTL写的好的人，很懂验证的

A2 : 前端写 RTL 就像 写 C 的程序员，一对一翻译 spec 在实践中不可能存在，除非是设计自己写的 spec

A3 : 试想一下，designer完全按照自己的理解写spec和code，然后验证按照这个写验证的teatcase，能验出来什么？

A4 : 系统写系统spec，应用写应用的spec，rtl写design spec。理想状况是先出design spec，然后设计验证一起开始码代码

A5 : 写rtl只是designer的最后体力活步骤，前面还有活呢…

A6 : 有的只有RTL，别的一无所有呢。RTL是大爷，人家不写，咱也不敢问，也不敢说，公司不重视验证。RTL只动口，不动手。（不写spec的RTL都是没接受过正规军训练的吧）

A7 : 我印象特别深前年系统口头给我一个 spec

A8 : 架构随便改设计也很无奈啊...

A9 : 没有spec，拒绝验证！没有spec，拒绝验证！

从谁写spec到spec的formal化

spec的formal化很重要

A1 ：用RISC-V举例子，现在RISC-V组织就在研究，怎么把txt的文档，转化成机器可读的文档，然后用工具gen出model。参考阅读：https://github.com/riscv/ISA_Formal_Spec_Public_Review

A2 : 你写的RTL和model做formal对比，保证功能一致 （多少人做梦都想要这个啊……）

A3 : 现在有5个方案，sifive的最强了，spec直接生成veirlog model，这个model就是golden model了，RTL怎么写都行

A4 : 信息格式一直都不重要，重要的是txt里给什么信息，和从txt里怎么提取信息 (就是一边写spec一边出model)

A5 : ISA 比较好formal

A6 : ISA太复杂了，没有一个formal的spec，真的很难搞，这里面的坑，只有踩过的人才知道 A7 : 其他的spec文本要是能转化成语言，不管c还是其他，都太厉害了。

A8 ：methodology 已经攻克整个流程好多年了。你从这几十年的 HLS ESL 各种文章还有再早期 RTL 版图的文章看，问题都解决了啊....但是实际上 HLS 叫了 20 多年了... （好吧，你这么理解formal 也对）

A9 ：c 的hls不也是尝试formal 化rtl么

等等，是不是跑题了？

• 以上几位，感觉对formal和HLS的定义不一致。大家最好不好用formal来表示等价验证，因为是包含关系。HLS，出来的到底是rtl还是netlist？（我以为是netlist
• Chisel出来的是RTL，BSV出来的也是RTL，其他的不知道呢
• 形式化，将要求或者功能用标准格式进行描述或输出
• formal是以寄存器为节点 把设计打断成逻辑节点的逻辑等价性验证
• Using formal verification gives us the flexibility to mathematically guarantee that input RTL code is 100% matching in-terms of the functionality till post-layout （riscv 的这个formal 化和formal verification 不是一个意思）

ICer的formal verilfication一般还是sv里加assertion，当然和ISA的formal不是一回事了

• 但是如果你把语言这个框架抛弃，ISA spec其实也就是一堆assertion
• 我看这个定义的话，python module 就是一个 formal spec? purely functional = python method；precese and formal: pythonic = explicity
• 我寻思对着spec直接写assertion到底有多难，为什么要一层转一层

老驴又追问了几个问题

Q : assertion 是rtl designer 写的还是verification 工程师写的？还是工具写的

• assertion是verification工程师写的
• assertion 是独立文件？还是跟rtl 混在一起的？(都可以)
• 通常做法是各写各的吗？我以前错误的认为，都是rtl designer写的呢 (我怎么觉得是写spec的人写呢？)
• 多了的话分开，是写 design spec 的 rtl designer 写
• 那如果是rtl designer写的，如果formal 验证可以cover function 是不是就可以不用跑那么多仿真了？（互相补充，互相验证）
• 那意思是formal 要跑 常规的验证也要跑？为什么之前很多设计只跑常规验证就够了呢？（formal 可以增加function cover 不到的地方

https://github.com/sifive/Kami/tree/9e5fae76d02bc28fbda3ecbd6bd05ecc23224840

Q ：那做formal 验证根本目的是为了解决function coverage 上不去的问题吗？

A ：function 验证你要是讲究coverage，永远跑不完

Q ：感觉验证越来越复杂，又是formal 又是加速器的

A1 ：加速器是为了加速function验证的速度，其实是为了解决同一个事情

A2 ：PSS也是加速功能覆盖率的哦

A3 ：传统验证跟形式验证的关系，有点像后仿和sta的关系，我说的是有点像

Q ：formal 按照数学方式去分析吗？是不是理论上如果assertion 完备，可以不用跑传统验证的？

A：

• 你就写一个软件，也会加很多assertion。比如你写错一个算式本来是+写成-，assertion cover不到吧
• 两码事 功能验证是为了证明正向逻辑 断言往往是为了证明反向逻辑
• 我前东家，某控制逻辑模块只用formal验，算法逻辑模块只用uvm。
• 有的模块一千多个port，形式验证到下个宇宙季

Q：formal 会快很多吗？

A：

• formal当然快得很啊 静态仿真肯定比动态仿真快
• 想象一个FIFO的验证，fromal assertion几句话完成了，testbench要写多少呢？

我方了，楼上几位说的formal是一个formal么？迷之术语...

Aha！终于有人说清楚了

以上提到了三种formal，怕大家晕了：

1. 提到的formal spec，是写spec直接出model的流程，rtl另写，跟hls也无关。
2. 前端验证用的formal verification，代表工具Jaspergold，无需激励，golden是assertion。验证功能。
3. 后端工程师的formal verification：rtl2rtl，rtl2gate，gate2gate的等价性验证。

后仿阶段加速仿真的一些策略

大家还聊到的一些有趣的技术tips有

在后仿阶段加速仿真的一些策略，（base on vcs+verdi）如

A1 ：挖网表，force时钟等手段，加速仿真 A2 : 基于ucli，搭建环境时前面初始化的多用dpi，同时调整环境为支持dpi仿真时编译，这样就可以不每次带设计编译

A3 : 把一些东西改成读文件配置，通过修改配置直接仿真 而不必要编译

A4 : 保存仿真session，随时调用debug，需要debug的话，vcs用ucli的方式调用tcl脚本，可以很随意的force信号，随时dump波形 A5 : 分割编译，保证尽可能减少设计编译 A6 : 没有debug需求，只是回归，可以关闭vcs的debug选项，速度快很多 A7 : 设置空壳，主要把一些大的比较独立的子系统用空壳替换，把PLL的模型leaf模型简化成行为模型，稳定期再把partition切回去

前面仿真加速的话题，来自嘉琪同学的几个补充

• 在编译仿真中无效翻转对性能影响并不大，更多在于timescale debug选项，为了减少debug选项使用尽量不用uvm hdl方法，改用其他方法。
• 编译现在是分块编译，但是分块需要满足一些划分或者coding规则，否则会影响效率
• 当然dummy一些较大不用的模块也是很重要的，如果能dummy pll最好了
• 关于dpi使用个人用在两方面

1. 算法加速，用c++对大规模计算速度 文件读取速度等远大于sv
2. 模拟一些总线操作，可以将用于soc仿真的c提前进行，减少后期开发成本

后面继续有同学追问

Q ：请教个问题 在后仿中，因网表非常大，每个用例每次编译都花费很长时间，现在想一次编译，后续共用编译过的文件 这个怎么设置

A1 ：

这个分两种

1. sdf预编译
2. 文件增量

sdf预编译可以减少sdf不修改情况下的编译时间，具体命令忘记是什么了。文件增量参考上午的回答还有alice发的。与普通v sv增量是一样的方法

A2 : 这个应该问EDA的FAE

如果某些netlist不用也可以用dummy代替

很多时候partition不起作用不是没有开启增量，而是pkg等定义不合理造成的，还有一个是用自定义的三步partition代替两步的auto

A3 ：还有一个方法：弄个nb的服务器

A4 ：相似问题同样在verdi中遇到，打开速度超慢，有遇到一种实现，VCS编译结果供Verdi调用 （使用vcs编译的库打开，而不是flist，这些应该是verification架构或者CAD该解决的）

A5 : 对的，原来单打开就用2分钟，后来共用编译结果后就秒开

怎么可以不知道单元测试

以下内容来自嘉琪的分享和答疑：

ut(unit test) 最细粒度的测试，比目前我们常说的都要小 比如测试一个task一个class一个module等用被测试完善的底层搭建出来的出错概率更小，即使有改动也可以保证快速收敛。它的设计结构与上层的uvm框架不大一样。

我沿用的都是软件领域的划分。unit的对象可以是module可以是class可以是任何需要被完备验证的小物件，也可以验证验证的正确性。单元测试（unittesting），是在计算机编程中，针对程序模块（软件设计的最小单位）来进行正确性检验的测试工作。程序单元是应用的最小可测试部件。对于单元测试中单元的含义，一般来说，要根据实际情况去判定其具体含义，如C语言中单元指一个函数，Java里单元指一个类，图形化的软件中可以指一个窗口或一个菜单等。

事情的解决方案要更高一层去考虑，鲁棒性要向下去寻找了。如果用搭积木比喻，那么ut是最小方块，多少个ut集合需要再一次验证呢，这个怎么评估？（具体怎么划分划多大就看实际制定plan人怎么考虑了，以前领导讲过验证空间正交化的概念）

block/soc regression 遇到的问题都可以下沉到ut。利于debug。我们就做了两套flow，一套支持ut，一套regression(block subsystem soc等)。这也是我们内部大范围使用ut的原因，可以使后期的功能修改收敛速度得到极大的提高。

我们做这块会考虑一些复用性，也用了一些体系方法（借鉴微服务概念）可以将分散的组织起来，更容易拼出大的验证

敏捷里的故事分为用户故事即场景和功能故事即功能实现，觉得验证也是这两个方向交织的吧，毕竟功能不能用所有场景串联起来，功能组合对不对不知道，但是可以保证功能是对的，组合起来对的概率就大。

IP验证传男不传女的独门秘笈

Q : 对自己不熟悉的ip应当如何处理以提高验证的完备度？

A1 : 找到所有干系人，群策群力

A2 : 看模块的复杂度，太过复杂，时间紧，人手不足，趁早找外援或者外购VIP....

A3 : 当然还有验证常规那些手段，但对于这种模块最怕的是场景 corner的遗漏

A4 : 如果不是第一版testchip，那么一定了解一下之前留片的testchip或者用户是如何测试的，遇到了什么前期验证没有cover的场景

A5 : 谁有vip的资料吗 （IP vendor）

A6 : 一些常见的教训

1. 外购最好确认下业界是否已经有厂家采购并使用过，如果可能是新版本，那么不要那么肯定百分百不出问题，即使S公司的成熟IP我都累计发现过十几个问题
2. 手册要通读，特别是涉及接口和接口时序的部分 一些特殊标注的注意事项 脉冲宽度等 事实上扫完一本书要不了一周 而且这个是长期的工作
3. 设计的一定要做好CDC 不要盲目相信厂商 尤其在给过来的IP的几个模块分几个部门设计的时候
4. 起码把需要应用的低功耗场景验和基本使用的功能场景证到
5. 把自己的最大流量场景分析清楚，并按照相应的ost验证能否达到，外边总线架构导致的延迟能否流水起来, IP内针对读操作是否先预留了足够的缓存
6. 考虑死锁问题，比如master的读写数据依赖，访问多个电存在路径合并等各种死锁模型
7. 后仿真中jtag访问路径覆盖 时钟最大最小频率 出pad时序 模拟出pad没有误加东西 电源划分处理对不对等
8. 给出底软各需要的配置dpi函数并验证下，为回片准备

继续追问

Q ：考虑死锁问题，比如master的读写数据依赖，访问多个电存在路径合并等各种死锁模型，能不能给个例子

A :

这个就太多了,大家可以看axi和noc的死锁模型。那种中间突然有个频点不过的就是异步问题。设置规则过宽导致的匹配多了信号。还有warning没过仔细，电源接衬的都有。

各个corner的最大最小跑到就可以 不过定位问题时可以扫頻。那种中间突然有个频点不过的就是异步问题

一路追问

Q ：请教下，后仿除涉及PAD，ANALOG，RF等模块接口的timing，以及power switch相关的功能外，还会有什么timing问题是PT不能完全保证的呢

A ：

• CDC吗 （cdc主要还是得lint工具来查吧，靠后仿太晚了）
• PT不能保障的也很多，能做的也很多，但关键得是人都会犯错误，工具可能不完善
• 还有sdc 设错，sta以sdc为准，后仿可以帮助确定sdc的正确性

给这个妹妹解释一下增量编译

增量编译是编译工具特性，eda工具默认就是增量方式，验证平台也是v或者sv写的，当然可以增量

一路追问，好的讨论就应该这样

Q ：接着问一下，增量的原理的是什么？要指定吗？还是自动的？tool怎么识别那些改了，那些没有改？

A ：

• 时间戳
• 这个需要与ana同时使用，ana判断文件是否修改，elab根据partition看修改部分在哪里

Q ：那么接着问，时间戳修改的全部作为增量编译吗？就是整个文件？还是部分？

A ：

• 每个文件都有独立的时间戳，像git
• 如果partition内部没有修改，再看依赖的pkg是否有修改
• Pkg是一个带有作用域的东西，使用的时候要谨慎。增量编译是以改变的上一层作为编译主体的
• “编译”分为compile和elaborate两个过程，elaborate一般时间更长，compile其实有了增量后，很快的
• 比如层次结构a.b，如果b改变了，编译的是a以及之下的
• 增量体现在elab

Q ：elaborate 和compile做的工作有什么不同？

A ：

• compile编译文件以及语法，不关心层次性等其他。就是文件自己能编译过，缺cell什么的compile不关心。增量只在elab
• elab花的时间最长 partioncompile 节省的就是这段时间
• compile再大也就是秒数量级，加速意义不大
• 从log上就可以看出 每个part lib会看是否有改动，决定要不要做elab；这也是为什么做了libmap以后 会大大加速elab的原因
• 是的，毕竟没有改动整个层次结构就不动了；而是直接沿用之前的

#拦不住的趁机带货，你们其他家的AE不来加入一下就亏喽#

M的加速器在系统bring up和 hw/sw codebug有优势，另外就是单机容量大，功耗低

Q ：这些增量编译的知识是从哪来的，仿真工具的manual吗？我寻思我以前做验证的时候从来没涉及过这方面

A ：

• 不完全是 都是血泪史积累的
• 血泪史+1

验证在验什么，怎么验

以下主要内容观点来自IC圆桌派群聊剪辑

是不是都得通过function coverage来完成收敛呢？收敛是方法的问题，不同的策略反应出的收敛状态是不一样。只说function coverage，这个东西本身就靠人做的，它的目的是什么呢，是通过什么提取出的function，如果是spec，是否存在某些局限？

肯定spec是主要来源，关键是spec要写到什么程度，通过spec需要提取出什么呢，spec不可能写的非常细 细到能直接翻译成coverpoint。另外spec也是日后甩锅的依据。

个人觉得第一件事情是三方（设计 dv 软件）沟通使用场景，哪些内容是必须的，哪些内容是可选的。应该有主次，有些是必须的，有些是非必须，有些是首先要覆盖的。

有些功能点是验证工程师直接从spec来提取，这样保证验证的准确性。而设计工程师也需要根据rtl来提出一些具有风险或者复杂场景的功能点。而后者的优先级肯定比前者要高。

同一份spec，不同人理解不一样，由此而验证更安全。针对每一个点，每一种模式，每一种应用场景。提取验证项目，然后review，查缺补漏定优先级。很多时候还得项目经理拍板，特别是应用场景和优先级。

用function coverage比较清晰明了 所以，要满足验证需求的spec要写些什么东西，应该是一个话题。spec中应该要包含function point的内容。以及主要的应用场景 只有spec中写明这些东西，验证才具有针对性，才能快速收敛。

如果用function coverage来收敛，这个cover point也可以先写个壳子，后面慢慢丰富。先跑通smoke case 不停增加新功能case，同时丰富对应cover point，不停跑regression，看function cover情况，这是不是太理想化了？

这种属于verification plan的。

需要验证者，尽量写得细，verifylist做得好，工作就完成一半了。场景内会有一些feature的cov以及每种需要在什么层级验证，如何复用等一个体系化工作。我们要寻找的一般都是固定时间内的折中解，所以由哪块做什么就会显得重要一些。

好的验证体系能够更快帮助我们达到想要的TO标准。不认为验证需要等设计完成再动，只要有了场景验证就可以做各种工作，使用ut进行各种单元验证，这样即使设计有改动我们有ut保证的底层单元也能做到快速收敛。验证应该是和design一块儿开始的，接口定义好，给个wrapper就能开干。验证uvm tb很多事儿可以提前来干。RTL有编码规范，接口定义清晰，尽量模块化复用。越简单越不容易出bug。

assertion一般应该是design写么？那么严密的时序，应该是design的活儿，都不敢写assertion，特别容易出错，也容易写出性能差劲的assertion，而且对跨时钟域验证支持有问题，写起来也难，很多时候都是用的sv实现。

verification是个很不容易聊到东西，可大可小。能上升到哲学，还可以下降到干杂活的。就说这个assertion，当年的意思是，你要表达某个事情，比如你说，我想创造个美女，你可以有很多种表达方式，你可以说，我要设计个三围是多少的，欧洲风格的，温柔的… 等等等参数，可是你不是上帝，有可能你想了好多参数，某种参数没想好，等出来了一看，靠，不是美女。所以assertion提供了另一种方式来表达，你可以assertion一下，我希望出来一个倾国倾城的。这样简单一句话就验证了，出来的肯定是美女。

从架构, FE, MID, BE, LP, 到研发管理，新技术，新工艺，IC职场，每天一组新话题，期待您的参与，欢迎扫码加群