日志

国产EDA的崛起之路

已有 1717 次阅读| 2021-3-1 13:14 |系统分类:芯片设计

提到芯片EDA，一般人能在模糊的印象里搜索到的几个词是“卡脖子”，“芯片领域皇冠上最闪耀的明珠”，“比光刻机还要紧缺的产品”。而芯片从业人员会发现，尽管贸易战打了这么久，能看到的EDA仍然全是国外三大巨头的产品。伴随着海思麒麟9000的绝版，芯片领域的制裁愈演愈烈，而作为卡脖子工程的国产EDA却一直神秘的停留在新闻中。作为业内人士，笔者希望通过这篇文章，讲清楚国产EDA的前世今生和未来之路。

国产EDA的起源，还要回溯到上世纪80年代。中国领导人很早就认识到芯片的重要性以及EDA被“卡脖子”只是时间问题。1986年，中国动员了全国17个单位，200多个专家集中到北京集成电路设计中心联合攻关，终于在1990年的时候发布了熊猫EDA，接连斩获两项国际大奖，也一举打破了西方技术的封锁。三大国际EDA巨头火速就在北京设立了一个办事处。使用更成熟的技术，超低的价格在中国市场倾销，其他的中国芯片设计厂商，自然就会选择物美价廉的美国软件。没有了客户反馈，软件产品无法迭代，熊猫EDA只能慢慢萎缩。随着verilog2001的推出和工艺标准的升级，昔日的明星产品渐渐淡出人们的视线。而接过熊猫EDA的华大九天，在之后的二十几年都没有真正的EDA产品推出。直到2010年后，以华大九天为代表的国内EDA公司陆续推出多款工具，如果仔细研究会发现，这些工具大多集中在模拟和后端领域。有人问什么是后端？这个得从头说起。

首先要科普下芯片设计的流程。以芯片行业内规模最大，占比最高的数字芯片开发为例，跟EDA相关的标准流程分为前端RTL设计，后端布局布线和封装测试。举个不太恰当的例子，这几个步骤好比盖房子，蓝图设计（RTL设计验证）—施工建房（布局布线）—交付装修（封装测试）。

蓝图设计：需要科学家，考虑的是结构，承重，安全等级
施工建房：需要工程师，考虑的是标准，流程，施工效率
交付装修：需要设计师，考虑的是省钱，好看，主任喜欢

科普完毕，再回到国产EDA的发展。

2018年中兴事件后，中国的芯片行业被持续打压。作为中国科技企业领头羊的华为也不得不因为“缺芯少魂”将手机市场拱手让人。为了发展芯片行业，国家不惜投入重金，甚至成立了集成电路大基金，并持续增加投入。而国内集成电路相关企业从2017年的5000家不到，骤增到现在的6万家，然而其中研发EDA工具的公司却两只手都数的过来。按照官方说法，出现这种局面，除了三大巨头的垄断之外，还有个重要原因就是研发难度大。我在这里拆解下“难”。

让人觉得困难的事情大概分为两种，一种是难以理解，超出目前的知识范围。好比让小学生做一道微积分的题目，就算答案摆在面前也不明所以。另外一种是繁琐复杂，需要大量的时间投入，特别考验耐心。好比让你把航空母舰拆开再装回去，或者去跑步机上跑上几千公里。EDA的“难”在这两方面都有体现。EDA中涉及大量的算法，同时跟工艺紧密结合，需要大量的时间迭代。目前国内的EDA在后端扎堆，主要原因是这种“繁琐复杂”是中国人比较擅长处理的“难”，只要人力和时间堆上去，会有产出。而跟核心算法相关的“难以理解”的EDA前端工具却很少有国内的公司愿意碰。为什么会出现这种局面？

其实除了芯片行业，中国整体也是弱基础研究而重工程能力强。说起来得回到中西方思维习惯上。西方哲学注重的是“学以致知”，不关心产出，更关心原理。而中国哲学注重的是“学以致用”，不关心过程，更注重结果。所以在广场上到处抬杠的苏格拉底在西方被抬上神坛，而同样的处事风格到了中国通常会被当成“杠精”，变成《天龙八部》里让人讨厌的包不同。有点跑题了，回到EDA工具，把产品继续细分下来，芯片EDA产品分为静态检查—仿真—布局布线—封装测试。这些产品从前到后对算法，性能和标准的依赖度如下表：

	静态检查	仿真	布局布线	封装测试
算法	★★★★★	★★★★	★★★	★
性能	★★★	★★★★★	★★★★★	★★★
标准	★	★★★	★★★	★★★★★

表中可以看出算法集中在静态检查工具。EDA行业的静态检查工具包括nLint，spyglass，0-In。不出所料，到目前位置，涉及静态检查工具的中国EDA公司一家也没有。这些工具每个芯片项目都会用到，而被海外全面垄断的静态分析工具到底质量如何？

以nLint为例，最早nLint被Novas公司开发出来，2008年被Springsoft收购，2012年被synopsys收购。有意思的是，不光国内公司不愿意碰，国外也只有唯一一家，还是被synopysy收购后作为旗下非重点产品维护。Synopsys于2015年左右决定不再更新nLint，并且并入另外一个工具中捆绑销售。之所以这么做，不是因为不重要，而是因为垄断，反正用户也没得选，产品再差再难用也卖得出去。

nLint主要用于hdl规则检查，所有在大型项目用过的工程师都会被虐到怀疑人生，甚至怀疑自己花了二十年，连verilog都不会写。使用nLint大致过程是，配置完毕，软件立刻报出几万条错误和警告。等用户心惊胆战的关掉大部分无效规则后，耐下心来搬起小板凳一条条看过来。终于发现忙活了很久，没有一条是有用的，或者只有几处，还是可改可不改的地方。一般我们在公司里见到瞪大眼睛对着屏幕，时而眉头紧皱，时而满嘴脏话，然后拍桌子骂娘的大牛工程师，大概率都是在给项目清除nLint报错。这些大牛最常骂的就是，“XX也太蠢了，这也报出来”。沉淀了十几年的产品为什么会是样？

垄断是一个很重要的原因。除此之外本身静态检查的算法是基于HDL语言本身。要在整个编程语言支持的范围内找出各种用户可能出的错，并且准确的区分真假，这本身就不是个简单的事情。在编程语言上做出语法分析后进行合理的语义理解，并推测使用者的真实意图，静态工具做到这里才能真正让人满意。用人话举个例子，让大家对静态工具的工作有个透彻的理解。假设你住在一个村庄里，性别男，爱好女。有一天你对村里的姑娘表白，“山无棱，天地合，乃敢与君绝“，正常人会知道这是山盟海誓，要终身相许。但是如果你的表白对象是村里的傻姑，她会以为你要分手，直接一巴掌甩你脸上。因为她只能听懂后半句”与君绝”。nLint目前的智商大概就相当于这个低能儿。尴尬的是，村里只有傻姑一个女人，你写完的情书（代码）只能拿给她一个人看。如果只是听不懂，其实可以一遍遍的跟她解释，换成她可以理解的表达方式，或者直接忽略她的抱怨。但是更可怕的情况是，你说什么，傻姑都只是对你呵呵的笑，不管你说什么她都不反对，然而最终错误的后果却还是要自己承担。对于nLint来说是同样的问题，几万条的误报或没有必要的检查，给芯片造成的损失无非是开发周期长一点，花的时间多一点，工程师骂骂娘就过去了，这还可以忍。更可怕的是那些被nLint漏掉的错误，如果后面的流程也没有抓出来，就直接泄露到产品中，这才是真正可怕的问题所在。

说了半天，我们回到产品上，分析下nLint的问题。由于垄断和不思进取，nLint的算法选择了最省力的方法，所有的检测都从形式出发，即使是最简单的逻辑展开也不愿意往下多走一步。这个部分没有例子很难说清楚，非芯片行业的同学可以直接跳过去。随便举几个会被误报的例子,直接上代码吧。

示例代码1：

wire[7:0] i_a;

wire[7:0] i_b;

wire [8:0]c,d,e;

assign c=i_a+i_b;

//assign e=(i_a==8'b0)? c :9’b0;//nLint no warning, but equal with next line

assign e=(i_a==8'b0)?(i_a+i_b):9'b0;//nLint error here, but not a real issue

误报原因分析：标红的两行，语义上是完全一致的，但是nLint会对后面一行误报位宽匹配错误。主要原因是对于赋值表达式 assign variable=condition？expression_a : expression_b; Verilog语法支持expression_a/expression_b为各种表达式，nLint的检测算法不能正确的处理嵌套复杂表达式，因此计算位宽错误。

如果觉得误报可以忍的话，还拿位宽检测作为例子，随手再来个漏报的例子。

示例代码2：

wire[2:0] i_a;

wire[7:0] i_b;

wire c;

assign c=(i_a==i_b);

漏报原因分析：运行后nLint没有任何报错信息。主要原因是对于赋值表达式 assign variable= expression_a; Verilog语法支持expression_a为各种表达式，nLint的检测算法直接跳过复杂表达式，因此无法检测出expression_a内部的位宽匹配错误。

再上个简单的。

示例代码3：

//assign port_out = 1'b0;

assign b = (a==1'b0)?1'b0:1'b0;

漏报原因分析：变量b被常量驱动nLint不会报出来。原因是对于变量驱动，nLint选择了比较容易的算法，没有真正的做语义分析。上面代码，如果对变量表按照数值展开，会很容易发现不论a为什么值，b都会被赋值为0。但是nLint只能识别出来被注释掉的一行的赋值表达式这种简单的形式。

还能忍？再来。

示例代码4：

always@(*)

if (sel||(!sel) )

port_out=port_in1;

else

port_out=port_in2;

漏报原因分析：对于条件判断，nLint选择了比较容易的算法，没有真正的做语义分析。例如例子中红色部分，如果对变量表按照数值展开，会很容易发现红色运算结果永远为真。综合后 port_in2可能会被优化掉，没有真正的load。但是nLint目前算法无法识别。

其实nLint的这种简单粗暴省时省力的算法非常好理解，就是垄断。产品合并后，客户的投诉有没有继续更新跟进，恐怕就只有他自己知道。简单地说，如果真剩下最后一个女人，她一定没有动力打扮，就算永远是“如花”的样子，也还得捏着鼻子忍。负能量到此为止，因为终于有人忍不住了。

从2020年下半年开始，国内EDA公司逐渐开始进入前端。2020年6月份成立的芯华章，首轮就拿到了20亿投资，发力前端，甚至打出了开源EDA的口号。2021年1月九霄智能更是直接推出了第一款商用静态检查工具ultraeda，并且目前在免费试用阶段。

所谓静态检查其实是和动态仿真相对而言的。

动态仿真由来已久，是在设计中加入动态激励的基础上比对设计是否满足预期。仿真验证其实说白了，就是可以在结婚前试一段时间，尽量造，尽量挑毛病。除了各种激励，仿真最重要的是导入了时间的维度，而在时间轴上前后给出的两个激励有时候会有相关性。也正是因为如此，激励会变得异常复杂，使用者需要花费大量精力开发各种激励。有时候激励场景的构造比产品开发本身的难度还要大。因此，芯片设计公司里通常会有专门的团队负责构建激励，一般称为验证团队。而验证团队的规模通常是设计团队的两到三倍，并且在整个产品周期中时间占比最大，投入人力最多。

静态检查工具对使用者的要求则比较低，设计开发完后基本上可以直接看到结果。这个过程大概相当于结婚前找人算一卦，预测两个人是否合适。由于输入有限，对用户的要求很低，而静态工具本身开发的难度则特别大。一般来说静态工具开发主要分为三步，语法分析，语义理解和规则导入。语法分析通过研究HDL语法，结合规则检查的需求，生成抽象语法树。语义理解部分在抽象语法树的基础上，提取核心逻辑。规则导入，是在语义的基础上，检查目标代码是否符合制定的规则。语法分析和语义理解属于编译器的前期步骤，目前成熟的HDL编译器都有各自的规则，这部分是比较成熟的逻辑。检查规则部分则是根据实际工作中遇到的各种人为引入的错误提供检查，能够在芯片项目早期发现更多的错误，节省大量人力。

ultraeda从底层算法上彻底颠覆了nLint的检查方法，在语义层面上深入挖掘。该产品的静态语法检查功能深入分析了用户的意图，大大减少了误报和漏报的情况。例如，为了multidriver规则检查，ultraeda抛弃了形式推断的方法，用算法提取了整个模块的变量驱动表，在此基础上完成整个规则检查。该算法需要综合考虑各种条件分支和循环，同时对于不同变量取值可能会导致的多驱动问题都需要全盘考虑。2020年各大EDA公司联合举办的EDA知识竞赛，就是以multidriver的检测作为压轴考题，以期能找到合适的算法。九霄经过多年的深入研究，掌握了具有完全自主知识产权的核心算法，可极大的降低芯片中潜在的风险。下图为九霄公司ultraeda的独特drive视图（仅供业内人士参考）。