10
\$\begingroup\$

I am trying to get a general understanding on what happens if you leave an FPGA unprogrammed for a long duration of time.

Suppose you have an FPGA and you leave it unprogrammed for a long period of time (several minutes to hours after power-on), i.e. no bitstream on it, is this bad for the device? Is it recommended to have some bitstream on a powered-on FPGA at all times? What is the general opinion regarding this?

Are the results different on different devices or manufacturers (Xilinx vs. Altera vs. others)?


Additional Info:

I have a custom SoC board which uses a Xilinx Virtex-6 FPGA. I also have a Xilinx ML605 which I use for reference purposes.

Custom board: I power-on the board. I notice that I get a short duration of time to program it using XMD (Xilinx Microprocessor Debugger). If I lose the 20-30 sec window, I have to switch off and switch on the board before trying again. This does not happen with an ML605.

When I try to program the custom board over XMD, I get something like:

Error: Device Reset by JPROGRAM command, failed. INIT_COMPLETE did not go high.

Let me know what you think.

\$\endgroup\$
  • 1
    \$\begingroup\$ You emphasize in your question and in your edit the "long period of time". Does it really matter if it's a few seconds or a few hours? I don't think it does.. \$\endgroup\$ – m.Alin Jun 22 '12 at 14:27
  • \$\begingroup\$ I am seeing a phenomenon on a custom FPGA board where I get a 20-30 sec programming window. If I do not program in this window, I cant program successfully. The central theme of my question is not the time duration but to get an understanding of the phenomenon. \$\endgroup\$ – boffin Jun 22 '12 at 14:35
  • \$\begingroup\$ Are you able to connect to the device at all? Or does it just fail when you try to program? What is the error the programmer is giving? \$\endgroup\$ – embedded.kyle Jun 22 '12 at 15:22
  • 1
    \$\begingroup\$ Are you programming the FPGA via JTAG directly, or are you loading the Flash chip first and then letting the FPGA configure through that? \$\endgroup\$ – ajs410 Jun 22 '12 at 15:44
  • \$\begingroup\$ @fpga_boffin, could you add those details to your question please? \$\endgroup\$ – Jon L Jun 22 '12 at 17:39
7
\$\begingroup\$

This is an interesting question. From personal experience, I have left FPGAs powered up for hours in an unprogrammed state while performing checks on the rest of the circuitry when a new board comes in from the assembly house. I have not noticed any detrimental effects from doing so. But I've honestly never thought about it.

I looked around to try and find a recommendation from an FPGA manufacturer but could not find one. The only statement I found regarding this state is from a Lattice whitepaper and regards the design of the FPGA itself and not how it should be used:

Pre-Programmed Static Quiescent Device Power Consumption is the amount of power consumed by the FPGA prior to the device being programmed. For quiescent device power consumption the FPGA is in a non-programmed state, yet has been powered. It is important that the device not consume significant power during this time, as conceptually the FPGA device could draw excessive power and potentially shut down power supplies, preventing the board from successfully initializing itself and the system.
The FPGA supplier therefore has to carefully design transistors that have a low static 3 Designing for Low Power A Lattice Semiconductor White Paper power footprint, without compromising in areas where higher performance is required (e.g. I/O and SERDES)

Xilinx likewise mentions what the quiescent current is so that you can design your power supply accordingly. But does not mention what the effect on the device is of leaving it in such a state:

Static or quiescent power is mainly dominated by transistor leakage current. When this current is listed in data sheets, it is listed as ICCINTQ and is the current drawn through the VCCINT supply powering the FPGA core.

I would be very interested to hear if anyone has experienced damage to a device from leaving it in a quiescent state. But I think as long as the power supply is properly matched to the device, there should be no problem.

| improve this answer | |
\$\endgroup\$
6
\$\begingroup\$

I am referencing the Spartan 3 datasheet, since that's the FPGA I'm most familiar with.

If you look at chapter 2 (Functional Description), the section "Configuration" has a couple flow diagrams. Figure 27 (page 50) shows the flow diagram for loading from Flash. Figure 28 shows the JTAG flow diagram.

Here's a brief summary.

1) Wait for Vccint, Vccaux, and Vcco to reach required levels.

2) Clear Configuration latches

3) Wait for INIT_B to go high. INIT_B is an open-drain output that an external master can hold low in order to delay configuration.

4) Sample Mode pins. This determines whether you're going to load via JTAG or Flash, and if Flash whether the FPGA or the Flash is the Master.

5) Load Configuration data frames.

6) Verify that the CRC for the data frames is correct. If it is NOT correct, the FPGA will drive INIT_B low to indicate a CRC error and it will abort startup.

Step 5 is probably where your real question is - what happens if there is nothing to load from? Well, you shouldn't get to Step 5 if you're doing things right. The Flash chip will hold INIT_B low until it's ready to serve data to the FPGA. If you're using JTAG, then I'm not sure whether your JTAG programmer would hold INIT_B low, but when it went to program the FPGA it would almost certainly assert PROG_B (by driving it low), which causes the FPGA to go back to step 2.

If I were you, I'd scope the INIT_B signal during power-on to see what's happening. If it starts low, goes high, and then goes low again, the FPGA aborted the startup sequence and you will probably need to assert PROG_B in order to reset the FPGA.

| improve this answer | |
\$\endgroup\$
  • \$\begingroup\$ Your answer says nothing about the internal state of the FPGA before step 5, which is what OP wants to know. \$\endgroup\$ – stevenvh Jun 22 '12 at 16:06
  • \$\begingroup\$ Step 2. Clear Configuration Latches. Step 3, waiting for INIT_B. I also discuss what kind of decision the FPGA may be making whenever it finds there is no configuration data to load (INIT_B going low to indicate a CRC error). \$\endgroup\$ – ajs410 Jun 22 '12 at 17:24
  • 1
    \$\begingroup\$ My apologies, the datasheet I was referencing was circa 2005, and it was updated in 2009. However, had you actually read my comment thoroughly, you would have been able to find it. Chapter 2, Functional Description, under the Configuration heading. The link has been updated to point to the latest datasheet, as well as the new page numbers. \$\endgroup\$ – ajs410 Jun 22 '12 at 17:40
0
\$\begingroup\$

The default configuration is designed to be as passive as possible in order to make the device universally usable.

For the Altera Cyclone series (which I have the most experience with) this means

  • the I/O pins are weakly pulled up to VCCIO (to keep ICs with active-low chip enable lines off the bus),
  • the CONF_DONE output is pulled low (you can connect this to the reset pin of other ICs to keep them in reset until a configuration has been loaded as well as restore them to known state when reconfiguring), and
  • the clock inputs are not forwarded to the clock networks.

Other FPGA types should be similarly quiescent, and provide non-inverted and inverted outputs indicating configuration status to the rest of the board.

Leaving the device in that state is harmless, as the core is fairly isolated from the outside world, and only the pull-ups may have a small current across them.

| improve this answer | |
\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.