用于调试在多核架构中执行的多线程程序的方法和系统的制作方法

专利名称：用于调试在多核架构中执行的多线程程序的方法和系统的制作方法
技术领域：
本发明涉及在多核架构中进行调试的方法和设备。
背景技术：
近年来，为了使硅效率(即，“应用可实现的”MIP/mm2或MIP/mW)最大化，出现了一种制造包含多个核的处理器的趋势。这种多核架构理想地适于运行基于线程的应用，因为线程定义了包含执行状态、指令流和数据组的自主工作包，该线程通过定义可以与其他线程并行执行。然而，这种并行执行对在这些多核架构上使用的软件调试进程引入了另外的问题。软件调试是对计算机应用的执行中的错误进行定位和改正的总称。
软件调试所面临的关键问题之一是海森堡臭虫(Heisenberg bug)(也称为“探针效应(probe effect)”)。出于调试目的(例如，为了提高系统诊断的级别)而添加的任意代码都可能稍微改变同时和/或并行执行的线程的定时。这带来了程序缺陷(bug)被掩饰的风险，这些程序缺陷在同一应用的发行版本中可能会被发现。另外，难以在生成中存在很多调试代码时提取有意义的性能测量值和测定值(instrumentation)。这是因为如高速缓存和互连性能的二级效应可能会受到附加代码的影响，并且对代码大小有更明显的影响。
另外，由于其开发中使用了很多资源，所以对于提高为这种多核架构开发的软件的可重用性存在不断增长的需求。过去，用于多核架构的应用是在定制的基础上编写的，从而开发出可移植性很差的硬件专用应用。另外，这些应用的调试也非常特殊。

发明内容
根据本发明的第一方面，提供了一种对多核处理器架构中的线程执行进行监测的方法，该多核处理器架构包括用于处理这些线程的多个互连的处理器元件，该方法包括接收多个线程参数指示符，这些线程参数指示符表示与一个或多个线程的功能和/或标识有关的一个或更多个参数；将这些线程参数指示符中的至少一些与第一多个预定标准进行比较，每一个预定标准都代表了感兴趣的指示符；以及根据作为所述比较的结果被识别为感兴趣的线程参数指示符来生成输出。
这提供了以下的能力在线程级别对在多核处理器架构上运行的应用进行调试和跟踪，而无需出于线程级别调试的目的而专门添加代码。另外，还提供了以下的优点使得能够对多核架构应用进行调试，而不需要引入附加代码而因此引入探针效应。
根据本发明的另一方面，提供了一种用于多核处理器架构的线程级别软件调试控制器，该多核处理器架构具有多个互连的处理器元件，每一个元件都提供用于处理线程的资源，所述调试控制器与所述处理器元件中的每一个进行通信，并且包括用于对该多核处理器架构中的线程的分配和执行进行监测的监测器逻辑。


本发明可以按照多种方式来实现，下面将参照附图并通过示例的方式来描述某些实施例，在附图中图1示出了典型的多核处理器架构系统的逻辑布局的示意性框图；图2示出了图1的逻辑布局的一种示例性实现的示意性框图，其中线程管理和分配控制器与专用存储器设备和控制器客户端(client)一起结合在通用多核处理器架构中；图3再次以框图的形式示出了结合有图2的元件的基于现有的片上系统(SoC)总线的架构的示例；图4示出了图1、2和3的控制器的外部连接的更详细视图；图5示出了图2和3的存储器设备的更详细视图；图6示出了图2、3和4的控制器的内部构成的更详细视图；
图7示出了如图2和3所示的控制器客户端的示意性框图；图7B示出了在单个控制器客户端用作用于多个处理资源的代理的情况下该系统的示意性框图；图8示出了硬件控制器客户端的更详细示意性框图；图9示出了线程描述符、控制器、处理资源和共享系统存储器之间的典型关系；图10示出了根据本发明实施例的结合有调试架构的典型多核处理器架构系统的逻辑布局的一种示例性实现的示意性框图。在图10中，控制器用作用于调试控制的中心仲裁器；图10b示出了根据本发明实施例的结合有调试架构的典型多核处理器架构系统的逻辑布局的另一示例性实现的示意性框图。在图10b中，不是本发明的一部分的附加组件提供了包括控制器的多核处理器架构内的所有核之间的调试事件集合；图11示出了图10和10b的线程调试控制器的外部连接的更详细视图；图12a示出了图10和10b的线程调试控制器的跟踪缓冲器的外部连接的更详细视图；图12b示出了图12a的跟踪缓冲器的典型输出的时序图；图13示出了图10和10b的线程调试控制器的外部连接的另一详细视图，包括到图2的控制器的多个子块的连接；图14示出了图11的线程调试管理器的内部构成的功能框图；图15示出了图14的调试机之一的逻辑框图；图16示出了图14的调试机之一的物理框图；图17示出了图14的调试机的级联(concatenation)能力的示例；图18示出了在单字EventWatch情况下调试机内的指令数据流；图19示出了在双字EventWatch情况下调试机内的指令数据流；图20示出了图14的示例性静态事件过滤器模块的功能框图；图21示出了图20的静态事件过滤器模块中的事件过滤器掩码(mask)的示例性分配；以及图22示出了图14的跟踪数据格式化器/压缩器模块的示例的框图。
具体实施例方式
图1示出了典型的多核处理器架构的示例的系统框架的逻辑视图。该框架包括多个处理资源150，每个处理资源都可以与该多核架构中的其他处理资源150相似或不相似。处理资源150可以是能够执行指令的任意形式的硬件或其等价物，因此可以包括通用处理资源150，或者具有有效限制指令集的处理资源150，例如输入输出设备。
该系统框架还包括集中线程管理和分配系统，该集中线程管理和分配系统包括线程管理和分配控制器130以及经由存储器接口180连接至该控制器的专用紧密连接的存储器190。每个处理资源150都能够通过互连115来访问控制器130。应该理解，图1的结构的实现不需要任何特定的互连策略(即，控制器130与各个处理资源150进行通信或者各个处理资源150与控制器130进行通信所用的结构，以及各个处理资源150与系统资源，例如存储器140，进行通信所用的结构)；具体地说，同样可以采用点对点链接、中央系统总线或者甚至是管道架构，只要处理资源150中的每一个都应当能够直接或间接(即，通过其他处理资源150或其他方式)与控制器130进行通信。
图2再次仅以示例的方式示出了实现图1的逻辑结构的多核处理器。图2的多核处理器采用了多个处理资源150，每一个处理资源都通过系统互连160而连接。系统互连160进而通过输入接口100和输出接口110与控制器130进行通信。在图3的示例中，系统互连160被布置为传统的中央总线，该中央总线将处理资源150中的每一个彼此连接并将处理资源150中的每一个与控制器130连接，还将处理资源150中的每一个与诸如系统存储器的共享系统资源140连接。可以通过多种目前可用的接口技术中的任意一种来实现与共享系统资源140的连接。存储器可以由目前可用的中央计算机存储器技术中的任意一种来构成，例如静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)，或者双倍数据速率随机存取存储器(DDR RAM)。
如图2所示，多个处理资源150中的每一个都具有被构造用于从中央控制器130接收控制信息，并根据所接收的控制信息来管理处理资源150的相关联的控制器客户端120。下面更详细地描述控制器客户端120的功能和用途。每个处理资源150还具有用于通过系统互连160与控制器130进行通信的相关联的互连代理170。互连代理170为控制器客户端120提供普通接口，该接口独立于系统互连160上使用的基本互连协议，即，该接口提供了系统互连160上使用的通信协议与控制器客户端120所使用的通信协议之间的协议翻译。由于使用了互连代理170，本发明实施例的控制器客户端120可以应用于目前可用的任意系统互连协议。实际上，控制器客户端120与控制器130进行通信所通过的接口协议115可以与接口协议160中的任意一个或全部在物理上不同并且具有不同的特性，所述接口协议160被用来使得能够在处理资源150和共享系统资源140(例如，系统存储器)之间进行通信。
作为整体，多核处理器10被构造用于执行目标应用，该目标应用可以分为多个单独的任务(称为线程)。每个处理资源150都由控制器130分配了适当的线程。该分配是根据多个参数来执行的，这些参数包括但并不限于所关注线程的优先级、每个处理资源150的可用性以及特定处理资源150对于特定线程的执行的适合性。
然而，应该理解的是，添加控制器130及其专用存储器190并不需要对处理器10的布局进行重新设计。
图3中示出了一种具体结构，图3以框图的形式示出了典型的片上系统(SoC)架构，并且示出了可能在实际应用中被置于控制器130的控制之下的各种处理资源150。应该注意，处理资源150实际上可以具有相对普通的能力，例如DSP，或者可以具有相对有限的功能，例如外围IO。
图4示出了控制器130及其相关联的输入接口组100、输出接口组110，以及两个双向接口组160和180，每个组都位于控制器130的外围。
系统控制组102包括确保控制器130的正确操作所需的各种信号。这些信号包括系统时钟、实时时钟和重置信号(RST)。来自控制器130的所有输出信号对于系统时钟都是同步的，尽管它们可能根据系统的需要而被重新同步为其他时钟域。对于控制器130的所有输入信号在处理之前对于系统时钟都是同步的。RST输入是用于重置控制器130的同步重置信号。
外部中断组101由源自线程管理和分配系统外部的一组外部中断构成。外部中断组101中的信号例如可以通过与外界的输入接口来驱动，或者通过引脚直接从多核处理器的外部进行驱动。外部中断输入的数量可以在多核处理器10的设计阶段来限定。
内部控制组111由针对每个控制器客户端120及其相关联的处理资源150的同步中断构成。因此，信号的数量通常与系统内的处理资源150的数量相对应，并且将在多核处理器10的设计阶段进行限定。内部中断信号是表示线程准备执行的内部线程就绪中断信号，并被分配给与该控制器客户端120相关联的特定处理资源150。
调试接口组112由以下子组构成1、辅助调试接口，其使得外部调试代理能够对控制器130以及作为整体的系统进行调试访问。通过该接口，可以内部和外部地设定断点和观察点，并且可以读取系统状态信息。
2、跟踪缓冲器输出，其是根据一组预先配置的过滤方针并在调试管理器400的最终控制下提供运行时系统状态的流式输出。
3、外部调试使能信号，其可以按照它们自己的名称(right)用作断点信号，或者可以与处理资源特定使能信号进行组合。
下面将更详细地描述该特定格式、结构和以上调试接口组的使用。
紧密连接的存储器接口组180将控制器130连接至其专用的紧密连接的存储器资源190。
图5示出了该专用的紧密连接的存储器190的典型结构。地址路径和数据路径的宽度在多核处理器10的设计阶段进行限定。专用的紧密连接的存储器接口180包括存储器地址总线191、存储器读取数据总线192、存储器写入数据总线193以及写入使能信号194和读取使能信号196。
假定所附加的存储器是同步SRAM设备。根据目标应用的需要，专用的紧密连接的存储器190如在多核处理器10的设计阶段所限定的，包含整数个控制器存储器元件195。在当前优选的实施例中，每个控制器存储器元件195都消耗256位的存储器空间。另外，在当前优选的实施例中，该控制器支持最多65536个控制器存储器元件(即，16Mb存储器)。尽管如稍后所述，队列描述符消耗了控制器存储器元件195，但是在典型系统中，所需的控制器存储器元件195的数量将由线程支持要求来控制。例如，能够在控制器130内同时支持400个线程的系统将需要大约128kb的附加存储器。
图4的互连接口组160遵从所选择的互连协议或者多核处理器10中使用的协议以及互连代理170，互连代理170是在多核处理器的设计阶段限定的。在存在多个不同的互连结构的情况下，互连接口组160可以由多个可能不同的接口构成。在所示的实施例中，使用了总线接口。然而，应该明白的是，如前面所提及的，同样可以采用各种其他形式的接口。
控制器子块描述和功能图6示出了控制器130的主要逻辑组件。控制器130的功能被分为四个主要内部并行处理子块，分别执行以下功能1、线程输入管理器(TSIM)200，其被构造用于维持专用的紧密连接的存储器190中的空闲控制器存储器元件195的列表，并且检查控制器存储器元件195的恢复。
2、线程同步管理器(TSPM)210，其被构造用于根据需要维持在专用的紧密连接的存储器190中的等候(pending)列表和定时器队列，并在线程之间进行同步，并将线程提升(promotion)为在专用的紧密连接的存储器190中的就绪队列结构。线程同步管理器210通过在专用的紧密连接的存储器190中插入或提取等候线程描述符来维持等候和定时器队列结构的完整性。
3、线程输出管理器(TSOM)220，其被构造用于维持专用的紧密连接的存储器190中的就绪队列结构，并维持在专用的紧密连接的存储器190中的用于各个处理资源150的调度队列(dispatch queue)。线程输出管理器(TSOM)220还被构造用于生成被发送到控制器客户端120的中断110。就绪队列结构的完整性的维持是通过在专用的紧密连接的存储器190中插入和提取保存在控制器存储器元件195中的线程描述符来进行的。
4、线程调度管理器(TSSM)230，其被构造用于为设置在专用的紧密连接的存储器190中的就绪队列结构内的各个处理资源150提供调度决定。
另外，多个二级处理子块提供了以下支持功能5、线程存储器管理器(TSMM)240，其被构造用于提供对所附加的专用的紧密连接的存储器190的集中访问，包括互相排斥和锁定。
6、中断管理器(TSIC)250，其被构造用于将输入外部系统中断转换为内部同步原语(primitive)。
7、时间管理器(TSTC)260，其被构造用于为每个处理资源150提供用于同步目的的定时器功能以及监视定时器功能。
8、系统接口(TSIF)280，其被构造用于提供互连接口和构造以及对多核处理资源150和控制器130内的各个子块的运行时访问。
9、服务器垫片(shim)(TSSS)290，其被构造用于提供控制器130与多核处理资源150之间的物理接口115。
以上列出的主要和二级子块中的每一个还包括调试输出，该调试输出构成调试接口112的一部分，用于向本发明的调试控制器400通知在与该信号相对应的各个子块内发生的事件。在命令可能通过特定条件完成的情况下，在子块内对状态标志进行管理。
总的来说，控制器130通过维持专用的控制器存储器190内的多个队列结构来管理线程。这些队列结构包括等候、就绪、定时器和调度队列。在这些队列中的一个或更多个中保存有正在等待执行的线程，并在这些线程就绪时被将这些线程分配给适当的处理资源150。这些队列中的线程的控制主要使用push(压入)、pop(弹出)和sort(排序)操作来进行。在共同未决的美国专利申请No.10/308,895中描述了控制器130的操作的全部细节，在此通过引用并入其全部内容。
下面是对控制器130内的上述主要和二级处理子块的交互的详细描述。
每个子块都为其他子块提供一组函数(function)，使得每个子块都能够指示其同一层次的功能单元(peer)在专用的紧密连接的存储器190内对它们各自维持的结构进行控制。当接收到在控制器软件应用程序接口(API)处接收的相似命令时，由特定子块来调用函数。
线程输入管理器函数线程输入管理器200为控制器130内的其他子块提供了三个公共函数。
FreeListStatus函数返回控制器存储器元件195空闲列表内的头指针和元素的数量。该空闲列表是当前未使用的控制器存储器元件195的列表。该函数仅可以由系统接口280在控制器130软件API处接收到相似命令时调用。
PushFreeIndex函数用于将被释放的控制器存储器元件195的索引压入回到空闲列表中。该函数仅可以由线程调度管理器230调用。
PopFreeIndex函数用于从空闲列表中弹出空闲控制器存储器元件195的索引。其通常在系统接口280内的API调用服务例程中调用。
线程同步管理器函数线程同步管理器210为控制器130内的其他子块提供了七个公共函数。
以下五个函数仅可以由系统接口280响应于控制器130软件API所接收的相似命令来调用。
PushPendingDescriptor函数在启动过程中使用，以向等候队列描述符的列表中添加等候队列描述符。
PushThread函数在运行时使用，以向给定等候队列中添加从属线程。
GetTimerStatus函数返回定时器队列中的头指针和元素的数量。
SetTimerStatus函数设定该定时器队列中的头指针和元素的数量。
SetPendingStatus函数设定等候队列描述符列表的状态。
GetPendingStatus函数返回等候描述符队列中的头指针和元素的数量。
SyncEvent函数用于向给定的等候队列发出同步原语。该函数由线程中断管理器250或系统接口280调用。
TimeEvent函数用于向定时器队列发出基于定时器的同步原语。该函数仅由时间管理器260调用。
线程输出管理器函数线程输出管理器220为控制器130内的其他子块提供了五个公共函数。
Push函数将线程描述符设置在就绪队列结构中。该方法可以由系统接口280或线程同步管理器210调用，并且其可以以高优先级被调用从而提高处理速度(例如，处理中断)。
在线程是独立(刚刚就绪)的情况下，将从系统接口280进行调用，而在线程描述符最初具有依赖性时，从线程同步管理器210进行调用。
以下函数仅可以由系统接口280响应于在控制器130的软件API处接收到相似命令而调用。
GetDispatchQueueStatus函数返回调度队列列表内的头指针和元素的数量。
SetDispatchQueueStatus函数设定调度队列列表内的头指针和元素的数量。
DispatchQueueSetMetrics函数设定当前正在执行的线程的量度(metrics)，从而可以进行所通知的占先决定。
DispatchQueueEvent函数将调度事件从就绪队列结构传播到由线程输出管理器(TSOM)220管理的调度队列。该函数仅由线程调度管理器(TSSM)223调用。
DispatchQueuePop函数从调度队列的头部中弹出线程描述符。
DispatchWorkQueuePush函数将调度队列压入到线程输出管理器220的工作队列中。该函数仅可以由线程调度管理器230调用，线程调度管理器230利用该函数来通知输出管理器220作为调度更新的结果的调度队列内所需的改变。
线程调度管理器函数线程调度管理器230为控制器130内的线程输出管理器220和系统接口280提供了三个公共函数。
PushPushWorkEvent函数由线程输出管理器220在其将线程描述符添加到就绪队列结构中后立即调用。
PushPopWorkEvent函数由线程输出管理器220在其将线程描述符从就绪队列结构中去除后立即调用。
FreeIndex函数使得控制器存储器元件195的释放能够与线程调度管理器230内的正在进行的调度行为适当地同步。可以在控制器130的软件API处接收到相似命令，或者作为线程输出管理器220内的pop操作的结果来发出该调用。
控制器客户端如前所述，术语处理资源150适用于可以执行指令的任意资源，而不管该指令可能会多么基本。因此，还包括了诸如输入/输出模块的具有固定功能的资源。根据处理资源150的类型，系统互连160与处理资源50之间经由控制器客户端120的连接可以是单向的或双向的。
图7示出了用于控制器130的控制器客户端120的示例图。
对于适当的处理资源150，例如通用处理器或数字信号处理器，控制器客户端120通常以软件形式实现。然而，当处理资源150功能有限时，控制器客户端120可能需要硬件组件。
在系统互连160与处理资源150之间使用了硬件组件的情况下，控制器客户端120仍然使用相同的接口与处理资源150相连。也就是说，控制器客户端120为互连代理170提供了与处理资源150对控制器客户端120相同的接口。在某些情况下，例如在输入/输出设备的情况下，将进入处理资源150的数据路径视为与离开处理资源150的数据路径不同。
除了主接口之外，控制器客户端120还提供频带外接口(out of bandinterface)作为用于运行时和调试事件的输出。在使用软件控制器客户端120的情况下，使用标准中断来提供这些接口，以调用适当的服务例程，或形成对处理资源150的特定调试和跟踪单元151的输入。
控制器客户端的操作模式每个控制器客户端120都被完全中断驱动。当从控制器130接收到内部中断时，控制器客户端120从与特定处理资源150相关联的调度队列的头部中弹出线程描述符，该调度队列保存在专用的紧密连接的存储器190中。然后使用该线程描述符中的该唯一引用(reference)从主存储器资源140读取进一步的线程控制信息(线程控制块(TCB))。该TCB中所包含的信息可以是以下的任意一种1、控制器客户端120的构造内容。该信息可用于构造控制器客户端120的系统资源使用监控(policing)、地址或数据总线触发器构造(用于调试)、数据呈现模式等。
2、处理资源150的构造内容。这是使处理资源150准备执行特定线程所需的信息。其可以包括从该线程的之前的部分执行或专门的硬件加速器(例如，音频CODEC)的构造中恢复。
3、指令内容。在固定功能硬件加速器的情况下，“指令”将在目标硬件处理资源150中暗示，例如在处理资源150是输出模块时的输出指令，并且任意所需的特殊化或配置都将容纳在配置信息中。在软件控制器客户端120的上下文中，这通常是对于与线程相关联的函数代码的指针。
4、数据内容。该内容可以限定系统存储器140中的起始地址或多个地址以及线程可以操作的数据的范围。
5、控制器客户端120后处理内容。该内容确定了控制器客户端120在完成线程执行之后的动作。
控制器客户端120的操作有三个不同阶段。
1、配置阶段，其中准备处理资源150和控制器客户端120以执行特定线程。在最简单的情况下，该配置阶段为空。
2、执行阶段，其中执行线程，并且控制器客户端120可以提供数据或监测资源利用。
3、完成阶段。处理的完成可能导致无动作、创建另一线程、发出同步原语、或者线程创建和同步的组合。此外，控制器客户端120还可能需要设定或更新调度机的量度并终止线程。在执行线程的过程中需要其他存储器来存储结果的情况下，控制器客户端120还必须执行该服务器方法。
在各个硬件控制器客户端120b在有效周期期间充分利用可用的系统互连160的带宽的情况下，优化方案将使得控制器客户端120b能够作为针对多个硬件处理资源150的代理来操作。图7B中示出了这种结构。与前面的情况相同，代理控制器客户端120b被中断驱动，然而，尽管在前面的示例中，仅从控制器130路由单个中断，但是在代理控制器客户端模型中，每个处理资源150都有中断。根据从控制器130接收的中断的索引，代理控制器客户端120b对所识别的处理资源150执行相同的步骤。在代理控制器客户端模型中，如果需要系统互连160的使用监控，则硬件适配器120c将保留在处理资源150和系统互连160之间。
如前所述，控制器客户端120可以实现为软件。在此情况下，控制器客户端120的某些功能(例如，共享资源使用监控)通常会利用可能已经存在于处理资源150硬件中的现有硬件组件(例如，存储器管理单元(MMU))。
结果，软件控制器客户端120架构和实现对于处理资源150是部分特定的。
根据相关处理资源150的特性，硬件控制器客户端120可以还具有特殊要求。以下部分说明了在大多数情况下适用的一般架构。
硬件控制器客户端的一般示例图8中示出了硬件控制器客户端120的基本结构。该设计的功能核心是控制器客户端有限状态机(FSM)300。该有限状态机(FSM)300可以在所有三个阶段中都有效。控制器客户端FSM 300由来自控制器130的中断111启动。
首先，控制器客户端FSM 300对系统互连160进行管理，以从共享存储器资源140中读取TCB，该TCB包含了对其本身指令的引用。在配置阶段中，控制器客户端120可以管理处理资源接口、解释配置命令并将它们翻译为发送至处理资源150的写入循环。此外，控制器客户端120对其自身的资源监控进行配置。从配置状态过渡到执行状态的方式对于处理资源150是特定的，但是可以通过显式执行原语或仅通过进入数据传递状态来进行标记。
从控制器客户端120的角度可以看出，最简单的架构对于处理资源150和系统侧具有相同的接口协议。在此情况下，在执行阶段中，通过检查适当的情况，将处理资源150的读取和写入循环简单地映射到系统接口。
最简单的控制器客户端120的实现在系统到处理资源的路径310和处理资源到系统的路径320上都需要FIFO型接口。在具有该特性的控制器客户端120的执行阶段中，可以通过消息模式或流模式将数据提供给处理资源150。消息模式(其中在处理之前，整个数据集本地累积在控制器客户端120中)造成更粗放的可靠的(coarse grained blocky)互连行为，这便于更复杂的互连仲裁器。流模式(其中数据直接从系统存储器140流传输到处理资源150中)提供了硅效率更高的方案，该方案需要更仔细地考虑硬件握手，并且展示了精细互连交易和对互连性能的紧密结合。
从执行阶段到完成阶段的过渡可以通过测量对处理资源150的数据提供来推断出，或者由处理资源150本身显式地告知。在完成阶段中，控制器客户端120再一次根据原始线程控制块所提供的指令集来执行。
注意，在某些情况下，适于将进入处理资源150(例如，输入/输出设备)的数据路径和离开处理资源150的数据路径视为不同。相比而言，在某些情况(例如，诸如DSP的算术加速器)下，将数据的消费者和产生者结合在同一控制器客户端120框架中是很自然的。
为了提供处理资源150与其他系统资源之间的分离(decoupling)级别，还可以由控制器客户端120提供多个附加功能(facility)a)可以针对由基本地址和偏移定义限定的预期行为，通过使用比较器330和比较地址寄存器340对处理资源150产生的地址进行检查。
b)可以使用减法器350和偏移地址寄存器360对处理资源150产生的地址进行偏移，使得处理资源150能够对于任意给定的线程具有归一化的地址映射图，通常为归一化循环地址(around address)0x0。
c)在处理资源功能有限并且因此不包括其自身的指令级调试硬件的情况下，可以包括调试监视寄存器。于是这种寄存器可用于监测地址使用，使得其他缺少固定功能的硬件资源150能够具有指令级的调试能力。
对象控制器130中使用的数据类型的示例分为公共可见(可以通过系统详尽地看到并控制)和私有可见(仅在控制器130内可见，并仅受控制器130子块的控制)。为了确保该设计在多端应用上的可移植性，将所有线程、队列和集合队列的描述符存储在使用公共基本类的专用的紧密连接的存储器190、控制器存储器元件195中。
控制器存储器元件每个控制器存储器元件195都可以表示10种描述符类型中的任意一种1、空闲列表元素。该元素是空闲的，而可以由其他描述符类型中的任意一种使用。无需用户初始化或运行时控制。
2、线程描述符(TD)。这是表示应用/管理线程的数据结构。该描述符可能存在于专用的紧密连接的存储器190内的等候队列、就绪队列或调度队列中。无需用户初始化，但是需要运行时控制。
3、调度机根描述符(SRD)。这是调度机等级的最高级描述符。需要用户初始化，但是不需要运行时控制。该根描述符没有父描述符，但是子描述符可以是SSTD、DSTD或TD中的任意一个。
4、静态调度机等级(Tier)描述符(SSTD)。这是静态调度机等级描述符，其父描述符可以是SRD或另一SSTD。SSTD的子描述符可以是另一SSTD、DSTD或TD中的任意一个。
5、动态调度机等级描述符(DSTD)。这是动态调度机等级描述符。不需要用户初始化，但是需要运行时控制。DSTD的父描述符可以是SRD或SSTD，但是DSTD可以仅具有TD子描述符。
6、调度队列描述符。该类描述符描述了正在等待来自相关处理资源150的弹出操作的线程描述符的列表。需要用户初始化，但是不需要运行时控制。
7、等候队列描述符。该类描述符描述了正在等待同步事件的线程描述符的列表。需要用户初始化，但是不需要运行时控制。
8、池(pool)附接节点(PAN)。PAN用于将调度机根等级附接到处理资源150池根等级。需要用户初始化，但是不需要运行时控制。
9、池静态节点(PSN)。PSN用于将调度机根等级附接到处理资源150池根等级。需要用户初始化，但是不需要运行时控制。
10、池根节点(PRN)。对于每个处理资源150池，存在单个PRN。需要用户初始化，但是不需要运行时控制。
图9示出了线程描述符、控制器130、处理资源150和共享系统存储器140之间的典型关系。每个线程原语都包含唯一的引用，pReference。该引用不能由控制器130解释或修改。pReference提供了对于系统存储器140中的限定了要执行的任务的数据结构的指针。通常这会是控制器客户端控制块125，并且将包含至少以下元素函数指针(在图9中被表示为处理资源指令块145)、堆栈指针和变量指针(在图9中一起被表示为数据块135)。
可以定义另外的字段，这些字段提供带内配置或共享系统资源的安全性。
然而，根据应用和/或目标处理资源150，控制器客户端控制块125的复杂度会改变。特别要注意，可以包括其他间接级别，这些间接级别在给定适当的“控制”指令代码和相应的“数据路径”代码的情况下，可以使得完全不同的处理资源150能够在特定环境下对相同数据执行相同的功能。在这种情况下，与不同处理资源150所要求的特定指令流相对应地存在针对各种类型的处理资源150的指针。允许不同处理资源执行相同线程的能力还使得能够对多核架构内的所有可用处理资源进行载荷平衡。此外，可以将处理资源集中(pool)在一起。
处理器资源池使得能够将特定处理资源150的实例集中在单个分配节点中。该分配节点于是可以对属于特定处理资源池的各个处理资源150提供载荷平衡、智能占先和电力管理。
图10和10b示出了结合有根据本发明实施例的特征的调试系统框架的基本示意性布局。在图10中，本发明提供了一种针对系统范围调试控制的集中点，而在图10b中，本发明按照与所有其他调试和跟踪单元类似的方式连接至外部集中调试控制集合组件。
通常，每个处理资源150都提供指令级调试和跟踪单元151，以在指令级使用，或者等效地仅对于相关处理资源150是本地的。这些对于处理资源150是特定的，然而操作使用相同或相似的数据。
广义来讲，调试的方法可以分为两种静态操作，其中系统在提取调试信息的过程中暂停；以及动态操作，其中信息在运行时被收集、监测和分配。
静态操作包括除此之外的断点和观察点的设定配置、暂停和单步的管理、系统状态和存储器负载的快照、观察和分析。
动态操作包括除此之外的处理器循环的监测、高速缓存操作、处理器间通信和系统互连(例如，总线)事务。这种类型的监测总称为跟踪，并且在系统行为的“概评(profiling)”中使用。动态调试(或者跟踪)信息通常由所嵌入系统的组件自主地生成。
本地指令级调试和跟踪单元151包含使得相关处理资源150内的指令的处理在某种预定情况下暂停的嵌入“触发器”逻辑，但是还可以用于发起或终止跟踪信息的累积或者某些其他功能。触发器通常是表示已经观察到预定“触发器序列”的事件位。
作为最低要求，这种触发器逻辑通常包括在遇到给定指令时向本地处理资源150发出中断(触发器)的断点逻辑。包含在这些单元中的功能的量对于处理资源150是特定的，然而，如前所述，在需要的情况下，控制器客户端120可以包括调试观察寄存器，以提供最小级别的指令级调试和跟踪能力。当处理资源150功能有限(例如，专用音频CODEC)时需要这样。
指令级调试和跟踪单元151中的每一个都具有连接至调试访问端口141的双向接口155和经由一个或更多个可选的本地跟踪缓冲器152、跟踪集中点142和可选的统一跟踪缓冲器143连接至跟踪端口144的跟踪输出接口105。
调试访问端口141使得外部“调试主机”能够控制并访问调试进程。通常，这些主机通过串行端口或者其他类似的低速连接接口协议进行连接。
跟踪端口144向外部设备提供对跟踪数据的访问。这使得对跟踪数据的观察可以作为软件调试进程的一部分出现。
可选的本地跟踪缓冲器152和统一跟踪缓冲器143用于在输出之前临时存储跟踪数据。这使得可以存储系统的运行“快照”，然后通过跟踪端口144随后读出。这样，假设调试数据实时地输出，则跟踪端口144不必具有所要求的潜在高传输速度。这就不需要(至少部分地)专用于调试数据输出的大量输出引脚。这是非常重要的，因为与功能逻辑本身的尺寸相反，目前可以装配到任意特定集成电路(IC)小片(die)上的输入/输出焊盘的数量限制了IC小片的尺寸。
跟踪集中点142仅用于将从本地调试和跟踪单元151输出的多个调试跟踪流105复用到单个输出流中，以备存储在统一跟踪缓冲器143中，或者仅用于在没有统一跟踪缓冲器143的情况下通过跟踪端口接口144输出。
在图10中，本发明的线程调试控制器400连接至本地调试和跟踪单元151中的每一个。该线程调试控制器400还再次经由一个或更多个可选的本地和统一的跟踪缓冲器连接至控制器130、调试访问端口141和跟踪输出端口144。在图10的调试框架中，控制器130向各个DTU 151提供初始调试使能信号450，该控制器130建议了最初根据在控制器内观察到的事件得到的调试策略。
在图10b中，指令级调试和跟踪单元151中的每一个都从调试控制集中单元接收调试使能信号，该信号作为对预定事件序列(可以包括本发明所生成的事件)进行观察的结果实现这种使能。图10b的框架使得能够实现可以由本地调试和跟踪单元151或者本发明发起的调试策略。
图11示出了本发明实施例的线程调试控制器400的具体输入和输出。
控制器130的子块200至280中的每一个都具有用于将信号传送到线程调试控制器400中的调试接口410。当这些子块进行交互以管理并在各个处理资源150之间分配各个线程时，这些输入信号将控制器130的相应子块的每一个中发生的事件通知给线程调试控制器400。该线程调试控制器400还可以对用于跟踪和触发器信息的子块事件进行过滤。
控制器130的各个子块内的命令执行导致向线程调试控制器400发送EventID字段和EventData字段。各个事件所相关的子块由这些字段通过哪个接口发送来确定，因为每个子块都具有其自身对于线程调试控制器400专用的接口440。EventID字段可以由用户来定义，因此长度可以为N位，然而在本发明的优选实施例中，EventID的长度为4位。每个单独的EventID字段都识别在特定子块200到280中发生的各个事件。
子块内可能发生的事件的示例包括将线程压入到队列中/从队列中弹出线程、对控制器存储器元件195的读取/写入访问、产生同步事件和在处理资源150与控制器130之间提供低级通信形式的事件。
在当前优选实施例中，伴随每个EventID的EventData字段的长度为32位。该字段包含了由当前正在执行的事件使用的主要数据。通常，其包含控制器存储器元件195的32位长pReference字段，然而，它还可以包括多种其他数据类型中的任意一种，或者当每个数据类型的长度都小于32位时，包含这些数据类型的组合。这些其他数据类型的示例包括控制器存储器元件195索引、中断掩码、定时器值和子模块ID。
线程调试控制器400还具有时间接口420。该接口提供32位时间表示，当线程调试控制器400经由子块输入接口410从控制器130的各个单独子块接收到所有记录的事件时，线程调试控制器400使用该32位时间表示来对所有记录的事件加上时间戳。
辅助调试接口430是用于使得标准外部软件调试及系统可视化和控制工具可以访问线程调试控制器400的双向接口。这些外部软件调试工具用于设定与系统初始化相关的调试参数，并且采集和显示所得到的跟踪数据。所支持的接口的示例包括IEEE 1149.1 JTAG接口和能力更强的IEEE Nexus 5001 AUX端口接口。
最初，旨在用于对芯片设备的边界扫描的JTAG是基于包括串行链路和低速时钟策略的4线接口的技术，JTAG现在扩展用于多核架构中，以使得能够对数据访问进行调试。由于其带宽限制以及接口由调试主机通过低速串行链路来管理的事实，JTAG的应用通常限于静态操作。然而，由于其相对廉价(在硅面积和芯片I/O方面)且易于实现，所以JTAG已经成为用于芯片上调试(on-chip debug)的标准物理层。
Nexus 5001 AUX端口接口提供了更丰富的一组调试能力，包括扩展动态动作，例如对线程调试控制器400内部的调试寄存器的动态访问。
跟踪缓冲器接口440被设计成利用了任意当前可用的缓冲器技术。在该特定实施例中，跟踪数据是通过简单的字节宽度的先进先出接口输出的。图12a示出了字节宽度的接口及其相关控制信号，而图12b示出了形成这些数据并控制输入/输出的电信号的定时。尽管示出了单字节宽度的接口，但是本领域技术人员应该理解，本发明并不因此而范围受限。
再次参照图11，在图10所描述的框架中，外部调试使能信号组450都是本地调试和跟踪单元151使能信号。对多核架构10内存在的每个本地调试和跟踪单元151设置了一个使能信号，因此在设计阶段设定了精确数量。这些信号中的每一个都可以在检测到触发器事件时使能特定的本地调试和跟踪单元151。通过使用这种本地调试和跟踪单元151使能信号，并且由于控制器130的操作的固有线程级抽象(abstraction)，线程调试控制器400提供了可以利用本地指令(微观架构)级别的本地调试和跟踪单元151进行门控(gated)的线程(即，宏观架构)级别调试能力。这为软件工程师提供了基于粗放线程的调试和基于较精细指令的调试，从而便于调试过程，而无需引入另外的调试软件，该另外的调试软件会导致探针效应。
再次参照图11，在图10b所描述的框架中，外部调试使能信号组450是用于将所有本地调试和跟踪单元151使能信号集中在调试控制集中块中的使能信号。这种信号的精确数量是由系统设计者希望传送至调试控制集中块的离散事件的数量来确定的。于是，调试控制集中块的责任就是过滤所有调试使能源并在检测到触发器事件时确定适当的本地调试和跟踪单元151。如上所述，通过使用这种本地调试和跟踪单元151使能信号，并且由于控制器130的操作的固有线程级别抽象，线程调试控制器400提供了可以利用本地指令(微观架构)级别的本地调试和跟踪单元151来进行门控的线程(即，宏观架构)级别调试能力。然而，在这种情况下，触发器序列可以不由控制器发起。
应该注意，线程调试控制器400还为构成任务分配控制器130的子块提供了多种精细调试能力。下面将结合图13对此进行更加详细的说明。
内部调试使能信号组460包括由线程调试控制器400发送给构成任务分配控制器130的每个子块(200-280)的信号。这些信号用于根据线程调试控制器400的配置，使得线程调试控制器400能够使每个子块单步执行其下一指令，或者使该子块完全暂停。
线程调试控制器中断信号组470包括2个信号。它们使得对来自线程调试控制器400的中断的反馈能够回到控制器130。按照与对控制器130的所有其他外部中断相同的方式处理这些中断。这些信号的使用完全是可编程的，但是它们的应用的典型示例包括对应用中的需要关注的事件的统计的收集，以及特定处理资源150中的调试监测线程的启动。
TSIF系统接口412使得可以在控制器130的接口管理子模块280与线程调试控制器400之间进行通信。该接口包括SubBlockCmd从输入接口490和GenericReg主输出接口480。TSIF子块和位于多核处理器内的所有处理资源150都可以通过SubBlockCmd从输入接口490访问线程调试控制器400，从而进行正常和调试操作，例如，在运行应用时对调试参数进行编程。同样，可以允许线程调试控制器400通过GenericReg主输出接口480完全访问控制器130的所有内部子块。
图13示出了控制器130的每个子块与线程调试控制器400之间连接的更详细的图。线程调试控制器400通过接口管理器(280)利用一般寄存器(GenericReg)接口480对控制器130的每个子块内的资源进行访问。该接口还使得线程调试控制器400能够独立地对每个子块进行调试和执行单个步骤。
线程调试控制器400还提供了多种系统范围的闭环调试能力。首先，中断管理器(TSIC)250具有另外的线程调试控制器400反馈中断470。线程调试控制器400使用这些中断来表示被观察的一组特定的用户可定义事件已经发生。该中断随后可用于使中断管理器(TSIC)250生成SyncEvent来释放正在等待该特定SyncEvent的系统管理线程。这样，调试系统就可以在检测到特定系统事件时触发系统管理线程。
其次，专用TSIF系统接口280命令可以生成能够保存32位数据的TSIF DebugEvent。随后这些TSIF DebugEvent可用于创建事件，以例如表示处理状态的改变，或者作为主机调试器和每个处理资源150之间的低比特率通信信道。
图14示出了线程调试控制器400的内部功能实现。
动态调试接口540用于对线程调试控制器400的动态操作的细节(例如，线程调试控制器400要寻找什么系统管理和分配事件，以及当观察到特定事件时线程调试控制器400要执行什么动作)进行控制。
静态调试接口530用于对线程调试控制器400的静态操作的细节(例如静态事件过滤器)进行控制。
SubBlockCmd接口490使得控制器130的接口管理器280可以访问动态调试接口540。专门设计的复用器560仅使得可以从SubBlockCmd接口490访问动态调试接口540。Nexus协议转换器435将来自使用IEEENexus 5001协议标准的外部调试主机的信号转换为适于控制线程调试控制器400的调试操作的内部信号。这样，转换器435还提供了Nexus推荐寄存器的子集。允许外部调试主机经由复用器560来访问动态调试接口540和静态调试接口530。还允许外部调试主机经由接口管理器280一般接口来访问控制器130的所有内部子块200-280。
图15示出了调试机500中的一个的逻辑图。调试机500的数量是任意的，并且在设计时设定。
调试机500提供了一种灵活且用户可配置的设定多个断点或观察点、以及针对处理资源150的任意个体、池或任意组的复杂触发器场景(scenario)的方法。作为观察到出现触发器场景的结果，一个或多个调试机500还可以使能/禁能内部跟踪记录模块和静态事件过滤器600。
每个调试机500都包括EventWatchInst先进先出(FIFO)寄存器510，用于存储要由该调试机500监视的事件；以及ActionListInst FIFO寄存器515，用于存储在检测到来自EventWatchInst FIFO 510的特定事件时要执行的动作。通过动态调试接口540使用这些寄存器各自的指令对这些寄存器进行编程。每个调试机500还包括事件服务模块520，该事件服务模块520获取来自EventWatchInst和ActionListInst寄存器二者的输出，并将它们与从控制器130的各个子块输入的系统管理和分配事件进行比较。该事件服务模块随后输出以下信号中的一个或更多个DebugEnable信号450，用于使能相应处理资源150的本地调试和跟踪单元151；TraceEnable/Disable 550，用于使得静态事件过滤器600能够(或不能够)将跟踪信息输出给跟踪缓冲器440；SynEnable信号555，用于控制与当前调试机500连接在一起的其他调试机。调试机500还具有调试编程的来自动态调试接口540的输入。
图16示出了此处描述的发明的具体实施例中的调试机500的物理实现。在该实施例中，EventWatchInst FIFO 510a和ActionListInst FIFO 515a实际上被实现为在所有调试机500之间共享的两个指令寄存器文件。经由读取506和写入505控制逻辑系统来访问这些作为逻辑上独立的FIFO的统一的寄存器文件510a和515a。这种实现使得可以将针对每个调试机500的FIFO深度分别配置得适于用户的特定实现。
图17示出了调试机500的连接能力。这提供了对多个复杂逻辑触发器组合进行编程的能力。使用调试机500的SyncEnable信号555来创建这些复杂触发器组合。在所示的触发器场景中，各个触发器事件的单个序列之后必须是三个触发器序列的组合，这三个触发器序列的组合之后进而必须是动作被执行之前的另一单个触发器序列。由于提供了多个调试机500，所以可以同时评估组合触发器关系。
EventWatch指令用于捕获来自控制器130内的特定子块200-280的单个事件。控制各个调试机500的有限状态机(FSM)会查找EventWatch指令中指定的子块事件，并执行相关ActionList指令中限定的动作(例如，断点使能等)。
每个EventWatch指令都为44位宽。有两种主要类型的EventWatch指令单字和双字EventWatch指令。双字EventWatch指令为88位长，并占据EventWatchInst FIFO 510内的两个条目。下面示出了这两种类型
单字EventWatch指令格式

双字EventWatch指令格式

这两种类型的EventWatch指令的各个字段为1、EWOpcode()这是定义操作格式的3位代码。
其可以是以下代码中的任意一种

2、SubModuleID()该5位代码定义了事件所相关的子块

3、EventID()该4位代码定义了各个子块事件，如从构成控制器130的各个子块200至280通过接口410提供的各个事件内提供的EventID所描述的。
4、EventData()该32位代码定义了被监视的各个子块200至280事件，例如控制器专用控制器存储器190内的pReference字段。
图18示出了用于单字事件观察的调试机500内的数据流。
对于单字事件观察，首先将下一EventWatch指令从EventWatchInstFIFO 510加载到事件服务模块520内的两个EventWatch指令缓冲器中的第一个中。接下来，使用比较器522将SubModuleID、EventID和EventData部分与输入的控制器130事件进行比较。尽管只包括EventID和EventData，但是因为每个子块都有其自身特定的接口410，所以SubModuleID是已知的。如果可以，则随后使用OR逻辑块523将比较的结果与由其他调试机500执行的其他比较的结果进行OR。使用OR功能块的输出来控制EventWatch指令解码器524(用于对EventWatch指令内包含的EWOpcode进行解码)的输出。EventWatch指令解码器524本身的输出对ActionList指令解码器521的输出进行控制，ActionList指令解码器521对与EventWatch指令相关的ActionList指令(前面已经由ActionList缓冲器516从ActionList指令FIFO 515载入)进行解码。ActionList指令解码器521的输出可以是以下信号中的任意一种DebugEnable信号，用于控制与所关注的调试机500相关的处理资源150的本地调试和跟踪单元151；TraceEnable信号，用于使得跟踪数据可以从该点向前输出；SyncEnable信号，用于使得调试机500之间能够同步。
除了单字EventWatch指令内存在的字段以外，双字EventWatch指令还包括一组掩码，在根据EventWatch指令字段进行评估之前，根据MaskOp字段中指定的指令，将这些掩码应用于SubModuleID、EventID和EventData输入。MaskOp字段的值可以为以下任意一种

图19示出了在执行双字EventWatch指令的情况下调试机500内的数据流。与执行单字EventWatch指令的主要不同之处在于，根据以上示出的MaskOp代码类型，将双字EventWatch指令的字1的SubModuleID、EventID和EventData字段与双字EventWatch指令的字0进行AND、OR或XOR。
单字和双字EventWatch指令使用相同的ActionList指令。ActionList指令使得一个或多个调试机500能够执行复杂断点触发、跟踪使能或禁能，以及各个调试机500之间的同步，并且包括以下字段

图20示出了静态事件过滤器600的功能框图，静态事件过滤器600在将系统管理和分配事件传送至跟踪数据格式化器压缩器模块700以进行采集之前对系统管理和分配事件进行过滤。该过滤器模块600还使用来自时间接口420的32位输入对从控制器130接收的所有事件加上时间戳。
静态事件模块提供了一组用户可通过静态接口530进行编程的事件过滤器掩码611至613，事件过滤器掩码611至613用于选择是否应该采集来自特定子块200至280的特定事件。将事件过滤器掩码应用于SubModuleID、EventID和EventData字段。对于每个单比特数据，在每个事件过滤器掩码中分配了两个位。这导致为每个事件过滤器掩码分配了76位的过滤器掩码。这些两位中的每一个两位的操作含义如下

可以将用户可定义数量的事件过滤器掩码611至613分配给四个事件过滤器表610中的一个。每个事件过滤器表610都可以包含用户可定义数量的事件过滤器掩码611至613。然而，在该具体实施例中，这些表必须包含连续的过滤器掩码。这些表通过提供过滤器掩码子集而使得能够实现进一步的可编程性和对硬件资源的有效利用，这使得可以使用各个调试机500。
图21示出了特定事件过滤器掩码611至613对于特定事件过滤器掩码表610的分配。注意，在本示例中，没有使用过滤器表编号3。
图22示出了此处说明的本发明的具体实施例的跟踪数据格式化器压缩器700的功能框图。
跟踪数据格式化器压缩器模块700对跟踪数据进行压缩，以确保对片上跟踪缓冲器模块的有限能力进行最大可能的利用。尽管可以连同跟踪集中装置142或统一跟踪缓冲器143一起提供压缩模块，但是它们被设计成对来自与各个处理资源150相关的各个本地调试和跟踪单元151的指令级别或相同级别的调试和跟踪数据进行集中和压缩。由于当数据的特性既是公知的又是相似类型时对压缩进行了优化。因此该压缩器700在将从静态事件过滤器600得到的公知类型且形式类似的数据从线程调试控制器400输出到统一集中点142(如果存在的话)之前，对它们进行压缩。
跟踪数据格式化压缩器700包含事件开关710，该事件开关710将所有经过滤和加有时间戳的子块事件路由到下一个可用的两条目FIFO720(其形成了到字段基本相关器730的输入)。这些FIFO是使得能够存储单字或双字事件的两个条目。事件开关710能够从控制器130的10个子块200至280接收10个同时事件。事件开关总是向目前可用的编号最小的FIFO 720进行写入。
一旦所有FIFO 720都包含了至少一个条目，或者一旦内部定时器到期(表示当前FIFO加载周期的结束)，则将FIFO压入到字段基本相关器中。内部定时器在该10个FIFO 720中的任意一个中驻留有至少一个条目的情况下加载有固定值，并且在这些事件被读出时重新加载。
字段基本相关器730对各个固定长度的事件字段进行固定的功能操作，以使输出的字段中的零的数量最大。相对于第一FIFO，这是通过利用各个字段内的空间和时间相关性来实现的。因此第一FIFO保持不变。对于FIFO 2至10所得到的固定长度字段以及未改变的FIFO 1随后在被输入到符号内运行长度编码器750中之前被输出至另一字段相关的FIFO740。该符号内运行长度编码器750对每个输入符号进行零运行长度编码，从而得到一组可变长度的输出符号。在加载到产生最终的输出位流的符号间运行长度编码器770中之前，将它们再次存储在一组输出FIFO 760中。通过可变长度分组器780将最终的输出位流分组成适于跟踪缓冲器接口440的可变长度数据分组。
跟踪分组数据的格式依赖于物理层。在物理层没有显示分组信号开始的情况下，接收器FSM可以使用固定模式头部和分组长度字段来经过多个分组以获得对分组描绘的锁定(lock)。示例分组格式

再次参照图14，线程调试控制器500的内部调试控制模块580为控制器300内的子块200至280提供各自的子块调试使能信号和单步执行功能。当从任意一个调试机500接收到内部DebugEnable信号时，内部调试控制模块580会将指定子块设置为调试模式。用户还可以通过动态调试接口540单步执行指定的子块。
尽管已经对本发明的具体实施例进行了说明，但是应该理解，这仅是示例的方式，可以想到各种变型例。此外，本发明普遍适用于采用多核处理器的任意设备或应用，例如但并不限于移动电话或基于IP的语音(VoIP)网关。因此，该具体实施例不应被视为对由以下权利要求所确定的保护范围的限制。
权利要求
1.一种用于对多核处理器架构中的线程执行进行监测的方法，该多核处理器架构包括用于处理线程的多个互连的处理器单元，该方法包括以下步骤接收多个线程参数指示符，这些线程参数指示符表示与一个或多个线程的功能和/或标识和/或执行位置有关的一个或更多个参数；将这些线程参数指示符中的至少一个与第一多个预定标准进行比较，该第一多个预定标准中的每一个都代表了感兴趣的指示符；以及根据作为所述比较的结果而被识别为感兴趣的线程参数指示符来生成输出。
2.根据权利要求1所述的方法，其中，生成输出的所述步骤包括生成用于控制所述多个互连的处理器单元中的一个或更多个的控制信号。
3.根据权利要求2所述的方法，其中，所述互连的处理器单元还包括本地指令级调试逻辑，并且该方法还包括使得所述指令级调试逻辑能够使用所述处理器单元控制信号。
4.根据权利要求1所述的方法，其中，所述多核处理器架构还包括控制器，该控制器包括多个单独的子单元，并且其中，生成输出的所述步骤包括生成用于控制所述控制器的所述单独子单元中的一个或更多个的控制信号。
5.根据权利要求4所述的方法，其中，所述线程参数指示符由所述控制器生成。
6.根据权利要求5所述的方法，其中，所述线程参数指示符由包括在所述控制器内的所述单独子单元中的一个或更多个生成。
7.根据权利要求4所述的方法，其中，所述子单元控制信号包括使所述控制器的所述子单元中的一个或更多个暂停的信号。
8.根据权利要求7所述的方法，其中，所述子单元控制信号包括用于使所述控制器的所述子单元中的一个或更多个进行到下一操作的信号，该信号是在所述处理器单元之间管理和分配线程所需的。
9.根据权利要求1所述的方法，其中，生成输出的所述步骤包括生成包括在所述比较之后出现的多个线程参数指示符的列表的输出。
10.根据权利要求9所述的方法，其中，生成包括在所述比较之后出现的多个线程参数指示符的列表的输出的所述步骤根据所述比较的结果而开始。
11.根据权利要求9或10所述的方法，其中，所述多核处理器架构还包括多个用户可定义的线程参数指示符过滤器，并且该方法还包括以下步骤对所述多个线程参数指示符进行过滤，以定位感兴趣的指示符。
12.根据权利要求11所述的方法，其中，所述多核处理器架构还包括全局时间信号，并且该方法还包括以下步骤使用表示所述全局时间信号的代码对所述比较之后出现的多个事件加上时间戳。
13.根据权利要求12所述的方法，其中，所述多核处理器架构还包括格式化器压缩器，用于对线程参数指示符的列表进行格式化和压缩，并且该方法还包括以下步骤对从所述线程参数指示符过滤器输出的线程参数指示符的列表进行格式化和压缩。
14.根据权利要求1所述的方法，该方法还包括从所述控制器或者从所述处理器单元中的一个或更多个接收输入信号；以及根据从所述控制器或处理器单元接收到的所述输入信号来改变所述多个预定标准。
15.根据权利要求1或14所述的方法，其中，所述多核处理架构还包括用于将符合第一协议的信号转换为符合不同的第二协议的信号的协议转换器，该方法还包括从所述协议转换器接收输入信号；以及根据从协议转换器接收到的所述输入信号来改变所述多个预定标准。
16.根据以上权利要求中的任意一项所述的方法，该方法还包括以下步骤将所述事件中的至少某些与分别表示感兴趣的指示符的第二多个预定标准进行比较；以及根据作为所述第一和第二比较的结果而被识别为感兴趣的线程参数指示符来生成输出。
17.根据权利要求1或16所述的方法，其中，所述第一或第二多个预定标准包括表示特定类型的线程的特定实例的标准。
18.根据权利要求1或16中的任意一项所述的方法，其中，所述第一或第二多个预定标准包括表示所述控制器的特定子单元的标准。
19.根据权利要求17或18中的任意一项所述的方法，其中，所述第二多个预定标准包括表示第一和第二比较之间的关系的标准。
20.根据权利要求19所述的方法，其中，第一和第二比较之间的关系可以是以下的任意一种AND关系；OR关系；或者XOR关系。
21.一种用于在多核处理器架构中进行软件调试的线程级调试控制器，该多核处理器架构具有多个互连的处理器单元，每个处理器单元都提供用于处理线程的资源，所述调试控制器与所述处理器单元中的每一个进行通信，并且包括用于对所述多核处理器架构内的线程的分配和执行进行监测的监测器逻辑。
22.根据权利要求21所述的调试控制器，其中，所述多核处理器架构还包括控制器，所述控制器包括多个互连的单独子单元，并且其中，所述监测器逻辑还包括多个调试机，所述调试机中的每一个都适于针对预定标准对来自各个所述子单元的、表示所述多核处理器架构内的线程的分配和执行的多个输入信号进行监测。
23.根据权利要求22所述的调试控制器，其中，所述多核处理器架构还包括对于所述处理器单元中的每一个为本地的指令级调试监测逻辑单元，并且其中，各个调试机还适于根据特定标准的检测而向所述指令级调试监测逻辑单元中的一个或更多个提供输出控制信号。
24.根据权利要求23所述的调试控制器，该调试控制器还包括用于针对感兴趣的信号对所述多个输入信号进行过滤的多个过滤器，所述多个输入信号表示所述多核处理器架构内的线程的分配和执行，并且其中，各个调试机还适于提供过滤器控制信号，该过滤器控制信号用于控制使用所述多个过滤器中的哪一个来过滤所述多个输入信号。
25.根据权利要求24所述的调试控制器，该调试控制器还包括格式化器压缩器，用于对表示所述多核处理器架构内的线程的分配和执行的经过滤的多个输入信号进行格式化和压缩，以备输出。
26.根据权利要求22所述的调试控制器，其中，所述多个调试机中的每一个还包括存储器，该存储器用于存储准备用于检测的标准以及在所述标准中的每一个的检测时要由所述多核处理器架构来执行的动作指令的列表。
27.根据权利要求26所述的调试控制器，其中，用于存储标准的所述存储器是仅由所述线程调试控制器使用的线程调试控制器专用存储器。
28.根据权利要求26或27所述的调试控制器，其中，所述多个调试机中的每一个还包括比较器，用于将所述检测标准与表示所述多核处理器架构内的线程的分配和执行的信号进行比较。
29.根据权利要求28所述的调试控制器，其中，所述多个调试机的输出通过控制逻辑彼此互连，该控制逻辑用于对所述调试机比较器的输出之间的关系进行控制，并且其中，所述调试机输出之间的关系可以是以下的任意一种AND关系；OR关系；或者XOR关系。
30.根据权利要求29所述的调试控制器，该调试控制器还包括指令解码器，用于对与一个或更多个检测标准的特定实例的检测有关的动作指令进行解码，所述一个或更多个检测标准是在表示所述多核处理器架构内的线程的分配和执行的信号内检测的。
31.根据权利要求24所述的调试控制器，其中，所述多个过滤器包括标准掩码的列表，所述过滤器中的每一个都包括所述掩码列表内的一组连续掩码，并且其中，所述过滤器中的每一个都可以由过滤器使能信号的确定来使能。
32.根据以上权利要求中的任意一项所述的调试控制器，该调试控制器还包括协议转换器，用于将符合第一协议的来自外部调试主机的调试控制输入信号转换为适于控制所述调试控制器的符合不同的第二协议的信号。
全文摘要
本发明提供了多核架构中的调试。一种对多核处理器架构内的线程执行进行监测的方法，该多核处理器架构包括用于处理线程的多个互连的处理器单元，该方法包括接收多个线程参数指示符，这些线程参数指示符表示与一个或多个线程的功能和/或标识和/或执行位置有关的一个或更多个参数；将这些线程参数指示符中的至少一个与第一多个预定标准进行比较，该第一多个预定标准中的每一个都代表了感兴趣的指示符；以及根据作为所述比较的结果而被识别为感兴趣的线程参数指示符来生成输出。
文档编号G06F11/36GK101084488SQ200580030789
公开日2007年12月5日 申请日期2005年9月13日 优先权日2004年9月14日
发明者马克·大卫·李佩特, 阿耶温·翁 申请人:科威尔公司, 富士通株式会社