TI公司的C64XX和C66XX设备为程序可视化和设备中的数据流提供硬件支持。大部分硬件都内置在内核中，系统事件用于扩展芯片其余部分的可视性。事件还充当核心和系统之间的同步点，允许所有活动在一个事件线上"缝合在一起"。

Debug and Tooling Categories

在运行时，可以使用硬件和软件工具来调试特定问题。鉴于在系统升级开发的不同阶段可能出现不同的问题，可用的调试和工具资源分为几个类别进行描述。下表为对应的4个场景
在这里插入图片描述
虽然上表中描述的特征并非多核设备所独有，但具有多核、加速器和大量端点意味着设备内有大量活动。因此，尽可能多地使用仿真和检测功能以减轻在开发、测试和现场环境中调试实时问题地复杂性非常重要。

Trace Logs

从根本上说，必须对每个核心上运行地代码进行检测，并配置可用地硬件仿真逻辑，以生成设备执行的软件和数据流跟踪。此过程支持调试在系统开发期间或部署之后发现的任何问题。跟踪日志可以一直启用，也可以在调试会话期间启用，并且可以包括以下任何数据项：

API call log： 目标软件包含记录功能，以记录所有感兴趣的API调用。API调用可以用ID、时间戳和任何感兴趣的参数记录在内存中
Statistics log： 可以定期捕获芯片级统计信息，以通过SCR交换机结构提供随时间变化的活动图片。统计信息包括总线监视器、事件计数器和任何其他感兴趣的数据。这通常驻留在系统中，尽管在调试期间可以选择性地捕获不同的/附件的统计信息
DMA transaction log： 感兴趣的DMA传输可以触发统计数据捕获，包括计时器值、芯片寄存器和数据表。这通常驻留在系统中，尽管在调试期间可以选择性地捕获不同/附加的事件和事务。
Core trace log： 核心高级仿真触发器(AET)可以跟踪与CPU时间相关的系统事件；这通常驻留在系统中，尽管在调试期间可能跟踪不同的系统事件。此外，还可以将PC跟踪添加到跟踪日志中。如果在调试期间需要数据跟踪，则需要禁用事件跟踪
CPU或DMA可根据需要将其他事件/数据记录在日志缓冲区中。这里的用法是针对于用户

然后，可以使用历史信息来构建一个独立的测试用例，使用相同的控制和数据流，在实验室中重新一个场景以供进一步分析。

API Call Log

API Call Log是基于目标软件中的软件检测。多个logs可能与同一核心上或跨核心的时间相关。API call log由软件直接记录到设备内存中

每个API记录都将附带一个时间戳，以允许与其他事务日志进行关联。日志的内容可能有助于理解调用流程以及在执行过程中不同时间处理的信息的细节

Statistics Log

Statistics Log由定期采集的芯片数据组成，这些数据提供了设备活动的高级图片。DDR、接收加速器(RAC)和天线接口(AIF)模块都有内置的statistics寄存器来跟踪总线活动。然后，可以使用日志提供的每个时间窗口期间通过SCR交换机结构的数据流的高级视图

内存中软件记录的statistics也可以记录在日志中。除了statistics值外，话必须记录芯片时间值，以便与其他事务日志关联

系统捕获的统计数据具有一定的灵活性，因此统计数据的捕获由应用程序负责。日志所需的格式是包含一个时间值，后跟感兴趣的统计信息。多个日志是可能的，只要每个日志都有一个时间值以允许和其他日志进行关联

DMA Transaction Log

考虑到EDMA控制器在SCR交换机结构内处理的数据流量，记录某些DMA事务发生的时间非常有用。EDMA通道可配置为触发辅助DMA信道，以记录与其活动相关的统计信息：标识符和参考时间。每个感兴趣的DMA信道可以有一个事务日志，其中可以记录传输标识符、传输时间以及围绕传输的任何相关信息。事务日志的数量是灵活的，并且仅受可专用于执行记录的EDMA通道数据的限制

每个条目记录的时间值应与其他事务日志中使用的时间值相关，以允许与其他芯片活动相关

Event Log

事件日志由每个核心通过其事件跟踪功能提供。事件跟踪允许系统事件与CPU活动一起跟踪，以便可以理解与CPU内执行的处理相关的设备活动。从每个内核输出的跟踪数据可以通过模拟器或嵌入式跟踪缓冲器中的片外捕获。随着时间的推移，事件日志确实增加了对处理器状态的额外可见性，但也使用了额外的自由运行硬件，并且在已部署的系统中可能会造成功耗问题。但是，在开发过程中，事件跟踪可以与其他事务日志一起使用，以提高可见性。

事件日志允许记录PC中断、每个CPU周期的执行/暂停状态以及最多八个系统事件(用于可编程的)。为了将多个内核的事件跟踪彼此关联，并与其他事务日志关联，八个系统事件之一必须是其他日志共有的时间事件

Customer Data Log

应用软件的附加检测是可能的，并且应遵循为其他事务日志概述的指南，记录每个条目的事件戳，以允许与其他芯片活动相关。每个条目的内容可以是客户系统中任何有意义的内容

Correlation of Trave Logs

需要使用一个公共系统事件关联系统收集的多个跟踪日志，以构建芯片上程序和数据流的完整视图。所有API、statistics、DMA和data logs必须包含一个与收集日志数据的时间窗口相对应的计数值。根据日志的类型，时间值的记录可能会有所不同，但前提是计数取自同一基准，并且具有公共的周期或关系，则可以将日志合并在一起

在这里插入图片描述
时间间隔显示为整数(x或y)乘以一个公共周期p。整数倍数应该是彼此的整数倍数(例如，对于每个DMA事务日志窗口可能有四个)

对于API调用日志，每个API调用都会记录时间值本身。由于日志记录是在CPU软件控制而不是DMA控制下进行的，记录窗口标记将需要一个中断，并且不会提供任何额外的信息，因为窗口可以通过计数值除以窗口周期p来确定

Statistics log获取内存中的日志记录。每个x*p UMTS(universal mobile telecommunications system)在时间周期内对DMA断言一个事件，以捕获时间值和所有感兴趣的统计数据。此外，必须清除统计信息寄存器，以便在下一个时间窗口开始收集，因为统计信息表示当前窗口中的事件。随统计数据一起记录的时间值作为一个窗口的开始时间

DMA事务日志与API调用日志类似，记录每个事务或多个相关连锁事务的时间。时间值有DMA通道捕获，该通道与感兴趣的传输以及标识事务所需的信息相关联。与API调用日志一样，可以通过将记录的值除以p来确定事务记录所属的窗口

时间日志包含UMTS计时标记和CPU程序计数器(PC)标记。UMTS时间间隔标记用于将时间日志与其他日志关联起来，并用于区分收集窗口。时间值表示时间窗口的开始。CPU PC值被记录在每个时间事件中，可以用来指示在每个时间窗口中发生的处理活动。它可以提供关于在其他日志中收集一些信息的原因见解

客户数据日志是客户定义的，但是应该映射到上面的一个或多个定义

Trace Log Correction
在这里插入图片描述
如前几节所述，可以使用公共时间事件相互关联跟踪日志。核心事件跟踪每个事件都有一个PC值，GLOBAL_TIME是其他跟踪日志常用的标记。DMA日志记录了每个GLOBAL_EVENT(或多个)，UMTS Time记录了日志条目，显示了哪个窗口的时间。调用日志中记录的每个API调用的时间戳就是实际的时间。

Core Event Trace Correlation

在这里插入图片描述
使用核心事件跟踪，日志中的每个条目都被引用到执行跟踪功能的核心的PC值。由于每个核心可以独立于其他核心停止，因此需要使用公共时间标记将日志彼此关联起来。每个日志显示的Global_TIME是相同的，并且与用于与其他跟踪日志关联的Global_TIME相匹配。

使用上述信息，可以构建设备操作的每个时间窗口的摘要，如下表。这些信息提供了每个核心上的活动的详细信息，以及通过设备接口加载的系统和来自用户定义源的重要事件。

Time Window Trace Log Summary
在这里插入图片描述

类似的跟踪和调试功能集成在数据可视化工具(DVT，Data Visualization Tool)中，该工具适用于多核C64x+和KeyStone系列设备。

DVT有下列功能：

图形视图执行的任务在不同核心
SoC中所有核心的任务同步执行的图形视图
每个内核的CPU加载的图形视图
在外部内存中存储日志以进行脱机处理(生成图)

DVT使用与前面描述的机制类似的机制。捕获任务执行的时间信息的方法是用函数检测任务/代码块中的入口点和出口点，以捕获本地核心的当前时间

除了时间戳外，DVT还记录了一个32位的Tag字段，包含CPU ID，process ID，process type和location信息，如下所示

CPU ID：在这个例子中，CPU ID为C6670设备的core ID，取值范围为(cores) 0-3
Process ID：对于要分析的任务，可以将这个ID映射到要在DVT中显示的任务的名称字符串
Location：调试仪器的位置，任务的开始，任务的结束或任务中的中间位置

以下是在DVT中定义的标准宏，可以按照通用指南放置在代码中

void function()
{
	/*variable initializations*/
	LTEDEMO_DBG_TIME_STAMP_SWI_START(LTEDEMO_DBG_ID_SWI_SOFT_SYM);
	/*body of code*/
	LTEDEMO_DBG_TIME_STAMP_SWI_END(LTEDEMO_DBG_ID_SWI_SOFT_SYM);
}

在上面的例子中，LTEDEMO_DBG_ID_SWI_SOFT_SYM是一个ID

LTEDEMO_DBG_TIME_STAMP_SWI_START是一个宏，定义如下：

#define LTEDEMO_DBG_TIME_STAMP_SWI_START(id) LTEDEMO_DBG_TIME_STAMP(LTEDEMO_DBG_PROC_SWI,LTEDEMO_DBG_LOC_START,id)

为要检测的每个任务定义了唯一的id。可以根据宏在代码块中的位置使用不同的宏

所有这些信息(CPU ID,Process ID,Location)都是进行按位或的，以获得32位标记信息。DVT存储32位标签信息和从核心的TSCL寄存器读取相应时间。这些信息可以转储为标准的CCS DAT文件格式，工具使用该格式生成图形。

DVT捕获的时间戳基于与每个核相关的本地TSCL寄存器。因此，从每个核心收集的数据不会与其他核心同步。使用不同的进程ID的BIOS中断任务进行同步。当接收到中断时，在每个核上记录参考时间。来自给定核心的每个事件条目将根据特定的公式进行调整，以实现同步。

下面三个图对于为每个不同场景生成的图形信息

Execution Related to Cores
在这里插入图片描述
在上图中显示了3个核的活动状态，如下：

X轴是时间轴(按毫秒)
每个核心上的活动都用一种独特的颜色来表示，Core0活动以红色显示
颜色越过"0"线为红色的时间长度表示CPU处于活动状态的时间间隔，也就是说，一个任务正在核心上执行。否则，处于空闲状态

Execution Related to Tasks

在这里插入图片描述
上图显示了不同内核中SoC级别的任务活动，如下所示：

x轴以微秒为单位表示时间，y轴列出了不同的任务
考虑一个单独的任务。他会有不同的颜色，表示任务在相应CPU核心上的活动状态。例如，从t1到t2，任务是在Core 0(绿色)上执行的，从t2到t3，它同时在Core 0和Core 1上执行(黑色)，从t3到t4，它在Core1上执行(红色)
在图中还可以看到小线条，它们表示任务执行中的中断或感兴趣的点

CPU Load Graph

在这里插入图片描述
上图显示了使用线性图绘制的CPU负载：

X轴是子帧的数目。Y轴是CPU负载百分比。例如。子帧10，核心0的加载率为40%，核心1的加载率为30%，核心2的加载率为30%
每个核的CPU负载信息分别获取。在给定的MIPS(每秒百万指令)窗口内，计算核的空闲时间。激活时间由MIPS窗口减去空闲时间确定。这将给出给定核心的CPU负载信息

DVT是在系统分析仪下安装的，系统分析仪是默认的CCS

System Trace

系统跟踪是一种用于收集系统级执行数据的技术，对应用程序具有有限的或不具有侵入性。系统跟踪最初部署在C66xx代多核设备上，在前几代(C64xx)上不可用。使用System Trace，传统上由插装代码捕获的统计信息现在可以使用SoC内建的逻辑自动捕获，而无需消耗宝贵的系统资源

系统跟踪提供了捕获片上消息并将传递到外部模拟器或将其存储在片上嵌入式跟踪缓冲区的能力。通过System Trace输出的每个消息都分配了一个系统级时间戳，这支持整个系统的同步。系统跟踪提供了生成两种类型的消息能力：硬件和软件

Hardware Messages

每个支持系统跟踪的设备都有一组称为公共平台跟踪器(CP跟踪器)的统计计数器。CP跟踪器位于设备的从接口，如DDR接口。通过配置统计指标，可以统计指定时间内的访问统计信息。当该事件快到期时，测量的统计信息将自动输出到系统跟踪流中。捕获的数据可以用在应用程序执行过程中可视化这些度量，以定位处理瓶颈。这里捕获的数据与Statistics Log中提供的数据类似，但是不需要代码插装或CPU周期的消耗来捕获数据

Software Messages

软件消息是通过软件执行生成的STM消息

这些函数提供了类似printf的功能，而没有传统printf所需的侵入性。此外，每个消息都有一个系统级时间戳，这允许用户为调试目的检测它们的代码，并查看精确周期的日志。软件消息的灵活性使用户能够以多种方式可视化他们的应用程序。简单的例子可能是生成一个周期精确的多核线程执行图，或者诊断错误条件以确定消息在内核之间的何处丢失

多核编程指南(十三)---系统调试