Looking for consultant

something's

Try hanging a small capacitor, 33 pf maybe, from the jtag clock pin to ground at the FPGA.

John

My background's FPGA design, but I'm willing to try an appendectomy if he'll cover the insurance, I lived with a load of doctors through university so something's bound to have rubbed off :-)

Nial.

: My background's FPGA design, but I'm willing to try an appendectomy if he'll : cover the insurance, I lived with a load of doctors through university so something's : bound to have rubbed off :-)

: Nial.

We are looking for consultant who will be able to solve the following problem:

PCB with Xilinx Virtex II and EPROMS. EPROMS are loaded with bitstream through JTAG. Once PCB is powered up, FPGA will have problems loading core. Nature of the problems is intermittent. Sometimes it will load core, sometimes it will not. When it doesn't load the core, it reports CRC error. When it loads the core, everything works perfectly.

We are looking for experienced consultant (PCB, digital electronics, FPGA,

10+ yrs. of experience).

Contact:

Slavisa Zigic email: snipped-for-privacy@cfrsi.com tel: 703-385-4493

Hello Slavisa,

Just a hint from a guy who is not an FPGA expert. Sometimes these kinds of problems are not digital. There could also be issues with, for example, the power supply rail during or shortly after power-up. Timing issues are another area to look at. Same for the transmission lines if the EPROM is far away from the Virtex chip.

Regards, Joerg

Although you don't explicitly say so, you appear to be working somewhere within the United States of America.

Your problem seems to lie in the data transfer between between the EPROMs containing the programming data for the Virtex II FPGA and the FPGA itself.

Since the transfer sometimes works, the proportion of bits being corrupted during transfer has to be very low. You are going to have to hang a scope probe on the connection and look at the analog signal to get some kind of idea of the way the data is being corrupted.

This is hands-on work, and the chance that I could offer much help from the Nijmegen in the Netherlands is not all that high - though modern scopes digitise the signals that they look at and can be persuaded to turn the screen image into an e-mailable file.

You've already had a couple of pieces of useful advice - John Larkin and Joerg both know what they are talking about - and should be able to get more.

------------ Bill Sloman, Nijmegen

something's

Judging by your website, it looks like you have a company full of PhDs. You should have the smarts there to figure this out.

You could have a voltage incompatibility, power supply startup problem, signal integrity problem, control signal problem, etc. Search 'configuration' on the Xilinx website.

================================

Greg Neff VP Engineering

*Microsym* Computers Inc. snipped-for-privacy@guesswhichwordgoeshere.com

This sounds like a signal integrity issue, like the others have said it'll probably take a bit of hands on analysis and I'm based in Edinburgh, UK. If you're willing to pay for flights I'll come and visit :-)

Some things to look at....

These config signals can be relatively fast, especially if you're using a serial configuration scheme. It's important to consider this when placing devices and routing signals.

How far away ftom the FPGA is the configuration device?

Are the config signals routed carefully over a continuous ground plane?

Are there signals with fast edges close to your config signals that could be inducing noise on your signal lines?

If noise is being coupled onto your clock line John's suggestion of a small cap at the FPGA might be worth trying to decouple it a bit.

Some of the Xilinx config devices allow you to specify what the configuration clock speed is. If this option is available it could be worth slowing the configuration down to see if it helps. This is a bit of a bodge though, if things seem to be better I wouldn't rely on this to give guaranteed 100% performance. You still need to clear up the signal intergity problems.

If you're really stuck it's probably worth contacting your local Xilinx FAE. They should be able to help or know of local consultants that will give you a hand.

Hope this helps,

Nial

------------------------------------------------------------- Nial Stewart Developments Ltd FPGA and High Speed Digital Design

Do you have any power-on reset to make sure the power rails are stable before you start trying to load the configuration? The pin is called PROG_B on the Spartan-3 series, I'm sure the Virtex II has something similar.

If so, have you scoped to make sure that the pin is in fact being held low for long enough for the rails to be stable?

No you're not looking for an experienced consultant, most of whom are near worthless. You are looking for an intelligent person with a track record of fixing problems. Your problem is either layout or turn-on sequencing related, trivial whatever the case. Just find someone who can pay attention to detail and make measurements, with enough background to characterize the engineering parameters so as to make a permanent fix that works through production. The damned "job" won't take half a day, and that with a liberal frequency of coffee breaks.

2E's also have the crazy powerup current surge, wherein they look like millifarads of capacitance as you try to grunt them up. I think they've fixed that on the Spartan 3's. I sure hope they have.

We always use slave serial config mode, and it works. I did have one board that needed a cap to ground (or a serious termination, that worked too) on the config clock line; never understood why.

Can you really program a Xilinx chip to fry itself? Neat.

John

It was CCLK, the serial configuration clock, that I had to bypass. Without that, the configuration was intermittent, sort of what the OP describes. I discovered it accidentally by poking it with a 1x scope probe; as long as I held the probe on the pin, it would configure every time. So then I scoped it with a 500 MHz scope and a 1GHz fet probe, and it looked fine, no nasty ringing or anything, and setup/hold times were huge. So we just ECOd the cap onto all the boards.

I hate stuff like that; never did understand it.

John

something's

I'm very very familiar with that problem. You need a power supply capable of delivering at least the maximum current for each Xilinx device when programming through JTAG. I even managed to crash and literally burn several Xilinx Spartan 2E devices while implementing the JTAG programming algorithm just by trying to program them. In short: stay away from programming Xilinx devices through JTAG. The JTAG implementation is buggy and may also vary between devices. For instance the algorithm described for Virtex and Spartan 2 devices doesn't work for Spartan 2E devices. Either use parallel programming or the serial programming through DIN if you want something stable.

--
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl

The OP stated that they are using JTAG to program the PROM, not the FPGA. The mechanism used to configure the FPGA from the PROM was.not clearly stated.

You certainly can program an FPGA to be a toaster, Just tie lots of internal outputs together, and attempt to drive them to different states.

By the way, I would not try using a capacitor on a Xilinx FPGA clock input. The Xilinx inputs are blindin/screamin/honkin/biteyerass fast. They have no hysteresis, no patience, and no sympathy. Xilinx doesn't have Doc Johnson on retainer for nothing. The capacitor will reduce the amplitude of an aggressor signal, but it will also slow the clock transition time. This will have the effect of increasing the time at which the input sits near the transition voltage, widening the window in which the input will be susceptible to an aggressor. I have seen a small capacitor make the problem significantly worse. On the bright side, this makes it easier to identify the aggressor.

================================

Greg Neff VP Engineering

*Microsym* Computers Inc. snipped-for-privacy@guesswhichwordgoeshere.com

No doubt your small-size cap made little difference in the risetime, but perhaps it lowered Zclock, and prevented double-clocking on edges.

--
 Thanks,
    - Win

(snip)

With subtle crosstalk problems you can stare at a signal until you are blue in the face, use all your fancy triggers, and still not see it.

I track these down by first examining the PCB layout. I make a list of all signals that are physically close enough to be crosstalk hazards. I then take my best guess as to which one is the likely culprit and start there. In some cases it can be a group of signals that transition simultaneously, like an address bus.

You then need a 2 channel fast DSO and a pair of FET probes. Set the scope to edge trigger on channel 1(first try falling edge, then try rising edge). Connect channel 2 to your victim signal (in this case CCLK). Now use channel 1 to look at your potential aggressors. You will now clearly see any crosstalk on your victim. The crosstalk will affect a clock only if it is coincident with the clock edge, but if you can observe the crosstalk while the clock is high or low, and the signals are asynchronous to each other, then you know that the crosstalk will also affect the clock during its transition.

================================

Greg Neff VP Engineering

*Microsym* Computers Inc. snipped-for-privacy@guesswhichwordgoeshere.com

Pretty good discussion and helpful hints? Was following everything till now, whats a Zclock?

Thanks Brijesh

The impedance of the clock line.

--
 Thanks,
    - Win

Very interesting. Thank you for sharing that!

--Mac