JTAG is JTAG is JTAG - Page 1
Forum section: electronics / general

author: Crazy Ape
author_rank: Regular Contributor
timestamp: November 28, 2013, 02:57:48 pm
content: JTAG is JTAG is JTAG...................as long as you can avoid the vendor supplied programming utility.It seems that every chip vendor requires you to use 'their own' - expensive - JTAG programmer to program the chips they produce. While this may be pocket change for some folks, some of us prefer to save a dollar or ten where ever possible.While a hobbyist may not want to spend money on yet another programming device, other reasons exist for not wanting to use the vendors programming software/tool. You might have several devices, all from different vendors, and all sitting on the same JTAG chain. Programming each device with it's vendors software and associated JTAG programmer can become a real pain.Myself, I don't like the artificial limits that chip companies impose on their customers. The first (only) programmer I bought was an Altera USB Blaster (likely some kind of clone actually), this was great for the large Altera CPLD I was playing with but I also had a small Xilinx device as well.Open Source to the rescue with UrJTAG.Link:http://urjtag.org/UrJTAG allows you to use most JTAG programmers with a variety of devices from different vendors.The key to this is to export your design as an .svf file, most vendors have this as an option in their software.This is an example of programing a 'Xilinx' xc3s500e FPGA with an 'Altera' USB Blaster.Quote

author: MrAureliusR
author_rank: Unknown
timestamp: November 28, 2013, 03:05:22 pm
content: Yeah I just downloaded this software, looks incredibly cool! I'm probably going to pick up a Xilinx JTAG programmer off someone I know locally, good to know I can apply it in many ways!On that note, if you scour eBay, you'll notice most of the Chinese knockoff JTAG programmers look suspiciously similar, just different stickers on the outside. There's even one with Xilinx, Altera and Lattice logos on the side that claims to do all three!

author: Crazy Ape
author_rank: Regular Contributor
timestamp: November 28, 2013, 03:18:49 pm
content: Quote from: MrAureliusR on November 28, 2013, 03:05:22 pmYeah, I've seen the flood of JTAG programmers of all sorts on ebay and the Chinese sites. But what I have works well for what I do. It adds two mouse clicks (switch to UrJTAG window and back again) and generally two key presses (up arrow and enter - assuming I'm repeating the same command) which adds about 1/4 of a second to my work flow. Though the triple mode programmers look like they could be handy.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: November 28, 2013, 03:46:11 pm
content: JTAG itself is standard, however there are non-standards at both ends - at the PC end, there is no standard API, although now that FTDI supply a JTAG API for their hi-speed USB parts, there is no excuse for anyone inventing a new one, and some manufacturers (e.g. Lattice) support programming via a FTDI chip.At the other end, how JTAG is used to program devices is typically very part-specific and often undocumented.This is how companies like Segger can get away with charging such high proces for their JTAG hardware

author: Crazy Ape
author_rank: Regular Contributor
timestamp: November 28, 2013, 04:31:47 pm
content: Quote from: mikeselectricstuff on November 28, 2013, 03:46:11 pmI agree with all the above, lots of undefined cruft sitting on to of a well defined standard, the being the JTAG state machine.Being able to export to an .svf file were possible at least gets away of the vendors proprietary binary format.As for the communication API between the PC and the JTAG programmer, while it transports JTAG commands to the JTAG state machine in the device, it seems to be more about locking you (or your product design) into a particular vendor than anything to do with improving JTAG usage. Though if we're using non vendor software with a choice of programmer API's, this is much less of an issue.What I was getting at with my post was that the JTAG state machine is standard everywhere and there are numerous ways to drive it, not just via the vendors tools.

author: legacy
author_rank: Super Contributor
timestamp: November 28, 2013, 04:46:16 pm
content: it there a way from an embedded router (linux/mips) with usb to download a bitstream (through Xiling-usb-blaster) to a Xiling fpga ?

author: Crazy Ape
author_rank: Regular Contributor
timestamp: November 28, 2013, 05:09:36 pm
content: Quote from: legacy on November 28, 2013, 04:46:16 pmIf you have root access to the router and a way of compiling code for it, then I don't see why it wouldn't work.You'll need the following (and whatever dependencies they have):The open source FTDI drivers:http://www.intra2net.com/en/developer/libftdiLibUSB (may already be present depending on router):http://www.libusb.orgUrJTAG:http://urjtag.org

author: Crazy Ape
author_rank: Regular Contributor
timestamp: November 28, 2013, 05:10:00 pm
content: There are still other options.If you have a half reasonable micro-controller handy (and know how to wield it) take a look at Xilinx XAPP058.http://www.xilinx.com/support/documentation/application_notes/xapp058.pdf

author: legacy
author_rank: Super Contributor
timestamp: November 28, 2013, 05:13:39 pm
content: FTDI is not x86 binary only ?

author: Crazy Ape
author_rank: Regular Contributor
timestamp: November 28, 2013, 05:17:43 pm
content: Quote from: legacy on November 28, 2013, 05:13:39 pmThere is more than one set of FTDI drivers, I linked to the Open Source drivers, they will compile on non-Intel architectures.

author: nctnico
author_rank: Super Contributor
timestamp: November 28, 2013, 08:42:05 pm
content: IMHO JTAG sucks pretty bad. It looks like a nice piece of asfalt but you need a different kind of car for each destination. Managers don't seem to care because they usually think JTAG is standard so they only need one JTAG dongle to program everything.I try to avoid it whenever possible especially on embedded platforms. Early in my career the design team I was part of decided to program a bunch of Xilinx FPGAs on a PCB through JTAG from a microcontroller. JTAG is standard so how hard can that be? I got the task of actually getting it to work. It turned out to be an much bigger project than anticipated. It appeared Xilinx had some semi documented protocol where packets send over JTAG would set the FPGA in certain modes. I got it working mostly through trial and error (including a fried-by-software FPGA!). A board respin with different FPGAs (the brand new Spartan 2E instead of Spartan2) caused the programming to stop working. With more trial and error I got it working again.From that moment I used serial programming options whenever available.

author: legacy
author_rank: Super Contributor
timestamp: November 28, 2013, 08:55:21 pm
content: Quote from: nctnico on November 28, 2013, 08:42:05 pmwhy ?

author: EEVblog
author_rank: Unknown
timestamp: November 28, 2013, 08:55:46 pm
content: Quote from: mikeselectricstuff on November 28, 2013, 03:46:11 pmJTAG pogrammers have always been high priced because their primary market has been professionals for whom cost is not a major factor, JTAG enabled devices haven't really penetrated much into the low cost scene like the PIC/AVR/MSP/WHATEVER programmers have captured. And for those that have (Xilinx/Altera FPGA's + ARM processors), you can get programmers delivered for under $10 on ebay.And the professionals also use JTAG for production boundry scan testing etc, not just as a programmer. so the software tools get a lot more complicated and expensive than just programming software.

author: legacy
author_rank: Super Contributor
timestamp: November 28, 2013, 09:21:42 pm
content: Jtag for Flash programming may be done with cheap jtag devices (< $50)• Flash programming algorithm controls our chip output pin-s state using JTAG EXTTEST mode• Pins logic state is set to 0,1 or high impedance state according to signal diagrams in FLASH chip data sheetbut Step-by-step debugging sees two corner cases of JTAG software debug implementation–First case: software "speaks" with JTAG device in terms of TAP controller FSM states; bit-vectors need to be shifted in and out, to and from registers of TAP controller• Physical connection to TAP controller is made in software bit-banging mode• Optimized access to TAP controller when intellectual JTAG cable accelerates JTAG operations at physical levelsExample: Olimex-USB-OCD + OpenOCD for ARM (still cheap devices < $50)-Second case: software "speaks" with JTAG device in terms of debugged process, such as "next instruction", "step-in", "step-over", "show registers, they go for the description of "Optimized TAP controller with high throughput and advanced features"Example: Abatron BDI 2000 (expensive > $400 devices, and it may costs $2000 or more, BDI 2000 is very very expensive)

author: Crazy Ape
author_rank: Regular Contributor
timestamp: November 28, 2013, 09:22:47 pm
content: Quote from: nctnico on November 28, 2013, 08:42:05 pmSetting up certain modes on the target sounds pretty much like standard JTAG state machine manipulation to me. If you try to treat JTAG as some kind of serial protocol, you'll come to grief quite quickly.This is the beast you were dealing with:

author: legacy
author_rank: Super Contributor
timestamp: November 28, 2013, 09:37:56 pm
content: From the point of view of the Electrical Characteristics JTAG is an interface with special four/five pins• TDI (Test Data In)• TDO (Test Data Out)• TCK (Test Clock)• TMS (Test Mode Select)• TRST (Test Reset) - optionalFrom a the point of fsm jtag is a TAP State Machine composed by these commands• BYPASS 111...1 "all ones" command, register is filled with ones• EXTTEST 000 ..0 "all zeros" command, connects "boundary scan" register between TDI and TDO• SAMPLE 000...1 "one in last bit" command, connects 1-bit "bypass" register between TDI and TDO TAP behaves as transparent 1-bit shift register-------- which may also have optional commands -------• INTEST, places the IC in an internal boundary-test mode and selects the boundary-scan register to be connected between TDI and TDO• CLAMP, sets the outputs of an IC to logic levels determined by the contents of the boundary-scan reg & selects the bypass regto be connected between TDI and TDO• HIGHZ, sets all outputs (including two-state and three-state types) of an IC to (high- impedance) state and selects the bypass register connected between TDI and TDO• USERCODE, allows functional mode and selects the device register to be connected between TDI and TDOFrom my (and debug Application) point of view Jtag is related to Boundary scan description language (BSDL) which is a subs to VHDL used to describe how JTAG (IEEE 1149.1) is implemented in a particular device, and a device to be JTAG compliant,it musthave an associated BSDL file. Many IEEE Std 1149.1 tools already on the market support BSDL as a data input format. These tools offer different capabilities to customers implementing IEEE Std 1149.1 into their designs, including board interconnect automatic test-pattern generation (ATPG) and automatic test equipment (ATE).So BSDL is/may be the problem !

author: Crazy Ape
author_rank: Regular Contributor
timestamp: November 28, 2013, 09:49:59 pm
content: Quote from: legacy on November 28, 2013, 09:35:23 pmVendor tools are obviously the way to go if you have deep pockets, or need some function that's not met in open-source tools, but not everyone fits that category.That being said, vendors release BSDL files so I'm not sure why BSDL should be a problem. For instance, lets check the state of PAD63 on my xc3s500e die. It's an unused input with pulldown to ground, so it should be 0.QuoteNo problems playing with the boundary scan register here.

author: nctnico
author_rank: Super Contributor
timestamp: November 28, 2013, 10:30:15 pm
content: Quote from: legacy on November 28, 2013, 08:55:21 pmBecause the programming sequence for the 2E was slightly different from the 2. But thats ancient history now. AFAIK the Spartan2E is already obsolete.@Grazy Ape: Now try to do something with that statemachine... JTAG is like SPI, I2C, UART, etc: a physical layer interface. If you know which commands to send you can access the chip otherwise you can't.

author: Crazy Ape
author_rank: Regular Contributor
timestamp: November 28, 2013, 10:41:05 pm
content: Quote from: nctnico on November 28, 2013, 10:30:15 pmThe commands are listed in the BSDL file, and you can also get a good idea of their use by looking at the first page of any .svf file targeted at the device.

author: MrAureliusR
author_rank: Unknown
timestamp: November 29, 2013, 03:08:01 am
content: Question about Bus Pirate and JTAG (if anyone knows about it):I'm using Kubuntu Linux 13.04, just FYI. I've also tried to compile OpenOCD for Cygwin but it fails because of syntax errors, outdated files, etc. It just doesn't seem well-supported in Cygwin anymore. So I've finally got OpenOCD set up in Linux -- I've got the buspirate.cfg file correctly written, but now I'm a bit lost. I understand that once the OpenOCD 'server' is running you have to connect to it using ssh, telnet or similar.How exactly is this done? loopback/127.0.0.1? The tutorials on the Dangerous Prototypes website seem to all be very old, and I know it's not a super-supported feature, but I'd just like to be able to use the Pirate for all the interfaces I possibly can.Thanks!PS When my Xilinx dev kit shows up I will do a thread about it. I have a feeling it's going to be very good value for money. Also, trying to find Verilog resources for beginners -- recommendations anyone?

author: Crazy Ape
author_rank: Regular Contributor
timestamp: November 29, 2013, 03:54:15 am
content: Quote from: MrAureliusR on November 29, 2013, 03:08:01 amThe manual says:A human should interact with the telnet interface (default port: 4444) or via GDB (default port 3333).http://openocd.sourceforge.net/doc/html/General-Commands.htmlLets give is a tryQuoteIt works, just ignore the "telnet: connect to address ::1: Connection refused" message, it's an IPv6 connection attempt by my telnet.So, this should work for you:telnet localhost 4444

author: MrAureliusR
author_rank: Unknown
timestamp: November 29, 2013, 04:17:45 am
content: Got it.Problem now is I don't think the target config is quite right... man JTAG is powerful, though!

author: Crazy Ape
author_rank: Regular Contributor
timestamp: November 29, 2013, 04:19:32 am
content: Quote from: MrAureliusR on November 29, 2013, 04:17:45 amWhat device are you targeting?

author: MrAureliusR
author_rank: Unknown
timestamp: November 29, 2013, 04:21:25 am
content: TMS570LS04x TI Hercules ARM processor. There's a JTAG chain on this board, of about 3 or 4 devices I believe. If I use ti_calypso.cfg it actually does detect the chip, but then basically nothing actually works.It's not a huge deal, it'd be cool to get it working, but I really just want to use this as a backup/possibly my only option for programming my Xilinx dev board.

author: Crazy Ape
author_rank: Regular Contributor
timestamp: November 29, 2013, 04:31:20 am
content: Quote from: MrAureliusR on November 29, 2013, 04:21:25 amOK, the Hercules uses TI's ICDI (in-circuit debug interface) so you'll need to rebuild OpenOCD with --enable-ti-icdiSee here for info, it's for Stellaris but both Stellaris and Hercules use ICDI so you should be good to go.http://www.jann.cc/2012/12/11/getting_started_with_the_ti_stellaris_launchpad_on_linux.html#build-openocd-with-icdi-support

author: westfw
author_rank: Super Contributor
timestamp: November 29, 2013, 05:39:56 am
content: JTAG is just a low-level communications protocol, right? Pretty much not more than than a spec for a cascadable set of shift registers capable of running through all your JTAG-enabled devices through a single connection to your board.What the bits communicated to various registers actually DO is beyond the specification. So saying that JTAG sucks because you need a bunch of different devices is like saying that Ethernet sucks because a web page is ugly.

author: Crazy Ape
author_rank: Regular Contributor
timestamp: November 29, 2013, 06:12:31 am
content: Quote from: westfw on November 29, 2013, 05:39:56 amAggreedQuote from: westfw on November 29, 2013, 05:39:56 amHmmmmm, well, if you want to access my web page, you'll have to buy a $700 Ethernet card from me. Sound about right.

author: legacy
author_rank: Super Contributor
timestamp: November 29, 2013, 06:56:39 am
content: Quote from: nctnico on November 28, 2013, 10:30:15 pmbut Spartan2E is 5V tolerant, so it is still good, while Spartan3E is not 5V tolerant

author: legacy
author_rank: Super Contributor
timestamp: November 29, 2013, 07:01:32 am
content: anyone has used a low cost jtag cable with- blackfin- Atheros AR9830in case, about blackfin's jtag, there isthisincredible story

author: clifford
author_rank: Regular Contributor
timestamp: November 29, 2013, 05:30:11 pm
content: Quote from: Crazy Ape on November 28, 2013, 05:10:00 pmUnfortunately xilinx released that under the xilinx reference design licence, whichonly allows you to run the code on a xilinx fpgaand not re-release the sourcecode.But as even the title of the appnote says, this is meant to be run on a uC outside of the fpga. and if you want to use it from an existing framework or kernel you have to check if the "not re-releasing to source code" clause is compatible with that. I have not checked if they have fixed the issue, but at least it was like that a couple of years back. I sent them a mail back then and just got a standard reply that xilinx does not make any licencing exceptions for stuff released under the reference design licence.So I went and wrote my own library for running SVF files from a uC:http://www.clifford.at/libxsvf/It's used to program FPGAs in the LHC accelerator ring at CERN. So I guess this is a strong argument for releasing your code under a liberal licence..

author: Crazy Ape
author_rank: Regular Contributor
timestamp: November 29, 2013, 06:01:33 pm
content: Hi Clifford,I've had a play with the gpio version of your code on an LPC1768, programing the FPGA on a gameduino (hey it was cheap) from a FAT32 SD card.Nice code by the way.

author: nctnico
author_rank: Super Contributor
timestamp: November 30, 2013, 02:12:42 am
content: Quote from: clifford on November 29, 2013, 05:30:11 pmLast time I checked (about a decade ago) the software provided by Xilinx was immensly bloated and way too large. IIRC it compiled into 32KB on a Renesas H8.QuoteI'm wondering how SVF files work when you have different configurations for several FPGAs in a chain (for example depending on a module installed on the board).Anyway, IMHO the serial (SPI like) programming of an FPGA is much easier and you can use the SPI interface on a controller to make it extremely fast. In one project I used an SPI flash for several purposes. By connecting the SPI flash' SDO to the data in of the FPGA and gating the SPI clock to the clock input of the FPGA I could pump the configuration into two daisy chained FPGAs very fast even though the microcontroller was a simple MSP430.

author: westfw
author_rank: Super Contributor
timestamp: November 30, 2013, 04:22:54 am
content: QuoteSure. Till you have a board with a dozen FPGAs and a microprocessor on it, and want to do that boundry-scan testing that JTAG also allows.They way I see it, device programming (and debugging) are kuldges added to the JTAG world that was originally designed to do quite different things. (by ... shudder ... HARDWARE people. No wonder the SW geeks don't like it.)

author: clifford
author_rank: Regular Contributor
timestamp: November 30, 2013, 11:49:33 am
content: Quote from: nctnico on November 30, 2013, 02:12:42 amTL;DR:JTAG is not easy, but its not hard either. When using SVF/XSVF you need extra files for all possible physical configurations of your scan chain. The more devices you have on JTAG the more benefits you will get from it over an interface like SPI.Let me first summarize some background information so we are on the same page:The SVF file (or XSVF, whichbasicallyis a binary version of SVF made by xilinx) only specifies what the host should send. So everything you can do over JTAG, you can do over SVF, as long as it does not require any interaction. Its a simple "send this pattern, expect that pattern" format.So when you are using JTAG, you have all your devices in a daisy chain using the TDI and TDO pins, the TMS pin and the TCK pin are driven by the host and go to all devices in parallel.Now each device puts an internal shift register between the TDI and TDO pins and a state machine driven by TMS can be used to select if this shift register is the "DATA REGISTER" (DR) or the "INSTRUCTION REGISTER" (IR). Each device has one IR and many DRs, and the value in IR determines with DR is in place.There are some special values for IR and some conventions about the reset state that allow you to scan the chain and figure out with devices are on there and how large their IR register is and so on. One IR configuration that all devices must support is the BYPASS register. In this mode the chip just put one single FF in the daisy chain when in DR mode.So when generating the SVF/XSVF file you simply tell the tool how many devices are in the chain, which size the IR registers are and which device your target device is. The SVF file generated will then simply put all other devices in BYPASS mode and add the required number of padding bits to each DR write.Regarding the overhead: Usually the IR is set once and then hundreds of DR writes follow, each hundreds of bits wide. The IR register becomes much larger if you have many devices in the chain, but the IR is written so seldom that this does not really matter. The DR chain only increases by one additional bit per device on the chain, and the actual DR data for the device you want to program is so large, that the few extra bits do not make a huge difference.If you have a physical configuration that can change you basically have two options.The first question is if the socket for you extra module is just empty when the module is not installed or if you have some special connector that just shorts TDI and TDO on the connector so the chain is still intact. If you do not have such a connector, and do not want to place extra components (such as transfer gates) on the motherboard to re-route the TDI and TDO pins, then you must have two chains, one for the motherboard and one for the extra module.With two chains you can share TDI and TCK between the chains, as long you do not want to run them simultaneously. You obviously need separate TDO pins because the JTAG output pin is not a tristate pin, so you would short out two drivers if you'd connected them together. You also need separate TMS pins. This way you can hold one chain in the JTAG reset state (just resets the jtag interface, not the device) while you talk to the other chain. Thus the chain in reset will ignore the TDI data.If you have a special connector that shorts the TDI and TDO pins when no module is installed, then you'd normally have two programming files: one for the case where the module is installed and another one for the case where you only have this terminator connected to the port. I theory it would be possible to add the extra fill bits to all DR and IR writes on demand, but I have never seen anybody actually doing that.If you just want to program a single FPGA, then the SPI interface certainly is much easier. The JTAG interface has a lot of other advantages:1) You can use it to program and probe a large range of devices, not only FPGAs, and the uC doing that does not need to know anything about them. It just need to know how to play those SVF/XSVF files.2) You can easily attach a probe to the JTAG port and use the same interface to program the devices directly from a PC, debug processors, perform boundary scans, and many other wonderful things.3) You do not need any extra per-device pins. This is great because you might want to add an additional IC to your design late in the development process. With JTAG you can simply hang it into the scan chain and all you need are signals that can be re-routed from any nearby chip that already is in the scan chain. With SPI you would have to route an extra slave-select signal all the way from the new chip to the pint where you SPI signal originates (e.g. a uC), and then hope that you still have a free GPIO pin there.

author: rsjsouza
author_rank: Super Contributor
timestamp: November 30, 2013, 12:43:33 pm
content: As westfw said, I always look at the JTAG standard as a small step above the TIA-232 (typical serial port) standard: it specifies electrical and signaling characteristics, has a minimal protocol but does not go beyond that - thus it is open to customization from each manufacturer.Keep in mind this was devised in a time whereeverythingwas proprietary and the manufacturers were trying to solve a much greater problem of testability.For microprocessors I also see JTAG as a debugger and not as a programmer, which contrasts with some of the serial port based ISPs.Quote from: mikeselectricstuff on November 28, 2013, 03:46:11 pmQuote from: Crazy Ape on November 29, 2013, 06:12:31 amThis is what I don't get: if you are trying to access something that charges you a boatload of money, either there is a great reason for that or you can move away to a different webpage. There is a lot more work and money involved in creating and supporting your own JTAG debugger than using one off-the-shelf.This threaddiscusses Segger's prices (student version for $60 US dollars and a full commercial one for $240). Also, MrAureliusR mentioned Hercules from TI: there is theXDS100 debugger(FTDI-based with complete design files available for free) that costs $79 or $89 dollars, and is able to debug from M3s to A15s, is able to access its built-in ETB to do minimal trace and also includes support for their DSPs.

author: MrAureliusR
author_rank: Unknown
timestamp: December 01, 2013, 02:18:13 am
content: I'm also looking at the Dangerous Prototypes Bus Blaster, which is specifically made for JTAG. The new(ish) v3 seems to be very popular, and the (brand) new v4 (which is still kinda of beta-y) seems be high-speed. It uses a CPLD to reconfigure itself to appear as many different programmers, so it's compatible with a few different softwares. From what I've heard it's pretty configurable, basically what the defunct uniJTAG project was aiming for.The v3 (which is more stable) goes for $34.95 on Seeed Studio, the v4 $45. I'm pretty sure they're not directly compatible with Quartus and Vivado/Xilinx ISE but I've also read it's not hard to program those parts. You just do all your work inside the ISE and then when it's time to send the code out you use a different piece of software to program. Almost like the MPLAB IDE/IPE combo. Not too much of a hassle (if it works smoothly, and its popularity seems to say it does).Anyone have experience with the Bus Blaster?

author: nctnico
author_rank: Super Contributor
timestamp: December 01, 2013, 07:15:23 pm
content: Quote from: clifford on November 30, 2013, 11:49:33 amThat point is a bit moot. Only complex chips support JTAG and adding such a chip late in a design is not very likely. Secondly, you can cascade SPI devices so you wouldn't need to route an extra select line from the MCU. Using a hardware SPI uC peripheral is way faster than bitbanging JTAG. Besides that even for an FPGA using SPI for programming has the advantage you can use the same lines to communicate with the FPGA over SPI. You need one extra line from the MCU instead of 4 (or 5 if you include a reset) for JTAG which you'd only use during programming and production testing.Most SoCs can boot directly over USB, from SPI flash or from an SD card nowadays. If JTAG was so easy to use they would not have added those features...

author: clifford
author_rank: Regular Contributor
timestamp: December 04, 2013, 05:53:20 pm
content: Quote from: nctnico on December 01, 2013, 07:15:23 pmIf SPI and those other features you mentioned would be so great, they would not have JTAG on the chips.See: It is really easy to use this kind of argument for almost anything.You might also have noticed that I have never said that JTAG would be easier than SPI or any of the other options you mentioned. I've just said that it is easy, and gets more beneficial as you add more devices in the scan chain.Regarding your argument that one would find JTAG only on large chips and thus it is very unlikely that you would add one of those late in the design: I'd say that this only depends on the kind of the design you are working on. Unless you use DIP or SOT packages, even a small-ish uC usually has JTAG and you might add something like a CPLD late to a design if the design is not cost sensitive. (CPLDs are often used to add additional debug functionality and flexibility to a one-off design such as a test or devel board, for example.)

author: nctnico
author_rank: Super Contributor
timestamp: December 04, 2013, 08:18:12 pm
content: Quote from: clifford on December 04, 2013, 05:53:20 pmYou are carefully avoiding the point I'm makingBut maybe I should have put it differently: if JTAG would be sufficient (for starters: easy and convenient to use) they would not have added the other boot methods later on.A couple of years ago I built an FPGA based JTAG gang programmer for a MIPS based SoC which only had a JTAG interface. With the gang programmer it took 20 seconds instead of 3 minutes with a parallel port JTAG adapter to progam the 150kB bootloader. That programmer cost the firm about €8000 in parts and labour. If the SoC would have been capable of booting over USB or even the serial port things would have been so much easier.

author: clifford
author_rank: Regular Contributor
timestamp: December 04, 2013, 08:54:36 pm
content: Quote from: nctnico on December 04, 2013, 08:18:12 pmWith an FT232H it should take well under a second to program a 150kB payload. (depending on how fast you want to clock the JTAG interface, I usually don't go faster than a couple of MHz). FTDI even sells cables with that chip with USB on one end and loose pins on the other. It can't get any easier than that. The same chip is used in the digilent probes and many others. So you can simply put a digilent-compatible probe directly on your board and have full support in many tools (such as Xilinx Impact and Xilinx ChipScope, for example).I can't tell you what went horribly wrong in that project you mentioned, but I can assure you it did not went wrong because JTAG is an inherently complicated and hard to implement interface.The main reason why there is SPI on FPGAs is because in many applications one wants to load the bitstream from SPI serial flash, btw.And yes, if you only want to upload a bitstream file from a uC that already has an SPI controller, there is nothing wrong with that. But that does not make JTAG the overly complicated interface that you are trying to make it look like.

author: nctnico
author_rank: Super Contributor
timestamp: December 04, 2013, 11:11:51 pm
content: Quote from: clifford on December 04, 2013, 08:54:36 pmNot on a MIPS platform where you have to execute several instructions while emulating memory and stack thru JTAG to transfer one word. I have improved a lot on OpenOCD's MIPS support (IIRC I got it 2 or 3 times faster by optimising the instructions and data transfer) and add some extra hacks to use the buffered JTAG interface in the FPGA most efficiently.

author: Crazy Ape
author_rank: Regular Contributor
timestamp: December 05, 2013, 06:27:38 am
content: Quote from: nctnico on December 04, 2013, 11:11:51 pmRight, so what you're saying is you had trouble using MIPS' EJTAG extensions in "PrAcc" mode. It's not the JTAG part of EJTAG that was causing you trouble, more the 'E' part.That being said, I do recall tackling ETJAG on a router with BroadCom SOC. No EJTAG "DMA" mode, only "PrAcc", and yes, much fun - NOT.The extensions that were causing you problems were not part of the JTAG standard. Do you have similar nightmare stories using actual JTAG?

author: nctnico
author_rank: Super Contributor
timestamp: December 05, 2013, 08:25:03 am
content: Oh, shifting bits through the JTAG interface is peanuts. But that gets very little done. Its the convoluted protocols which manufacturers put on top of JTAG which make it so unappealing to me. In my world I never came across a situation where I was happy to use JTAG. For starters it always means getting extra hardware before I can get started. And then there are all kinds of signal integrity issues even when connecting a dongle with short wires or flat cable. Turning on the light or plugging in an adapter can cause a large enough pulse to disturb the clock. If the download takes several minutes then something like that gets really anoying. There also was a Xilinx JTAG dongle/software which output the rising edge of the TCK together with TMS and TDO (violating / barely meeting setup timing). Try to get that to work while talking to a whole chain of devices on a board.

author: abyrvalg
author_rank: Frequent Contributor
timestamp: December 05, 2013, 01:27:27 pm
content: ROMless SoCs were real PITA, I prefer to send just some small loader to internal RAM over JTAG, then bring up UART/USB from it and start breathing freely - no data integrity issues, no watchdogs biting while core is halted and much higher speeds usually. Happily things are changing towards ROM boots last years and JTAG is returning to it's second letter denotes - Test.