标签: JTAG

System-on-Chip (SoC) devices are increasing in size and becoming more complex day-by-day, with ever-increasing numbers of intellectual property (IP) blocks combined with humongous quantities of custom ("secret sauce") functionality. Not surprisingly, designing and verifying these devices is becoming ever-more problematic.   Traditional solutions include JTAG, IP vendor offerings, and in-house tools and technologies. JTAG has the advantage of being universal, but it is a decades old technology that runs at an extremely low-level. Furthermore, on-chip JTAG is pretty dumb -- all of the intelligence resides in external tools running on workstations, which means it's of use in the lab, but less so after the SoC has been deployed to the field.   IP Vendors (e.g., ARM and Imagination) have some very powerful solutions that are great in their own domain, but typically cannot span the functionality of the entire SoC. Meanwhile, mega-companies (e.g., Apple and Qualcomm) have typically made use of internally-developed tools, but the complexity of the devices they are designing is increasing at such a rate that these companies are increasingly licensing more-sophisticated offerings from external vendors while freeing up their own engineers to focus on differentiating and adding value to their products.   All of which brings us to the folks at UltraSoC , whose vendor-neutral modules operate non-intrusively across the whole SoC, reporting rich information in real-time from both hardware and software. As a rough ballpark, the folks at UltraSoc tell me that -- based on their existing customer experiences -- on an 18-month development project, using UltraSoC's solutions for debug and verification can accelerate time-to-revenue by two months (this also means saving two months of development costs).   Following deployment to the field, an UltraSoC-equipped SoC can unobtrusively monitor its own operation, thereby allowing you to refine your products on the basis of data acquired in actual, real-life usage. You can gather trend data to pre-empt in-field malfunctions; and you can access key status information in the event of a failure incident to facilitate the forensics required for root cause analysis (RCA).   Now, UltraSoC has extended its monitoring and analytics capabilities with Bare Metal Security that provides the security functionality demanded by products ranging from Internet of Things (IoT) devices to embedded systems to enterprise systems.   Conventional security tends to live at the operating system (OS) level. By comparison, Bare Metal Security features are implemented as hardware running below the OS; these features are nonintrusive and remain robust and vigilant, even if the system’s conventional security measures are compromised.   (Source: UltraSoC) As the folks at UltraSoC say: Bare Metal Security functionality uses the UltraSoC monitors to watch for unexpected behaviors such as suspicious memory accesses or processor activity, at hardware speed and non-intrusively, with minimal silicon overhead. Because it is an orthogonal on-chip hardware infrastructure independent of the main system functionality and software, there is no negative impact on system performance and it is very difficult for an attacker to subvert or tamper with. By offering resource-efficient and highly effective protection against malicious attack and malfunction, the UltraSoC on-chip analytics and monitoring system provides both development support and functionality enhancement from the same on-chip blocks. Teams which are already using UltraSoC to accelerate the debug, silicon validation and bring-up process can therefore utilize the same infrastructure for security processing; while designers who need Bare Metal Security features get the development benefits of a vendor independent on-chip debug infrastructure at zero additional cost. I, for one, am becoming increasingly concerned about security (or the lack thereof) in our electronic systems. Having the ability to embed powerful, intelligent, orthogonal security directly into the hardware seems to me to be a very good way to go, and I will be watching the progress of UltraSoC's Bare Metal Security products with great interest.

Do we now need a solution better than JTAG? Hard real-time control software is increasingly common in terms of the number of different items in everyday life that use it. Many items that offer better safety, with equivalent or better energy efficiency, are now possible. But most of the people I know who have recently purchased a new piece of electronics, or a vehicle, or some other device have found at least one bug! It is becoming increasingly clear that, without help, JTAG-based ICE (in-circuit emulation) is not up to par on many of today's CPUs. Furthermore, JTAG testing and debugging does not allow one to test all the "at speed problems" one encounters in research and development or in production. This is forcing JTAG test escapes to be found by other means. The CAN bus (for controller area network) came out around the same time as JTAG, and both took time to gain momentum. This was when embedded Flash memory sizes were only a few hundred kilobytes in size. By comparison, modern automobiles and control systems use real-time stacks on 100mbp/sec Ethernet, and 1GHz (or higher) processors with many gigabytes of Flash memory, but they often still use only JTAG for debugging, Flash Loading (often only the boot loader), and partial production test. It is left for each chip maker and OS/OEM to come up with a full Flash load/debug solution on its own. Be it an MCU, an FPGA, or some other device, many are limited in one way or another by limitations in JTAG technology. Isn't it time we come up with a readily affordable, industry-wide solution? The thing is that bad debug and test capability can have a very real human cost. Allow me to relate a story that will illustrate my point... Back in the 90s I worked for an aerospace company designing police, fire, medevac, and special mission radios for helicopters and aircraft. We had one Intel ICE for the 8051. The ICE used the old "Bond Out" chip ICE technology. I was not there when the original code was developed and they first attempted to use this ICE. It was bad enough that we were out in a lab in the middle of the desert with a bad ICE. When we were not dealing with scorpions, poisonous centipedes, black widows, or the occasional side-winder that would craw into our lab (or up through the shower drain in the middle of getting ready for work) we had to find other, less venomous, but equally vexing, "bugs" by the time- honoured tradition of "Burn and Learn." What this meant was that we would "burn" a UV erasable version of the processor and then "learn" whether or not it would then burn out the transmitter. Dealing with ever-so-great equipment and angry customers that could fly in at any minute to lodge a complaint was never dull. It was also interesting having to handle walking, crawling poisonous bugs while we were frantically wrestling our own black widow's nest of a C compiler riddled with bugs coupled with a bad ICE. The ICE was so complicated to set up and get working—and the power in the lab went out so often—that it was damn near impossible to get it all running right before we lost power along with the working configuration. It was a race against time reminiscent of a "Dr. Who" episode. This was in the days of DOS, and there was no such thing as an uninterruptable power supply (UPS) for a PC and ICE, let alone a Flash memory in which to save the ICE configuration. This system had actually been designed to use a VT-100 terminal as the interface! Sadly, it had been made for a large corporation that could have easily afforded a plant-wide UPS. Furthermore, the company executives had all been fined for billing all kinds of executive perks to the government, so there was no money for a better ICE when one finally came out. William Murray Electrical Engineer

Is a solution better than JTAG now necessary? Hard real-time control software is increasingly common in terms of the number of different items in everyday life that use it. Many items that offer better safety, with equivalent or better energy efficiency, are now possible. But most of the people I know who have recently purchased a new piece of electronics, or a vehicle, or some other device have found at least one bug! It is becoming increasingly clear that, without help, JTAG-based ICE (in-circuit emulation) is not up to par on many of today's CPUs. Furthermore, JTAG testing and debugging does not allow one to test all the "at speed problems" one encounters in research and development or in production. This is forcing JTAG test escapes to be found by other means. The CAN bus (for controller area network) came out around the same time as JTAG, and both took time to gain momentum. This was when embedded Flash memory sizes were only a few hundred kilobytes in size. By comparison, modern automobiles and control systems use real-time stacks on 100mbp/sec Ethernet, and 1GHz (or higher) processors with many gigabytes of Flash memory, but they often still use only JTAG for debugging, Flash Loading (often only the boot loader), and partial production test. It is left for each chip maker and OS/OEM to come up with a full Flash load/debug solution on its own. Be it an MCU, an FPGA, or some other device, many are limited in one way or another by limitations in JTAG technology. Isn't it time we come up with a readily affordable, industry-wide solution? The thing is that bad debug and test capability can have a very real human cost. Allow me to relate a story that will illustrate my point... Back in the 90s I worked for an aerospace company designing police, fire, medevac, and special mission radios for helicopters and aircraft. We had one Intel ICE for the 8051. The ICE used the old "Bond Out" chip ICE technology. I was not there when the original code was developed and they first attempted to use this ICE. It was bad enough that we were out in a lab in the middle of the desert with a bad ICE. When we were not dealing with scorpions, poisonous centipedes, black widows, or the occasional side-winder that would craw into our lab (or up through the shower drain in the middle of getting ready for work) we had to find other, less venomous, but equally vexing, "bugs" by the time- honoured tradition of "Burn and Learn." What this meant was that we would "burn" a UV erasable version of the processor and then "learn" whether or not it would then burn out the transmitter. Dealing with ever-so-great equipment and angry customers that could fly in at any minute to lodge a complaint was never dull. It was also interesting having to handle walking, crawling poisonous bugs while we were frantically wrestling our own black widow's nest of a C compiler riddled with bugs coupled with a bad ICE. The ICE was so complicated to set up and get working—and the power in the lab went out so often—that it was damn near impossible to get it all running right before we lost power along with the working configuration. It was a race against time reminiscent of a "Dr. Who" episode. This was in the days of DOS, and there was no such thing as an uninterruptable power supply (UPS) for a PC and ICE, let alone a Flash memory in which to save the ICE configuration. This system had actually been designed to use a VT-100 terminal as the interface! Sadly, it had been made for a large corporation that could have easily afforded a plant-wide UPS. Furthermore, the company executives had all been fined for billing all kinds of executive perks to the government, so there was no money for a better ICE when one finally came out. William Murray Electrical Engineer  

       这篇文章主要是还原一个“事故”现场，具体原因有待进一步分析。           遇难芯片： 1片Xilinx FPGA XC5VSX95T、1片PROM XCF32P、2片PROM XCF08P、一块盗版Xilinx Platform Cable USB II。           事故起因： 如下图，左边板子的硬件是我做的，右边的硬件不是（但以前的整个系统是我调的）。我的工作就是将这两款板子的各个功能接口调试完成并将实验平台搭起来，剩下的工作就是动动嘴皮子就行了。之前，我一直在调试右边板子上的超高速AD，有一个通道有些误码（这个以后再谈）。之后，我画的板子回来了，便随心所欲的挨个调试。为了方便描述，左边板称为A板，右边板称为B板。        A板                                                             B板          但是，手上只有一个我以前自己买的盗版下载线（官方下载线退还了），如下图。   盗版下载线                                                 方下载线          事故之前还有个细节，A板刚送来时有隔离磁珠没有焊上，我挨个焊上测量电压均正常，唯独1.2V的磁珠左端正常，而右端只有800mV。当时觉得磁珠碍事，便换了0Ω电阻，但测量还是一样的情况。观察之后发现800mV出现的原因是我把示波器的地线接在了电源地上，而0Ω右端都是与板子右边那片数字区域相连（电源地和数字、模拟地之间也通过0Ω连接，单点接地设计）。因此，将电源地换成数字地，显示的就是1.2V了。这之后A、B两块板子单独找FPGA都是正常的。           事故过程： 正当我认为都没问题，觉得其他电源都是磁珠，就1.2V是0Ω电阻，不满意便换回了磁珠。这里列出磁珠选用型号：PB2012-800/3A（100M阻抗80Ω、最大过流3A），ZRX图如下。        准备再次上电调试时，不幸的事情发生了（我只是单独上电，绝没有同时上点的可能）打开连接A板子的电源，显示的电流变大了将近200mA（输入24V）左右。这意味着肯定有东西短路了，计算机上FPGA也找不到了。马上关掉电源，上手去摸一下各个IC的温度，发现A板的PROM XCF08P已经发烫，但FPGA没有温度，其他也无异常，情况还不算遭。仔细看了下当时的电路，下载线连接如下图            虽然只有一个盗版下载线，但是刚好调试台下面有两**立电源，而我做的板子有14Pin接口，另外一块则刚好是6Pin接口。于是乎就想当然的将这两块板子同时挂在了下载线上。          现在记不清在未换1.2V磁珠上电测试之前，正常状况下这样是否连接过，隐约有这个印象是连过的。换了磁珠再上电就出了状况，这是我的第一反应。因为担心未上电的B板也出问题，我又开了下B板的电源，同样也是增加了200mA左右（B板12V输入，具体电流增加多少没太留意，A板正常应该是110mA，B板插上AD正常应该是500mA左右）。这下情况不妙了，B板的PROM XCF08P一样很烫，背面的PROM XCF32P也有点温度但不烫，FPGA一样无明显的温度变化，其他IC，包括电源都无异常。再看看下载线，还是绿灯，电源正常，但是坏的可能性已经很大了，我以前也用坏过盗版下载线，不过没有烧过配置芯片。           事故排查： 心急之下，第一反应便是还原之前的正常状态，因为怀疑是磁珠的问题，便把A板1.2V的电源磁珠换成了0Ω电阻。换了A板的PROM XCF08P，电源电流正常，但是这次单独连接下载线就找不到FPGA了，临时找到别的地方一个盗版下载线连上正常。心里暗自庆幸，希望B板也只是PROM烧了问题不算大。于是乎也换了B板的PROM XCF08P，因为它的温度太热了。撤下AD板再次上电，电流是降了下来，几乎回到了正常值的范围300mA左右（AD板加上500mA），但是依然找不到FPGA，同时我也用示波器彻底检查了下各个电压值，均无异常。那么，现在要做的就是检查B板的菊花链，主要保证FPGA未坏。取下08P和32P，飞线接出FPGA TDO到JTAG TDO，依然找不到FPGA，检查了N多遍（因为这个板子的下载线是用串口头引出的，起初总是怀疑是不是连线有问题），还是不找不到。为了确定FPGA的JTAG是否被打坏，除了看官方资料，调整了配置模式M =101为JTAG模式外，还拿来了一个正常的小开发板挨个对比TCK、TDI、TMS、TDO。这下算是确认了。如下图所示。   正确的TCK   正确的TDI   正确的TMS   正确的TDO          而B板JTAG的TCK、TDI、TMS都有信号，并与正确信号类似只是信号电平有些出入，唯独TDO在示波器上触发不到任何边沿信号。FPGA的TDO无输出？这我想国内任何人都无能为力，只有更换芯片了。第二天换好的了FPGA、两块PROM的B板送过来，再次上电只找到了FPGA，ID还是错误的。这下是虚惊了一身冷汗，其实这个问题我碰到过不止一次，就是虚焊而已，以前是TQFP的FPGA虚焊，这次就是PROM虚焊。FPGA虚焊很可能就想以前那样找不到任何东西，PROM虚焊则可能找到些异常的东东，补焊一遍就解决了。这并不一定是焊工不行，在搬运或者移动过程中，一些颠簸或者摩擦振动、残渣都有可能引起虚焊，航空测试就有专门的振动试验，听别人说有的板子一上测试台连有些航空导线都被振的七零八乱的，这又和安装、接插件、设计结构以及工艺有关了。           事故分析： 这次事故主要原因还是在于我的操作不规范，如果规规矩矩借个下载线分开调试，可能就不会有这么多麻烦事。但是，我还是有兴趣在分析下这个内藏玄机的事件。我是这样看的，我的目的只是换了磁珠，上A板电验证之前的正常状况而已，B板根本未上电，只是A、B两板由盗版下载线的转接头有连接关系。A板上电坏了XCF08P，Spartan6 XC6SLX25正常，而B板上不光是坏了XCF08P、XCF32P、最值钱的Xilinx FPGA XC5VSX95T的TDO（或者JTAG）却坏了（这也可能是我第二次上电打坏的，但B板电源依然完好）。这便是我觉得悲剧的地方，95T躺着都中*。我觉得有些差异，V5是真脆弱还是有别的原因。我画的FPGA板子在JTAG的供电问题上我都是3.3V和2.5V二选一，一般都是使用2.5V，而B板只能接3.3V，这是我调试忽略地方。A、B板菊花链（JTAG链路）如下图所示。   A板菊花链示意图   B板菊花链示意图   转接板连接图          虽然A、B板的JTAG电源不同，但只是上了A板电源的电，B板相当于负载。          有一种解释是B板3.3V负载较多，而A板2.5V只有PROM和FPGA的VCCAUX。由于同根下载线VREF和GND同时连接A、B板，负载变小。导致电源输出电流增加，同时A板菊花链TDO与B板菊花链的TDO共同连接在JTAG的TDO上，当A板响应时，TDO输出信号，灌进B板的TDO（V5）引脚，置其损坏。但两板的电源没有丝毫损坏，而且A板的FPGA还完好无损。也就是说，主要原因出在A板菊花链的最后一级，但又是什么原因造成最后一集的PROM被打坏的呢？电源过来的脉冲？不得而知。          另一个解释就是盗版下载线内部因为某种原因把脉冲漏进了TDO管脚，致使两条菊花链的最后一级的TDO被损坏，A板FPGA幸免的原因是前面有PROM用身躯挡住了脉冲，而B板则是FPGA第一个遭殃，后面的PROM靠近FPGA的也损坏（至于A、B板后级菊花链的一好一坏的结果可能与FPGA和PROM的JTAG结构有关，这就不是很清楚了）。对于盗版下载线的TDO是如何有输出脉冲的，也许浪涌是罪魁祸首。而官方的下载线是有这方面的保护芯片，盗版没有，至少我这款确定是没有。          至于我当时的第一反应磁珠，我自己也不敢肯定是否与它有关。虽然磁珠隔离只会吸收高频脉冲，是降压而非升压，即便是过流也不是一个磁珠造成的，更何况我换的还是1.2V FPGA核心电源的磁珠，这产生的浪涌也能漏进2.5V的话，FPGA还完好无损如何解释？。这就与TI开关电源模块的输出网络扯不上关系了。           事故小结： 现在我深刻意识到调试贵重东西时候一定要按步就班，不异想天开、想当然的做。每次上电都要高度警觉，对电源，对开板子之外的一切外设接口都要留心。除自我约束之外，我想应该是时候好好研究一下JTAG下载线，之前也早有打算自己弄一个，但没有时间。再说了，USB传输比PCIe要小型化的多，到哪里都能用。刚好我导师的雷达上用到68013做为USB传输芯片，不过是与Altera的FPGA连的，不懂USB有点说不过去。这次如果真是盗版没有浪涌保护的原因，那就真的是一次大教训了。FPGA并不是金刚不坏之身，他的致命弱点或许就是TDO管脚。对于配置接口的浪涌保护，下载没有，那设计的时候不防加上。   （PS：题外话，写这篇文章主要为我自己留下深刻印象，有啰嗦的地方见谅，电路不便放多，忘理解，如有不同观点的动动手 交流交流哈 ）      

 1、 元件选择：电路板上使用的集成电路（IC）支持边界扫描标准IEEE1149.1，优先选用同时支持IEEE1149.1和IEEE1532标准的可编程集成电路。IEEE1532标准能使来自不同厂家的可编程逻辑集成电路使用相同软件进行编程。 2、 扫描链连接方式：由于LATTICE、XILINX、ALTERA、TI和AD公司的编程软件工具不兼容，因此，为了便于使用各自的编程软件工具进行编程，不同公司的可编程集成电路应放置在不同的扫描链上，每一个扫描链提供一个独立的用于编程和测试的JTAG接口。 如果不同公司的可编程集成电路支持IEEE1532标准，则可以把它们放置在同一扫描链上。此时，可以使用相同的编程软件对来自不同公司的集成电路进行编程。 3、 扫描链中电压处理：尽量把具有相同电压等级的集成电路放在同一条扫描链中。ScanWorks可以提供可编程的JTAG接口电平，以适应不同电压等级的集成电路测试需要。若要把不同电压等级的集成电路设置在同一个扫描链中，则需要进行电平转换。 4、 TCK时钟选择：当把具有不同TCK的速度的集成电路设放置在同一个扫描链时，TCK速度必须设置为扫描链中最慢集成电路的TCK速度。 5、 信号缓冲驱动：边界扫描测试接口信号包括TMS、TCK、TRST、TDI和TDO。为了保证这些信号的完整性，需要对进入数字电路板的接口信号进行缓冲，特别是TCK和TMS。TCK、TMS在进行测试时其典型扇出不能多于10个，为保证信号的完整性及电路的可靠性，一般在扇出大于5个时应进行缓冲驱动处理。常用的缓冲集成电路有54LS244。若54LS244不能满足速度要求，则可以采用速度更快的FPGA作为缓冲器。 6、 芯片边界扫描文件阅读及特殊引脚设置：某些支持边界扫描测试的集成电路有一些特殊功能引脚，这些引脚影响边界扫描测试功能。当进行边界扫描测试时，需要将这些引脚设置到特定的状态。在使用集成电路之前，应仔细阅读该集成电路的BSDL文件，然后按照特殊功能引脚的使用要求进行合理的连接。BSDL文件是由集成电路制造商提供的描述该芯片边界扫描功能的一种文本格式的文件，用记事本即可打开。     Xilinx SPARTAN XC2S150 FPGA的BSDL文件中指出：当处于边界扫描测试模式时，该芯片的PROGRAM引脚应设置为1；当处于其它工作方式时，PROGRAM引脚应设置为0。为了保证在边界扫描测试模式时，PROGRAM引脚能设置为1，该引脚应连接到一个开关上，利用开关可以设置PROGRAM引脚为1或0。     TI公司的TMS320C6701（DSP）芯片，当处于正常工作或仿真调试状态时，EMU0和EMU1引脚应设置为11，而处于边界扫描测试状态时，EMU0和EMU1引脚应设置为00。这两个引脚不能连接到固定信号上，应连接到开关上，利用开关设置EMU0和EMU1引脚的状态。