Opentitan硬件设计说明

Opentitan硬件设计说明

本文档旨在说明如何在 OpenTitan 项目中开始硬件设计。 这里所说的设计一般是指一种新的可移植外设，但可以包括高层次的架构设计，如设备的复位策略等。这部分主要是为了从头开始创建新设计的说明，但也有关于如何为现有设计做出改进的说明。 它针对 RTL 设计人员，以明确声明功能、寻找其他人进行审核等的典型流程。我们的目标是在增加清晰度和不过度规定规则和流程之间取得合理的平衡。 有时需要采取更有条理的方法，这些将在本文档中着重强调。 欢迎反馈和提出改进意见！

设计的阶段

Opentitan的硬件设计的生命周期在硬件开发阶段文档中有所说明。硬件设计被分为三大阶段：规范(Specification)、开发(Development)和签核(Signed-off)。 本文档试图就如何开始第一阶段并顺利过渡到开发阶段提供指导。 需要说明的是，这不是硬性规定，而是我们在opentitan项目中所使用的方法。

概念和RFC

设计的概念可能来自各种方面：

1. 根据未来产品需求所要设计的模块;
2. 扩展产品功能所需的新设计;
3. 值得引发广泛讨论的设计思路;
4. 甚至可能是现有设计的新方法（更高的性能;更安全等）。

无论是哪个方面的激励，这个概念都应该被写成一个具有基本特征的简短提案。 这与对现有设计的微小修改建议不同，后者可以作为与现有设计关联的 GitHub 拉取请求或问题文件进行处理。 此提案应采用 Google Doc 媒介，以实现快速的审核。 理想情况下，系统会在团队云端硬盘中创建此提案文档，但如果作者无权访问团队云端硬盘，他们可以共享私下创建的文档。

我们建议设计方案应遵循RFC（Request for Comment, 征求意见）流程，该流程会处理所有的此类提案。 如果 RFC 可能包含可能与认证相关的信息（要共享的指南），请先向 security@opentitan.org 发送注释以获取反馈。 OpenTitan技术委员会也许能够建议其他合作者来帮助初期的审查。

我们将提供一个规范的 RFC 的示例 (TODO)。

详细规范

简短的设计提案一旦通过了对功能集和高级描述的初步审查，以及潜在的安全审查，设计者就需要提供Google Doc形式的完整的详细规范。 内容、形式和格式已在设计方法和文档方法指南中说明。 最终所呈现的结果应是一个可供其他项目成员进一步详细审查的设计规范。 设计规范的内容和状态可以与团队共享。

规范详细规范的一个示例是 pinmux 规范，该规范可以在 TeamDrive 的TechnicalSpecifications –> deprecated目录下找到。 （在GitHub上转换为Markdown的Google Docs存档在这里）。

请注意，在开发 OpenTitan 安全 IP 时，设计人员应遵循安全硬件设计指南。

初始架构

在发布和审查设计规范的同时，可以开始初始架构设计。 有很多方法可以避免在实施过程中的“大爆炸”，并帮助设计者通过最终的代码审查。 一种推荐的方法如下：

• 从包含 Hjson 格式寄存器内容的完整或接近完整定义的框架开始
• 与包含该文件的基本的Markdown相结合
• 结合对自动生成的寄存器模型实例化的 IP 顶级 Verilog 模块（请参阅寄存器工具文档），包括所有已知的 IP 级 IO、时钟和复位。
  以上这些不是强制性的，但达到了通过首次审查的基本条件，以及随着时间的推移的完整自定义详细信息。 不管是否是第一次提交设计，当然应该是可编译的，语法正确的，遵守编码风格指南，可移植性等效等，如设计方法用户指南所示。

初始架构设计的一个很好的例子可以在 AES 模块的116号合并请求中看到。

作为GitHub提交过程的一部分，Google Doc规范必须转换为Markdown规范。 （提示：有一些Google Doc插件可以将规范转换为Markdown格式）。 完成此操作后，团队云端硬盘上的所有规范都应移至云端硬盘的已弃用部分，顶部会显示一个链接，表明该文档仅用于历史目的。 这仅适用于源自驱动器的规格。

完整设计

一旦 IP 块准备就绪，就可以将其包含在顶层设计中。 为此，请按照以下步骤操作：

• 就是否以及如何集成 IP 块达成一致。
• 确保 IP 块的质量可接受。
• 确保顶级模拟不会受到负面影响。
• 打开包含必要代码更改的合并请求。

如果不清楚如何继续，请随时提交问题以寻求帮助。

中断更改

除了 RTL 更改之外，更改 IP 块的中断还需要一些额外的工作。

• 如果存在 DV 环境，则其测试平台要有可以连接tb.sv的端口。
• 如果 IP 块已在顶层中实例化，则需要重新生成该顶曾以包含新的端口。
• 自动生成的 DIF 需要重新生成。
• PLIC测试也应该更新。

第 1 项无需赘述， 下面展示了如何执行第 2-4 项。

更新顶层

$ make -C hw top

在你修改完IP,IP顶层模块，IP寄存器接口以及DV测试平台之后，你可以利用上面的命令重新生成顶层。 这将读取文件并更新中断信号，并在需要.hjsontb, .sv 和.hjson时重新生成PLIC模块。

新的DIF

需要注意的是，重新生成TOP并不能解决所有问题。 如果更改了中断名称或引入了新的中断，则应重新生成 IP 块的 DIF。

$ ./util/make_new_dif.py --mode=regen --only=autogen

上面的命令会在 .sw/device/lib/dif/ 目录下更新DIF自动生成的部分。

如果 IP 块的 DIF 已经使用了内部的中断枚举，则需要手动修改引用。在大多数情况下，中断名称后接 PascalCase（e.g） 中的 IP 名称，然后是 PascalCase（e.g） 中的中断名称。 例如， 要引用顶层 PLIC 枚举中的中断，格式为 ：后跟 PascalCase 中的 IP 名称，然后是 PascalCase 中的中断名称。 比如：

.kDifSpiDeviceIrqRxFullkDifSpiDeviceIrqRxFullkTopEarlgreyPlicIrqIdkTopEarlgreyPlicIrqIdSpiDeviceRxFull

PLIC测试

如果中断次数已更改，则需要手动修改软件单元测试。

打开宏并将其更改为当前中断编号。 然后，找到并修改 Bit 值或添加下面的内容(如果添加了新的寄存器)。

.sw/device/lib/dif/dif_rv_plic_unittest.ccRV_PLIC_PARAM_NUM_SRCRV_PLIC_IE0_REG_OFFSETRV_PLIC_IP0_REG_OFFSETIEIP

ps：本篇为 google 开源项目 opentitan 的硬件设计说明的大致翻译，笔者水平有限，仅供参考。