CN103577294B - 用于互连跟踪的方法和装置 - Google Patents

Abstract

本发明涉及用于互连跟踪的方法和装置。提供了一种跟踪监视器，被配置为：跟踪芯片上系统的主设备和从设备之间的多个信号的交换，其中，所述多个信号具有多个请求和多个响应；以及追踪在激活跟踪之前和之后作出的所述多个请求和所述多个响应，以确定在跟踪被激活之后跟踪所述多个响应中的哪些响应以及在跟踪被去激活之后跟踪其余多个响应。

Description

用于互连跟踪的方法和装置

技术领域

本公开的方面总体涉及互连跟踪。特别地，本公开的方面涉及改进高性能芯片上系统互连跟踪。

背景技术

跟踪监视器帮助嵌入式软件开发者对已针对芯片上系统（SoC）写入的软件进行调试。SoC是将典型计算机组件（诸如，中央处理单元（CPU）、图形处理单元（GPU）和存储控制器）结合在单个硅管芯中的集成电路。这些组件通过芯片上的互连来与彼此通信。对于嵌入式软件开发者，在软件引起的通信通过互连进行传播时观察这些软件引起的通信可能是有帮助的。这可以提供信息，诸如在CPU与存储器之间传送的数据字，这可以用于调试。

针对后续观察而捕获信号值的过程被称为跟踪，并且所捕获的数据被称为跟踪数据。执行观察的实体通常被描述为跟踪监视器。根据互连的类型，跟踪监视器可以接通（hook up）至总线或者至纵横（crossbar）开关的一个或多个端口。

跟踪监视器决不应当变为互连的活动构件。其始终应当保持对其他组件来说不可见，以符合非侵入式跟踪的范式。在大量场景中，总线上的不同方的相互作用可以是漏洞的原因。举一个简单的例子，两个组件可以参与到竞态条件中，这是由于这两者想要同时与相同存储位置进行交互。例如由于利用相同总线传输其跟踪数据的跟踪监视器而更改这些竞态条件可能使漏洞消失。

一般地，SoC协议因卖方及其预期的使用情况和性能而可与彼此区别。大多数完善且普遍的互连协议中的一些是：ARM AMBA（高级微控制器总线架构）协议族；IBM核心连接协议族；以及开放核心协议（OCP）。

许多解决方案采用IDLE循环过滤作为跟踪大小减小技术（trace-size reduction technique）。如果跟踪解决方案供应了高级跟踪大小减小技术（诸如信号压缩和抽象），则其仅对AHB协议来说可用。不幸的是，AHB仅被视为中性能协议，其使这些解决方案对于在使用更快协议的高性能SoC中的使用来说不合格。另一方面，如果解决方案支持高性能协议，则其仅供应了IDLE循环过滤，而未进一步供应高级跟踪大小减小技术。

因此，拥有解决以上讨论的问题中的一个或多个的方法、系统和计算机程序产品将是有利的。

发明内容

提供了一种在芯片上系统中进行跟踪的方法。所述方法包括：跟踪所述芯片上系统的主设备和从设备之间的多个信号的交换，其中，所述多个信号具有多个请求和多个响应；以及追踪在激活跟踪之前和之后作出的所述多个请求和所述多个响应，以确定在跟踪被激活之后跟踪所述多个响应中的哪些响应以及在跟踪被去激活之后跟踪其余多个响应。

提供了一种装置。所述装置包括跟踪监视器，所述跟踪监视器被配置为：跟踪芯片上系统的主设备和从设备之间的多个信号的交换，其中，所述多个信号具有多个请求和多个响应；以及追踪在激活跟踪之前和之后作出的所述多个请求和所述多个响应，以确定在跟踪被激活之后跟踪所述多个响应中的哪些响应以及在跟踪被去激活之后跟踪其余多个响应。

提供了在一个或多个非瞬变计算机可读介质中编码的逻辑，其包括用于执行的代码，并在被处理器执行时可操作用于执行包括以下内容的操作：跟踪芯片上系统的主设备和从设备之间的多个信号的交换，其中，所述多个信号具有多个请求和多个响应；以及追踪在激活跟踪之前和之后作出的所述多个请求和所述多个响应，以确定在跟踪被激活之后跟踪所述多个响应中的哪些响应以及在跟踪被去激活之后跟踪其余多个响应。

附图说明

在附图中，遍及不同视图，相似参考标记一般指代相同部分。附图不必被按比例绘制。在以下描述中，参照以下附图来描述本公开的方面，在附图中：

图1是根据本公开的方面的芯片上系统的示意；

图2是根据本公开的方面的不正确指派的示意；

图3是根据本公开的方面的上下文感知和用户可调整的事务过滤的示意；

图4是根据本公开的方面的跟踪监视器的硬件架构的框图；

图5是根据本公开的方面的跟踪动作信号的示意；

图6是根据本公开的方面的REQ捕获信号的示意；

图7是根据本公开的方面的跟踪动作信号的示意；

图8是根据本公开的方面的识别芯片上系统中的网络拥塞的流程图；

图9是根据本公开的方面的利用计数器来识别芯片上系统中的网络拥塞的流程图；

图10是根据本公开的方面的利用计数器来识别芯片上系统中的网络拥塞的流程图；

图11是根据本公开的方面的利用FIFO来识别芯片上系统中的网络拥塞的流程图；以及

图12是根据本公开的方面的利用FIFO来识别芯片上系统中的网络拥塞的流程图。

具体实施方式

以下详细描述参照了附图，附图通过示意示出了本公开的具体细节和方面。本文中，词语“示例性”用于表示“用作示例、实例或示意”。本公开或者本文中被描述为“示例性”的设计的任何方面不必被理解为与本公开或设计的其他方面相比优选或有利。

一些附图可以使用类似的参考标号。这仅仅指示不同附图中的相同标号可以是类似类型的项目。然而，不同附图中的相同标号中每一个可以是其自身的重述或本公开的方面。

图1是根据本公开的方面的芯片上系统的示意。芯片上系统（SoC）100可以是将典型计算机组件（诸如，中央处理单元（CPU）102和104、图形处理单元（GPU）106和存储控制器108）结合在单个硅管芯中的集成电路。这些组件通过芯片上的互连来与彼此通信。

SoC 100还可以包括跟踪监视器110。跟踪监视器110可以采集、管理和分析跟踪数据。本公开的各个方面认识到并考虑到许多解决方案采用IDLE循环过滤作为跟踪大小减小技术。如果跟踪解决方案供应了高级跟踪大小减小技术（诸如信号压缩和抽象），则其仅对AHB协议来说可用。不幸的是，AHB如今仅被视为中性能协议，其使这些解决方案对于在使用更快协议的高性能SoC中的使用来说不合格。另一方面，如果解决方案支持高性能协议，则其仅供应IDLE循环过滤，而未进一步供应高级跟踪大小减小技术。

本公开的各个方面认识到针对除IDLE循环过滤外还供应高级跟踪大小减小技术的高性能协议的跟踪监视器的需求。本公开的各个方面提供了针对这种跟踪监视器的设计。已经针对与AXI协议类似的OCP实现开发了该监视器。本文公开的跟踪监视器可以被视为高性能。取代采用信号压缩或抽象技术，该监视器通过引入即时、用户可调整的事务过滤来实现高级跟踪大小减小。可以在跟踪期间过滤掉整个事务（请求+响应）。可以通过一系列过滤器来对应该被排除的事务进行分类。这类过滤器可以描述所允许的存储地址范围或者所允许的事务突发长度。在事务不符合这些规则的情况下，将其过滤掉。可以在每个跟踪回合之前配置这些过滤器。

如果未被芯片上逻辑规避，则必须在每个跟踪回合之前手动进行该操作。为了进行该操作，可以例如通过设置CPU的断点来停止所有主设备。在短时间之后，所有未完成响应将已结束。仅在第一响应将属于第一请求的情况下才可以开始跟踪。然而，该方法使跟踪变得复杂。此外，其破除了非侵入式跟踪的范式（这是由于其更改了所观察的环境）。跟踪监视器110可以自动地丢弃属于在开始跟踪前已发出的请求的响应。

附加地，SoC 100可以包括用于存储要在实现与如本文概述的应用管理相关联的操作时使用的信息的一个或多个存储元件（例如，存储元件112）。这些设备可以进一步将信息保存在任何合适的存储元件（例如，随机存取存储器（RAM）、只读存储器（ROM）、现场可编程门阵列（FPGA）、可擦除可编程只读存储器（EPROM）、电可擦除可编程ROM（EEPROM）等）、软件、硬件中或者在适当时且基于特定需要而保存在任何其他合适组件、设备、元件或对象中。本文讨论的存储或储存项目中的任一个应当被理解为被包含在如本文所使用的较宽术语“存储元件”内。

此外，本文中，用于在SoC 100中跟踪的操作可以由在一个或多个有形介质中编码的逻辑实现，该一个或多个有形介质可以包括非瞬变介质（例如，在专用集成电路（ASIC）中提供的嵌入式逻辑、数字信号处理器（DSP）指令、潜在地包括处理器或其他类似机器要执行的目标代码和源代码的软件等）。在这些实例中的一些中，一个或多个存储元件（例如，存储元件50）可以存储针对本文描述的操作使用的数据。这包括能够存储被执行以实现本文描述的活动的软件、逻辑、代码或处理器指令的存储元件。

处理单元102和104可以是处理器、多核处理器、单核处理、微控制器、控制器电路或者任何其他类型的处理设备。处理单元可以执行与用于实现本文详述的操作的数据相关联的任何类型的指令。在本公开的一个方面中，处理器可以将元件或物件（例如，数据）从一个状态或事物变换至另一状态或事物。在另一示例中，可以利用固定逻辑或可编程逻辑（例如，由处理器执行的软件/计算机指令）来实现本文概述的活动，并且本文标识的元件可以是某种类型的可编程处理器、可编程数字逻辑（例如，FPGA、EPROM、EEPROM）或包括以下各项的ASIC：数字逻辑、软件、代码、电子指令、闪存、光盘、CD-ROM、DVD ROM、磁或光卡、适于存储电子指令的其他类型的机器可读介质、或者其任何合适组合。

SoC 100可以包括总线系统114，总线系统114可以由一个或多个总线（诸如，系统总线或输入/输出总线）组成。当然，总线系统114可以使用提供被附着至总线系统114的不同组件或设备之间的数据传送的任何合适类型的架构加以实现。

图1中的SoC 100的示意并不意在暗指对于可实现本公开的方面的方式的物理或架构限制。可以使用除所示意的组件外和/或替代所示意的组件的其他组件。在本公开的方面中，一些组件可能是不必要的。

将协议划分为三个阶段，其为用于管线/信号解耦合的OCP术语。对于每个阶段，主设备和从设备执行单独的握手。

每个事务变为解耦合（请求+写入或读取数据）并与线程ID（ThreadID）解耦合。可以按顺序完成具有相同线程ID的连续事务，但是可以不按顺序完成具有不同线程ID的事务。该特征用于提高总线的吞吐量。在特定情形下，如果从设备对所接收到的请求的序列重新排序，则从设备能够更快速地响应。

在OCP协议中，存在两种类型的ID：事务ID和线程ID。每种ID可以用于驱动跟踪监视器的线程ID输入，或者如果OCP使用这两种类型的ID，则每种ID甚至可以用于驱动这两者的连结。并且像AXI之类的协议可以对每发起者的事务ID外加每发起者的独特ID起作用。被附着至具有被复用在一起的多个这种发起者的互连的跟踪监视器可以在其线程ID输入上使用发起者ID和事务ID的连结，以便能够应付所有独立请求/响应流。线程ID可以被用作请求和响应的独立地重新排序的序列的标识符，而不论最后如何从可在互连协议中可用的不同ID构造该线程ID。

图2是根据本公开的方面的不正确指派的示意。

跟踪监视器可以结合芯片上逻辑，这解决了在协议利用具有对多个未完成事务的支持的管线时出现的问题。这是由所有高性能协议结合的性能提高的特征。其允许请求202从对应响应204的传输解耦合。因此，主设备可以甚至在对先前请求的响应已到达之前提出新请求。因此，如果从设备的响应被延迟，则主设备不必保持空闲，这加强了互连利用率。然而，该特征可能导致所谓的上下文丢失。这在任意时间点处激活跟踪时发生。

在该图中，出于示意的目的，Clk 208是时钟，并且clk周期nr 210是时钟周期号。在时钟周期1中开始，发出三个连续读取请求206。解耦合的响应开始针对相应请求相继地在时钟周期3中到达。如果在互连已经处于操作中的任意时间点处激活监视器，则上下文丢失发生。可以在时钟周期1之后激活跟踪监视器。因此，其将在时钟周期2中记录读取请求，并在时钟周期3中看到响应。但是，这两者不属于彼此。事实上，该响应属于在已激活跟踪监视器之前已发出的请求。但是监视器正丢失该上下文。因此，其不能丢弃来自时钟周期3的响应。因此，查看跟踪数据输出可能导致下述错觉：已经从在时钟周期2中请求的位置读取来自时钟周期3的读取数据。这导致SoC的内部状态的错误描绘。

如果未准许协议的相应管线级处于恰当的上下文中，则监视器所递送的所有信息可能不都是有价值的。

从设备利用重新排序，这是由于其可以使用高速缓存来对想要立即从相同地址读取的所有请求快速地作出响应。

然而，决定论的这种丢失使得难以过滤掉完整的事务，这是由于当将发出对请求的响应时，其是不可预测的。

协议自身基于突发，这意味着：像长度1的突发那样处理单写入和单读取事务。因此，有效的是，针对单读取/写入请求的响应被称为第一或最后一拍（beat），这是由于其在相同时刻处相同。在该工作的其余部分期间，可以根据哪个在相应上下文中听起来更符合逻辑来使用这两个名称。然而，重要的是知道：在技术上，它们始终被作为最后一拍来处理。

图3是根据本公开的方面的上下文感知和用户可调整的事务过滤的示意。

本公开的一个或多个方面覆盖涉及使跟踪监视器成为上下文感知的且能够进行事务过滤的方法。为了保持简明，所有接下来的示例将仅表征请求和响应阶段。然而，所有构思也直接适用于数据握手阶段。

请求阶段：

在请求阶段中，发起事务。主设备被允许将多个线程ID用于其事务，只要这些线程ID不与其他主设备的线程ID重叠即可。在总线上保持所发出的请求，直到从设备就绪并对请求进行肯定应答为止。该握手终结请求阶段。信号是：

MCmd 302：对八个状态进行编码，但是仅IDLE、WRITE和READ被支持。其余编码将被忽略并被内部对待，如同其为IDLE一样。如果MCmd从IDLE切换至READ或WRITE，则在其名称中具有开头“M”的所有其他信号也必须有效。

MAddr 304对用于相应操作的目标地址进行编码。

MBurstPrecise和MBurstSingleReq这两者被永久地约束于逻辑“1”。这确保了每个突发事务是单请求突发。

MBurstSeq像MCmd那样具有八个编码，但仅两个被支持：INCR用于增加突发类型，并且WRAP用于包裹突发类型。后者可以仅被与2的幂次个突发长度一起使用。如果开始地址未对准，则其包裹在MBurstLength 306 × MAddr'length/8的地址边界周围。

MByteEn对READ请求的部分字传送进行编码。其不具有WRITE请求的意义。该信号必须具有长度[(data_word_length/8)-1:0]。因此，对于每个字节，MByteEn保持一个比特。每个比特对是否应当传送字的字节进行编码。

MReqInfo保持与每个请求一起发送的用户定义的额外信息。MThreadID 308由主设备针对每个请求来定义，如以上已描述的那样。最后，SCmdAccept 310对主设备的所发出的请求进行肯定应答。

因此，MCmd和SCmdAccept形成请求阶段的握手。可以如何执行握手的可能性如下：

1. 在主设备发出请求之前断言SCmdAccept。因此，在相同时钟周期中接受请求。

2. MCmd从IDLE改变至WRITE或READ，而不断言SCmdAccept。a）如果从设备具有低等待时间组合类型，则其可以仍在相同时钟周期中断言SCmdAccept。

b）一般地，将比顺序类型从设备迟一个或多个时钟周期断言SCmdAccept。

数据握手阶段

层级中的三个阶段中的第二个是数据握手阶段。无论何时已经在请求阶段中提交了WRITE请求，都在该阶段中递送实际写入数据。

主设备被允许在相同时钟周期中将突发的第一拍与请求一起呈现，但这不是必要的。根据其实现，从设备可以在一个时钟周期中一起接受写入请求和写入数据，但也可以在连续周期中进行该操作。信号可以如下：

MDataValid和SDataAccept形成握手。像在请求阶段中那样，可以在MDataValid变为高之前使SDataAccept被断言。如果传输针对突发写入的读取数据，则SDataAccept必须分别对每个单个拍进行肯定应答。

MData、MDataByteen和MDataInfo在请求阶段中精确地像其对应的信号那样起作用，并针对每拍有效。

MDataThreadID必须与正被应答的请求的实际线程ID相对应。

MDataLast指示突发事务的最后一拍，并因此终结每个写入数据传送。

响应阶段

层级中的第三阶段是响应阶段。信号可以如下：

MRespAccept和SResp在下述两个给定场景中执行握手：

对写入事务进行肯定应答：这通过将SResp 312驱动至DVA（数据接受）或ERR来进行。这可以在相同时钟周期或者在数据握手阶段中已经断言和肯定应答最后一拍后的时钟周期中发生。

递送读取请求的拍：对于所递送的每个拍，将SResp驱动至DVA（数据有效）或ERR。在最后一拍上，将SRespLast 318驱动至逻辑“1”。

在所有情况下，主设备向从设备通知其已经通过将MRespAccept 320驱动为高来处理了响应。

SData 314、SDataInfo和SDataThreadId 316像在两个其他阶段中那样针对每拍有效。

可以通过仅在执行握手时触发跟踪逻辑来丢弃IDLE周期。这是无论何时表1中的声明评估为真时的情况。

阶段	信号
		请求
数据握手
		响应

表1：握手条件。

通过采用这些触发条件，每个阶段的跟踪逻辑自动地仅聚焦于在其中实际传送数据的周期。

上下文感知计数器：

为了防止上下文丢失，可能必须丢弃属于在已激活跟踪之前已发出的请求的所有响应。该过程是事务过滤的原始形式。

本公开的方面提供了用于通过独立地聚焦于不同线程来消除响应阶段的随机性能的系统，这是由于在单个线程内，对请求的响应的序列始终按顺序。

因此，涉及使监视器成为上下文感知的第一种方法基于针对每个线程ID实现一个丢弃计数器和一个跟踪计数器，诸如丢弃cnt[5] 322、跟踪cnt[5] 324、丢弃cnt[9] 326和跟踪cnt [9] 328。根据表2中的指令来递增和递减计数器。

表2：计数器管理。

对于每个线程ID，跟踪逻辑获得与来自相应计数器对的下述两个事物有关的知识：

第一，当对跟踪进行激活时，丢弃计数器的值指示其响应尚未被发出的多少个请求已经被计数。因此，监视器知道需要丢弃多少个即将被发出的响应以恢复上下文。

第二，当对跟踪进行去激活时，跟踪计数器指示仍必须跟踪多少个即将到来的响应。这是由于跟踪计数器对在跟踪在线时已发出、尚未被响应的多少请求进行计数。

供这些计数器工作的重要要求是这些计数器未被开启或关闭。这些计数器在SoC从重置中出来时活动，并且这些计数器仅在SoC被关断时停止。监视器仅可以在其已经观察到总线上的事务的完整历史的情况下才保持为上下文感知的。这是隐式的要求。

在本公开的另一方面中，在已经对跟踪进行激活之后，监视器必须将其保持活动至少直到所有丢弃计数器已变为0为止。如果事先对跟踪进行了去激活，则计数器陷入混乱，并且跟踪数据也陷入混乱。可以利用极小的努力来实现该简单迟滞。

针对用户可调整的事务过滤的匹配FIFO：

针对每个线程ID的计数器对使监视器成为上下文感知的。然而，如果应当采用用户可调整的过滤以在跟踪期间过滤掉整个事务，则新问题出现。图3示出了在跟踪变为在线之后发出具有线程ID 9的三个读取请求的示例。假设下述过滤器：其被配置为使得其应当排除包括地址0x4的所有事务。这种事务由具有线程ID 9的三个请求中的第二个启动。这对观察和跟踪请求阶段的逻辑来说不是问题。过滤器可以告知跟踪逻辑一旦其在MAddr信号上看到地址0x4就丢弃当前周期。

但是，丢弃对应的响应要困难得多，这是由于如示例中所示，其在更晚的时钟周期中到达。计数器在这里不会有帮助，这是由于这些计数器将仅能够告知必须丢弃多少个即将到来的响应。

它们不能指示这三个中的哪一个。在这种情况下需要的是：与是已经跟踪还是丢弃了相应请求的信息一起分别记住每个请求的实例。再一次，必须针对每个线程ID采用这种实例，以规避不按顺序的响应的缺乏决定论。

解决该问题的方法是针对每个线程ID实现FIFO结构。无论何时发出请求，都将向针对相应线程ID的FIFO推送新条目，该新条目包含是已经跟踪还是丢弃了请求的信息。这意味着：FIFO的读取信号指示是否应当跟踪即将到来的响应。当然，这仅对每个FIFO所属于的相应线程ID来说有效。然后，跟踪逻辑可以在其观察到响应时相应地进行动作，并在最后一拍（SRespLast==1）上弹出FIFO。因此，将读取信号切换至FIFO存储器中的下一条目，该条目保持用于下一即将到来的响应的指令。

已针对该任务采用的FIFO还拥有所谓的旁路特征。如果新值被推送至空FIFO，则其不仅被存储在存储器中，而且仍在相同时钟周期中通过FIFO进行传播。如果还存在在相同时刻处发出的读取（弹出），则该值甚至不会被存储在存储器中。这在SoC具有超快的组合从设备的情况下是重要特征。这些从设备能够在发出请求的相同时钟周期中对请求作出响应。当然，这仅在不存在未决的未完成响应的情况下是可能的，这意味着：对应的FIFO在该时刻处具有为0的填充计数。给定该场景，那么跟踪逻辑将看到请求，跟踪或丢弃该请求，并将新条目推送至FIFO。同时，从设备已经对该请求作出了应答。仍在相同时钟周期中，跟踪逻辑观察到响应并检查是否已经跟踪了对应请求的FIFO的输出。由于旁路特征，该值已经通过FIFO进行传播并确实属于正确的请求。因此，跟踪逻辑能够针对响应执行正确动作。在没有旁路特征的情况下，该值不会已经在相同时钟周期中可见，而是在更晚的一个时钟周期中可见，从而使响应阶段的跟踪逻辑错误地进行动作。

附加地，每个FIFO的填充计数指示多少个未完成响应针对相应线程ID未决。

合并这两个解决方案：

结果是，当设计还采用匹配FIFO时，不需要上下文感知的计数器，这是由于可以合并这两种方法。FIFO从计数器借用下述内容：不仅当跟踪是活动的时，计数器在重置之后也直接是活动的。因此，每当跟踪逻辑在跟踪离线时观察到请求时，就利用丢弃指令来推送相应FIFO。因此，可以在任意时刻处切换跟踪。然后，跟踪逻辑已经通过查看FIFO元件来知道要丢弃多少个响应直到请求和响应再次处于上下文中为止。

过滤器设置：

为了利用匹配FIFO，已经实现对可调整的过滤器的以下选择：

地址范围：仅在事务的地址处于给定范围内或外的情况下才跟踪事务。

突发长度：仅在事务的突发长度处于给定范围内或外的情况下才跟踪事务。

线程ID范围：仅在事务的线程ID处于给定范围内或外的情况下才跟踪事务。

数据范围：仅在响应的数据字处于给定范围内或外的情况下才跟踪响应。

请求类型：可以排除写入或读取事务。

突发类型：可以排除所有突发事务，或者仅排除类型INCR或WRAP的突发。

可以在开始跟踪之前配置所有这些过滤器。

图3中的状态管理系统的示意并不意在暗指对于可实现本公开的方面的方式的物理或架构限制。可以使用除所示意的组件外和/或替代所示意的组件的其他组件。在本公开的方面中，一些组件可能不必要。此外，呈现了框以示意一些功能组件。在本公开的方面中被实现时，这些框中的一个或多个可以被组合和/或划分为不同框。

图4是根据本公开的方面的跟踪监视器的硬件架构的框图。

跟踪监视器400必须被放入相同时钟域中作为其所观察到的OCP信号。RX 406和TX 408表示监视器的输入/输出端口。可以直接钉住（pin out）它们或者将它们与例如将跟踪数据存储至芯片上RAM的中间芯片上子系统互连。

直接将受到跟踪的OCP互连信号402路由至OCP嗅探器块404中。所有信号是只读输入。跟踪监视器决不可以更改信号中的任一个。其对互连来说完全不可见。这确保了完全非侵入式的观察。

经由芯片上网络接口来进行输入和输出操作。监视器接收和发送分组。将分组细分为微片（flit），该微片是传送的原子单元。存在下述三种类型的微片：

· 头微片；

· 有效载荷微片；

· 尾微片。

在示例中，分别传输头、体和尾微片。发送器通过断言请求信号来发信号通知有效微片。接收器利用就绪信号来对其传输进行肯定应答。如果接收器忙碌，则对就绪取消断言。在这种情况下，发送器必须保持当前微片直到再次断言就绪为止。

对监视器的RX和TX子系统进行完全解耦合。接收侧由被称为配置/控制单元410的子系统处理，该子系统具有对RX端口的独家访问。另一方面，发射部分不由单个单元处理。监视器内部的每个分组化块带来其自身的TX端口接口。通过经受仲裁和复用这两个阶段来决定谁被允许使用后者。

输出仲裁器/复用器412是最高阶仲裁和复用块。其直接连接至监视器的TX端口。该块必须在寄存器接口分组化器414与OCP嗅探器404之间进行决定。赢得仲裁的那一个使其信号被直接复用至监视器的TX端口。

但是甚至在这发生之前，OCP嗅探器内部的仲裁和复用级就必须决定谁与寄存器接口块竞争。将立即说明什么在OCP嗅探器内部发生以及谁在此处竞争仲裁。

配置/控制单元410：

配置/控制单元是任何监视活动的开始点。其托管对监视特性进行控制的所有配置寄存器。

存在针对将OCP信号与用户定义的范围进行比较的每个过滤器的寄存器对。其缺省值被设置为覆盖相应信号的整个可能范围。配置寄存器保持过滤器的配置并对跟踪是开启还是关闭进行控制。

依照缺省，配置寄存器被配置为使得跟踪离线，并且不进行数据过滤以及不进行统计跟踪。将立即说明这所意味着什么。附加地，对所有类型的请求进行跟踪，并且所有范围过滤器在其值处于相应寄存器中存储的范围外时丢弃请求。

监视器还表征通过送出缓冲器422而被链接至外部寄存器420的外部寄存器接口416。这些外部寄存器是可选的。根据其所控制的内容，其可以使调试过程方便得多。一个示例将是对接至对CPU的调试特征进行控制的寄存器。因此，将可以通过相同接口来设置跟踪监视器以及CPU的调试断点。

如前所述，配置/控制单元对接至监视器I/O接口的RX端口，并使用RX逻辑424来监听输入分组。存在被接受和处理的两种类型的分组：

· 针对特定寄存器的更新（新值/数据字）。

· 针对特定寄存器的读取请求。

通过唯一地址、同样地通过内部和外部地址区分寄存器。

写入寄存器：

可以通过将包含寄存器地址和值的写入类型的分组发送至监视器来更新寄存器。但是，将新值写入到内部寄存器418不像其可能起初看上去那样微不足道。data_max和data_min寄存器例如保持用于在数据握手和响应阶段中对数据字进行过滤的值。在活动跟踪期间改变这些值将因下述两个原因而影响跟踪输出的一致性：

1. 数据握手和/或响应阶段可以处于跟踪突发的中间。新寄存器值可能使否则将已被跟踪的拍被过滤掉。

2. 同样适用于未完成事务，其中，请求已经被跟踪，但是相应的数据握手或响应阶段数据仍然未决。

因此，当接收到具有寄存器更新的分组时，状态机首先检验监视器当前是否是活动的。如果是，则通过将状态[0]比特设置为“0”来发起对所有当前跟踪活动的关断。这使OCP嗅探器内部的请求跟踪块立即停止跟踪任何请求。同时，对RX端口的就绪信号取消断言，从而暂停输入分组。监视器保持处于该状态，直到数据握手和响应阶段的所有未完成事务被完成为止。未完成事务计数器指示何时出现这种情况。

其是针对每个写入请求增加2且针对已被跟踪的每个读取请求增加1的简单计数器。如果在数据握手（写入数据）和/或响应（写入肯定应答或读取数据）阶段中发现属于相应请求的未完成事务，则相应地减小计数器。一旦其变为0，监视器就重新断言就绪信号，处理输入分组的其余部分并更新相应寄存器。

对于每个成功的寄存器更新，监视器将在送出缓冲器内部存储包含已被更新的寄存器的地址的肯定应答分组。

读取寄存器：

读取寄存器未面临像写入所面临的那样的困难。包含寄存器地址的读取类型分组被发送至监视器。寄存器值被读出并存储在送出缓冲器中。

发送分组：

寄存器接口分组化器将注意送出缓冲器何时已被填充。缓冲器内部的ID字段将向分组化器告知其是对读取请求的响应还是对写入请求的肯定应答。然后，其从输出仲裁器/复用器请求仲裁。当被准许时，即时组装分组并经由TX端口来发送出分组。

模块化OCP嗅探：

在已经通过内部寄存器来配置和激活监视器之后，OCP嗅探器块将继续跟踪。

已经基于协议的三个阶段将跟踪逻辑442划分为三个逻辑子系统。因此，存在请求430、数据握手432和响应跟踪块434。但可能仅存在请求跟踪块。SoC的设计者可以省掉其他两个块。这样做的一个原因是：当该资源非常有限时，节约区域/门（gate）。经由编译时间处的专用泛型，省略数据握手和/或响应块的实例化是可能的。每个块430、432、434可以分别包括缓冲器452、454、456，并还分别利用分组化块462、464、466来执行分组化。

如果这两者均被省掉，则也将自动地省略未完成事务计数器470和仲裁器/复用器实例。在没有数据握手跟踪和响应跟踪实例的情况下，请求跟踪实例不具有针对仲裁而与之竞争的任何对象。同时，将不存在任何未完成事务，从而使未完成事务计数器无用。

请求跟踪：

请求跟踪块是所有跟踪活动的根源，这是由于其观察发起每个事务的OCP阶段。该块能够产生包含跟踪数据的五个不同分组。这些分组是：

· 数据分组：

- 单WR；

- 单RD；

- 突发WR；

- 突发RD；

· 统计分组，递送与丢失的事务有关的信息。

在四个不同数据分组之间进行区分的原因是：根据事务的类型，请求阶段信号中的一些是可忽略的。起初排除这些信号有助于在跟踪数据被传输至外部世界时节约宝贵的带宽。

无论何时由于满的跟踪缓冲器而可能未跟踪事务，都生成统计分组。存在四个丢失计数器，针对四个基本事务中的每一个有一个丢失计数器。

监视器将利用过滤器440来过滤掉所有IDLE周期。这意味着：监视器将仅跟踪在其中两个握手信号均为“正”的时钟周期。因此，它们不会贡献任何信息。为此原因，SCmdAccept未被包括在这些跟踪分组中的任一个中。然而，MCmd具有双重目的。其充当握手信号和请求类型（WR或RD）指示符这两者。与MBurstLength信号一起，MCmd可以用于确定将在跟踪数据分组的头（头微片）中传输的分组ID（单 WR、单RD等等）。因此，在跟踪分组的头中部分地对MCmd所保持的信息进行编码，但是不以原始形式跟踪该信息且在分组的有效载荷中传输该信息。

对于单WR/RD请求，MBurstSeq是不相关的。同样地，当分组头已经告知其是单类型事务时，不需要MBurstLength。其将是通过发送出将始终为1的七个比特数字对该信息进行编码的带宽的浪费。

MByteEn信号仅对RD类型请求感兴趣。WR类型请求在数据握手阶段中递送这种类型的信息。

跟踪缓冲器设计：

简单FIFO充当存储分组内容的缓冲器。深度可以通过专用泛型（generic）来加以调整。利用分组ID、有效载荷和时间戳来划分该FIFO中的元件。

元件的宽度由其有效载荷聚集大多数数据的分组确定，在这种情况下，该分组是突发RD分组。由于信号宽度中的一些仅通过泛型（MReqInfo和MThreadID）在编译时间处加以确定，因此FIFO元件宽度也变化。

仅有的强制字段是分组ID，这是由于其为分组化器所需以便知道在跟踪缓冲器的有效载荷部分中存储了什么。示出了时间戳450字段，这是由于其是被结合在所有五个分组中的仅有字段。跟踪数据的其余部分被填塞至有效载荷部分中。分组化器将始终以检查分组ID字段开始。随后，其将继续从右至左。

图5是根据本公开的方面的跟踪动作信号的示意。

跟踪链中的第一元件是连续地生成被称为trace_action 502的信号的子系统。该信号可以对五个不同状态进行编码：

· IDLE

· WR_SINGLE

· WR_BURST

· RD_SINGLE。

利用虚线来描绘过滤器信号504，这是由于其实际上不是跟踪逻辑块内部的专用信号。其已经为了理解的目的而被放入到该图中。实际上，在生成trace_action信号的逻辑块内部隐式地生成和评估过滤信号。在该示例中，过滤器被配置为排除关于地址0x7的事务。trace_active信号506指示跟踪何时是活动的。

跟踪逻辑：

随后到来的是实际跟踪逻辑。其连接至跟踪缓冲器的写入端口，并仅观察trace_action信号。无论何时该信号改变至非IDLE（空闲）值，跟踪逻辑都尝试将信号转储与正确的分组ID（由trace_action信号指示）和时间戳一起写入到跟踪缓冲器的空元件中。如果跟踪缓冲器为满，则相应丢失计数器被增加。

在这些丢失计数器之一具有大于0的值的情况下，跟踪逻辑等待trace_action信号的下一IDLE（空闲）周期。然后，其在IDLE周期期间进一步评估是否至少两个元件在跟踪缓冲器内部空闲。如果是，其将统计分组的内容（也被称作丢失计数器和时间戳）推送到FIFO中。否则，其回退直到两个元件空闲为止，即使这意味着必须在过程中对进一步损失进行计数亦如此。等待两个空闲元件的原因说明如下：

如果统计数据将被写入到具有仅一个空闲元件的跟踪缓冲器中，则该数据将再次阻塞跟踪缓冲器，这可能进而触发附加的丢失。因此，将被存储到跟踪缓冲器中的下一数据将再次是统计数据。为了永远防止这种情况继续，逻辑等待两个空闲元件。这确保了每个统计/损失数据转储后紧接着至少一个跟踪数据转储。

图6是根据本公开的方面的REQ捕获的信号的示意。

在将跟踪数据推送到跟踪缓冲器中时，跟踪逻辑生成被称为REQ_captured（REQ捕获）602的信号。其像trace_action信号那样对相同的四个状态进行编码，但其值具有不同语义。在新信号的上下文中，WR_SINGLE不再意味着“存在立即发生的单个写入请求”。取而代之，其指示“将立即捕获总线上的该单个写入请求”。相应地，语义中的这种改变适用于其他信号状态。因此，仅当跟踪缓冲器具有空时隙以存储当前请求时，REQ_captured信号才将具有非IDLE值。如果如buffer_full信号604所指示，跟踪缓冲器为满，并且请求不能被跟踪，则REQ_captured将保持IDLE。

REQ_captured信号从SoC引导至关断的历史精确地告知请求阶段中的哪些请求已经被跟踪并将示出何时检查跟踪数据输出。这完全是匹配FIFO所需的内容。根据与请求一起发出的线程ID，属于该线程ID的匹配FIFO将记录REQ_captured信号的值。

因此，当在数据握手606或响应阶段608中发出数据传送时，跟踪逻辑必须进行的全部操作是查看相应匹配FIFO的当前输出。其将告知是否必须跟踪该数据传送。

分组化器：

然而，在那种情况发生之前，请求阶段的分组化器将继续进行动作。其被完全从其他子系统解耦合并仅被连接至跟踪缓冲器的读取端口。当跟踪缓冲器填充计数大于0时，触发分组化器。然后，其将检查分组ID字段以确定必须对什么进行分组化。同时，从OCP嗅探器内部的仲裁器/复用器块请求仲裁。一旦被连通至监视器的TX端口，分组化器将发送出在其原子微片中分割开的分组。仲裁可以持续到发送出整个分组所耗费的那样长的时间。

统计跟踪：

监视器还具有被称为统计跟踪的特殊跟踪模式。通过配置寄存器的config[10]比特来激活监视器。

统计跟踪将不记录来自互连的任何实际信号。取而代之，将利用丢失计数器来对在跟踪活动的时间期间发出经过过滤器的多少单写入、单读取、突发写入和突发读取请求进行计数。

然后，将在下述两种时机处发送包含这四个计数器的统计分组：当计数器之一变得接近于溢出时和/或当跟踪被停止时。

在统计跟踪模式中，REQ_captured信号将始终被指派为IDLE。因此，数据握手和响应跟踪逻辑将不跟踪任何数据。

采用统计跟踪模式，可以得到对互连利用率的估计。

数据握手跟踪

在数据握手阶段中，将属于先前请求的写入数据从主设备传送至从设备。由于缺少针对该整个过程的单独术语，在本公开的其余部分期间，其应当被称为写入响应。

在数据握手阶段与请求阶段之间存在影响了该信号划分的两个较大区别。

第一，数据传送可能需要多于一个时钟周期结束。这是当在互连上传送突发写入请求的写入数据时的情况。由于用于该工作的OCP实现不支持写入数据/响应数据交织，因此突发的所有拍将按顺序出现。在这种情况下，不必传输每个连续拍的线程ID；这是由于它们将肯定属于与已被跟踪的第一拍相同的线程ID。这是存在针对第一拍的单独分组和针对每个连续拍的分组的原因。后者将在没有线程ID的情况下来到。附加地，每个连续拍将在其前任之后出现仅几个时钟周期，因此，也省掉了时间戳。

还存在新第三方信号：拍号码。该信号由计数器生成，并始终保持具有当前拍的号码的值。该号码被包括在第一拍分组以及每个连续拍分组这两者中。该信息对将跟踪数据保持一致来说非常重要。需要这一点的两个场景按如下方式读取：

1. 当突发数据的传输开始时，令跟踪缓冲器为满。监视器将不能够跟踪前几拍，但是跟踪缓冲器中的一些时隙在传送的中间某时变为空闲。因此，将被跟踪的第一拍不是整个传送的第一拍。

2. 假定跟踪缓冲器在突发传输开始时具有一个或多个空闲时隙，但最终在突发期间达到其极限。一些拍将必须被丢弃，但是仍然在相同传送期间，再次释放跟踪缓冲器，使得将再次跟踪相同传送的附加后续拍。

在这两种情况下，监视器均将丢失传送的一些拍。在没有被指派给这些拍中的每一个的拍号码的情况下，将不可能重构出哪个拍属于哪个存储地址。这是已经实现该计数器的原因。

第二，不能以与已经针对请求阶段所进行的操作相同的容易方式来逼近损失计数。在已经针对请求阶段所进行的操作中，知道请求已经丢失是足够的，但是除请求的类型已经是什么外，具有与其有关的进一步信息没有任何重要性。附加地，在进一步的过程中，匹配FIFO将确保对应的数据握手和/或响应阶段数据也将被过滤掉。然而，相反，丢失先前跟踪的请求的写入响应提出了新问题：

当在跟踪之后检验跟踪数据输出时，必须能够精确地指出丢失的写入响应属于哪个请求。否则，请求和写入响应的正确序列将不可再现。

然而，写入响应可以在数据握手阶段中不按顺序到达。因此，产生仅声明已经丢失多少写入响应的统计分组将毫无意义。必须知道针对每线程ID已经丢失多少写入响应。对于该命题，已经选择了解决该问题的以下方法：

监视器表征丢失计数器的阵列，针对每个线程ID有一个丢失计数器。无论何时写入响应的数据被转储到跟踪缓冲器中，跟踪逻辑都将包括属于已利用写入响应断言的相同线程ID的计数器的丢失计数器值。随后，将相应计数器重置至0。因此，“prev.Losses（丢失）”和MDataThreadID值的组合告知在已经捕获了当前分组之前已经丢失了特定线程ID的多少写入响应。

丢失计数器将仅在整个写入响应已丢失的情况下增加。如果至少一个拍已被转储，则计数器将保持不变。因此，连续拍分组将不表征prev.Losses值，这是由于它们将仅在继续进行的拍已被捕获（以包含prev.Losses值的第一拍分组的形式）时被生成。

可替换地，无论何时数据握手阶段处于空闲周期中，都可以生成包含所有线程ID的所有丢失计数器的专用统计分组。但是，根据线程ID的数目，该分组可以变得非常大，因此，该方法尚未被实行。

仅当用户显式地想要执行具有数据过滤的跟踪时，才生成数据过滤后的分组。为了进行该操作，可以在激活跟踪之前将config[9]比特设置为“1”。在该选项被激活的情况下，跟踪逻辑将针对过滤规则（data_max和data_min寄存器内部的范围值和通过config[4]比特设置的范围策略）来校验每个拍的MData值。当执行数据过滤后的跟踪时，仅将生成数据过滤后的类型的分组。背后的思想是：仅当与错误数据字有关的显式信息可用时，才激活数据过滤。因此，以下可能性较高：在整个跟踪期间将需要捕获仅非常少的拍。为了最大化这些拍将被捕获的可能性，引入第二类的计数器：

丢弃计数器。与丢失计数器相似，针对每个线程ID存在一个丢弃计数器。无论何时观察到其MData值处于过滤器的范围外的拍，都将增加相应的丢弃计数器。计数器值还将与每个被跟踪的分组一起被存储。这些计数器对在最小化必须被转储的拍的量的同时使跟踪数据保持一致来说是必要的。

出于已知的原因，忽略了作为握手信号的MDataVaild和SDataAccept。MDataLast也未被转储，这是由于其所编码的信息不只是利用拍Nr.信号加以覆盖。

出于明显的原因，与“第一拍”类型相比，单个类型的分组不包括拍号码。

跟踪缓冲器设计：

数据握手跟踪逻辑的跟踪缓冲器已经被分割为两个分离部分。可以在表3中看出该划分。

像在请求阶段中那样，可以使用泛型来控制FIFO深度。但是，生成规则在这两者之间不同：

分组ID

MData

MDataByteEn

MDataInfo

拍Nr.

（a）第一FIFO

丢弃的cnt.

prev.Losses

MDataThreadID

时间戳

（b）第二FIFO

表3：跟踪缓冲器划分。

该划分背后的思想是：在大多数情况下，突发事务将产生比第一拍分组更连续的拍分组（仅有的例外是长度为2的突发事务）。因此，已经组装了第一FIFO，使得其可以存储连续拍分组所需的所有值。由于这些分组将以超多的数目到来，因此第一FIFO将始终具有比第二FIFO更多的元件。后者仅在需要存储非连续拍分组的附加数据时被使用。因此，通过防止冗余触发器（FlipFlop）的实例化来最小化门计数，同时，跟踪收益保持相同。

图7是根据本公开的方面的跟踪动作信号的示意。

数据握手阶段中的跟踪以trace_action信号502开始，恰与在请求阶段中相同。根据跟踪模式（标准或数据过滤），信号可以呈现出以下编码：

表4：数据握手阶段trace_action编码。

生成该信号的逻辑即时评估以下输入：

1. 属于当前被断言的MThreadID值的匹配FIFO 704的输出。

2. MDataValid 702和SDataAccept 310信号（握手）。

3. 数据范围校验的结果（仅在数据过滤被激活的情况下）。

仅在匹配FIFO在其输出信号上具有非空闲值并且MDataValid和SDataAccept信号这两者均被设置逻辑“1”的情况下，trace_action信号才呈现出非空闲值。MData 712包括该数据。MDataLast 714可以是最后的握手。此外，trace_action(df)信号716指示具有数据过滤选项的跟踪。

如果用户已经激活了数据过滤，则也校验数据范围比较器的结果。

分组化器（packetizer）：

分组化器精确地像其请求阶段对等物那样工作。仅有的区别是：其必须连接至两个FIFO而不是一个。每当利用至少一个元件来填充第一FIFO时，都触发分组化器。如果第一FIFO具有类型连续的拍，则分组化器必须仅访问第一FIFO。否则，其必须通过合并这两个FIFO的输出来组装分组。

响应跟踪：

响应阶段跟踪逻辑生成最后一串跟踪数据分组。

WR ack分组对写入事务（单个或突发）是已经被成功地结束还是错误地结束进行肯定应答。因此，所需的仅有信号是SResp和SThreadID。也包括prev.Loss计数器值，这是由于写入肯定应答响应等于特定线程ID内的任何其他响应，并因此可以是报告先前丢失的响应的第一分组。

正如针对数据握手阶段所进行的操作那样，将跟踪缓冲器分割为两个部分。Trace_action信号生成拍号码706计数、first_beat_captured 710信号和分组化单元也以相同方式加以实现。

OCP嗅探器仲裁器/复用器：

该块对OCP嗅探器内部的跟踪子系统的仲裁和复用进行管理。将根据哪个跟踪子系统将被实例化6来对不同仲裁和复用块进行实例化。存在针对每个组合可用的一个：

· 请求+数据握手阶段；

· 请求+响应阶段；

· 请求+数据握手+响应阶段。

策略已经被选择为仅基于优先级，从而表征以下顺序：

1. 请求阶段；

2. 响应阶段；

3. 数据握手阶段。

请求是跟踪链中最重要的部分。如果请求不能被跟踪，则也将在过程中忽略对应的写入响应和响应。因此，重要的是，捕捉得尽可能多。因此，请求阶段跟踪缓冲器得到最高优先级。因此，无论何时OCP嗅探器被准许对TX端口的访问，都将首先释放请求阶段跟踪缓冲器，这进而创建了更多空间以跟踪更多请求。

按顺序接下来的是响应跟踪，这是由于不像数据握手跟踪那样，该阶段生成针对写入和读取请求的分组（分别是写入肯定应答和读取数据响应）。数据握手跟踪将生成仅针对写入请求的跟踪数据。因此，在写入和读取请求被均匀分布的场景中，响应阶段跟踪子系统将生成比数据握手跟踪子系统更多的分组。

输出仲裁器/复用器：

像其OCP嗅探器对等物那样，该仲裁和复用块是基于优先级的。其必须在OCP嗅探器与寄存器接口分组化器之间进行决定。后者将是优选的，这是由于其将仅在罕见的时机（用户可以请求这些时机）处生成小分组（32比特寄存器，寄存器写入肯定应答）。

附加地，在跟踪期间，OCP嗅探器将在几乎没有中断的情况下要求仲裁。因此，不时地在小寄存器接口分组中混合而不是一直被OCP嗅探器阻塞不会有害处。

以上章节推断出：每个线程ID需要单独的匹配FIFO。以上描绘的FIFO被设计为保存和提供具有线程ID 1的写入响应的信息。为了进行该操作，出于上述原因，将REQ_captured信号连接至写入输入（wdata）。

无论何时在请求阶段中发出具有线程ID 1的请求，都可以存储该输入信号，这与具有被断言的线程ID 1的非IDLE周期相对应。这是被连接至winc信号的逻辑块所评估的内容。比较器校验MCmd是否等于WRITE（写入），而第二比较器确保针对属于FIFO的相同线程ID（在这种情况下为线程ID 1）发出操作。最后，与门确保仅当这两个比较器均评估为真且从设备接受请求（SCmdAccept = “1”）时才触发winc信号。

触发winc存储了在wdata输入上断言的当前值，并增加FIFO内部的写入指针。随后，FIFO具有填充计数1（假定其之前为空），这意味着：在不远的未来将看到数据握手阶段中的线程ID 1的写入响应。

一旦对应的写入响应到达，复用器就会将rdata输出连接至matching_fifos信号。这通过直接将复用器的选择输入连接至MDataThreadID信号来进行。因此，matching_fifos信号将始终被连接至针对当前线程ID指定的匹配FIFO。

当写入响应结束（最后一拍的传输发生）时，需要从FIFO弹出条目。这由被连接至rinc信号的逻辑进行。3输入与门校验事务的最后一拍是否被传送（MDataValid = SDataAccept = MDataLast = “1”）。比较器确认针对正确线程ID执行事务，而第二与门合并其输出。然后，rinc信号增加FIFO内部的读取指针，这释放了当前元件。

仅被稍微改编的相同构思用于响应阶段匹配：

FIFO。必须作出以下改变：

· 针对(MCmd = READ)的winc逻辑校验

· 针对 的rinc逻辑校验。

为了防止匹配FIFO可能最终溢出，设计者必须确保FIFO深度等于未完成事务的最大数目。由于该数目可以针对相同协议的不同实现而变化，因此可以调整专用泛型以在编译之前设置FIFO深度。

附加地，像匹配FIFO那样，在数据握手和响应阶段中必须针对每线程对丢失和丢弃计数器进行实例化。这里，也可以使用由OCP线程ID信号切换的复用/解复用实例来管理计数器。

跟踪逻辑可以与当前线程ID无关地指示将通过断言incr_cnt信号来丢失或丢弃总线上的当前事务。然后，由MDataThreadID或SThreadID切换的复用/解复用单元将相应地切换。

可以存在下述场景：其中，不必针对每个可能线程ID都具有跟踪支持。需要20个线程的SoC例如必须具有5比特宽度的线程ID信号。因此，存在可能从不使用的12个线程ID（25 – 20）。在另一场景中，SoC设计者可以愿意地想要从曾被跟踪的中排除特定线程ID。在这些情况下，其可以是用于针对每个这种线程ID对匹配FIFO、丢失计数器和丢弃计数器进行实例化的硅空间的浪费。因此，两个泛型将允许设计者设置应当由跟踪监视器支持的线程ID的范围。将从跟踪中排除所有其他线程ID。起初将不针对它们对匹配FIFO和计数器进行实例化。

随后，仍可以通过经由软件接口设置线程ID范围过滤器来使针对跟踪而支持的线程ID范围变窄。

以上已经相当宽地概述了本公开的不同方面的特征和技术优势，以便可以更好地理解以下详细描述。以下将描述本公开的方面的附加特征和优势。本领域技术人员应当意识到，所公开的构思和具体方面可以被容易地用作修改或重新设计用于实现本公开的不同方面的相同目的的其他结构或过程的基础。本领域技术人员还应当认识到，这类等效的构造并不脱离如所附权利要求中阐述的精神和范围。

在本公开的不同方面中，可以与彼此结合地使用图8-12。

图8是根据本公开的方面的识别芯片上系统中的网络拥塞的流程图。过程800可以被实现在来自图1的芯片上系统100中。

在本公开的方面中，过程800开始于跟踪芯片上系统的主设备和从设备之间的多个信号的交换（步骤802）。该多个信号具有多个请求和多个响应，确定是否至少一个分组延迟时间满足阈值。

然后，该过程追踪在激活跟踪之前和之后作出的该多个请求和该多个响应，以确定在跟踪被激活之后跟踪该多个响应中的哪些响应以及在跟踪被去激活之后跟踪其余多个响应（步骤804）。

图9是根据本公开的方面的利用计数器来识别芯片上系统中的网络拥塞的流程图。过程900可以被实现在来自图1的芯片上系统100中。

在本公开的方面中，过程900开始于跟踪芯片上系统的主设备和从设备之间的多个信号的交换（步骤902）。该多个信号具有多个请求和多个响应，确定是否至少一个分组延迟时间满足阈值。

然后，该过程识别该多个信号中的从主设备至从设备的请求（步骤904）。接着，该过程确定在发出该请求时跟踪是否被激活（步骤906）。响应于跟踪被去激活，递增丢弃计数器（步骤908）。响应于跟踪被激活，递增跟踪计数器（步骤910）。此后，该过程终止。

图10是根据本公开的方面的利用计数器来识别芯片上系统中的网络拥塞的流程图。过程1000可以被实现在来自图1的芯片上系统100中。

在本公开的方面中，过程1000开始于跟踪芯片上系统的主设备和从设备之间的多个信号的交换（步骤1002）。该多个信号具有多个请求和多个响应，确定是否至少一个分组延迟时间满足阈值。

然后，该过程识别该多个信号中的从从设备至主设备的响应（步骤1004）。接着，该过程确定在发出该响应时跟踪是否被激活（步骤1006）。响应于跟踪被去激活，确定跟踪计数器是否大于0（步骤1008）。响应于跟踪计数器大于0，递减跟踪计数器（步骤1010）。响应于跟踪计数器为0，递减丢弃计数器（步骤1012）。

回到步骤1006，响应于跟踪被激活，确定丢弃计数器是否大于0（步骤1014）。响应于丢弃计数器为0，递减跟踪计数器（步骤1016）。响应于丢弃计数器大于0，递减丢弃计数器（步骤1018）。此后，该过程终止。

图11是根据本公开的方面的利用FIFO来识别芯片上系统中的网络拥塞的流程图。过程1100可以被实现在来自图1的芯片上系统100中。

在本公开的方面中，过程1100开始于跟踪芯片上系统的主设备和从设备之间的多个信号的交换（步骤1102）。该多个信号具有多个请求和多个响应，确定是否至少一个分组延迟时间满足阈值。

然后，该过程识别该多个信号中的从主设备至从设备的请求（步骤1104）。接着，该过程确定是否将跟踪该请求（步骤1106）。响应于该请求被跟踪，将条目推送到先入先出列表中，其中，该条目指示将跟踪该请求（步骤1108）。响应于该请求被丢弃，将条目推送到先入先出列表中，其中，该条目指示将丢弃该请求（步骤1110）。此后，该过程终止。

图12是根据本公开的方面的利用FIFO来识别芯片上系统中的网络拥塞的流程图。过程1200可以被实现在来自图1的芯片上系统100中。

在本公开的方面中，过程1200开始于跟踪芯片上系统的主设备和从设备之间的多个信号的交换（步骤1202）。该多个信号具有多个请求和多个响应，确定是否至少一个分组延迟时间满足阈值。

然后，该过程识别该多个信号中的从从设备至主设备的响应（步骤1204）。接着，该过程确定是否通过读取先入先出列表中的下一条目跟踪了与该响应相关联的请求（步骤1206）。该下一条目指示该响应是否与被跟踪的请求相关联。然后，响应于该请求被丢弃，丢弃该响应（步骤1208）。响应于该请求被跟踪，跟踪该响应（步骤1210）。此后，该过程终止。

不同的所描绘的方面中的流程图和框图示意了装置、方法、系统和计算机程序产品的一些可能实现的架构、功能和操作。在这一点上，流程图或框图中的每个框可以表示计算机可使用或可读程序代码的模块、段或部分，其包括用于实现一个或多个指定功能的一个或多个可执行指令。在一些可替换实施方式中，框中指出的一个或多个功能可以不按附图中指出的顺序出现。例如，在一些情况下，根据所涉及的功能，可以基本上同时执行接连示出的两个框，或者有时可以按相反顺序执行这些框。

一种用于跟踪的方法，所述方法包括：跟踪主设备和从设备之间的多个信号的交换，其中，所述多个信号具有多个请求和多个响应；追踪在激活跟踪之前发出、尚未被发出响应的多个请求；对跟踪进行激活；丢弃对在激活跟踪之前发出的多个请求中的每一个的响应的跟踪；追踪在所述跟踪被激活之后发出的多个请求；追踪在所述跟踪被激活之后发出的多个响应；对跟踪进行去激活；以及识别要在跟踪被去激活之后跟踪的多个响应。

Claims (10)

1.一种在包含跟踪监视器的芯片上系统中进行跟踪的方法，所述芯片上系统还包括交换包括多个请求和多个响应的多个信号的主设备和从设备，所述方法包括：

由跟踪监视器跟踪包括从所述多个请求和所述多个响应接收和存储一个或多个请求以及一个或多个响应；以及

由跟踪监视器追踪在激活跟踪之前和之后在所述主设备和从设备之间作出的一组一个或多个请求和一组一个或多个响应，以确定在跟踪被激活之后跟踪来自所述一组响应的哪些响应以及在跟踪被去激活之后跟踪来自所述一组响应的其余响应中的哪些响应，其中所述一组请求和所述一组响应具有第一线程ID，其中针对来自所述一组请求的每个请求而言，所述追踪包括：

    识别所述多个信号中的从所述主设备至所述从设备的请求；

    确定在发出所述请求时跟踪是否被激活；

    响应于确定跟踪被去激活，递增丢弃计数器；以及

    响应于确定跟踪被激活，递增跟踪计数器。

2.根据权利要求1所述的方法，其中，针对来自所述一组响应的每个响应而言，所述追踪包括：

识别所述多个信号中的从所述从设备至所述主设备的所述响应；

确定在发出所述响应时跟踪是否被激活；

响应于确定跟踪被去激活，确定所述跟踪计数器是否大于0；

响应于确定所述跟踪计数器大于0，递减所述跟踪计数器；

响应于确定所述跟踪计数器为0，递减所述丢弃计数器；

响应于确定跟踪被激活，确定所述丢弃计数器是否大于0；

响应于确定所述丢弃计数器为0，递减所述跟踪计数器；以及

响应于确定所述丢弃计数器大于0，递减所述丢弃计数器。

3.根据权利要求1所述的方法，其中，所述多个信号进一步包括第二组请求和第二组响应，以及其中，所述第二组请求和所述第二组响应具有第二线程ID，以及其中，所述方法进一步包括：

由所述跟踪监视器追踪在激活跟踪之前和之后作出的所述第二组请求和所述第二组响应，以确定在跟踪被激活之后跟踪来自所述第二组响应的哪些响应以及在跟踪被去激活之后跟踪来自所述第二组响应的其余响应中的哪些响应。

4.根据权利要求1所述的方法，其中，针对来自所述一组请求的每个请求而言，所述追踪进一步包括：

确定是否将跟踪所述请求；

响应于所述请求被跟踪，将条目推送到先入先出列表中，其中，所述条目指示将跟踪所述请求；以及

响应于所述请求被丢弃，将条目推送到所述先入先出列表中，其中，所述条目指示将丢弃所述请求。

5.根据权利要求4所述的方法，其中，针对来自所述一组响应的每个响应而言，所述追踪进一步包括：

识别所述多个信号中的从所述从设备至所述主设备的响应；

确定是否通过读取所述先入先出列表中的下一条目跟踪了与所述响应相关联的请求，其中，所述下一条目指示所述响应是否与被跟踪的请求相关联；

响应于确定所述请求被丢弃，丢弃所述响应；以及

响应于确定所述请求被跟踪，跟踪所述响应。

6.一种包含跟踪监视器的芯片上系统，

该跟踪监视器被配置为：

跟踪所述芯片上系统的主设备和从设备之间的多个信号的交换，其中，所述多个信号包括一个或多个请求和一个或多个响应；以及

追踪在激活跟踪之前和之后在所述主设备和从设备之间作出的一组一个或多个请求和一组一个或多个响应，以确定在跟踪被激活之后跟踪来自所述一组响应的哪些响应以及在跟踪被去激活之后跟踪来自所述一组响应的其余响应中的哪些响应，

其中所述一组请求和所述一组响应具有第一线程ID，

其中针对来自所述一组请求的每个请求而言，所述跟踪监视器进一步被配置为：

    识别所述多个信号中的从所述主设备至所述从设备的请求；

    确定在发送所述请求时跟踪是否被激活；

    响应于确定跟踪被去激活，递增丢弃计数器；以及

    响应于确定跟踪被激活，递增跟踪计数器。

7.根据权利要求6所述的跟踪监视器，其中，针对来自所述一组响应的每个响应而言，所述跟踪监视器被进一步配置为：

识别所述多个信号中的从所述从设备至所述主设备的所述响应；

确定在发出所述响应时跟踪是否被激活；

响应于确定跟踪被去激活，确定所述跟踪计数器是否大于0；

响应于确定所述跟踪计数器大于0，递减所述跟踪计数器；

响应于确定所述跟踪计数器为0，递减所述丢弃计数器；

响应于确定跟踪被激活，确定所述丢弃计数器是否大于0；

响应于确定所述丢弃计数器为0，递减所述跟踪计数器；以及

响应于确定所述丢弃计数器大于0，递减所述丢弃计数器。

8.根据权利要求6所述的跟踪监视器，其中，所述多个信号进一步包括第二组请求和第二组响应，以及其中，所述第二组请求和所述第二组响应具有第二线程ID，以及其中，所述跟踪监视器被进一步配置为：

追踪在激活跟踪之前和之后作出的所述第二组请求和所述第二组响应，以确定在跟踪被激活之后跟踪所述第二组响应中的哪些响应以及在跟踪被去激活之后跟踪其余多个响应。

9.根据权利要求6所述的跟踪监视器，其中，针对来自所述一组请求的每个请求而言，所述追踪进一步包括所述跟踪监视器进一步被配置为：

确定是否将跟踪所述请求；

响应于所述请求被跟踪，将条目推送到先入先出列表中，其中，所述条目指示将跟踪所述请求；以及

响应于所述请求被丢弃，将条目推送到所述先入先出列表中，其中，所述条目指示将丢弃所述请求。

10.根据权利要求9所述的跟踪监视器，其中，针对来自所述一组响应的每个响应而言，所述追踪进一步包括所述跟踪监视器被进一步配置为：

识别所述多个信号中的从所述从设备至所述主设备的响应；

确定是否通过读取所述先入先出列表中的下一条目跟踪了与所述响应相关联的请求，其中，所述下一条目指示所述响应是否与被跟踪的请求相关联；

响应于确定所述请求被丢弃，丢弃所述响应；以及

响应于确定所述请求被跟踪，跟踪所述响应。