对基于SoC系统设计的探查

即使是自动完成，仍然会有变化。如果把在系统中不同部分同时发生的小事件作为触发器，只定义这类事件——例如，ADC输出等于0，而一个CPU内核进入某一中断服务例程，那么会出现什么情况?如果事件不仅仅涉及到不同的地方，而且还有不同的抽象级——例如，串行端口的接收眼图闭上后，出现了堆栈上溢，又会怎样呢?Quinton把这类跨域分配事件触发描述为系统触发的“圣杯”。正如这一隐喻所示，很难找到合适的解决方案。但是，采集了足够的数据，经过认真思考，构建能够采集这类复杂事件的本地触发器，通常能够实现这些解决方案。

从芯片到系统

我们详细讨论了芯片级调试功能，它比简单的CPU调试内核有很大的进步。对于开发自己的SoC的系统设计人员，这些数据非常有用。但是，其他人会怎样，谁会使用他人的芯片设计?这里的很多理念仍然能发挥作用。

其中最首要的是重视提前做好规划：确定用户及其使用环境，制定测试策略，回答这些用户可能提出的问题，规划数据采集来支持这一策略。最大的不同是，芯片设计人员会提出这些问题，然后，在他们的SoC中开发结构。系统设计人员也会提出问题，然后，通过SoC供应商所提供的工具以及他们的支持来解答问题。

相应的，系统设计团队至少会向他们的SoC供应商提出三类很难的问题。第一，芯片供应商会提供调试工作台——例如，Tektronix或者ARM主软件包，来控制SoC的调试硬件吗?主软件包能够很好的适应您现有的系统调试环境吗?

第二，硬件实际接触SoC中的哪一点?您只获得了一个CPU内核的触发/跟踪功能，或者芯片提供CPU、加速器、总线和外设控制器的扩展采集，跟踪以及交叉触发功能吗?第三，调试子系统会提供哪些方法来观察系统中其他芯片和器件的状态?

这些问题的答案会定义系统团队连接哪类外部测量设备工作台，在哪些工作台上能够实现他们的系统调试计划。在这么多的系统工程中，关键是尽早开始对调试进行规划——在工程的体系结构设计阶段。没有足够的数据呈现，就开始调试基于SoC的系统，这种场景很快就会很难维持下去。