【IC测试】整理下最近芯片测试过程中遇到的问题

验证背景：

此次板级验证的IC是基于ARM-A9双核架构，通过DStream调试器的JTAG接口调试该SoC。
由于该芯片是流片回来的初次测试，主要目的以“能连接、能访问、能使用”为出发点，去测试芯片的可用性。此次测试过程中先后遇到了3个问题，我将根据问题现象、问题排查过程、验证猜想，这种思路整理问题及原因。

第一个问题现象：双核CPU在用JTAG扫描的时候只能扫到第一个核，第二个核和剩余CoreSight组件在读取ComponentID及PeriphID时失败。

这是第一张图，扫出来了第一个核的组件ID

这是第二张图，当开始扫描rom_table中指向的CoreSight其他组件时，开始报错，并一直failed。（如图所指0x80112FF0是Core1_DBG的ComponentID4的address，0x80113FF0是Core1_PMU的ComponentID4的address）。

排查步骤1（确定大致范围）

因为之前在FPGA原型验证的时候遇到过CoreSight的组件扫描不到的问题，所以知道当第一个组件ID读取失败时，总线会挂死。当时在EDA上做仿真才知道挂死的原因有以下几种：

1. Core1处于复位状态；
2. Core1处于无时钟状态；
3. 其余CoreSight组件在rom_table中的rom_entry的bit0为0，处于未使能状态；
4. （不确定点）不确定以前Core1是怎么启动的，不知道是在Core0启动后，执行了ROM里的程序才将Core1的复位拉起来并给出时钟，还是说设计中会有逻辑等待Core0启动后检测到某个触发信号自动将Core1的复位拉起并使能时钟门控。

排查步骤2（缩小范围）

有了第一步中的3种主要原因，我们便开始缩小范围：

1. 检查Core1是否处于复位状态；
2. 检查Core1是否处于无时钟状态；
3. 检查其余CoreSight组件是否在rom_tab