如何防止基于 FPGA 的项目误入歧途

在我的职业生涯中，我参与了为一些非常有趣的项目开发大量 FPGA 设计。遗憾的是，我还参与了拯救一些严重误入歧途的 FPGA 设计的工作。当我处理这些问题设计时，很明显——尽管目标应用程序和开发团队的成员不同——这些设计有一些共同点，这些共同点在第一位工程师甚至坐下来写第一行之前就注定了它们的失败HDL代码。

考虑到这一点，我想我会解决我在拯救这些项目的过程中观察到的五个常见问题。这些问题如下：

#1： 第一个问题不仅与基于 FPGA 的开发有关，而且与一般的工程有关。问题在于启动时没有稳定的需求基线。总是希望在需要证明进展的基础上在需求仍然成熟时开始项目。然而，如果我们在没有完全理解需求的情况下开始开发，那么——很多时候——任何最初的进展都会被证明是错误的，并且执行下游更正会引入额外的延迟和成本。过早开始实际上会在开发中引入风险，而这种风险需要降低。我明白，根据手头的应用程序，需求的深度和细节可以扩展。我期望 SIL4 系统比商业系统有更多、更详细的要求。然而，总而言之，如果需求没有从一开始就达成一致和基线，就会出现范围蔓延。尽管设计开始时可能是针对所理解的需求的合理架构，但当开发人员试图随着基线的成熟而硬塞入新功能时，它会变得越来越复杂。用不了多久，东西就会坏掉。

#2： 在了解了需求情况之后，团队的每个成员都需要了解开发 FPGA 的计划。因此，最好有一个计划来定义从启动到交付所遵循的方法，确定所涉及的主要步骤以及将在开发过程中应用的工程审查门。除了计划之外，我们还需要记录架构和设计，确定每个主要功能，决定哪些功能要新开发，哪些功能要利用第三方 IP 或重新使用现有 IP（更多关于这个之后）。这种组合的计划、架构和设计描述文档将使工程团队能够清楚地了解手头的任务。我们还可以将所有功能追溯到需求集，以确保所提出的方法满足所有高级需求。

#3： 设计模块和整个 FPGA 需要时间；然而，需要更长的时间来验证设计并确保它满足其要求。这种验证不仅需要包含逻辑功能，还需要在设备的所有可能运行条件下执行。反过来，这意味着有必要为设计制定明确的验证策略；这不再是仅仅编写代码，执行一些模拟，然后将设计投入硬件的情况。

#4： 有时，我们都非常接近事物并陷入沉思，以至于当我们错过了什么时就很难发现。这就是发明工程设计审查的目的。通过进行这些审查，我们可以确保我们遵循良好的工程实践并遵守内部开发标准。重要的是，它们还为独立工程师提供了查看设计（其架构和实现）的能力，以确保其提供所需的功能。如果我们不随着设计的进展进行审查，我们将无法提高质量，并且会增加任何下游集成问题。

#5： 到目前为止，您可能已经注意到，我提出的大部分要点都与流程和更广泛的工程方面有关，而不是设计本身的编码。当然，开发代码很重要，但确保我们利用第三方 IP 并重用内部 IP 也很重要。理想情况下，我们应该尽可能多地重复使用我们库中的现有 IP 块。如果这是不可能的，我们当然会需要开发新模块。在这种情况下，我们应该首先考虑以可以在未来项目中重复使用的方式创建这些新模块。为了帮助我们创建这些新块，我们应该考虑使用高级综合 (HLS) 工具。通过让我们能够在更高的抽象级别上工作，这些工具能够更轻松地探索解决方案空间并降低风险、开发时间和成本。

上面提出的要点只是我在拯救 FPGA 设计时注意到的一些事情。我很想听听您对误入歧途的项目的看法。