3.2.1需求阶段

为了以最少的迭代次数快速实现设计,工程需求应该清晰、明确且保持稳定。需求文档不一定很正式——可以像微软Word中的简报一样简单——但是理想状态下需求文档应该尽可能完整且易于维护。包含表格的文档或者电子表格都是很不错的样板。（电子表格的缺陷是每个表框内所容纳的字符受限。）需求文档里应该包含正式或者非正式的配置/版本控制。最好也应该指定谁可以在什么情况下更新需求。

各种文档齐全有助于添加资源到工程中，也有助于在有限的方式下查看原始设计团队的工程。许多FPGA设计日程（和预算）安排自由度太大，导致很多需求改变对于设计周期来说太频繁或者太迟。为了控制好整个开发流程，需求必须得到有效的管理。

使用FPGA设计需要注意的一个问题在于FPGA太灵活了，以至于让人觉得可以不加限制的随意变更工程的需求。实际上任何变更都可能极大的影响到工程结构，乃至日程安排。所以应尽量限制对实际需求的更改次数和影响范围，尤其是在当工程正处于开发过程中时。项目的团队要尽可能用正式的文档收集并记录FPGA模块需求和功能需求。记录的目标是使得需求说明尽可能正式化，同时注意防止给工程添加额外的负担。谁可以更改需求、为什么更改需求，都要受到一些限制。注意需求文档的更改是团队决定的，而文档的是由个别的负责人或是文档作者进行更新。一定要保证文档的版本是最新的，并且保证需求文档的更新（添加或更改）是整个设计团队做好沟通的结果。

添加任何新的需求都要通过工程更改单(ECO)的方式实现。新的需求对设计的潜在影响有哪些？是额外的资源吗？是否会影响工程的日常安排？FPGA设计性质决定了不可能在工程设计的早期就能提供一份“完整”的设计需求，需求就好像一个“移动的目标”。我们的目的是限制这个目标移动的范围和速度。如果需求更新没有一套完善的规则和既定的手续，并且在需求到达关键设计模块之前工程已经启动或者需求更改过于容易，那么会由于工程“流失”导致过去的努力都付诸东流。

需求应该定义必须实现的功能。需求文档该指明需要什么功能，而不是如何实现功能。接口定义很关键，更多的细节内容可能有助于设计流程的简化，从而提高效率。举例说明包括：需要什么信号？将使用什么样的信号状态、等级、数据格式和协议？多快的运行速度？有何特殊的时序要求？是否有可测试性要求，如内嵌的自检测（BIST）支持或者扫描链支持？设计者应尽量记录所有可能的设计约束：功耗、热量、封装、I/O数量，接口需求和机械（尺寸）限制。在尚未完全定义出最终细节的部分,需添加尚未决定（TBDs）标识，提示此处设计步骤需要另外再做决定。尽量对硬件需求、固件需求与软件需求进行分类。有些需求是完全无法协调的，而有些需求与其说是固定的不如说是“有它更好”。需要避免的是多次重复设置或以不同方式完成同样的需求，这样可以保证文档条例清晰，易于应用和更新。设计者应将相关的需求集中写成一组，但是还是要将每个需求孤立成单独的部分，而不是写成复杂的句或段。避免盲目的目标设定和对工程未来需求的过分设计；应该确定当前需求的设计，同时指明未来的实际目标。