Spartan 3 chips in power up
rickman
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.
ghe...@lycos.com
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.
Steve Knapp (Xilinx Spartan-3 Generation FPGAs)
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.
rickman
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.
Jim Granville
>
> 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
Jeff Brower
> 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
Jeff Brower
Sorry, I got corrected here... those revisions should be AFQ (exhibits
pre-DONE outputs) and EGQ (no pre-DONE outputs).
-Jeff
Peter Alfke
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
Steve Knapp (Xilinx Spartan-3 Generation FPGAs)
> 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.
Jeff Brower
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
John_H
superbly easy to find in the DC and Switching Characteristics data sheet.
"Jeff Brower" <jbr...@signalogic.com> wrote in message
news:1145371209.2...@z34g2000cwc.googlegroups.com...
Steve Knapp (Xilinx Spartan-3 Generation FPGAs)
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.
rickman
> 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.
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...
rickman
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!
Jeff Brower
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
rickman
> 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.
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???