Saving state on power off

[Axk]

Given a circuit with an FPGA and power disappearing how do you implement triggering of saving the current state?

I'm thinking about adding a capacitor between the power supply and FPGA's power pins while having a GPIO pin monitor the power supply bypassing the capacitor.
When the GPIO pin goes low then it would save the state. Assuming the capacitor will give it enough time to save the state before the FPGA loses power.

Are there any standard approach(es) to dealing with "save on power off"?

[NiHaoMike]

That can certainly work and is done in quite a few popular 3D printers. Another solution is to constantly save the state to FRAM or SRAM with battery or supercap backup.

[Ian.M]

It doesn't matter whether its a MCU, FPGA or other digital processor - the key ingredients are the same:

* Some sort of non-volatile memory.

* A power supervisor chip (or internal module) to either hold the processor in reset  when its supply drops, or to de-assert the NVM Chip Enable so the processor doesn't corrupt the NVM with spurious writes as it drops below its min. operating voltage

* Optionally, for write endurance limited NVMs like FLASH or EEPROM, or just to make maintaining data integrity easier,  advance warning of power failure e.g loss of AC input, low battery detection, etc. to give enough time to save the state, or complete any pending writes, then the firmware locks out further writes until the incoming power is OK again (with or without compete powerdown in-between).  If you don't have a power fail interrupt, you'll have to store multiple copies of the data with checksums as any copy of the data set may be corrupted by power loss while updating it.

ultra-low-power MCUs can take an end-run around the problem: Maintain power to the CPU with a backup battery or supercap, and when incoming power-loss is detected, enter a low power sleep state that preserves internal RAM contents.

Caution: if using FLASH or EEPROM NVM in mains powered or removable battery applications, its advisable to rate-limit NVM updates, otherwise a very noisy mains supply or intermittent battery contact due to vibration can cause rapidly repeated updates and chew through the NVM'ss expected write endurance lifetime in weeks or months rather than the expected years or decades.  The trade-off is the possible loss of any state changes in the last X minutes before power loss, where X is the interval you chose to rate limit updates.  This does not apply to effectively unlimited write endurance NVM, e.g. FRAM and battery backed static RAM

[jbb]

Using an FPGA may make things more difficult, because you may be using internal block RAMs etc. Any technique which relies on pushing data into non-volatile (or battery backed) memory will need some hardware support to a) write the important data out periodically and b) get it back in again after a blackout.

This will be easier if your FPGA has a microcontroller inside and all the relevant data is mapped to the micro’s memory space.

If you need to maintain all of the state, you might need to simply deploy a backup battery large enough to keep the whole FPGA alive. (Note: clock gating in the FPGA could be very helpful here in terms of reducing power consumption / battery size.)

[jbb]

Oh, yes. I forgot...
In terms of system design, you can also use a specially designed power supply that can keep the DC rails up for a little while after the main supply drops out (i.e. a large capacitor somewhere). Then use a monitor circuit (with de glitching) on the power input  to send a signal to the FPGA saying ‘power’s down, shut off loads and save critical states NOW.’

I have seen a few systems which go so far as having a little LiPo or LiFePO4 cell to provide ‘last gasp’ features including state saving and even sending a power loss message via cellular modem.

[DaJMasta]

Similar technique, different implementation, you can do your power off monitoring on the mains side of your power supply, so that as long as you have enough cycles to save state on an interrupt, you get to use the capacitance in your power supply output without adding extra or trying to sense it very early on in the discharge cycle.


It sort of comes down to how long you need to save state, though.  If there's no capacitance or the chip may be in sleep or very slow operation, you probably want something that is just regularly saved or an additional supply (capacitor) to give it the time to save.  If you keep your save requirements for the state to just a few cycles and the power sensor is quick and on a high priority interrupt, you may be able to get away with just the power sensor, no extra storage or hardware.  With traditional power supply designs, you likely have at least 100uS, and probably have several ms before the power drops low enough to prevent operation, so you just have to be able to sense the fault and react in that window.

[Axk]

I just need to save around 10 bytes of state and planning to save it into the FPGA's (LCXMO2-1200HC) internal flash.
So I hope to get away with a couple of hundred of uF of capacitance to give it enough time (a couple of milliseconds at around 20mA max) to write to the flash.

[mariush]

How often does that state change ?
Maybe have a flag which is set if any of the bits in those 10 bytes changes, and start a timer at that point... when 5-10 seconds go by, dump the bytes to flash and reset the flag

[Axk]

up to 1.5Meg times a second

[jbb]

Eek, that’s a lot.  Now we can guess why you’re using an FPGA

You should check out the erase / write lifetime of the internal flash. As someone said earlier, you could get a lot of write cycles if the incoming AC power goes intermittent.

[Axk]

Thinking about the implementation details now.
How do I detect the loss of power as close to the FPGA as possible, without going all the way up to the input of the circuit (which is 54V)?

Putting a Schottky diode right before the backup capacitor and then sensing before the diode comes to mind (so that when the input current is lost the FPGA continues to work from the capacitor but sensing input doesn't see the voltage on the capacitor).

Will this approach work?

[Ian.M]

That depends on how much margin you've got between the normal FPGA operating voltage and the minimum voltage at which it can operate normally + write to FLASH.  If you tap off earlier in the PSU, before the regulator, (possibly via a potential divider to a micropower comparator), you get a lot more warning  time for a lot less capacitance as the input side of the regulator can drop far further below its normal voltage before the FPGA browns out. You'll probably still want a diode so the comparator doesn't sense the slowly dropping bulk cap voltage after the supply input goes away.

[Axk]

Thinking about it more, I already have voltage measurement before the regulator and the voltage divider (VSEN) that that is measured is disconnected when the circuit is switched off.
So I suppose should be able to use this voltage measurement provided I add enough capacitance (not added in the schematic yet) to ground after the regulator to give it time to write to flash.

[NorthGuy]

FPGA is likely to be high power which makes it difficult to power with a capacitor. I would use a small low power MCU instead of flash fed by a separate linear regulator. You would pass the state to the MCU continuously. MCU would detect voltage sag and then would store the state in the internal flash. You don't need a big capacitor to maintain an MCU and it would cost you the same as flash IC. You can also use the same MCU to power down your FPGA gracefully.

[Axk]

To write one page of flash it takes 0.1ms.
I can erase the flash on power on, so I only need about 0.1ms to save the state.
100uF (a couple of 1206 X5R 100uF ceramics considering derating) should be enough considering the 75mA total current draw of the circuit (3.3V).

[Ian.M]

Its much more effective to add capacitance before the regulator.   Assuming your regulator will work down to 25V (I'm guessing its a switching regulator as dissipating 3.8W in a linear regulator would need heatsinking), and starting from 10% low input voltage, so 48.6V,  there's 868 Joules per Farad between those two voltages (from E=C*V²/2)   You need 75mA, @3.3V, which if the regulator is 80% efficient is 0.31W input power.   To hold the 3.3V rail up for 1 second only needs 356uF, or 0.356uF for 1ms. 

If you are using a linear regulator the maths is easier.   Assuming it drops out at 8.6V, the input can fall 40V.  From Q=CV, allowing 5mA quiescent current for the regulator and 75mA load current,  it would tahe 2000uF to hold it up for 1 second, or 2uF for 1ms

The tradeoff is the higher voltage caps required are larger and usually more expensive than low voltage ones.  OTOH the 3.3V rail is maintained in spec. for the holdup time.

 

[Axk]

@Ian.M, thanks!
I didn't think in terms of the regulator giving a lot of margin to how far a capacitor on the high side can discharge before the low side starts sinking.
I though I would need an electrolytic on the high side, and I want the board to be low profile.
So as you point out considering the margin I can use a couple of 100V chip ceramics instead.

I'm planning to use a linear reg with an external TO-220 NPN with the whole board attached to a somewhat longer 2mm aluminum sheet and the transistor screwed to the sheet where it sticks out to keep it level with the board.
I could use a switching converter but I want to keep things simple.

[Axk]

How do I determine if my PMOS switch can withstand the current surge needed to charge the 10-20uF of capacitance?
The maximum instantaneous current is specified at 3A?
Can it withstand more to charge the caps or should I use a current limiting circuit?
I 20 ohm resistor in series with the capacitors?

[Ian.M]

Choose a gate resistor to limit the PMOS turnon speed so the capacitor charging current doesn't exceed Id_peak.  Some experimentation may be required with a current probe and a DSO,