Loss of FPGA configuration

Hi:

The Loss of configuration should only happen at Power on Reset, or by pulling nCONFIG low.

The Supply's associated with the Power on Reset are VCCPT, VCCPGM, VCCPD VCC and VCCL

as shown in Figure 10-3 in the handbook. but other supplies VCCA_PLL VCCD_PLL VCCIO and VCC_CLKIN are also mention in the tRAMP Requirements in Table 10-1.

(See Handbook pages 10-4 and 10-5)

Another possible issue would be with the nCONFIG pullup is weak, or has a short to your clock enable signal in the bad case.

A third Possibility is that instead of the PLL settling to zero, it runs wild. And actually draws more current than your expecting, causing one of the supplies to droop. You may want to either pull all power from the FPGA if you can to save maximum power, or clock gate internally in the FPGA after the PLL.

Thanks for sharing your thoughts. Out of these, I've got some further questions:

- In my setup, the CONFIGn is stable, therefor, I assume that POR is triggered. Which of the supply voltages that are monitored by POR would you expect to dipp assumed the PLL is "running wild"?

- Are there other indicators to make out whether the PLL is the "bad" guy (I can not see the PLL output clock going mad)?

- I use two synchronized DDR2 I/F with internal PLL, therefor, access to the PLL (to directly gate ate the clock output drivers) seems not trivial for me. Until now, I wasn't able to have external DDR2 PLL synchronized. Therefor, I intend to reduce the clock to a very low one instead of completely switching it off. May this be viable?

I think neither the memory IP nor the RAM hardware is intended to work with this kind of clock gating. Problems, e.g. suspected excessive current consumption will surely not occur in the PLL and also unlikely in the FPGA core, but likely in the internal or external peripherals.

Did you try to stop the affected system parts, including the PLL with an asynchronous reset? This would also make clock gating needless.

> Did you try to stop the affected system parts, including the PLL with an asynchronous reset?

I replaced the clock gating by the reset (global_reset_n of DDR2 IP) as you indicated. On the board I'm currently working on, the error does not show up anymore. I even may gate the clock subsequently to the reset without any harm.

However: I still observe significant power supply dip on VCCL(1.1V) and VCCPD (2.5V) when activating the reset (without clock gating), and I assume the POR did just not trigger (but may do so on another device...). Maybe I have some illegal bank voltage combination (did check that, but found no offending conditions so far)?

=================================================

This is how my topology looks like (EP3SL50780):

P28, CLK1p, Bank 1C, 3.3V : 50 MHz clock input to general PLL

AH15, CLK5n, Bank 3C, 1.8V : Direct feed (here was the gate) from P28

A14, CLK13n, Bank 7C, 1.8V : Direct feed (here was the gate) from P28

Memory interface AB:

AG15, CLK5p, Bank 3C, 1.8V : 50 MHz DDR PLL clock input (fed from AH15)

Memory interface uses banks: 3A, 3C, 4A

Memory interface CD:

B14, CLK13p, Bank 7C, 1.8V : 50 MHz DDR PLL clock input (fed from A14)

Memory interface uses banks: 7A, 7C, 8A

PLL outputs of both memory interface are merged as indicated by AN462, most of the design is clocked with the merged phy_clk (200 MHz, fanout 17679). This is the clock I intend to stop for sleep mode.

My general power supply concept looks like this:

1V1_VCCL : All 24 VCLL

1V1_VCC : All 8 VCC

1V1_VCCD1 : VCCD_PLL_B1

1V1_VCCD2 : VCCD_PLL_L2

1V1_VCCD3 : VCCD_PLL_R2

1V1_VCCD4 : VCCD_PLL_T1

1V8 . VCCIO1A/2A/3A/3C/4A/4C/5A/6A/7A/7C/8A/

2V5 : VCC_CLKIN3C/4C/7C/8C

VCCBAT

VCCPD1A/2A/3A/3C/4A/4C/5A/5C/6A/6C/7A/7C/8A

VCCIO5C/6C

2V5_VCCPT : All 8 VCCPT

2V5_A : VCCA_PLL_B1/L2/R2/T1

3V3 : All 2 VCCPGM

VCCPD1C/2C/8C

VCCIO8C

--- Quote Start ---

However: I still observe significant power supply dip on VCCL(1.1V) and VCCPD (2.5V) when activating the reset (without clock gating), and I assume the POR did just not trigger (but may do so on another device...). Maybe I have some illegal bank voltage combination (did check that, but found no offending conditions so far)?

--- Quote End ---

The observation seems to suggest, that the suspected power supply drop below reset threshold happens at internal nodes (PLL and core supply) and not peripheral supply, as I previously guessed. This changes the picture. I wonder, if the current transient may be normal operation and the voltage drop primarly a board hardware problem.

To get clarity about the effect, I would either measure the respective supply rail dynamic current or check the power supply transient response with a test load.

--- Quote Start ---

To get clarity about the effect, I would either measure the respective supply rail dynamic current or check the power supply transient response with a test load.

--- Quote End ---

I'm going to do that in near future.

In meantime: Which dynamic current peaks would you expect putting a PLL into reset mode without gating it's input clock?

Actually, the same 2.5V supply I use for VCCPD powers VCC_CLKIN3C/4C/7C/8C, too. According to spec, these supplies may draw up to 250mA each. May this be the hot spot in question?

--- Quote Start ---

I wonder, if the current transient may be normal operation and the voltage drop primarly a board hardware problem.

--- Quote End ---

Actually, this was it. A little embarassing for me, but I stopped the power supply synchronisation as well, when going to sleep mode (and so having a weakness in supply at the begin of the sleep mode). Using a clock that doesn't stop makes the sleep mode work perfectly, even when just gatinng the input clock. Additionally putting the DDR I/F into reset state prior to the ghating is even slighly better from a consumption point of view.

Sorry for bothering you about this, the hints were great help just the same!