4.3 Defined FPGA Design Process

Most organizations have not developed an official defined FPGA design process or procedure. Instead, each individual designer implements the process that they deem appropriate based on their experience and personal preferences. This lack of a common structured FPGA design approach can contribute to FPGA design oversights, errors and inefficiencies. It is crucial to establish a correct level of process to guide and control the development and design process; too much or too little process can both have a significant impact on project progress/efficiency. The correct level of process is a difficult balance to develop and maintain, but it is definitely worth the effort.

Figure 4.1 illustrates a high-level philosophical view of the FPGA design process.

Figure 4.1 Philosophical design flow

A direct relationship can be established between the level of FPGA design process used and the number and effect of design errors on an FPGA design.(The “FPGA design process” can be loosely defined as the established design flow, requirements definition, design architecture definition, documentation, design review process, and design standards.) The need to follow a common defined FPGA design process is based on the need to make and verify a large number of design decisions during the FPGA design cycle. The FPGA design process is inherently complex with a higher degree of design flexibility and larger number of design options than many other potential design implementation approaches. Simply put, with more decisions and available design options, there are more opportunities for mistakes and oversights.

The FPGA design process does not have to be overly formal or add significant overhead to the design cycle. An effective design process focuses on reducing the impact and frequency of design mistakes. The majority of FPGA design decisions can be modified or adjusted during the design cycle with limited design impact. However, there are design decisions and choices that can require significant resources (time, money, budget, and personnel) to change or re-address. These critical design decisions and processes need to be identified and discussed.

A well-developed FPGA process will reference guidelines and establish standards and expectations for project documentation and design reviews. By developing and following an established FPGA design process, it is possible to move toward a standardized FPGA design cycle that is more science than art and far less dependent on individual design team member experience and personal discipline. FPGA design should not be an “ad-hoc” reactive process that relies on trial and error and personal experience to solve design issues.

Clear distinction must be made between architecture phase and the implementation phase. Clearly, separating these two design phases reduces the effect of implementing a less-than-optimum design architecture because the “designers wanted to get a jump on the design implementation” and “so much work had already been done using that particular approach.” A separation between the two phases can be enforced by requiring the development of a presentation and review of the proposed approach before significant design implementation efforts are allowed to begin.

Developing a requirements traceability matrix or a rudimentary testing-and-verification plan early in the design cycle can help the design team to identify incomplete or conflicting design requirements.

It is obvious that generating and updating requirement documents require man-hour of effort. It is certainly possible that any of these efforts may be taken beyond the limit of what can reasonably be supported by a commercial development effort. However, wholesale rejection of all these suggestions because “there simply isn’t the time or budget to do anything other than get the functionality implemented as quickly as humanly possible” is likely to result in an equal or greater number of hours spent later in the design process trying to recover from mistakes made in the rush to get to the finish line as quickly as possible.

A majority of FPGA design mistakes are caused by not following practices that prevent common design failures and oversights to occur. Critical design process steps, decisions and tasks can be identified by their significant impact on an implemented FPGA design and the high cost of reversing or re-implementing.

4.3 明确的FPGA设计过程规范

大多数组织都没有开发一个正式的FPGA设计过程规范或步骤规范。每个设计者基于以往的开发经验和个人喜好，按照自己认为合适的流程完成开 发。缺乏共同制定和遵循的设计过程规范，会造成FPGA设计中的疏忽、错误和低效率。建立一个疏密有当的过程规范来指导和控制开发设计的过程是至关重要的。 过程规范不应该制定得过于细致或粗疏，过于细致或过于粗疏的过程规范都会对工程的进展和效率产生不良影响。在细致和粗疏之间保持平衡是困难的，但是制定这 样一个设计过程规范的努力肯定是值得的。

图4.1给出了理想的FPGA设计过程的高层次视图

（图略）

FPGA设 计过程规范的细化程度与FPGA设计错误发生的数量和设计错误产生的影响之间存在着直接的联系。（这里所说的“FPGA设计过程规范”可以宽泛地定义为：包括需求定义，设计结构定义，设计归档，设计审查过程和设计标准 在内的明确的设计流程。）遵循共同制定的FPGA设计过程规范的需要来自于在FPGA设计周期中制定和验证大量设计决定的需要。由于存在比许多潜在的其他设计实现手段更高程度的设计灵 活性和更多数量的设计选项，FPGA设计过程本质上是复杂的。简单地说，设计决定和设计选项越多，出错误和疏漏的机会就越多。

FPGA设计过程规范不用过于正式，也不应该给设计周期增加显著的负担。有效的设计过程规范着眼于减轻设计 错误产生的影响和减少设计错误发生的频率。大部分的FPGA设计决定如果在设计周期中发生更改或调整，对设计过程产生的影响是有限的。尽管如此，改变某些设计决 定或重新做出某些设计选择将会需要大量的资源（时间，金钱，预算和人员）。对这些关键的设计决定和步骤有必要进行确认和讨论。

制定得好的设计过程规范应该参考通用的设计准则，应该包含工程文档的书写标准和对设计评审的预期要 求。通过开发并遵循明确的设计过程规范，使FPGA设计过程逐步标准化是有可能的；标准化的设计过程更像是科学而不是艺术，它更少地依赖于设计成员的个 人经验和自觉性。FPGA设计不应该是一个“即兴的”反应式的过程（an “ ad-hoc”reactive process），不应 该依靠反复试验和个人经验来解决设计中的问题。

结构设计阶段和实现阶段需要明确地区别开来。往往由于“设计者跳过了结构设计阶段，已经开始了设计实 现工作”和“采用该方法已经做了这么多工作”这样的说法，即使某种设计结构被证明是非最佳的，也不得不被采纳并付诸实现。把这两个阶段分开，无疑减小了这 种效应。为了确保分开这两个阶段，可以在设计过程规范中要求：在开始大规模的设计实现工作前，必须进行结构设计的展示和评审。

在设计周期之初，开发一个需求追溯表或一个初步的测试验证计划，可以帮助设计团队确认出不完整的或 矛盾的设计需求。

很明显，生成和更新需求文档是一项费时费力的工作。诚然，任何一项这样的工作都有可能超出一个商业性 开发工作可以合理支持的极限。然而，由于“除了尽可能快地使功能得以实现以外，实在是没有时间和经费来做任何其它的事情了”这样的说法，对上述建议的全盘 否决很可能会导致在设计过程后期同等的甚至更多的时间花费，用于努力挽回急于求成造成的错误。

绝大多数的FPGA设计错误是由于没能遵循可以阻止常见的设计失败和疏忽发生的准则造成的。设计过程中关键的步骤、决 定和任务可以通过它们在业已实现的FPGA设计中和它们对回溯和返工的高昂代价上产生的显著影响得以确认。