当前位置:主页 > 技术支持 > 芯片解密 >

技术支持 / TECHNOLOGY
技术案例 / CASE

基于SoC系统的设计与调试规划

  调试复杂电子系统从来就不是一项简单的工作,但至少是可以实现的,您要找到问题的所在。采用您最相信的“示波器”,通过模拟电路到数字转换,您可以追溯到问题的源头。然后,编写测试小程序,检查驱动和外设,增加一些逻辑探针,再回到外设控制器和CPU总线上,从而最终解决问题。当然,这需要利用别人的一些代码。
  而芯片系统(SoC)集成从根本上改变了这一切。今天,微处理器、总线、外设控制器以及大部分存储器和模拟电路都被包封在一个封装中。它可以是ASSP、高级微控制器、FPGA,或者您自己设计的ASIC。不论SoC是什么,事实上是,除非芯片设计团队愿意帮助您,否则,您不可能深入地了解芯片内部。
  在嵌入式CPU中调试硬件,为您提供断点和准实时跟踪等传统调试功能,从而帮助您完成调试工作。但是,对于他们自己,调试内核也只是给出了您系统的CPU外观视图。如果不能针对系统总体状态来更广泛的定义某一事件,那么,当事件发生后,您可能需要编写诊断短代码,使系统暂时停止工作,将相应的数据写回CPU。这一过程最好的情况是仅仅耗费了您的时间,而最差的情况是,耗费了时间却不一定能解决问题,效率非常低。
  硅片知识产权(IP)供应商提供越来越精细的SoC仪表调试手段,从而解决了这一难题。但是,当今的产品是个性化的,而不是标准化的。系统设计人员需要在芯片设计早期阶段独立作出选择,而另一公司的其他团队则根据产品能否及时面市、管芯面积等来确定自己的目标,并不关心能否方便的进行系统调试。而芯片设计人员、软件开发人员和系统设计人员等参与者还是有一个共同点——互相协作,在系统级找到问题所在。
  从一开始就做好规划
  实际上早已决定了您是否能够成功的找到系统中的问题——两年前,在您目前正在使用的SoC的开发阶段。Brad Quinton是泰克公司嵌入式验证的首席规划师,他认为在芯片设计早期阶段进行规划非常关键,不仅仅是能够充分探查芯片,而且还涉及到采用什么样的调试硬件。然而,这并不常见。
  芯片设计团队的确在测试结构中开展了前端工作,但却是出于其他原因。芯片中置入了测试设计和内置自测试硬件来支持IC测试。但是,这些资源并不是用于调试,一般只提供很少的诊断信息。芯片设计人员会专门针对硅片开发团队而内置工具,但是,这些工具可能只有内部文档,硅片一旦发布后,就会禁用这些工具。高速串行端口上会有边界扫描,甚至是非常复杂的仪表功能,必须在系统中对其进行调整。但是,这些手段是为了在电路板级建立并验证连接能力,而不是用于系统调试。
  Quinton质疑,虽然这些结构非常有用,但是芯片设计人员会有更多的问题。Quinton认为,“从系统级进行考虑。关键接口、高级状态机在哪里?通过掌握哪些信息您能够知道哪一子系统正在工作?”
  这些思考导致某些IP供应商开发了一类新模块:在SoC中设计实现仪表和控制器,不仅供设计芯片的IC团队使用,而且还有使用它的系统设计团队,如图1所示。
图1 片内调试电路本身会成为实际的设计
  从不同的方向开始工作,两类供应商验证了这一发展趋势。ARM扩展了其CPU内核调试内核CoreSight,涵盖了多核SoC的大部分工作,而现在是泰克一部分的Quinton Veridae从仪表模块开始,集中开发触发器/踪迹控制器,包括了CPU调试内核。这两种方法对于系统调试人员都非常宝贵。这都为在SoC基础上扩展可探查性提供了重要的理念。
  数据源
  虽然您想立即开始在系统结构图中加入各种各样的数据采集节点,而Quinton首先提出了一些基本问题。谁会使用调试功能:应用编程人员、模拟设计人员,还是机械工程师?他们会在哪一抽象等级上来定义事件;功能调用、信噪比、扭矩读数?这些用户会怎样做:确定他们的代码热点、找到瞬变噪声,或者知道驱动杆为什么失效?只有您理解了问题所在,才能够找到解决问题的数据。
  Quinton认为,现在的技巧是确定在哪里收集数据。很明显,首先是在源头采集所有数据:A/D转换器(ADC)输出、状态寄存器、网络接口等。当然,您希望尽可能获得接近源头的一些信息,例如,受控物理器件的状态等。
  但是,在其他情况下,事先考虑好在哪里采集数据可以减少测量开销,以及后分析所需要的数据量。Quinton建议,“找到关键地方来观察系统。在一点上所通过的系统状态量会让人感到惊讶:例如,CPU与系统总线的接口。”
  在哪里对数据进行采样也取决于用户所希望的抽象级。例如,可能是通过PCI Express (PCIe)总线的系统交换信息等。探查串化器/解串器(SERDES)和PCIe控制器,使您能够获得底层协议层工作的详细信息,这对于总线接口调试非常重要。但是,如果您希望总线接口能够正常工作,观察信息流,那么,您最好监视主存储器中的缓冲,而忽略总线控制器。
  问题的相对性
  一旦找到了您需要的数据,确定了要在系统中的哪些地方来提取这些数据,那么,您需要收集数据,知道数据与时间的相关性,找到触发模式,采集您希望保存的数据,从系统中提取出这些数据,送入分析工具中。在分立系统中,这一过程相对简单:所有工作都可以回到逻辑分析仪中完成,分析仪提供统一时间基础。在基于SoC的系统中,您可能希望把所有数据送回SoC的中心模块中,如图2所示。好消息是,泰克和ARM的IP简化了这一过程。
图2 完整的片内调试系统结合了传统的CPU内核调试和数据采集站以及信息路由,提供将数据从芯片中输出的方法。
  但是,使用IP带来了新问题。中心模块和电路板另一侧芯片之间的延时会有十几个时钟周期。即使在芯片内部,也会有数十个时钟域,当您跨过时钟域边界时,延时会增加很多CPU周期。您怎样知道两路数据是同时的呢?
  如果您要开发自己的调试工具,那么,这会很难。您可以估算数据采集模块和中心控制器之间的传播延时,然后,对数据流进行后处理,使其对齐。但是,这一方法难以解决时钟域交叉的非确定性延时