Cyclone IV E JTAG issues - VCCA voltage level

Hi,

I took a look in the handbook and maybe you could check something additional...

Acc. handbook the "Reset completed" is indicated by nConfig and nStatus both being high (ch. 8). This could validate the Cyclone is ready for configuration to check the 1.0/1.2 V issue (in fact, I would think the 1.2V on the Cyclone IV shall not cause direct failure (otherwise you would observe high current consumption / overload on the internal 1.2V regulator or a hot Cyclone). Nevertheless (assuming it's not a selection process like the speedgrades were on some intel Processors) this overvoltage will not extend the operational life...

Regarding the USB-Blaster I/F (Pin4, VCCA) the Blaster must be powered by 2.5V as the internal circuits are not compatible with lower operation voltages. ("You must power up the VCC of the download cable with a 2.5-V supply from VCCA. For device using VCCIO of 1.2, 1.5, and 1.8V refer to Figure 8-24"). Thus first is to disconnect Pin4 from the board and apply 2.5V to power the USB Blaster... IMHO

Besides this - the VCCA is always 2.5V (being the supply for the PLL) and must be applied even for circuits not using the PLL - maybe you also need to check the routing for the VCCA pins...

I'll cross fingers :-)

Good morning CarlHermann, thanks for the reply.

--- Quote Start ---

Acc. handbook the "Reset completed" is indicated by nConfig and nStatus both being high (ch. 8). This could validate the Cyclone is ready for configuration to check the 1.0/1.2 V issue

--- Quote End ---

Thanks for this great tip.

1. Checked the pullups are 10k to 2v5

2. nConfig is 2V5

3. nStatus is low

any ideas on what the inputs are to the nstatus pin and what might cause the "not completing reset" issue?

--- Quote Start ---

(in fact, I would think the 1.2V on the Cyclone IV shall not cause direct failure (otherwise you would observe high current consumption / overload on the internal 1.2V regulator or a hot Cyclone). Nevertheless (assuming it's not a selection process like the speedgrades were on some intel Processors) this overvoltage will not extend the operational life...

--- Quote End ---

As you mentioned, the Cyclone does not even get warm, let alone hot. Current draw for the complete board is at 120mA

--- Quote Start ---

Regarding the USB-Blaster I/F (Pin4, VCCA) the Blaster must be powered by 2.5V as the internal circuits are not compatible with lower operation voltages. ("You must power up the VCC of the download cable with a 2.5-V supply from VCCA. For device using VCCIO of 1.2, 1.5, and 1.8V refer to Figure 8-24"). Thus first is to disconnect Pin4 from the board and apply 2.5V to power the USB Blaster... IMHO

Besides this - the VCCA is always 2.5V (being the supply for the PLL) and must be applied even for circuits not using the PLL - maybe you also need to check the routing for the VCCA pins...

--- Quote End ---

I ALWAYS read the footnotes but somehow missed this specific one on the VCCA. Anyway, what I did last night at some silly hour was to remove the chip/components on the mainboard (that are connected to the 1V8 rail) and converted the rail to 2V5. Thus my VCCA pins are now 2V5 and so is the byteblaster. The other banks are at 3V3. I also adjusted the core voltage down to 1V, figuring that the FPGA "might" have some overvoltage protection that keeps it in reset.

I tried this but got the same answer. Decided it is not acceptable and triple checked my jtag wiring (I added a separate header with short 30mm wires directly to FPGA JTAG) and found that I had Tdi and Tck swapped around. Fixed that and ran the JTAG debugger again and at last got "Some" result.

The debugger detects an EP3S16 (which is not correct), but still gives a red cross on the TDI pin. So the chain is working better, but not correct yet.

What I don't understand is why the TDI would give a problem. It is input to the FPGA from the byteblaster. I retested the BB on a devkit and it is still ok. Even with the TCK and TDI swapped, it should not damage the FPGA, both are inputs. TDI seems to be stuck to ground now. (it used to toggle when the voltages were wrong). I check with a ohm meter on TDI (power off) and the pin shows a resistance of about 820R to 2V5. The pull-up however is a 10k. I Triple checked that. I isolated only the TDI pin from the rest of the board and measured again the resistance and it is still in the 820R range.

does anyone have ideas on the tdi stuck low issue?

Thanks for your assistance. Every idea/tip triggers new thoughts on this side and is very much appreciated.

Best regards

Ivor

Hi,

well the VCCA is why the slogan "you need just two voltages for the FPGA" some time ago is not valid when you have to interface with 3.3V logic... I struggled once on this "you need to connect VCCA to 2.5V" also on my first Cyclone II board...

While I have currently no clue for the nStatus (assuming there is only the FPGA and the Pull-Up on the line) the "wrong" identification on JTAG is ok... Strange enough the ID reported by the Cyclone IV and III are identical thus the "Auto detect" reports a Cyclone IV as a Cyclone III - you have to correct this to proceed with JTAG configuration...

Referring to ohmic measurements on FPGA pins - be careful when you are using a standard DMM - ohmic measurements are taken (normally) by application of voltage and measurement of currents.. If the DMM applies a measurement voltage above 3.3V, this will either result in internal clamping diodes on the FPGA (which are normally not active w/o being configured) or other I/O structure to get conductive... Sometimes with predamaging the I/O structure - just as a hint...

Nevertheless there is something tying TDI to GND (most likely the Blaster - are there not even some pulses? E.g. on "Auto-Detect"?)

Carlhermann

--- Quote Start ---

well the VCCA is why the slogan "you need just two voltages for the FPGA" some time ago is not valid when you have to interface with 3.3V logic... I struggled once on this "you need to connect VCCA to 2.5V" also on my first Cyclone II board...

--- Quote End ---

Yeah, there are a lot of traps in FPGA design, like pll config etc. I wish I could say this mistake is because it is my first board, but it is because it has been awhile since I did an FPGA board.

--- Quote Start ---

While I have currently no clue for the nStatus (assuming there is only the FPGA and the Pull-Up on the line)

--- Quote End ---

Checked again, nStatus is only connected to 10k pullup to 2v5.

--- Quote Start ---

the "wrong" identification on JTAG is ok... Strange enough the ID reported by the Cyclone IV and III are identical thus the "Auto detect" reports a Cyclone IV as a Cyclone III - you have to correct this to proceed with JTAG configuration...

--- Quote End ---

Ok, that is sort of good news. So the detection as an EP3S16 is normal for autodetect. I will remember to fix in programmer. This could have bugged me for a while, thanks for mentioning it.

--- Quote Start ---

Referring to ohmic measurements on FPGA pins - be careful when you are using a standard DMM - ohmic measurements are taken (normally) by application of voltage and measurement of currents.. If the DMM applies a measurement voltage above 3.3V, this will either result in internal clamping diodes on the FPGA (which are normally not active w/o being configured) or other I/O structure to get conductive... Sometimes with predamaging the I/O structure - just as a hint...

--- Quote End ---

Yip, noted, I suppose I could have damaged the pin, BUT I only measured this after it did not work. Also, I think it is highly unlikely that such a sort event would harm the device. But will keep it in mind.

--- Quote Start ---

Nevertheless there is something tying TDI to GND (most likely the Blaster - are there not even some pulses? E.g. on "Auto-Detect"?)

--- Quote End ---

I put the scope on again, Ch2 on TCK and CH2 on TDI. both normally low (TDI should be high) and this is the case with BB plugged or unplugged. Plugging BB in and running detect has clock signal toggling but nothing on TDI. Well, let me qualify that. I drop the scope voltage setting down to 10mV/DIV and then picked up some "noisy" signals on the TDI to a p-p of about 30mV. Probably the blaster doing his best to drive the signal to 2V5 or the noise feeding in during the tristated periods.

tdi low and the status pin remains the unsolved mysteries...

Hi,

well - if there is only TDI and a pull-up on this Pin and the pin did some pulses initially, even being incorrectly driven with TCK in your first wiring, this TDI perm. low seems strange as both pins are driven by same "output power" from the BB point of view...)...

If the TDI pin is low as soon as the Cyclone is powered this indicates more or less that either the pull-up is missing or the device itself has a short on the input when being under bias. Second is less repairable :-/

Yip, this is the conclusion that I come to as well. If the nStatus was not doing it as well, I would have programmed the EPC and let it program the FPGA, but chances are this will not work either. So the other option is to replace the BGA and hope it solves the both the issues.

Thanks for your ideas and view. Any other (related ;>) ) brainwaves please let me know.

I will respond back with the results. ( I will also AGAIN check the pull up)

Vielen dank

Ivor

Hi,

in case you are about to remove the BGA, I would suggest to use this replacement as an option to check the correct voltages at the power pins, configuration pins ans the interconnection between these pins and the pulls... Just to ensure that everything is ok with the PCB itself...

It's difficult to measure at the pins with BGAs... :-)

--- Quote Start ---

Hi,

in case you are about to remove the BGA, I would suggest to use this replacement as an option to check the correct voltages at the power pins, configuration pins ans the interconnection between these pins and the pulls... Just to ensure that everything is ok with the PCB itself...

It's difficult to measure at the pins with BGAs... :-)

--- Quote End ---

Got the second board of the two that were built the same time.

Before applying ANY power, I adjusted all the voltage rail to be as follows:

Vccint = 1.015V

Vcca = 2.423

Vccio = 3.273

The JTAG pins bank has VCIO of 2.423 volt.

All pull ups are checked.

nConfig goes high, nStatus seems to try to go high, but then is pulled low again, this happens every 65us.

Look very much like a POR event, but the voltages looks in range. Also checked the voltages on the scope and they are not drooping.

Any idea why the device would keep resetting. and why every 65us?

hi,

"trying to go high" sounds not like there is a stable (even perhaps short) pulse but some rise in voltage which does not really reach anything near to a high level...

This definitely - as there is nothing than the Pullup and the Pin being connected to the line - indicates the Cyclone not finishing POR. The question is "why?"

Can you be 100% sure, that there is no mistake in layout or manufacturing that disconnects either on of the power or gnd pins (thus triggering the Built-In Brown-Out / Power fail detection reset) and that the pull-Up is wired to the Cyclone / the 2.5V?

nStatus is bidirectional, thus if e.g. the Pull-Up is broken, not soldered correctly or not connected to VCCIO the missing "High" is detected and restarts configuration... Maybe worth checking...

Is there anything connected to nConfig that externally resets the Cyclone (nStatus goes low with nConfig being driven low) or is nConfig initially going high and remains a stable High?

Besides what's written in the handbook... I may have to recheck this, but iirc

* nconfig goes high => reset condition removed

* nStatus goes high => internal device reset "do this an that" completed, device can accept configuration data

* Conf_Done goes high with device configured

Even with no data (e.g. blank Config device or nothing by JTAG) the nStatus should stay high as long as there is no interrupt on the power lines...

(having read through the configuration section I did not really found the magic 65µs...)

CarlHermann, First I want to thank you for supporting me during this problem. It helps an incredible amount to have someone to bounce ideas off, and to generate new paths of investigation. I really do appreciate your help.

--- Quote Start ---

"trying to go high" sounds not like there is a stable (even perhaps short) pulse but some rise in voltage which does not really reach anything near to a high level...

This definitely - as there is nothing than the Pullup and the Pin being connected to the line - indicates the Cyclone not finishing POR. The question is "why?"

--- Quote End ---

I agree with this.

--- Quote Start ---

Can you be 100% sure, that there is no mistake in layout or manufacturing that disconnects either on of the power or gnd pins (thus triggering the Built-In Brown-Out / Power fail detection reset) and that the pull-Up is wired to the Cyclone / the 2.5V?

nStatus is bidirectional, thus if e.g. the Pull-Up is broken, not soldered correctly or not connected to VCCIO the missing "High" is detected and restarts configuration... Maybe worth checking...

--- Quote End ---

You hit the nail on the head. Last night while staring at the pulses on nStats, I measured each of the voltage rails. Later I realised that I never actually measured the voltages on ALL the fpga power vias. So I did that last night (about midnight) and low and behold, the VCCINT has some disconnected pins. I have a regulator at the point of load feeding into the via grid under the FPGA, but for some reason ( I suspect incorrect copper pour sequence) the VCCINT section got split in two by a ground section. This should have been pick up by the DRC as an unconnected route. I will check later as to why I missed the DRC error.

I decided last night it would be better to remeasure all the pins again and then do the mode while I am fresh. I will report back with the results.

--- Quote Start ---

Is there anything connected to nConfig that externally resets the Cyclone (nStatus goes low with nConfig being driven low) or is nConfig initially going high and remains a stable High?

Besides what's written in the handbook... I may have to recheck this, but iirc

* nconfig goes high => reset condition removed

* nStatus goes high => internal device reset "do this an that" completed, device can accept configuration data

* Conf_Done goes high with device configured

Even with no data (e.g. blank Config device or nothing by JTAG) the nStatus should stay high as long as there is no interrupt on the power lines...

(having read through the configuration section I did not really found the magic 65µs...)

--- Quote End ---

I have read the handbooks like crazy but also did not find anything about the 65us. As far as nConfig goes, I did have an EPCS16 on board, but I disabled it for the JTAG testing, so the nConfig goes high(according to scope) and never triggers low again.