Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

YAJT (Yet Another Jtag Thread) - Signal integrity issues?

Status
Not open for further replies.

alexandicity

Newbie level 6
Joined
Oct 18, 2017
Messages
11
Helped
0
Reputation
0
Reaction score
0
Trophy points
1
Activity points
166
Hi all,

I'm trying to program an FPGA - a Proasic3 - via JTAG from a LCPS programmer (functionally equivalent to a Flashpro3).

When all wired up to the header, I start the programming process. The reading of the device IDCODE and other status data works fine (at least, I get consistent and sensible values - including a correct value of previous programming cycles).

Then I try to program. The first part of this is a chain scan, which fails. To me, all indications suggest a signal integrity issue.

The error I get from the programmer is:

Error: programmer '77435' : Signal Integrity Failure
Integrity Check Pattern Not Found.
Integrity Check Pattern :
550FAAF000FF0000FFFF
IrScan Error.
Possible chain exceeds expected maximum device count: 256.
Chain Analysis Failed.
Error: programmer '77435' : Data Bit length : 8272
Error: programmer '77435' : Compare Data : 41550F0AFFFF00FFFF0000FF0000FF00FF00FF00FF00FF0000FFFFFFFFFFFFFFFFFFF(lots more FF)
Error: programmer '77435' : Scan Chain FAILED.
Error: Failed to run Action.


Seems to be that the device's JTAG controller is getting into a weird state. Interestingly, it looks like the compare data (TDO, I assume) is consistent between attempts, suggesting it's not just some random event causing this.

Looking at the signals, I see good rises and falls, but a lot of overshoot. I fear that the overshoot is occasionally sufficient to corrupt the message. I hack around this by setting my scope probes to 1X and therefore introducing some 100pF capacitance. This makes the signals much cleaner (even if I feel dirty for doing so). When I set this, I can get the boundary scan to pass and the process to move into the erase and programming steps But this fails too, on verify, with error code 11 or -24 (indicating bad signal integrity, Vjtag or Vpump). Supply sounds like a likely candidate - during erase/programming, I see no current draw on either, which is very wrong. I assume that it is not actually doing any programming, and that more likely device's JTAG controller is still getting into a weird state.

Vpump is 3.3V and has a local 0.01uF and 0.22uF near the package pin. Vjtag, along with Vcc and Vcci, are 1.5V. Both look very stable and clean on the board near the package throughout, so I don't *think* it's a problem with these themselves. TCK is running at 1MHz, which seems to be its lowest setting. I have a 20cm wiring harness running between programmer and device, and it is possible that something is mis-wired or poorly connected (although I have checked both!) The programmer is quite happy programming an IGLOO device on a starter board.

Any thoughts as to what might be going on? Is there ever a situation where you need to add capacitance to JTAG lines? What might I be able to do to debug this further?
 

Do you have the proper pullups on TDI, TMS, and TRST and termination on TCK?

Is that severe under/overshoot on TCK that could easily cause problems with moving the TAP state machine to the wrong state. As 1149.1 is supposed to be no more than 10 MHz (though lots of devices allow it to run higher) the edge rates of TCK don't need to be in the sub-ns. The statement that you have good rise and fall times seems to me that you really have excessively fast rise/fall times given you have lots of overshoot.
 

Hi ads-ee, thanks for the response.

I have pull-downs (10k each) on the TCK and TRST lines, as that is what is suggested by the manufacturer (pg 359). There may be pull-ups on the programmer. I have no explicit termination on the TCK. I am going to add some capacitance more deliberately to each line to smooth it out, and I will also try adding a 100R to the clock.

Because everyone likes pictures, here's pair of captures from my scope. This is with the probes at default 10X, introducing little capacitance. Note the overshoot that occurs - would you call this problematic? The first shows the whole exchange during a chain scan, with TDO at the top remaining high for another 12ms before dropping low (presumably the source of all the Fs). TDI is not shown (as I have no more probes)! This second shot shows the same, but zoomed to show the waveform per bit.

NewFile3.png
NewFile4.png
 

A little development. By adding a series resistance to the TDO line, and a series resistance and a 100pF capacitor (a LPF) to the TCK line, I am able to get the programming process to complete successfully. Reportedly successful. It erases, programs and verifies fine and without error. However, I m suspicious. Partially because the FPGA does not appear to be working afterwards (which tbh may just be an error in my HDL somewhere). But more suspiciously, there was virtually no current draw during the erase, program or verify phases. >1mA on Vpump and >10mA on Vjtag. This looks very odd to be - I would expect dozens of mA on both. So I believe that the device is actually not programming at all, despite the apparent success reported via JTAG. Thoughts?
 

Hi,

Your link to the datasheet doesn't work because it references to your harddisk.

Your scope pictures show serious problems with grounding, bypassing or oter problems.
I assume your problems now are programming problems...but in future your application will suffer from problems, too.

Can you try to reduce JTAG clock frequency?

Please show your schematic and your PCB layout of the FPGA circuit.
Please show a photo of your complete connections and wiring.

Klaus
 

it references to your harddisk.Is that severe under/overshoot on TCK that could easily cause problems with moving the TAP state machine to the wrong state.
 

Hello all!

Apologies for the bad link. The correct one is: http://www.actel.com/documents/PA3_UG.pdf

I agree the signal looks bad. I will provide schematic/photo/layout when I get back to my computer. I think the board itself should be ok, and I expect my programming wiring is the most likely source of the problem.

I am running at 1MHz clock, which is the slowest I can (apparently) set in the FlashPro software utility.

I am curious, though, how the JTAG programming can claim to complete successfully if it is not drawing any substantial supply current. I suppose I should first ask if a current draw on Vpump is normally present - from the bypass requirement, I presume there must be a large and variable load on this line during the process.
 

I expect my programming wiring is the most likely source of the problem.
You have cross talk problems with the TCK showing up on the TDO, TMS signals every time it switches. You also have severe reflections on TCL, which means you probably don't have good termination on that line. I also don't like the indeterminate voltage level on TDO.

Not sure why you show TDO and not TDI, TDI is the input to the FPGA and is the data being sent from the programmer to the FPGA.

Unless you've got a ribbon cable with grounds between the JTAG signals you probably continue to have issues with that 20 cm cable harness (I sure hope you don't have TCK, TDI, TDO, TMS, and TRST zip-tied together as a bundle of 5 wires, though the signals on the scope sure look like they were).

alexandicity said:
I suppose I should first ask if a current draw on Vpump is normally present - from the bypass requirement, I presume there must be a large and variable load on this line during the process.
Your bypass of 0.01uF and 0.22uF is not large neither qualifies as bulk capacitance.

You might want to look at this for termination of JTAG
https://www.xjtag.com/about-jtag/design-for-test-guidelines/
 

Not sure I follow you with the TCK crosstalk - while I see similar waveforms on all three lines, I presumed these were all due to the same line inductance properties and driver in the programmer. But they might be. The wiring is exactly as you describe - a bunch of wires with indiscriminate arrangement. I was unaware that there was such sensitivity to harness cabling (I rarely see 1MHz+ signals, so I'm not so familiar with the problems that can occur in them). I have no external TCK termination

I figured TDO was a better indicator of what was going on (as it shows the signal later in the "path" and can be corresponded more to the compare data). I looked at TDI too - it is similar in waveform to the TMS and TCK signals. I too am not too happy about the differing voltages; it looks as if it is being driven from more than one source.

Those capacitors aren't bulk capacitance (that is elsewhere); it's what the datasheet recommends for that line. Because they are so specific about them, I assumed there must be some substantial transient loads on it (as opposed to being a simple bias voltage).

So, it seems the problems are in my cabling, as suspected. I will look to build a better and shorter wiring to mitigate these problems in the future. Thanks for the link - it is quite a different implementation to the manufacturer's recommendations, but I can see how that configuration would help mitigate some of the problems I have seen here. In the short-term, though, the successful programming does not appear to be erroneously reported; I am now seeing the FPGA behave as it should, which is promising. I will need to look closely to see how signals on the board itself look without the programming connections.
 

The crosstalk of the clock can be seen each time the clock transitions there are little spikes from the current voltage level of the other two signals. Running wires next to each other in a clump for 20cm (nearly 8") will definitely exhibit crosstalk like this. Crosstalk isn't due to the 1MHz frequency of the signalling its due to the distance the signal travels down the wire adjacent to the other wires.

TDO is an output of the FPGA it isn't further down the path, it is the last output driver in a series circuit. If you want to look at the signal you should be looking at it on the receiver side, i.e. the programming pod.

Also TMS is exhibiting a small DC offset as the indicator for the ground is below the level of the signal maybe 0.2V.

The bypass is for dealing with any high frequency switching currents on the Vpump supply during programming. Vpump probably has some strict requirements on the ripple as most flash has pretty tight tolerance on the programming voltage that is used to program the flash cell.
 

Right! Well, thank you for your help explaining these points - I think i understand the problem much better now.
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top