发现了一篇有关FPGA的好文分享给大家，共同学习

xydyyt

在我的职业生涯中，曾经为一些很有趣的项目做过FPGA设计，也曾挽救过许多误入歧途的FPGA设计。我在处理这些问题设计时发现，虽然目标应用和开发团队的成员不同，但这些设计显然有一些通病，使设计从工程师坐下来写第一行HDL程序代码时，就注定了项目失败的命运。


有鉴于此，我想有必要介绍一下我在挽救这些项目时发现的5个共同问题。这些问题是：


问题一：第一个问题是在项目开始之时没有明确需求基线。这个问题不只与基于FPGA的开发有关，它与工程是普遍相关的。人们经常会在需求仍未成熟、还需不断修改之时就急忙进行项目。但是如果我们没有完全理解需求就匆匆开始开发，就可能出现初始步骤错误的情况，接下来的纠正则会带来延迟和额外的成本。


太早开始项目会带来开发风险，而这个风险需要降低。幸运的是，需求的深度和细节可以根据具体的应用进行修改。我期望为SIL4系统而不是商用系统提出许多更详细的需求。总之，如果一开始对需求没有达成一致意见，或没有形成正确的需求基线，就会出现范围蔓延问题。虽然一开始设计的架构非常合理，符合需求，但随着需求基线的成熟，开发人员会尝试加入新的功能，从而使架构越来越复杂。这样用不了多久就会发生问题。


问题二：在理解需求细节之后，每个开发人员还应了解开发FPGA的计划，因此需要制定一个计划，定义从项目启动到交货要遵循的程序，确定主要开发步骤和工程审查点。


除了制订计划外，我们还需要以文文件的形式记录架构和设计，确定每个主要的功能，看哪些功能是需要新开发的，哪些可以利用第三方IP或再利用现有IP(以后会越来越多)。计划、架构和设计描述文文件可以说明工程技术团队理清手头的任务。我们还可以按照具体需求检查所有的功能，确保提议的方案能够满足所有高层需求。


问题三：设计模块和整个FPGA需要花费时间；但耗时更长的任务是设计验证，以确保设计满足需求。这种验证不仅需要包含逻辑功能，还需要在组件所有可能的工作条件下进行。反过来说，这意味着有必要针对设计开发一个清晰的验证策略；这不再只是写写程序代码、执行一些仿真程序，然后将设计扔给硬件这么简单了。


问题四：很多时候我们会因为过于投入某件事情而难以发现其中的问题，这正是引入工程设计审查的目的。透过审查，我们可以确保遵循良好的工程操作方法，并符合内部的开发标准。另外，它们还能帮助独立工程师检查设计的架构和实现，以确保提供所需的功能。如果在开发过程中不经过审查设计，可能就无法实现高质量的设计，并且可能增加下游的整合问题。


问题五：到这里你可能注意到，我提出的大多数观点和过程是与更广泛的工程而不是与设计编码本身有关。开发程序代码固然重要，但是确保我们利用第三方IP和再利用内部IP也同样重要。


理想情况下，我们应该尽可能再利用链接库中的许多现有IP块，当不可能利用时，当然需要开发新的模块。在创建新模块时必须时刻牢记，这些模块在未来的项目中应能再使用。我们应该考虑使用高层次综合(HLS)工具来说明创建这些新模块。因为允许我们工作在较高的抽象层，这些工具可以帮助我们更容易地拓展解决方案空间、缩短开发时间，并降低风险和成本。