9月26日，开源生态论坛在浙江乌镇召开。论坛第三个环节上，印度InCore半导体首席执行官、联合创始人G·S·马杜苏丹（G S Madhusudan）发表视频演讲。

打开网易新闻 查看精彩图片

全文如下：

大家好，我是InCore半导体首席执行官、联合创始人G·S·马杜苏丹（G S Madhusudan）。

今天，我希望谈谈我们在特定领域架构可调式处理器的设计流程方面所做出的努力。这项工作仍在进行之中。我将和大家分享我们在开发过程中总结出的一些技巧、所犯的错误，以及我认为，其他团队想开展同样的工作时需要遵循的方法。我不会过多赘述我们具体的工作流程，而是会更加侧重我们在开发过程中总结出的通用技巧。

我们所知的每一条半导体行业的定律都走到了尽头。摩尔定律现在几乎不再适用了，登纳德缩放定律已经失效。我们还遇到了其他的问题。单线程性能的提高已经趋于停滞，CPU的复杂度却在不断升级，这意味着我们很难再去不断开发出更复杂的处理器了。安全方面的挑战和复杂的软件语言都在拉低处理器性能。那么，该怎么做才能进一步提高性能？

可能唯一的选择就是特定领域架构。你可以选择设计专用芯片，但问题在于它的软件是不可编程的。如果你想兼顾可编程性和更高的性能，那只能针对一个特定领域对处理器进行优化。要想在大方向上提升，那鱼和熊掌就不可兼得。RISC-V开放指令集架构让我们可以轻松实现DSA架构。问题就在于，我们如何制造使用DSA架构的CPU。当指令集兼容某一类DSA扩展时，设计的难易度就取决于你的工具链，更重要的是对产品的验证。所幸这个流程已经实现了高度自动化，大大缩短了设计时间，否则DSA架构是不可能这么快就得以实现的。

另一个可能出现的问题是碎片化。因为每家公司都只会选用指令集其中的一部分，

这就会引发这样的问题：工具链是由开源社区开发的，一旦指令集和工具链不兼容，你就必须让它们保持同步。这可能会发展成一场噩梦。所以，关键在于，如果想构造基于可配置指令集的处理器，就必须遵循一套可配置的设计流程。也就是说，我们需要一套通用流程和一个通用处理器。快速和超低功耗的处理器核已经有些过时了。虽然它们仍然有市场，但是相比起来，可配置内核正变得更加重要。

考虑到应用负载复杂性所导致的指令集不断演化，我们必须完成流程开发全生命周期的自动化。我们还需要使用代码生成器，并修正构造技术。最核心的想法就是，不要让工程师在低抽象层上工作。理想状态下，工程师应该着手高抽象层的复杂任务，而不是下层那些可以实现自动化的工作，这样才能最大限度地发挥他的专业技能。也就是说，InCore的INflo处理器设计过程旨在实现一个完整的设计流程。我们目前还没有完全成功，但是我认为我们取得了不错的进展。

首先，你需要用标准规格的工具捕捉你的配置，这是因为你需要和指令集兼容。另外，你还需要可配置的处理器核生成器，而不是多核的，因为你不能确定你的DSA应该需要多少个处理器核。最后，你还需要现代化的工具组件，这点我强调多少次都不为过。在我看来，BSV、Chisel、Verilog和SystemVerilog都已经过时了。如果你希望提高生产力以缩短处理器的开发周期，那你必须使用现代硬件设计语言。中间的表示语言，就是BSV语言转换为Verilog语言的部分。市面上有几种新的中间表示语言。我记得Open-Hardware也有一套语言即将发布。我认为，这就是编程语言的未来。Verilog从来就不是为了这个目的设计的。它在仿真目标的验证等方面上存在很多问题。这与我们今天谈论的话题无关，但仍然值得深入研究。

由于复杂程度的激增，经典的验证方法已经不能满足需要了，因此你还需要进行正式验证。任何处理器都包含一些关键组件。如果你能形式化的证明它们的正确性，将会减小你的验证压力。当然，你还需要一套可配置的验证流程组件。

除了设计组件之外，InCore还有两个已经完成或者正在开发的组件。其中RIVER_CORE用于核心级验证，而RIVER_SOC用于片上系统级验证。

顺便说一句，RIVER_CORE是开源的，可以供你使用。Open-Hardware开发的CORE-V-VERIF是一套类似的可配置流程，它同样很优秀，值得一看。一个可配置的指令集需要可配置的内核。

当然，这显而易见，但我还是希望强调一下。你需要以一个基本处理器为基础，然后不断添加组件。你需要捕捉指令集中所有的hook，并最好和微架构的hook一起编进一个配置文件中。然后你需要根据相应的hook配置你的指令集。实际上，使用Chisel语言可以让你的配置更易于使用。在硬件方面，最后我想谈谈对指令集的兼容性是必不可少的。你所有的配置都必须单一映射到指令集中。

下一步是进行微架构测试。你需要用程序生成器和测试生成器自动生成尽可能多的测试项目。对BSV、Chisel等高抽象度语言的覆盖率测试正变得愈发困难。我认为我们应该重新对覆盖率进行定义。

最后，不能不提到软件部分在整个流程中的重要性。通过利用指令集微架构的部分模板，我们应该可以构造编译器扩展和其它工具链的扩展。这对我们来说是一个新生的领域。我们正在和合作伙伴一同工作，以研究我们可以制作的产品。但目前当你添加新的指令时，就必须要设法手动破解编译器。因此这方面的研究是很有必要的。如果没有这样的工具的话，添加新的指令就会像噩梦一样麻烦。单单自动生成一个编译器拓展是很容易的，难点在于让这些拓展得到充分的利用。

总而言之，解决这个问题绝非易事，但是为了缩短基于DSA架构的产品的开发周期，这个问题我们必须解决。

我的整个报告都围绕着实现自动化和缩短周转时间两个话题，这是因为如果基于DSA架构设计一个产品需要花费2-3年的话，没有人会使用DSA拓展的。

今天我就讲到这里。感谢大家的聆听。祝大家生活愉快。