CN103748562A - 测试、验证和调试架构 - Google Patents

Abstract

本文描述了用于提供测试、验证和调试架构的装置和方法。在目标级或基础级，硬件钩子(用于测试的设计或DFx)被设计到硅部件中并与之集成。控制器可提供对此类钩子的抽象访问，例如通过对硬件DFx的低级细节进行抽象的抽象层。此外，抽象层通过接口(例如API)向更高级软件/表示层提供服务、例程和数据结构，而更高级软件/表示层能够收集测试数据以用于验证和调试测试中单元/平台。此外，该架构可能提供对测试架构的层级式(多个级的)安全访问。另外，通过使用统一双向的测试访问端口，可以为平台简化对测试架构的物理访问，同时还可能准许远程访问，以执行测试中部分/平台的远程测试和调试。基本上，本文描述了用于电子部分、设备和平台的测试、验证和调试的完整测试架构堆栈。

Description

测试、验证和调试架构

技术领域

本发明涉及计算机系统的领域，并且特别涉及为计算机系统提供测试和调试基础设施。

背景技术

半导体处理和逻辑设计的发展已经允许增加集成电路设备上可存在的逻辑的量。作为一种必然，计算机系统配置已经从系统中的单个或多个集成电路演进到各个集成电路上存在多个核、多个硬件线程和多个逻辑处理器以及在这类处理器内集成的其它接口。处理器或集成电路通常包括单个物理处理器管芯，其中处理器管芯可包括任何数量的核、硬件线程、逻辑处理器、接口、存储器，控制器中心(hub)等等。而且由于处理器和计算机系统二者在复杂性方面增长，那些系统的调试和测试的性质也在错综复杂方面增长。

高速、大量的逻辑和小性质或处理器正导致无法以及时或具成本效益的方式来调试、验证和发行产品。目前，测试和调试领域在制造商和客户/供应商之间已被分叉，其中，制造商倾向于专注于他们提供的硅设备，而供应商则专注于与硅设备集成的其它部分。经常为了保护他们的硅免受恶意和意外的损害，制造商不以任何级向供应商显露他们的硬件调试钩子(hook)，因为不存在提供此类访问的安全方法。并且，随着测试更高级计算机系统的复杂性变得更繁杂，制造商花费大量金钱和精力来辅助验证(即使当发现的问题并不直接涉及他们的设备)。此外，系统中每个不同的设备(处理器，控制器中心，图形设备，母板，等)可具有它自己的对测试和调试的访问。这种在测试/调试上分离的方法只会导致在验证产品中更多的混乱和延迟。此外，由于新的集成电路的物理尺寸限制，传统的探测测试方法已经变成抑制性的。

另外，不管作为制造商还是作为供应商，例如外部逻辑分析器和示波器的试图验证的工具花费相当量的金钱，以及花费大量的时间由受过训练的员工进行连接并且正确用于验证。另外，这些外部验证工具仅能够捕获互连上的协议交换，并且难于完全断定设备的状态(state)和交互。

作为特定示例，当前计算机系统不提供在某些条件下无巨大费用和时间而验证不同的系统事件的方式，例如跟踪设备内部信号、踪迹(trace)或状态；跟踪引导过程中早期的信号；确定某些事件，例如已经被集成为带内消息的挂起(hang)事件，以及捕获新的、高速内部存储器以及输入/输出(I/O)业务和/或协议。基本上，当前没有一种统一高效的方法跨多个载体(vector)进行验证(处理器测试/验证、平台调试、电极限化(margining)、母板诊断等)。

附图说明

本发明通过示例来示出，且并非旨在由附图的图来限制。

图1示出多处理元件处理器的逻辑代表(representation)的实施例。

图2示出多处理元件处理器的逻辑代表的另一实施例。

图3示出分层测试架构的逻辑代表的实施例。

图4示出计算机系统的实施例，其包括具有DFx特征的示范实施例的多个处理器。

图5示出利用分层互连堆栈的双向互连架构的框图的实施例。

图6示出用于捕获早期通电(power-on)信号信息的框图的实施例。

图7示出用于在电子系统的引导期间捕获早期信号的捕获逻辑的高级框图的实施例。

图8示出捕获供电序列(power sequence)中早期的信号信息的方法的流程图的实施例。

图9示出在低功率状态中捕获关注信号的说明性逻辑的实施例。

图10示出具有一个或更多VCU的说明性平台的实施例。

图11示出利用VCU服务于来自软件的DFx请求的方法的流程图的实施例。

图12示出更新测试架构以计及其中示出的改变的实施例。

图13示出用于测试架构的分层堆栈的实施例。

图14示出通过分层架构堆栈来访问DFx特征的方法的流程图的实施例。

图15示出提供对测试架构的安全访问的逻辑的实施例。

图16示出用于提供测试架构中的安全访问的流程图的实施例。

图17示出平台中用于示出的测试架构的通用测试访问端口(UTAP)的实施例。

图18示出示范大量(high volume)制造连接机制中的集成电路封装的实施例。

图19示出具有微小加载特征以支持顶侧测试引脚和探测的散热器的实施例。

图20示出提供热极限化的小形状因子(form-factor)热工具(SFFTT)设计的分解图的实施例。

图21示出远程访问测试中单元的实施例。

图22示出远程访问测试中单元的另一实施例的实施例。

图23示出通过边带总线来提供内部观察的踪迹信息的逻辑的实施例。

图24示出管理内部观察踪迹(IOT)数据的方法的流程图的实施例。

图25示出用于从IOT数据重构踪迹的流程图的实施例。

图26示出执行后处理分歧检测的方法的流程图的实施例。

图27示出用于使得RTL数据结构可被高级语言访问的流程图的实施例。

图28示出用于能够实现相对于管芯上事件的电力网的调试以及空间和和时间表征的基础设施的实施例，其包括将测试和系统事件与电力网性能相关(correlate)的能力。

具体实施方式

在以下描述中，阐述了许多特定细节，例如特定类型的特定处理器配置、控制器、验证/测试/调试钩子、组件的位置、安全性协议、抽象方法、信息格式化和放置、物理访问端口配置和位置、功率配置等的示例，以便提供对本发明的透彻理解。然而，对本领域技术人员来说显而易见的是，不需要采用这些特定细节来实践本发明。在其它情况中，未详细描述众所周知的组件或方法，例如特定以及备选的处理器架构、用于所述功能和算法的特定逻辑电路/代码、特定验证控制实现细节、其它已知设计验证钩子、已知安全性和访问方法以及其它特定操作细节，以免不必要地使本发明模糊不清。

本文描述的方法和装置用于为计算机系统提供测试基础设施。具体来说，讨论的主要焦点指向包括处理器(例如处理器100)的传统计算机系统内的验证。然而，本文描述的装置和方法并不这样被限制，因为它们可连同备选计算机架构以及要测试、调试和验证的任何电子设备等来实现。例如，本文描述的测试基础设施可在通信设备或其它集成电路环境中实现。或者测试基础设施可在嵌入式、小形状因子设备(例如PDA和蜂窝电话)中被利用。

处理器架构的实施例

参考图1，示出包括多个核的处理器的实施例。处理器100包括任何处理器，例如微处理器、嵌入式处理器、数字信号处理器(DSP)、网络处理器、或者运行代码的其它设备。在一个实施例中，处理器100包括至少两个核—核101和102，它们可以包括不对称的核或对称的核(示出的实施例)。然而，处理器100可包括可能对称或不对称的任何数量的处理元件。

在一个实施例中，处理元件是指线程单元、线程槽(thread slot)、处理单元、上下文、逻辑处理器、硬件线程、核和/或任何其它元件，其能够保持用于处理器的状态，例如运行状态或者架构状态。换句话说，在一个实施例中，处理元件是指能够与代码(例如软件线程、操作系统、应用或其它代码)独立关联的任何硬件。物理处理器通常指集成电路，其可能包括任何数量的其它处理元件，例如核或硬件线程。

核经常指位于集成电路上的能够维护独立架构状态的逻辑，其中，每个独立维护的架构状态都与至少一些专用运行资源相关联。与核相比较的是，硬件线程通常指位于集成电路上的能够维护独立架构状态的任何逻辑，其中，独立维护的架构状态共享对运行资源的访问。正如能够看到的，当某些资源被共享并且其它资源被专用于架构状态时，硬件线程与核的命名之间的界限重叠。然而经常的是，核与硬件线程被操作系统看作是各个逻辑处理器，其中该操作系统能够分别地调度每个逻辑处理器上的操作。

物理处理器100(如图1中所示的)包括两个核，核101和102。此处，认为核101和102是对称的核，即具有相同的配置、功能单元和/或逻辑的核。在另一个实施例中，核101包括乱序(out-of-order)处理器核，而核102包括有序处理器核。然而，核101和102可从任何类型的核分别来选择，例如自然核(native core)、软件管理的核、适于运行自然指令集架构(ISA)的核、适于运行转换的指令集架构(ISA)的核、共同设计的核或者其它已知的核。然而为了使讨论更进一步，下面进一步详细描述核101中示出的功能单元，而核102中的单元以类似方式操作。

如所描绘的，核101包括两个硬件线程101a和101b，它们也可被称为硬件线程槽101a和101b。因此，在一个实施例中，例如操作系统的软件实体可能将处理器100看作是四个分开的处理器，即能够同时运行四个软件线程的四个逻辑处理器或处理元件。如上所混淆的(as eluded to above)，第一线程与架构状态寄存器101a相关联，第二线程与架构状态寄存器101b相关联，第三线程可与架构状态寄存器102a相关联，并且第四线程可与架构状态寄存器102b相关联。如所示的，架构状态寄存器101a在架构状态寄存器101b中被复制，因此，能够为逻辑处理器101a和逻辑处理器101b储存各个架构状态/上下文。在核101中，例如重命名分配器逻辑130中的指令指针和重命名逻辑的其它较小资源也可被复制用于线程101a和101b。可能通过分区来共享一些资源，例如重排序/引退单元135中的重排序缓冲区、ILTB 120、负载/存储缓冲区以及队列。可能完全共享其它资源，例如通用目的内部寄存器、页表基址(base)寄存器、低级数据高速缓存和数据TLB 115、运行单元140和乱序单元135的部分。

处理器100常常包括可被完全共享、通过分区共享或者由处理元件专用/专用于处理元件的其它资源。在图1中，示出具有处理器的说明性逻辑单元/资源的纯示范性处理器的一实施例。注意到，处理器可包括或者省略这些功能单元中的任何单元，以及包括任何其它已知的功能单元、逻辑或固件(未描绘)。如所示的，核101包括简化的、具有代表性的乱序(OOO)处理器核。该OOO核包括预测要运行/采纳的分支的分支目标缓冲区120以及存储用于指令的地址转换条目的指令转换缓冲区(I-TLB)120。

核101进一步包括耦合到取单元120以对所取的元素解码的解码模块125。在一个实施例中，取逻辑包括与线程槽101a、101b分别相关联的各个定序器(sequencer)。通常核101与第一指令集架构(ISA)相关联，其定义/规定可在处理器100上运行的指令。此处，作为第一ISA的部分的机器代码指令常常包括引用/规定要被执行的指令或操作的一部分指令(被称作操作码)。解码逻辑125包括从其操作码来识别这些指令并且在流水线中传递解码的指令以便处理(如第一ISA所定义)的电路。例如，在一个实施例中，如下面更加详细所讨论的，解码器125包括设计于或适合于识别特定的新指令(例如条件提交(commit)指令和/或推测检测点指令)的逻辑。作为由解码器125进行的识别或结果，架构或核101采取特定的预定义动作来执行与适当指令相关联的任务。

在一个实施例中，分配器和重命名器块130包括保留资源的分配器，例如存储指令处理结果的寄存器文件(register file)。然而，线程101a和101b有可能能够乱序运行，其中分配器和重命名器块130也保留其它资源，例如跟踪指令结果的重排序缓冲区。单元130还可包括寄存器重命名器，以将程序/指令引用寄存器重命名为处理器100内部的其它寄存器。重排序器/引退单元135包括例如上面提及的重排序器缓冲区、负载缓冲区和存储缓冲区的组件以支持乱序运行和随后乱序运行指令的有序引退。

在一个实施例中，调度器和运行单元块140，包括在运行单元上调度指令/操作的调度器单元。例如，在具有可用浮点运行单元的运行单元的端口上调度浮点指令。与运行单元有关联的寄存器文件还被包括以存储信息指令处理结果。示范运行单元包括浮点运行单元、整数运行单元、跳转运行单元、负载运行单元、存储运行单元和其它已知运行单元。

较低级数据高速缓存和数据转换缓冲区(D-TLB)150与运行单元140相耦合。数据高速缓存用来存储最近使用的/操作的元素，例如可能在存储器一致性状态中保存的数据操作数。D-TLB用于存储最近虚拟的/线性的到物理的地址转换。作为一特定示例，处理器可包括页表结构以将物理存储器分解为多个虚拟页。

此处，核101和102共享对要缓存最近取的元素的更高级或更外层(further-out)高速缓存110的访问。注意到，更高级或更外层指的是离运行单元增加或变得更远途径的高速缓存级。在一个实施例中，更高级高速缓存110是末级数据高速缓存—处理器100上的存储器层次结构中末级高速缓存—例如二级或三级数据高速缓存。然而，更高级高速缓存110并非受如此限制，因为它可关联于或包括指令高速缓存。踪迹高速缓存—一种类型的指令高速缓存—转而可被耦合在解码器125之后以存储最近解码的踪迹。

在所描绘的配置中，处理器100还包括与处理器100外部的设备(例如系统存储器175、芯片组、北桥或其它集成电路)通信的总线接口模块105。存储器175可专用于处理器100或与系统中其它设备一起被共享。存储器175类型的常见示例包括动态随机存取存储器(DRAM)、静态RAM(SRAM)、非易失性存储器(NV存储器)和其它已知的存储设备。

应当注意，图1示出带有不同模块、单元和/或逻辑的代表的示范性处理器的抽象的逻辑视图。然而，注意利用本文描述的方法和装置的处理器不需要包括示出的单元。而且，处理器可省略所示单元的部分或所有。此外，图1只描绘了两个核；然而处理器可包括任何数量的核，例如相同类型的多个核，以及多于两个的核(每个核类型相异)。

图1也示出了以点对点(point-to-point)方式通过接口耦合到外部存储器控制器(控制器中心170)的处理器的一实施例。然而，许多当前的处理器已开始包括处理器上存储器接口模块—芯片上模块—带有不同的互连架构，例如互连多个核的环配置、以及共享的高速缓存和其它接口。

图2示出此类互连架构的一个实施例。处理器200被示为包括分布式高速缓存；环互连；以及核、高速缓存和存储器控制器组件。然而，此描述是纯说明性的，作为实现描述的方法和装置的处理器可包括任何处理元件；高速缓存的级或种类；和/或存储器、前端总线或与外部设备通信的其它接口。

在一个实施例中，缓存代理(caching agent)221-224将各自管理相关联的分布式高速缓存。注意，缓存代理221-224可管理逻辑共享的高速缓存的片(slice)或各个私有(private)高速缓存(在相同的存储器级)。作为示例，每个例如组件221的高速缓存组件将为并置的(collocated)核(缓存代理与之相关联的核)管理高速缓存的片以用于管理分布式片的目的。如所描绘的，缓存代理221-224被称作缓存片接口逻辑(CSIL)；它们也可被称作高速缓存组件、代理或用于与高速缓存或其片接口的其它已知的逻辑、单元或模块。注意，高速缓存可以是任何级的高速缓存；然而对此示范性实施例，讨论集中在被核201-204共享的末级高速缓存(LLC)。

与缓存代理处置环互连250上的业务并与高速缓存片进行接口非常相似，核代理/组件211-214将分别与核201-204接口并处置业务。此外，环250被示为包括存储器外设(peripheral)中心(IMPH)230和图形中心(GFX)240以与例如存储器控制器(IMC)231和图形处理器(未示出)的其它模块进行接口。然而，环250可包括或省略上述提及的模块中的任何模块，以及可包括未示出的其它已知处理器模块。此外，可通过例如点对点互连或多点(multi-drop)互连的其它已知互连来连接类似模块。

测试基础设施的实施例

在一个实施例中，包括例如图1和2中描绘的那些或其它已知处理设备的处理器的计算机系统包括适合于支持计算机系统中的不同方面的高效(既在成本又在复杂性方面)的测试、验证和调试的测试基础设施。为提供此类高效的环境，经常有多个层(例如物理、通信和软件层)要实现，例如图3中描绘的层。

例如，物理层305包括可被包括于遍布计算机系统的多个设备(处理器、互连、控制器中心等等)的测试钩子(系统中提供的硬件或固件，用以提供测试、验证和/或调试功能性)。在一个实施例中，这些测试钩子通过设计来收集调试/验证信息(在其它硬件/固件的方向，例如微控制器；或在软件的方向，例如用户/供应商调试程序或集成在计算机平台内的代码)。一些钩子的特定说明性示例包括：设备、电验证工具、计算机中系统/设备上逻辑分析器中的架构和微架构测试/踪迹测量特征、互连协议/踪迹测量特征、平台级测试特征、功率测试特征(在下文“功率验证的实施例”部分中进行更详细的讨论)、加电(power-up)/引导踪迹测量特征、验证电路、大量制造测试特征、和其它已知的基于硬件的测量和测试特征。

除了提供用于测试的设计钩子；在一个实施例中，通信层310适合于提供测试钩子和测试/调试软件之间的通信。通信层310可简单到为软件提供直接访问测试钩子(用于定义测试情形或检索测试结果)的能力。然而，如上所述，设备设计者可能想要向供应商或用户访问模糊硅测试特征。因此在那个情形中，通信层310为软件提供硬件测试特征的抽象视图，以便于供应商或用户的软件与通信层310交互。并且通信层310以从客户的视图所抽象的方式在物理层305内与硬件交互。在一个实施例中，可被称作验证控制单元(VCU)的微控制器将控制到各种测试钩子的访问。此处，供应商软件能够请求VCU协调不同的验证任务，例如程序各种断点、微断点触发事件、提取存储的踪迹、传递(deliver)验证信息、以及提供不同级的访问。

如由最后说明性示例所暗示的，可提供关于测试基础设施的不同级的抽象和安全性。此处，硅设计者可希望准许他们自己对所有被包括的测试特征的无拘束的访问，而向不同供应商、客户和用户提供变动等级(sliding scale)的访问。因此，第一步包括提供能够对物理层305中的钩子进行抽象的抽象层。然后第二步包括提供在一个实施例中能够在访问的不同级之间进行画界(delineate)的安全访问方法。

此外，通信层310也将向上对软件层315提供验证信息的报告。例如，管芯上逻辑分析器从处理器收集踪迹信息。而且通信层310包括适于以定义的格式向例如高速缓存或系统存储器的存储装置结构提供那个踪迹信息的逻辑，以便软件层315能够访问、识别并且操纵数据。作为一种必然，也可被称为访问层的软件层315提供访问通信层310并处理测试数据内容的程序/工具。继续来自上面的示例，当踪迹信息被放置在存储装置结构中时，验证和调试程序可处理用于解释(验证和调试)的踪迹信息。

至此，访问的主要讨论有关于对来自物理层305的数据的逻辑的或抽象的访问。然而，如何访问物理层305还有待讨论。在一个示例中，此类访问是通过物理访问。此处，提供专用或通用的调试/验证端口以支持双向通信(提取的调试信息的向上通信和调试请求的向下通信等等，例如使用用于对物理钩子的抽象访问的VCU)。此端口可被安置或复制于计算机系统内的任何地方(处理器封装、芯片组、母板、或通过现有的I/O接口，例如通用串行总线接口)。

在另一实施例中，测试基础设施也将提供远程访问。例如，假设供应商正在试图验证计算机系统中的处理器，但由于当前计算机平台的复杂性，他们有麻烦。而且供应商仅被提供对处理器调试工具的高级的抽象访问。作为处理器制造商必须物理地派遣验证工程师以帮助调试过程的替代，基础设施可能准许用于验证和调试的远程访问。此外，由于安全性协议，远程制造商可能能够访问硬件基础设施中的更多以解决调试问题，而仍对供应商维护硅测试特征的隐瞒。除远程调试之外，图3的层也可被本地或远程更新，例如提供补丁以更新固件或VCU内的代码，从而提供灵活的和可适应的未来验证。

注意到，图3已经将测试架构的层概括为三个主要类别(物理，通信和软件)。然而，测试架构堆栈可被以任何方式组织，以及包括提供相同测试接口的其它层。例如，在一个实施例中，验证架构堆栈包括目标层(Dfx测试中的物理单元)、传输层(使较高级的传输不可知(transport-agnostic)堆栈适于在目标DFx单元上运行以进行测试的层)；抽象层(在应用和较低级的DFx接口之间提供抽象通信的层)；应用层(包括与用于DFx服务进行接口的抽象层通信的应用、服务、工具和其它软件的层)；和表示层(相关、可视化、和/或呈现底层数据、协议和信息的层)。

验证，测试和调试钩子的实施例

在一个实施例中，验证、测试和调试钩子被集成在计算机系统/平台和/或处理器的硅中以支持高效的测试、验证和/或调试。集成在最终产品中的验证钩子经常被称为用于调试、验证和/或测试的设计(本文称为DFx)。DFx包括被包括在产品中以支持该产品的测试、调试和/或验证(自验证工具)的任何已知钩子。下面包括此类钩子的许多说明性示例；然而，注意到该清单是非穷举的是重要的。此外，下面讨论的DFx特征中的任何特征或全部特征可被省略或与其它已知集成的测试/调试特征组合。此外，DFx的主要讨论是关于处理器；但类似的钩子可被包含在例如母板、控制器中心、嵌入式处理器、图形处理器、输入/输出(I/O设备)等等的其它硅设备中。

转到图4，描绘了包括多个处理器以讨论DFx特征的示范性实施例的计算机系统的一实施例。注意，该描绘是纯说明性的，以推进描述。而且可利用任何已知计算机系统配置，例如图1中描绘的更传统的遗留配置。此外，四个处理器(410a，b，c和d)中的每个被示为具有相同的组件。而且虽然每个处理器可包括不同的、非对称的配置，但是为简化描述，主要讨论处理器410a的特征。

在一个实施例中，计算机系统400包括一个或更多验证控制单元(VCU)以提供并控制对硅DFx的访问。如所示的，每个组件(处理器410a-d和外设控制器中心470)包括它们自己的VCU；然而，可提供任何数量或布局(layout)的VCU以控制对处理器或计算机系统的访问。在下面“验证控制器的实施例”部分中，VCU的实施例及其相关特征在下面被更详细地讨论。因此，为了描述DFx特征的实施例的目的，在此情形中，VCU 412a提供对处理器410a的DFx特征的访问。

作为DFx特征的第一示例，处理器410a包括集成的(也被称为管芯上或芯片上)逻辑分析器(ODLA或OCLA)413a。以前，逻辑分析器包括了分开的物理设备，这些设备通过外部端口或由大量探头而耦合至部分以捕获/显示设备的数字信号。但是外部设备极其昂贵。而且随着计算机在复杂性方面的发展，制作产品与开发能够与该产品进行接口的逻辑分析器之间的滞后/延迟已经猛烈地增加。因此，技术行业正失去以及时、有成本效益的方式调试、验证和发行产品的能力。

因此，在一个实施例中，处理器410a包括适于支持逻辑分析器的管芯上功能性的ODLA 413a(由硬件，固件，微代码或其组合组成)。换句话说，处理器410a包括ODLA 413a以捕获数字信号、状态、踪迹等等。作为特定说明性示例，处理器410a包括适于设置断点(或微断点)以触发捕获点的逻辑。此处，用定义触发情形的事件之一或其组合来设置例如控制寄存器的事件存储装置。而且当遇到该情形时(事件中的每个以情形中规定的方式发生)，捕获处理器中所关心的状态、信号、踪迹等等。触发条件或情形可简单到测试信号的断言(assertion)或遗弃(desertion)，或复杂到微架构事件的组合，例如，达到指令引退的数量推出(pushout)超过仅与经历二级缓存未命中的指令相关联的阈值。

注意到，ODLA 413a可不像图4内逻辑框中所示的一样被物理地分组在一起。但而是，ODLA 413a可包括通过处理器410a分布的逻辑以捕获处理器410a内任何内部或外出的信号。在一种情形中，ODLA 413a包括：与处理器410a的架构或微架构部分相关联的逻辑，用以捕获踪迹或电路逻辑电平；与内部互连相关联的逻辑，用以捕获内部业务；与例如接口460a的存储器接口相关联的逻辑，用以捕获存储器业务；与输入/输出接口(例如接口450、465，图形接口(未示出)、遗留或边带接口(未示出)，或与处理器相关联的其它已知接口)相关联的逻辑。

使用以前的外部逻辑分析器，结果被外部设备捕获。但是，在上面情形中，处理器410a作为它自己的逻辑分析器而操作。因此，在一个实施例中，ODLA 413a将利用可用计算机存储装置来保存捕获信息。例如，ODLA 413a使用高速缓存存储器或存储器420a的部分作为踪迹缓冲区来保存捕获的信息。在一个实施例中，存储器420a的部分从软件的视角来看是隔离的。而且捕获的信息被放置到存储器的隔离的部分中。

此处，用预定的、规定的格式将捕获的信息放置在它的原始形式中，以便具有适当访问级的验证软件(来自制造商或客户(在应用层))能够访问和操纵数据，例如将原始数据变换为时序图、协议解码、踪迹的代表或对逻辑分析器数据的其它已知操纵。在另一实施例中，ODLA 413a(具有包含的可编程逻辑，代码或微代码)将原始数据格式化为另一种形式并将其放置在存储器中，以用于由较高级的软件来解释。

作为特定说明性实施例，通过通信层所提供的应用编程接口(API)，例如通过由VCU 412a提供的抽象层，软件为处理器410a请求某个断点情形。VCU 412a接收该请求，并且如果该请求具有必需的安全性级访问，则VCU 412a在处理器410a的控制寄存器中设置触发情形。然后，在正常的或测试模式的运行期间，当遇到控制寄存器中所定义的断点情形时，该断点被触发。而且捕获的信息被存储到存储器420a中从操作系统视角来看是模糊的区中。通过接口API，软件能够访问、操纵并解释信息；基本上取代了使用外部逻辑分析器或示波器的需要，而且可能对硅设备的内部的和外部的通信提供更为完整和详细的查看。

除了设置触发情形之外，任何其它已知验证技术也可被与ODLA413a组合和/或集成。例如，与其它逻辑组合的ODLA 413a能够设置测试情况并捕获类似的踪迹信息。事实上，设计者为在正常运行期间不易被复制的最坏情况进行设计是非常常见的。结果，在验证期间，它可有利于能够用特定最坏情况刺激来激发处理器410a，以确定实际响应以及实际响应与以前仿真之间的相关。因此，逻辑适于设置特定逻辑状态或提供某些输入来生成ODLA 413a从其捕获数据的情形。

至此，DFx的讨论主要集中于ODLA 410a以捕获处理器410a的内部状态。然而如上面提到的，在一个实施例中，ODLA 413a和/或其它逻辑适合于还验证外部接口和互连。此处，作为在电踪迹上放置微微(pico)探头来观察设备之间的通信(像用外部逻辑分析器一样)的替代，硅中包括的ODLA 413a能够在设备内的实际接口执行相同的功能。

注意到，类似的互连钩子可被包括在处理器上接口上。作为示例，立即返回图2，DFx钩子可被绕着环250散置以验证：环250的电属性(时序极限(margin)、比特率、误差测试、交叉耦合、响铃、下冲、过冲等等)、环250上的业务、环250的通信协议(即高速缓存一致性协议)、控制器接口230/231上的业务/协议、图形接口240上的业务等等。

结果，复杂接口的验证可包括集成于硅中的钩子以验证互连架构堆栈的多个层，例如物理的、电的属性，逻辑的状态/踪迹和较高级协议。从图4，示出了包括用于验证的DFx钩子的此类接口(连接处理器410a-d的QPI接口450；分别将处理器410a-d连接到存储器设备420a-d的存储器接口460a-d；和将遗留处理器410c连接到外设控制器中心470的PCI-E或其它接口)的几个示例。此外，如本文所述，例如图形接口或边带互连的其它接口也可利用类似的DFx钩子。然而，注意到所示接口是处理器中心的是重要的。而且，例如PCH 470的其它设备也可包括类似的DFx钩子以验证其它接口，例如外设接口(PCI-E、通用串行总线(USB)、串行高级技术附连(SATA)、直接媒体接口(DMI)和其它已知计算机互连)。

为了提供特定说明示例，图5描绘了利用分层互连堆栈的双向互连架构的框图的示范性实施例；其说明性示例包括PCI高速(Express)(PCI-E)和快速通道互连(QPI)。描绘的分层的架构主要参考QPI架构而讨论，但可被类似地应用于任何互连，例如PCI、PCI-E、图形、存储器、外设或其它已知互连。对图5的层(例如物理层502)的参考包括可在不同的代理中实现的通用层的讨论，例如物理层502a和物理层502b。如所描绘的，互连堆栈被划分为五个层，它们中的一个或更多基于设计实现是可能可选的。例如，在一个实施例中，路由选择层504被嵌入到链路层503的功能性中；因此，在一个实施例中，路由选择层并非是分开的且有区别的层。

在一个实施例中，物理层502负责物理媒体上的信息的电传输。例如，在链路层实体503a和503b之间利用物理点对点链路。作为说明性示例，该物理链路包括差分信令(signaling)方案，其包括双向差分信令对551和552。此处，物理层可能被逻辑地划分为电的子块和逻辑的子块，以便物理层将分隔堆栈的其余部分与信息的电传输并将与链路层503通信。

在一个实施例中，链路层503从堆栈的较上层抽象物理层502并向多个虚拟信道(channel)和消息类(class)中提供涉及链路的服务，例如物理信道/接口的虚拟化和连接的代理/实体之间的可靠数据传输和流程控制。此处，虚拟信道可被视为供堆栈的较上层使用的多个虚拟网络。例如，协议层506可能依赖由链路层503提供的抽象将协议消息映射到消息类中，并因此映射到一个或更多虚拟信道。

在一个实施例中，路由选择层504提供了一种用于将分组从源路由到目的地的灵活方法。如上述的，在极其简单的拓扑中，路由选择层504可不是明显的，而是被集成到链路层503的功能性中。例如，路由选择层504可依赖于链路层503的抽象来规定<端口，虚拟网络>对以路由分组。此处，保存路由选择表信息来为分组提供路由选择信息。

在一个实施例中，传输层505提供端到端(end-to-end)的可靠传送服务。与路由层504类似，基于设计实现，传输层505也是可选的。作为示例，传输层505依赖于路由选择层504服务来提供用于协议层506的可靠的传送支持。在一个实施例中，在互连架构内，组件的子集包括传输层505。结果，组件的此子集定义了涉及传输层505的分组的子字段，而其它组件可能不定义那些子字段。

在一个实施例中，协议层506将实现节点/代理之间较高级的通信协议，例如高速缓存一致性、排序、对等(peer-to-peer)通信、中断传递等等。换句话说，协议层506相应地为节点或代理(例如主节点(home node)、对等体(peer)节点、缓存节点和非缓存节点)定义可允许的消息、请求、响应、阶段(phase)、一致性状态等等。下面讨论消息的示例，例如主节点消息、探听消息、响应消息等等。

注意到，层的讨论和与之相关联的逻辑可以任何方式被耦合。例如，可以说协议逻辑被耦合到物理层，即传送或接收逻辑。此处，如可从图5能看到的，在一个实施例中，协议逻辑可不被直接耦合到物理层逻辑，而是通过其它层逻辑被耦合。此外，在一个实施例中，互连堆栈被耦合到例如高速缓存控制或高速缓存存储器逻辑的内组件逻辑以发起适当的高速缓存一致性动作。

在一个实施例中，基于QPI的互连包括“修改的排他共享无效转发(Modified Exclusive Shared Invalid Forward)”(MESIF)协议，其提供与不具有单一、串行总线的可能限制的探听协议类似的协议。与探听高速缓存协议相似，MESIF依赖具有数据的缓存副本的节点以维护一致性。使用点对点链路而不是同步的集中化的广播引入时间歪曲(time-warp)的问题，即从不同节点的视点来看事件呈现出以不同顺序发生的事实。作为示例，MESIF协议通过对由于时间歪曲引起的可能的错误进行识别并且对其提供协议或软件解决方案来处置时间歪曲。

主节点经常与数据的未缓存的副本相关联。结果，主节点可参与涉及与主节点相关联的数据的事务。然而，主节点并不必须被包括在与事务相关联的“关键通道”中，而是主节点可放入事务以解决冲突和时间歪曲事项(issue)。由于方案的同时发生的广播性质，在一个实施例中，当获得数据的可缓存副本，在某些情况中，在最小可能的等待时间(单次回返程请求-响应)中，MESIF获得与探听协议相关联的低等待时间。

在一个实施例中，与MESIF协议有关的基础事务牵涉向所有对等体节点以及主节点广播初始请求。如果副本在状态E、F或M一致性状态中被缓存，则它被包含于响应中。然后向主节点发送第二消息，通知它请求已被满足。如果请求的行未被缓存，或如果只有S状态副本存在，则向主节点发送的第二请求被用来确证(confirm)以前的请求，主节点到现在可已经从它的存储器取了该请求。在任一情况中，主节点都响应于第二请求(并且可能响应于第一请求，虽然它们有时能被组合)，以用于同步和冲突解决方案的目的。注意到主节点可具有一个或更多高速缓存，因此就像任何其它节点一样，它可响应于初始请求。

在一个实施例中，以分布式方式来处置冲突。由于各个请求能被延迟任意长时间，因此时间歪曲问题使得难以检测冲突。然而，如果每个节点在做出请求后监视冲突，则冲突将被检测到。多个节点可以可能检测冲突，但是作为示例，节点中的至少一个将会检测冲突。结果，在一个实施例中，来自节点的响应可能包含冲突信息。

在一个实施例中，准许从响应接收数据副本的节点在接收后立刻在内部使用数据，但并不使得使用数据的效果对系统的其余部分可见，即全局可见，直到该节点已接收确证。该确证也包括请求节点必须向另一个节点转发它的副本的、并或许将该节点从它自己的高速缓存中驱逐的指令。最后，当某个节点通过供应缓存的数据而响应于来自另一节点的请求时，该节点在一个实施例中就为相同的高速缓存行推迟它接收的其它请求，直到该节点从主节点接收确认该节点转发了数据的事实的响应，因此确保所有节点观察到(可能可写的)高速缓存行的传输的相同顺序。

如上述的，主节点是用于未缓存数据的储存库，但主节点也可包括处理器和高速缓存。此处，当主节点处理器未命中缓存时，主节点向所有其它(对等体)节点广播请求，并且主节点像它将处置到达用于主节点的任何其它请求一样在内部处置请求。注意到，这是特殊情况，其中主节点并不明显地向自身(主节点)发送消息。此外，当对于本地缓存的数据的外部请求到达时，主节点适当地响应。

在一致性(高速缓存和主)代理、非缓存代理、以及其它代理(存储器控制器、处理器等等)之间，公开的消息协议定义一组准许的消息。一致性协议使用这些消息作为算法中的词语和语法，以表达一致性思想。该算法合理排序请求，解决冲突，并描述了缓存代理之间的交互。尽管上文已经描述过MESIF，但并不要求利用MESIF高速缓存一致性协议。例如，转发状态可不被利用，这导致已知MESIF协议的利用。此外，注意上述讨论是MESIF协议实施例的示范性概述。因此，上述各种组件在分开的实施例中可不同。

如能看见的，如此复杂的验证和调试(既从电的又从协议的观点)变得极其繁琐。因此，在一个实施例中，来自图4的处理器410a包括DFx以帮助遍布分层互连堆栈的验证。例如，响应于触发情形或某件其它事件的ODLA 413a能够捕获互连分层架构的业务、踪迹或状态。在一个实施例中，状态是指验证对象的其它组件和/或代理、设备、参数的状态的快照(snapshot)。状态也可被称为架构或验证对象的架构状态。作为另一示例，状态由在该状态快照时的参数值的组合来定义。因此，如果为互连架构标识了一百个参数，则对于那一百个参数不同值的每种组合都有可能导致不同的状态。

由于状态经常是指用于复杂协议的大量参数，用于高速缓存一致性协议的状态的过简化的说明性示例包括在共享一致性状态中保存高速缓存行的一个处理器，在无效状态中保存高速缓存行的两个处理器以及在处理器之一接收的探听。此处，存在多个协议代理、多个状态中保存的多个高速缓存行以及在特定目的地所接收的请求/消息。因此，在这个独自的简单示例中，存在非常少量的参数。作为另一说明性示例，携带数据有效负荷的写事务有可能导致多个状态，因为其它参数、例如写的目的地、与要写入的数据有效负荷相关联的高速缓存行的状态、互连业务、其它代理的写响应等等可被变更。

因此，在一个实施例中，参数是指在可被变更或放置在不同状态中的协议、物理逻辑、设备、代理或全局状态/变量之内的任何元素。作为特定示例，当验证高速缓存一致性互连协议时，对于例如处理器410a的缓存代理的参数包括对探听的高速缓存响应。此处，高速缓存响应参数的一个值包括向请求设备转发被探听的高速缓存行，而且高速缓存响应参数的第二个值包括向主节点写高速缓存行。其它常见的一致性协议参数包括不同类型的代理、代理响应、设备响应、互连响应、消息响应、响应类型、特定动作的其它响应、响应目的地、消息、消息类型、消息目的地、请求、请求类型、请求目的地、高速缓存类型、高速缓存状态、高速缓存位置、寄存器状态等等。

然而，由于例如物理互连、通信协议或其它协议的任何架构可以是验证的对象，参数中可会有各种各样的变量。可能的涉及协议的参数的非穷举说明性清单包括协议代理的数量、协议代理的类型、代理的高速缓存实现的类型、不同类型协议代理的数量、协议代理的样式、协议代理的状态、协议代理中或总线上的状态机或电路的状态、代理标识符，协议请求的数量、请求类型、请求源、请求目的地、请求状态、被引用的操作、操作源、被引用的地址、被访问的地址、地址位置状态、数据有效负荷、协议代理状态、高速缓存状态、高速缓存行的状态、和物理协议状态参数、例如电压、频率、功率状态、或其它物理协议属性。

关于物理层502a、b，几个互连结构的物理参数示例包括电压，下冲，过冲，频率，周期，扩频，抖动，时序极限，噪声等，同时其它参数包括涉及互连的状态的状态机、代理类型、代理状态、代理中I/O电路的状态等等。然而，架构内的任何可变元素都可被视为参数。

因此，在一个实施例中，ODLA 413a适于捕获状态或踪迹，其可涵盖目标接口的全部或部分。除了曾经向例如触发情形的定义的事件响应的特定快照之外，ODLA 413a适于捕获业务(接口上通信的多个状态)。在此情形中，设备之间的协议交换被捕获。并且在数据被处理之后，高级软件能够创建协议图表，来验证在接口上正发生正确的协议交换。继续上面的示例，DFx硅可生成或被加载有特定触发情形，该情形与在排他一致性状态中接收对高速缓存行的特定探听消息的处理器410a相关联。而且ODLA 413a在存储器420a的部分中捕获信息，例如处理器410的对例如探听消息的响应。通过由VCU412a提供的API，第三方供应商(TPV)应用使用合适的访问能够基于在第二存储器420a中保存的信息来建立协议，以验证对于定义的状态的境况下的特定探听消息给予了适当响应。

如从此示例能看出的，可利用类似的方法和装置来验证QPI互连450的电特性和协议，例如上面介绍的MESIF高速缓存一致协议。而且QPI互连450的说明性示例可被外推以展示硅上钩子如何能够为例如分层互连架构的任何接口提供验证。

除了用于处理器410a的内部和外部接口的ODLA 413a和验证钩子以外，其它硅钩子也可被集成在处理器410a中。例如，在一个实施例中，特定的微架构钩子被包括在处理器410a中。例如，具有序号11/143,425的名称为“ENHANCEMENTS TO PERFORMANCEMONITORING ARCHITCUTRE FOR CRITICAL PATH-BASEDANALYSIS，”的共同未决申请讨论了用于监视微架构性能的装置和方法。通过仿真、分析推理、引退推出测量、总运行时间、以及其它确定每个实例事件成本的方法来监视性能。结果，类似的装置可被包括在硅中来基于微架构的事件来标记/计数指令、测量引退推出、确定指令/程序的总运行时间以及验证/调试处理器的任何其它已知特征。

作为另一示例，处理器410a示出了功率控制单元(PCU)414a来协调并控制功率，例如处理器410a中的处理元件的功率状态。此外，DFx钩子可被包括在PCU414a内以捕获不同功率验证度量，例如功率消耗级、不同的功率状态中花费时间的总量、功率状态转变的频率、功率状态转变的协议以及任何其它已知涉及功率的度量。与ODLA 413a的操作类似，功率信息可在正常操作期间被收集，在具有如刺激所提供的特定最坏情况功率情形(即由在接口上传送的最坏情况型式(pattern)所生成的最坏情况功率共振频率)的测试模式期间被收集，或响应于遇到触发情形而被收集。下面关于图28更详细地讨论功率DFx和操作。

再次从说明性的可被类似地包括于电子系统内任何设备中的处理器中心的DFx离开，也可包括其它平台级DFx。注意到，上面和下面描述的DFx(调试)特征可被分别实现，而无需本文描述的测试架构的其它部分。例如，如参考图6-8更详细讨论的，早期在引导过程中的信号信息的捕获可在不具有验证控制单元或分层的抽象访问的遗留系统上被实现。

转到图6，示出了用于捕获在信号信息上早期功率的框图的实施例。此处，PCH 605通过直接媒体接口(DMI)635被耦合到处理器640。通常在通电期间，PCH 605首先被加电。而且像大多数硅设备一样，PCH 605在若干阶(stage)中被加电。例如，某些阱(well)按照特定顺序被加电。作为纯的说明性示例，时钟610最先被通电；那些之后是阱615和620，例如中止(suspend)阱、活动阱、实时时钟阱等。最后启用测试逻辑625，例如可管理性引擎和/或测试访问端口(TAP)。在有些境况中，在启用测试逻辑625之前转变的某些通电或早期信号是不可见的(不存在到具有那些信号的任何事项中的可见性)，因为到测试逻辑625在引导过程中被启用之时，与那些信号相关联的任何转变信号经常被丢失。但是，在验证和调试期间，可有利的是，能够查看和捕获此类信号信息。此类信号的说明性示例包括功率管理控制器重置信号。此处，此信号的转变用来指示功率管理控制器，以启动取和运行。因此，能够确定：(1)信号是否没转变；(2)信号是否转变；和/或(3)何时信号转变了，从而帮助调试其中功率管理控制器挂起的情形(‘阻塞’情形)。

因此，在一个实施例中，早期通电信号捕获逻辑(也可被称为早期引导测试逻辑)将在设备被完全通电之前捕获早期信号信息。用于捕获例如踪迹的信号信息的任何已知方法或装置都可被利用。此处，捕获逻辑630包括适于在初始通电之后捕获特定信号信息并且存储此类信号信息的逻辑。而且随后，当测试逻辑625变为启用的，信息可被读出以执行适当的调试操作。

转到图7，描绘了用于在电子系统的引导期间捕获早期信号的捕获逻辑的高级框图实施例。如所示的，捕获逻辑700包括存储元件720，例如寄存器，适于捕获/保存关于关注信号(即在引导期间将被监视的信号，例如信号1，2，3……11)的信息。在一个实施例中，在应用功率时，捕获逻辑700就开始按照默认的预配置的设置(没有对于用户触发或第三方访问/编程的任何需要)来捕获信号信息。作为另一示例，捕获依据特定条件的发生而开始，例如特定信号/时钟的转变或特定的阱被启用。类似地，信号捕获可依据条件的发生而被暂停，例如一定量时间/周期之后、一定量时间没有检测到关注的信号的转变之后、当最后关注信号转变时、当一定量时间之后最后关注信号没有转变时、当特定的阱被启用时、当测试逻辑被启用时、当程序指示捕获应该停止时、或依据任何其它已知事件。

尽管用于捕获信号信息(转变时间，转变数量，转变方向，踪迹等等)的任何已知装置或方法可被利用，参考图7讨论了特定的说明性示例。在此情形中，寄存器720记录关注的信号(或每个关注的信号)转变时的时间。例如，寄存器720包括信号名称字段和时间戳字段。信号名称字段适于保存标识关注信号的比特代表(即，可识别为与特定关注信号相对应的比特型式)。并且时间戳字段适于保存与在信号名称字段中标识的信号的转变相对应的时间的比特代表。注意到，在一种情形中，时间戳值跨设备的硅变形(skew)是确定性的，例如来自图6的PCH 605。此处，时间戳跨将被用作调试的硅变形是确定性的。

此外，寄存器720可保存状况(status)字段，该字段适于保存有效值以指示信号名称字段和时间戳字段保存有效信息。相反，无效值指示相同寄存器中的相应字段的状态是无效的。在一个实施例中，寄存器720包括寄存器阵列来保存关于所有关注信号的信息(如由设计者来决定或后来由制造商更新)。此外，寄存器720可被实现为具有深度为N(N为正整数)的环形缓冲区，因此N个条目的最后集合将被捕获，以能够实现最后的N个功率状态转变中事项的标识。

为了提供更加特定说明性示例，假设功率控制单元重置信号(信号11)将被捕获/监视。此处，通电信号启动引导过程。然后例如PCH605的设备开始加电。注意寄存器720可被初始化为默认值。响应于通电信号或早期起动信号的其它转变，计数器725开始计数。当信号11转变时，它导致脉冲生成逻辑710生成脉冲，该逻辑可也包括对于信号11(未示出)的边缘检测逻辑。结果，将标识信号11(功率控制单元重置信号)的比特型式存储进信号名称字段735。注意其它信息也可被存储，例如指示转变方向的比特。除了更新信号名称字段，计数器725的值(时间戳)被存储到时间戳字段730中。并且将状况字段740设置成有效值，例如设为高逻辑值，来指示信号名称字段735和时间戳字段730中保存的值是有效的。

此处，该过程可为更多信号的转变而重复。如上所述，环形缓冲区组织可用于为与环形缓冲区的深度一样多的功率状态转变维护信息。此外，在一个实施例中，当信号转变被捕获后，计数器725继续计数(从开始计数的绝对时间戳)。而且在另一示例中，计数器725被重置(从以前信号转变开始的相对时间戳)。此外，如上所述，捕获逻辑700依据预定事件来暂停信号信息捕获，该预定事件例如是最后的信号转变或一定量时间后的最后信号转变的缺乏(可能挂起或‘阻塞’情形)。

在一个实施例中，捕获完成后，寄存器720能够被读出(即信号信息是可视的，以依据信号转变或其缺乏而执行任何必要的调试)。在一个实施例中，在遗留系统中，利用遗留的测试访问端口来物理地连接和读出寄存器信息。在一个说明性示例中，此类读不通过熔丝(fuse)被掩蔽或封锁，而且它可在启用管理性引擎或测试端口之后的任何时间被执行。在另一实施例中，如本文描述的，验证架构提供并控制对寄存器720的访问。例如，验证控制单元(VCU)可能提供对寄存器的抽象且安全的访问。此处，软件能够通过API的使用来请求信息。而且VCU能够从寄存器720读出信息并将它提供给请求软件。注意如本文所描述的，替代寄存器720或与之组合的是，捕获的信息可被放置在系统存储器中，如前面参考利用系统存储器作为用于ODLA的踪迹缓冲区所讨论的。

着重注意的是，上述讨论主要集中于在通电期间捕获位于控制器中心内的信号踪迹。然而，本文描述的用于捕获早期信号踪迹的装置和方法并非如此受限。事实上，在任何硅设备的测试模块被启用/就绪之前，它们可被类似地应用于这些任何的硅设备。例如，可在处理器640或小形状因子设备中的嵌入式处理器中实现类似的装置，以在启用与之相关联的测试/验证单元之前捕获信号信息。

参考图8，描绘了捕获供电序列中早期的信号信息的方法流程图的实施例。在流程805中，通电事件发生。通电事件可简单至功率信号的断言(或解断言(de-assertion))。然而，在另一示例中，捕获响应于通电信号而发生，但依赖于干涉信号转变来实际开始捕获信息。例如，对于控制器中心的内部信号可响应于通电信号而转变。而且信号信息的捕获直接响应于该干涉、内部信号而启动。此处，通电事件可包括功率信号、内信号的转变、或两者。

在流程810中，早期通电信号信息(关于可在测试单元被启用之前转变的信号的信息)被捕获。如上述的，可利用任何已知装置或方法来捕获此类信息。例如，可利用被预置成依据功率事件捕获信息的简化的ODLA。作为另一示例，如上面描述的捕获逻辑也可被使用。不管装置和方法如何，在流程815中捕获依据预定条件被暂停/停止，例如在一定量的时间/周期之后、在一定量时间未检测到关注信号的转变之后、当最后关注信号转变时、当一段时间之后最后关注信号没有转变时、当启用特定阱时、当启用测试逻辑时、当程序指示捕获应该停止时，或依据任何其它已知预定开启(boot-up)事件。

在流程820中，测试端口变成可用的。例如，管理性引擎测试访问端口在引导过程期间被启用。作为另一说明示例，如下所述，VCU连同通用访问端口一起被启用。当测试端口被启用时，可安全地通过抽象层或直接通过测试设备来读取流程810中捕获的信号信息。并且软件或调试器能够确定是否发生任何问题或事项。因此，相比于以前对不使用此类集成硬件钩子的调试的尝试，在引导过程中(例如在启用通常对内部信号提供可见性的逻辑之前)转变的信号能够被有效地监视和调试而不添加很多花费和努力。

在一个实施例中，除了上述用于捕获早期通电信号的DFx特征之外，钩子也被包括以在超低功率域中捕获信号踪迹。转到图9，示出了在低功率状态中捕获关注信号的说明性逻辑的实施例。

功率状态经常被定义为是产品特定的；然而，在一个实施例中，功率状态是指具有不同功率规范的任何状态，例如功率状态的高级配置和功率接口(ACPI)物种形成(speciation)。对于处理器，ACPI规范定义了三种基础的状态：C0(操作/活动状态)；C1(已知为暂停，其中指令未正在运行但能返回到运行状态)；C2(已知为停止时钟，其中维护软件可见状态，但它可需要更长的时间醒来)；和C3(已知为睡眠，其中处理器并不保持高速缓存一致，而是维护其它状态)。此外，已经在这些状态上做出变更。例如，增强的C1状态可被用于降低功率消耗。并且C3/睡眠上的变更可包括更深的睡眠状态(即C6是更深或最深的睡眠状态)，这要求更多的时间来唤醒处理元件。注意到，这些功率状态纯粹是说明性的并且主要参考处理器而被利用。然而，ACPI规范为其它设备(例如控制器中心)定义了类似状态。

如描绘的，可包括处理器、控制器中心、图形设备或其它已知涉及计算机的设备的设备900包括在低功率状态(即在上面示例中是非操作的C0状态的任何状态)期间捕获关注信号901-906的逻辑。逻辑的第一阶(实况(live)捕获920)捕获信号901-906的实况踪迹/数值。例如，时序图970示出了基于时钟信号910的信号906的捕获。注意到，例如调试启用的启用信号也可被用于当不在调试模式中时约束时钟910(即门控(gate)时钟910以翻转阶920、930)。并且如能看出的，如由功率周期信号925指示的，当功率周期被发起时，第二阶(存储的值930)捕获信号901-906的实况状况。例如，在PCH中，功率周期信号可被生成以响应于特定的预定义的引脚的断言(解断言)。此处，在无引导情境中，验证工程师切换引脚以重引导系统。因此，此情形下，信号901-906的最近版本/状况被捕获并存储。注意到在描绘的示例中，如时序图970中所示，在成功的引导时，存储的值930保存最近的失败引导条件期间信号901-906的状况950。

为了提供特定示例以示出逻辑900的操作，假设设备/系统900尝试了5次引导。在第一次引导时，启用比特被设置以装备(arm)逻辑。此处，遗留JTAG或其它测试接口可用于设置启用比特。在另一个实施例中，VCU设置启用比特。假设第1次引导成功，功率周期信号925被驱动至低，所以信号901-906的状况被捕获。在第2次成功的引导时，状况指示全一逻辑值(以前的成功引导，并且启用比特仍保持被装备)。然而，在未成功的第3引导时，系统被重启。此处，功率周期信号被切换，例如从高至低再到高，信号901-906的状况在功率周期信号925被驱动至低时被捕获。假设第4次引导也不成功，系统以同样的方式重启。在随后的第5次成功引导时，状况950将为最近不成功的引导尝试(引导尝试4)报告信号901-906的踪迹/状况。如上所述，可由遗留测试设备读取状况950。或在另一个实施例中，利用实现分层测试架构的VCU提供和控制对逻辑900的访问。

上述讨论中的许多是关于为处理器捕获验证信息；其中一些集中于捕获用于例如PCH的控制器中心的信号的状态。然而，DFx钩子并非如此受限，正如它们可在其它区域中并在平台各处被实现。前面简要提及的另一区域正在为功率传递网络以及功率关联硬件的调试、验证和测试提供硬件钩子。例如，频率步进逻辑或电压相对于时间的测量逻辑可能够表征(定义阻抗剖面(profile)和/或确定共振频率)功率传递网络。或测量逻辑可被由母板上的电压调节器(VR)插入，以测量当前需求、功率消耗，噪声等等的量。

此外，本文所述的DFx和验证架构不限于实验室验证。此处，DFx特征可被集成在处理器、控制器中心、母板或其它设备中来与大量制造(HVM)测试设备相接口。结果，如下所述，任何已知HVM测试可通过通用访问接口来路由。而且在一个实施例中，作为制造商，任何安全、分层的验证架构给予制造测试人员最高的安全性调查(security clearance)(即对最多或全部包括的DFx特征的低级访问)。

作为跨产品提供测试架构的一种必然，可跨例如处理器、母板等等的产品诊断出制造缺陷(跨产品验证)。此处，通过向上通过分层测试架构提供测试结果以便多个产品上的软件来理解，缺陷和变形可以是可容易确定的。例如，使用通过VCU和分层测试架构对DFx的访问，HVM可对数以千计的处理器进行测试。而且，由于结果被聚集到软件/表示层，软件能够将信息制定为可呈现的信息，例如变形、缺陷等等。

作为另一示例，以前母板诊断依赖在多个具有专用外部测试器的板上测试点的电路中(电路板的探查的测试)测试(ICT)。随着形状因子已收缩以及测试点成本已飙升，继续支持ICT变得非常困难。结果，在一个实施例中，利用本文所述的测试架构(例如VCU和为较高级软件提供的API)以提供跨设备的全面诊断。

结果，例如是无缺陷的但由于母板失败而返回(“无缺陷发现”返回)的例如处理器和芯片组的设备的以前返回可通过向测试提供此优雅简单的解决方案而没有对ICT的需求来避免。例如，多达测试成本的30％可通过集成DFx和通过VCU和API而不是必须使用外部ICT设备来提供DFx的支持(访问和控制)而被减少。

验证控制器的实施例

在一个实施例中，验证控制单元(VCU)被包括以提供对例如本文描述的硬件测试、验证和调试钩子的DFx特征的控制和访问。VCU可包括任何硬件、固件、软件、代码、微代码或其组合来实现此类控制和/或访问。转到图10，描绘了具有一个或更多VCU的说明性平台的实施例。如所示的，平台1000包括多个VCU；一个在处理器1010中以及一个在处理器1075中。在此情形中，VCU可被包括于多个设备内(处理器、控制器中心、图形设备、母板或其它已知计算机设备)。结果，每个VCU可负责对它们的相应硅DFx特征的访问和控制。此处，例如VCU 1012的VCU被包括在每个处理器中，以便能够向处理器1010的DFx特征(架构和微架构DFx 1015、ODLA 103和PCU1014)提供访问和控制。注意到，在平台1000内多个硅设备中的此分布使得在单独部分测试(例如各个部分的HVM测试)期间和在平台测试/调试(例如多个部分被集成到平台中，其中整个系统分析以及系统中的单独部分性能可以是有用的)期间能够访问和控制DFx特征。

在一个示例中，使用此分布式VCU实现，多个VCU之间能够彼此通信。此类通信可直接执行，例如在将平台1000中的VCU 1012和1080耦合在一起的VCU互连(未显示)上执行。备选的是，例如VCU 1012和VCU 1080的VCU可在耦合它们的对应设备(处理器1010和PCH 1075)的现有互连(可包括直接媒体接口(DMI)、快速通道接口、快速PCI接口或其它已知互连的互连1065)上通信。作为另一备选，VCU可通过共享存储器空间彼此通信。例如，VCU1012向从操作系统来看是模糊的但对例如PCH 1075/VCU 1080的其它系统设备可见的存储器部分1021写。结果，VCU 1080能够读由VCU 1012写的信息，反之亦然。

作为特定的说明性示例，当统一的端口被提供以用于对验证架构的访问时，如下面更详细描述的，VCU之间的互连/通信被用来协调对遍及平台的DFx特征的软件访问。此外，其它事项可由VCU和/或管理性引擎(例如活锁、死锁、补丁负载同步、功率/性能状态转变同步、生存性、触发和踪迹配置、转储数据后收集、安全性和捕获/报告覆盖)之间的通信来检测并解决。

虽然上述讨论主要集中在每个部分(例如处理器、控制器中心、母板)中的VCU的分布，但此类分布并不是必需的。备选的是，单个VCU被包括在例如处理器1010或PCH 1075的设备中。而且它控制对它的DFx钩子的访问，以及对平台的DFx钩子的访问。此外，当利用分布式VCU实现时，VCU并不需要对称。在该情况中，由于硅部分可相异，所以VCU也可不同。此外，一个或更多VCU可具有较高的优先级(例如头主(head home)或主控(master)VCU，协调系统中其它VCU的访问和控制)。备选的是，每个VCU可被认为是通信主控。

在一个实施例中，VCU 1012包括可编程引擎或单元以控制对处理器1010的DFx特征的访问。例如，VCU 1012包括微控制器。微控制器经常包括具有自己的处理元件、存储器(闪存、可编程ROM、SRAM或其它已知存储器设备)和通信接口的设备。基本上，它可被视为是处理器1000内的小的、嵌入式、或自包含的计算机。因此，它可保存它自己的代码/微代码(当被它的处理元件运行时)以实现它的向上与较高级软件以及向下与DFx特征的接口。此外，如下面更详细地描述的，微控制器可被更新(保存于其存储器中的其控制或操作代码打补丁(例如通过认证的补丁)或更新)以提供新的功能性，以用于适合测试、验证架构的其它层(软件或DFx特征)中的改变。因此，可对平台DFx特征或较高级软件做出改变，并且VCU能够不替换硬件(或整个部分)而适应。

注意到，包括微控制器的VCU的讨论是纯说明性的。反而，类似的设备可对DFx特征执行类似的访问控制并且向较高级层提供类似的接口。例如，可编程逻辑设备，例如可编程阵列逻辑设备、通用阵列逻辑设备，复杂可编程逻辑设备，现场可编程门阵列设备等等可被利用。此外，VCU 1012被作为处理器1010中单个逻辑块而示出。然而，正如ODLA可在处理器1010各处分布，VCU 1012的部分也可被分布于处理器1010的封装或管芯的不同部分。

具有一些DFx特征的VCU1012交互的说明性示例立即被包括在下面以增进讨论。此处，VCU 1012具有对核上接口1011中的信道(例如被耦合到处理器1010的控制寄存器的消息信道)的访问。此外，VCU 1012具有对例如扫描输出信号和熔丝的扫描信号的访问。结果，VCU 1012能够编程各种微断点触发事件(情形)、指引ODLA 1013在存储器1020(或与操作系统隔离的存储器1021的部分)中存储踪迹、提取存储在存储器120中的踪迹、以及向较高级软件(例如调试工具)传递踪迹。此外，VCU 1010能够基于当前安全性(解锁)级控制哪些DFx特征可被访问。而且在一个实施例中，VCU 1010显露了工具能够为访问处理器1010的DFx特征而对其编程的API。

在一个实施例中，VCU 1012负责实现下面描述的验证分层架构中的一个或更多层，例如向较高级软件抽象或模糊DFx特征的硬件细节的抽象层。而且不管抽象层是否被利用，在一个实施例中，VCU1012负责对DFx特征的安全访问，如下面在验证基础设施安全性部分的实施例中描述的。

转到图11，示出了利用VCU服务来自软件的DFx请求的方法的流程图的实施例。在流程1105中，DFx请求响应于运行软件程序(例如来自第三方供应商的测试和调试程序)根据应用编程接口(API)而被生成。此处，DFx的请求可符合被提供以与由VCU提供的服务和例程交互的API的规范和规则。换句话说，软件程序可符合由API规定的“词汇”而被写，例如调用由API识别的惯例(convention)。

在流程1110中，DFx请求用VCU实现的API来解释。此处，API作为软件和DFx硬件之间的接口或促进器(facilitator)而工作。作为示例，存储在VCU中的代码(例如存储在VCU微控制器的存储器中的代码)响应于DFx请求而被运行。在此情形中，VCU中存储的代码可包括库、例程、数据结构、对象类、协议等等。此处，假设DFx请求包括对VCU中例程的调用，这将导致VCU上例程的运行以执行与DFx特征相关联的一些功能/操作。

在一个实施例中，如下面更详细描述的，VCU将控制对DFx硬件的访问(安全性)。因此，在流程1115中，基于安全性级来确定是否准许DFx请求。虽然下面会更详细地讨论安全性，但在此点提供简化的示例以继续VCU的说明性操作。因此作为示例，VCU可包括安全访问的多个级；其每个级准许对硬件DFx的不同级的访问。例如，每个级可与加密的通行码(passcode)相关联。所以当软件程序开始运行时，可提供安全通行码以解锁它的安全性级，指定软件程序能够访问什么特征。因此，在流程1115中，根据由VCU预定义的访问级，确定DFx请求是否在与软件程序相关联的安全性级内是准许的。如果该DFx请不被准许，则在流程1120中它将被适当处置(拒绝、不执行、抛出异常等等)。

另一方面，如果DFx请求被准许，则在流程1125中DFx请求被服务。继续上面的示例，其中如果DFx请求包括对由API定义的服务例程的调用，则VCU执行服务例程。此处，如上述的，服务例程可包含任何例程以设立、发起硬件DFx特征或与之交互。例如，VCU可设置微断点触发事件，其导致处理器遇到触发事件并且ODLA捕获在断点处的踪迹。结果(踪迹)可然后在流程1130中被提取，例如被写出到由ODLA用作踪迹缓冲区的存储器。而且在流程1135中结果被提供至软件程序。在此情形中，软件程序能够读存储器以为后来的解释/调试获得踪迹信息。

转到图12，对测试架构的改变在流程1205中被确定。改变可包括架构的任何层内的任何改变，例如对DFx硬件的改变、在VCU如何与另一个VCU交互方面要做出的改变、在VCU如何与DFx硬件交互方面的改变、由VCU提供的服务中的改变、安全性级(它们每个准许访问什么)中的改变、API规范中的改变等。而且在流程1210中，VCU被更新以计及对测试架构的改变。此处，补丁、认证的补丁、或更新可被本地或远程地应用以更新VCU代码以计及改变。结果，当处于分层堆栈中的VCU级或下面的某个东西改变时，制造商仅必须向VCU软件提供更新。而且因为在此示例中，仅仅API是向较高级软件显露的，所以第三方供应商不必更新他们的软件程序或工具。相反，API保持不变，但是VCU的动作基于计及测试架构中的改变的更新而被修改。因此，当存在对测试架构堆栈的微小改变时，费用(重设计或替换硬件的成本)和时间可能由于不必修改堆栈的所有级而被节省。

验证分层架构的实施例

如上文提到的，测试、验证和调试架构在一个实施例中在分层堆栈中被实现。用于测试架构的分层堆栈的实施例在图13中被示出。注意到，描绘的层是纯说明性的。而且其它层可被包括，而示出的层中的任何层可被省略。此外，实现示出的层中的一个或多个(例如抽象层1315)的例如VCU的逻辑的示例也是说明性的，因为层可在逻辑、硬件、固件、代码、微代码、软件或它们的组合中被实现。

在一个实施例中，堆栈1300将模糊硬件DFx的实现细节。此处，抽象层1315(服务层)被提供以抽象此类硬件DFx细节，同时向客户端层(应用层1320和表示层1325)提供接口。如描绘的，提供给应用层1320的接口由多个API(API 1316、1317和1318)组成。

API通常是指例如应用层1320的软件层为访问和使用由此提供的服务将遵循的规则和规范的具体集合。基本上，它在不同的(软件、固件或硬件的)层之间提供接口并且促进它们的交互。API可被层1320和1325访问，这些层可包括能够与API进行接口或对其编程的控制台、工具、软件、操作系统、库、应用或能够其它已知结构。作为特定说明性示例，API包括对于服务、例程、函数、数据结构、对象类、协议或其它已知的涉及API的构造(construct)的规范。

虽然一个API可被利用，在描绘的实施例中，不同API被提供以用于对抽象层1315提供的不同服务、例程和数据结构的访问。例如，API 1316可提供核服务和数据结构以由应用层1320用于低级细节的安全性(如下面更详细地讨论的)和抽象，这可能导致减少的代的工具逆转(turnover)(在具有不同抽象层1315服务和/或不同DFx特征的下一代处理器上与相同API进行接口的相同工具的使用)。

此外，例如API 1317和1318的其它API可提供其它服务、数据结构和抽象。作为示例，硬件DFx不是由层1315提供的唯一抽象。此处，API 1317和1318提供与电验证(EV)、功率传递、管理性、安全性、访问或其它已知的涉及测试、验证、调试的支柱(pillar)相关联的服务和数据结构。以前，制造商一直保护将由客户端层中驻留的工具使用的某些算法，例如电验证(EV)算法。因此，当前提供这些算法或仅提供其子集，这经常导致对于EV的不够标准的供应商工具。

因此，在一个实施例中，API 1317包括EV支柱API以提供此类算法的完全集合的抽象以由较高级层1320、1325中的工具/软件来利用。因此，算法可以安全方式(对TPV工具不可见)被提供，从而导致更好的TPV测试工具，而任何秘密算法保持秘密、抽象。注意，EV特定API支柱的示例可被外推至将抽象硬件、固件、软件、代码、算法、协议等等的任何单独的涉及测试、验证和/或调试的API支柱。此外，提供支柱特定API服务模块，如所示的，可能准许更容易的模块的更新。例如，如果与EV相关联的某个东西将被修改，那么例如存储在实现EV API 1317的VCU微控制器中的EV代码的补丁的更新可能被执行而不必须更新核服务或其它API模块。

在上面的示例中，对抽象层1315和客户端层(应用层1320和表示层1325)之间的接口的参考主要关于API被讨论。然而，任何用于提供掩盖、抽象或模糊来自较低级的低级细节的接口的已知装置或方法可被利用。此外，如上述的，抽象层1315的示例被VCU微控制器实现。此处，实现API 1316-1318的逻辑和代码被包括在VCU中，例如存储在VCU微控制器的存储器设备中的代码。在另一个实施例中，为抽象层1315实现API的代码、服务和数据结构被保存在存储器中，并由例如测试中的处理器的测试中设备来运行。

如所示的，堆栈中的最低层包括目标DFx层1305，该层包括任何已知DFx特征，例如上述的硬件特征/钩子。此外，DFx层1305可也包括遗留测试/验证特征。结果，直接访问1350在一些实施例中准许对层1350中的硬件DFx特征的一些特征的直接访问。作为另一示例，目标DFx层1305包括测试中的单元，该单元可包括处理器、PCH、图形设备、母板或其它电子设备。

传输层1310将使通信(来自由抽象层1315提供的服务和例程的此类任务，其是传输不可知的(即不知道服务/例程如何被传输到DFx层1305))适合于运行于特定传输媒介(vehicle)上。例如，传输层1310包括传输硬件和相关联的驱动器，以取得来自抽象层1315的通信，并将其改装成用于向层1305传输的适当的分组/信息。此处，传输媒体可包括平台内的互连、通过端口将控制台/测试器耦合到平台或设备的互连、主机机器上的层1315和测试中的远程单元上的层1305之间的远程访问网络、或其它已知涉及测试的设备、例如目标内探头(ITP)设备、定义的调试端口、第三方供应商(TPV)传输设备。

如能从网络示例中推断的，堆栈1300的一个或更多的层可在不同机器和/或组件上被实现。例如，目标层1305可包括远程连接到实现堆栈的剩余部分的一个或更多层的主机平台的测试中平台。作为另一示例，客户端层在远程访问测试中的部分或平台的主机系统上实现，所述测试中的部分或平台实现服务层和目标层1305。远程访问在下面验证架构访问的实施例中被更加详细地描述。

客户端层可包括任何工具、控制台、应用或其它实体，以用于与将抽象DFx层1305的低级细节的抽象层1315和/或目标层1305中的DFx特征进行接口。当与抽象层1315的接口是通过一个或更多API(例如API 1316-1318)时，应用层1320被设计成与API进行接口与对其编程(根据它们的规范和规则，包括支柱特定API模块的规范和规则)。此外，如上所述，即使当新一代产品被提供时，只要客户端层与抽象层1315之间的API通信规范的保持相同，则客户端层工具不必被改变以用于新版本。相反，抽象层被更新，以关于新产品(目标DFx层1305)的新方式来提供相同服务。此外，第三方遗留的和非服务应用可与制造商附属品(collateral)一起被集成到客户端层内的一个或更多工具解决方案中。

表示层可与工具或分开的实体集成，其将相关、可视化和/或呈现底层数据和协议。结果，这些工具是由第三方来设计或以第三方的偏好来设计以采用他们如此选择的任何方式从DFx测试来制定最终结果。在这个示例中，应用层1320将使用其中提供的服务和例程对抽象层1315编程。来自这些服务和例程的结果(例如层1305中的测试结果或驻留于层1315中的算法的输出)被上传到应用层1325。应用层将此数据传到表示层，表示层为人或进一步工具解释来解释(调试)和呈现数据。

转到图14，通过分层架构堆栈访问DFx特征的方法的流程图实施例被示出。在流程1405中，例如第三方供应商工具的应用对抽象层编程。此处，工具或其它实体请求/使用来自抽象层的服务(如由与抽象层相关联的API定义的)。而且此类服务在流程1410中被提供。注意在服务包括抽象层内的本地算法的情况下，信息/数据结构可被提供回至应用层。

另一方面，如果该服务包括与DFx特征或测试中的目标设备的向下通信，则在流程1415中，来自较高层的传输不可知的堆栈(抽象层和应用层)的通信被改装以适于被传输。例如，所述改装可包括将来自抽象层信息格式化为传输协议，例如测试端口协议、互连协议、网络协议或互联网协议。在流程1420中，通信的改装格式被传输到执行由抽象层请求的操作的测试中的DFx单元。注意到，例如上述那些DFx操作的任何已知DFx操作可被执行。结果可接着在流程1425中被提供回至应用并在流程1430中由表示层来解释。

继续来自上面的普通示例以示出流程，假设测试和调试工具请求微断点被编程到例如处理器的测试中单元中并且捕获直到微断点、在微断点处或在微断点之后的踪迹。在此示例中，应用可调用由应用层提供的服务(流程1405)。抽象层运行所谓的服务例程，这包括在堆栈中向下传送微断点定义和踪迹捕获方向(流程1410)。传输层从传输方面来改装微断点定义和踪迹捕获，例如将它们形成将通过测试端口传输的分组(流程1415)。制定的分组被传送到处理器(流程1420)。在响应中，微断点被设置在处理器的控制寄存器中，并且按照请求捕获踪迹信息。此处，数据的返回可包括堆栈往回的上传，例如通过抽象层，回到应用(流程1425)。作为另一示例，踪迹信息可被存储到用作踪迹缓冲区的存储器中。并且应用能够从该存储器读回踪迹信息(流程1425)。使用踪迹信息，表示工具能够在仿真中再造处理器踪迹，以解释数据(流程1430)。注意到，抽象层以下特征的可访问性可被保护，即对没被解锁的或超过应用安全性/特权级的特征的来自应用的访问请求可被拒绝。此类可能安全性增强立即在下面被讨论。

用于验证架构的安全性的实施例

如上所述，测试、验证和调试架构的一个可能目标包括对设计者或制造商不希望显露的低级细节进行抽象。然而，此类细节的纯抽象或模糊在一个实施例中可能不是足够的“安全性”。如果仅仅利用了抽象层，那么包括最终用户的任何人可能够访问测试架构(如果他们确定如何与抽象层API通信)。结果，在一个实施例中，对测试架构的访问被保护，即来自未授权的较高层的请求不被准许。

图15示出了提供对测试架构的安全访问的逻辑的一个实施例。此处，可包括上面参考应用或表示层描述的实体中的任何实体的应用或控制台1515包括通行码1520。通行码1520也可被称为密钥，包括值的任何已知格式，其将为访问的特征或级提供安全的或锁定的访问。依据初始交互，或随后依据请求，应用1515在接口1530(例如由VCU 1507实现的API接口)上提供它的通行码1520至抽象层。注意，应用1515如在逻辑上与UUT 1505分开的拓扑仅仅是说明性的。然而，UUT 1505可正在运行应用。或VCU 1507可在设备1515中实现，其在此情形中被认为是访问UUT 1505的控制台/主机系统。

不管物理实现如何，当抽象层接收通行码1520时，它向应用1515提供一定量的访问，这基于应用通行码与存储元件1510中保存的通行码相比较，存储元件1510例如是UUT 1505的通用寄存器、控制寄存器或模型特定寄存器(MSR)。作为一个示例，仅有一个访问级(完全访问或无访问)。此处，如果应用通行码1520与存储元件1510中保存的通行码匹配，那么应用1520就能利用由VCU 1507实现的抽象层的提供的所有服务(对相关联的DFx特征的访问)。备选的是，如果无通行码被提供或通行码不匹配，则来自应用1515的对抽象层的请求不被服务/准许。

然而，在一个实施例中，多个安全性级可被提供。例如，设计者可希望不同的客户或供应商对算法、协议、数据结构、DFx特征等等具有不同的访问级。事实上，设计者/制造商可希望提供给自己对DFx特征的低级细节不模糊的访问(这些细节是抽象层将模糊的)，以测试、验证并调试DFx特征，以及相关联的UUT。类似地，设计者/制造商可提供给自己抽象层内的完全访问。

在描绘的实施例中，存储元件1510将保存三个级的通行码。一个通行码(通行码1511)是制造商通行码以提供0级访问(无拘束的或不是非常受限的)来访问DFx特征。第二级(1级)由通行码1512代表，其提供对测试架构的一些选择性的/受限的访问。并且第N级由通行码1513代表，其提供对测试架构的甚至更选择受限的访问。此处，通行码中的每个可被安全地提供，例如对第三方供应商(TPV)提供通行码1512。结果，在设计TPV工具时，他们能够集成或利用通行码1512作为通行码1520。因此，当应用1515经过认证过程(向由VCU 1507实现的抽象或安全性层提供通行码1520)时，它被提供对测试架构的1级访问。在此情况中，该1级访被限制。所以不在它的安全性级之内的来自应用1515的访问(对限制的DFx特征或实现细节的访问)被VCU 1507拒绝(不准许)。

转到图16，用于提供测试架构中安全访问的流程图的实施例被示出。在流程1605中，确定应用的访问级。在一个实施例中，任何已知认证过程被用于将应用与用于测试架构的访问级相关联。在另一示例中，如上述的通行码检验过程被用于确定应用的访问级。注意，此类确定可在运行应用的开始被做出(对程序的在其开始的一般认证)或可依据特定请求被做出。

在流程1610中，服务请求由应用向抽象层API提供。此处，向API的服务请求是纯说明性的，正如请求可包括对DFx特征的任何服务请求或尝试访问。不管请求的类型或格式如何，在流程1615中，基于确定的访问级来确定该请求服务是否被准许。在此情形中，某些服务、算法、协议、DFx特征等等根据定义的安全性访问级被预定义为可准许的或受限制的。因此，如果请求与应用的访问级(或具更多访问的级)相关联，则在流程1625中该请求被准许并且在流程1630中被传输到(如果是服务的部分)测试中的DFx单元。相反，如果该请求不在应用的访问级之内，则在流程1620中它不被准许。

对验证架构的物理访问的实施例

以前，对硬件测试特征的访问通过全部散布在计算机平台上的多个不相交的、未连接的端口来分布。这使得测试平台的连接既繁琐又昂贵(连接到那些端口的不同的端口和工具)。因此，在一个实施例中，提供通用测试访问端口(UTAP)来取代多平台测试接口。参照图17，示出平台中用于测试架构的UTAP的实施例。

处理器1710a-d包括由例如快速通道互连的互连1750耦合在一起的任何已知处理器，而PCH 1770通过例如直接媒体接口(DMI)的互连1765被耦合到处理器1710c。如示出的，VCU 1712a-e能够在例如测试互连或其它已知接口的互连1790上通信。但是，如上述的，在另一个实施例中，VCU能够在互连1750、1765之上通信。因此，在此情形中，VCU 1712a-e适于与彼此通信，这能够实现通过单个统一的端口(如UTAP 1785)对平台1700的VCU测试特征的访问。此处，VCU1712a-e能够协作地交互。或至少，它们能够将消息从UTAP1785路由至适当的预期VCU。

在一个实施例中，UTAP 1785包括双向端口以提取调试信息(从与处理器相关联的存储器或从VCU往回)并且与VCU1712a-e通信。作为一个示例，UTAP 1785包括专用测试接口。在另一个实施例中，UTAP 1785搭载自(piggy-back off)另一接口，例如现有接口(例如通用串行总线(USB)接口、串行高级技术附连(SATA)接口或其它已知接口)或被双重利用的未来接口。

注意，描绘的拓扑是纯说明性的。任何数量的处理器可被包括。而且不必须包括PCH。此外，UTAP 1785可包括将耦合至外部设备(例如控制台、计算机或测试器)的物理端口。作为另一示例，UTAP代表与主机或远程系统(下面将更详细描述远程访问)进行通信的控制器或网络接口设备(例如NIC)。此处，控制器可包括基板管理控制器(嵌入到母板上的嵌入式微控制器)，它可报告系统参数(例如温度、风扇速度、功率状况等等)并且可促进与平台1700的远程通信。

提供通用测试端口可能简化(既在成本方面又在复杂性方面)平台测试。然而，用于各个部分的当前测试站点(site)(例如处理器)也包括低效。例如，处理器一般在它们的“底侧”已经包括测试和验证引脚，其经常是引脚受限的，从而导致更大的封装衬底和更大的成本。为了减少此类成本，客户越来越多地省去了测试和调试钩子。结果，当客户不能够调试某个部分时，它可变成返回至制造商的错误。

因此，在一个实施例中，集成电路(IC)封装衬底(例如处理器、控制器中心等等)的顶面上的未占区域(例如在衬底的周边上的)被用来放置测试和/或验证使用引脚的一些或全部。作为示例，这些引脚被蚀刻到封装衬底的外面金属层中，并被阻焊剂显露。

转到图18，示出了示范性大量制造连接机制中的集成电路封装的实施例。在此示例中，IC包括CPU封装1860，该封装包括顶侧测试和调试引脚1865。这些引脚能够以取决于相关联的使用情况的多种方式而被连接。在验证或故障检修使用情况中，它们可使用压缩式连接器机制来访问，除其它可能性之外，其可包括将连接器直接对准封装衬底的对准特征；从而获得最好可能的容限(tolerance)，并驱使引脚特征尺寸和连接系统尽可能的小。注意，这些特征通常将兼容的往复特征包括于插座1850中，以使顶侧连接器能够与IC 1860的衬底进行接触。

示出的连接情形(例如HVM连接情形)包括蛤壳式铰链(hinge)固定1820以将IC固定探头1835(例如pogo引脚式连接)连接到顶侧引脚1865。并且IC固定探头导线(wire)1810将固定探头1835连接到控制台/测试器1805。结果，蛤壳式铰链1820准许打开连接机制，插入新部分，并且随着铰链1820的关闭，进行测试器1805和顶侧测试/调试引脚1865之间的连接。在各种大量制造测试使用情况(其中预期到这些封装顶部引脚的互连的速度维持最小可接受的“拍频差率(beat rate)”)中，连接的方法将倾向于使用如图18中示出的自动化的和/或高效率机制的类型。

与母板1840的类似连接也被示出，其中母板固定导线1823将测试器1805连接到MB固定探头1825。此外，基座(base)探头1830也被示出成接触母板1840的基座。注意，蛤壳式铰链1820的示例完全是说明性的，并且可利用用于探头、测试器、插座、HVM工具等的任何已知连接情形。此外，类似的机制也可用于其它IC，例如控制器中心或外设设备。

图18也描绘了集成散热器(IHS)1870，在一个实施例中，它被设计成准许空间以用于顶侧引脚1865和通过固定探头1835到其的连接。转到图19，示出了具有微小加载特征以支持顶侧引脚和探测的散热器的实施例。此处，封装1907上的集成电路1905与IHS 1910相关联。在一个实施例中，IHS 1910包括微小的凸起的“加载耳”1911。在图中，加载耳1911为启用的插座加载机制提供插座激励(actuation)加载点，所述加载机制例如是直接插座加载(DSL)机制1920。如上所述，利用此类设计可能导致更少地占用顶侧区域，这又准许更多的空间以用于验证的信号引脚/焊盘。

加载耳1911的外侧，IHS 1910的周边可具有沿着IHS 1910边缘的较小的连续的或不连续的台阶(step)。作为另一备选，边缘没有任何台阶。如所示的，当耳1911被加载时，封装1907被按到插座上，激励插座，并迫使插座和设备封装之间发生电连接。注意耳的数量(示出为2个，但不限于此)取决于具体应用的加载点数量。此外，耳1911位于给定应用的加载点之下(例如紧接之下)，并且不要求在IHS 1910的中间。然而，通常耳1911的位置将一般(不总是)使得IHS 1910上的加载机制所应用的力导致激励力充分到足以关闭IHS1910/封装1907中心。在一个实施例中，加载耳1910具有一定长度以覆盖加载机制的完整加载带(zone)。例如，建议的IHS耳在1mm至50mm长的范围中，以覆盖DSL负载片(plate)1920的负载长度。注意，在IHS 1910装配期间，IHS密封剂可放在耳1911的下面以向封装1907传输负载力而不弯折耳1911。

结果，具有围绕大约90％周边的加载台阶以确保能足够分布的负载的以前典型的HIS激励插座以强制电连接。但通过提供加载耳，如上面讨论的，相同的加载过程可用减少的边缘台阶来获得，使IC顶侧上的更多空间能够用于测试/调试引出线和探测。此外，为了有利于更多空间，IHS 1910可具有选择性定形的架子(shelf)，带有微小的加载耳1911，这些耳1911位于加载最多应用于IHS 1910之处。例如，DSL负载片1920连接IHS 1910的台阶的一小部分。所以策略性地将耳1911放置于DSL片1920放置负载之处。因此，有了新释放的空间，可包括新的顶侧测试引脚而不增长封装尺寸或减少IHS1910的热消散区域。

在涉及热消散的事情中，当前热极限化工具设计非常大，这导致更大的实际区间(estate)使用和减少的信号完整性极限。因此，参照图20，描绘了提供热极限化的小形状因子热工具(SFFTT)设计的分解视图的实施例。注意此类极限化在一些实施例中可被认为是DFx特征。此处，SFFTT 2000包括一个或更多特征，包括：定制低温(cold)片2010，其被焊接到袖珍块状(mini-bulk)热电冷却器(TEC)阵列2025的底部；带有微沟道冷却技术的水冷却器2040，其通过液态金属热接口材料(例如Ga-Sn液态金属材料)附连到袖珍块状TEC阵列2025的顶部；提供均匀水流分布的水冷却器2040的盖子的独特沟道设计；在设备中心用于水的入口和出口(流入2050和流出2060)的管道；到控制器的导线线束(harness)装配件；T类型热电偶，其嵌入冷却片2010的中心，以向控制器提供温度反馈；隔离片2020，在水冷却器2040与低温片2010之间，以解决TEC破裂事项；TEC2025线缆管理，其使用面包板2035以缓解导线应力；以及温度开关(switch)。

这些特征为SFFTT提供了潜在优点。例如，带有微沟道冷却技术的水冷却器2040比菱形鳍(diamond-fin)技术设计可能更高效。在SFFTT 2000的中心的入口和出口(250，260)的放置连同水冷却器盖子的独特沟道设计准许低温流从中心进入水块，而加热的水行进到冷却器的侧面；与其它菱形鳍式设计相比，这个距离仅是沟道长度的一半。结果，最冷区在中心，在那里，热浓度通常由于TEC 2025和测试中的硅所生成的热而是最高的。最终，跨水冷却器的温差可能降低多达3度C，而且温度被更均匀地分布，该冷却器导致TEC 2025的改进可靠性。作为另一示例，低温片2010到袖珍块状TEC阵列2025的附连可能减少热阻的层。此外，水冷却器2040和低温片2010之间的隔离片2020提供了缓冲机制，以防止块状TEC情况中面临的TEC2025的破裂事项。并且，使用面包板2035的线缆管理可能缓解导线应力，以及减少TEC引线(lead)故障。

为了提供进一步的讨论，本文讨论上述特征的一些说明性规范。作为第一示例，袖珍块状TEC阵列2025包括多达39mm×39mm的区域，带有75C的最大消散温度和多达15cm^2的脚印(footprint)。此外，任何数量的TEC可被连接于阵列2025中。作为一说明性实施例，11个TEC的两组串联连接，而11个TEC的两组并联连接。此外，水冷却器2040的微沟道鳍设计提供垂直(或水平)的冷却沟道，而不是菱形鳍的环形冷却型式。并且沟道/鳍可以是任何尺寸。例如，鳍可以是2mm高、3mm宽、且间隔开3mm。下面在表A中提供水冷却器2040不同设计的示范仿真。

表A：水冷却器仿真的性能概要

类似的仿真显示通过微沟道水冷却器技术的显著改进的速度分布和温度分布。作为这些改进的结果，SFFTT相比以前的热极限化设备在尺寸上可能减小多达40％-50％，同时仍提供相似的温度极限化(例如5C-100C)。此外，通过使得芯片能够被放置得与下一芯片更近，形状因子的减少也可能节省板上的真实区间并改进信号完整性(SI)极限。SI极限的改进也驱动了所有市场部门(segment)朝向产品小型化的趋势。水冷却器盖子上独特的沟道设计还可能提供均匀的水流分布，这导致改进的TEC可靠性。而且，作为制造商和供应商的后硅调试/验证活动的部分，故障检测可通过分隔故障和减少遗漏来加速。并且，使得温度极限化能力能够用于供应商可向制造商提供性能上的竞争优势。还值得注意的是，供应商的验证发现也可帮助制造商在电验证中变得更高效，这可能能够实现更多最终用户友好产品的交付。

对验证架构的远程访问的实施例

以前，制造商花费大量的资源(时间、人员和资金)来帮助供应商进行他们的调试工作。事实上，当供应商不能执行他们自己的测试和调试或遭遇与此的问题时，制造商/设计人员常常将派遣验证工程师到供应商站点。不幸的是，随着部分和平台的复杂性增长，该过程对于供应商变得愈加困难，而对于制造商则变得愈加麻烦。因此，在一个实施例中，验证架构能够实现帮助测试、验证和/或调试过程的远程访问。

转到图21，示出远程访问测试中单元的实施例。如上所述，测试架构堆栈的层可跨机器(和网络)来实现。此处，远程主机2105包括/实现工具2106(具有测试、验证和/或调试工具的应用层)和抽象层2107，如上所述。来自层2106、2107的通信正在接口2130上提供，接口2130可包括任何已知接口，例如远程接口、网络接口、外设接口等。在一个实施例中，此类通信根据任何已知加密算法2150来加密。此外，在另一实施例中，VPN加密2110被用于传输中。在此情形中，本地主机2115(即以任何方式耦合到远程主机2105的主机)将实现传输层2116，以用于使传输不可知层2106、2107适合于向测试中单元(UUT)2120传输。因此，从与测试中单元进行接口的远程主机，可实现上述测试、调试、验证和安全性操作中的任何操作。

随即参考图22，示出远程访问测试中单元的另一个实施例。此处，远程主机2205包括三个层(2206、2207和2208)并且具有通过加密信道与测试中单元(UUT)2220的直接通信。正如布局差异所示出的，任何耦合或布局可被实现以远程地与测试中单元进行接口。同样任何认证过程可用于设立信道。而且安全性协议(类似上文所述的那些安全性协议)能用于检验访问的不同级。结果，供应商或制造商可能够远程测试、验证或调试设备，而不必物理与单元进行接口。从上述内容，能够看出通过准许验证工程师从他们的原位置远程地验证产品而不是必须在供应商站点物理出现，可能显著减少与测试/调试相关联的时间和费用。

追踪捕获信息管理的实施例

如上所述，例如在“测试、验证和调试钩子的实施例”部分中，处理器、控制器中心或其它设备上的ODLA在一些实施例中能够捕获管芯上和/或接口信息，例如踪迹信息。并且它可在任何数量的方式中被传递，例如利用存储器作为踪迹缓冲区。或如下面更详细描述的，逻辑可通过接口(例如边带通信总线)来提供此类数据。接着，所述信息可被提供到用于管理(格式化，操纵，解释，调试等)的工具。

上面还提到，使用外部分析器来捕获和分析部分是复杂的并且耗费成本的。例如，对于复杂接口(例如PCIe接口)的协议分析器可花费50,000美元以上。并且随着遗留信号变得越来越集成(例如经由高速串行接口的带内消息传递的部分)，信息在母板上不是轻易可得到的。结果，图23示出通过边带总线(例如JTAG或SM总线)向主机系统提供踪迹信息的逻辑的实施例。要捕获的遗留带内信号的示例包括：TRDY 2321、INTR 2322、SMI 2323和STPCLK 2324。此处，PCH 2320中的ODLA 2330捕获上述信号的踪迹；注意这可响应于任何事件，例如在主机系统2360或嵌入式控制器2340(例如实现抽象层的VCU)的指引下切换引脚、设置断点事件。控制器2340收集对于这些信号的数据，并且将它通过边带总线2350提供到主机系统2360。作为示例，该数据的格式包括：对应信号是阻塞高、阻塞低、切换、切换的方向还是切换的速率的指示。此处，通过处理数据的嵌入式控制器2340和ODLA 2340选择要观察的不同内部信号的能力，调适能力能够被更新而无硬件中的任何改变。

转到图24，描绘了管理内部观察踪迹(IOT)数据的方法的流程图的实施例。在流程2405中，在系统上运行测试。例如，上述测试在测试中单元上运行。并且IOT数据从逻辑上来获得，例如ODLA(也被称为管芯上逻辑分析器OCLA)。注意，IOT数据可包括多个流/源(例如，存储器、I/O、核上接口等)。

在流程2410中，IOT数据被转储。例如，与测试中单元相关联的存储器被用作IOT数据的踪迹缓冲区。但是，可利用任何已知接口向例如控制台或主机系统的系统转储/提供数据，所述系统将处置/解释IOT数据。

在流程2415中，从IOT数据重构踪迹数据以使得能够重放。重构踪迹和/或格式化踪迹数据的任何已知方法可被利用。为了提供说明性示例，对图25进行快速参考。此处，将IOT数据的格式进行解码。在一种情形中，IOT数据包括具有特定预定义格式的多个流/源。因此，在流程2505中，按照例如格式将IOT数据解码。作为一示例，为IOT数据标识源。并且在流程2510中，将IOT数据按照源进行分开、分组和/或桶装(bucket)。

对于每个源的模块(服务)(例如，对于存储器源IOT数据的存储器模块；对于处理器踪迹源IOT数据的内部处理器模块；对于快速通道接口IOT数据的快速通道模块；对于核上互连的环业务的核上模块等)在流程2515、2520中为每个对应源重构事务。此外，这些模块在一个实施例中在流程2525中特别为重放而重新格式化重构的踪迹数据。返回到图24，重放格式化的重构的踪迹数据的重放。结果，重放能提供对测试中单元的操作中的洞察以用于验证和调试。

因此，增加产品开发周期的调试时间和成本可能被减少。并且重放准许软件机制能够实现包括相同或相似DFx方法(例如本文所述的测试架构)的产品的模仿环境中隐错(bug)的再现。模仿环境中再现此类隐错提供对测试中系统内所有系统行为的完全可见性，从而能够实现快速调试。这可能有助于解决逻辑和电路极限性(marginality)隐错。此外，类似的装置和方法可用于开发用于大量制造的测试内容；这可能为大量制造提供快速且高效的测试内容，这通过改进产品稳定性中的置信度和协助部分装箱(part binning)而节省成本。

转到图26，示出执行后处理分歧检测的方法的流程图的实施例。如上所述，当在测试中系统上运行测试(流程2605)时，数据能够被收集并且被用于在模仿/仿真环境中重放确切相同的测试条件(流程2610-2625，其在与上述图24-25相似的方法中操作)。从该过程，验证能够检测到硬件上和软件模型上执行的测试之间的差异；这些差异被称为作为分歧。后处理分歧检测利用DFx硬件特征，例如通过OCLA的IOT捕获，以保存系统状态。当测试被重放时，模仿中IOT中存储的数据(重放IOT数据2635)可在重放运行后被处理，并且与收集自测试中系统的IOT中存储的数据(收集的IOT数据2615)相比较，以获得后处理分歧检测结果2640(即数据2615和重放数据2635之间的差异)。重放期间的运行时间是代价高的，因为它要求昂贵的专门用途硬件。因此在此类重放期间计算分歧可能浪费代价高的运行时间。因此，在一个实施例中，到内部位置(例如系统存储器)的保存的系统状态准许在重放阶完成以后分开地在不太昂贵的硬件上处理数据的能力。

接着参见图27，示出用于使得RTL数据结构能够可被高级语言访问的流程图的实施例。当从测试中系统收集踪迹数据时，收集的某些数据字段通常被分析，这可包括来自踪迹的修改。不幸的是，RTL正在不断改变，这导致围绕RTL设计的软件必须被持续更新。因此，在一个实施例中，当发布软件(流程2705)时，在软件发布的时间对RTL模块进行扫描(例如，在流程2710中，取得RTL数据的快照)。从所述快照，RTL数据类型在更一般的格式中被记录，例如在XML中。此处，在流程2715中，RTL数据结构快照数据库从RTL快照数据来创建。

一旦存储了RTL数据(即创建数据库)，就提供基于快照RTL数据类型定义来读、掩蔽和修改踪迹分组的软件机制/服务。通过简单地基于踪迹源自哪个RTL模型而选择要加载哪个快照，其它软件可能被隔绝于不连贯的RTL改变。作为一示例，当软件要使用RTL模型来解释或修改来自测试的踪迹数据(流程2720)时，它查询RTL数据结构的数据库(流程2725)并使用该信息对踪迹数据进行解码(流程2730)。结果，不是依赖于恒定的RTL模型和改变的软件，而是提供了对RTL数据结构的灵活且可适应的基础设施(封装的模型与信号格式)。

功率验证的实施例

随着逻辑增加以及电路变得更小，涉及电路的事项正尖锐地增长。并且电路隐错正从检测遗漏。此外，目前还没有好的表征方法使得电路故障对于非高速通道事项更加可重现。结果，在一个实施例中，电路极限性验证(CMV)方法用于为非高速通道、以及可能为速度通道寻找问题。电路极限性的主要事项包括：管芯上信号完整性(交叉耦合引入的噪声，下降(droop)事件引入的噪声)；功率传递完整性(常常由于时钟门控而引起的高动态电流事件)；时钟域交叉；以及过程、电压和温度改变(功率状态转变，硅过程变更)。

基于过去几代指示上的平台验证管理产品分析显示电力(pwr)网是对电路极限性的主要贡献因素(contributor)。因此，在一个实施例中，提供了一种基础设施，其用于能够实现相对于管芯上事件的电力网的调试以及空间和时间表征，包括将测试和系统事件与电力网性能相关的能力。

转到图28，提供一个此类基础设施的实施例。此处，提供一种综合的集成(管芯上)架构，其能够实现管芯上电压调节事件的观察以及基于时间的和空间控制，带有将此类事件确定性地与测试内容以及系统事件相关的能力。如所示的，架构2810将通过抽象层2805(如上所述)与主机2800接口，抽象层2805可由VCU 2815来实现。

架构2800的组件包括：高带宽管芯上电压下降监视能力(VDM2830)和下降注入机制(ODI 2835)(这两者在一个实施例中都适合于在时间上和空间上来配置)；时钟周期特定测试内容同步基础设施、确定性事件触发和时钟周期精确时间监视基础设施(DSC 2840)，其在一个实施例中准许事件加时间戳和重放；动态管芯上电压调节状态捕获能力，例如用于VR状态捕获的ODLA，具有事件相关；可配置的基于硬件有效负载修改机制(微断点逻辑2830)，其在任何给定一个或多个功率域中在用户/主机2800的判断下可依据系统事件、测试事件和/或功率状态转变而被发起。

关于架构能力的示例的非穷举清单包括：将ODL/VDM/系统(I/O或核)事件与管芯上电压调节内部观察相关的能力，例如经由A/D样本的模拟观察点的快照和状态机口(vent)的动态快照；确定性地发起基于硬件的有效负载修改的能力；将ODI和/或VDM触发事件同步到内部VR事件的能力；在内部VR事件上打断的能力；捕获内部VR事件的时间戳的能力；监视功率管理命令事项与实际VR改变之间延迟的能力；观察VDM/ODI改变的能力；将进入的当前行为相关到内部事件的能力，观察器具(gear)定量(ration)改变和功率分布效果的能力以及提供占空比检测间隔演算的能力。

架构的模型和应用的一些非穷举示例包括：电力网表征；基于系统事件的相关；以及基于功率事件的相关；下面对其所有进行说明性描述。对于电力网，给定用户完全灵活性，可在任何数量的方式中进行表征。基本上，此操作模式中的电压监视电路被预先配置成随时间过去而捕获电压。电压通过对短时间持续时间期间环振荡器的振荡进行计数来测量。在测试或其它系统活动的过程上，通过比较贯穿表征周期的过程的样本来捕获给定功率域局部内的最高峰和最低谷。此处，表征可在系统静默时、在引导周期中、在测试期间或在任何数量的系统事件期间来进行。而且，表征也可在任何/所有域上同时进行。

对于基于系统事件的相关，利用一种微断点基础设施，其配置成：将测试序列(或关注的系统事件)的开始与电力网采样的发起进行同步，到故障点或在例如循环冗余校验(CRC)故障(作为说明示例)的具体系统事件的发生时捕获流逝的时间。测试序列然后可被确定性地重放，以在可配置方式中评估管芯上电压调节性能(带有在给定触发事件之前、期间或之后查看任何给定时钟周期的能力)。状态数据和模拟点的数据收集可在局部或时间中的给定实例基于关注的触发事件来动态捕获。因此，存在架构中固有的多样灵活性，使得触发事件和动作可由功率调节块、功率mgmt或测试/系统特定事件来提供。

对于基于功率事件的相关，操作类似于系统事件相关。微断点“相似的”基础设施被集成到电压调节电路中，从而准许通过经由VDM2830的电力网的采样和/或经由ODI 2835的下降事件的注入来发起多个系统事件。此模式中的触发事件在一个实施例中最通常依据特定功率事件或状态而被发起。

如本文使用的模块是指任何硬件、软件、固件或其组合。通常，被示为分开的模块边界常常变更并且可能重叠。例如，第一和第二模块可共享硬件、软件、固件或其组合，同时可能保有一些独立的硬件、软件或固件。在一个实施例中，术语“逻辑”的使用包括硬件，例如晶体管、寄存器等，它们被组合和/或配置以执行任务。在另一实施例中，逻辑是指其它设备，例如可编程逻辑设备或可编程逻辑阵列。在又一个实施例中，逻辑也包括与硬件集成的代码或软件，例如固件或微代码。

本文使用的值包括数、状态、逻辑状态或二进制逻辑状态的任何已知代表。通常，逻辑电平、逻辑值或逻辑的值的使用也为称为简单地代表二进制逻辑状态的1和0。例如，1是指高逻辑电平，而0是指低逻辑电平。在一个实施例中，例如晶体管或闪存元(cell)的存储装置元可能够保存单个逻辑值或多个逻辑值。然而，计算机系统中值的其它代表已经被使用。例如十进制数10也可被代表为二进制值1010和十六进制字母A。因此，值包括能够被保存在计算机系统中的信息的任何代表。

此外，状态可被值或值的部分来代表。作为示例，第一值，例如逻辑1，可代表默认或初始状态，而第二值，例如逻辑0，可代表非默认状态。此外，术语“重置”和“设置”在一个实施例中分别是指默认的和更新的值或状态。例如，默认值可能包括高逻辑值，即重置，而更新的值可能包括低逻辑值，即设置。注意，可利用值的任何组合来代表任何数量的状态。

上面阐述的方法，硬件、软件、固件或代码的实施例可经由在机器可访问或机器可读媒体上存储的可被处理元件运行的代码或指令来实现。机器可访问/可读媒体包括以机器(例如计算机或电子系统)可读的形式提供(即存储和/或传送)信息的任何机制。例如，有形的机器可访问媒体包括随机存取存储器(RAM)，例如静态RAM(SRAM)或动态RAM(DRAM)；ROM；磁或光存储媒体；闪速存储器设备；电存储设备；光存储设备；声存储设备；用于保存无形的传播信号(例如载波、红外信号、数字信号)的其它形式的有形存储设备；等等。

此外，上面阐述的方法，硬件、软件、固件或代码的实施例可由存储在机器可读媒体上的编译器的运行来实现，或作为运行由编译器编译的存储在机器可读媒体上的代码的部分来实现。编译器通常包括程序或程序的集合，以将源文本/代码转换成目标文本/代码。通常，用编译器的程序/应用代码的编译在多个阶段和多遍(pass)中进行以将高级编程语言代码变换成低级机器或汇编语言代码。然而，单遍编译器可仍用于简单编译。编译器可利用任何已知编译技术并执行任何已知编译器操作，例如词法分析、预处理、解析、语义分析、代码生成、代码变换和代码优化。在一个实施例中，编译器将编译和/或优化代码以插入操作、调用、函数、指令等等以执行本文描述的方法。

较大的编译器通常包括多个阶段，但最通常的是，这些阶段被包括在两个一般阶段之内：(1)前端，即一般发生句法处理，语义处理和一些变换/优化之处，和(2)后端，即一般发生分析、变换、优化和代码生成之处。一些编译器涉及中间端，这示出编译器的前端和后端之间画界的不明确。结果，对插入、关联、生成或编译器的其它操作的引用可发生在任何以前提及的阶段或遍中、以及编译器的任何其它已知阶段或遍中。在一个实施例中，此类插入发生在静态和/或整个程序编译期间。在另一实施例中，在动态编译期间，编译器代码或动态优化代码可插入此类操作/调用，以及为运行时间期间的运行优化代码。在一种情形中，例如编译器程序的软件或硬件也可执行程序运行的动态剖析(profiling)。

本说明书各处对“一个实施例”或“实施例”的引用是指连同该实施例描述的具体特征、结构或特性被包括在一个实施例中。因此，在本说明书各处不同地方中短语“在一个实施例中”或“在实施例中”的出现不一定都指相同的实施例。此外，具体的特征、结构或特性可以任何适当的方式在一个或更多实施例中被组合。

在上述说明书中，参考特定示范性实施例给出了详细的描述。然而，在不偏离所附权利要求中阐述的本发明的更广精神和范畴的情况下，显然可对其进行各种修改和改变。本说明书和图形相应地要在说明性意义而非限制性意义中来看待。此外，实施例和其它示范性语言的上述使用不一定指相同的实施例或相同的示例，而是可指不同且有区别的实施例，以及可能指相同的实施例。

Claims (22)

1.一种装置，包括：

一个或更多硬件测试钩子，适合于提供测试信息；和

抽象逻辑，适合于从软件层抽象所述一个或更多硬件测试钩子，并且向软件层提供接口，所述接口适合于提供与所述一个或更多硬件测试钩子相关联的服务。

2.一种装置，包括：

集成电路，包括适合于捕获与集成电路相关联的踪迹信息的管芯上逻辑分析器(ODLA)；

存储器，耦合到所述集成电路，所述存储器适合于被用作踪迹缓冲区，以保存所述ODLA所捕获的与所述集成电路相关联的所述踪迹信息。

3.一种装置，包括：

集成电路，包括适合于捕获用于所述集成电路的接口的踪迹信息的管芯上逻辑分析器(ODLA)；以及

存储器，耦合到所述集成电路，所述存储器适合于被用作踪迹缓冲区，以保存所述ODLA所捕获的用于所述集成电路的所述接口的所述踪迹信息。

4.一种装置，包括：处理器，所述处理器包括，

验证控制器，耦合到所述处理器中的一个或更多控制寄存器，所述验证控制器适合于配置所述一个或更多控制寄存器以定义断点；

管芯上逻辑分析器(ODLA)，适合于当所述一个或更多控制寄存器被配置成定义所述断点时，响应于所述处理器遇到所述断点而捕获与所述处理器相关联的踪迹信息。

5.一种装置，包括：集成电路，所述集成电路包括，

测试端口，适合于准许对与所述集成电路相关联的测试信息的访问；

早期通电信号逻辑，适合于在所述集成电路的通电序列期间，捕获要在启用所述测试端口之前转变的信号的信号状态信息。

6.一种装置，包括：集成电路，所述集成电路包括，

通电信号，适合于转变以指示所述集成电路的通电；

计数逻辑，适合于响应于所述通电信号转变而开始计数；

边缘检测逻辑，检测关注信号的边缘转变；

存储元件，适合于当边缘检测逻辑检测到所述关注信号的边缘转变时，保存所述关注信号的信号标识和基于所述计数逻辑的计数的时间戳值。

7.一种装置，包括：集成电路，适合于驻留于活动功率状态和多个低功率状态中，所述集成电路包括，

低功率信号逻辑，适合于响应与所述多个低功率状态中的低功率状态相关联的功率周期事件而捕获信号的信号状态信息。

8.一种装置，包括：集成电路，所述集成电路包括，

多个硬件用于测试的设计(DFx)特征；以及

微控制器，适合于提供对所述多个硬件DFX特征的访问，其中所述微控制器包括代码，所述代码在被运行时，导致所述微控制器向软件提供一个或更多应用编程接口(API)，以用于与所述多个DFX特征相关联的服务。

9.一种包括代码的有形机器可读媒体，所述代码在被运行时，导致机器执行以下操作：

根据应用编程接口(API)规范来解释来自请求软件的对于与所述机器中的硬件测试钩子相关联的服务的请求；

响应于解释所述请求而服务于所述请求，其中服务于所述请求包括发起与所述硬件测试钩子相关联的测试；以及

向所述请求软件提供来自所述测试的测试结果。

10.一种包括代码的有形机器可读媒体，所述代码在被运行时，导致机器执行以下操作：

确定对所述机器的硬件测试钩子的改变；

更新微控制器中存储的代码，以计及对所述机器的硬件的改变，其中更新所述代码仍维护用于访问与所述机器的硬件测试钩子相关联的服务的对软件层的相同接口。

11.一种系统，包括：

目标物理层，适合于实现集成电路内的硬件测试特征；

传输层，适合于传输从抽象层到所述目标物理层的传输不可知通信；

所述抽象层，适合于对所述目标物理层进行抽象，并向应用层提供一个或更多应用编程接口(API)；

所述应用层，适合于根据所述一个或更多API的规范来请求来自所述抽象层的与所述目标物理层相关联的服务。

12.一种包括代码的有形机器可读媒体，所述代码在被运行时，导致机器执行以下操作：

对用于与集成电路的硬件测试特征相关联的一个或更多服务的应用编程接口(API)进行编程；

从所述一个或更多服务接收数据；以及

响应于接收所述数据而解释所述数据。

13.一种装置，包括；

控制器，适合于接收来自应用的请求，所述请求与访问集成电路内的硬件测试特征相关联；

安全性逻辑，适合于确定多个访问级的所述应用的访问级，以响应于所述应用的访问级具有对所述硬件测试特征的访问而准许来自所述应用的所述请求，并且响应于所述应用的访问级不具有对所述硬件测试特征的访问而不准许来自所述应用的所述请求。

14.一种方法，包括：

确定应用的访问级；

提供从所述应用到抽象接口的服务请求，所述抽象接口控制对集成电路的硬件测试特征的访问；

基于所述服务请求的类型和所述应用的访问级，确定从所述应用到所述抽象接口的所述服务请求是否是可准许的；以及

基于所述服务请求的类型和所述应用的访问级，响应于确定从所述应用到所述抽象接口的所述服务请求不是可准许的而不准许所述服务请求。

15.一种系统，包括：

多个集成电路，其中所述多个集成电路的每个集成电路包括适合于控制对所述多个集成电路的每个集成电路的硬件测试特征的访问的验证控制器；以及

通用测试访问端口，适合于提供对所述多个集成电路的每个集成电路中的每个验证控制器的访问。

16.一种装置，包括：

集成电路(IC)封装，包括所述IC封装的底侧上的信号引脚和所述IC封装的顶侧上的测试引脚，所述测试引脚适合于被电耦合到测试探头。

17.一种系统，包括：

集成电路(IC)封装，包括所述IC封装的底侧上的信号引脚和所述IC封装的顶侧上的测试引脚；以及

大量制造(HVM)连接机制，包括固定探头，所述固定探头电耦合到测试器和所述IC封装的顶侧上的所述测试引脚。

18.一种装置，包括：

集成电路封装；以及

集成散热器(IHS)，热耦合到所述集成电路封装，所述IHS包括微小的凸起的加载耳。

19.一种装置，包括：小形状因子热工具，包括，

低温片，适合于热耦合到集成电路；

热电冷却器阵列；

水冷却器，具有微沟道冷却鳍；以及

入口和出口，在所述水冷却器的中心。

20.一种装置，包括：小形状因子热工具，包括，

低温片，适合于热耦合到集成电路；

热电冷却器阵列；

水冷却器，具有微沟道冷却鳍；以及

入口和出口，在所述水冷却器的中心。

21.一种包括代码的有形机器可读媒体，所述代码在被运行时，导致机器执行以下操作：

在计算机系统上运行测试；

将踪迹信息转储到所述计算机系统中的存储器设备；

从所述存储器设备中的所述踪迹信息来重构踪迹数据；

在仿真环境中，运行所述踪迹数据的重放。

22.一种包括代码的有形机器可读媒体，所述代码在被运行时，导致机器执行以下操作：

响应于软件发布：取得电阻器晶体管逻辑(RTL)结构的快照，并且基于所述RTL结构的所述快照来建立RTL结构快照数据库；以及

Images