Programmable Devices
CPLDs, FPGAs, SoC FPGAs, Configuration, and Transceivers
21602 Discussions

Loss of FPGA configuration

Altera_Forum
Honored Contributor II
2,152 Views

To minimize power consumption, I have the Oscillator input of the main part of my Stratix III design gated (glitchfree keeping low, if gated). 

 

Connected to this clock (50 MHz) are two synchronized DDR interfaces (alt_mem_phy) and behind it, the major part of the design, all running at 200 MHz. A smaller part of it is active (I2C slave to wake the item from its sleep mode). 

 

The principle works quite well, on a majority of my boards (~60%) I can observe the gating signal, the gated clock and the 200 MHz clock (PLL output) becoming slower and slower, then stopping. 

 

However, on some boards, ~16-18us after sending it to sleep (200 MHz clock is already very slow), the FPGA looses its configuration and goes to unconfigured state afterwards. 

 

The bad case occurs allways on an affected board, never on a good board. 

 

My questions: 

- Which power supply (VCC or VCCL mor another one) is responsible to keep the configuration (in order to search for power shortage)? 

- Which conditions may lead to a reset of the FPGA configuration? 

- Is there any literature on bringing DDR memory controller IP to a sleep mode? Is a minimal frequency required (just to keep the configuration in the FPGA, not to have any functionality)? 

- Any other idea? 

 

Thanks in advance ;-)
0 Kudos
7 Replies
Altera_Forum
Honored Contributor II
1,087 Views

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.
0 Kudos
Altera_Forum
Honored Contributor II
1,087 Views

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?
0 Kudos
Altera_Forum
Honored Contributor II
1,087 Views

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.
0 Kudos
Altera_Forum
Honored Contributor II
1,087 Views

> 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
0 Kudos
Altera_Forum
Honored Contributor II
1,087 Views

 

--- 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.
0 Kudos
Altera_Forum
Honored Contributor II
1,087 Views

 

--- 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?
0 Kudos
Altera_Forum
Honored Contributor II
1,087 Views

 

--- 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!
0 Kudos
Reply