Talk:JTAG

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

General[edit]

Hi all, nice job on the page so far. Especially given much of the history is lacking on the web. Just tried to add a little bit of history. Note that the security vulnerability section is a blatant advertisement. All those links and mention should likely be taken out or limited to one sentence. I will try to find more documents and links to history to help your page out. Feel free to accept or modify anything I put in. BTW, I did not work for Intel. In fact, we were the ones who forced Intel into adding JTAG (NCR/Teradata Mainframe group) in 1990. We built a 1024 processor supercomputer that year that had every IC and board on a JTAG scan system. We could hot plug any board and test any internal chip or register while the system was online. We even built PSR and CRC checks into a special JTAG control chip that was placed on each board. Even the back plane was scannable! SurplusGadgets 19:17, 22 May 2007 (UTC) SurplusGadgets (aka randyh@sevni.com)[reply]

Links are now pruned. I'd be interested in seeing more info about “JTAG in the very-large&lrdquo; at some point, but as you noted, that stuff isn't very visible on-line, except maybe within certain IEEE working groups. --69.226.209.34 (talk) 23:04, 2 October 2009 (UTC)[reply]

i know i'm nitpicking a bit, but "enables a programmer to access an on-chip debug module which is integrated into the CPU via JTAG" in the first paragraph is ambiguous (to me). Does the programmer access the debug module via JTAG or is the debug module integrated into the CPU using JTAG? I would suspect the former, but it's not clear.
>the Dbeugmodul is realized in the CPU with a JTAG Interface :) Some Debug Interfaces are only under NDA.

That should be a lot better now. --69.226.209.34 (talk) 23:04, 2 October 2009 (UTC)[reply]

Question: Would it make sense to publish the IEEE 1149.1 State Machine or might this be a problem, because of copyright issues ? —Preceding unsigned comment added by 84.154.55.78 (talk) 12:34, 4 November 2007 (UTC)[reply]

The state machine as printed by IEEE might have issues, but there are many versions around. Nobody seems to have put an image into the wikipedia repository. Personally, I suspect the state machine would be "too much detail". It's certainly not necessary for anyone not doing very lowlevel work with JTAG, though it might be interesting. 69.226.238.251 (talk) 08:35, 26 November 2009 (UTC)[reply]
The state machine is a good idea I think as it forms the fundamental base of IEEE Std 1149.1 Boundary-scan Test Access Port And Architecture (aka JTAG). I will attempt to add it asap.Mapstain (talk) 10:29, 16 December 2009 (UTC)[reply]

This comment is added as a result of discussions at the boundary-scan article boundary-scan talk. It is intended to help resolve/highlight a dispute regarding the inclusion of more detailed information on the IEEE Std 1149.1 boundary-scan subject. It is the view of 69.226.238.251 that the boundary-scan subject be chiefly covered in the 'boundary-scan article' and that JTAG be the repository for information on proprietary JTAG debug/emulation modes. I disagree and have undertaken one revert (i.e. added information on boundary-scan back into the article - no deletions).. More of the discussion can be viewed at the boundary-scan talk link above - further comments and opinions welcomed 81.103.50.148 (talk) 20:09, 22 December 2009 (UTC)[reply]

Dear editors, I have questions as to whether much of the content in here is applicable. Some of it is promotion or meant to confuse the reader to think JTAG is something else that it is not. SCAN_N is not a 1149.1 optional instruction. What is the relevance of IEEE 1149.7 here at all? it's the first external link. It's not JTAG but a proprietary 2-wire debug interface, crafted into a entity based IEEE standard (non-public WG) which does not use BSDL (or any of the langauge extensions in upcoming P1149.1-2012. 1149.7 is interesting and probably needs to have a 1149.7 wiki. I am missing its contributions to the history of JTAG and its need to be prominent in a wiki on JTAG, which is known as a 4 wire, optional TRST* interface. I don't even see a link to the IEEE working group which makes the JTAG standard possible. I see lots of references to ARM as well, debug and halt mode, those are also proprietary and perhaps belong in a seperate wiki page, ARM page or CPU debugging page. Does anyone else agree? I also think the state-machine would be useful here. It is not a copyright violation of the IEEE to create your own artwork for the 1149.1 state-machine. just don't scan the figure in the IEEE 1149.1 standard. the page doesnt seem to conform to wiki guidelines. Jtagchair (talk) 16:46, 18 February 2012 (UTC)[reply]

x86[edit]

In general a very good article. BUT - I have a bit of an issue with the statement "Primarily of historical interest: Intel's Pentium processors supported a "probe mode"[15] supporting JTAG access for debuggers. For a long time, its documentation was withdrawn by Intel. Current x86 processors appear to use JTAG only for boundary scan."

Both AMD and Intel have consistently supported full JTAG debug going all the way back to the original JTAG standard definition. Intel is a founding member of the JTAG MIPI group. JTAG vendors supporting JTAG debug on Intel architecture include Green Hills, American Arium, Wind River, Macraigor Systems, and Lauterbach. Most of these vendors focus in Intel Atom Processor, except for American Arium which tends to be the JTAG vendor of choice for client and server Intel Core and Xeon processors.

In addition Intel has it's own ITP-XDP3 JTAG device that is available as part of something called Intel System Studio and is also available with a restricted access advanced enabling product.

AMD similarly has a good ecosystem of JTAG vendors supporting their processors. Since the JTAG implementation of AMD differs from that of Intel the ecosystem vendors offering support are different as well, although there is some overlap.

With the heightened need for platform security JTAG is frequently disabled on production silicon, but that is true for many ARM processor SKUs especially in mobility and telephony as well.

The only other limitation I see compared to ARM is that most of the x86 JTAG devices fall into the higher cost bracket. The options for the hobbyist or small scale system integrator are limited.

I am willing to make the appropriate changes to this Wikipedia entry, if this is the general consensus. — Preceding unsigned comment added by Roboima (talk • contribs) 16:32, 23 June 2013 (UTC)[reply]

Picture(s)[edit]

Can somebody take a pictures of a JTAG cable, connector, and/or port to add to this? Also, would an eye pattern be useful here? --W0lfie (talk) 14:59, 21 December 2007 (UTC)[reply]


JTAG pinouts[edit]

I think this paragraph is quite wrong, I would recommend complete re-write (I can do it and supply also a photo as per previous request):

There are only minimal standards for JTAG adapters, even when standard 2.54mm pin spacing is used. For example, ARM based systems often use a 20-pin header; but many systems from TI use a 14-pin header which includes one interface for an ARM core and second one for a DSP core. Atmel's AVR 8-bit and 32-bit processors use a 10-pin JTAG header. Some systems use 12-pin headers, others use 6-pin single-row header. Higher end products frequently use dense 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. Production boards often rely on bed-of-nails connections for testing and programming.


  • "recent trend having USB to JTAG..." is IMHO not 100% true, although some boards DO have USB-JTAG on itself
  • There are only few commonly used JTAG pinouts:
  1. for PLD programming, 8 or 9 pin in one row
  2. Altera ByteBlaster/AVR/... and compatible 2x5 pin
  3. ARM 14pin and 20pin JTAG
  4. MIPS EJTAG

The above pinouts are common for multiple products and vendors (i.e. almost all ARM chips use 20 or 14 pin JTAG with same pinout).

81.201.62.154 (talk) 15:07, 2 June 2008 (UTC) (no wiki account)[reply]

Well, you're off-base about that para being wrong. Dividing *only* by pin count would be wrong, yes, but as a first order consideration it's easy to see that a 10-pin, 14-pin, and 20-pin connectors are rather different, and that's a good way to make the incompatibility point very quickly.
I've seen the subset of pinouts at that URL you give; it's incomplete. Within an arm's reach I have six more pinouts (two TI ARM/DSP variants, 20-pin "compact"/1.27mm and 14-pin/2.54mm; ARM 38-pin Mictor, with ETM; AVR32 10-pin and 38-pin Mictor; 14-pin FPGA) which are not listed there. In the next room I have at least three more (TI 60-pin for trace; new ARM 10-pin/1.27; non-Altera CPLD).
The last set of microcontroller development boards I shopped, and the last DSP and FPGA boards I received, all integrated USB-to-JTAG adapters. It's a trend, albeit maybe a limited one, and of interest in terms of tool support.
Sure, there are some conventions that are fairly common, but the point remains that if this *one* developer managed to get a dozen different JTAG connectors without even trying ... any standards are at best minimal, as written. I am glad that most of my ARM boards offer a 20-pin ICE-compatible connector, matching my main JTAG adapter. But I have several ARM boards where it's not used, and it doesn't work on any non-ARM boards.
--69.226.209.118 (talk) 03:19, 28 July 2009 (UTC)[reply]


Does JTAG standard even talks about pin outs? I think it does not. It only state the pins and that's it. No pin heathers or anything like that. Am I wrong?
--Pelgv (talk) 21:26, 19 April 2010 (UTC)[reply]

Well, whatever it is, could someone add a table formatted list of these variations. As it stands now it is completely incomprehensible and illegible. 78.60.91.93 (talk) 22:05, 19 April 2011 (UTC)[reply]

IEEE manufacturer code[edit]

"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 an IEEE manufacturer code, a manufacturer part number, and a part version code."

Is there a central database for all IDCODEs? Does this IDCODE have something to do with IEEE's Organizationally Unique Identifier? --Abdull (talk) 16:51, 14 March 2010 (UTC)[reply]

Hopefully now clearer. Ptoboley (talk) 10:11, 24 May 2010 (UTC)[reply]

Somewhere it would be good to clarify that the IDCODE used in an Arm DAP identifies just the SWJ-DP or JTAG-DP (with the Arm JDEC code), rather than the device manufacturer. Tsh~enwiki (talk) 10:37, 30 January 2018 (UTC)[reply]

JTAG Instructions[edit]

In the article, the following is stated: "The BYPASS instruction, opcode all ones regardless of the TAP's instruction register size, must be supported by all TAPs. It is associated with a single bit data register (also called BYPASS) which always reads as zero." I need clarification here because I after reading about JTAG, I understand that the BYPASS instruction will "connect" a 1 bit shift register (FF) between TDI and TDO. Then the statement "...which always reads as zero." is not true.
It might be that at start-up or upon selection (could someone confirm this as I do not have the IEEE Standard available) the BYPASS register will always read zero but then it will read whatever TDI value was on the previous clock cycle.
Pelgv (talk) 22:28, 16 March 2010 (UTC)[reply]

A scan DR (of BYPASS register)immediately following and update-IR (loading the BYPASS) instruction will/should always yield a single bit '0' zero. After that anything on TDI will shift through the BYPASS register if in teh shift DR state.Mapstain (talk) 16:46, 20 April 2010 (UTC)[reply]

Harry Wardrop[edit]

This name has been added recently by an untracable agent. The name is not known to me in connection with JTAG so I am keen to know more about this person. Another Harry, Harry Bleeker, certainly chaired the JTAG committee for some years. Is this a point of confusion ? Or, can someone enlighten me. Mapstain (talk) 16:46, 20 April 2010 (UTC)[reply]

Merger complete[edit]

  checkY Merger complete. All information from Wiggler (JTAG) has been merged into this article. Northamerica1000(talk) 15:19, 9 July 2012 (UTC)[reply]

I removed the Wiggler information. Parallel port interfaces were mentioned above (and limitations were cited). The tone sounds like it is advertising a product. Other information about the Wiggler is tangential to JTAG. Glrx (talk) 15:26, 10 July 2012 (UTC)[reply]
Unbuffered Wiggler is so popular among hobbysts that it really should be mentioned here. The popularity comes from its practically zero cost to build compared to regular JTAG adapters which can easily cost more than US $100. — Preceding unsigned comment added by 212.160.172.85 (talk) 10:41, 27 April 2017 (UTC)[reply]
The Wiggler might have been important at one time, but not anymore because few new computers have a parallel port in 2017. Today, a person can easily find a cheap JTAG device, and much cheaper than USD$100. Still there should added to an open-source section, along with some others. • Sbmeirow • Talk • 09:54, 28 April 2017 (UTC)[reply]

License[edit]

Dear engineers. Please add section about copyright, license, and fees for use (if any). Ideally the article should contain exact information about these, and also about limitations for free use, patenting, and other issues for use in DIY and other open environments. Or, if no such limitations, it must be clearly stated. Thanks. — Preceding unsigned comment added by 85.31.112.107 (talk) 07:43, 26 March 2014 (UTC)[reply]

History[edit]

My brain is fried right now, but I think there is more depth to the history. At some point, James B. Angell at Stanford proposed logic testing using serial scans. IBM came out with Level-Sensitive Scan Design (LSSD) for testing its computers. Then there was JTAG. Glrx (talk) 17:10, 1 April 2015 (UTC)[reply]

Requested move 16 April 2016[edit]

The following is a closed discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a move review. No further edits should be made to this section.

The result of the move request was: Moved  — Amakuru (talk) 20:43, 25 April 2016 (UTC)[reply]


Joint Test Action Group → JTAG – Return this article to its previous name of JTAG.

User:Kbrose recently moved this article from JTAG to Joint Test Action Group. The move seems confusing because JTAG is usually about the TAP and boundary scan protocols rather than the association. The TAP/protocols are known as "JTAG" and not "Joint Test Action Group". The article mentions both the TAP/protocols and the association, but the emphasis is on the TAP/protocols rather than the association.

  • There is a Joint Test Action Group; it is an association that created the boundary scan specification. The association uses the acronym JTAG (pronounced Jay-Tag).
  • The association created the IEEE specification known as "1149.1-1990 - IEEE Standard Test Access Port and Boundary-Scan Architecture". That specification is about particular hardware and protocols for that hardware. The specification has become known as JTAG. In other words, the WP:COMMONNAME of the specification is JTAG and is distinct from the association.

The two are distinct. When I hear "Joint Test Action Group", I think of the association rather than the TAP/procotols. Glrx (talk) 20:07, 16 April 2016 (UTC)[reply]

  • Support – Most JTAG users have no idea what it stands for. It's just JTAG. Dicklyon (talk) 22:02, 16 April 2016 (UTC)[reply]
  • Support This may need the JPEG treatment. I.e., JTAG for the standard and Joint Test Action Group for the committee? As it stands now, the article is mostly about the former so the title should reflect that. —Ruud 12:36, 17 April 2016 (UTC)[reply]
    I don't think separate articles are warranted here. The main thing the association did was write the spec; right now, the article has only three sentences about the association. Glrx (talk) 01:48, 21 April 2016 (UTC)[reply]
The above discussion is preserved as an archive of a requested move. Please do not modify it. Subsequent comments should be made in a new section on this talk page or in a move review. No further edits should be made to this section.

Article Name[edit]

I just now noticed the renaming of this article. Though JTAG does make sense, there are cases for alternate names, per other articles on Wikipedia, which also has weight in the naming of this article. I know there are more, but these are the ones that I remember. • Sbmeirow • Talk • 21:22, 25 April 2016 (UTC)[reply]

Example of articles as "specification number" (JTAG is IEEE 1149.1):

Examples of articles in "long form":

Unlike FireWire and WiFi, this standard does not seem to be as well known by its number (and we do have articles on ZigBee and WiFi as well). And as was noted above, in this case the long form of the acronym is somewhat misleading (just as is the case with e.g. JPEG). —Ruud 23:50, 25 April 2016 (UTC)[reply]

Serial Wire Debug[edit]

As of the current version, there is a passage which says Serial Wire Debug (SWD) is an alternative 2-pin electrical interface that uses the same protocol.

I think there are two clarifications missing:

  1. Same protocol as what? I can't be referring to JTAG, as JTAG ist not a protocol: "The JTAG specification doesnt even define the protocol for how data is passed between debugger and debugee." [1]
  2. SWD is an own protocol, which serves the same purpose as JTAG, but is not using it in any form.

--2003:F7:5BC0:1F00:B14F:45B1:4815:D277 (talk) 19:11, 12 December 2019 (UTC)[reply]

Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:JTAG&oldid=1201183280"