Re: XC3000 non-recoverable lockup problem

On 30 Mar 2005 06:29:36 -0800, "lecroy7200@chek.com" <lecroy7200@chek.com> wrote:
>> Well, I have read all of your posts, and everyone elses too.
>> The problem is one of clarity of communications.
>
>Good that you know that everyone read them all.  I for sure could not
>make that statement.

Well, this is still a clarity issue. I wrote "elses" but should have
probably written "else's", as in "I have read the articles by everybody
else".

You read "elses" and assumed I meant "else has" which is a contraction
I have never heard of :-)

Philip
Philip Freidin
Fliptronics

One of the things that has been bothering me through all of this is your
detecting of a 16 MHz clock. The configuration clock for these devices is
nominally 1 MHz, but actually it can range from 500 KHz to 2 Mhz. I am
certain that it does not use a faster clock and then divide it down. So I
have been beating my head about what this 16 MHz is. Well, I just figured
it out.

The baseline family is XC3000

The XC3100  family was a higher performance family

The XC3000A family had some routing enhancements which made use of some
            previously dummy bits in the config bitstream.

The XC3100A has both the higher performance of the XC3100 family, and
            the routing enhancements of the XC3000A

The XC3000L is a low power derivative of the XC3000A

(FYI, all bitstreams are the same length. Designs compiled for the XC3000
or XC3100, can be used with any of the 4 families. Designs compiled for
the XC3000A or XC3100A, may make use of the dummy bit, and so these
bitstreams can not be used in the XC3000 or XC3100 devices).

The performance enhancement in the XC3100/3100A family is achieved by the
use of on chip charge pumps. These create higher voltages that are used
on selected circuits in the FPGA. These charge pumps use free running
oscillators that are separate from the config oscillator, and are almost
certainly the 16 MHz that you are seeing. There is no way to actually
measure these oscillators, other than what you are doing with the spectrum
analyzer.

Since you are seeing that the 16 MHz is not present in devices that are
not operational, this means that the charge pumps are not all running.
Under this situation, I would expect that the chips would be basically
non operational, and no amount of banging on reset, D/P, or other control
pins is going to help. This is what you have reported.

I don't remember if the problem you are seeing is that devices that
operational, stop operating, without turning the system off, or that
when a system is turned on, sometimes it does not start up correctly.
(Have you ever said this?)

At this point it would seem that either the profile of the powerup
voltages, transients on the power lines while operational, or maybe
negative transients on data lines.

As an example, I have seen DRAMs fail due to excessive undershoot on
a data line, that violates the devices max negative spec. This is
a failure mode different from the well known problem of latchup. I.E.
the device fails, but does not exhibit the high power consumption
associated with latch up.


Philip Freidin





===================
Philip Freidin
philip.freidin@fpga-faq.org
Host for WWW.FPGA-FAQ.ORG

Philip,

> The performance enhancement in the XC3100/3100A family is achieved by
the
> use of on chip charge pumps. ... These charge pumps use free running
> oscillators that are separate from the config oscillator, and are
almost
> certainly the 16 MHz that you are seeing.

Thanks for all your insight!!  I was a bit surprized that the "smartest
and most helpful engineers" at Xilinx did not pick up on the charge
pump right away.

As per our off-line talks, I have gone ahead and rebuilt the design
using slew limited outputs for the two pins in question.  I have begun
running my transient tests but it will be a few weeks before I am
convinced this was the problem.

The following link is to my post about the reflected energy causing
possible problems:

http://groups-beta.google.com/group/comp.arch.fpga/browse_frm/thread/1423e577bf37d509/1f921b2ef9ae4542?q=reflected&rnum=3#1f921b2ef9ae4542

The following was taken from a Xilinx app. note.

"For all FPGA families, ringing signals are not a cause for reliability
concerns. To cause such a problem, the Absolution Maximum DC conditions
need to be violated for a considerable amount of time (seconds). "

I am including parts of our off-line talks that may be a benifit to
others reading this thread.



>So, I drug out the trusty scope to start probing around.  Made a nice
ground plane around the device for a reference.  Ground plane is
attached to devices ground in multiple places.  The scope is a LeCroy
7300.  3GHz BW with a sample rate of 20GS/S.  Using a 3.5GHz active
probe with a loop of about 0.5".  All measurements are taken at the
FPGA's pins.  Using no filtering, etc.  If there is a glitch, I will
find it.

>The outputs are not terminated (except by the next device) and there
is some undershoot from the reflection.  This undershoot can be more
than 0.5 Volts below the rail.  On their newer parts I had seen where
they started to specifiy the SWR of the next stage, but I was not able
to obtain this document.    You may recall me posting this lenghtly
post last summer.    I have never seen a problem where, say all of the
energy was reflected back to the device's output and have it cause a
problem.  Maybe the 3100A was prone to having problems with this.
>
>Any idea?

Well anything that goes more than .5V below ground would concern me,
even
very short duration. I don't think the 3100A was particularly prone to
this.

While normally you worry about undershoot and overshoot at a receiver,
in the case of FPGAs, all pins are both. So even if you are usin a pin
only as an output, it still has an input structure including the
protection diodes. The undershoot can cause the diode to conduct, and
this can in turn upset the local ground reference inside the FPGA. This
may be your fault mode. Note that this type of thing can have data
pattern sensitivity. I.E. a bunch of outputs all switching low at the
same time, maybe on pins that are further away from the ground pins
rather than nearer, with reflections arriving at about the same time,
etc.

Two suggestions: can you force the data outputs to bang between paterns
that are predominantly all '1's and then '0's? Other idea, set up a low
impedance pulse generator to generate say a 1 uS pulse of -1V, and
apply it to some pins (1 at a time) and see if this induces the
problem.

lecroy7200@chek.com wrote:
<snip>
> As per our off-line talks, I have gone ahead and rebuilt the design
> using slew limited outputs for the two pins in question.  I have begun
> running my transient tests but it will be a few weeks before I am
> convinced this was the problem.
> 
> The following link is to my post about the reflected energy causing
> possible problems:
> 
> http://groups-beta.google.com/group/comp.arch.fpga/browse_frm/thread/1423e577bf37d509/1f921b2ef9ae4542?q=reflected&rnum=3#1f921b2ef9ae4542
> 
> The following was taken from a Xilinx app. note.
> 
> "For all FPGA families, ringing signals are not a cause for reliability
> concerns. To cause such a problem, the Absolution Maximum DC conditions
> need to be violated for a considerable amount of time (seconds). "
<snip>
That's from a Pin-failure viewpoint. - ie energy damage.
They also spec a MAX peak current.

There IS another failure mode, which is the lateral currents that result 
from the clamp diodes ( which are actually side-ways transistors ).
It is not easy to KNOW what peak currents you get, especially on cable 
or external runs.

At the highest levels, these injection currents cause latch-up, but 
there can be lower levels, where operation is compromised, but the
device does not latch up.

Latchup tests are purely "did the SCR trigger?" ones, they do NOT 
(AFAIK) ever check to see if the part logically miss-fired in any way.

-jg

Jim Granville wrote:
> lecroy7200@chek.com wrote:
> <snip>

> >
> > The following link is to my post about the reflected energy causing
> > possible problems:
> >
> That's from a Pin-failure viewpoint. - ie energy damage.
> They also spec a MAX peak current.
> -jg

Yes, I think that's what I had stated.

Peter's original app note on the subject.
http://klabs.org/richcontent/fpga_content/DesignNotes/signal_quality/xapp096.pdf

So far no problems with my testing.  If this solves the problem it
would be interesting to know if there was some reason that the 3100A's
internal doublers were prone to failure because of this.

I have come to the conclusion that it is possible that the actual core
design can effect the internal charge pump circuits.  After weeks of
testing a core that was  auto generated, I have been unable to
reproduce the problem.  Setting the outputs to FAST or slow appears to
have no effect on the failure.  Talking with Philip, it does not appear
that the device had any capabilities to turn off the charge pumps.

I did go back to the original core and made sure I could reproduce the
failure once more.

I also came across this old note from Xilinx:

"Note that XC3100L and XC5200L use a continuously running
internal oscillator to generate an elevated voltage for driving
the pass-transistor gates , This is called "pumped gates" and
gives better speed, but results in significantly elevated idle
( quiescent ) current consumption, bad for battery-operated
systems. XC3100 devices have always used this technique, while
the original XC5200 devices did not, but the coming releases
will."

It appears some of the newer parts also used internal charge pumps.
Would be interesting to know if they would be prone to the same
problem.

All of

The more recent FPGAs use the Vccaux supply through a regulator to 
supply Vgg, or the pass gate voltage supply.

There are no charge pumps in FPGAs now since Virtex (roughly 7.5 years).

Austin

> There are no charge pumps in FPGAs now since Virtex (roughly 7.5
years).

Just doing a quick search I find the Coolrunner is using a charge pump
for the programming voltage. Just search the data sheet for "charge"
and you will find it.

Coolrunner is a CPLD.

Austin

lecroy7200@chek.com wrote:
>>There are no charge pumps in FPGAs now since Virtex (roughly 7.5
> 
> years).
> 
> Just doing a quick search I find the Coolrunner is using a charge pump
> for the programming voltage. Just search the data sheet for "charge"
> and you will find it.
> 

You are correct!

Now that your posting again, why did you feel the need to change the
subject line?