本文详细说明dmactiveAck信号的含义，以及其在SoC集成中的处理方式。阅读本篇文章前，建议先阅读第一篇文章：
https://blog.csdn.net/heyuming20062007/article/details/125594822?spm=1001.2014.3001.5502一、dmactiveAck
A new input dmactiveAck is returned from customer logic and is used to indicate when dmInner is able to accept DMI transactions (i.e. debug_clock is running and debug_reset is negated). When dmactiveAck is negated, a bus blocker returns denied for transactions to dmInner. The current version of OpenOCD is tolerant of this blocker, but other software may need to be updated.
dmactiveAck的含义如果根据官方的说明文档来看，非常难以理解。从命名规则上来看，该信号是dmactive的应答信号，但是谁应答、怎么应答以及JTAG调试如何使用该信号，都无法获得更多的有效信息。
这里先对官方的说明进行解释，dmativeAck需要用户逻辑处理，它用来指示dmInner是否有能力接受DMI传输请求（也就是说debug_clock有效，debug_reset复位释放）。dmactiveAck无效，会导致DMI发送到dmInner的传输被“拒绝”。而且该改动影响到了上位机的软件兼容性，尽管OpenOCD能够兼容该行为，但是有必要进行软件升级。
看到这里可能很多SoC设计者还是一头雾水，最大的原因在于dmactiveAck是指示dmInner的行为，而DMI接口和dmInner均在rocketchip内部，为啥还要用户逻辑来处理？这里我们先看下dmOuter的一处修改：
图中黄色部分为dmOuter，绿色部分为dmInner，改动在dmiBypass模块上，该模块为新版本添加。上一版本中，如果dmInner没有时钟或者不工作，其asource接到dmInner的bus会直接无效，dmInner不会应答asource给出的任何请求，这就很有可能将auto_asource_out_*这组接口卡死，导致JTAG调试异常。如果总线卡死，还会影响挂在该总线上的其他接口，导致其他接口也无法获得正常应答和响应。新版的改动，会在dmInner不工作或者复位有效时，通过dmOuter的bypass信号直接用dmiBypass的内部逻辑来应答JTAG下发的传输命令，这样可以有效的避免JTAG不知情dmInner的情况。那么，dmOuter的bypass信号是如何产生的？这就跟dmactiveAck相关了，通过分析dmactiveAck内部的信号去向，我们可以大致判断出该信号的功能。
二、SOC集成方法
从上图可以看出，dmactiveAck在内部影响了两个地方，其中一路就是到了dmibypass模块，成为bypass有效的条件之一。另一路是与上dmactive后，成为一个新的dmcontrol reg[0]位，通过JTAG可以读取出去。
上图提供了一种dmactiveAck的SoC处理方法，要求在debug_clock不工作时，或者debug_reset有效时，保持dmativeAck为0。在debug_clock工作，且debug_reset释放后，也就是dmInner正常工作时，将dmactive逻辑cdc处理后传送给dmOuter。这样处理后，在dmInner不工作的时候，dmativeAck保持位0，bypass会被拉高有效，防止总线无法应答DTM的命令请求。同时，在dmactive写1拉高以后，debug_clock使能打开，dmactiveAck在同步后也会晚几个cycle拉高有效，如果复位释放，此时dmInner能正确应答JTAG请求。
三、软件相关
JTAG可以通过读取dmcontrol寄存器的dmactive位，来观察dmInner是否开始工作，用户可以将dmactive写1，然后在读取该寄存器数值，如果读回来的值是0，那么表示此时dmInner没有正常工作，上位机软件需要一直读取该数值，直到该数值为1，才能通过JTAG下发命令。这也是为什么官方文档会说明OpenOCD的兼容性问题。
由于JTAG下发命令速度非常慢，以TCK为20MHz举例，其两次命令下发至少需要50ns，这还不包括JTAG的串到并的过程。JTAG两次命令下发间隔非常长，而同步使用的是debug clock，该时钟是内核的运行时钟，一般能跑到800MHz。因此，CDC的delay不会影响到dmInner应答JTAG后续下发的命令，而且上位机软件应该等待dmactive读变1后，再进行数据下发动作。