原创 JTAG协议学习笔记--远程边界扫描测试的实现

    在最新一期EDNChina上看到了JTAG Technologies的一篇文章，详细介绍了远程边界扫描测试（Remote boundary-scan tests）的实现方法。 riple 
   

    这篇文章给了我以下几点启发： riple
1. 远程JTAG是可行的。 riple

2. 远程JTAG可以通过复用产品电路板上的通讯接口，以增加很少的成本为代价添加到现有的产品上。 riple

3. 通过差错控制机制，远程JTAG可以保证测试数据的完整性。 riple

4. 在硬件上加以巧妙设计，可以把用于直连JTAG的测试软件应用到远程JTAG上，减少了软件的改动，操作方式的变化也很小。 riple

5. 在上位机端，以软件方式在扫描链中增加“虚拟单元”，可以用来补偿远程JTAG带来的延时。 riple

6. 在上位机端，以硬件方式在扫描链中增加FIFO，可以用来连缀真正的测试数据，保证JTAG数据的连续性。 riple

7. 采用1:n的方式，在上位机添加硬件，可以有效地减少下位机成本的增长。 riple

8. 采用回环测试可以确定通讯链路的延迟，从而确定插入“虚拟单元”的个数和FIFO计数器的初始值。 riple

9. 回环测试配合FIFO，可以虚拟出长度可动态调整的测试链，动态地补偿不同的延时。 riple

10. 下位机端通过控制TCK的有无，实现扫描时间的暂停，可以不考虑延时补偿和数据缓存问题。 riple

11. 上位机端，采用“虚拟单元”实现延时补偿功能，是为了符合JTAG协议在上位机端对时序的要求；采用FIFO实现数据缓存功能，既是为了符合JTAG协议对数据连续性的要求，也是最小化软件改动的措施。 riple

    这篇文章很清晰地讲解了直连JTAG中延迟的来源，以及由此带来的TCK频率和JTAG电缆长度的定量关系。通过这段图文并茂的原理分析，我终于想明白了JTAG电缆长度不能过长的原因：不仅是信号强度会变弱，更主要的原因在于过长的电缆不能满足特定TCK频率下，JTAG协议对于延迟的要求。所以，要延长JTAG电缆的长度，单纯增加信号的驱动强度是不够的，还需要人为添加“虚拟单元”补偿延迟或者调整测试软件补偿延迟才可以。 riple 
    记得以前实验室有一根超长JTAG电缆，就是采用差分信号增强信号的抗干扰能力的，但是没有考虑补偿延迟的问题。看来那根电缆也不是“要多长都可以”的 。 需要软件配合才能做得更长。 riple

    在远程JTAG中，需要解决的还不止是“长”电缆的固定延迟问题，还有一个数据不连续问题。由于JTAG协议要求扫描链是连续的（否则就不成“链”了），从而可以简单地进行同步操作（这也是为什么用PC机并口进行JTAG操作时CPU会被占满的原因）；而远程JTAG在连续的JTAG链路中插入了本质上是不连续的远程协议（TCP或者是USB），不但引入了延迟，更破坏了数据的连续性。所以简单地在扫描测试软件中加入延迟补偿并不能解决数据不连续问题，还需要把不连续的数据连缀起来，形成连续的数据链，这就是这篇文章中用到FIFO的原因。这样一来，测试软件在没有获得连续的数据之前对“虚拟单元”进行扫描（相当于空等），同时FIFO把接收到的数据包按顺序存储下来，当FIFO中有了足够的连续数据后，测试软件才开始真正的数据扫描。 riple 
    上述操作应该也可以在软件中实现，只要实现延迟补偿和数据缓存的功能就可以了。 riple

    这样看来，Altera的Ethernet Blaster和USB Blaster也并不神秘啊。 riple

    通过写这篇日志，深刻体会了Avan说的“写作是最有效的学习方式”这句话。写这篇日志，我对原文的个别段落重读了近10遍，对于一些关键操作产生了多个层次的认识。真是越写越难，越写越有趣啊。 riple