Doing More with Less – An IEEE 1149.7 Embedded Tutorial : Standard for Reduced-pin and Enhanced-functionality Test Access Port and
Boundary-Scan Architecture
Adam W Ley
ASSET InterTech, Inc. Richardson TX, USA
Abstract
IEEE Std 1149.7 offers a means to reduce chip pins dedicated to test (and debug) access while enhancing the functionality of the Test Access Port (TAP) as a complementary supert of the original IEEE Std 1149.1 (JTAG). Extended features such as hot-plug immunity, power management, optimization of scan throughput, access to instrumentation, and access to custom technologies provide welcome improvements for debug. Further, the boundary-scan architecture is bolstered to ensure full support for test. This important advancement in test and debug interfaces is well suited for access to multiple cores on SOC or multiple die in SIP or POP.
1.Introduction
In the 1980s, the Joint Test Action Group (JTAG) was formed to address a growing concern about diminishing test access to chips on boards due to the adoption of surface-mount asmbly methods and ongoing miniaturization of chip packages. In 1990, their efforts culminated in the ratification of IEEE Std 1149.1 – Standard Test Access Port and Boundary-Scan Architecture. While 1149.1 was firmly rooted in the need
to solve the problems of board test, as exemplified by the provision for boundary scan, the proponents of the standard realized the need for a generalized means of low-level access to components on boards and in systems that would suit a wide range of us. As a result, the 1149.1 test access port (TAP), as specified, has met this need.
诗经楚辞起名
In fact, even before the ink was dry, the 1149.1 TAP was being exploited for purpos beyond board test. In the early days, its utility was deployed to support access to chips for in-circuit emulation (debug), albeit often with additional pins for proprietary signals. Somewhat later, the ubiquity of the 1149.1 TAP was exploited in a normative n for in-system configuration of programmable devices by way of IEEE Std 1532. Later still, u of the 1149.1 TAP as a debug interface was standardized by NEXUS 5001 (although still requiring additional signaling for many cas). Today, for the same reasons of utility and ubiquity, the 1149.1 TAP is considered the most likely means of access to chips
that support embedded instruments per P1687 (informally known as Internal JTAG or IJTAG).
Notwithstanding the exceptional merits of the 1149.1 TAP, ongoing industry momentum toward greater miniaturization and still more integration led some to the conclusion that a makeover was needed [1]. In particular, they propod to enhance its functionality and utility in applications debug, but also to reduce pins to be better suited to multi-core/ multi-die architectures. IEEE Std 1149.7 [2, 3, 4, 5] has been developed to meet the needs [6, 7, 8, 9, 10, 11, 12].
1.1What is IEEE 1149.7
IEEE 1149.7 is a standard for a test access port and associated architecture that offers reduced pins and enhanced functionality. With regard to pin reduction, whereas the conventional 1149.1 TAP (TAP.1) requires at least four signals (with a fifth, for test ret, being optional), the reduced-pin 1149.7 TAP (TAP.7) requires only two signals (with the possibility for encoding the optional test ret function onto the). Further, with regard to functionality enhancement, it is expected that, in many cas, extended signaling needs for us such as applications debug can be met on no more than two pins. Even while delivering the benefits, 1149.7 has taken great pains to prerve the investment that the industry has made in 1149.1 for chips and on boards. Particularly, 1149.7 adopts
the entirety of the 1149.1 boundary-scan architecture to fully support board test and in-system configuration. Further, 1149.7 does not replace 1149.1, but rather adapts it and extends it, building upon its foundation and legacy. For example, as illustrated in Figure 1, an 1149.1 chip can be adapted easily to provide a TAP.7. As well, TAP.7s can coexist with TAP.1s on boards and, in some cas, even on the same board-level TAP connections.
“before”“after”
Figure 1—Adaptation of 1149.1 to 1149.7
1.2
IEEE 1149.7 Key Objectives
鱼松的做法The key objectives for 1149.7 fall broadly into three categories – system architecture, applications debug, and legacy infrastructure (to include test).
Benefits for system architecture derive from the appropriate accommodation of multiple on-chip embedded TAP Controllers (EMTAPC), the reduction of pins, the adoption of glue-less star topology, independence from CPU/debug technology, and provisions for power management. Where intellectual property (IP) blocks may each contain EMTAPCs, multiples of the may be accommoda
ted on a complex system-on-chip (SOC). While reduced pin count has inherent value with respect to miniaturization, consider as well that, in combination with the star topology, fewer pins better support the new 3D packaging methodologies such as system-in-package (SIP). The typically involve the stacking of die as shown in Figure 2; converly, a daisy-chaining implementation is not only more difficult but also is not 1149.1 compliant. Of cour, the same can be said for package-on-package (POP). Further, independence from particular CPU/debug technologies supports similar integrations even where chips may incorporate CPU IP from multiple sources. Facilities that permit the test logic to enter power-down modes support increasingly aggressive power management requirements.
Figure 2—Star topology for a 3-die SIP
For applications debug, the TAP.7 provides advanced capability that reduces or eliminates the need f
or signaling beyond the two wires. Extensions provided include robust hot connect, incread throughput by way of scan optimization, higher operating frequency, and transport of background instrumentation data and/ or custom protocols. Of cour, independence from CPU/debug technology also accrues here becau uniform tool ts can support chips with heterogeneous CPUs.
Finally, as concerns the legacy infrastructure, the objectives are two-fold – first, honor 1149.1 by prerving the test infrastructure that has been built up around it and on which the industry depends; and cond, maintain a level of compliance such that existing intellectual property in chips, on boards, and in debug and test systems (DTS) can be adapted at low cost.
2. Overview/ How it Works
At the highest level of abstraction, 1149.7 provides for a chip-level TAP.7 Controller that bridges the conventional 1149.1-accessible System Test Logic (STL) to the four (five) or two (three) wires of the chip-level TAP.7 (the test ret signal is optional in either ca). The STL has its own 1149.1 chip-level TAP Controller (CLTAPC) and all of the associated test logic architecture, including a chip-level boundary-scan register and related EXTEST, PRELOAD, and SAMPLE instructions.
Seeking to extend 1149.1 in a compatible fashion, 1149.7 starts with the obrvation that the TAP Controller (TAPC) at the core of 1149.1 is a two-wire control means, even in the conventional ries topology, as shown in Figure 3.
TCK TDI
TDO
TMS
Figure 3—Conventional ries topology, highlighting the star
wiring for TCK/TMS
Per 1149.1 convention, the starred TCK/TMS can only advance the TAPC state, which in turn invokes TDI/TDO for scan operations, but, abnt instruction register scans, does not change the mode of the test logic. Thus, the key concept of 1149.7 continues with the obrvation that control extensions might be overlaid on quences of TAPC states (more details on this later).
Thus, 1149.7 adds its own commands and registers on which the other layers of extended functionali
ty are bad. The additional layers add scan formats, direct addressability, packetization of scan data (TMS, TDI, and/ or TDO information) onto the TMS wire (hence, re-designated TMSC), and finally packetization of non-scan information onto TMSC to provide for transport of background and/ or custom data.
As such, 1149.7 supports a number of capability class (six in number, designated as T0 - T5). So the TAP.7 Controller is configurable to support the required capability for a given implementation. The primary functional units are illustrated in Figure 4 and are designated as follows: Advanced Protocol Unit (APU), Extended Protocol Unit (EPU), Pin-Sharing Logic (PSL), and Ret and Selection Unit (RSU). The manner in which the items are invoked (or not) for given capability class will be described in subquent ctions.
TDI(C)nTRST EPU TAP.7TDO(C)
TCK(C)TMS(C)TAP.7 Controller
Figure 4—Notional view of the 1149.7 architecture
2.1 Capability class
Regardless of which capability class is implemented, a given TAP.7 must implement all of the mandatory features of its own class as well as tho of all lower-numbered class (T0 < T5). The class are generally considered in two primary groupings: tho which extend 4-wire operation (T0 – T3) and tho which provide the reduced-pin, 2-wire operation (T4 – T5).
T0–foundation
As the foundation of all TAP.7 capabilities, T0 begins with 1149.1-Specified behavior, such that the T0 STL is 100 percent compliant to 1149.1 including provisions for the mandatory chip-level boundary-scan architecture. With 1149.7 T0, the chip-level device identification register becomes mandatory.
Of the TAP.7 Controller elements shown in Figure 4, only the RSU is permitted as an option; the other items are rerved for higher class.
Where the RSU is implemented, this would be done, as for any other class, to permit Escape Sequences and/ or Selection/Delection Alerts to be available to manage the sharing of TAP.7 signaling across technologies and topologies. When the TAP.7 Adapter TAPC (ADTAPC) is delected, the CLTAPC will be parked. The topics will be addresd in greater detail with T3 where the RSU becomes mandatory.
Of particular note, even where the chip has multiple EMTAPCs, as might be the ca for a complex SOC that implements a mix of veral core IP blocks, the T0 STL shall provide 1149.1-Specified behavior from the Test-Logic-Ret TAPC state. 1149.7 identifies veral means by which EMTAPCs can be lected under the control of the CLTAPC. A further method is defined for managing multiple die-level TAPCs in a similar manner for SIP. T1–commands and registers
With T1, the 1149.7 mechanism providing extended control by way of TCK/TMS is invoked to access 1149.7 commands and registers. The functions pertain to the EPU as illustrated in Figure 4. So, the EPU block of the TAP.7 Controller is prent for T1. Otherwi, excepting the RSU, as for T0, all other blocks are rerved for higher class.
As described earlier, the extended control mechanism operates without disruption to the conventiona
l 1149.1 TAPC state machine. Rather, it us a particular state quence, which is benign to normal 1149.1 operations, to initiate 1149.7-defined action.
The state quence of interest is known as a zero-bit DR scan (ZBS) and the are to be operated only while all of the CLTAPCs in the lected topology operate BYPASS or IDCODE so as to ensure that they do not disrupt normal system operation. In fact, ZBS detection is validated only when no IR scans have intervened since the last occurrence of the Test-Logic-Ret TAPC state.
The progression of states that is recognized as a ZBS is illustrated in Figure 5.
Scan
Capture-DR
原来我也很坚强
病句练习题Exit1-DR
Exit2-DR
Update-DR
Shift-DR
Pau-DR
1
1
1
01
1
1
a
b
Figure 5—Zero-bit scan (ZBS)
There are actually two different paths, labeled as “a” and “b” in Figure 5, that can implement a ZBS. I
n either ca, the state quence of interest is defined as follows: from the Select-DR-Scan TAPC state, proceed to the Update-DR TAPC state without passing the Shift-DR TAPC state. From the Test-Logic-Ret TAPC state, wherein the ZBS count is t to zero, the extended control mechanism is initiated when at least two ZBSs are detected before a subquent non-zero-bit DR scan, which locks the ZBS count. A locked ZBS count of two provides access to the 1149.7 commands and registers. Locked ZBS counts greater than two access higher control levels that will not be detailed here.
Once the ZBS count is locked, and a control level t, it is only unlocked when the control level is exited by entry to either the Select-IR-Scan or Test-Logic-Ret TAPC states or by certain 1149.7 commands and events that are ud to synchronize T4 and T5 operations.
At control level 2, commands are recognized, without the u of TDI/TDO pins, by counting the number of TCK(C)
ticks in the Shift-DR TAPC state for two scans that immediately follow the completion of the non-zero-bit DR scan that locked the ZBS count. Each of the two primary command words is coded in 5 bits, ensuring that the counts need not exceed 31. All commands include two such parts for a tot
al code length of 10 bits. In most cas, the command and register operations are concluded in the two parts but in some (only three) special cas a third part (a DR scan of a length determined by the control register addresd by the command) is required.
T1 mandates a given minimum t of such commands and the registers that they address. Additionally, some commands, registers, and associated functions are optional, notably tho that invoke directed test ret generation and request for functional ret.
Additionally, T1 provides for power management through four modes of power control for the test logic. The four modes are: allow power down if TCK stops at logic one for more than 1 ms, allow power down if TCK stops at logic one for more than 1 ms in the Test-Logic-Ret TAPC state, allow power down if the device is in the Test-Logic-Ret TAPC state, and do not allow power down (the test logic is always powered).
Given that a power-down mode is supported, the test logic is directed to resume powered operation when the Run-Test/Idle TAPC state is forced for at least 100 ms and at least 3 TCK(C) ticks.
房子缺角
T2–scan formats
The 1149.7 scan formats are introduced in T2. A T2 TAP.7 supports JScan0 – JScan2; other scan formats are rerved for higher class.
Of the TAP.7 Controller elements shown in Figure 4, for T2, as for T1, only the EPU is mandatory with the RSU permitted as an option; the other items are rerved for higher class. For T2 versus T1, the EPU adds the commands and registers associated with the scan formats. As regards the function of the scan formats, JScan0 provides 1149.1-Specified behavior while JScan1 provides for the delection of the CLTAPC in favor of a 1-bit scan path (so-called Super Bypass) that is active for IR scans as well as DR scans and JScan2 provides for activation/deactivation of the Super Bypass according to the value of an 1149.7 register.
A T2 TAP.7 can opt either for JScan0 or JScan1 as its startup behavior. The latter ca is described as providing hot-plug immunity since it should permit live connection (or disconnection) of the TAP.7 signals to be non-disruptive to the test logic.
T3–direct addressability
Finally, with T3, the star topology (4 wire), as in Figure 6, is supported. This comes by adding the means for direct addressability and the JScan3 scan format that provides for scans to star-4 topologi
es.
简单的书签Figure 6—Star-4 topology
Of the TAP.7 Controller elements shown in Figure 4, T3 adds the RSU as a mandatory element in addition to the EPU. For T3 versus T2, the EPU adds the commands and registers associated with direct addressability. Note that for T3, the TDI and TDO signals are re-designated as TDIC and TDOC, respectively.
Concerning the RSU for T3, it is required to implement Escape Sequences for ret and for lection/ delection and may optionally implement Selection and Delection Alerts. Escape Sequences involve the detection and counting of a number of edges on TMS(C) driven while TCK(C)
is held at logic 1. The count of such edges determines the action to be taken in respon to the Escape Sequence. Alerts are specific predefined quences of 128 bits as driven on TMS(C).
The resource invoked for support of direct addressability is the TAP.7 Controller Address (TCA), as shown in Figure 7. The values corresponding to DEVICE_ID are inherited from the 1149.1 device identification register capture value for the CLTAPC. The assignment of the NODE_ID is made by some implementation-specific means that is not defined by 1149.7. The NODE_ID rves to distinguish multiple TAP.7s on a given topology branch where they are of the same device type.
Figure 7—TAP.7 Controller Address (TCA)
A key provision required to facilitate scans to the star-4 topology is the prevention of drive conflict on TDOC. The JScan3 format is managed so that when multiple TAP.7 Controllers are requested to participate, then drive on TDOC will be inhibited.
As discusd in more detail in 4.1, test applications require the ability to coordinate the simultaneous
entry of all devices of interest into and/ or through the Capture-xR, Update-xR, and Run-Test/Idle TAPC states. At first glance, the star topology would em not to support this requirement. But in addition to the JScan3 scan format, T3 adds the Scan Selection Directives (SSD) to deal with this matter. The SSDs make u of Pau-xR TAPC states as parking states to which simultaneous scan captures are
directed and from which simultaneous scan updates are directed. Scan shift operations, as necessitated by the star topology are done on a device-by-device basis and are both directed from and to the Pau-xR TAPC states. T4–packetization of scan data (2-pin scan formats)
With T4, a number of additional scan formats are added to support the advanced protocol, which is operated on two pins. The TCK/TMS pins are re-designated as TCKC/TMSC, respectively. The corresponding star-2 topology is illustrated in Figure 8. Note that TMSC is bidirectional.
TMSC
TCKC
Figure 8—Star-2 topology
Of cour, the additions require the provision of the APU of Figure 4. As well, since the TDIC/TDOC pins are optional since they are not ud for 2-pin operation, where they are provided the PSL also becomes an option. Where a T4 TAP.7 does not provide the TDIC/TDOC pins in any configuration, it is described as narrow and designated as T4N. Where a T4 TAP.7 does have a configuration that provides the TDIC/TDOC pins, it is described as wide and designated as T4W.
One of the more basic scan formats that supports the advanced protocol is OScan1. The rialization of the scan packet for OScan1 is illustrated in Figure 9. As shown, the TDI bit information is inverted. Also, for each cycle in which the TDO bit appears it is driven from the lected device in the target system back to the DTS.
TCKC
TMSC state
Figure 9—Scan packet rialization – OScan1
Other scan formats in the OScan ries provide for optimizations in which the scan packets omit bits that can be known to carry no significant information. An example worth noting is the OScan7 format which is optimized for downloads from the DTS to the target system. For OScan7, as illustrated in Figure 10, only the TDI bit information is included in the packets nt during Shift-xR TAPC states.
TCKC nTDI nTDI nTDI nTDI nTDI nTDI nTDI nTDI nTDI
三国演义的简介TMSC Shift-xR
Shift-xR
Shift-xR
state
Figure 10—Scan packet rialization – OScan7
Further performance optimization that can be obtained for T4 is by invoking falling-edge sampling for TMSC which, presuming hold times still can be met, delivers a degree of improvement in tup times that would allow the TCKC frequency to be incread (perhaps doubled).
T5–transport of non-scan data (2-pin mode)
共济会中国
At the top of the class, T5 offers the capability to interleave transfers of non-scan data among the scan transfers. This is referred to as transport and has two variants – background data transport (BDX) and custom data transport (CDX).
Both types of transport can u any combination of Run-Test/Idle, Pau-xR, and Update-xR TAPC states after which to inrt transport packets. The distinction is that, whereas BDX has fixed allocatio
n of I/O bandwidth available to the chip-level data channel, CDX has a custom allocation of I/O bandwidth as determined/ defined by the chip-level unit.
2.2 Selection hierarchy
While some aspects of the lection hierarchy have been described above, some additional detail is warranted as it is a key aspect of the 1149.7 system architecture.
In general, where lection is enabled within the hierarchy, tho items not lected are effectively offline/ parked and respond only to particular lection requests on the TAP.7 signaling. Tho that are lected are online and respond to the TAP.7 signaling according to the protocols for which they are configured.
Five levels in the lection hierarchy are elaborated below. For each level of the hierarchy, one or more lection mechanisms may pertain. - Technology
Where the 1149.7 technology can be placed offline, the TAP.7 signaling can be shared with other technologies
- Topology
W here the constituent 1149.7 devices can be placed offline (a function required for T3 and above), the TAP.7 signaling can be shared among any topology branches, whether ries, star-2, or star-4 - Adapter (i.e., ADTAPC)
1149.7 devices comprising a lected topology branch will share TAP.7 signaling and, where the topology branch is star-2 or star-4, a given device may be lected for a given operation
