FPGA/HDL 开发的 10 条规则

HDL 开发的 10 条规则

编写良好的、可移植的、可重用的 HDL 代码，使设计能够以所需的频率实现，这绝对是一个挑战。

为此，许多（不是大多数）专业组织都有编码标准。不过，编码规则可能会成为战场。一些公司的编码规则非常复杂，不仅控制代码结构，还控制格式和命名，而有些公司则稍微宽松一些。

但是，如果你是专业开发 FPGA，或者是作为爱好者，都应该有一些基本的编码规则。当你来到项目的后端并且必须实现时序收敛时，遵守这些基本规则可以节省大量时间和精力。为此，我开始思考我的 HDL 开发的 10 大规则是什么？？

• 状态机——只是单个进程。忘记关于组合部分和顺序部分的学校和课程。所有状态机都应该是单个进程。这有助于调试，防止锁存器的出现，并确保所有输出都是寄存器类型，从而减少毛刺并帮助我们实现时序收敛。

• 状态机——尽可能多地从状态机中解耦功能。这意味着确保计数器等位于它们自己的进程中（在 FSM 进程之外）并由来自 FSM 的信号控制。这种解耦使FPGA的实现对于 FSM 和计数器都更加优化，结果会得到更好的结果质量。
• 状态机——理想情况下，状态机应该在们自己的单独文件中，与其他代码元素分开。我会允许在同一个文件中解耦计时器和其他元素。
• 推断——只要有可能，编写代码时，应使综合工具能够推断出它所绑定的逻辑结构（例如，DSP48、BRAM 等）。这使得代码可以随着系列之间架构特性的变化（例如，DSP48 到 DSP58）而更方便移植。
• 实例化——当无法执行推理并且必须实例化组件时，应该在架构顶层的文件中。这使得替换或更新实例化的 IP 更容易。
• 实体/模块——每个进入或离开模块的信号都应该被注册。这有助于解决时序收敛问题，尤其是当我们以更快的频率运行时。
• 使用标准接口——使用 AXI4、AXIS、AXI4-Lite 或其他标准，如果是纯 HDL 设计，例如使用wishbone总线在模块之间进行通信。这简化了架构元素对具有大量矢量端口和相关握手信号的需求，这些端口需要连接、布局和布线，并实现时序收敛。如果需要流水线实现时序收敛，这些接口通常也更加灵活。
• 不要将结构代码和功能代码混合——这使重用变得方便而简单，因为功能代码位于单独的文件中可以轻松重用。同样，结构代码文件更容易理解，因为它们只是定义解决方案的配置。
• 命名——在整个设计中使用合理的变量名称，这些名称具有描述性，有助于提高可读性。考虑使用 i_ o_ s_ v_ 等前缀来标识正在访问或处理的变量的类型。前缀比后缀更有效，因为变量名称的大小会发生变化。如果想要进行更改，使用前缀可以简化批量编辑（竖选）。
• 文档 – 可以让阅读正在使用的 IP 的文档了解其工作原理（不要以为你知道它是如何工作的）。UltraFast 设计方法参考指南值得阅读，可以学习编码结构（例如，复位和控制信号）。同样，在设计中包含自己的文档也是一个好习惯。有几种开源工具可以使用，例如用于时序图的 WaveDrom、用于框图的符号器、用于寄存器定义的位字段等。能够将这些包含在源代码中是理想的，因为它可以防止文档丢失。在这种情况下，推荐TerosHDL 编辑器（https://terostechnology.github.io/terosHDLdoc/）。

遵循这些规则，能够创建优秀的 FPGA 设计，这些设计不仅可以以所需的速度实现，而且还具有灵活性并能够实现大量重用。但是，我将添加两个额外的规则：

• 仿真你的设计——在考虑实施之前，请确保顶层文件有一个测试台，该测试台可以证明设计按预期工作。设备上调试仅用于集成类型问题，而不是验证设计是否有效。
• 使用 GIT 等版本控制系统，并认真使用问题跟踪和发布功能。它真的可以帮助你，让你摆脱困境。

这些是我的 HDL 开发的前 10 条（好吧，12 条规则）。我很想知道如果是你，你会考虑添加哪些规则？