Spartan 3 chips in power up

I have looked at the data sheet and they say very clearly that the
Spartan 3 is held in reset until all three power supplies are fully up.
 But the range of voltages is very wide, with reset being released when
the Vcoo on Bank four is as low as 0.4 volts.

I get a lot of grief from the FPGA firmware designers on every little
nit and pic that they don't like about the board design.  I need to
know that this will keep the FPGA in reset and all IOs tristated
whether the various power voltages are above or below the internal
reset threshold, up to the point of being configured.

rickman wrote:
> I have looked at the data sheet and they say very clearly that the
> Spartan 3 is held in reset until all three power supplies are fully up.
>  But the range of voltages is very wide, with reset being released when
> the Vcoo on Bank four is as low as 0.4 volts.
>
> I get a lot of grief from the FPGA firmware designers on every little
> nit and pic that they don't like about the board design.  I need to
> know that this will keep the FPGA in reset and all IOs tristated
> whether the various power voltages are above or below the internal
> reset threshold, up to the point of being configured.

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.

rickman wrote:
> I have looked at the data sheet and they say very clearly that the
> Spartan 3 is held in reset until all three power supplies are fully up.
>  But the range of voltages is very wide, with reset being released when
> the Vcoo on Bank four is as low as 0.4 volts.
>
> I get a lot of grief from the FPGA firmware designers on every little
> nit and pic that they don't like about the board design.  I need to
> know that this will keep the FPGA in reset and all IOs tristated
> whether the various power voltages are above or below the internal
> reset threshold, up to the point of being configured.

I assume that you are looking at Table 28 on page 54 in the Spartan-3
data sheet.
http://www.xilinx.com/bvdocs/publications/ds099.pdf

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
http://www.xilinx.com/spartan3e
---------------------------------
The Spartan(tm)-3 Generation:  The World's Lowest-Cost FPGAs.

Steve Knapp (Xilinx Spartan-3 Generation FPGAs) wrote:
> rickman wrote:
> > I have looked at the data sheet and they say very clearly that the
> > Spartan 3 is held in reset until all three power supplies are fully up.
> >  But the range of voltages is very wide, with reset being released when
> > the Vcoo on Bank four is as low as 0.4 volts.
> >
> > I get a lot of grief from the FPGA firmware designers on every little
> > nit and pic that they don't like about the board design.  I need to
> > know that this will keep the FPGA in reset and all IOs tristated
> > whether the various power voltages are above or below the internal
> > reset threshold, up to the point of being configured.
>
> I assume that you are looking at Table 28 on page 54 in the Spartan-3
> data sheet.
> http://www.xilinx.com/bvdocs/publications/ds099.pdf
>
> 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.

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.

rickman wrote:
> 
> 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.

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....

> 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.

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-

> 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.

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

Jeff Brower wrote:
> Steve-
>
> > 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.
>
> 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.

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.

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

>From the XC3S1500 errata notice ...
http://www.xilinx.com/xlnx/xweb/xil_publications_display.jsp?category=-1210888

... 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.

> 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.

The equivalent resistance is actually specified in the data sheet.  See
Table 32 on page 56 in specific.
http://www.xilinx.com/bvdocs/publications/ds099.pdf

The actual measurement is a current, which equates to a resistance.
The "resistor" is as Peter described in ...
http://groups.google.com/group/comp.arch.fpga/tree/browse_frm/thread/b8a43f2bf79e9491/97ca8a520cfd0b3b?rnum=1&hl=en&_done=%2Fgroup%2Fcomp.arch.fpga%2Fbrowse_frm%2Fthread%2Fb8a43f2bf79e9491%2F6d8f92cbcdcf403f%3Flnk%3Draot%26hl%3Den%26#doc_422b86b865e6c456

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
http://www.xilinx.com/spartan3e
---------------------------------
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