设计SoC不再仅仅是核心。
对于今天的芯片架构师和设计师来说，RISC-V中的“ISA”只是一个小问题。问题甚至不在于选择“核心”。今天的设计师面临着一个“整个系统”的问题——一个系统复杂性的问题。
这一事实在我向人们展示的解释UltraSoC嵌入式分析架构的图片中是隐含的。它展示了一个SoC的块级表示，具有广泛的计算节点、内存和自定义逻辑，由一个NoC连接。其中一个计算块是RISC-V处理器。这是一个重要的组成部分。但这只是其中之一。在可预见的未来，甚至可能永远，RISC-V都将与其他架构一起使用。
一切都会改变，但我们面临的不是二选一。
核心问题是，在这个系统复杂的时代，我们需要做什么来建立一个一致的基础设施来支持设计师?例如，我们如何成功地将RISC-V与Arm处理器一起使用?
有许多问题需要处理:越来越多的系统没有架构(在公认的意义上);在软件方面，特别编程范例;processor-processor交互;硬件软件交互;互连，NoC和死锁;处理一致性。
在顶层，我们需要交付异构(即它们应对不同处理器的存在)架构和建模探索系统。应该可以输入运行时系统数据来关闭该环境中的循环。
我所描述的架构工具是必要的，但还不够。当我们实现设计时，我们需要真正异构的核心工具链——一个系统中不同核心的单一驾驶舱。在调试的世界中尤其如此。开源工具(如GDB和OpenOCD)需要以有效的方式处理这个问题;但我们也必须承认，许多工程师并不信任开源工具。他们更喜欢使用成熟、健壮的商业工具，这些工具支持良好、定期改进，并且适合工程师将要使用它们的特定目的。
最后，迫切需要能够让工程师清楚地看到系统运行时行为的工具——这些工具需要开放的api，以便信息可以在工具链的不同部分之间传递。朝着不那么结构化和纪律化的工作方式发展的趋势不会消失:在许多领域，比如机器学习，芯片的行为本质上是不确定性的。
这就不可避免地产生了对运行时更好的可见性的需求，以及对能够解释和分析运行时行为的工具的需求——具有像自主因果关系检测这样的强大功能，以帮助工程师通过人类大脑无法独立理解的复杂层次。
RISC-V社区在构建一个新的生态系统的过程中，处于独特的地位，能够应对系统复杂性的挑战。现在，我们需要将注意力从ISA和核心转移到更广泛的问题上，这些问题正在实践当今设计师的思想(并在此过程中制造痛苦!)部分原因是，正如我所说，在未来很长一段时间里，RISC-V将与Arm等更成熟的架构一起使用。同样重要的是，我们需要创建一个有利的环境，鼓励开发这些异构系统的开发人员所需的商业和开源工具。
|
|
|
|
|
|
|
|
|
|
“核心问题是，在这个系统复杂的时代，我们需要做什么来建立一个连贯的基础设施，为设计师提供支持?例如，我们如何成功地将RISC-V与Arm处理器结合使用?”
将中断处理程序和驱动程序移出应用程序内存。大约60年前，IBM用非常成功的360系统做到了这一点。有一个开始IO，通道控制字独立于CPU执行，在结束时有一个IO中断，状态字指示完成。
当你看到一个RISC ISA时，你已经看到了所有的RISC ISA，因为没有一分钱的区别。
每次加载一个操作数，加载操作符并重复操作，不管有多少个操作符，最后存储结果。
神奇的是，2 + 2 = 4只需要4条指令。
最重要的是，应用程序是用编译语言编写的，因此只有编译器的后端才能看到ISA。