在一般的FPGA设计流程中，大部分设计师从书面的规划书开始工作，该规划书包括了定义主要逻辑模块、接口和总线的结构图。设计经理开始根据该模块图来划分功能模块并根据模块的功能描述来分配开发任务。每个模块被单独编写代码，并可以在特定模块的测试文件中进行仿真。设计团队将所有模块组合为一个器件级的文件，其中端口是目标器件的引脚。然后该设计准备被编译而用于仿真，并开始进行开发的调试阶段：仿真之后是硬件调试。

大部分仿真采用测试文件来执行，该测试文件由设计师来编写。测试文件一般包括时钟、复位以及在设计中操作的控制引脚，并且在测试文件中指定信号断言时序。测试文件通常也包含到FPGA将在系统中通信的其它器件的接口的模型。这些接口可以是存储器总线、PCI或者以太网端口。某些模型由设计FPGA逻辑的同一个人建立，并且是以他们所理解的接口是如何工作的原理为基础。接口操作是从器件数据手册的时序图推断出的。

当在设计中使用第三方IP产品的时候，接口模型可以从提供IP产品的测试文件处切断，并被合并到驱动IP接口的FPGA测试文件设计中。

仿真调试

设计师使用逻辑仿真器来发现并纠正设计中的错误。器件级的设计经常被嵌入到测试文件中。测试文件驱动设计的输入来操作该设计。通常，仿真是调试的第一阶段，并且紧随其后的必须是该设计在硬件上运行来调试。

测试文件仿真采用固定的信号时序分配以及连接到FPGA的外部器件的逻辑模型来作为仿真的激励。仿真结果显示在波形观察器中。设计师通过比较仿真波形和理想的行为来对逻辑调试，并反复修改设计源文件。然而，RTL仿真仅仅表明了逻辑行为。如果信号的时序或模型的性能并不与实际器件的行为一致，那么仿真结果将不与系统开发板上的器件操作一致。尽管在设计实现后，反标目标器件的时序以便仿真后的行为反映实际实现的时序是可能的，但是，对在测试文件和实际的系统操作环境之间的任何时序上的差别而言，其实并不正确。

在多时钟系统中，各时钟之间相位或频率没有关系，因而时钟成为特别值得关注的根源。设计测试文件，对不同时钟之间所有可能的相位关系建模是很困难并且耗费时间的。然而，这些关系可以驱动系统内的器件，并在任何条件下必须正确执行。物理设计实现的系统内分析无疑是一个必要条件。问题是：什么是最容易和最有效的方式来搜集信息，这些信息是与什么是在实验室环境的器件实际发生行为有关的？

用逻辑分析器进行硬件调试

开发者执行可编程逻辑设计的硬件验证，该设计以目标系统的速度运行并在实际条件下观察其逻辑行为。典型的硬件调试方法包括使用逻辑分析器来探测和显示信号。

通过使用PCB上的一系列引脚来完成探测，这些引脚与FPGA上未使用的引脚相连。开发板的引脚被连接到逻辑分析器的探头。将FPGA引脚输入设计中作为设计的端口，其被连接到设计中的节点。然后，使用可编程逻辑供应商的工具给设计进行布线。信号值被逻辑分析器捕捉并显示。

该方法提供了在操作中进入器件的一个窗口，但是有大量的缺欠。首先，设计师必须人为地使用仪器分析设计，并且每次要人工反复调试。他们要查找观察的任何节点都不是在设计的器件级，而必须是被布线到最上层。其次，探测的容量受器件上能够得到的未使用引脚数目以及开发板上的引脚数目的限制。再次，信号名必须输入逻辑分析器的观察器中以便追踪设计中的节点并将其显示在那一行上。每一次探头移动后，信号名必须被再次输入。最后，设计中布线的节点可能干扰器件操作或时序。

使用逻辑分析器进行调试是耗时、受限制以及难用的。

片上逻辑分析器调试工具

大量的可编程逻辑器件供应商和其他供应商提供硬件调试工具，其使用编程通道来访问器件操作信息。该工具使用器件上的编程端口与内部节点连接。在器件被编程并且在系统中工作以后，调试工具使用器件上的逻辑和存储器资源进行采样并存储节点的行为。当实例化调试工具时，设计师将对设计进行综合并使用供应商的工具来对器件上的设计进行布局布线。这些工具包括可以访问编程端口上的信息并在信号波形中显示它的观察器。

该调试过程包括连结和实现流程的多次反复。该过程从综合内核开始，该内核是用于连接采样数据的设计节点和将其传送回PC用于观察的编程端口的。

该供应商工具克服了由于使用器件和开发板的引脚用于逻辑分析器探测而产生的限制。该工具的探测也对器件逻辑实现和时序有很少的干扰。然而，作为用于调试的逻辑分析器，它们有共同的缺点。

对设计进行探测的方法

这一过程从综合内核开始，该内核是用于连接采样数据的设计节点与将其传送回PC用于观察的编程端口的。

至少有两种方法能够用于内核和节点的连接。其中一种方法，设计师在综合内核后增加内核并连接内核与节点。该方法相对容易，但需要在每次反复调试期间重新连接，这是因为综合可能消除连接。这种方法还需要在运行综合时保留对连线名的选择。否则，当绘图的时候，信号和模块名可能被消去或改变。甚至强迫保留名字而不保证节点的功能将不被逻辑压缩或其他实现的算法改变。

第二种方法包含了在综合之前编辑源文件来增加内核。设计师编辑设计的顶层源文件来增加一个两组分的层次。顶层组分连接到端口和更低一层组分，这更低一层组分也连接到设计中被监视的节点。该组分允许数据显示格式的规范以及采用与节点连接的触发条件的建立。

该方法保留了反复调试之间的探测连接，因为它们是在综合之前建立的。但是因为该工具不支持为了观察更低层次的节点而对组分的层级插入，必须手工编辑设计以及逻辑层次间的信号布线，以便它们能够被连接到探头。这种布线是一种耗时的过程，该过程也由于与功能无关的改变而使得设计失真。

例如，在一个状态机中，一个没有输出的状态不能被探测，除非增加一个假的输出信号来作为一个状态输出，并通过顶层的层级对其进行布线。新增加的这些组分或模块上仅仅连接到探头的信号和端口，主要采用延时进行调试并与设计功能无关。

该方法的另一个问题是不能采用实例化的组分仿真设计，这是因为它们包含不能用于仿真编译的库组件。

无论采用任何一种方法，设计师仍然必须手工编辑文件来建立探测连接。

保持设计的一致性

设计中可能需要多种工具，在这里不同的工程师可能在同一时刻对单独的模块调试。为了避免这些相互冲突的工具彼此干扰，每种工具或者需要的探测使用不同的设计拷贝。例如，如果每位设计师在连接到探测点的层级上对信号进行布线，不同信号的布线必须通过同一个模块。

当管理不同的拷贝时，设计的一致性变成一个问题，这是因为一个版本的调整必须添加到所有的版本中。

保持逻辑的完整性

当使用供应商的调试程序探测或触发节点的时候，在综合优化过程中，甚至当节点名保留的时候，都能够改变节点的功能或者极性。该结果是无效的触发或数据。这种改变源于在门级而不是在RTL级增加探测点。

解释结果

逻辑分析器和片上逻辑分析工具都显示波形来表示逻辑级的变化。波形必须返回有关的原始源代码在原始的基于文本的设计中来理解器件行为。

波形仅仅表示了行为发生时的瞬态图，并且为了观察信号而被组织在一起，其的行为是结果信号变化的前提。准备探测和波形显示来提供有意义的结果需要仔细的准备。除非代码中能够影响其它信号的所有信号都在波形中显示之外，你不可能知道是哪一个信号引起了变化。

反复调试的时间

当在节点之间移动探测点时，逻辑分析器和片上逻辑分析工具都需要长久的反复调试，这是因为调试方法并不依赖于实现的工具。在返回实验之前，每次通过综合与布局布线都必须运行这些工具。当这些工具在运行的时候，调试团队是空闲的，直到器件做好准备再次编程。

设计师所需要的是一整套工具，其与综合器一起工作，它们能够在大的设计中快速定位节点并适当地追踪监测。设计师需要结果，这些结果很容易地观察到、返回有关的源代码，并很快地实现反复设计，以便调试团队可以完全专心于设计。

本文由Synplicity公司提供