基于FPGA的快速系统原型开发.pdf

《基于 FPGA 的快速系统原型开发》 CH3.2.1 译 3.1 概述 与其它工程学科一样，绝大多数成功的 FPGA 设计团队都遵循着一套固有的设计 流程。 对于大多数的工程项目， 开发流程中每个设计阶段的顺序及其相互间的关系都是固定 的。高层次 FPGA 设计流程包括了从设计需求的定义到最终产品的量产所必须经历的各个 阶段。图 3.1 给出了高层次 FPGA 设计的流程图。 图 3.1 FPGA 设计流程 为了快速有效的完成系统开发，采用并遵循优化的设计流程是绝对必要的。这种 优化的设计流程有利于设计团队处于一种尽可能高效率的开发环境中， 将更多的时间和精力 投入到设计本身的实现上来。 该设计流程需要设计者在适当的时候进行设计检查， 并明确设 计的关键阶段、 每个阶段的主要目标和预期成果。 优化的设计流程也应突出关键的设计决策， 也鼓励设计参与者为做出这些决策而努力。 FPGA 设计流程所固有的重复性，几乎是 FPGA 设计流程的各个阶段都不可避免 的。许多设计决策如 FPGA 3.2.1 需求阶段 为了以最少的迭代次数快速实现设计 ,工程需求应该清晰、明确且保持稳定。需求文档 不一定很正式——可以像微软 Word 中的简报一样简单——但是理想状态下需求文档应该尽 可能完整且易于维护。包含表格的文档或者电子表格都是很不错的样板。 （电子表格的缺陷 是每个表框内所容纳的字符受限。 ）需求文档里应该包含正式或者非正式的配置 /版本控制。 最好也应该指定谁可以在什么情况下更新需求。 各种文档齐全有助于添加资源到工程中， 也有助于在有限的方式下查看原始设计团队的 工程。许多 FPGA 设计日程（和预算）安排自由度太大，导致很多需求改变对于设计周期 来说太频繁或者太迟。为了控制好整个开发流程，需求必须得到有效的管理。 使用 FPGA 设计需要注意的一个问题在于 FPGA 太灵活了，以至于让人觉得可以不加 限制的随意变更工程的需求。 实际上任何变更都可能极大的影响到工程结构， 乃至日程安排。 所以应尽量限制对实际需求的更改次数和影响范围，尤其是在当工程正处于开发过程中时。 项目的团队要尽可能用正式的文档收集并记录 FPGA 模块需求和功能需求。记录的目标是 使得需求说明尽可能正式化， 同时注意防止给工程添加额外的负担。 谁可以更改需求、 为什 么更改需求， 都要受到一些限制。 注意需求文档的更改是团队决定的， 而文档的是由个别的 负责人或是文档作者进行更新。 一定要保证文档的版本是必威体育精装版的， 并且保证需求文档的更新 （添加或更改）是整个设计团队做好沟通的结果。 添加任何新的需求都要通过工程更改单 (ECO) 的方式实现。 新的需求对设计的潜在影响 有哪些？是额外的资源吗？是否会影响工程的日常安排？ FPGA 设计性质决定了不可能在 工程设计的早期就能提供一份“完整”的设计需求，需求就好像一个“移动的目标” 。我们 的目的是限制这个目标移动的范围和速度。如果需求更新没有一套完善的规则和既定的手 续，并且在需求到达关键设计模块之前工程已经启动或者需求更改过于容易， 那么会由于工 程“流失”导致过去的努力都付诸东流。 需求应该定义必须实现的功能。需求文档该指明需要什么功能，而不是如何实现功能。 接口定义很关键， 更多的