FPGA设计验证关键要点

不同于ASIC设计，FPGA设计中的标准元件或客制化实作，一般欠缺大量的资源及准备措施可用于设计验证。由于可以重新程式化元件，更多时候验证只是事后的想法。本文将探讨在FPGA设计验证周期过程中使用的工具及技术，并逐一审视各项优缺点。有效验证降低设计风险
FPGA设计验证的规画和预算安排的失败，可能瓦解整个产品开发计画；时程的延误会和光罩技术的再修正（respin）一样严重。由于失误可重新程式化加以修正，验证的风险不高，因此并未把追踪及校正错误所需的成本纳入考量。尤其在复杂、多重时脉FPGA设计中，若将元件、系统及软件开发的交互影响考虑进来，这个后果更可能会加大数倍。

一个良好验证技术和工具，在FPGA开发过程中可用来大量减少使用元件的风险。在此架构中，初始验证倾向于高阶中执行以发现总体功能上的错误，但当验证程序进行到设计以全速操作所有功能的最终目标时，设计上的问题逐渐困难到令人难以理解。通常问题和资料及时序相关，有些问题很少碰到甚至要以全速执行验证数小时甚至数天，才能侦测到它们发生一次；有些问题显然和一些模糊不清的事件有高度相关，当真的碰到时，必须先准备好测试环境以捕捉该问题并提供资料才能作分析。  多数模拟提供之验证并非完整
模拟将设计编译成一种以逻辑向量作为驱动的形式，该向量代表输入驱动信号.。设计中的行为模式可看成一种波形，设计者使用逻辑模拟器来修正设计中的错误。

模拟运作在RTL层次，因此能提供设计者一个熟悉的设计视野，它提供一个设计最完整且最能掌控的视野，设计中任何电路节点都可被检视及强制设定到一逻辑准位。然而，相对于实际元件运作的速度，模拟一个具有众多向量的大设计是非常慢的。

大部份的模拟使用一个测试向量（test bench），该测试向量一般包含设计本身及驱动设计的所有输入；包含系统中操作该设计的资料、时脉、重置及控制的逻辑信号，而输入的资料样式及时序便是由这些逻辑信号决定的。若设计中包含复杂的模组，像是和外界沟通的Ethernet、PCI埠，或是外部存储器控制器，那么测试向量可能也包含了外部元件的模拟行为模组，该模组塑模了系统运作时FPGA和外部元件的互动模式。

模拟模组可由设计FPGA逻辑的设计者同一人建立，因为他们了解这些介面是如何运作，而介面运作是由元件的规格表（datasheet）中的时序图所推断出来。

当有其他厂商的IP产品用于设计时，该IP通常都包含一个用来验证它自己的介面模型，该模型可以整合进设计的测试向量以驱动IP介面。

测试向量模拟采用固定的信号时序设定及FPGA外部元件的逻辑模型当作模拟引信（stimulus），模拟结果显示于波形检视器，设计者以波形和设想的行为模式比对并反覆修正设计原始码来作逻辑除错。

然而，RTL模拟只能显示逻辑行为，如果信号的时脉或是模型效能和实际的元件行为不同，那么模拟结果和元件实际下载到系统板上的结果将不相符；尽管将设计实作后之目标元件时序回贴（back-annotate）是可行的，如此模拟的行为可以反应实际实作后的时序，但这并不能校正任何测试向量和实际运作环境时序上的差异。

时钟（clocks）在多重时脉系统中是另一个特别要注意的信号来源，在此系统中并无一个实用的方法可以建构这些在测试向量中的相位及频率的关系，而这些时序关系可以明确决定该设计是否在系统能正常运作。

当模拟设计时，验证层级是测试向量和实际运作环境相似精确度的函数，以精确地反应母板环境的向量来模拟设计去侦测到最多的错误。然而，建构这类的环境并不容易，而且大多数向量仅提供实际引信的近似值，大多数情况下，模拟提供的验证不完整。  硬件验证
仅管模拟提供了设计一个重要的层级，但它对设计效能在整体系统中的表现，没有提供足够的瞭解。因为引信（stimulus）最多只是实际环境的近似值，硬件验证提供了唯一方法，可以瞭解当FPGA于系统中以时脉速度运作时，内部究竟发生了什么事。

FPGA硬件验证可分为用逻辑分析仪的外部验证及用硬件除错器的内部验证。

■使用逻辑分析仪之外部验证
逻辑分析仪原本用于电路板层级的除错。透过I/O接脚连接到FPGA内部讯号用来监控FPGA内部信号。逻辑分析仪提供从板子以及从FPGA内部同时捕捉资料的好处，这能力足以分析整个系统。

将PCB板上接脚连上FPGA没使用到的脚位就可用逻辑分析仪连接或是探测FPGA。板上接脚另外连上逻辑分析仪接头，将FPGA接脚设计成连进设计内部成为连接埠（ports），深入设计内的线路节点。接着，设计以可程式化的逻辑工具绕线，就可以捕捉到信号值并显示在逻辑分析仪。

当逻辑分析仪捕捉到元件内部节点的资料时，以上方式提供了视窗以透视元件在系统中运作的情形，不过会有些缺点：首先，设计者必须手动更改设计，在阶层中一路向上穿透，将内部节点连到元件接脚，该接脚再连接至外部板上接脚。而这过程在每一次反覆修正中都要重覆一次，不属于设计中元件层级的节点都必须绕线到最上层，不仅容易出错而且耗费时间。

再来，探测能力受到元件上可自由运用接脚及板上接脚的数目限制。第三，信号名称必须输入逻辑分析仪之检视器以追踪设计中哪个节点显示在哪一行，而每次探测点一移掉，名称就得重新输入。最后，除了设计原订目的，设计中节点绕线到其他的接脚，可能会干扰到元件运作或时序。

目前有工具可减少自设计中展开网目（net-list）节点的连接数目，将深藏在设计阶层中的节点以讯号线导引至最上层，该技术可减轻这样的负担。缺点是由于使用网目，在设计从RTL到网目过程中，其名称及功能会改变，却没有警讯并会提错误资讯。

逻辑分析仪具备复杂的触发机制选项，但触发点不是设计来捕捉FPGA内部事件，它只能操作在连接到外部接脚的那些节点上，使用逻辑分析仪对FPGA内部设计除错是相当费时、不方便和受限的。

 硬件除错器
没有模拟的人为操作及逻辑分析仪的使用不便，硬件除错器代表系统验证工具的最终手段。不像模拟器，除错器显示了元件实际的逻辑资料，让设计者看到当元件在系统中以全速运作时，其内部逻辑的实际运算结果。以元件硬件资源来换取资料和命令，让除错器不再需要元件的接脚。

在众多的除错器中，可发现有不同运算的特色及方法的除错器，除错器可大致分为二大类：设计网目型以及原始代码型（source code）。除错器同时也提供不同的触发机制及功能。
　

■网目除错器
网目除错器定义为：在合成（synthesis）而展开后的网目设计上运作，探测（Probes）及触发点直接加到网目，资料则会显示在波形图上。

■RTL除错器
RTL除错器可显示在设计层级，而探测及触发点直接加于原始代码上，其结果可贴回（annotated）到原始代码，在时间轴上前进或退后以显示每个时脉来观察，也可以用波型图看到结果。

■除错器需求
验证设计时，要使工具好用，一些需求是基本的，每个需求视所需要的程度而定，而工具提供这些能力的程度，决定这个验证工具可应用在多大的范围。明显地，资料必须精确地反应RTL功能，而设计者必须要能将资料和原来设计关连起来，除错器必须提供检视和解释结果的方法。

所有的除错器都在探测设计的节点并图形化显示结果。然而，为了效率最佳化，除错器必须在RTL层级上探测和显示结果，因为那是一般熟悉的设计版本，而且那里的逻辑必须运作地和预设的一样。

当使用硬件除错器时，很重要的一点是，它要能精确地补捉发现错误和验证系统行为所需的资料。工具不仅必须定位某一事件附近的逻辑转换位置，而且要能追踪甚少发生事件的错误，并保证可以捕捉到这些事件以作进一歩检查。

除错器必须提供触发机制，能捕捉任何时刻、任何频率的任何逻辑事件，并把相关的资料收集起来。触发必须要有够强大的功能，能一路追查一系列的事件到触发的根源。最后，除错器必须要能侦测跨不同时域的事件，如：电子不稳态（metastability） 在某段时间内造成的信号转换。这些需求在下面的章节中会再讨论，并对照比较操作在RTL及网目层级的工具差异。

■加入探测及触发点
除错器应该要能支援快速且容易地加入探测点及触发器，允许资料能轻易地对照到原设计。最重要的是，它要保证资料在任何时刻的完整性，能提供选择个别节点、整条或各组（field）汇流排的能力，以供探测及触发点之用。网目除错器显示设计中所有节点的清单供探测个别节点或用来当作触发点，这清单可以透过筛选器删减以显示其中某部份，节点可以被选定作为探测或触发点。

节点的名称可能令人陌生，因为它们是经过编译产生的，其功能在编译过程中可能已经改变了。RTL除错器则直接在原始代码中加入探测和触发点，在下面图一中，显示了一个经Synplicity的Identify RTL Debugger编译过的设计，其中所有可能被探测的节点都以小图示标记起来，点选其中一个节点会开启一份选单让人设定该节点是一个探测点、触发点、或者二者皆是，因为有维持住设计层级，很直觉就可以浏览设计以定位探测点。
　

<图一> Synplicity’s Identify Instrumentor
　

除了探测个别节点，除错器应该还要能从汇流排上捕捉并显示资料，汇流排及汇流排组也应该要能当作触发点，就如同个别节点一样，汇流排组（fields）应该要能被程式化以针对特定或某范围的值检查。汇流排在网目中会被展开，但可在网目除错器中藉由选择汇流排中每一个位元来重组成一汇流排，在这样的一个汇流排中无法探测或触发其中某部份，因为在设计展开后的版本中，汇流排的观念是无意义的。

Identify RTL Debugger可提供个别节点、汇流排以及部份汇流排的信号量测。部份汇流排区段的定义以下面图二的选单来定义，其中指定了要取样或是作为触发点的汇流排组。
　

<图二>Identify Instrumentor，汇流排触发选单
　

每个部份汇流排区段都可以上图二中的汇流排触发选单来量测，指定汇流排组后，其它的选项用来探测（取样）该汇流排组，从数个样式中触发一至二个。

■移动探测点
在除错期间，很难预期设计中所有可能发生错误的节点都可被依序探测到。大部份情形是，在验证过程中会不断反覆探测不同的次数及位置，最差的情形是，这些改变需完整重新编译，包含整体设计合成及布局绕线，理想上每次探测不须耗费使用者太多力气，不用重新编译。Identify RTL Debugger和某些网目除错器都提供加速编译（incremental compilation），藉由呼叫FPGA编辑器来修改现有绕线，让探测或触发点从其中一点移到另一点。

■跨时域触发
多重时脉在FPGA元件中经常被使用，多个专用的时脉缓冲器是其特徵。在多重时脉系统中常碰到有关不同时域间资料的时序问题。这类问题包括电子不稳态（metastability）,setup及hold time无法达成，以及资料流失的问题。侦测这种细微的问题一般来说是很困难的，这种问题可能根本不会在逻辑模拟中出现，也无法仅用单一时域内过度取样，或是在某时域内触发而在另一时域内取样的除错方式侦测到。硬件除错器应该提供方法侦测这类由跨时域间资料传递所引发的问题。网目除错器没有提供任何侦测跨时域时序问题的机制。

Identify RTLDebugger提供一个交互触发的功能，如下图三所示，可允许触发某时域内逻辑，去驱动和致能另一时域内的触发器。交互触发可用来检视跨时域事件的时序，藉由另一个更快时脉过度取样某时段，它亦可用来观看该时段内发生的事件。
　

<图三>交互触发例子
　

■取样和触发模式
当触发条件成熟时，取样模式控制资料被加入缓冲器的方式，这些模式允许使用者依据不同模式排列资料流入顺序，仅藉由排序相关资料，即可增加缓冲器的使用效率，例子包括填充整个缓冲器、储存单一取样信号线或中断前才进行储存。

触发模式描述对应触发条件的资料储存时序，例子包括触发周期的数目、週期宽度及某週期之后的延迟时间。

网目除错器仅提供非常阳春的缓冲器控制，只有每个触发取样的数量或是缓冲器的设定，但没有实际资料排序的能力。Identify RTL Debugger有四个取样模式及四个触发模式，取样模式控制缓冲器如何补捉资料，触发模式则控制资料捕捉时序。

■状态机触发
侦测独特条件最精确最强而有力的方法就是使用状态机作为触发方式。当追踪一连串事件时，状态机可追查任何条件之间的状态，状态机建立一连串元件运作时，必须要完成的歩骤及条件，以达到一个以上的触发条件。触发条件可以和任何状态联结在一起，以使状态机收集模煳不清事件的资料。

网目除错器没有内建状态机触发点，但允许手动实作状态机或计数器以触发某一事件，藉由编辑原始代码可将状态机加入设计中。手动解决方案需要人为调整逻辑，也需要手动为每个触发作调整，再指定新的触发节点，最后予以重新合成。除错器中的触发点会附在状态机的节点上。

网目除错器的确包含一简易串列状态条件的形式，这是在进行到最后之储存资料条件前，必须满足的一连串触发条件。并不提供路径，或是发生单一状态次数的计算，以及停留在某一状态内时间的其他选择。

Identify RTL Debugger提供了状态机编辑器，藉由提供包含巨集触发功能的选单式编辑器以自动触发状态机.。例如；是否触发某个状态，或是在某条件下触发，以及如何使用计数器触发等...都可在除错器内作调整，也可以在除错过程中动态改变设定，并不会直接影响设计。

如下图四所示，该编辑器可使用任何触发/条件模式，或一至二个类似状态机的取样模式的巨集。巨集编辑器包含一些栏位设定，可决定某状态会使用的条件以及事件数量，或是计算出来的取样数，每个状态都有转移到其他状态的条件。
　

<图四>Identify RTL Debugger状态转换编辑器将触发状态机自动化
　

■断点（Break Point）触发
在RTL分支叙述（如WHEN或IF叙述）上触发，允许设计者直接从原始代码本身而非逻辑值上表明触发，好处是可以更接近原始代码的方式参照设计的除错资料。本质上，网目型产品并不能提供断点触发，因为触发点仅在网目编译后才加入设计中，此时这类的结构已不存在。

Identify RTL Debugger确实提供了断点触发，断点可紧邻置于分支叙述旁，而且可在一个除错週期中动态及个别启动这些断点。

■资源需求
在资源受限的设计中，实现探测点及触发点所需的资源是很重要的，在这种情况下，设计者想知道他们所加的探测资源是否会使设计变得太大，以致无法实现于元件中。

网目除错器的探测点是八进制累加，因为那就是探测核心所用的大小，跨过八进制的边界需要对整个八位元核心作加法。资源需求是加到触发口（trigger port）上比对单位数以及比对型态复杂度的函数。

当使用网目工具时，除非经人为计算，无法得知有那些资源真正用来探测设计，因为FPGA编译软件不提供此资讯。虽然可经由使用者手册中的规格表计算出来，但仅能用于表格中使用的最简单配置。

使用Identify RTL Debubber时，资源是以单一位元为基准加上去的，所以只有所需的资源才会用到，使用到的资源会动态地显示并且于每次新增或删除一探测/触发/断点时都会更新，这种呈现方式让设计者看得到面积成本（area cost）。

■结果显示
不管是一段长时间或甚至聚焦于单一时脉中，设计者都必须能够看得到除错结果。结果包含设计中探测节点取样的逻辑值，该结果通常以环状缓冲方式储存在晶片内建存储器中，必须要有明确的路径将结果对应回原设计，节点的逻辑功能必须和原来的原始代码相符。

如上述，网目节点可能在无警示下改变了名称或功能。在编译初期以设计最佳化为代价，以换取原封不动地保留某些指定的名称，而那些没有如此指定的名称就无法指望能存留下来。那些在网目中会发现的名称，可能作用已有所不同，这些改变来自网目除错器先天限制，这也解释了为何将除错结果对应回原始代码是如此的困难。

相对地，RTL除错器藉由编译前将名称直接加入原始代码的功能，将名称及探测节点功能二者都保留下来，因为这些探测点本身就需要它。所有的除错器都提供波形浏览器，Identify RTL Debugger也提供如同图五所示般，直接于RTL代码显示每一时脉的除错结果。藉由时间轴向前或向后拖拉，使用者可以检视原始代码上之每一时脉的逻辑状态值。
　

<图五>Identify Debugger对每个时脉的RTL Code检视图

 结论
设计验证包含一系列的步骤，从揭露基本功能错误到捕捉硬体上甚少发生而模煳难解的事件，需要于每一验证过程歩骤中使用不同工具：模拟器可找到逻辑错误，逻辑分析仪可找出电路板级的错误，除错器可补捉内部FPGA错误，而功能完善的除错器可以在任何事件或一系列事件上设定触发点。