如果您的FPGA设计无法综合或者没能按预期在开发板上正常工作，原因往往不明，要想在数以千计的RTL和约束源文件中找出故障根源相当困难，而且很多这些文件还可能是其他设计人员编写的。考虑到FPGA设计迭代和运行时间的延长，设计人员应该在设计流程的早期阶段就找出可能存在的诸多错误，并想方设法重点对设计在开发板上进行验证。

　　在特定条件下采用更智能的技术来隔离特定错误，找到问题电路的源头并渐进式修复错误，这很重要。为了节省时间，您可以对时钟、约束和模块级接口进行初步设置检查以确保符合设计规范，这样就不必在综合与布局布线（P&R）时浪费大量时间。

　　Synopsys 公司的Synplify Premier 和Synplify Pro FPGA设计工具以及Identify RTLDebugger 等产品能帮助设计人员完成上述工作。这些工具的特性使得设计人员能快速隔离错误，有效缩短运行时间，并减少开发板启动所需的迭代次数。

　　精确找到开发板上的问题

　　如果开发板出现明显的功能性错误，要缩小查找问题根源的范围可能会相当困难。为了进行设计调试，我们应当创建附加电路并保留某些节点，以便我们对设计运行时得到的数据进行探测、检查和分析。下面我们就看看如何用板级调试软件来查找错误。

　　按下列四步法并利用RTL调试器，您能精确查找问题，并对信号和关注的条件采样，然后将观察结果关联至原始RTL，从而将问题锁定在RTL规范或约束设置范围内。

　　第一步：指定探测。在RTL中明确要监控哪些信号和条件。在此要声明您所感兴趣的观察点（要观察的信号或节点）和断点（RTL控制流程声明，如IF、THEN 和CASE 等）。

　　第二步：通过探测构建设计。利用附加的监控电路——即用于根据您的监控要求捕捉并导出调试数据的智能内部电路仿真器（IICE）——对FPGA设计进行综合。

　　第三步：分析和调试。设计综合完成之后，运行设计并用RTL调试器观察数据。在开发板上运行测试时，观察点和断点共同触发数据采样，使您能在您所关注的非常明确的条件下观察并调试特定节点的电路的行为。您可将观察到的采样数据写入VCD 文件并将其关联到RTL。

　　第四步：渐进性修复错误（incrementaLfix）。一旦找到了错误所在，就可以通过分级、渐进式流程在RTL或约束中渐进地进行修复。

　　时序和功能性错误的可视检查

　　FPGA设计和调试工具还有一大优点，就是能显示RTL和网表级原理图。举例来说，具有互动调试功能的原理图查看器能够显示设计的RTL和网表原理图，便于您进行观察并将时序报告和VCD 数据（设计在开发板上运行时产生）关联至RTL源文件。查看器包含一个RTL视图，用来以图示的方式描述设计。该视图在综合RTL编译阶段后提供，由技术独立的加法器、寄存器、大型多路选择器和状态机等组件构成。通过RTL原理图，您可以交叉探测原始RTL，对不符合预定规范的设计进行调整，同时也可以探测到约束编辑器，从而更简便地更新和指定约束（图1）。

　　要将错误操作的源头追溯到RTL，您可以利用RTL调试器在RTL原理图上方实时插入观察到的操作数据。

　　原理图查看器包括一个网表级技术视图，用于显示综合后的实际设计实现情况。在HDLAnalyst 原理图查看器中，该视图基于查找表、寄存器和DSP slice 等基本的赛灵思器件原语。您可在原理图中对路径进行交叉探测，追溯到原始的RTL以及综合后和布局布线后的最终时序报告，以便分析和提高整体性能。

　　在FPGA中原型设计的ASIC 门控时钟结构并非FPGA实现中的必要环节，这会导致FPGA资源使用效率低下。解决该问题的有效办法就是用FPGA综合软件转换时钟。

　　大型设计的调试

　　在大型设计中探测所有信号是不可能，因为生成的数据量极为庞大，而且探测数据所需的额外调试逻辑也太大。片上调试方法的一个常见弊病是难以提前预测需要对哪些信号进行探测和监控。

　　一些调试软件通过分治法能够在一定程度上解决这个问题。利用多路复用的采样组，设计人员可以有选择性地进行采样并通过多路复用的路径和共享的IICE 在信号组之间切换。这种方法增加了可观察的信号和条件，而且不会增加数据存储要求。您可以即时切换感兴趣的信号组，不必花时间进行重新调整或重新综合新的设计。

　　不幸的是，在探测和采样数据时用使的调试IICE 逻辑会占用包括存储器BRAM 在内的芯片资源。您可在SRAM 存储卡中对IICE 采样数据进行片外存储，以减少片上BRAM 的使用。这种方法的另一个好处是能增加采样数据的深度。

　　我的设计无法综合

　　设计错误的出现可能导致无法实现有效综合或布局布线。由于存在成千上万的RTL和约束源文件，因此可能需要几个星期才能完成首次综合与布局布线。进行FPGA原型设计时，应让ASIC 设计源文件处于“FPGA就绪”状态。举例来说，就是要进行门时钟转换。

　　在 FPGA中原型设计的ASIC门控时钟结构并非FPGA实现中的必要环节，这会导致FPGA资源使用效率低下。解决该问题的有效办法就是用FPGA综合软件转换时钟。例如，门控或生成时钟转换功能可将生成时钟和门控时钟逻辑从顺序组件的时钟引脚转移到使能引脚，这样您就能将顺序组件直接绑定到源时钟，消除偏移问题，并减少设计中所需的时钟源数量，进而节约资源。

　　在Synplify Premier 软件中启用门控时钟选项：

　　– 选择Project->Implementation Options

　　– 在GCC & Prototyping Tools 标签中点击Clock Conversion checkbox

　　或在TCL中使用以下命令

　　set_option -fix_gated_and_generated_ clocks 1

　　在Synplify Pro/Premier 中执行门控和生成时钟转换，而set_option -conv_mux_xor_gated_clocks 1则针对基于Synopsys HAPS 的设计在Synplify Premier 时钟树的多路选择器或OR 门上执行门控时钟转换。

　　“完整”的系列时钟约束包括在所有正确位置定义时钟并在生成的时钟之间定义关系。有时候，时钟会出于某种原因与真正的源断开关联，例如时钟源和时钟目标端间产生了黑盒，这样会造成顺序组件的时钟缺失或时钟约束放置错误，导致首次时钟转换因为缺少时钟约束而失败。在许多情况下，转换失败是由约束不完整造成的。举例来说，门控逻辑中可能存在一个组合回路，应在时钟转换之前利用异常处理约束将其打破。综合编译阶段之后会提供一个门控时钟报告，告诉您有哪些门控和生成时钟已被转换以及被转换时钟的名称、类型、分组和相关约束。另一个时钟列表则显示的是未转换的时钟，并包含故障信息，用于说明原因。图2 给出了报告实例。

　　举例来说，如果设计中有黑盒子，您可以在RTL中指定具体的软件命令，用于为自动化门控时钟转换提供辅助。比方说，采用 syn_gatedclk_clock_en 指令在黑盒子中指定启用引脚的名称，用syn_gatedclk_clock_en_polarity 指令指出黑盒子上时钟使能端口的极性。每个转换实例和驱动实例的时钟引脚都被赋予一个可搜索的属性，从而能在设计数据库中识别，并提取到定制 TLC/Find 脚本生成报告中。

　　端口不匹配

　　设计包含公司内外部提供的文件。在设计中进行IP 实例化或预验证分级模块时，经常会出现“端口不匹配”错误，而且难以检测，特别是出现在混合语言设计中更是如此。举例来说，如果顶层VHDL实体 “Top”实例化Verilog 模块“sub”，那么顶层VHDL声明sub 有4 位端口，而实际Verilog 模块只有3 位端口。就Synplify Premier 软件而言，会立即将其标记为不匹配，并在单独的日志报告中通过超级链接引用该错误。

　　视图work.sub.syn_black_box 和视图work.sub.verilog 之间的接口不匹配

　　细节：

　　========

　　源视图work.sub.syn_black_box 中的以下位端口在目标视图work.sub.verilog 中不存在。

　　=======================================

　　Bit Port in1［4］

　　Bit Port in2［4］

　　Bit Port dout［4］

　　多级层次中，如何将不匹配问题追踪到问题模块的RTL定义呢？工具应以某种方式给所有模块实例打标签，比方说采用orig_inst_of 属性。属性的值包括模块的原始RTL名称，可方便地检索至RTL。例如，假设sub_3s 导致端口不匹配错误，那么我们就能用以下TCL命令找回RTL模块的原始名称“sub”：get_prop -prop orig_inst_of {v:sub_3s} 返回值为“sub”。

　　约束的清除

　　指定充足且正确的约束将影响到结果质量和功能。约束声明通常应包括三个元素：主时钟和时钟组定义、异步时钟声明、错误和多循环路径声明。

　　进行综合之前检查约束是一个很好的方法。提供约束查看器的工具能发现语法错误并分析时序约束和实例名称是否适用，警示问题所在。比方说，它会报告通配符扩展后约束如何应用以及在定义时钟约束后产生的时钟关系。它会标出那些由于参数或对象类型无效或不存在而未被应用的时序约束。

　　进行综合之前，在Synplify Pro/Premier 软件中生成名为projectName_cck.rpt 的约束检查器报告：

　　Synplify Pro/Premier GUI： Run -> Constraint check

　　或采用TCL命令：project -run constraint_check

　　注意，要避免潜在的MetA不稳定性，应运行“异步时钟报告”，提醒您注意那些在一个时钟域启动而在另一个时钟域中结束的路径。

　　在Synplify Pro/Premier 软件中生成时钟同步报告projectName_async_clk.rpt.csv：

　　Synplify Pro/Premier GUI：Analysis->Timing Analyst并选择Generate Asynchronous Clock Report 选项。

　　采用TCL命令： set_option -reporting_async_clock

　　正确的方法是确保您充分且全面地对设计进行约束，而且不会过度约束（过度会导致运行时间延长，生成关键路径错误报告）。确保您已完全指定多周期和错误路径，并且已为得到的时钟设置了约束（set_multicycle_path，set_false_path）。

　　缩短调试时间

　　实施潜在的RTL或约束故障解决方案可能需要好几个小时才能看出结果。我们来看看如何利用分级“分治法”设计方法和“错误继续”功能在单次综合迭代中发现多个错误，从而减少迭代次数。

　　为缩短运行时间，模块化流程必不可少。这种流程支持设计保存，能锁定已经证明有效的设计部分。支持模块化流程的工具能帮助您在进行综合前创建RTL分区，也就是编译点。一些软件还能帮助设计人员将有故障的设计部分变成黑盒子，彻底将该部分导出并作为独立的设计子项目进行再加工。一旦解决问题，子项目还能够以网表形式通过自下而上的流程或用作为RTL通过自上而下的流程整合回原设计，甚至还能综合利用自上而下和自下而上两种流程。

　　要集成和调试大型设计，应尽早在设计进程中发现错误的说明。举例来说，“错误继续”功能可提供涉及每个综合通过信息的组合错误报告。“错误继续”能容许非致命的非语法HDL编译问题和某些映射错误，因此设计人员可在每次综合迭代中分析并完成尽可能多的设计内容。为了在带有 SynplifyPro/Premier GUI 的Synplify Premier 软件中调用“错误继续”功能，应启用项目视图左侧的Continue-on-Error 选项。

　　在TCL中：set_option –continue_on_error 1

　　用属性is_error_blackbox=1 标记故障模块和带接口错误的实例父模块，如图3 所示。

　　用TCL找到所有“故障实例”：

　　c_list ［find -hier -inst * -filter

　　@is_error_blackbox==1］

　　用TCL列出所有“故障模块”：

　　get_prop -prop inst_of ［find -hier -inst

　　* -filter @is_error_blackbox==1］

　　要查看将被关入黑盒子或导出的故障模块，请查找HDLAnalyst RTL视图中的红色块（图3）。

　　通过导出模块隔离问题

　　您可将故障模块作为完全独立的综合项目导出，以便专门对该模块进行调试。导出过程会产生隔离的综合项目，其中包含所有该模块的源文件、语言标准和编译库，以及所含文件的目录路径和路径顺序，以达到对该模块进行单独综合与调试的目的。如前一节所示，出现错误的模块会自动在设计数据库中标出错误属性，并在设计原理图中突出显示，便于对该模块进行查找和提取。

　　为了导出模块及其所有相关源文件进行隔离调试，应首先在Synplify Pro/Premier 软件GUI 中（图4）的设计分级视图或RTL视图中选择设计模块或实例，然后点击右键并在弹出菜单中选择“Generate Dependent File List”。

　　将每个分级模块的错误进行修复后，您可将其再集成到设计中，既可作为RTL在整个设计环境中重新综合（自上而下的综合流程），也可作为网表（自下而上的流程）进行综合（见图5）。

　　要满足时序要求就不可避免地要用到设计分级，这可能会带来挑战。层级界限可能会限制性能，除非为设计的每个层级分区建立时序预算。使用RTL分区（也称为手动锁定编译点）时，一些工具能自动设置时序预算。Synplify Pro/Premier 软件还能提供自动编译点，能创建自动分区，比方说通过多处理加速运行速度。预算功能为每个RTL分区建立接口逻辑模型（ILM），这样软件就能知道如何满足每个分区的时序目标。这样，您可为每个编译点指定一个约束文件，从而覆盖手动锁定编译点自动时序预算。

　　Synopsy 近期进行的全球用户调查发现，59% 的设计人员认为“设计规范的正确性”是最重要的设计挑战之一。这个挑战会造成设计延期，最坏情况下可能导致设计失败。设计工具必须能尽早捕捉到错误，并就设计工作提供更高的可视化，确保设计规范得到有效验证和修复。这些工具还必须就提出的设计修复方案提供反馈途径。