为什么要 Multi-language?

[Devil-SX]

高级语言验证生态已有不少的成果，比如基于 cocotb 的 pyuvm，已然实现了 UVM 标准的全覆盖，我看 mlvp/toffee 也是 计划对 UVM 进行全覆盖，这是从 picker 重新起了一套轮子，唯一的区别就是除了 Python 也支持其他各种语言，也就是首页说的 ”让人们用自己擅长的编程语言进行验证“，尽可能减轻工具成本，将这件事情众包出去。

支持 Python 外更多语言目的在于更高程度调用软件端人才资源，毕竟 golang、java 这些都是做软件人用得多。但软件端可以迁移到众包验证的技术栈好像就语言以及验证方法学了，没有的硬件知识和架构知识，感觉这个路径更多利好硬件方向的人才减轻验证工作，而不是吸引更多软件端人才？

请指教

[Miical]

刚刚开通了 Discussions 板块，可以将此问题迁移到 Discussions 中进行探讨

[Miical]

很好的问题，我在这里详细回答一下吧。首先，对于picker/toffee这做的一整件事来说，就是为了一个目的，那就是使用开源众包来降低芯片验证的成本。在这个过程中，我们利用了软件生态。

为什么要引入软件端人才？因为软件人才资源相比硬件人才资源不在一个量级，掌握Python和掌握SystemVerilog的人数可能相差千万倍。如果采用SystemVerilog去进行开源众包，恐怕没有多少人掌握，能来参加的人更是少数。 所以使用多语言，根本目的是能让懂这些语言的软件端人才能够直接来验证，不用另外再学习Verilog语言和SystemVerilog语言，从而达到开源众包的目的。至于来参加的人很可能没有硬件和架构知识，这就是我们要做的另一件事，将硬件的操作方式向软件操作方式转换。

现有的cocotb你会发现，它将硬件世界中对硬件的操作方式直接搬到了高级语言，再看pyuvm，它仅仅是将硬件框架UVM的一个不同语言的实现而已，用高级语言去验证其实还是硬件那套东西，就是语言不同。systemverilog对硬件的操作方式本身就让软件人员感到困惑，UVM中巨量的概念对软件人员更是巨大的挑战。按照我们的经验，一个人起码学习UVM 1-2个月的时间，才能勉强开始搭建UVM平台。并且UVM的设计本身就是基于SystemVerilog进行，它的表达能力受到限制，很多机制很难和软件中的工具方法去结合。

而在Picker里，整个硬件设计被抽象成了一个状态机，通过输入输出和一个状态改变的接口Step()就能完成对硬件设计的所有操作，软件人员理解起来很容易，甚至都不需要知道有时钟的概念。提问中Toffee的链接是我们已经弃用的一个版本，Toffee也不需要对UVM进行全覆盖。Toffee目的是去做一个软件测试框架，让验证硬件变得的更加灵活高效。你会发现通过Toffee，硬件的操作直接会被转化为函数的调用，测试用例的编写和软件测试几乎一模一样，pytest、hypothesis这些原有软件测试框架都能无缝使用，还能够结合很多软件测试技术。经过我们的对比，通过toffee完成一个加法器的验证，只需要50行，而UVM需要400行。这是Python语言的高效、Picker对硬件的抽象、Toffee框架设计、软件中的工具方法共同作用的结果。这一套路线带来的不仅是对软件人员学习门槛的降低，也是对芯片验证效率的提升。

所以picker/toffee与cocotb/pyuvm走的是完全不同的路线，一个是让硬件人员也能用python去做验证，一个是让软件人员也能去做芯片验证。目前为止，我们的工具做到可以让软件人员在很短时间内上手，通过提供的一些易读的架构文档，就能很快的投入到实际的验证工作中。大量的人来参与并快速投入才能真正降低芯片验证成本。未来我们会开放报名，让更多的人能来参与，真正去完成这项事情。