SFC2020
SFC2020 管理员

554枚
铜币

689点
威望

0个
银元

SpinalHDL:此CHISEL非彼Chisel

2020-06-09 13:48

3760

这里有两个概念

CHISEL泛指
泛指基于Scala的硬件构筑语言(Constructing Hardware In Scala Embedded Language),

图片:微信图片_20200609133656.jpg



包括chisel和SpinalHDL,所以标题中CHISEL是指一个基于Scala的HDL语言,实际上chisel和SpinalHDL称为HDL框架更为合适,因为除了一些电路语法外,绝大多数都是在运用Scala的语言功能,一切强大都源于Scala语法。

Chisel特指
特指伯克利大学发布的Chisel硬件开发语言。
我们文章中大CHISEL为泛指, 小Chisel为特指。

Verilog不够用吗?
需要一门新的语言吗?
VHDL诞生于1982年 ,Verilog诞生于1981年, 起初是用来电路存档描述, 都是硬件描述语言, 是用来描述数字电路的结构,行为,功能和接口的语言。
虽然Verilog/VHDL简单易用,在那个历史时期相当程度上提高芯片的设计效率,但是这么多年过去了,Verilog显然已经落后与时代,集成电路的规模以摩尔指数增长,复杂度越来越高,种类也越来越多,但是Verilog还是在一种非常低效的方式开展工作,高效的复用并不能展开,即便是后来出现的像SystermVerilog 这类语言也并没有完全解决Verilog的问题,况且EDA工具对SV的支持并不是很积极,造成了这种尴尬的状况。

例化不方便
有人会说,有辅助插件帮你完成 (确实有很多好的插件,emacs verilog-mode , vim 的autoinst) 即便这样,但是对带参数的模块例化, 一对多例化同样需要手动处理,非常不方便

大量的重复声明
无休止的变量声明,无休止的位宽声明,容易出错, 作为一门上古时期的语言,对编译器不能要求太高

函数不能带参数
verilog中函数的使用只能是零零星星,哪怕是一个位宽的变化都要重写函数, 作为一门语言函数不能广泛使用,实为鸡肋

参数化实在是笨拙
虽然支持参数化,parameter 也只能做一些简单的加减左移操作, 没有基本math包。
利用宏做参数化,对于变量比较多的设计,非常复杂,并且也不好维护。

错误检测很弱
编译工具对错误的处理比较保守, 这种保守可能也源于语言本身,以及编译器的能力不及。
以下问题需要工程师自己处理

位宽不匹配,
input/output端口写反
饱和截位弄错,
跨时钟域问题
锁存器检查
组合逻辑环自己查
....
基于前仿的编译,会遗漏大量的错误,必须要Lint, 综合检查, 费时费力又费钱。

重构、增减信号,Bist/DFT逻辑插入麻烦
需要手动处理, 编写脚本, 即便是脚本也不通用

等等...

所以现在写Verilog纯粹就是体力活,RTL工程师大概就是这个样子:

图片:微信图片_20200609134123.png



可以参考一个实例, 笔者本人写过一个用在手机芯片小区搜索的IP,python算法代码不到500行,Verilog整整写了2万多行 绝大多数时间不是在处理功能逻辑问题,而是消耗在一些位宽错误, 模块集成,端口连接,信号声明,重复基础cell等低级问题的处理上。

反而编译器倒落了个清闲,编译器的状况大概就是这个样子:

图片:微信图片_20200609134155.jpg



五个灵魂追问?
能不能愉悦的开发?
不想干重复的脏活

能不能参数化设计?
想一劳永逸

能不能方便的复用?
我懒

能不能检查错误?
我粗心

能不能扩展它?
emm。。这个,老板肯定会问


为什么是Scala?
软件领域的技术革新变化很快,而IC开发领域几乎被verilog/VHDL包办了40年,不管是语言还是Flow都事实标准化了。在IC领域想要技术方法大的更新,需要EDA工具厂家的支持,IC公司的认可(流程庞大变化迟钝),工程师技能更多的是面向IC领域,缺乏软件工具造血能力。所以让变革发生在行业内部可能性极低。

虽然抽象能力参数化能力更好的SystemVerilog, E, SystemC等语言相继的诞生,但并没有根本上解决 这些问题,主要原因是EDA工具厂家对这些特性支持不积极,更多的是用在验证建模领域。

同时IC设计也出现了另外一个方向HLS(High Level Synthsis), HDL语言是需要明确的电路信息的注入。而HLS是描述算法,对电路没有明确的描述,所以一般就会导致生成的电路资源冗余,时序冗余, HLS每年每家EDA都拿出来炒,真正使用HLS开发IP的公司还是非常少见。

除了传统的这些对verilog的扩展语言外或者另辟蹊径走HLS的语言之外,基于不同语言平台的DSL多如牛毛->HDL语言列表, 其中也不乏有超强的参数化能力以及面向对象的特性, 但是都没能流行起来。

他们的问题除了完全不会有EDA工具的主动支持以外,主要有两个原因:

  • 缺乏杀手级的特性(类型推导,函数式特性)
  • 缺乏杀手级的项目(像Chisel的rocket, Spinal的Pinsec,Vexriscv )

能担当此任的HDL一定是基于像Rust、Scala这类现代编程语言上的DSL, 虽然lisp, haskell本身也具备这样的能力,但是基于圆括号的代码风格不太容易被主流接受, 另外纯函数式有点不见人间烟火,虽然Scala经常被吐槽函数式编程不纯粹,但是混合面向对象的特性,在管理数据构建程序结构而言面向对象还是相当方便.

所以我认为不太可能出现在python,ruby,java这类语言, 参数化能力很容易办到,但是缺乏函数式特性,类型推导惰性求值特性。一言以蔽之,这些不适合做DSL。

Scala能为我们做什么?
目前较为流行的Scala HDL框架有两个Chisel和SpinalHDL,Chisel出生伯克利自带流量,借着RISCV这两年算是出尽风头. 反观SpinalHDL那可低调的多,导致很多人都没有认真去了解过它, 不清楚作者Charles Papon是不会宣传还是不屑宣传,就连github上的头像都是默认图标。

我本人起初对Scala开发硬件这套方法也持怀疑态度,骂骂咧咧的上了Chisel的贼船,在公司的项目上用过Chisel, 尝到了甜头也隐隐觉的有些别扭。一个感受就是:“爽了一下,又硌了一下”。

直到 一次偶然的机会我重新阅读SpinalHDL文档源码,我意识到问题出在哪儿,别扭源于哪里。Spinal的文档和源码阅读起来毫无障碍,你也很容易把它跟硬件中的概念联系在一起,我想这个跟作者本人的RTL开发经理有关,所以很多概念抽象的非常准确。并且不乏有惊叹的关键字设计,诸如Mhz, Kib,m"1011100" master slave >-/->,从前只有在文档中出现的概念直接引入建模,更进一步提高参数化能力。

对于Scala开发硬件这套方法是否可行,如果chisel让我还有些不确定的话,那么SpinalHDL展现的这套界面我对这套方法充满信心,即便将来不是SpinalHDL,可能是名字叫XXX的另一个框架,也许是你自己或者公司写的后台,但是SpinalHDL展现的这套界面不会过时,放四海皆准。

后面章节我会更详细的对比Chisel和SpinalHDL, 在比较两者的区别之前我来罗列一下他们的共同点,也是所谓的泛CHISEL特性。

泛Chisel特性
  • 非常好用的位宽推断(甚至跨模块边界)
  • 错误检查能力(Lint, CDC, timing评估, more)
  • 彻底的参数化能力
  • 大量的基础组件以及可重用IP
  • 至少一个完整的Soc框架(Chisel的RokectChip, SpinalHDL的PineSec)
  • 继承Scala平台所有强大的语言特性

在这里引入一个插曲,有些人会说rocket和Chisel不同一个项目,不能拿Rocket来当chisel做比较, 不过我觉的脱离SOC和lib来讲CHISEL实在没什么可讲的,当年入学时煞有架势抱一本书在啃Verilog,我们的导师问的一句 让我记忆犹新"Verilog只需要两个小时就学会的语言,为什么要抱一本书?你现在需要的编写代码"。所以不管是Chisel还是Spinal电路级的语法我也认为只需要2个小时就够了,更多的时间要花在编写代码更学习如何构建SOC或者lib上。现在网上看似有很多Chisel的资料,结果发现翻来覆去都在讲电路语法,而真正介绍RocketChiP,总线,时钟域,构建Lib的资料少之又少。所以学习Chisel或者Spinal最快的方法就是尽快上手去写代码。最好是实际的项目。

期望效果
  • 解放工程师,避免重复琐碎,避免低级错误
  • 加快开发周期,开发周期和模块大小不再是线性,有望指数

目前用Scala编写HDL代码,别有风景, 工程师完全可以从些低级重复的工作中解放出来, 把那些重复容易犯错的事情交给编译器,它会比人做的更好,而且大量的可重用的总线和lib让你省事不少。


现在的你:

图片:微信图片_20200609134155.jpg



为什么不让编译器多干点呢?

图片:微信图片_20200609134123.png



本文源自马車 ExASIC,转载目的在于传递更多信息,版权归原作者所有。


返回顶部