Spartan 3 chips in power up

IIRC, the I/O's are inputs (or HiZ) w/ soft pullup until after configuration.

It should be simple enough to delay the start of configuration until after the last supply is up.

I assume that you are looking at Table 28 on page 54 in the Spartan-3 data sheet.

These are essentially the trip points for the power-on reset (POR) circuit inside the FPGA. The trip voltage range is somewhat wide due to process variation, etc.

The POR circuit prevents configuration from starting until all three power rails meet are within the trip-point range. The POR can happen as early as the minimum voltage levels or as late as the maximum limits.

Until the POR is released, all I/Os not actively involved in configuration are high-impedance. The HSWAP_EN pin controls whether or not internal pull-ups are applied to these I/Os. When HSWAP_EN = High, the I/Os are turned off. Also, the pull-ups connect to their associated power rail so you won't see the effect until VCCO ramps up.

--------------------------------- Steven K. Knapp Applications Manager, Xilinx Inc. General Products Division Spartan-3/-3E FPGAs

--------------------------------- The Spartan(tm)-3 Generation: The World's Lowest-Cost FPGAs.

Thanks for the info. Yes, I was looking at that table, plus table 30 on the next page. I am concerned about letting the DSP run before the FPGA power is fully up and also operating the DSP while the FPGA power has a momentary glitch for what ever reason. The DSP has a separate core voltage from the FPGA and shares the Vcco of 3.3 volts. The FPGA is configured and operated on the DSP external memory bus which also connects to the program/data flash memory. I just want to make sure I can defend my power up and power glitch operation of the board. When the board is powering up, it is clear that the FPGA is held in reset until the three power rails are somewhere within the trip ranges or above. Then the DSP can hold the PROG_B signal low to continue holding the FPGA in reset until the DSP is happy with the power supplies and is ready to configure the FPGA without concern that the FPGA will mess up the memory bus. That part seems clear.

But table 30 on page 55 seems to be saying that if Vccint or Vccaux dip below the minimum values, but still above the reset trip points, the configuration can be corrupted and the FPGA will not be put in reset. In this case should I assume that the IOs can then be in any state and may hang the DSP memory bus? If so, I need to use the PowerOK on the LDO regulators to either halt the DSP or make sure it gets an NMI and runs only from internal memory. I would prefer to be able to keep the DSP running normally and record the power event in memory. I have some concerns about the system power supply design and would like to be able to show clear evidence that the power is not stable rather than having to extrapolate from processor resets.

Most digital suppliers will only commit to monotonic power supplies. [and even then, sometimes some pretty tight dV/dT - IIRC, see the MAX II ? ]

If you have brownout dips, you are pretty much on your own....

Well, if you are really worried about the system power, you will need all the belts and braces at your disposal - even run to a separate small uC, whose sole job is power integrity and logging ?

-jg

Steve-

Except for the S3 errata about "if HSWAP_EN input is high, pull-up resistors are momentarily enabled on User-I/O at end of Configuration" which I believe only hints at the magnitude of the problem we saw on Spartan 3s in mid-2005. On one board with ACQ revision XC3S1500-676, the I/O pins are forced high enough to produce a 1.5V output on lines with 1k pull-down resistors, and this condition lasted more than 100 msec prior to DONE assertion.

On boards with revision ECQ and later parts, we don't have the problem so it looks like it has definitely been fixed.

But this brings up a question we've had about S3s for a long time: what is the actual pull-up R value? I had heard from our local FAE that the pull-ups are not true Rs, but a "pseudo-transistor" method is used.

Thanks.

-Jeff

Steve-

Sorry, I got corrected here... those revisions should be AFQ (exhibits pre-DONE outputs) and EGQ (no pre-DONE outputs).

-Jeff

There is nothing "pseudo" about the pull-up transistor that functions as a pull-up resistor. Almost all so-called resistors on modern CMOS chips are really transistors (p-channel for pull-up), with their geometries chosen appropriately for the desired impedance (or resistance if you will). On-chip resistors are extremely unpopular... Peter Alfke

Spartan-3 pull-up and pull-down resistors are much stronger than in previous FPGA families. In previous families, they were on the order of 20-50k ohms.

... it appears that the "pull-ups active during end of configuration" issue was fixed on parts marked with either "AGQ" or "EGQ". In other words, essentially anything built with the "GQ" process/fab code. The errata also has diagrams indicating how to determine which device you have. The "EGQ" is the current silicon. Table 3 in the errata notice describes which issues were in the early and later silicon revisions.

The equivalent resistance is actually specified in the data sheet. See Table 32 on page 56 in specific.

The actual measurement is a current, which equates to a resistance. The "resistor" is as Peter described in ...

For example, the equivalent pull-up "resistor" when powering a bank for

3.3V, is between 1.27k and 4.11k ohms. The equivalent pull-down "resistor" is between 1.75k and 9.35k ohms.

--------------------------------- Steven K. Knapp Applications Manager, Xilinx Inc. General Products Division Spartan-3/-3E FPGAs

--------------------------------- The Spartan(tm)-3 Generation: The World's Lowest-Cost FPGAs.

Steve-

Thanks very much for the detailed explanation. I did not realize S3 has that much variation in pull-up/pull-down values, and the min values could be under 2k. That does explain some of the things we've seen. We had got this idea in our heads of "weak pull-ups" from our Spartan II boards...

I wish S3 Rs were a uniform 10k or so, but it sounds like it's not easy as the process continues to shrink. Is this what we can expect on newer devices also? It seems if we used a lot of internal FPGA pull-ups/downs instead of external ones we could significantly increase power consumption and heat of the device.

-Jeff

The Spartan3Es are back to the pre-Spartan3 weak pullups. The values are superbly easy to find in the DC and Switching Characteristics data sheet.

The Spartan-3 resistor values turned out a bit stronger than originally expected during design. The Spartan-3E resistors values are weaker, but still strong enough to be useful. Early FPGA families has resistors up around 20K to 50K, too weak to be useful.

--------------------------------- Steven K. Knapp Applications Manager, Xilinx Inc. General Products Division Spartan-3/-3E FPGAs

--------------------------------- The Spartan(tm)-3 Generation: The World's Lowest-Cost FPGAs.

Thanks for the info. I don't understand why you say a 50K PU is too weak to be useful. That is more the range that I expect from an internal PU. I am working the Spartan 3 configuration sequence and have been getting a lot of coments from one person in particular about my pull up/down resistors being too weak. He has made a lot of unsubstantiated claims about a previous design not working until various PU/PD resistors being replaced with 0 ohm jumpers. I see now that there may be some truth to this.

I have been searching the data sheet for all info on internal PU/PD and it is not easy to find. It is rather scattered about and takes a lot of searching. At first I didn't think any of the configuration pins had PUs, but I saw the notation in Table 6 that the values of resistance applied to User I/Os, Dual Purpose and Dedicated pins. So I searched the document for pull-up and eventually found them all... I think.

Here is what I think I have found...

HSWAP_EN - PU

PROG_B - PU during configuration, PU optional based on ProgPin config option

DONE - bit stream configurable for open drain or totem-pole, optional PU in User mode or external PU required

M0,M1,M2 - I am very confused about this one. Here is what it says in the detailed pin description... "In user mode, after configuration successfully completes, any levels applied to these input are ignored. Each of the bitstream generator options M0Pin, M1Pin, and M2Pin determines whether a pull-up resistor, pull-down resistor, or no resistor is present on its respective mode pin, M0, M1, or M2."

The mode pins have to be held in the appropriate state before any of the bit stream can be loaded. So external PU/PDs are required. Further the pins are ignored except for the rising edge of INIT_B. Then what purpose does it serve to provide PU or PD after configuration?

I am a bit confused about the setting of the Mode pins. There appears to be a mode for JTAG configuration and in one place it says the JTAG port can not be used until the INIT_B pins rises. But in another place the data sheet says "The JTAG port is always active and available before, during, and after FPGA configuration." If this is true, do the Mode pins need to be set to 101 to configure the part using JTAG? I suppose it could be that the JTAG port is available for other things like boundary scan, but not configuration unless the correct setting is applied to the Mode pins. Do I need to provide for different settings for JTAG configuration and Slave Parallel configuration? That would be two resistors I need to change...

I don't know whether to feel stupid or to feel Xilinx is stupid. I found an answer record that answers the part about the Mode pins having pullups. I could not find anywhere in the data sheet about the mode pins having pullups. But the answer record says the Mode pins are all pulled up to 2.5 volts by the equivalent of a 1.15 kohm resistor, worst case. This means you need no larger than about 470 ohms for your pull downs!!!

Does the data sheet say these pins are pulled up and I missed it? I actually did a search on "pull-up" (which is how Xilinx seems to term them) and did not find any mention of a pullups on the mode pins. The pin definition, where this info certainly should be, makes no mention of this. I think Xilinx really dropped the ball on this one!

Rick-

If it's any consolation, we went through S3 pull-up/pull-down hell last summer. We ended up putting a few additional values on the board that we thought the S3 should have been able to handle internally. We also found significant variation between S3 devices.

We also found issues with multi-FPGA configuration from platform Flash vs. temperature that required some undocumented FPGA-related board mods that my company won't disclose, as it took us nearly 6 weeks to get it nailed down.

But with that said, I have to add the S3 is otherwise an outstanding device. Everything we want to do so far in logic we've been able to find the way. We even ported a chunk of TI/Telogy code they were using on Altera Flex devices (on a yr 2002 reference design), and with minor mods it runs perfectly. TI/Telogy guys, who normally stick to Altera like glue, seem to be impressed.

-Jeff

Thanks for the info, but your troubles are never consolation for mine. Considering that the Spartan 3 pullups are so stiff, I find it negligent that Xilinx would not document the fact that they put them on the mode pins. Unless you typically use *very* stiff resistors or just plain use 0 ohm jumpers for pulldowns, the mode pins will not work. Xilinx knows this and still has not put it in the data sheet that I can find. I just downloaded the data sheet and it was just updated this month. The answer record that describes the pulldown problem is over a year old! Don't you think a year is enough time to get the facts straight in a data sheet, especially on such a basic and important issue???