差别
这里会显示出您选择的修订版和当前版本之间的差别。
| 两侧同时换到之前的修订记录 前一修订版 后一修订版 | 前一修订版 | ||
|
jtag [2016/05/31 14:39] admin [Boundary scan register] |
jtag [2021/09/13 23:31] (当前版本) gongyu |
||
|---|---|---|---|
| 行 1: | 行 1: | ||
| - | The Joint Test Action Group (JTAG) is an electronics industry association formed in 1985 for developing a method of verifying designs and testing printed circuit boards after manufacture. In 1990 the Institute of Electrical and Electronics Engineers codified the results of the effort in IEEE Standard 1149.1-1990, entitled Standard Test Access Port and Boundary-Scan Architecture. | + | ## 什么是JTAG? |
| - | JTAG implements standards for on-chip instrumentation in electronic design automation (EDA) as a complementary tool to digital simulation.[1] It specifies the use of a dedicated debug port implementing a serial communications interface for low-overhead access without requiring direct external access to the system address and data buses. The interface connects to an on-chip test access port (TAP) that implements a stateful protocol to access a set of test registers that present chip logic levels and device capabilities of various parts. | + | JTAG is an IEEE standard (1149.1) developed in the 1980s to solve electronic boards manufacturing issues. Nowadays it finds more use as programming, debug and probing port. |
| - | The JTAG standards have been extended by many semiconductor chip manufacturers with specialized variants to provide vendor-specific features. | + | But first, let's see JTAG's original use, boundary testing. |
| - | ====History==== | + | ====== 边界测试 ====== |
| - | In the 1980s, multi-layer circuit boards and non-lead-frame integrated circuits (ICs) were becoming standard and connections were being made between ICs that were not available to probes. The majority of manufacturing and field faults in circuit boards were due to poor solder joints on the boards, imperfections in board connections, or the bonds and bond wires from IC pads to pin lead frames. The Joint Test Action Group (JTAG) was formed in 1985 to provide a pins-out view from one IC pad to another so these faults could be discovered. | + | |
| - | The industry standard became an IEEE standard in 1990 as IEEE Std. 1149.1-1990[3] after many years of initial use. In the same year Intel released the first processor, the 80486, with JTAG which led to quicker industry adoption by all manufacturers. In 1994, a supplement that contains a description of the boundary scan description language (BSDL) was added. Further refinements regarding the use of all-zeros for EXTEST, separating the use of SAMPLE from PRELOAD and better implementation for OBSERVE_ONLY cells were made and released in 2001.[4] Since 1990, this standard has been adopted by electronics companies world-wide. Boundary-scan is now mostly synonymous with JTAG, but JTAG has essential uses beyond such manufacturing applications. | + | Here's a simple electronic board (also called "PCB" for "printed circuit board") with two ICs ("integrated circuits"), a CPU and an FPGA. A typical board may have many more ICs. |
| + | {{ :jtag1.gif |}} | ||
| - | ===Debugging=== | + | ICs can have lots of pins. So of course, ICs are connected together with lots of connections (PCB traces). |
| - | Although JTAG's early applications targeted board level testing, the JTAG standard was designed to assist with device, board, and system testing, diagnosis, and fault isolation. Today JTAG is used as the primary means of accessing sub-blocks of integrated circuits, making it an essential mechanism for debugging embedded systems which may not have any other debug-capable communications channel. On most systems, JTAG-based debugging is available from the very first instruction after CPU reset, letting it assist with development of early boot software which runs before anything is set up. An in-circuit emulator (or, more correctly, a "JTAG adapter") uses JTAG as the transport mechanism to access on-chip debug modules inside the target CPU. Those modules let software developers debug the software of an embedded system directly at the machine instruction level when needed, or (more typically) in terms of high level language source code. | + | We show just four here. But you can easily have a few thousands on a PCB. |
| + | {{ :jtag2.gif |}} | ||
| - | System software debug support is for many software developers the main reason to be interested in JTAG. Many silicon architectures such as PowerPC, MIPS, ARM, x86 built an entire software debug, instruction tracing, and data tracing infrastructure around the basic JTAG protocol. Frequently individual silicon vendors however only implement parts of these extensions. Some examples are ARM CoreSight and Nexus as well as Intel's BTS (Branch Trace Storage), LBR (Last Branch Record), and IPT (Intel Processor Trace) implementations. There are many other such silicon vendor-specific extensions that may not be documented except under NDA. The adoption of the JTAG standard helped move JTAG-centric debugging environments away from early processor-specific designs. Processors can normally be halted, single stepped, or let run freely. One can set code breakpoints, both for code in RAM (often using a special machine instruction) and in ROM/flash. Data breakpoints are often available, as is bulk data download to RAM. Most designs have “halt mode debugging”, but some allow debuggers to access registers and data buses without needing to halt the core being debugged. Some toolchains can use ARM Embedded Trace Macrocell (ETM) modules, or equivalent implementations in other architectures to trigger debugger (or tracing) activity on complex hardware events, like a logic analyzer programmed to ignore the first seven accesses to a register from one particular subroutine. | + | Now if you build a thousand boards, each with a few a thousand connections, you inevitably have a few bad boards. How do you test all these boards? You have to make sure that all these connections are fine. You can't just test all these connections by hand. So JTAG was created. |
| + | {{ :jtag3.gif |}} | ||
| - | Sometimes FPGA developers also use JTAG to develop debugging tools.[5] The same JTAG techniques used to debug software running inside a CPU can help debug other digital design blocks inside an FPGA. For example, custom JTAG instructions can be provided to allow reading registers built from arbitrary sets of signals inside the FPGA, providing visibility for behaviors which are invisible to boundary scan operations. Similarly, writing such registers could provide controllability which is not otherwise available. | + | JTAG can take control (or hijack) the pins of all the ICs. On the picture, maybe JTAG is going to make all the CPU pins outputs, and all the FPGA pins inputs. Then by sending some data from the CPU pins, and reading the values from the FPGA pins, JTAG can make sure that the board connections are fine. It is called an "IC boundary test". |
| - | ===Storing firmware=== | + | Now JTAG really consists of four logic signal, named TDI, TDO, TMS and TCK. From the PC's point of view, that's three outputs, and one input. |
| - | JTAG allows device programmer hardware to transfer data into internal non-volatile device memory (e.g. CPLDs). Some device programmers serve a double purpose for programming as well as debugging the device. In the case of FPGAs, volatile memory devices can also be programmed via the JTAG port, normally during development work. In addition, internal monitoring capabilities (temperature, voltage and current) may be accessible via the JTAG port. | + | {{ :jtag4.gif |}} |
| + | These four signals need to be wired in a particular way. First TMS and TCK are wired in parallel to all JTAG ICs. | ||
| + | {{ :jtag5.gif |}} | ||
| - | JTAG programmers are also used to write software and data into flash memory. This is usually done using data bus access like the CPU would use, and is sometimes actually handled by a CPU, but in other cases memory chips have JTAG interfaces themselves. Some modern debug architectures provide internal and external bus master access without needing to halt and take over a CPU. In the worst case, it is usually possible to drive external bus signals using the boundary scan facility. | + | Then TDI and TDO and connected to form a chain. In JTAG terminology, you often hear the term "JTAG-chain", that's where it comes from. |
| + | {{ :jtag6.gif |}} | ||
| - | As a practical matter, when developing an embedded system, emulating the instruction store is the fastest way to implement the "debug cycle" (edit, compile, download, test, and debug).[citation needed] This is because the in-circuit emulator simulating an instruction store can be updated very quickly from the development host via, say, USB. Using a serial UART port and bootloader to upload firmware to Flash makes this debug cycle quite slow and possibly expensive in terms of tools; installing firmware into Flash (or SRAM instead of Flash) via JTAG is an intermediate solution between these extremes. | + | As you can see, each JTAG compliant IC has four pins used for JTAG (three inputs, and one output). A fifth pin named TRST is optional (JTAG reset). The JTAG pins are usually dedicated (not shared for other purposes). |
| - | ===Boundary scan testing=== | + | All big ICs use boundary testing using JTAG - boundary testing is the original reason JTAG was created. |
| - | JTAG boundary scan technology provides access to many logic signals of a complex integrated circuit, including the device pins. The signals are represented in the boundary scan register (BSR) accessible via the TAP. This permits testing as well as controlling the states of the signals for testing and debugging. Therefore, both software and hardware (manufacturing) faults may be located and an operating device may be monitored. | + | |
| - | When combined with built-in self-test (BIST), the JTAG scan chain enables a low overhead, embedded solution to testing an IC for certain static faults (shorts, opens, and logic errors). The scan chain mechanism does not generally help diagnose or test for timing, temperature or other dynamic operational errors that may occur. Test cases are often provided in standardized formats such as SVF, or its binary sibling XSVF, and used in production tests. The ability to perform such testing on finished boards is an essential part of Design For Test in today's products, increasing the number of faults that can be found before products ship to customers. | + | But wouldn't it be nice to use JTAG for more purposes than just boundary testing? |
| - | ====Electrical characteristics==== | + | * CPU and FPGA manufacturers allow JTAG to be used as debug port. |
| - | A JTAG interface is a special interface added to a chip. Depending on the version of JTAG, two, four, or five pins are added. The four and five pin interfaces are designed so that multiple chips on a board can have their JTAG lines daisy-chained together if specific conditions are met.[6] The two pin interface is designed so that multiple chips can be connected in a star topology. In either case a test probe need only connect to a single "JTAG port" to have access to all chips on a circuit board. | + | * FPGA manufacturers also allow configuring the FPGA through JTAG, and use the JTAG signals inside the FPGA core. |
| - | ===Daisy-chained JTAG (IEEE 1149.1)=== | + | ====== JTAG的工作原理 ====== |
| - | The connector pins are | + | |
| - | * TDI (Test Data In) | + | |
| - | * TDO (Test Data Out) | + | |
| - | * TCK (Test Clock) | + | |
| - | * TMS (Test Mode Select) | + | |
| - | * TRST (Test Reset) optional. | + | |
| - | Test reset signal is not shown in the image. | + | |
| - | {{ :654px-jtag_chain.svg.png |}} | + | |
| - | <WRAP centeralign> **Example of JTAG chain** </WRAP> | + | |
| - | The TRST pin is an optional active-low reset to the test logic - usually asynchronous, but sometimes synchronous, depending on the chip. If the pin is not available, the test logic can be reset by switching to the reset state synchronously, using TCK and TMS. Note that resetting test logic doesn't necessarily imply resetting anything else. There are generally some processor-specific JTAG operations which can reset all or part of the chip being debugged. | + | |
| - | Since only one data line is available, the protocol is serial. The clock input is at the TCK pin. One bit of data is transferred in from TDI, and out to TDO per TCK rising clock edge. Different instructions can be loaded. Instructions for typical ICs might read the chip ID, sample input pins, drive (or float) output pins, manipulate chip functions, or bypass (pipe TDI to TDO to logically shorten chains of multiple chips). | + | Now that we know how to connect JTAG to different ICs, let's see in details how JTAG works and how to control it from a PC. |
| - | As with any clocked signal, data presented to TDI must be valid for some chip-specific Setup time before and Hold time after the relevant (here, rising) clock edge. TDO data is valid for some chip-specific time after the falling edge of TCK. | + | ===== Control JTAG from your PC ===== |
| - | The maximum operating frequency of TCK varies depending on all chips in the chain (the lowest speed must be used), but it is typically 10-100 MHz (100-10 ns per bit). Also TCK frequencies depend on board layout and JTAG adapter capabilities and state. One chip might have a 40 MHz JTAG clock, but only if it is using a 200 MHz clock for non-JTAG operations; and it might need to use a much slower clock when it is in a low power mode. Accordingly, some JTAG adapters have adaptive clocking using an RTCK (Return TCK) signal. Faster TCK frequencies are most useful when JTAG is used to transfer lots of data, such as when storing a program executable into flash memory. | + | You use a "JTAG cable" to control a JTAG bus from a PC. The JTAG cable is just a way to control the four JTAG signals from the PC. |
| - | Clocking changes on TMS steps through a standardized JTAG state machine. The JTAG state machine can reset, access an instruction register, or access data selected by the instruction register. | + | The JTAG cable might connect to a PC's |
| - | JTAG platforms often add signals to the handful defined by the IEEE 1149.1 specification. A System Reset (SRST) signal is quite common, letting debuggers reset the whole system, not just the parts with JTAG support. Sometimes there are event signals used to trigger activity by the host or by the device being monitored through JTAG; or, perhaps, additional control lines. | + | * Parallel (printer) port |
| + | * USB port | ||
| + | * Ethernet port | ||
| - | Even though few consumer products provide an explicit JTAG port connector, the connections are often available on the printed circuit board as a remnant from development prototyping and/or production. When exploited, these connections often provide the most viable means for reverse engineering. | + | The simplest is a parallel port JTAG cable. |
| + | USB and Ethernet JTAG cables are good too. They are faster at streaming large amount of data, but more complex to control and with more overhead (=slower) for small amount of data. | ||
| - | ===Reduced pin count JTAG (IEEE 1149.7)=== | + | ==== The parallel port ==== |
| - | Reduced pin count JTAG uses only two wires, a clock wire and a data wire. This is defined as part of the IEEE 1149.7 standard. The connector pins are | + | |
| - | * TMSC (Test Serial Data) | + | |
| - | * TCK (Test Clock) | + | |
| - | {{ :example_of_reduced_pin_count_jtag_interface.svg.png |}} | + | |
| - | <WRAP centeralign> **Example of JTAG with reduced pin count **</WRAP> | + | |
| - | The two wire interface reduced pressure on the number of pins, and devices can be connected in a star topology. [8] The star topology enables some parts of the system to be powered down, while others can still be accessed over JTAG; a daisy chain requires all JTAG interfaces to be powered. Other two-wire interfaces exist, such as Serial Wire Debug. | + | A parallel port can be regarded as a twelve bits output from the PC, and a five bits input to the PC. JTAG just requires a three bits output and a one bit input, so that's no problem. For example, take a look at the schematic of Xilinx's parallel-III cable. You can see on the left the PC's parallel signals, one the right the JTAG connector, and in the middle a few 74HC125 electronic buffers. |
| - | ====Communications model==== | + | From the software point of view, a parallel port is ideal since it is very easy to control. |
| - | In JTAG, devices expose one or more test access ports (TAPs). The picture above shows three TAPs, which might be individual chips or might be modules inside one chip. A daisy chain of TAPs is called a scan chain, or (loosely) a target. Scan chains can be arbitrarily long, but in practice twenty TAPs is unusually long. | + | For example, here's C code that shows how to toggle the TCK signal for an Altera ByteBlaster JTAG cable. |
| + | <code c> | ||
| + | #define lpt_addr 0x378 | ||
| + | #define TCK 0x01 | ||
| - | To use JTAG, a host is connected to the target's JTAG signals (TMS, TCK, TDI, TDO, etc.) through some kind of JTAG adapter, which may need to handle issues like level shifting and galvanic isolation. The adapter connects to the host using some interface such as USB, PCI, Ethernet, and so forth. | + | void toggle_TCK() |
| + | { | ||
| + | outport(lpt_addr, 0); | ||
| + | outport(lpt_addr, TCK); | ||
| + | outport(lpt_addr, 0); | ||
| + | } | ||
| + | </code> | ||
| - | ====Primitives==== | + | One minor problem with Windows 2000/XP/Vista is that the "outport" IO instruction is restricted, but GiveIO and UserPort are free generic drivers that open up the IO space. |
| - | The host communicates with the TAPs by manipulating TMS and TDI in conjunction with TCK, and reading results through TDO (which is the only standard host-side input). TMS/TDI/TCK output transitions create the basic JTAG communication primitive on which higher layer protocols build: | + | |
| - | * State switching ... All TAPs are in the same state, and that state changes on TCK transitions. This JTAG state machine is part of the JTAG spec, and includes sixteen states. There are six “stable states” where keeping TMS stable prevents the state from changing. In all other states, TCK always changes that state. In addition, asserting TRST forces entry to one of those stable states (Test_Logic_Reset), in a slightly quicker way than the alternative of holding TMS high and cycling TCK five times. | + | ==== The JTAG TAP controller ==== |
| - | * Shifting ... Most parts of the JTAG state machine support two stable states used to transfer data. Each TAP has an instruction register (IR) and a data register (DR). The size of those registers varies between TAPs, and those registers are combined through TDI and TDO to form a large shift register. (The size of the DR is a function of the value in that TAP's current IR, and possibly of the value specified by a SCAN_N instruction.) There are three operations defined on that shift register: | + | |
| - | * Capturing a temporary value | + | |
| - | * Entry to the Shift_IR stable state goes via the Capture_IR state, loading the shift register with a partially fixed value (not the current instruction) | + | |
| - | * Entry to the Shift_DR stable state goes via the Capture_DR state, loading the value of the Data Register specified by the TAP's current IR. | + | |
| - | * Shifting that value bit-by-bit, in either the Shift_IR or Shift_DR stable state; TCK transitions shift the shift register one bit, from TDI towards TDO, exactly like a SPI mode 1 data transfer through a daisy chain of devices (with TMS=0 acting like the chip select signal, TDI as MOSI, etc.). | + | |
| - | * Updating IR or DR from the temporary value shifted in, on transition through the Update_IR or Update_DR state. Note that it is not possible to read (capture) a register without writing (updating) it, and vice versa. A common idiom adds flag bits to say whether the update should have side effects, or whether the hardware is ready to execute such side effects. | + | |
| - | * Running ... One stable state is called Run_Test/Idle. The distinction is TAP-specific. Clocking TCK in the Idle state has no particular side effects, but clocking it in the Run_Test state may change system state. For example, some ARM9 cores support a debugging mode where TCK cycles in the Run_Test state drive the instruction pipeline. | + | |
| - | So at a basic level, using JTAG involves reading and writing instructions and their associated data registers; and sometimes involves running a number of test cycles. Behind those registers is hardware that is not specified by JTAG, and which has its own states that is affected by JTAG activities. | + | We know that a PC is connected to the JTAG bus as illustrated here: |
| + | {{ :jtag6.gif |}} | ||
| - | Most JTAG hosts use the shortest path between two states, perhaps constrained by quirks of the adapter. (For example, one adapter[which?] only handles paths whose lengths are multiples of seven bits.) Some layers built on top of JTAG monitor the state transitions, and use uncommon paths to trigger higher level operations. Some ARM cores use such sequences to enter and exit a two-wire (non-JTAG) SWD mode. A Zero Bit Scan (ZBS) sequence is used in IEEE 1149.7[7] to access advanced functionality such as switching TAPs into and out of scan chains, power management, and a different two-wire mode. | + | So we have 4 signals (TDI, TDO, TMS, TCK) to take care of. |
| - | ===JTAG IEEE Std 1149.1 (boundary scan) instructions=== | + | === TCK === |
| - | Instruction register sizes tend to be small, perhaps four or seven bits wide. Except for BYPASS and EXTEST, all instruction opcodes are defined by the TAP implementor, as are their associated data registers; undefined instruction codes should not be used. Two key instructions are: | + | |
| - | * The BYPASS instruction, an opcode of all ones regardless of the TAP's instruction register size, must be supported by all TAPs. The instruction selects a single bit data register (also called BYPASS). The instruction allows this device to be bypassed (do nothing) while other devices in the scan path are exercised. | ||
| - | * The optional IDCODE instruction, with an implementor-defined opcode. IDCODE is associated with a 32-bit register (IDCODE). Its data uses a standardized format that includes a manufacturer code (derived from the JEDEC Standard Manufacturer's Identification Code standard, JEP-106), a part number assigned by the manufacturer, and a part version code. IDCODE is widely, but not universally, supported. | ||
| - | On exit from the RESET state, the instruction register is preloaded with either BYPASS or IDCODE. This allows JTAG hosts to identify the size and, at least partially, contents of the scan chain to which they are connected. (They can enter the RESET state then scan the Data Register until they read back the data they wrote. A BYPASS register has only a zero bit; while an IDCODE register is 32-bits and starts with a one. So the bits not written by the host can easily be mapped to TAPs.) Such identification is often used to sanity check manual configuration, since IDCODE is often unspecific. It could for example identify an ARM Cortex-M3 based microcontroller, without specifying the microcontroller vendor or model; or a particular FPGA, but not how it has been programmed. | + | TCK is the JTAG clock signal. The other JTAG signals (TDI, TDO, TMS) are synchronous to TCK. So TCK has to toggle for anything to happen (usually things happen on TCK's rising edge). |
| - | A common idiom involves shifting BYPASS into the instruction registers of all TAPs except one, which receives some other instruction. That way all TAPs except one expose a single bit data register, and values can be selectively shifted into or out of that one TAP's data register without affecting any other TAP. | + | === TMS === |
| - | The IEEE 1149.1 (JTAG) standard describes a number of instructions to support boundary scan applications. Some of these instructions are "mandatory", but TAPs used for debug instead of boundary scan testing sometimes provide minimal or no support for these instructions. Those "mandatory" instructions operate on the Boundary Scan Register (BSR) defined in the BSDL file, and include: | + | Inside each JTAG IC, there is a JTAG TAP controller. On the figure above, that means that there is a TAP controller in the CPU and another in the FPGA. |
| - | * EXTEST for external testing, such as using pins to probe board-level behaviors | + | The TAP controller is mainly a state machine with 16 states. TMS is the signal that controls the TAP controller. Since TMS is connected to all the JTAG ICs in parallel, all the TAP controllers move together (to the same state). |
| - | * PRELOAD loading pin output values before EXTEST (sometimes combined with SAMPLE) | + | |
| - | * SAMPLE reading pin values into the boundary scan register | + | |
| - | IEEE-defined "Optional" instructions include: | + | Here's the TAP controller state machine: |
| + | {{ :jtag_tap.gif |}} | ||
| - | * CLAMP a variant of BYPASS which drives the output pins using the PRELOADed values | + | The little numbers ("0" or "1") close to each arrow are the value of TMS to change state. So for example, if a TAP controller is at state "Select DR-Scan" and TMS is "0" and TCK toggles, the state changes to "Capture-DR". |
| - | * HIGHZ deactivates the outputs of all pins | + | |
| - | * INTEST for internal testing, such as using pins to probe on-chip behaviors | + | |
| - | * RUNBIST places the chip in a self-test mode | + | |
| - | * USERCODE returns a user-defined code, for example to identify which FPGA image is active | + | |
| - | Devices may define more instructions, and those definitions should be part of a BSDL file provided by the manufacturer. They are often only marked as PRIVATE. | + | |
| - | ===Boundary scan register=== | + | For JTAG to work properly, the tap controllers of a JTAG chain must always be in the same state. After power-up, they may not be in sync, but there is a trick. Look at the state machine and notice that no matter what state you are, if TMS stays at "1" for five clocks, a TAP controller goes back to the state "Test-Logic-Reset". That's used to synchronize the TAP controllers. |
| - | Devices communicate to the world via a set of input and output pins. By themselves, these pins provide limited visibility into the workings of the device. However, devices that support boundary scan contain a shift-register cell for each signal pin of the device. These registers are connected in a dedicated path around the device's boundary (hence the name). The path creates a virtual access capability that circumvents the normal inputs and outputs, providing direct control of the device and detailed visibility for signals.[9] | + | |
| - | The contents of the boundary scan register, including signal I/O capabilities, are usually described by the manufacturer using a part-specific BSDL file. These are used with design 'netlists' from CAD/EDA systems to develop tests used in board manufacturing. Commercial test systems often cost several thousand dollars for a complete system, and include diagnostic options to pinpoint faults such as open circuits and shorts. They may also offer schematic or layout viewers to depict the fault in a graphical manner. | + | So let's say we want to go to "Shift-IR" after power-up: |
| + | <code c> | ||
| + | // first sync everybody to the test-logic-reset state | ||
| + | for(i=0; i<5; i++) JTAG_clock(TMS); | ||
| - | To enable boundary scanning, IC vendors add logic to each of their devices, including scan cells for each of the signal pins. These cells are then connected together to form the boundary scan shift register (BSR), which is connected to a TAP controller. These designs are parts of most Verilog or VHDL libraries. Overhead for this additional logic is minimal, and generally is well worth the price to enable efficient testing at the board level. | + | // now that everybody is in a known and identical state, we can move together to another state |
| + | // let's go to Shift-IR | ||
| + | JTAG_clock(0); | ||
| + | JTAG_clock(TMS); | ||
| + | JTAG_clock(TMS); | ||
| + | JTAG_clock(0); | ||
| + | JTAG_clock(0); | ||
| + | </code> | ||
| - | ====Example: ARM11 debug TAP==== | + | === TDI and TDO === |
| - | An example helps show the operation of JTAG in real systems. The example here is the debug TAP of an ARM11 processor, the ARM1136[10] core. The processor itself has extensive JTAG capability, similar to what is found in other CPU cores, and it is integrated into chips with even more extensive capabilities accessed through JTAG. | + | |
| - | So this is a non-trivial example, which is representative of a significant cross section of JTAG-enabled systems. In addition, it shows how control mechanisms are built using JTAG's register read/write primitives, and how those combine to facilitate testing and debugging complex logic elements; CPUs are common, but FPGAs and ASICs include other complex elements which need to be debugged. | + | Now that we know how to change state, we can use the two most important JTAG states, namely "Shift-DR" and "Shift-IR". |
| + | {{ :jtag_tap2.gif |}} | ||
| - | Licensees of this core integrate it into chips, usually combining it with other TAPs as well as numerous peripherals and memory. One of those other TAPs handles boundary scan testing for the whole chip; it is not supported by the debug TAP. Examples of such chips include: | + | Shift-DR and Shift-IR are used in combination with the TDI and TDO lines. |
| + | Let's start with Shift-IR. | ||
| - | The OMAP2420, which includes a boundary scan TAP, the ARM1136 Debug TAP, an ETB11 trace buffer TAP, a C55x DSP, and a TAP for an ARM7 TDMI-based imaging engine, with the boundary scan TAP ("ICEpick-B") having the ability to splice TAPs into and out of the JTAG scan chain.[11] | + | There is one register into each IC TAP controller called IR, the "instruction register". You write a value into this register that corresponds to what you want to do with JTAG (each IC has a list of possible instructions). |
| - | The i.MX31 processor, which is similar, although its "System JTAG" boundary scan TAP,[12] which is very different from ICEpick, and it includes a TAP for its DMA engine instead of a DSP and imaging engine. | + | |
| - | Those processors are both intended for use in wireless handsets such as cell phones, which is part of the reason they include TAP controllers which modify the JTAG scan chain: Debugging low power operation requires accessing chips when they are largely powered off, and thus when not all TAPs are operational. That scan chain modification is one subject of a forthcoming IEEE 1149.7[7] standard. | + | |
| - | ====JTAG facilities==== | + | Also each IC IR register has a specific length. For example, let's say that the CPU's IR is 5 bits long, and the FPGA's IR is 10 bits long. The IR registers form a chain that is loaded through the TDI and TDO pins. |
| - | This debug TAP exposes several standard instructions, and a few specifically designed for hardware-assisted debugging, where a software tool (the "debugger") uses JTAG to communicate with a system being debugged: | + | {{ :jtag7.gif |}} |
| - | BYPASS and IDCODE, standard instructions as described above | + | From the PC point of view, the above IR chain is 15 bits long. |
| - | EXTEST, INTEST, standard instructions, but operating on the core instead of an external boundary scan chain. EXTEST is nominally for writing data to the core, INTEST is nominally for reading it; but two scan chains are exceptions to that rule. | + | To load IR values, the PC has to make sure the TAP controllers are in the Shift-IR state, and send 15 bits through TDI. Once shifted, the first 10 bits actually end up into the FPGA IR, and the last 5 bits into the CPU IR. If the PC was sending more than 15 bits, it would start receiving back what it sent (with a delay of 15 clocks) on TDO. |
| - | SCAN_N ARM instruction to select the numbered scan chain used with EXTEST or INTEST. There are six scan chains: | + | |
| - | 0 - Device ID Register, 40 bits of read-only identification data | + | |
| - | 1 - Debug Status and Control Register (DSCR), 32 bits used to operate the debug facilities | + | |
| - | 4 - Instruction Transfer Register (ITR), 33 bits (32 instruction plus one status bit) used to execute processor instructions while in a special "Debug Mode" (see below) | + | |
| - | 5 - Debug Communications Channel (DCC), 34 bits (one long data word plus two status bits) used for bidirectional data transfer to the core. This is used both in debug mode, and possibly at runtime when talking to debugger-aware software. | + | |
| - | 6 - Embedded Trace Module (ETM), 40 bits (7 bit address, one 32-bit long data word, and a R/W bit) used to control the operation of a passive instruction and data trace mechanism. This feeds either an on-chip Embedded Trace Buffer (ETB), or an external high speed trace data collection pod. Tracing supports passive debugging (examining execution history) and profiling for performance tuning. | + | |
| - | 7 - debug module, 40 bits (7 bit address, one 32-bit long data word, and a R/W bit) used to access hardware breakpoints, watchpoints, and more. These can be written while the processor is running; it does not need to be in Debug Mode. | + | |
| - | HALT and RESTART, ARM11-specific instructions to halt and restart the CPU. Halting it puts the core into the "Debug Mode", where the ITR can be used to execute instructions, including using the DCC to transfer data between the debug (JTAG) host and the CPU. | + | |
| - | ITRSEL, ARM11-specific instruction to accelerate some operations with ITR. | + | |
| - | That model resembles the model used in other ARM cores. Non-ARM systems generally have similar capabilities, perhaps implemented using the Nexus protocols on top of JTAG, or other vendor-specific schemes. | + | |
| - | Older ARM7 and ARM9 cores include an EmbeddedICE module[13] which combines most of those facilities, but has an awkward mechanism for instruction execution: the debugger must drive the CPU instruction pipeline, clock by clock, and directly access the data buses to read and write data to the CPU. The ARM11 uses the same model for trace support (ETM, ETB) as those older cores. | + | For example, let's send 00100 into the CPU's IR, and 0000000010 into the FPGA's IR. |
| + | <code c> | ||
| + | // Because the bits are shifted through in a chain, we must start sending the data for the device that is at the end of the chain | ||
| + | // so we send the 10 FPGA IR bits first | ||
| + | JTAG_clock(0); | ||
| + | JTAG_clock(1); | ||
| + | JTAG_clock(0); | ||
| + | JTAG_clock(0); | ||
| + | JTAG_clock(0); | ||
| + | JTAG_clock(0); | ||
| + | JTAG_clock(0); | ||
| + | JTAG_clock(0); | ||
| + | JTAG_clock(0); | ||
| + | JTAG_clock(0); | ||
| - | Newer ARM cores within the Sitara Family, such as the Cortex-A8, closely resemble this debug model, but build on a Debug Access Port (DAP) instead of direct CPU access. In this architecture (named CoreSight Technology), core and JTAG module is completely independent. They are also decoupled from JTAG so they can be hosted over ARM's two-wire SWD interface (see below) instead of just the six-wire JTAG interface. (ARM takes the four standard JTAG signals and adds the optional TRST, plus the RTCK signal used for adaptive clocking.) Also, the newer cores have updated trace support. | + | // then send the 5 CPU IR bits |
| + | JTAG_clock(0); | ||
| + | JTAG_clock(0); | ||
| + | JTAG_clock(1); | ||
| + | JTAG_clock(0); | ||
| + | JTAG_clock(0 | TMS); // last bit needs to have TMS active (to exit shift-IR) | ||
| + | </code> | ||
| - | ====Halt mode debugging==== | + | In our example, the CPU's IR is 5 bits long (i.e. can hold values from 0 to 31). That means it can support up to 32 JTAG instructions. In practice, a CPU probably uses 5 to 10 instructions, and the remaining IR values are unused. |
| - | One basic way to debug software is to present a single threaded model, where the debugger periodically stops execution of the program and examines its state as exposed by register contents and memory (including peripheral controller registers). When interesting program events approach, a person may want to single step instructions (or lines of source code) to watch how a particular misbehavior happens. | + | |
| - | So for example a JTAG host might HALT the core, entering Debug Mode, and then read CPU registers using ITR and DCC. After saving processor state, it could write those registers with whatever values it needs, then execute arbitrary algorithms on the CPU, accessing memory and peripherals to help characterize the system state. After the debugger performs those operations, the state may be restored and execution continued using the RESTART instruction. | + | Same thing for the FPGA, with a 10 bits long IR, it can hold 1024 instructions, with most of them unused. |
| - | Debug mode is also entered asynchronously by the debug module triggering a watchpoint or breakpoint, or by issuing a BKPT (breakpoint) instruction from the software being debugged. When it is not being used for instruction tracing, the ETM can also trigger entry to debug mode; it supports complex triggers sensitive to state and history, as well as the simple address comparisons exposed by the debug module. Asynchronous transitions to debug mode are detected by polling the DSCR register. This is how single stepping is implemented: HALT the core, set a temporary breakpoint at the next instruction or next high-level statement, RESTART, poll DSCR until you detect asynchronous entry to debug state, remove that temporary breakpoint, repeat. | + | JTAG has a few mandatory instructions (what these instructions do will be illustrated later): |
| - | ====Monitor mode debugging==== | + | * BYPASS |
| - | Modern software is often too complex to work well with such a single threaded model. For example, a processor used to control a motor (perhaps one driving a saw blade) may not be able to safely enter halt mode; it may need to continue handling interrupts to ensure physical safety of people and/or machinery. Issuing a HALT instruction using JTAG might be dangerous. | + | * EXTEST |
| + | * SAMPLE/PRELOAD | ||
| + | * IDCODE (not mandatory but very often implemented) | ||
| + | To get the list of possible IR values supported by a specific IC, check the IC's datasheet (or BSDL file - more on that later). | ||
| - | ARM processors support an alternative debug mode, called Monitor Mode, to work with such situations. (This is distinct from the Secure Monitor Mode implemented as part of security extensions on newer ARM cores; it manages debug operations, not security transitions.) In those cases, breakpoints and watchpoints trigger a special kind of hardware exception, transferring control to a "debug monitor" running as part of the system software. This monitor communicates with the debugger using the DCC, and could arrange for example to single step only a single process while other processes (and interrupt handlers) continue running. | + | ==== DR registers ==== |
| - | ====Common extensions==== | + | Each TAP controller has only one IR register, but has multiple DR registers. The DR registers are similar to the IR registers (they are shifted the same way the IR registers are but using the Shift-DR state instead of the Shift-IR). |
| - | Microprocessor vendors have often defined their own core-specific debugging extensions. Such vendors include Infineon, MIPS with EJTAG, and more. If the vendor does not adopt a standard (such as the ones used by ARM processors; or Nexus), they need to define their own solution. If they support boundary scan, they generally build debugging over JTAG. | + | |
| - | Freescale has COP and OnCE (On-Chip Emulation). OnCE includes a JTAG command which makes a TAP enter a special mode where the IR holds OnCE debugging commands[14] for operations such as single stepping, breakpointing, and accessing registers or memory. It also defines EOnCE (Enhanced On-Chip Emulation)[15] presented as addressing real time concerns. | + | Each IR value selects a different DR register. So in our example, the CPU could have up to 32 DR registers (if all IR instructions were implemented). |
| - | ARM has an extensive processor core debug architecture (CoreSight) that started with EmbeddedICE (a debug facility available on most ARM cores), and now includes many additional components such as an ETM (Embedded Trace Macrocell), with a high speed trace port, supporting multi-core and multithread tracing. Note that tracing is non-invasive; systems do not need to stop operating to be traced. (However, trace data is too voluminous to use JTAG as more than a trace control channel.) | + | ====== Query the JTAG chain ====== |
| + | Count the number of devices in the JTAG chain | ||
| - | Nexus defines a processor debug infrastructure which is largely vendor-independent. One of its hardware interfaces is JTAG. It also defines a high speed auxiliary port interface, used for tracing and more. Nexus is used with some newer platforms, such as the Atmel AVR32 and Freescale MPC5500 series processors. | + | One important IR value is the "all-ones" value. For the CPU that would be 11111 and for the FPGA, that's 1111111111. This value corresponds to the mandatory IR instruction called BYPASS. In bypass mode, the TAP controller DR register is always a single flip-flop which does nothing besides delaying the TDI input by one clock cycle before outputting to TDO. |
| - | ====Uses==== | + | One interesting way to use this BYPASS mode is to count the number of ICs that are present in the JTAG chain. |
| - | Except for some of the very lowest end systems, essentially all embedded systems platforms have a JTAG port to support in-circuit debugging and firmware programming as well as for boundary scan testing: | + | If each JTAG IC delays the TDI-TDO chain by one clock, we can send some data and check by how long it is delayed. That gives us the number of ICs in the chain. |
| - | ARM architecture processors come with JTAG support, sometimes supporting a two-wire "SWD" variant or high speed tracing of traffic on instruction or data busses. | + | |
| - | Modern 8-bit and 16-bit microcontroller chips, such as Atmel AVR and TI MSP430 chips, support JTAG programming and debugging. However, the very smallest chips may not have enough pins to spare (and thus tend to rely on proprietary single-wire programming interfaces); if the pin count is over 32, there is probably a JTAG option. | + | |
| - | Almost all FPGAs and CPLDs used today can be programmed via a JTAG port. A Standard Test and Programming Language is defined by JEDEC standard JESD-71 for JTAG programming of PLD's. | + | |
| - | Many MIPS and PowerPC processors have JTAG support | + | |
| - | Intel Core, Xeon, Atom, and Quark processors all support JTAG probe mode with Intel specific extensions of JTAG using the so-called 60-pin eXtended Debug Port [XDP]. Additionally the Quark processor supports more traditional 10-pin connectors. | + | |
| - | Consumer products such as networking appliances and satellite television integrated receiver/decoders often use microprocessors which support JTAG, providing an alternate means to reload firmware if the existing bootloader has been corrupted in some manner. | + | |
| - | The PCI bus connector standard contains optional JTAG signals on pins 1-5;[16] PCI-Express contains JTAG signals on pins 5-9.[17] A special JTAG card can be used to reflash a corrupt BIOS. | + | |
| - | Boundary scan testing and in-system (device) programming applications are sometimes programmed using the Serial Vector Format, a textual representation of JTAG operations using a simple syntax. Other programming formats include 'JAM' and STAPL plus more recently the IEEE Std. 1532 defined format 'ISC' (short for In-System Configuration). ISC format is used in conjunction with enhanced BSDL models for programmable logic devices (i.e. FPGAs and CPLDs) that include addition ISC_<operation> instructions in addition to the basic bare minimum IEEE 1149.1 instructions. FPGA programming tools from Xilinx, Altera, Lattice, Cypress, Actel, etc. typically are able to export such files. | + | |
| - | As mentioned, many boards include JTAG connectors, or just pads, to support manufacturing operations, where boundary scan testing helps verify board quality (identifying bad solder joints, etc.) and to initialize flash memory or FPGAs. | + | |
| - | JTAG can also support field updates and troubleshooting. | + | |
| - | ====Client support==== | + | Here's an example: |
| - | The target's JTAG interface is accessed using some JTAG-enabled application and some JTAG adapter hardware. There is a wide range of such hardware, optimized for purposes such as production testing, debugging high speed systems, low cost microcontroller development, and so on. In the same way, the software used to drive such hardware can be quite varied. Software developers mostly use JTAG for debugging and updating firmware. | + | <code c> |
| + | // go to reset state | ||
| + | for(i=0; i<5; i++) JTAG_clock(TMS); | ||
| - | If you want to acquire a JTAG adapter, you first need to decide what systems it must support. Everything else follows from that, including your software options. Low-end adapters may cost less than $US 50 and have limited hardware and software support. High-end adapters can cost a hundred times as much, including software support, and have corresponding improvements in capability. | + | // go to Shift-IR |
| + | JTAG_clock(0); | ||
| + | JTAG_clock(TMS); | ||
| + | JTAG_clock(TMS); | ||
| + | JTAG_clock(0); | ||
| + | JTAG_clock(0); | ||
| - | ====Connectors==== | + | // Send plenty of ones into the IR registers |
| - | A Netgear FVS336G firewall with a 14 pin JTAG header at lower left. | + | // That makes sure all devices are in BYPASS! |
| - | A Netgear DG632 ADSL modem with an 8 pin JTAG header at location "5". | + | for(i=0; i<999; i++) JTAG_clock(1); |
| - | There are no official standards for JTAG adapter physical connectors. Development boards usually include a header to support preferred development tools; in some cases they include multiple such headers, because they need to support multiple such tools. For example, a microcontroller, FPGA, and ARM application processor rarely shares tools, so a development board using all of those components might have three or more headers. Production boards may omit the headers; or when space is tight, just provide JTAG signal access using test points. | + | JTAG_clock(1 | TMS); // last bit needs to have TMS active, to exit shift-IR |
| - | Some common pinouts[18] for 2.54 mm (0.100 in) pin headers are: | + | // we are in Exit1-IR, go to Shift-DR |
| + | JTAG_clock(TMS); | ||
| + | JTAG_clock(TMS); | ||
| + | JTAG_clock(0); | ||
| + | JTAG_clock(0); | ||
| - | ARM 2×10 pin (or sometimes the older 2×7), used by almost all ARM based systems | + | // Send plenty of zeros into the DR registers to flush them |
| - | MIPS EJTAG (2×7 pin) used for MIPS based systems | + | for(i=0; i<1000; i++) JTAG_clock(0); |
| - | 2×5 pin Altera ByteBlaster-compatible JTAG extended by many vendors | + | |
| - | 2×5 pin AVR extends Altera JTAG with SRST (and in some cases TRST and an event output) | + | |
| - | 2×7 pin Texas Instruments used with DSPs and ARM-based products such as OMAP | + | |
| - | 8 pin (single row) generic PLD JTAG compatible with many Lattice ispDOWNLOAD cables | + | |
| - | MIPI10-/20-connectors (1.27 mm 050") for JTAG, cJTAG and SWD | + | |
| - | Those connectors tend to include more than just the four standardized signals (TMS, TCK, TDI, TDO). Usually reset signals are provided, one or both of TRST (TAP reset) and SRST (system reset). The connector usually provides the board-under-test's logic supply voltage so that the JTAG adapters use the appropriate logic levels. The board voltage may also serve as a "board present" debugger input. Other event input or output signals may be provided, or general purpose I/O (GPIO) lines, to support more complex debugging architectures. | + | |
| - | Higher end products frequently use dense connectors (frequently 38-pin MICTOR connectors) to support high-speed tracing in conjunction with JTAG operations. A recent trend is to have development boards integrate a USB interface to JTAG, where a second channel is used for a serial port. (Smaller boards can also be powered through USB. Since modern PCs tend to omit serial ports, such integrated debug links can significantly reduce clutter for developers.) Production boards often rely on bed-of-nails connections to test points for testing and programming. | + | // now send ones until we receive one back |
| + | for(i=0; i<1000; i++) if(JTAG_clock(1)) break; | ||
| - | ====Adapter hardware==== | + | nbDevices = i; |
| - | Adapter hardware varies widely. When not integrated into a development board, it involves a short cable to attach to a JTAG connector on the target board; a connection to the debugging host, such as a USB, PCI, or Ethernet link; and enough electronics to adapt the two communications domains (and sometimes provide galvanic isolation). A separate power supply may be needed. There are both "dumb" adapters, where the host decides and performs all JTAG operations; and "smart" ones, where some of that work is performed inside the adapter, often driven by a microcontroller. The "smart" adapters eliminate link latencies for operation sequences that may involve polling for status changes between steps, and may accordingly offer faster throughput. | + | printf("There are %d device(s) in the JTAG chain\n", nbDevices); |
| + | |||
| + | </code> | ||
| - | As of 2009, adapters with full speed USB links are probably the most common approach, and new products often include high speed USB support. Higher end products often support Ethernet, with the advantage that the debug host can be quite remote. Adapters which support high speed trace ports generally include several megabytes of trace buffer and provide high speed links (USB or Ethernet) to get that data to the host. | + | Get the IDs of the devices in the JTAG chain |
| - | Personal computer parallel port adapters are simple and inexpensive, but they are relatively slow because they use the host CPU to change each bit ("bit banging"). They have declined in usefulness because newer computers do not have parallel port hardware. Driver support is also a problem, because the adapter electronics varied so widely.[citation needed] | + | Most JTAG ICs support the IDCODE instruction. In IDCODE mode, the DR register is loaded with a 32-bits value that represents the device ID. |
| - | Serial port adapters also exist, and are similarly declining in usefulness. They generally involve either slower bit banging than a parallel port, or a microcontroller translating some command protocol to JTAG operations. Such serial adapters are also not fast, but their command protocols could generally be reused on top of higher speed links. | + | Unlike for the BYPASS instruction, the IR value for the IDCODE is not standard. Fortunately, each time the TAP controller goes into Test-Logic-Reset, it goes into IDCODE mode (and loads the IDCODE into DR). |
| - | With all JTAG adapters, software support is a basic concern. Many vendors do not publish the protocols used by their JTAG adapter hardware, limiting their customers to the tool chains supported by those vendors. This is a particular issue for "smart" adapters, some of which embed significant amounts of knowledge about how to interact with specific CPUs. | + | Here's an example: |
| + | <code c> | ||
| + | // go to reset state (that loads IDCODE into IR of all the devices) | ||
| + | for(i=0; i<5; i++) JTAG_clock(TMS); | ||
| - | ====Software development==== | + | // go to Shift-DR |
| - | Most development environments for embedded software include JTAG support. There are, broadly speaking, three sources of such software: | + | JTAG_clock(0); |
| + | JTAG_clock(TMS); | ||
| + | JTAG_clock(0); | ||
| + | JTAG_clock(0); | ||
| - | Chip Vendors may provide the tools, usually requiring a JTAG adapter they supply. Examples include FPGA vendors such as Xilinx and Altera, Atmel for its AVR8 and AVR32 product lines, and Texas Instruments for most of its DSP and micro products. Such tools tend to be highly featured, and may be the only real option for highly specialized chips like FPGAs and DSPs. Lower end software tools may be provided free of charge. The JTAG adapters themselves are not free, although sometimes they are bundled with development boards. | + | // and read the IDCODES |
| - | Tool Vendors may supply them, usually in conjunction with multiple chip vendors to provide cross-platform development support. ARM-based products have a particularly rich third party market, and a number of those vendors have expanded to non-ARM platforms like MIPS and PowerPC. Tool vendors sometimes build products around free software like GCC and GDB, with GUI support frequently using Eclipse. JTAG adapters are sometimes sold along with support bundles. | + | for(i=0; i < nbDevices; i++) |
| - | Open Source tools exist. As noted above, GCC and GDB form the core of a good toolchain, and there are GUI environments to support them. | + | { |
| - | All such software tends to include basic debugger support: stopping, halting, single stepping, breakpoints, data structure browsing, and so on. Commercial tools tend to provide tools like very accurate simulators and trace analysis, which are not currently available as open source. | + | printf("IDCODE for device %d is %08X\n", i+1, JTAG_read(32)); |
| + | } | ||
| + | </code> | ||
| + | |||
| + | ====== Run a boundary-scan ====== | ||
| + | Now let's ask the TAP controllers to go into boundary-scan mode, where the DR chain goes through each IO block and can read or hijack each pin! | ||
| + | |||
| + | {{ ::jtag8.gif |}} | ||
| + | |||
| + | Boundary-scan can be used even while a device is otherwise running. So for example, using JTAG on an FPGA, you can tell the status of each pin while the FPGA is running. | ||
| + | |||
| + | ===== SAMPLE ===== | ||
| + | |||
| + | Let's try to read the value of the pins. We use a JTAG instruction called SAMPLE for that. Each IC instruction code list is different. You have to look into the IC datasheet, or the IC BSDL file to get the codes. | ||
| + | |||
| + | A BSDL file is actually a VHDL file that describes the boundary chain of an IC. | ||
| + | Here's an interesting portion of an Altera BSDL file (Cyclone EP1C3 in TQFP 100 pins package). | ||
| + | <code bsdl> | ||
| + | attribute INSTRUCTION_LENGTH of EP1C3T100 : entity is 10; | ||
| + | |||
| + | attribute INSTRUCTION_OPCODE of EP1C3T100 : entity is | ||
| + | "BYPASS (1111111111), "& | ||
| + | "EXTEST (0000000000), "& | ||
| + | "SAMPLE (0000000101), "& | ||
| + | "IDCODE (0000000110), "& | ||
| + | "USERCODE (0000000111), "& | ||
| + | "CLAMP (0000001010), "& | ||
| + | "HIGHZ (0000001011), "& | ||
| + | "CONFIG_IO (0000001101)"; | ||
| + | |||
| + | attribute INSTRUCTION_CAPTURE of EP1C3T100 : entity is "0101010101"; | ||
| + | |||
| + | attribute IDCODE_REGISTER of EP1C3T100 : entity is | ||
| + | "0000"& --4-bit Version | ||
| + | "0010000010000001"& --16-bit Part Number (hex 2081) | ||
| + | "00001101110"& --11-bit Manufacturer's Identity | ||
| + | "1"; --Mandatory LSB | ||
| + | |||
| + | attribute BOUNDARY_LENGTH of EP1C3T100 : entity is 339; | ||
| + | </code> | ||
| + | |||
| + | Here's what we learn from this device's BSDL: | ||
| + | |||
| + | * The length of the IR register (10 bits long). | ||
| + | * The list of possible IR instructions, with their 10 bits codes. The code for SAMPLE is 0000000101b = 0x005. | ||
| + | * The IDCODE of the part (the manufacturer code reads 00001101110b = 0x6E, which is Altera. Xilinx would have been 00001001001b = 0x49). | ||
| + | * The length of the boundary-scan chain (339 bits long). | ||
| + | * The boundary-scan is 339 bits long. That doesn't mean there are 339 pins. | ||
| + | |||
| + | Each pin use an IO pad on the IC die. Some IO pads use one, two or three bits from the chain (depending if the pin is input only, output with tri-state, or both). See the links at the bottom of this page for more details. Also some registers correspond to IO pads that may not be bounded (they exists on the IC die but are not accessible externally). Which explains why a 100 pins device can have a 339 bits boundary-scan chain. | ||
| + | |||
| + | Going back to the BSDL file, we also get this: | ||
| + | <code bsdl> | ||
| + | attribute BOUNDARY_REGISTER of EP1C3T100 : entity is | ||
| + | --BSC group 0 for I/O pin 100 | ||
| + | "0 (BC_1, IO100, input, X)," & | ||
| + | "1 (BC_1, *, control, 1)," & | ||
| + | "2 (BC_1, IO100, output3, X, 1, 1, Z)," & | ||
| + | |||
| + | --BSC group 1 for I/O pin 99 | ||
| + | "3 (BC_1, IO99, input, X)," & | ||
| + | "4 (BC_1, *, control, 1)," & | ||
| + | "5 (BC_1, IO99, output3, X, 4, 1, Z)," & | ||
| + | |||
| + | ... | ||
| + | ... | ||
| + | ... | ||
| + | |||
| + | --BSC group 112 for I/O pin 1 | ||
| + | "336 (BC_1, IO1, input, X)," & | ||
| + | "337 (BC_1, *, control, 1)," & | ||
| + | "338 (BC_1, IO1, output3, X, 337, 1, Z)" ; | ||
| + | </code> | ||
| + | |||
| + | This lists all the 339 bits of the chain, and what they do. | ||
| + | For example, bit 3 is the one that tells us what is the value on pin 99. | ||
| + | |||
| + | Let's read the boundary-scan registers, and print the value on pin 99: | ||
| + | <code c> | ||
| + | // go to reset state | ||
| + | for(i=0; i<5; i++) JTAG_clock(TMS); | ||
| + | |||
| + | // go to Shift-IR | ||
| + | JTAG_clock(0); | ||
| + | JTAG_clock(TMS); | ||
| + | JTAG_clock(TMS); | ||
| + | JTAG_clock(0); | ||
| + | JTAG_clock(0); | ||
| + | |||
| + | // Assuming that IR is 10 bits long, | ||
| + | // that there is only one device in the chain, | ||
| + | // and that SAMPLE code = 0000000101b | ||
| + | JTAG_clock(1); | ||
| + | JTAG_clock(0); | ||
| + | JTAG_clock(1); | ||
| + | JTAG_clock(0); | ||
| + | JTAG_clock(0); | ||
| + | JTAG_clock(0); | ||
| + | JTAG_clock(0); | ||
| + | JTAG_clock(0); | ||
| + | JTAG_clock(0); | ||
| + | JTAG_clock(0 or TMS); // last bit needs to have TMS active, to exit shift-IR | ||
| + | |||
| + | // we are in Exit1-IR, go to Shift-DR | ||
| + | JTAG_clock(TMS); | ||
| + | JTAG_clock(TMS); | ||
| + | JTAG_clock(0); | ||
| + | JTAG_clock(0); | ||
| + | |||
| + | // read the boundary-scan chain bits in an array called BSB | ||
| + | JTAG_read(BSB, 339); | ||
| + | printf("Status of pin 99 = %d\n, BSB[3]); | ||
| + | </code> | ||
| + | |||
| + | Easy, right? | ||
| + | |||
| + | ===== Do more with JTAG ===== | ||
| + | |||
| + | * JTAG can hijack the pins. The JTAG instruction for that is EXTEST ("external test"). | ||
| + | * JTAG can perform FPGA configuration. See for example this file. | ||
| + | * JTAG can be used as debug port - for example Altera's SignalTap and Xilinx's ChipScope. | ||
| + | |||
| + | Your turn to experiment! | ||
| + | |||
| + | ===== Links ===== | ||
| + | * Altera器件的[[http://www.altera.com/literature/an/an039.pdf|Boundary-Scan Testing]] | ||
| + | * Xilinx的[[http://www.xilinx.com/xlnx/xil_sw_updates_home.jsp?update=bsdl|BSDL文件]]. | ||
| + | * Altera的[[http://www.altera.com/support/devices/bsdl/bsdl.html|BSDL文件]]. | ||
| + | |||
| + | |||
| + | 更详细的信息参见：[[WiKiPedia上关于JTAG的定义]] | ||
| - | ====Serial Wire Debug==== | ||
| - | Serial Wire Debug (SWD) is an alternative 2-pin electrical interface that uses the same protocol. It uses the existing GND connection. SWD uses an ARM CPU standard bi-directional wire protocol, defined in the ARM Debug Interface v5. This enables the debugger to become another AMBA bus master for access to system memory and peripheral or debug registers. Data rate is up to 4 Mbytes/sec at 50 MHz. SWD also has built-in error detection. On JTAG devices with SWD capability, the TMS and TCK are used as SWDIO and SWCLK signals, providing for dual-mode programmers. | ||