《基于FPGA的快速系统原型开发》CH3.3译

《基于FPGA的快速系统原型开发》CH3.3译

3.3 小节

       本章讨论了优化高层次FPGA开发流程。这里指出并讨论了各个设计阶段的关键环节。开发实现优化的设计流程能够使设计团队降低甚至消除风险因素，达到最大的效率从而增大成功的几率。开发期间尽可能的减少或消除设计错误和疏忽是成功的快速系统开发的关键点。

       为使开发效率最大化，设计团队必须充分了解整个设计流程，并在每个设计阶段有所展望，以确定当前的决策将对后续的设计阶段产生怎样的影响。设计团队应该制定并维护好详细的功能规格说明书，这本说明书会将潜在的设计增强和改进考虑在内。理想状态下，设计团队必须在整个开发周期中保持FPGA设计的灵活性。这将增大设计团队做决策时可选择的余地。以下列出了对于快速系统原型开发努力很重要的一些设计关键点。

l        追求一种基于系统的板级、FPGA级设计方法，从而最大化系统灵活性

l        可以使用面包板进行早期的功能验证，以此减少设计风险和开发时间

l        市场调查对于整个FPGA设计周期都很重要

l        设计余量也是FPGA设计的关键

l        合理的设计分割与分等级的设计能够减少设计改变和更新的影响，从而加速开发

l        同步设计对于可重用设计很关键

l        设计工具的选择在设计实现和调试中扮演了一个重要的角色

l        在整个设计流程中，在适当的点进行测试和仿真对于消除设计瑕疵都是很关键的

《基于FPGA的快速系统原型开发》CH3.2.4译

《基于FPGA的快速系统原型开发》CH3.2.4译

3.2.4 验证阶段

    设计不仅必须实现既定功能且正常运转起来，也必须支持高效的设计集成、验证（调试）和维护。在设计流程的早期就必须考虑在设计过程中如何能够存取到整个设计及其各个独立单元的信号。在重大系统不进行拆分的情况下，调试时无法对开发系统进行检测或访问是很糟糕的事。应当在设计早期花精力放置一些关键设计元件（指示灯、开关、电源质量验证通道、测试插座、配置插座、地焊盘），以使得在设计的各个阶段都很容易的访问到需要的信号。考虑到访问的需求，应将关键设计元件作为系统机械设计的一部分。

    设计的调试和验证阶段应尽可能最优化。可以制作一个确认/测试计划来验证设计的有效性和完整性。如果条件允许，可以尝试让模块设计者以外的人来验证FPGA的功能。

    添加足够的测试点有利于更容易的访问到FPGA器件内部任何需要的节点或一些原本不易于被访问到的接口信号。在整个开发周期中，包括完全或即将完全装配好的最终交付产品，应力求能够方便的访问到测试点、测试插座和配置端口。在设计可以交付给用户之前，考虑将被验证的功能，包括任何信号的访问和可以简化FPGA功能验证的特定电路。考虑在设计中添加内部自检测功能（BIST）。如果最后的设计配置无法支持实现BIST的资源需求，也可以考虑另外设计专用于测试与自检功能的FGPA部件。

    如果将来有很好的机会把设计转换成ASIC，可以执行覆盖关键功能的测试向量并记录FPGA仿真结果。若要执行第二次测试加载，需确保FPGA配置存储器能够支持第二次加载，并且执行方式能够控制何时以及如何加载FPGA的“测试”版本。

    调试以及验证包括更多的细节将在后续章节中讨论。

《基于FPGA的快速系统原型开发》CH3.2.3译

3.2.3 实现阶段

    设计工具集是实现阶段重要的一部分。设计团队应该拥有一套能够舒服有效完成相应工作的工具集，这些工具集不一定是最好的，只要合适日程、任务和工作环境要求即可。如果设计团队没有当前工作最适用的工具集，可以对何时具备合适的工具制作一份日程表，以帮助设计团队保持热情和动力。

    尽可能的减少影响设计的各种因素，因此设计进行中最好能够使用一套统一的软件工具集。这通常要求在整个设计阶段使用相同的软件工具集进行设计。软件版本的更新通常应该在不同的工程之间。如果需要在同一个工程的设计流程中更新软件，应该是基于实际的需要，而非因为希望保持软件版本是“最新”的。如果发现了影响当前设计的问题，应该考虑进行软件的更新，可以用一个更新的软件版本进行覆盖或者使用诸如安装补丁的方式进行软件版本更新。一旦升级到一个更新的软件版本（或者通过安装补丁的方式升级到最新的软件版本），设计团队必须清楚的知道：

l   软件的更新是由于什么原因？

l   新的软件版本是否与之前的版本相兼容（例如，是否能够在不同的软件版本间还原或升级）？

l   软件更新修正了什么问题？

l   软件的哪些方面得到了改善？

l   新软件存在哪些已知的问题？

l   这些问题是否影响设计？

l   安排何时解决已知的问题？

l   设计的新旧版本软件是否可以在一台电脑上并存？

l   新旧版本软件间能否还原或升级而不造成任何软件本身的问题和并发问题？（设计在升级到新版本软件后却不能还原回原版本，这样的问题并不罕见）

FPGA在产品开发中的最主要优势是能够在线重配置。这样，设计中的问题能够通过FPGA器件的功能实现得以解决。设计团队不应将FPGA解决问题的能力仅仅局限于FPGA器件的功能，因为这样可能限制了FPGA器件从系统角度看可能的功用。

在FPGA以外发生的板级问题，如果FPGA可以访问这些相关信号，那么也有可能通过FPGA来解决这些问题。如果已选择了一个具有充足逻辑门资源和可用I/O余量的器件，可以有选择的增加一些并非FPGA设计必须的走线来协助既定功能的实现。如果执行这些额外的努力，有很多问题必须考虑在内，包括：哪些信号？多少信号？增加的信号是否影响FPGA性能？一个实际的折中办法是，使用与FPGA连接的信号走线支持将来可能添加的新功能，并在连线上串上一个表贴、零欧姆的电阻。这种做法也使得在不添加飞线的前提下，很容易就能访问到可能需要的信号。其他好处包括隔离FPGA周边潜在的噪声信号（不焊接零欧姆电阻），如果需要的话，可以为设计更新或访问FPGA内部信号添加焊盘。零欧姆电阻方式仅限于低速、非关键信号。额外的板级设计努力和面积需求通常被证明是有益于改善设计灵活性的。

    FPGA的PCB板设计完成后也可能支持和实现额外的功能。这是一种超前的设计理念，这些额外的功能包含能够访问必要的板级信号和时钟，足够的功率和资源，能够包含一些原先并未在最初FPGA产品开发中定义的扩展的功能。通常随着设计的深入，这些特性是“最好能有”，但并不一定是初始设计的一部分。只要事先做好合适的计划和准备，FPGA器件一般都能够兼容额外的特性和功能。

    设计者若要达到这种设计能力，就必须对设计本身和将来可能实现的改进功能有一个系统级的认识。为了支持潜在的新特性，实现特定功能的信号和时钟应该事先与FPGA相连。对未来可能的需求进行规划也有助于这些特性更易于实现和支持。

    实现阶段另一个重要的方面是同步设计。同步设计对于实现高效的、可维护的、可支持的设计是至关重要的。使用同步设计后，独立的仿真、结构和工艺实现能够可靠、稳定、简化的进行，并简化了约束实现。第7章会对同步设计做更多的讨论。以下列出了实现同步设计的一些主要目标相关的要点。

l   避免门控时钟（避免产生内部逻辑或分频产生的时钟）

l   适当的使用低偏斜的全局时钟资源

l   使用时钟使能而非门控时钟

l   使用专用时钟块和全局走线从而最小化偏斜

l   避免门控异步复位/置位

l   用寄存器对异步输入打一拍

《基于FPGA的快速系统原型开发》CH3.2.2译

         在抽空翻译第三章的同时，特权同学也陆陆续续的细读到了这本书的第14章。体味最深的两个字叫“精彩”，感觉最想说的四个字叫“相见恨晚”。书中所阐释出来作者的点滴经验之谈都有些似曾相识，要是能够再早一些看到这些，也许可以再少走很多弯路。但是，书中有更多我所未曾经历未曾领悟的东西，这样一本“葵花宝典”是值得每一位FPGA工程师用心去学习的。就如riple兄所言，也许对于我们这些已经入了门，市面上国内出版的书都懒得去翻的时候，也许我们更需要这样一本能够带领我们身临其境的进入开发设计中每个环节（细节）的好书。

         我也不得不承认，在逻辑设计领域，我充其量不过只是个新手而已。项目做得还不够多、不够深、不够广，但这一点都不影响我对FPGA开发设计的热爱，也唯有抱着“谦卑谦卑再谦卑，追求追求再追求”的心态，才能够长久的在这个领域持续长进。也正是因此，我才格外推崇这本书。

         特权同学的E文水平也确实够烂，但是很庆幸有我的另一半做最坚强的后盾，花时间花心思核对修改这些对她而言也许是很枯燥乏味的文字。在这里再次表达我的爱意和谢意。

         个人时间、精力以及能力所限，不可能翻译得尽善尽美。还希望各位网友多提宝贵意见和看法，大家齐心协力尽可能原汁原味的用中文诠释作者的意思。

         也欢迎感兴趣的朋友一起加入我们的《基于FPGA的快速系统原型开发》翻译小组共同讨论：http://group.ednchina.com/2376/

         下面送上新鲜出炉的3.2.2小节的原文和译文。

《基于FPGA的快速系统原型开发》CH3.2.1译

3.2.1 需求阶段

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

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

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

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

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

《基于FPGA的快速系统原型开发》CH3.2译

3.2 FPGA设计流程

    高层次的FPGA设计流程包含了需求分析、结构设计、实现以及验证。在需求分析阶段，定义并完善高层次的需求，这一阶段的任务是完成系统功能的说明。下一阶段是结构设计阶段，这一阶段进行厂商、器件型号和开发工具的选择，也是对设计团队进行培训的最佳的时机。该阶段主要对设计中固定的离散功能模块与可编程模块进行划分，并对软硬件的执行进行划分，由此进行设计模块的划分。结构阶段完成后才是实现阶段。

    设计实现包括设计输入、设计约束、设计整合、功能仿真、时序验证、报告分析以及产生可下载到目标板的配置文件。在紧接着的验证阶段中，为了确保系统需求的正确执行，正式并（如果有可能）独立的对设计进行测试。该阶段涉及持续并全面的仿真、设计测试、对目标板上的FPGA部件的调试和功能验证。表3.1列出了不同设计阶段的主要行为。

表3.1

    在设计阶段，很可能大量的时间和资源都花费在寻找某个重大的缺陷上，这是很常见的事。例如，大多数的设计循环周期花费在了设计优化、整合、调试和验证阶段，而比例很小的时间是花费在需求定义、结构设计、模块划分和初始设计输入阶段。这很有意思，因为只耗费少量资源的早期的设计阶段对设计实现产生着最重大的影响。如何掌控这些关键点是本书不断重复的主题。在这些功能设计阶段的努力能够对整个设计效率产生重大影响。

    对设计早期的时间花费和努力程度产生影响的因素有很多。清晰、完整并合理的需求定义将使结构设计的效率得到提高。细致的进行结构设计有利于设计模块的划分与实现更加容易。如果很好的对设计模块进行划分并对其功能、性能和接口都做好定义，那么这个设计模块的开发、实现、复查、评估和测试就更加容易。越清楚有效的开发、执行并测试设计，进行整合、改进与维护也就越容易。如果这个有效的开发顺序能够被持续不断的执行下去，就能够最小化设计周期，避免很多由于不合理的设想，或者最后一刻的改变所带来的设计问题。

    在设计早期额外的付出可以大大消减在执行一些固定（可变）功能块时所付出的总的时间和精力。快速原型开发流程是的基础是任何既定设计功能的优化、整合、调试和验证需要花费的时间和努力的最小化。

    下面将对设计的主要阶段必须完成的任务的更多细节进行描述。

需求阶段

    设计说明书——定义并详细描述功能需求、接口、性能以及设计余量。修订并保持设计需求说明书，使其成为 “活生生的文档”。

结构设计阶段

    系统工程化/模块划分——为设计划分功能块、功能性分配、性能需求。定义系统结构以及设计层次。确定哪些设计模块将实现需求功能。

实现阶段

    设计输入（HDL）——使用高层次软件语言（HDL）作为设计输入。编写代码实现功能需求，初步设计仿真，代码配置控制。

RTL综合——将高层次HDL代码块综合成低层次电路称之为寄存器传输逻辑（RTL）。RTL定义了布尔等式、数据存储和设计元件连接性。通过综合约束和软件选项能够影响设计实现。

    行为级仿真——基于假设的门延时和布线延时的仿真。

    布局布线——将RTL设计映射成FPGA器件可用的设计单元。设计工具反复的调整逻辑单元布局，使得设计单元找到“最佳”的位置。设计信号或者网络也会反复的连接或走线，从而寻找“最佳”的连接方案。“最佳”的定义就是“足够好”的达到或超过定义的性能需求。

时序仿真—— 一旦FPGA设计在目标器件上完成了布局布线（也称之为适配），相应的逻辑延时和走线延时就会被反馈到固定的数据库文件（包含了这些参数）中。使用更新后的数据库文件进行仿真，从而验证综合后的动态时序。

验证阶段

    FPGA设计下载——定义了FPGA内每个可配置单元的设计文件被下载到器件中。该步骤也称为“配置”。

    调试和验证——使用外部测试设备探测内部节点信号，设计功能和真实性能得到验证。

    在详细的设计说明之外，快速嵌入式开发也需要设计者为高效率的设计、验证和测试作出努力。原型开发的另一个挑战是设计中包含相当多的新的未测试过的功能。最后，主要目标是尽可能快速高效的设计、调试、测试并递交完成预期功能需求的电路。

    例如，在进行FPGA管脚分配映射时，设计者必须清楚内部信号的走线，从而减少片上信号线的交叉和冲突（可能发生在FPGA器件的某个死角）。如果设计团队对可以预知的后果视而不见，作出错误的决定，那么很可能需要返工。

    图3.2给出了一个优化的设计流程。注意持续的自然迭代过程将贯穿于独立的设计步骤和阶段。最终的设计目标是最小化可以避免的设计迭代，从而达到设计效率的最大化。

图3.2

    在这些关键的各方面额外的努力才会将开发时间减小到最低，也能够消减、限制或消除常见的错误和疏忽。开发流程中把握好这些细节才有可能达到最高效的设计实现：节约预算、减少日程安排并最小化实现期望功能所需要的各种资源。下面列出了包含一些设计风险的方面。

设计的风险

无法还原设计

无法集齐原始/所需的文件

混淆而无法找到最新版本的文件

影响多个设计“链”的设计更新带来的挑战

没有合适的工具、更新、相关文档（速成文档）和许可文件

    如何使用较短的程序设计周期在相同等级下达到更高的效率是最大的挑战。尽管基本的设计方法在器件说明文档、应用笔记和其它技术文献或培训中都能够获得，但是最深刻的教训却是从亲身经历过的失败中获得的。这也通常是我们不愿意看到并希望避免的，而最重要的是不要重复失败。

《基于FPGA的快速系统原型开发》CH3.1译

《基于FPGA的快速系统原型开发》CH3.1译

《基于FPGA的快速系统原型开发》CH3译——前言

《基于FPGA的快速系统原型开发》CH3译——前言

    首先,很感谢riple兄给大家推荐了《Rapid System Prototyping with FPGAs》这本相当不错的书，尽管目前没有中文版面世，但是并不妨碍我们这些FPGA开发菜鸟对其产生浓厚的兴趣。感谢riple兄翻译了第四章的内容（http://blog.ednchina.com/riple/236637/message.aspx），这两天我也只是粗略的浏览了前三章，但是感触良多，只能用受益匪浅来形容我的收获。由于特权同学E文水平实在太烂，也许只是领会了原文不到80%的意思，而在这80%里也许还有20%没有领会作者所要表达的精髓内容。所以，还是那句话，好记性不如烂笔头。都说“树挪死，人挪活”，白字黑字那是死的，而我们对问题的思考、对原文的理解都是活的，所以我们有必要让这些死的字句活生生的映射到我们在FPGA开发设计中的每一个步骤里来。于是，特权同学希望从第三章入手，和大家一起探讨《优化开发流程》（《Optimizing  the  Development  Cycle》）这个话题。

    如果用最经典的一句话来阐释这个章节，那么特权同学会毫不犹豫的给大家送上这句话：

Although  the basics for designing can be obtained  in datasheets,  application notes  and other  technical  literature  or training,  the hard  lessons are  taught  through failures  and experience. While  this  is unfortunate  and typically unavoidable,  what  is most  important  is  that failures not be  repeated.

    相信每一个有过一定开发经验的工程师，哪怕不是一个FPGA开发工程师，这句话都是受用的。记得当年马哲书上这样告诉我们“经验分为直接经验和间接经验”，书上来的、甚至我们听某某前辈言传的所谓经验，那都叫间接经验，自己实践获得的才是直接经验。在我们设计开发的启蒙阶段，我们需要很多的间接经验指导我们的每一个动作，曾经大学课堂里从讲师那里灌输的基本知识、参加过的培训、乃至从器件厂商获得的每个IC的datasheet、application note都是我们进行相关设计的很好参考，这些都是不折不扣的间接经验，也许我们可以从中获得很多指导性的东西。但是，“纸上来的终觉浅”，最深刻的东西往往不是这些间接经验，却是那些让我们记忆犹新的一个个失败的教训。对设计者来说，最重要的也就是不要重蹈覆辙，错过了就不能再错，必须让曾经的过错成为明天的财富。今天的过错多一些，那么明天的过错就应该少一些。

    而《Rapid System Prototyping with FPGAs》一书的作者用20来年的开发经验来说话。它所传达的不仅仅是开发流程本身，更是每一个设计者应该用心去领会的每一个细节。回到我们的CH3上来，开发流程是死的，FPGA的开发流程更是一个很特殊的反反复复的过程，而如何最大程度的减少这个反反复复的过程就是快速系统原型开发中很重要的议题。所以，这个流程很有学问，如何达到最优化是我们应该好好思考、好好学习的。往后的博文（译文）希望大家共同探讨，特权同学文章中的疏忽和不妥之处欢迎指正。