Quartus II (v10.0) + Cyclone II : JTAG Issues

[Altera_Forum]

Dear all, 

 I have a JTAG chain of two devices. The first is a TI processor and the second a Cyclone II FPGA.   Using the TI JTAG emulator and configuring it to 'bypass' the cyclone II with an instruction register length of 10, we have never had any problems with connectivity.   Using Quartus II (v10.0) with a USB Blaster (rev C) we have never successfully been able to program. When using the Quartus II JTAG chain debugger, it successfully detects the right device when I run 'Test JTAG Chain' (See image2.jpg attached) but it does not pickup the first device. When I run the IDCODE scanner it does pick up both devices but reports back a warning (see image1.jpg). I have noticed that if I run the IDCODE scanner over and over sometimes the IDCODE reported back of the TI processor changes implying to me data integrity issues.   Alternate JTAG chain debuggers have reported back a JTAG chain length of 48 bits (Instruction register scanner), which with the cyclone II @ 10, leaves 38 for the TI DSP which seems coherent with some of their other processors (The processor I am using does not appear explicitely in any of their lists). The IDCODE scanner reports back an instruction register length of 255 for the 'Unknown' device, which I know is incorrect.   I have already taken the flat ribbon cable out of the equation by essentially eliminating it. The only thing I noticed was that the IDCODE scanner became a bit more consistent, but still always flagging the warning.   I will continue to assume this is a hardware level issue and start inserting things like series termination resistors to see what happens.   For now I raise the inquiry to see what others think/have seen.   Many thanks in advance,   James

[Altera_Forum]

We have replaced the yellow USB Blaster flat cable (regardless if Rev B or C) by a simple ribbon cable of max. 10cm as we had some JTAG problems in the past on boards with more than 1 device on the chain. 

If you have seen improvements by using a different connection as the flat cable you should inspect your jtag signals how they are layoutet and if you have the correct pull up's and down' and the correct voltage for pull up's. out of my head 3,3v for C2 and 2,5V for C3 could you show a schematic that just shows the jtag connector and all connections / parts involved to see the signal flow and how all jtag signals are connected ? do you have any else like the JTAG USB Blaster that is used for production inviroment to scan the jtag line ?

[Altera_Forum]

Thanks for the reply, 

 schematic 1.jpg = entry point (Please note I have added an external switch on /TRST to ensure the TI DSP gets put into a reset state to allow for proper bypassing, i.e. TDO of the TI DSP may not feed through TDI if in a wrong state, confirmed TDI passes through to TDO on scope). schematic 2.jpg = pass through (into and out of TI DSP, includes power rails) schematic 3.jpg = pass through entry into second device (Cyclone II) and exit   I realize it is a 14 pin TI interface hooked up to Altera 10 pin. I have an adapter board connecting the required 5 pins from USB Blaster to this interface.   I have just noticed that on the TDI into the TI DSP (Schematic 1.jpg) I have forgotten the 1k pull up to 3V3.   When I removed the 'yellow flat cable', I actually took my JTAG adapter vero board (very small) and soldered it straight into the USB BLaster (There goes my warranty! :) )   To answer your question, yes we use the XDS510 USB JTAG emulator for communicating with the TI DSP (first in the chain), where the Cyclone II is the second part of this chain, and communication has never been an issue, even when the design is installed in a very noisy environment (i.e. high power motor control cabinet). This leads me to believe that the signal integrity 'on my board' is fine.   My next steps are going to be to build up an adapter board with:   1. A buffer stage between the USB Blaster and my design 2. Another path with series termination resistors (100 Ohm) 3. Another path with AC coupled parallel termination resistors   I will keep you posted as to the results. It appears to me that many people have signal integrity issues with USB Blaster and multi chain designs. My guess is the USB blaster has very high speed buffers (beyond what it requires) with no adequate transmission line considerations and is very susceptible to over/undershoots. While doing my hack to the USB Blaster this appears to be the case as the design of the USB BLaster was VERY simple on a 2 layer PCB.   Cheers,   James

[Altera_Forum]

let me summarize  

jtag tdi comes from cn1a pin 3 goes to ti pin m9 from ti pin k9 as tdo to tdi fppga c2 pin 13 with 1k pull up to 3,3v from fpga c2 tdo pin 10 to ??? with a 0R to ???  ( i can't scroll your altium screenshot ;) )  from the datasheet and app notes for cyclone II configuration c2 page 55 figure 13-22 (http://www.altera.com/literature/hb/cyc2/cyc2_cii51013.pdf) JTAG TMS & TDI need 1K pull up to 3,3V and TCK 1K pull down to GND i have done some designs with 1k pull up at TMS and TDI but the datasheet has been changed a while ago further more you must enshure that nCE is directly connected to GND do not use any resitance here in between

[Altera_Forum]

Your summary is correct and in the third schematic image you can scroll the jpg :) The 0 ohm on the TDO of the C2 is there in case the C2 is not loaded (it is a high cost option), so that allows for the TDO to be passed in the event the device is not there. To answer your question, TDO out of C2 pin 10 goes out to pin 7 of CN1. 

 TMS and TCK have the appropriate pull ups at the C2 device (shared line). TDI has the 1k pull up @ C2 but TI never had a requirement for it so it never got added to the front of the chain. I tried adding this yesterday with no luck. Same symptoms.   nCE? What Chip enable line are you referring to?

[Altera_Forum]

nCE of the Cyclone 2 FPGA 

it is required that this pin is directly connected to GND for propper JTAG configuration, see the figure 13-22 i mentioned before and the notes there.

[Altera_Forum]

Gotcha. Yes it is tied to GND in my design. 

 Adapter design is ready for etching, will let you know of the results of the 3 methodologies it will employ and if any of them fix up the issue.

[Altera_Forum]

Did you ever get a resolution on this issue? I am troubleshooting a similar issue on a new custom board using 3 parts in the device chain, Vitesse PHY is# 1, S4GX180 is# 2 and MAXII1270 is# 3 in the chain. Any tips would be appreciated, if I don't have a solution by Fri we start drilling vias and adding wire-mods.

[Altera_Forum]

--- Quote Start ---  Did you ever get a resolution on this issue? I am troubleshooting a similar issue on a new custom board using 3 parts in the device chain, Vitesse PHY is# 1, S4GX180 is# 2 and MAXII1270 is# 3 in the chain. Any tips would be appreciated, if I don't have a solution by Fri we start drilling vias and adding wire-mods.  --- Quote End ---     Hey,   not yet. I designed a little PCB to test out 'serial' and 'parallel' terminations as well as a third signal path using a buffer stage.   Shortening the USB blaster cable did not fix it, but may be required alongside the termination methods I am going to test.   I'll keep you posted. I expect the PCB to arrive in a few days.

[Altera_Forum]

I got the jtag chain working today by drilling a via and adding a wire to bypass the Vitesse PHY chip, leaving just the FPGA and CPLD in the chain. I still don't have a good answer as to why this worked, signal integrity looks comparable, but I can program my devices now. 

 As an interesting side note, originally I could properly scan the chain with an EthernetBlaster using the autodetect, but could not program, but the Rev C USB blaster gave me the same error that you describe above. After modding the board and bypassing the PHY, both the EthernetBlaster and USB blaster can scan the chain and program devices w/o issue. We could also properly boundary scan the board using Gopel's cascon software, but Quartus didn't want to play (Cascon runs the jtag chain at a much slower frequency however).  After confirming signal integrity looked good, I guessed that the PHY chip was the problem b/c we've done ~5 boards this year using FPGAs and CPLDs and haven't had any jtag issues, and this PHY is a 1st for us.

[Altera_Forum]

My little module board came in and I tested, with a shortened USB Blaster cable: 

 1. Series termination 2. A.C. parallel 3. Buffer stage   On 2 and 3 my signals were clean as distilled water and I still had the same problem.   My solution unfortunately is going to have to be the same as yours. I have to leave the JTAG RST line on my DSP pulled low to allow its TDO to float and I hit the test point tied to this to inject the USB Blaster TDI straight into the FPGA (second in chain).   How annoying. I have lost my confidence in long chains with Altera equipment inline. The TI DSP seemed to handle the whole chain just fine.

[Altera_Forum]

I brought this up to my altera FAE and he'll come in to help troubleshoot when we get back to chasing this issue. Currently we've only re-worked 1 board but that's all we need at this point while we finish board checkout, then we'll get back to chasing down why this doesn't work in hopes that we don't have to re-work the remaining boards. If we come up with a solution or answer I'll post here, probably looking at a few weeks since this board is complicated.

[Altera_Forum]

Good call on the FAE. I'll do the same and see what we come up w ith on this end.