1. Home
  2. Field-Programmable Gate Arrays
  3. Virtex-II Pro slave serial configuration problem....

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

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

Reply to
John Providenza
Loading thread data ...

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

Reply to
John Providenza

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.
Reply to
Hal Murray

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.

Reply to
John Providenza

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.