IEEE P1687 is a valuable tool for accessing on-chip instruments during test, diagnosis, debug, and board configuration. However, most of these instruments should not be available to an end user in the field. We propose a method for hiding instruments in a P1687 network that utilizes a "locking" segment insertion bit (LSIB) that can only be opened when pre-defined values, corresponding to a key, are present in particular bits in the chain. We also introduce "trap" bits, which can further reduce the effectiveness of brute force attacks by permanently locking an LSIB when an incorrect value is written to the trap's update register. Only a global reset will allow the LSIB to become operable again. In this paper, we investigate the cost and effectiveness of LSIBs and traps in several different configurations and show that these relatively small modifications to the P1687 network can make undocumented instrument access exceedingly difficult.

No abstract

In today's large designs, especially large SOC (system-on-a-chip) designs, vector volume for a single core could dominate the memory resources of the target tester and leave little or no room for other vectors. To this end, delivery of an "optimized or "reduced vector set, without any loss of coverage, is preferred. One commercial means of delivering an optimized vector set is to compress the vectors during vector generation. Another applicable solution is to understand the overlapping faults among various fault models and remove them from the fault lists for certain pattern types. The main problem with these optimization approaches is that compressed vectors create more switching activities, which could potentially cause average power dissipation, instantaneous and peak power during test to be significantly higher than normal operation. Test power is such a big concern in large SOC designs that the power associated with the "reuse" vectors must be understood. This paper presents a case study of a Motorola Version 3 ColdFire@ microprocessor core, with a focus on the various vector optimizations and their ramifications on test power.

No abstract

In recent times, the 1149.1 TAP and TAP Controller have begun to play a more important role in accessing embedded logic that is not specifically limited to1149.1's scope as a board-test standard. This logic, referred to by the generic term instruments, includes manufacturing test and designfor-test (DFT) logic; design-for-debug/diagnosis (DFD) logic; design-for-yield (DFY) logic and monitors; and in-system verification logic (such as hardware assertions). The P1687 IJTAG StandardWorking Group was created to investigate formalizing and standardizing this use of the 1149.1 controller-and after a little more than a years worth of effort has produced a Hardware Architecture Proposal that is currently being used as a strawman to investigate and develop the description and protocol language effort.