一场关于开源芯片生态之语言与工具链的讨论
\\\插播一条：
自己在今年整理一套单片机单片机相关论文800余篇
论文制作思维导图
原理图+源代码+开题报告+正文+外文资料
想要的同学私信找我。
一、摘要
5.8日由网友的两个问题引发了大家的广泛探讨，从Chisel与Verilog孰优孰劣，Chisel的规范与规范，再到麻利设计与开源生态体系构建的挑战等一系列的相关探讨。
二、两段关于开源硬件语言和EDA工具链的反应
拜读了这篇详尽的综述，以及关于RISC-V的白皮书，关于选择Chisel的理由比较让人困惑，就是一个熟悉OpenSparcT1源码的工程师用Verilog写不出能够跑Linux的cache，但是本科生用Chisel却能够，并且代码量差异很大。
但其实现实情况是这样，通常硬件工程师都没有受过良好的编程语言的训练，假如如何封装，如何设计接口，只有看到波形没问题就能够。由于EDA攻克了大局部后续的工作，所以从软件开发来的角度来评估代码自身的质量通常都比较糟糕。所以这有可能是语言使用者而非语言自身的问题。至少过去我看过很多我EE同学的代码，能用，但没法看。这也是为什么国内芯片设计验证的压力那么大的理由。
假如能够让下个学期参加CPU设计的本科生们一局部用Verilog，后续再构成Chisel的toolchain能承受的形式（如net list或Firrtl）然后再烧进FPGA里，看一下这个流程花的时长和用Chisel的学生是否相似。假如相似的话，那么可能证明并非Chisel优于Verilog，而是学生们在程序设计方面受到的训练优于传统写Verilog的工程师。
之所以提这件事，是由于Verilog是一个DSL，其语法非常贴合电路的逻辑。Chisel是以Scala为根底的，在开发时须要在Chisel
【文章福利】：小编整理了一些个人觉得比较好的学习书籍、视频资料共享在群文件里面，有需要的可以自行添加哦！~点击绿色通讯软件搜索airuimcu加入。
和Scala两种概念模型之间来回切换。在硬件开发中是否要用到比较深入的OO或FP的概念，我对此表示怀疑。在NutShell的源码中，对于各种应用到Scala的OO特性的部分，其实也总能找到一个更简洁的Verilog替代。所以从开发者心智模型的角度，Chisel并不是一个好选择。以Verilog为例，我认为其提供的parameter，generate等功能对于硬件开发的抽象其实足够了（当然这个也是我认为）
其次的一个顾虑是，毕竟Chisel和RISC-V几乎来自同一个团队，Chisel也主要用来设计CPU。那么其它的硬件怎么办？比如RF，DSP，或是不依赖时钟的纯异步电路，Chisel及其开发思路在应用于设计其它类型的硬件的效率/效果并未得到验证。
最后，Chisel是一个开源项目。它是一个开放的实现，而不是开放标准。一个开放标准的形成是多方博弈的结果，由一个委员会或工作组来维护，这样确保一个语言的规范可以有序进行，不会产生disruptive change。把创新的芯片研发工作建立在没有开放标准的语言上，如果有一天Chisel的语法发生了重大变化，我们就都会变得很被动。所以以现在Chisel的社区治理形式来看，恐怕也不是一个好的选择。
比如Chisel目前没有任何关于formal verification的文档，虽然GitHub的issue中已经提到了experimental里已经有了类System Verilog Assertion语法的支持，但是文档中除了几个AP I就没有任何线索了。
所以我的建议是，首先最理想的是，在继续使用Chisel的同时，形成一个新的HDL的委员会/工作组，形成并维护一个新的语言标准，在此基础上允许各方拥有自己的实现，这样可以避开使用Verilog的各种影响，同时也能避免Chisel发生重大变化或社区崩溃的情况。新的语言可以在Verilog和Firrtl之间互译，从而能够利用上现有的Verilog和Chisel开源工具链。
如果这个无法实现，必须要选择Chisel，则退而求其次，要尽可能地在Chisel社区中发挥影响力，使它从一个实现变成既定标准，实现稳定的迭代。
包老师团队的成果对国人CPU及整个VLSI/SoC开发都具有示范作用，您的选择无论从商业开发还是教学方式都有很大影响力，很多人都在关注着您的动向。小弟本是nobody，只是殷切希望国内芯片半导体自主创新能通向一个健康的方向，希望包老师百忙中抽空看一下。
2）网友@双塔东街陶马文原文2
开源路真的挺长。现在也就是RTL级别仿真做的还可以，Icarus/Yosys/Firrtl都是不错的方案，但我们也没有国产的。再往下仿真验证环节，形式化验证这个概念本身也比较新，周围的工程师还是以看波形为主，对SVA支持程度也不一样。再往下Synthesizing/P&R/Layout那部分就更是路漫漫其修远兮了。
三、开源芯片团队讨论与反馈
1）Chisel与Verilog之争
网友对于“通过一个小例子来证明Chisel比Verilog好”提出了质疑。大家针对这个问题也进行了广泛的讨论，大家的观点也认为从一个例子来证明两个语言的好坏是不够充分的，衡量一门语言应该从多方面来进行考虑，而"如何量化这个标准"本身就是一个科学问题。
在计算机软件领域，衡量一门编程语言的好坏通常从：Abstraction，Performance，Integration，Simplicity，Testability，Debugging，State Management等角度进行衡量，而对于硬件描述语言(HDL)而言，目前并不存在一个公认的衡量标准。
尽管如此，大家认为以下几个因素对于HDL而言是至关重要的：1.同样对于一个对综合器理解不够深入的初学者，在相同的时间内，使用不同的编程语言，实现的某个具体模块的质量如何。2.对于一个刚入门的设计者，在使用不同语言实现相同功能的模块时，所用的工作时间如何。3.对于一个拥有多年设计经验的工程师，将一个相同的模块做到极致，最终的质量如何。
对于第一个和第二个问题而言，大家认为Chisel还是存在一定的优势的。最后，大家得出的结论是：芯片设计的质量最终取决于设计人员的水平，而编程语言也只是一种实现手段。从国内某个知名芯片设计大厂的竞赛数据中可以看到，即使同样使用Verilog语言，不同的设计人员在PPA上的差距可以高达20%-30%。
因此，在讨论编程语言的区别时，不一定非要争一个高下，踩一捧一是不可取的。正如在软件领域也存在许多编程语言一样，硬件设计语言也应当百花齐放才对。Chisel作为一门新生的语言，在配套的基础设施，认可度等各个方面也是存在它的不足之处，只有通过大家都对社区进行贡献，整个生态才会越变越好！
2）Chisel未来的发展
此外，网友提出了对于Chisel未来的担忧。针对这个问题，大家目前的看法普遍是乐观的，从历史来看，大部分编程语言的向前兼容性都是不错的，发生过重大语法的变化的语言还是少数。即使发生了重大语法变化，那也完全可以当作两门独立的语言，将过去的一个版本的分支迁出，就如同Python2与Python3一样。
关于标准化的问题，世界上的大部分语言在制定标准的时候都是由标准化委员会进行推进与审核的。作为一门被许多人使用的语言，Chisel的标准化委员会/工作组也是存在的，如国内的Sequencer也在参与相关工作。
最后，大家也感谢这位网友可以提出这么中肯的意见，以及对于中国芯片产业的殷切期盼，只有大家共同努力才能使得国内的开源芯片生态体系越来越完善，共勉。
3）开源工具链的讨论
此外，网友对开源工具链提出了道阻且长，任重道远的看法，这个问题也引起了大家的广泛讨论。诚然，开源芯片生态体系建设分为两个方面：开源芯片与开源的工具链。包老师也常说，开源芯片"香山"更多的是大家能看到的"冰山一角"，实际上在冰山下面，也就是从前到后的整套基础设施也是开源生态不可或缺的一部分。
而基础设施贯穿整个芯片设计流程，从微结构设计空间，RTL代码实现，RTL级仿真，形式化验证，等价性检查，模型检验，逻辑综合等前端所需要的功能，到布局布线，时钟树综合，静态时序分析，时钟树综合，物理验证等物理设计所需要的功能，再到分辨率增强技术，光学邻近校正，逆光刻技术等和制造相关的技术都离不开基础设施，也即所谓的"工具链"。
互联网的兴起离不开如雨后春笋般兴起的APP，而在这些APP的背后，许许多多的开源软件库与软件工具链的功不可没。在芯片设计领域亦是如此，如果有足够多的开源IP，配套的开源工具链，敏捷设计方法学与敏捷验证工具链。那样芯片设计领域会不会像互联网一样，涌现出许许多多的成功的商业案例呢？
网友的担忧不无道理，整条工具链所涉及到的工具，大大小小上百个，如果想要建立整条开源的工具链还是存在一定难度，但是我们不妨可以沿着一条主线；”开源的敏捷设计工具链“，建立整条工具链的子集，逐步代替。
如果想要建立工具链，则应该分门别类，逐个击破，在这里，我们可以从两个方面对工具进行划分:其一，从辅助前端设计的角度，语言或者语言的feature本身也属于工具的范畴，比如Chisel和 Spinal HDL可以是一门语言，也可以算作是Verilog generator，是用于生成Verilog，降低前端开发和验证成本的辅助工具；Chisel种的一些比较好的feature，能够降低开发者的验证成本，既算是语言功能，也可以算是工具。其二，传统意义上的EDA工具，如仿真验证工具，以及逻辑综合、物理设计和Signoff工具，理解为通用含义上的EDA工具。这两方面工具链的建立仍然存在许多挑战，只有抽丝剥茧，找到良好的切入点，才能有逐步解决的可能。
在辅助前端设计方面：RTL语言的好坏会严重影响前端开发的效率，并且RTL语言也会和仿真验证工具存在较强的耦合，比如如果想要在Chisel语言上实现形式化验证，可能不得不为Chisel添加类似于System Verilog Assertion的功能，并且支持model checking。但同时也可能存在一些好处，比如Chisel所生成的Verilog表示可能会在运算符上限定的更加严格，这样可以尝试利用Verilog的子集来设计一个RTL仿真器，它的通用性可能会差些（无法扩展到通用Verilog），但是性能的挖掘空间，可能更大一些。同样，如果这个仿真器真的设计好了，并且效果可达预期，就会成为 Chisel生态的一部分，提升 Chisel的吸引力。从这个角度来讲，辅助语言的工具，确实要比语言本身要重要一些，而这时候，工具本身也可能在概念上内化为语言的一部分，那就是，大家会说Chisel的仿真工具很好用，速度奇快。
语言的发展，总归是会朝着更加符合工业需求的方向发展，但这个“需求”是多维度的（比如开发效率、后期维护成本等）。比如软件领域的 Rust，其学习曲线比较陡峭，但可以有效减少常见的代码bug，降低后期的维护成本，因为Rust可以保证代码运行效率，同时在编译器层面保证并发安全和内存安全。对于百万行代码的项目来说，项目体量较大，后期维护成本不容小觑，借由 Rust来一定程度上避免代码质量受限于开发者水平，以降低开发效率来换取更低的维护成本，就变得很有吸引力了。
在传统EDA工具链方面：开源EDA的全流程工具链的质量确实差很多。整个工具链的流程很长，一个或多个环节的工具质量差一些，组合起来缺点会被叠加放大，最后的PPA相比商业的EDA工具会差很多。而在EDA行业这个事情几乎是无法容忍的，优秀的设计者总是期望我的设计工具一定以最小的面积成本获得最高的性能，每1%的面积缩减，都意味着成本的降低！用一个不恰当的例子，"行百里者半九十"，也可以认为达到了90%的性能所花的时间与达到100%的性能所花的时间相差一倍！而在实际的工程中这个数字甚至可能达到甚至十倍!
同时由于行业特点，EDA工具在验证工具上需要和芯片设计者交互；在辅助制造的工具上，需要得到制造厂商的认证；在EDA工具质量评测上，又需要设计公司的真实设计。因此，许多的初创EDA公司内忧外困，这就是所谓的行业壁垒。
但是有这么多困难就是没有希望了吗？也并非如此。随着"开源芯片生态"的不断扩大，“一生一芯”,“香山”等优秀的开源芯片项目的影响力不断提升，每年都产生大量的用户与真实设计，可以持续的为"开源芯片工具链"提供更加高质量的芯片输入，为不断打磨迭代提供了数据基础。与此同时，随着人工智能的不断发展，大家有了强有力的从数据中寻找pattern的方法论，相比于上世纪EDA诞生伊始靠着人工的提取数据特征，例化到code中去，效率提升了很多。同时，优化理论，机器学习，甚至Learning for Optimization的发展都对于EDA这个算法密集型的领域有着深远影响。也许过去不能被优化的问题，在未来引入了最先进的方法论后可以被解决！
冰冻三尺，非一日之寒；滴水穿石，非一日之功。诚然，正如网友所说的“任重道远”，建立“开源芯片生态”是一个道阻且长的过程。但是，与网友提到“任重道远”时的迷茫和悲观不同，我们在提到“开源芯片生态”任重而道远时，更多的是心中涌现出的澎湃和淡然，是对事物有了相对深入和客观的认识后，展示出的一种自信和洒脱。通过构建一套110nm可流片的P&R工具，我们有机会从实践中获得第一手的信息，这是我们对开源EDA的未来充满期待和信心的重要原因。
四、总结
开源芯片生态的建立离不开这样关心国家芯片发展的优秀网友，下面援引一位老师的一句话作为共勉:“鹏怒而飞，其翼若垂天之云；水击三千里，碧空九万丈，好风凭借力，送我上青云！”