利用新的开发工具提供IC设计的可见性(二)
推荐给好友
打印
加入收藏
更新于2007-06-29 12:43:40

        芯片集成度的不断增长,使软件开发工程师必须面对芯片高度集成导致“不断减弱的可见性”。当软件开发工程师通过查看复杂芯片内部的工作来调试设计时,实时可见性工具了提供一定的帮助。本文讨论了芯片提供商提供实时可见性工具解决方案时所面临的系统复杂度、应用困难、调试带宽以及应用多样性等方面的挑战。

可见性工具箱

        由芯片供应商提供的可见性解决方法构成了下一代调试工具的体系结构,并成为开发工程师进行工作的一种途径。这些供应商目前可提供可见性工具箱,它能够解决开发工程师遇到的两种典型的问题:与算法或数据相关的问题,以及与程序流或控制相关的问题。这两个令人头痛的问题在这个工具箱中具有许多不同性能的解决方法。

1 与算法或数据相关的问题

        对于与数据相关的问题,算法是稳定的,但是行为可能不是最优的。在这种情况下,可以把一个系统软件组件看成一个传递函数并确定输入和输出之间的关系。有些情况下,开发工程师会喜欢看到数据不断从一个应用程序中流出并检查和应用程序成功相关的特定数据。

        芯片供应商用实时数据传输技术满足了这种需求。这种技术在较早的第二代工具里就出现了,但有一些供应现在才提供这种技术。它支持在开发工具和目标系统之间的双向数据传输。一些解决方法甚至提供了足够大的带宽,这种带宽可供传输应用程序通过仿真产生的视频,然后把视频显示在主机上。

        同样,评价算法性能变得更加困难。假设你正在设计一个执行视频处理的嵌入式系统,不需要DSP提供方便的外部接口来监控在处理过程中前进阶段的视频流,但是在设计算法的时候,你会希望在不同的阶段控制视频输出的质量。

        为处理这种情况,芯片供应商增加了将数据高速传入传出芯片的工具。数据的收集和输出,或者接收和使用通常永久地被加入到应用程序中,并在需要的时候开启。对于从工具向芯片的传输,片上调试逻辑必须输入数据,并且应用软件必须控制数据。从芯片到工具的传输则是相反过程。图1表明了监视各种应用所需要的数据速率。

图1。

        这种技术最先出现在TI公司提供的基于扫描的调试工具上。这个工具引入了基于扫描的仿真和音频带宽的实时数据交换。利用标准的JTAG扫描连接器,开发工程师可以与一个或多个TIDSP和(或)ARM 微处理器CPU传输调试数据,这些DSP和ARM可以位于同一芯片或者多个不同的芯片上。

        XDS560系列仿真器的介绍唤起了开发工程师对这种技术的期待。这种仿真器和TI的DSP支持一种称为高速实时数据交换的高速数据传输连接,其速度超过2Mbps。这种技术采用一个直接的仿真器―芯片连接器旁路JTAG扫描路径。别的芯片供应商最近采用了这种技术,提供了他们自己有限的版本。在当前的集成水平下,这种能力在DSP上不是非常重要,因为它不需要太多逻辑,而且不会大幅提高成本。

        实际上,开发工程师在它们的应用程序中插入调用来打开和启动输出通道,然后把感兴趣的数据存入应用程序的存储器。数据通过一个标准的通信连接传输到仿真器或者主机。通过一个驱动程序来管理的,而数据主要用来进行实时的分析或者后处理分析。开发工程师可以在程序中插入许多收集点,使得这种可见性方法灵活且廉价。

        这种方法尽管很吸引人,但有两个缺点:存储代码和数据需要存储器,并且在代码执行的时候要增加CPU时钟周期。开发工程师控制着数据缓冲的大小和收集点数目,从而控制干扰。因为代码具有确定的行为,开发工程师很容易为MIPS(每秒数百万指令)速度的影响作计划。除了这些缺点,当开发工程师知道什么数据需要收集或丢弃的时候这种方法很有用。其实它的长处在于能够用最少的片上调试硬件有效地在程序中加入许多点。

2 与程序流或控制相关的问题

        在与控制相关的问题中,程序由于设计、存储器系统行为、丢失实时界限和其它因素而不稳定。开发工程师通常也希望能在不让仪器改变系统行为的情况下跟踪这些问题

        在这种情况下,开发工程师可以选择执行历史记录,尤其是当记录时间很长时。这意味着当存储要求太多时,执行历史记录不能在芯片上存储。相反,程序执行历史记录被到导出到芯片外面的仿真器或者逻辑分析仪上的大容量缓存中。利用这些执行历史记录可以比较容易地定位常见的代码失控和最终期限问题。另外,分析帮助可以确定代码的热点(hot spot)问题和其它性能问题。

        找出稳定性问题或者错过最终期限的问题需要比较长时间的程序流记录。例如,声音合成器常常丢失数据帧,仅确定这个问题是否存在就非常困难,而确定它为什么发生则绝对是个挑战。

        沿着程序流可以找出这些问题,但需要监视高速运行的程序地址总线。显然为每一个指令输出程序计数值是不实际的。简单的计算表明带有32b程序计数器的CPU可以以四倍的指令执行速度产生一个字节的跟踪数据。实际上,必须花大力气对指令执行检察进行编码/压缩,才能降低数据容量,从而可以用合理数目的管脚导出数据。

        即使在编码和压缩以后,跟踪程序流和定时也会比数据驱动模式多产生100到1000倍的数据。如果对程序流和定时以数秒钟的间隔进行监视,那么需要导出和记录的数据量会从数M字节跃升到数G字节。

        在检测系统中的某些问题需要花费很长的时间,这样就需要利用记录下来的大量数据找出最主要的系统问题。因为输出的数据进行了深度编码,所以要利用主机系统重建目标系统正在发生的行为,并使开发工程师能够利用这些数据。

作者:Gary Swoboda,email: g-swoboda@ti.com,德州仪器




 
关于我们 | 诚邀加盟 | 客户服务 | 相关法律 | 网站地图 | 友情链接 | 服务信箱:service@eefocus.com
© 2006 与非门科技信息咨询(北京)有限公司 All Rights Reserved.