cyclone2, odd problems

Just so I understand better ...

1 - What is the processor? Can you fully detail the JTAG chain (all components in the chain, the order of the components, any level converters?). My first suspicion is there is simply poor signal integrity in the JTAG chain circuitry. JTAG is one of those things that seems simple because it's such a low data rate, but it must be layed out correctly or it can provide no end of headaches. It will work some of the time and fail others. Engineers typically assume the JTAG chain is a no brainer only to suffer later on.

One of the best simple design guidelines is to route the clock in opposite direction of the data. So hit the last device in the chain with TCK first and procede to route TCK through all the devices in the chain in reverse order. Kind of like how you would route the clock to shift registers on a board.

2 - It would be extremely odd if the ROM itself were failing. I would consider that a last suspicion. Therefore, we ought to consider the surrounding circuitry instead.

a - Clocking. Is this a single clock ROM. Is the design meeting timing requirements? Is the logic that drives the address pins being driven by the same clock that's driving the ROM?

b - Reset. Is a proper reset being applied to the design?

c - Design. Is there anything in the design that might cause the wrong ROM address to be read after power-up.

Jake

1- not hearing anything from altera, i relaid out the board and solved this, sort of. there was only one jtag device. processor is netburner with only address, data and few control lines connected. there is a 75mhz clock coming from the proccessor, but not until it comes out of reset. there is all so a usb circuit that feeds a 60mhz clock ot the fpga, but not until the proccessor sets it up. some of the proccessor signals shared the same side as jtag. there is also a 25mhz clock.

what i did: rotated chip 90 degrees, so jtag is on the other side of proccessor's interface. changed from using snubber termination on data and no termination on other lines (remember, i have 2 other boards with exact same layout that worked just fine, the only difference is the components are 'closer' together); changed too, 47 ohm series resistor termination in 'every' line. also routed fpga 'done' signal to proccessor's reset circuitry and so proccessor is held in reset until the fpga is done loading.

i can now load a logic anaylizer and use it.

2- totally agree, "extremely odd", i was exteremely supprised when it was happening.

data coming in is latched at the pins, then this goes thru to the address register of the rom and the output is registered (-a- single clock). the worst case timing, as i remember, is 2.5ns, and the clock is 25Mhz. don't remember what the rom timing is, but sure it's better than 40ns.

power up the system and software guy's test software could say no problems. shut down and power up again and software guy may say, 'problems'. i also had a embeded logic anyalzer in the fpga to monitor input/output of the rom and other control signals. when problems were encountered, the logic anylzer all ways showed 'one' address, that was legal coming in, (same test software), and data out was wrong. power down and power back up and if it was failing (around 30% chance), it would be a 'different' address that was failing. now this was the decoding 10to10 bit rom, which 8 coulc be data and 2 contol bits. any illegal address would output a 0x3FF. when the rom failed, this was the output. i say this because, if the failure was during the bit loading of the fpga, i would expect a bit failure or some type, not the address failure it seems to show.

b- reset, power up of fpga. 'I' don't see anything wrong.

c- ? think it's as simpe as it could be (send it to if you want).

i stated, i took the rom's out and since then i've had not gotten any report back of continuous failures. my problem is that the boards are being used so i can't play with them. i have recently been able to get another board, with a cyclone3 on it, in the que for me to play with, but that might be another month out.

you've stated power problem for the stratix. could this be simular?

thanks

dave

--- Quote Start ---

JTAG is one of those things that seems simple because it's such a low data rate

--- Quote End ---

You hit the point. Although the data rate is low, the FPGA internal logic processing TCK isn't. So you can achieve false JTAG clocking either by ringing edges or crosstalk from other on-board fast signals. The latter should be considered if configuration in a multiple devices chain fails, after ather parts of the design started operation.

I think it's safe to say the cyclone II does not have a power-up problem. Altera would most certainly be aware of it by now.

Jake