 |
Claims  |
|
|
What is claimed is:
1. A method of testing an integrated circuit that includes at least one
output pin, core logic, an instruction register, a test access port (TAP)
controller operable in a plurality of states, including an UPDATE-DR state
and a SHIFT-DR state, and a Boundary-Scan cell coupled between said core
logic and said output pin, said method comprising steps of:
isolating said output pin from said core logic during said UPDATE-DR state
when said instruction register contains an external test (EXTEST)
instruction; and
coupling said output pin to said core logic during said SHIFT-DR state when
said instruction register contains said EXTEST instruction.
2. A method as claimed in claim 1 wherein:
said TAP controller is additionally operable in CAPTURE-DR, SELECT-DR and
RUN-TEST/IDLE states; and
said method additionally comprises a step of isolating said output pin from
said core logic during one or more of said CAPTURE-DR, SELECT-DR and
RUN-TEST/IDLE states when said instruction register contains said EXTEST
instruction.
3. A method as claimed in claim 1 wherein:
said TAP controller is additionally operable in UPDATE-IR, EXIT1-DR,
PAUSE-DR, AND EXIT2-DR states; and
said method additionally comprises a step of coupling said output pin to
said core logic during one or more of said UPDATE-IR, EXIT1-DR, PAUSE-DR,
AND EXIT2-DR states when said instruction register contains said EXTEST
instruction.
4. A method as claimed in claim 1 wherein said integrated circuit includes
at least one input pin and a second Boundary-Scan cell coupled between
said core logic and said input pin, said method additionally comprising
steps of:
isolating said input pin from said core logic during said UPDATE-DR state
when said instruction register contains an internal test (INTEST)
instruction; and
coupling said input pin to said core logic during said SHIFT-DR state when
said instruction register contains said INTEST instruction.
5. A method as claimed in claim 4 wherein said TAP controller is
additionally operable in CAPTURE-DR, SELECT-DR, RUN-TEST/IDLE, UPDATE-IR,
EXIT1-DR, PAUSE-DR, and EXIT2-DR states, said method additionally
comprising steps of:
isolating said input pin from said core logic during one or more of said
CAPTURE-DR, SELECT-DR, and RUN-TEST/IDLE states when said instruction
register contains said INTEST instruction; and
coupling said input pin to said core logic during one or more of said
UPDATE-IR, EXIT1-DR, PAUSE-DR, and EXIT2-DR states when said instruction
register contains said INTEST instruction.
6. A method of testing an integrated circuit that includes a Boundary-Scan
test access port (TAP) controller operable in a plurality of states,
including an UPDATE-DR state and a SHIFT-DR state, said method comprising
steps of:
loading a system action instruction into an instruction register;
asserting a system action in accordance with said system action instruction
during said UPDATE-DR state; and
refraining from asserting said system action during said SHIFT-DR state
while said system action instruction is loaded in said instruction
register.
7. A method as claimed in claim 6 wherein said TAP controller is
additionally operable in UPDATE-IR, EXIT1-DR, PAUSE-DR, AND EXIT2-DR
states, and said method additionally comprises a step of refraining from
asserting said system action during one or more of said UPDATE-IR,
EXIT1-DR, PAUSE-DR, AND EXIT2-DR states while said system action
instruction is loaded in said instruction register.
8. A method as claimed in claim 7 wherein said TAP controller is
additionally operable in CAPTURE-DR, SELECT-DR, and RUN-TEST/IDLE states,
and said method additionally comprises a step of asserting said system
action during one or more of said CAPTURE-DR, SELECT-DR, and RUN-TEST/IDLE
states while said system action instruction is loaded in said instruction
register.
9. A method for performing Boundary-Scan testing on an electronic system
having at least one Boundary-Scan integrated circuit (BSIC) that includes
at least one output pin, core logic, an instruction register, a test
access port (TAP) controller operable in a plurality of states, including
an UPDATE-DR state and a SHIFT-DR state, and a Boundary-Scan cell coupled
between said core logic and said output pin, said method comprising steps
of:
loading an external test (EXTEST) instruction into said instruction
register of said BSIC;
isolating, in response to said loading step, said output pin from said core
logic during said UPDATE-DR state; and
coupling, in response to said loading step, said output pin to said core
logic during said SHIFT-DR state.
10. A method as claimed in claim 9 wherein said BSIC and a Boundary-Scan
master couple to a data and control bus, and said method additionally
comprises steps of:
determining, at said Boundary-Scan master, when said isolating step will
occur; and
requesting control of said data and control bus prior to said isolating
step.
11. A method as claimed in claim 10 wherein:
said Boundary-Scan master generates a test mode select (TMS) signal which
controls sequencing of said TAP controller through said states;
said TAP controller of said BSIC is additionally operable in a PAUSE-DR
state;
said Boundary-Scan master generates a bus request signal and receives a bus
granted signal; and
said method additionally comprises, in response to said determining step,
steps of:
activating said bus request signal;
controlling said TMS signal to hold said TAP controller of said BSIC in
said Pause-DR state until said bus granted signal is received; and
controlling said TMS signal so that said TAP controller exits said PAUSE-DR
state after said bus granted signal is received.
12. A method as claimed in claim 11 additionally comprising, prior to said
activating step, steps of:
determining whether said data and control bus is already controlled by said
Boundary-Scan master; and
releasing control of said data and control bus when said data and control
bus is already controlled by said Boundary-Scan master.
13. A method as claimed in claim 10 wherein said BSIC is a microprocessor,
and said method additionally comprises a step of receiving programming
data from said microprocessor at said Boundary-Scan master through said
data and control bus, said programming data defining a Boundary-Scan test
for said microprocessor.
14. A method as claimed in claim 9 wherein:
said TAP controller is additionally operable in CAPTURE-DR, SELECT-DR, and
RUN-TEST/IDLE states; and
said method additionally comprises a step of isolating, in response to said
loading step, said output pin from said core logic during one or more of
said CAPTURE-DR, SELECT-DR, and RUN-TEST/IDLE states.
15. A method as claimed in claim 9 wherein said TAP controller is
additionally operable in UPDATE-IR, EXIT1-DR, PAUSE-DR, AND EXIT2-DR
states, and said method additionally comprises a step of coupling, in
response to said loading step, said output pin to said core logic during
one or more of said UPDATE-IR, EXIT1-DR, PAUSE-DR, AND EXIT2-DR states.
16. A Boundary-Scan master coupled to a data and control bus, said
Boundary-Scan master including:
means for determining when an external test (EXTEST) instruction will
assert a system action; and
means for requesting control of said data and control bus prior to said
assertion of said system action in response to signals from said means for
determining, said determining means coupled to said requesting means.
17. A Boundary-Scan master as claimed in claim 16 wherein:
said Boundary-Scan master generates a test mode select (TMS) signal which
controls Boundary-Scan testing of an integrated circuit (IC) having an
instruction register and a test access port (TAP) controller for operating
in a plurality of states, including an EXIT1-DR state; and
said determining means additionally includes means for identifying when
said EXTEST instruction is loaded in said instruction register of said IC
and said TAP controller has entered said EXIT1-DR state, said identifying
means coupled to said determining means and said requesting means.
18. A Boundary-Scan master as claimed in claim 16 wherein:
said Boundary-Scan master generates a test mode select (TMS) signal for
controlling Boundary-Scan testing of an integrated circuit (IC) having an
instruction register and a test access port (TAP) controller for operating
in a plurality of states, including a PAUSE-DR state;
said Boundary-Scan master generates a bus request signal and receives a bus
granted signal; and
said Boundary-Scan master additionally comprises, in response to said
determining means, means for:
activating said bus request signal;
controlling said TMS signal to hold said TAP controller in said PAUSE-DR
state until said bus granted signal is received; and
controlling said TMS signal so that said TAP controller exits said PAUSE-DR
state after said bus granted signal is received.
19. A Boundary-Scan master as claimed in claim 18 additionally comprising
means for, prior to activating by said activating means:
determining whether said data and control bus is already controlled by said
Boundary-Scan master; and
releasing control of said data and control bus when said data and control
bus is already controlled by said Boundary-Scan master.
20. A Boundary-Scan master as claimed in claim 16 wherein:
said Boundary-Scan master generates a test mode select (TMS) signal for
controlling Boundary-Scan testing of an integrated circuit (IC) having an
instruction register and a test access port (TAP) controller for operating
in a plurality of states, including a PAUSE-IR state;
said Boundary-Scan master generates a bus request signal and receives a bus
granted signal; and
said Boundary-Scan master additionally comprises means, operating in
response to said determining means, for:
activating said bus request signal;
controlling said TMS signal to hold said TAP controller in said PAUSE-IR
state until said bus granted signal is received; and
regulating said TMS signal so that said TAP controller exits said PAUSE-IR
state after said bus granted signal is received.
21. A Boundary-Scan master as claimed in claim 20 wherein said TAP
controller is additionally for operating in an EXIT1-DR state, and said
Boundary-Scan master additionally comprises, coupled to and responsive to
said regulating means, means for:
identifying when said EXTEST instruction is loaded in said instruction
register and said TAP controller has entered said EXIT1-DR state;
determining, in response to said identifying means, whether said data and
control bus is being controlled by said Boundary-Scan master; and
releasing control of said data and control bus when said data and control
bus is being controlled by said Boundary-Scan master. |
|
 |
|
 |
Claims |
|
|
|
Description |
|
|
TECHNICAL FIELD OF THE INVENTION
The present invention relates to Boundary-Scan testing of electrical
circuits in accordance with IEEE 1149.1-1990: IEEE Standard Test Access
Port and Boundary-Scan Architecture, and to similar testing architectures
and techniques.
BACKGROUND OF THE INVENTION
As electrical circuits and systems become more complicated, sophisticated
and miniaturized, techniques for viable automated testing of the circuits
and systems become more important. Boundary-Scan represents an approach to
testing that appears to be compatible with increasingly complicated,
sophisticated and miniaturized circuits and systems. Currently, numerous
integrated circuits, particularly complicated devices and application
specific integrated circuits (ASICs), include Boundary-Scan features, and
various Boundary-Scan support devices (e.g., Boundary-Scan masters) are
commercially available.
An outline for Boundary-Scan architectures and methodologies is set forth
in the IEEE 1149.1-1990 standard. This standard is concerned with
high-level testing approaches, and-applies to all circuits and systems,
regardless of their specific function. The standard discusses various
public and private features, along with various mandatory and optional
features. The standard permits a great deal of implementation flexibility
within its framework.
The main focus of Boundary-Scan testing appears to be aimed at
manufacturing environments. A system includes components or boards,
hereinafter referred to as a unit or units under test (UUT). The system
may benefit from testing the UUT to verify proper operation. Typically,
the system need not perform the functions for which it has been designed
during manufacturing testing. Consequently, the length of time required to
perform any one test is of minor importance compared to performing a valid
test.
A system need not test itself during manufacturing testing. The
manufacturing tests may rely on an external test controller (e.g., a
personal computer) running a program specifically configured to test the
UUT. Boundary-Scan testing may disable system controller components (e.g.,
microprocessors etc.) without affecting testing viability. In a
manufacturing environment, power to the UUT may be recycled or a reset
signal asserted to restart a controller device after testing completion.
On-line testing imposes more severe constraints than manufacturing testing.
Unfortunately, conventional Boundary-Scan techniques fail to adequately
meet these constraints. On-line testing typically occurs "in the field"
while a system continues to perform the functions for which it has been
designed. Typically, on-line testing takes place in a background mode of
operation, where system functions take place in a foreground mode of
operation and the foreground and background modes are interleaved in time.
Any one test should not consume an excessive amount of time because an
adverse impact on system functions may result. Typically, no external
controller is available for controlling the tests. System controllers,
which themselves may be subjected to testing, may be given the job of
controlling the tests. Consequently, testing should permit microprocessors
to continue with their normal sequencing, with a minimum of resetting and
power recycling.
SUMMARY OF THE INVENTION
Accordingly, it is an advantage of the present invention that an improved
Boundary-Scan testable system and method is provided.
Another advantage of the present invention is that Boundary-Scan testing is
extended to serve many on-line testing applications.
Another advantage is that the present invention adapts Boundary-Scan
principles so that the influence of testing on system activities consumes
less time.
Another advantage is that the present invention adapts Boundary-Scan
principles so that embedded system controllers may control system testing
without relying upon external testers.
The present invention advantageously adapts Boundary-Scan principles,
allowing testing of systems including shared system resources (e.g.,
common busses).
The above and other advantages of the present invention are carried out in
one form by a method and system for testing an integrated circuit
including at least one output pin, core logic, an instruction register, a
test access port (TAP) controller operable in a plurality of states,
including an Update-DR state and a Shift-DR state, and a Boundary-Scan
cell coupled between the core logic and the output pin. The method and
system call for isolating the output pin from the core logic during the
Update-DR state when the instruction register contains an external test
(EXTEST) instruction. The output pin is coupled to the core logic during
the Shift-DR state when the instruction register contains the EXTEST
instruction.
These and other advantages of the present invention are carried out in
another form by a method and system for operating a Boundary-Scan master
coupled to a data/control bus. The method and system call for determining
when an external test (EXTEST) instruction will assert a system action.
Data/control bus control is requested prior to assertion of system
actions.
BRIEF DESCRIPTION OF THE DRAWINGS
A more complete understanding of the present invention may be derived by
referring to the detailed description and claims when considered in
connection with the Figures, wherein like reference characters refer to
similar items throughout the Figures, and:
FIG. 1 is a block diagram of an exemplary system configured in accordance
with the teaching of the present invention;
FIG. 2 is a block diagram of an exemplary Boundary-Scan integrated circuit
(BSIC);
FIG. 3 is a state diagram for a BSIC test access port (TAP) controller;
FIG. 4 is a block diagram of mode selection logic and Boundary-Scan cells
associated with BSIC input and output pins;
FIG. 5 is a block diagram of an exemplary Boundary-Scan master; and
FIG. 6 is a flow chart of a process performed by the Boundary-Scan master.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
FIG. 1 is a block diagram of exemplary system 10, comprising a generic
computer or microprocessor architecture. However, the precise
configuration of system 10 is unimportant to the present invention, and
system 10 may represent other types of electronic circuits coupled
together into a system.
Microprocessor or other controller 12 couples to an address, data, and
control bus 14 (hereinafter D/C bus 14). In preferred embodiments of the
present invention, microprocessor 12 represents a Boundary-Scan integrated
circuit (BSIC), a component including elements to support Boundary-Scan
testing. Other components likewise couple to D/C bus 14, i.e., BSICs 16,
18. BSICs 16, 18 represent any of numerous integrated circuits known to
those skilled in the art as being usable in microprocessor designs. Such
integrated circuits may include buffers, interface devices, memory
devices, peripherals, direct memory access (DMA) controllers, other
microprocessors etc. System 10 may also include other BSICs, e.g., BSIC
20, not coupled to D/C bus 14.
System 10 further includes Boundary-Scan master 22 coupled to D/C bus 14.
Through D/C bus 14, Boundary-Scan master 22 receives programming data from
microprocessor 12. These programming data define how to configure
Boundary-Scan tests for system 10, including microprocessor 12.
Boundary-Scan master 22 supports one or more Boundary-Scan chains 24 (FIG.
1 depicts only one chain 24 for clarity). Chain 24 incorporates various
ones of the BSICs included in system 10, and these BSICs are serially
coupled together (i.e., daisy chained). Generally speaking, in response to
programming data received at Boundary-Scan master 22, test vector data
originate at Boundary-Scan master 22 and are serially routed through the
BSICs in chain 24 to load various registers in the BSICs. Likewise, test
signature data originated at the BSICs are serially routed through chain
24 back to Boundary-Scan master 22.
As is typical for microprocessor architectures and other designs, any
number of BSICs and other devices may couple to a common shared resource,
such as D/C bus 14. More than one of these devices may control D/C bus 14
from time to time. In other words, more than one of these devices may
output data via D/C bus 14. These data may request other devices to
respond therethrough.
In order to prevent interference among users of D/C bus 14, system 10
includes bus arbitrator 26. In the embodiment illustrated in FIG. 1, each
device which may granted control of D/C bus 14 couples to bus arbitrator
26. Such devices include at least microprocessor 12 and Boundary-Scan
master 22. Each of these devices includes pins to support a bus request
(BR) output signal, a bus granted (BG) input signal, and a bus busy (BB)
input/output (I/O) signal, each routed to bus arbitrator 26, and the bus
busy pins from all such bus-grabbing devices couple together. Bus
arbitrator 26 prioritizes the requests it receives for control of D/C bus
14 and grants control of D/C bus 14 in accordance with its prioritization
scheme and its currently received requests. Devices which may control D/C
bus 14 refrain from controlling D/C bus 14 unless they have first
requested and been granted bus control and other users have released the
bus busy signal.
Not all devices included in system 10 need to be BSICs, e.g., Boundary-Scan
master 22 and bus arbitrator 26. On the other hand, nothing prevents
Boundary-Scan master 22 and bus arbitrator 26 from being BSICs in various
applications. Moreover, in other applications, bus arbitrator 26 may
itself couple to D/C bus 14 to receive programming data from
microprocessor 12.
FIG. 2 is a block diagram of exemplary BSIC 28, representing any one of
BSICs 12, 16, 18, 20 (FIG. 1). BSIC 28 includes plurality of input pins
30, plurality of output pins 32, and core logic section 34. I/O pins may
be substituted for any of pins 30, 32 and three-state pins may be
substituted for output pins 32, but these are omitted in FIG. 2 for
clarity. Any number of input and/or output pins 30 and/or 32 may be
included in BSIC 28.
For the purposes of Boundary-Scan testing, system elements are deemed to
reside within core logic section 34, external to pins 30, 32. Core logic
section 34 performs the system-related functions performed by BSIC 28 in
system 10 (FIG. 1). In other words, it is core logic sections 34 in the
various BSICs included in system 10, along with other non-BSIC devices,
that permit system 10 to accomplish its tasks. The precise configuration
or nature of core logic 34 varies from BSIC 28 to BSIC 28.
Boundary-Scan (BS) cells 36 selectively couple and isolate core logic
section 34 from input pins 30 and output pins 32. Each BS cell 36 that is
used with an input pin 30 couples between an input pin 30 and core logic
34. Each BS cell 36 that is used with an output pin 32 couples between
core logic 34 and an output pin 32. Not all of the pins of BSIC 28 need be
associated with BS cell 36. For example, power pins and pins providing bus
request signals may omit an association with BS cell 36.
Each of BS cells 36 receives a common MODE input signal. In addition, each
of BS cells 36 couples to other BS cells 36 in a serial fashion so that BS
cells 36 collectively form Boundary-Scan register 38. A test data input
(TDI) input pin 40 drives the input of Boundary-Scan register 38. The last
BS cell 36 in Boundary-Scan register 38 couples to test data output (TDO)
output pin 42. Chain 24 (FIG. 1) is formed from series connections between
all Boundary-Scan registers 38 of the BSICs included in the chain.
As described so far, BS cells 36 and core logic 34 represent conventional
BS cells and core logic sections. Furthermore, BSIC 28 includes test
access port (TAP) controller 44, state decoder 46, instruction register
48, and instruction register decoder 50 similar or identical to those
known in the art. BSIC 28 may also include other registers 52, such as an
ID register, data register, bypass register etc., which are well known.
Instruction register 48 and other registers 52 couple in parallel across
the input and output of Boundary-Scan register 38. Registers 48 and 52
represent shift registers receiving input data from TDI pin 40 and
supplying output data through TDO pin 42. Parallel outputs from
instruction register 48 couple to inputs of instruction register decoder
50. Thus, instruction register decoder 50 determines which instruction may
be currently active for BSIC 28.
Test mode select (TMS) and test clock signals are applied at TMS and TCK
pins 54, 56, respectively. Pins 54, 56 couple to TAP controller 44 and
couple in parallel among the various BSICs 28 included in system 10 (FIG.
1). TMS and TCK signals are generated by Boundary-Scan master 22 (FIG. 1).
TAP controller 44 represents a state machine sequencing between various
states in response to the TMS signal logic level when clocked by the TCK
signal. An output of TAP controller 44 couples to an input of state
decoder 46. State decoder 46 determines when various states are executed
by TAP controller 44.
FIG. 3 is a state diagram depicting various states in which TAP controller
44 operates. These states, well known in the art, are briefly discussed
below. Activities occurring during these states (FIG. 2) as a result of
mode selection logic 58 permit BSIC 28 to operate in accordance with the
teaching of the present invention. Mode selection logic 58 receives inputs
from instruction register decoder 50 and state decoder 46 and responds by
generating the above-discussed MODE signal, which controls coupling of
core logic 34 to, and isolation of core logic 34 from, pins 30, 32 through
BS cells 36.
The state of the TMS signal present at pin 54 when clocked by the TCK
signal controls the sequencing of TAP controller 44 through its various
states, summarized below. When TAP controller 44 is in Test-Logic-Reset
state 60 (FIG. 3), it remains in state 60 when the TMS signal is high
("1") but moves to Run-Test/Idle state 62 when the TMS signal is low
("0"). When TAP controller 44 is in Run-Test/Idle state 62, it remains in
state 62 when the TMS signal is low but moves to Select-DR-Scan state 64
when the TMS signal is high.
When TAP controller 44 is in state 64, program control moves to Capture-DR
state 66 when the TMS signal is low but moves to Select-IR-Scan state 68
when the TMS signal is high. When TAP controller 44 is in state 68,
program control moves to Capture-IR state 70 when the TMS signal is low
but moves back to Test-Logic-Reset state 60 when the TMS signal is high.
When TAP controller 44 is in state 70, program control moves to Shift-IR
state 72 when the TMS signal is low but moves to an Exit1-IR state 74 when
the TMS signal is high. When TAP controller 44 is in state 72, program
control remains in state 72 when the TMS signal is low but moves to
Exit1-IR state 74 when the TMS signal is high. When TAP controller 44 is
in state 74, program control moves to Pause-IR state 76 when the TMS
signal is low but moves to an Update-IR state 78 when the TMS signal is
high. When TAP controller 44 is in state 76, program control remains in
state 76 when the TMS signal is low but moves to an Exit2-IR state 80 when
the TMS signal is high. When TAP controller 44 is in state 80, program
control moves back to Shift-IR state 72 when the TMS signal is low but
moves to Update-IR state 78 when the TMS signal is high. When TAP
controller 44 is in state 78, program control returns to Run-Test/Idle
state 62 when the TMS signal is low and returns to Select-DR-Scan state 64
when the TMS signal is high.
When TAP controller 44 is in Capture-DR state 66, program control moves to
Shift-DR state 82 when the TMS signal is low but moves to Exit1-DR state
84 when the TMS signal is high. When TAP controller 44 is in state 82,
program control remains in state 82 when the TMS signal is low but moves
to Exit1-DR state 84 when the TMS signal is high. When TAP controller 44
is in state 84, program control moves to Pause-DR state 86 when the TMS
signal is low but moves to an Update-DR state 88 when the TMS signal is
high. When TAP controller 44 is in state 86, program control remains in
state 86 when the TMS signal is low but moves to an Exit2-DR state 90 when
the TMS signal is high. When TAP controller 44 is in state 90, program
control moves back to Shift-DR state 82 when the TMS signal is low but
moves to Update-DR state 88 when the TMS signal is high. When TAP
controller 44 is in state 88, program control returns to Run-Test/Idle
state 62 when the TMS signal is low and returns to Select-DR-Scan state 64
when the TMS signal is high.
Although these states for TAP controller 44 (FIG. 2) are well known,
activities occurring during these states as a result of mode selection
logic 58 permit BSIC 28 to operate in accordance with the teaching of the
present invention. In particular, these activities relate to the operation
of BSIC 28 while system action instructions are active. BSIC 28 then
operates in a pin-permission mode. Instructions become active as TAP
controller 44 passes through Update-IR state 78. These system action
instructions are known and include EXTEST, INTEST, RUNBIST, CLAMP, and
HIGHZ instructions. Generally speaking, system action instructions require
Boundary-Scan testing to influence signals at pins 30, 32 (FIG. 2). In
contrast, when non-system action instructions are active, BSIC 28 operates
in a non-invasive mode. Non-system action instructions include BYPASS,
SAMPLE/PRELOAD, IDCODE, and USERCODE instructions. When non-system action
instructions are active, data may be shifted through chain 24 (FIG. 1)
without influencing signals present on pins 30, 32 or system operations of
BSICs 28 in system 10.
As noted in FIG. 3, when a system action instruction is active, pins 30, 32
(FIG. 2) are isolated from core logic 34 during Run-Test/Idle state 62,
Select-DR-Scan state 64, Capture-DR state 66, and Update-DR state 88.
However, pins 30, 32 are coupled to core logic 34 during Test-Logic-Reset
state 60, all of instruction register (IR) states 68, 70, 72, 74, 76, 78,
80, and data register (DR) states 82, 84, 86, 90, regardless of whether a
system action instruction is active.
FIG. 4 is a block diagram of an embodiment of mode selection logic 58 in
cooperation with BS cells 36, specifically illustrating one BS cell 36
associated with input pin 30 and one BS cell 36 associated with output pin
32. Any number of cells 36 may be included in BSIC 28.
BS cells 36 may be conventionally implemented. For example, for any BS cell
36, one data input of multiplexer (MUX) 92 may receive a system signal via
input pin 30 or core logic 34. Another data input of multiplexer 92 may
receive serial data through TDI pin 40. A selection input of MUX 92 may be
driven by a signal from state decoder 46 (FIG. 2) indicating when TAP
controller 44 (FIGS. 2-3) is operating in Shift-DR state 82 (FIG. 3).
Polarities may be arranged so that serial data from the direction of TDI
pin 40 is presented at the output of multiplexer 92 during Shift-DR state
82, and the system signal is presented at the output of multiplexer 92
during all other states.
The output of multiplexer 92 may drive a data input of capture flip-flop
(CAP FF) 94. Capture flip-flop 94 may receive a clock signal with timing
equivalent to the TCK signal when operating in data register (DR) states
64, 66, 82, 84, 86, 88, 90. While shifting data through chain 24 (FIG. 1),
capture flip-flop 94 serves as Boundary-Scan register 38 (FIG. 2). When
performing an EXTEST instruction, capture flip-flop 94 for BS cell 36
associated with input pin 30 captures the signal present at pin 30. When
performing an INTEST instruction, capture flip-flop 94 for BS cell 36
associated with output pin 32 captures a signal generated by core logic
34.
The output of capture flip-flop 94 couples to a data input of an update
flip-flop (UPD FF) 96. Update flip-flop 96 desirably receives a clock
signal at the end of Update-DR state 88 (FIG. 3). Accordingly, a dou | | |
