复杂器件内部的实时可视性的实现方法

　　如果在一个系统中拥有几个处理器和外设，要开发具有成本效益、可靠的产品，尤其是在今天很短的产品开发时间的条件下，了解所有这些芯片的实时动态特性将变得非常重要。实时嵌入式系统越来越多地在多内核ASIC或系统级芯片(SoC)上实现，以利用这些器件所具有的低功耗、低成本和更高集成度的优点。

　　开发者所拥有的很多这些标准设计工具是依赖于了解老的技术产品的内部运行情况来实现的，已经不适用于这些新型的、功能强大的多功能设计了。通过集成，SoC架构在单个硅片上拥有多个处理器、存储器、外设、控制器和其它重要的子系统组件。高速内部总线连接这些不同的组件，整体的性能决定于他们之间的数据流的高效管理。瓶颈、延迟和对于像总线和存储器等共享资源的竞争这些问题，对于实时数据传输来说是致命的。为了获得最佳性能，开发者应比以前更需要了解芯片内部运行的具体情况。

　　然而，对系统组件之间的事务处理的监控不再是像以前那样连接一个逻辑分析仪或者总线分析仪那么简单了，因为很多感兴趣的信号深“埋”在芯片内部。对SoC的可视性需要一套硬件和软件相混合的装置来采集SoC本身内部的数据，并由特征描述以及关联工具提供支持，这些工具能帮助开发者分析所采集的数据。

　　回到现实情况

　　传统上，当没有逻辑分析仪可用，或者太难于设置时，开发者使用软件测试工具来获得对他们设计的可视性。他们会向目标对象增加调试代码来采集、处理和上载调试数据。例如，在进入和离开一个函数时打开和关闭某个计时器，无论是过去还是现在，对于通过软件分析器来对函数进行描述来说，这种方法都是一种的简捷方法。

　　尽管这只需要增加很少的C语言Printf指令到测试代码中，对采集的数据进行格式化，并输出到一个标准的I/O器件，但此时这些代码对代码的大小、存储器利用、缓冲器性能、时序和系统资源竞争都有很大的影响。这些缺点使得Printf只适合于测试非实时的控制代码。对于实时的或者确定性代码，例如，用在消费媒体播放器和录制设备、手持无线通信设备、电信、机器人技术或汽车上的应用，需要采用其它的对系统影响较小的技术，以避免干扰目标程序的执行或错失实时期限。

　　减少干扰

　　有很多方法可以在增加可视性的同时减少干扰。从概念上来说，对一个系统进行监测涉及到数据采集、数据缓冲、上载来自目标器件的数据、后续处理以及进行显示等。认真安排这些活动在什么时候以及哪里发生，可以将它们对系统性能的影响减到最小。减少与测试代码以及数据采集设备相关的存储器区域，可以采集到更多的数据，并增加对系统实时行为测试的精度或广度。

　　一般需要数据点几倍大小的存储空间来记录关联信息，这些关联信息用于更准确地对其进行理解。例如，除了在采集时的数据值，可能还需要标记数据相关联的变量名字，获得一个数据采集时间的时间戳，并注意当在获得时间戳时正在执行的函数等。有几种方法用于获得和组织这种关联信息，并且不需要依赖于Printf和其字符串格式化功能。通常在数据中包含Pattern，如果用某种方式来采集数据，那么可以推断出一些额外的特性，而不需要将它们包含到缓冲器中。增加可视性的一些方法包括：

　　1. 记录格式

　　如果在缓冲器中采集一个变量，则不再需要对所采集的什么变量进行标记。如果需要采集多个值，就可以创建一种记录格式，每一个值对应一个给定的位置，这样避免了不得不对采集的内容再次进行标注的情况。

　　2. 多个缓冲器

　　通过将相似的数据点分组在一起，可以简化循环缓冲管理，减少对每个数据点的采集延时。同样地，如果按照优先级来对数据采集进行隔离，那么当系统在100%的利用状态时，可能使循环缓冲器抓取到非关键信息的溢出，而不是用一个非实时的上载来弄乱了实时系统的时限要求。在任何情况下，都需要用来标记溢出的机制。并且如果缓冲器存在一些前提条件，例如需要重构的时间戳，则可能追踪丢失了多少数据。

　　3. 采样数据

　　配置硬件计数器并使其运行对系统的影响很小。无论如何，读取一个计数器并上载其值都是具有干扰性的。对计数器的记录越频繁，记录就越准确，但采集和上载的干扰就越大。在确定确实需要更准确的信息之前，保持较低的记录频率。例如，一个记录当前哪个函数在执行的周期性分析器能确保得到一个非常准确的代码使用百分比情况。这样的分析器仅收集了在每个函数调用的记录期间所采集的信息的一部分，于是干扰很小。也可以按低优先级任务来对数据点采样，尽管这样可能使得结果产生一些偏差。

　　4. 确定性的数据

　　如果数据采样获取的频率固定的话，不必要加入一个时间戳。作为一种替代选择，如果数据必须通过一组连续的运算块，只需记录数据值和时间戳，因为可以从时间戳的次序确定实际的程序块。如果获取了几个值，可能更有效率，以确保数据流能通过一系列的程序块，此时只需记录函数和时间戳，并采用数据记录格式。

　　5. 动态/智能记录

　　通常只在需要时采集数据(换言之，在对某些信息感兴趣的情况下)，这样减少了数据采集产生的影响。利用几个调试标记，可以缩小采集的范围。这可以通过设置一个特定的标记来实现，这个标记只有在感兴趣的情况下才有效，通过这种方法，不会因为上载不需要的信息使系统过载。这也减少了捕获数据过程的开销，节约缓冲器空间。设置或检查一个标记只需要一个或者两个处理器周期，因此这是非常有用的方法，即使是对于基于硬件的计数器亦是如此。

　　6. 块状记录

　　在某些情况下，在不影响执行时(如没有实时运算时)有可能可以暂停对象。此时可以通过在能安全暂停的情况下触发一次暂停来“避免”缓冲期上载开销，然后在系统暂停的时候再对缓冲器上载。

　　7. 按块上载

　　如果任务比较空闲，可以在系统没有完全利用时用来上载缓冲器。尽管这不会减少上载开销，但却可以将上载的影响转移到一个对系统性能影响更小的时段。

　　8. RTOS监测

　　对于更复杂的监测，可以在实时 *** 作系统上找到支持。很多 *** 作系统具有内置的机制和库，能支持片上监测硬件，即易于配置又为管理循环缓冲器和向外发送数据流需要的基础架构提供基本代码，并提供用于自监测的Hook函数。通过对记录过程抽象化以及卸载数据，可以快速地对监测的对象、监测的方式、监测的频率、获取数据的位置以及卸载方式等进行重新配置。在创建自己的基础来测试代码之前，应首先检查RTOS提供的内容。

　　9. 避免访问存储器和其它系统资源

　　只有在硬件机制不足的情况下，才应该用软件手段作为补充，例如当需要非常大的缓冲器或者当有限的处理降低了整体的干扰时。理想的情况是，如果在不使用系统总线或存储器的情况下监测系统总线或存储器，将能得到更准确的结果。如果将采集的数据量控制到最小，就可以避免使用存储器中的缓冲器，只是通过JTAG或总线直接发送。

　　10. 连续采集

　　在过程中监测如果需要采集大量的数据，可以考虑连续采集。注意，因为在每次运行时会采集到不同的信息，将无法对结果进行关联，因为时间戳包含不同的测试延时。在考虑从什么地方开始发现问题时，这种方法最好。因为这样能降低概率，也能降低监测的等级。

　　11. 模块

　　如果通过JTAG或总线发送数据，则可以在目标和主机之间放置一个处理模块来处理时间戳的产生和有限的数据处理。通过将时间戳的工作卸载到该模块，可以释放测试总线的带宽，用来发送更多的信息。模块也是实现完全无干扰监测的非常有效的方法。例如，模块可以监测系统总线，监测测试总线上某个特定的存储器地址范围，或使用直接存储器访问(DMA)来触发一次准实时的数据块获取。

　　给定不同实时应用的特性，将希望测试不同的采集方案，来确定哪些组合能实现最小的干扰的最高可视性。例如，如果有多余的存储器，那么可以增加缓冲器大小。这取决于采集什么样的数据及采集多少数据。