Virtex-II Pro slave serial configuration problem....

[John Providenza]

So I thought, "how hard can it be to download to a V2P7 part using the slave
serial mode?"

Well, pretty hard.

I have a 'master' FPGA that loads a 'slave' FPGA using the slave serial
programming mode. The download process will work over and over, then
suddenly decide not to work. Then it doesn't work for a long
time. Very flakey.

The master FPGA drives PGM_N, CCLK, and DIN to the slave using
2.5V CMOS outputs. The signals all look clean, no over/undershoot,
no glitches in the transition region, etc. The data setup/hold is
over 100ns, the data is setup before the rising edge of CCLK and
is held until after the falling edge. By default, the clock is
held low and pulses high for about 70ns when new data is ready for
the slave.

The master FPGA has very simple logic that interfaces to a PC. The PC can
assert the PGM_N signal and can look at the status of INIT_N and DONE to
monitor programmng status. The PC can also write a 32 bit word into
the master which then serializes the data to the DIN and CCLK pins on
the slave.

Things to note:
1) The download is flakey, but since it can succeed multiple times
in a row, I'm pretty sure that the bit order of data being shifted
into the slave FPGA is correct.
2) I've added logic to grab the output data using the output CCLK clock
so the PC can verify that the data has not been corrupted. It always
reads back correctly.
3) I've turned the 'debug' flag on in bitgen so I can look at the
DOUT pin. When things work, I get lots of pulses out of DOUT,
when download fails, DOUT will either pulse low once or pulse
low multiple times, but stop pulsing before the download completes.
4) Occasionally, INIT_N is asserted by the FPGA before the download is done.
5) The data loads to the slave in bursts of 32 bits, ie, the PC sends
a 32 bit word, the master serializes it, then everything waits while
the PC realises it's done and loads the next word. It's about
150 usec between 'bursts'.

3 & 4 lead me to believe the slave FPGA is receiving corrupted data or
a bad clock occasionally, BUT... the signals look fine.

We have M[2:0] and HSWAP_EN pulled to 2.5V using 10K resistors. PWRDWN_N
is floating as is VBATT. The JTAG signal are also pulled to static levels.

It almost acts like there's a floating pin - if it's in one state everything
is fine, if it drifts or comes up in the 'wrong' state, the download fails.

Has anyone run into problems like this? My local FAE is stumped as am I.

Thanks for any insights!

John Providenza

 

[John Providenza]

I solved the problem - we got a very bad batch of circuit boards,
each one has a different set of etch problems...

Although the main power supplies on the board are OK, they actually
make good connectivity to a random number of power pads on the FPGA.
Each board has a different set of 'good' connections between the
power supply and the FPGA.

We're going to scrap the entire batch of *assembled* boards. What
a pisser.

John P



johnp3+nospam@probo.com (John Providenza) wrote in message news:<349ef8f4.0406031111.40c5fad7@posting.google.com>...

So I thought, "how hard can it be to download to a V2P7 part using the slave
serial mode?"

Well, pretty hard.

I have a 'master' FPGA that loads a 'slave' FPGA using the slave serial
programming mode. The download process will work over and over, then
suddenly decide not to work. Then it doesn't work for a long
time. Very flakey.

The master FPGA drives PGM_N, CCLK, and DIN to the slave using
2.5V CMOS outputs. The signals all look clean, no over/undershoot,
no glitches in the transition region, etc. The data setup/hold is
over 100ns, the data is setup before the rising edge of CCLK and
is held until after the falling edge. By default, the clock is
held low and pulses high for about 70ns when new data is ready for
the slave.

The master FPGA has very simple logic that interfaces to a PC. The PC can
assert the PGM_N signal and can look at the status of INIT_N and DONE to
monitor programmng status. The PC can also write a 32 bit word into
the master which then serializes the data to the DIN and CCLK pins on
the slave.

Things to note:
1) The download is flakey, but since it can succeed multiple times
in a row, I'm pretty sure that the bit order of data being shifted
into the slave FPGA is correct.
2) I've added logic to grab the output data using the output CCLK clock
so the PC can verify that the data has not been corrupted. It always
reads back correctly.
3) I've turned the 'debug' flag on in bitgen so I can look at the
DOUT pin. When things work, I get lots of pulses out of DOUT,
when download fails, DOUT will either pulse low once or pulse
low multiple times, but stop pulsing before the download completes.
4) Occasionally, INIT_N is asserted by the FPGA before the download is done.
5) The data loads to the slave in bursts of 32 bits, ie, the PC sends
a 32 bit word, the master serializes it, then everything waits while
the PC realises it's done and loads the next word. It's about
150 usec between 'bursts'.

3 & 4 lead me to believe the slave FPGA is receiving corrupted data or
a bad clock occasionally, BUT... the signals look fine.

We have M[2:0] and HSWAP_EN pulled to 2.5V using 10K resistors. PWRDWN_N
is floating as is VBATT. The JTAG signal are also pulled to static levels.

It almost acts like there's a floating pin - if it's in one state everything
is fine, if it drifts or comes up in the 'wrong' state, the download fails.

Has anyone run into problems like this? My local FAE is stumped as am I.

Thanks for any insights!

John Providenza

 

[Hal Murray]

Although the main power supplies on the board are OK, they actually
make good connectivity to a random number of power pads on the FPGA.
Each board has a different set of 'good' connections between the
power supply and the FPGA.

Ugh. That's probably the worst sort of problem to have to track down.

Any hints on how you found it? (just in case any of us are unlucky
enough to encounter the same problem)

--
The suespammers.org mail server is located in California. So are all my
other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's. I hate spam.

 

[John Providenza]

hmurray@suespammers.org (Hal Murray) wrote in message news:<P5WdnZUv-YS0iFTdRVn-sA@megapath.net>...

Although the main power supplies on the board are OK, they actually
make good connectivity to a random number of power pads on the FPGA.
Each board has a different set of 'good' connections between the
power supply and the FPGA.

Ugh. That's probably the worst sort of problem to have to track down.

Any hints on how you found it? (just in case any of us are unlucky
enough to encounter the same problem)

It took a lot of effort to find the problem. As it turns out,
the problem stumped our local FAE as well, and he's a pretty
sharp guy. Since the boards were flakey, almost any experiment
we performed was later invalidated by conflicting results from
another experiment. However...
1) I turned on the 'debug' flag in bitgen so that the data
output pin would wiggle during configuration. From this
it was clear that the download would fail at random points
in the download process.

2) I looked at signal quality of the clock and data input pin
to the target FPGA. As part of this, I re-clocked the
data being sent to the target back into my master so I could
verify that the proper data was being sent. Here was one of
the areas that snookered me. As part of these experiments,
I played around with slew rates on the pins being driven by the
master FPGA, sometimes things would get better, sometimes they'd
get worse. This led us down a signal integrity rat-hole.

3) I finally decided to re-verify suppy voltages at a couple of spots.
Luckily, I found unexpected voltages on a couple of bypass caps
pretty quickly. I then checked other boards and found different
voltage problems on other pins. This was the 'aha' moment.

During the process, I was trying to focus on:
a) bitstream correctness
b) signal integrity
c) supply voltage integrity.

Little did I suspect that the problem was random connectivity between
the supplies and the FPGA pins.

In all my years of design, I've never seen board problems like this. Odds
are most designers will never see boards that deteriorate over time like
this.