Talk:Joint Test Action Group
|WikiProject Computing / Hardware||(Rated Start-class, Mid-importance)|
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 firstname.lastname@example.org)
- 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. --188.8.131.52 (talk) 23:04, 2 October 2009 (UTC)
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.
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 184.108.40.206 (talk) 12:34, 4 November 2007 (UTC)
- 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. 220.127.116.11 (talk) 08:35, 26 November 2009 (UTC)
- 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)
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 18.104.22.168 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 22.214.171.124 (talk) 20:09, 22 December 2009 (UTC)
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)
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" 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.
||It is requested that an image or photograph be included in this article to improve its quality.
The Free Image Search Tool may be able to locate suitable images on Flickr and other web sites.
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.
- Dividing JTAG pinheaders by pin count is nonsense as they have completely different pinouts! Look at http://www.jtagtest.com/pinouts/
- "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:
- for PLD programming, 8 or 9 pin in one row
- Altera ByteBlaster/AVR/... and compatible 2x5 pin
- ARM 14pin and 20pin JTAG
- 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).
- 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.
IEEE manufacturer code
- "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."
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)
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)
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)