Chisel 再回首
强烈推荐 《香山源代码剖析》作为入门 Chisel 的教材 —— 2024 / 10 / 12
一年多前接触 Chisel 望 Scala 晦涩不堪的语法而却步。这一年多 Chisel 经过几次大版本更新，特别是切换后端后[1]生成 HDL 代码可读性提升一大截；更有小道消息最新 VCS 新增支持 Chisel，是时候重新入坑了。
同为 Scala 打底的 Spinal HDL，语法比 Chisel 赏心多了。奈何 Chisel UC Berkeley 名门出身，和自家 RISCV 架构工具紧密绑定，生态上差太多。唉，若是 Synopsys 下场实锤，Spinal 真是输麻了！
甜腻腻的 Scala
入坑 Chisel 首先被劝退的便是 Scala 的语法以及 scala 项目复杂工程配置。Scala 本质是函数式语言[2]，从面对对象编程思路迁移过来大多会不太适应，并且 Chisel 过多使用语法糖导致多种不同的语法实现之间摩棱两可；最后是过度符号化，符号化是一柄双刃剑，过多的符号化会带来大幅提升上手门槛（想想 Vim 就知道）不过这也使得他被选为 Chisel 的基底。好在 Chisel 的入门教程写得非常不错[3] ，从实际例子出发理解不必陷入 scala 语法的沼泽。
敏捷开发：美好的愿景
Chisel 全称 Constructing Hardware In a Scala Embedded Language。没错，Chisel 一直宣称自己既不是 HDL(Hardware Description Language)，也不是 HLS(High-Level Synthesis)，而是 HCL（Hardware Constructed Language）。Chisel 定位是 hardware generator，但相比 HLS 软件思维，Chisel 还是使用硬件思维编程，在不上不下的位置，捏了 HCL 这一种新定义。
在分析 chisel 优缺点之前，得先往敏捷开发泼一桶冷水，同样的设计，Verilog 写多少行 Chisel 写多少行故事是存在，但对提高效率影响不大。设计中语言只占开发时间的很小部分，很大的时间在写 spec 设计架构；其次整个数字流程中相比验证，设计又占据很小一部分。
参数化（parameterized）和更清晰的语法规范
Verilog 本身的参数化能力还是非常弱的，特别是处理复杂的信号名称互联往往心有余而力不足。之前参数化设计往往是写一套 RTL 代码，其中参数化部分用占位符代替，附之一套比如 Perl 或 Python 脚本语言处理参数化和字符串处理逻辑。需要借助脚本语言从代码字符串角度重构功能可见 Verilog 本身语言局限问题。
其次本身 Verilog 语言软硬件的边界并不是十分清晰，不可综合的软件验证逻辑和描述硬件的逻辑很多原语共用同一套关键字，其实别说软硬件边界不清晰，Verilog 就是硬件本身也不是很清晰，比如 chisel 统一端口是 wire 类型就很好。Verilog 差劲的语言标准[4]需要工程师本身代码风格水平过硬才能写出一套维护性强的代码。
而 Chisel 本身基于 scala 基底，能很自由地发挥高级语言特性参数化，同时在设计上硬件和软件采用了俩套不同的关键字分隔开（比如 if 和 when，= 和 := ，== 以及 ===）用语言标准确保了代码可读性的下限，从而将软件逻辑的参数化和硬件描述结合在同一个框架中。而 Chisel 自带一部分参数化处理功能（比如 rokect-chip 中的 diplomacy）又大大减少了参数化逻辑编程成本。
抽象化和生态
Chisel 将一些常见的逻辑保留为关键字，提高抽象层次进而提高了可读性，同时也节约了部分重复造轮子的时间，比如 RegNext 、ShiftRegister 、 Counter 、向开发者隐藏时序逻辑默认的 reset 和 clock 逻辑等。
此外 Chisel 积极推行开源生态风气，有 Rocket-CPU 、香山、承影等优秀开源项目。不过 Verilog 也不是没有开源生态，这一点倒不是很独特的优势，但 代码可读性比 Verilog 高上不少，更利于学习以及修改。
设计之外的故事……
Chisel 并非一枝独秀，Verilog 自上世纪诞生以来一直未曾有大范围改动，挑战它的人数不胜数[5]，就连官方的继任者 SystemVerilog ，也尚未有 EDA 实现了它的完整特性。因为工程并非仅仅取决于技术高低，也要考虑成本问题。整个硬件行业就是这样，由于流片费用高昂迭代成本高，新事物出现时往往倾向于维持旧有秩序，在原本的阵地上缝缝补补，直到只有当新事物回报远远大于开销才能取代旧事物。
Chisel 最诟病在于设计并非整个流程中的核心 bottleneck。设计时间远远低于验证成本。而 Chisel 验证的缺失是一大短板，为了缩短设计周期延长验证周期得不偿失。Chisel 5.0 之前的 ChiselTest 和基于 ChiselTest 的 ChiselVerify 框架已经被官方团队抛弃，转而维护 ChiselSim，Chisel 开发者似乎是想和现有的 UVM 系统兼容。
可见 Chisel 走了一条相对保守的路径，兼容原有 RTL 生态同时尽量克制过度提高抽象层次，最近更新也是，无论是提高 RTL 编码质量，以及放弃基于 chisel 的验证框架，都是尽可能降低了换新工具的过渡成本。但这既是 Chisel 的优势也是劣势，只对整个流程中一小部分进行优化，而设计本身并非核心占比，只有对设计的需求大才有 Chisel 的立意之本。历史上这个商业故事并没有成立，现在 chisel 入场的时机是否有所不同呢[6]？至于 EDA 工具的支持和社区生态则相对次要。不过若 Synopsys 下场消息为真，有了 EDA 厂商背书能减少大量额外成本，给 Chisel 未来打下一笔大大强心剂。
总结
本文对于 Chisel 主要观点和知乎文章[7]基本相似，大伙对于 Chisel 的共识是：有效，但很难说成一个商业故事。但至少对于学习研究而言，chisel 使得硬件从源码中学习修改难度大大降低。
(https://github.com/chipsalliance/chisel/blob/main/ROADMAP.md) ↩︎
注意 ChiselBootcamp 用得是旧版本 Chisel，里面很多东西比如 ChiselTest 已经被废弃了 https://mybinder.org/v2/gh/freechipsproject/chisel-bootcamp/master ↩︎
实际也不能怪 Verilog 标准指定的问题，半导体本身由于迭代成本高昂，相对封闭和保守，以至于新的语言标准很难迅速推广，都基于一些很老旧的标准维护。很久之前的制定者哪能考虑到这么多呢？ ↩︎
