XIlinx Spartan 2E stuck in configuration mode

I use a similar scheme for an XC2S200E and a '50E, except that I use a single bit wide data path. Initially I had similar problems. I found that the power supply rise was not monotonic, and this seemed to upset things. I also found that sometimes if the configuration process failed then the fpga needed to be power cycled before it would behave - so I implemented a series fet to do precisely that :-] The whole system is in a distributed noisy environment, and now I basically turn on the main power with the fpgas powered off, wait for everything to settle, then turn on and configure fpgas in a staggered sequence. Crude it may be, but it works in the field ...

Dave

Have you checked the obvious stuff like pin-out and power supply voltages? Even though the XC2S300E and XC2S150E come in the same packages there are slight differences in the pin usage. In the larger packages the

300E has more power pins, for example.

Also check that the hex file was generated with the correct format (not bit-swapped vs. the 150E file that worked). I would suggest trying to load the working bitstream of the 150E to see if you can make the INIT go low that way. If the device doesn't see the correct preamble it will not start loading code. Are you using the same version of tools that prepared the hex file for the 150E? There was a bug in the 8.1i iMpact GUI that cased raw hex files to come out bit-swapped whether you checked the box or not.

HTH, Gabor

Check for ringing on the CCLK signal at the fpga... that has nailed us a couple of times. Try adding 33 pF to ground, just to see if that's the problem. Sometimes just probing CCLK at the chip will allow a config to complete.

Rumor has it that some future Xilinx parts will add schmitt triggers to CCLK and maybe some other config pins. Lately, we're adding TinyLogic schmitt buffers right at the pin, unless the trace is *very* short.

CCLK signal integrity requirements are right up there with all the other clocks on the board.

John

False Rumor,

We still require signal integrity to be correct, and have no plans to try to deal with bad engineering.

Aust> >

The XC2S parts are notorious for being difficult to power. They went so far as to recommend that you use an LDO and large caps to generate the core voltage to make sure the voltage ramp is monotonic in spite of the the high surge current that the chips produce. I never was bitten by this one, but if you missed the spec on power-on surge requirments, you could be a victim.

The Spartan 3 devices don't have this problem, so sometimes Xilinx does deal with bad engineering, if it is their own!

Whose side are you on? Do you *prefer* your FPGAs to not configure, as some sort of punishment for crosstalk?

CCLK is often bit-banged from a uP port and bussed to multiple devices. Lately it requires serious added drivers/buffers and termination to be reliable with the faster FPGAs. Given a "slow" (say,

5 ns) risetime, the noise margin on Spartan3's is down in the millivolts. Since you really can't clock these things above 20-25 MHz in most situations, why use a gigahertz clock buffer on this pin?

John

Is that really what you meant to say ?!

-jg

and Austin Lesea replied:

Oddly enough, that particular Schmitt CCLK rumor was confirmed by Steve Knapp last spring [1] :

Fortunately, those nice GPD guys don't seem to pay any attention to Austin's newsgroup prevarications.

Which gives us such improvements as Schmitt triggered CCLKs, and S3E's simplified, DCI-free I/O buffers, having a quarter the input capacitance of a V4.

Brian

[1] Steve Knapp's post about forthcoming Schmitt CCLK pins

Brian,

I see Steve at lunch, so I will have to ask him who he talked to.

100 mV of hysterisis is pretty much part of all input buffers, but that won't do it.

Aust> John Lark>

Jim,

Not sure what you mean. If you mean that Xilinx should encourage bad engineering, well, no, we don't.

Austin

Jim Granville wrote:

Austin said: > We still require signal integrity to be correct, and have no plans to > try to deal with bad engineering.

Since John described a problem that required additional parts, and is thus an oversight in the FPGA design, that to me fitted the "bad engineering" descriptor quite nicely.

However, your reply suggests Xilinx have a very different way of measuring "bad engineering" ? and I was left bemused...

-jg

Jim,

The problem is perhaps a bit more complex than you are suggesting.

We have customers that require the parts to configure very fast, basically at the maximum CCLK rate in the data sheet. That said, those clocks require SI engineering.

Since some folks require high speed, and others do not, what compromise can we make?

Do we put the circuits in the chip and slow the edges down, schmidt trigger with extreme hysterisis, and just wqalk away from another set of customers? That doesn't work. Can we program the CCLK pin's behavior? No, because this is a "chicken and egg" problem (have not read in the bitstream, yet. If you have a solution, I am listening.

So, rather that characterize my response as callous, unforgiving, and elitist (which some have seemed to do), it should be seen as "these are the simple facts."

It is a high speed interface (because people do use it there), so if you use it at very low clock rates, you will still need to do the necessary singal integrity engineering.

And, if you do not have a tool to do it, our hotline will do it for you, for free. (I have said this many times before). We will also suggest you invest in an SI tool (my favorite is Mentor's Hyperlynx), which will pay for itself when you do not have a pcb respin, once, due to better SI engineering.

I am apalled that people who call themselves 'engineers' (not referring to you, of course) would completely ignore physics, and continue to act as if there is no such thing as signal integrity, and continue to waste their company's money by not doing something that they should be doing (not just for CCLK, but all the other IO pins on the package, too).

Austin

A ns or two of lowpass-type delay and a half of a volt of hysterisis or so wouldn't slow anybody down. The max S3 CCLK rate is spec'd at 80 MHz, and limited to 20-25 MHz under other conditions. Something that behaves like a TinyLogic schmitt would make everybody happy. I'm now using them adjacent to the CCLK pins.

The waste of money and PCB real estate is in having to buffer, fan out, terminate, and crosstalk-harden a signal as if it were a system clock, when all that is (or should be) absolutely unnecessary.

All pins do *not* need the same signal integrity analysis or treatment, and it would be impossible to provide it in many common situations. Data busses are a common example where hundreds of millivolts of crosstalk may just not matter, so we can bunch all those traces together on one layer.

I'm appalled that you have such contempt for real concerns of real customers, and insult us to boot. I design with 12 GHz CML when I have to, 35 ps edges with 400 mV swing, but I don't see why Xilinx won't do something simple to make their parts configuration easier and more reliable.

John

John,

I apologize, I had no intent to insult you.

I will pass along your suggestion to the folks who do that design for the config circuits, but I suspect I will hear what I have before ... "it isn't that simple..."

As for contempt, I have no contempt for anyone. I just point out that folks save pennies, and then spend thousands of dollars. A company that goes out of business is not a good customer to have. I prefer customers that are making a good profit.

Austin

Sorry Austin, but others seem to be able to DO this, so they are not simple facts.

Show this datasheet to your design team, next time they try and fob you off with a "it isn't that simple..."

This specs 190Mhz min clock, 300Mhz typ.

More of this Tinylogic is deploying Schmitt as default, and clearly they have decided the speed impact is tolerable, ( or perhaps their designer's are smarter ? )

Also mention that Atmel spec a 1.5ns (MAX) adder for their Hyst option, on a slower process than Xilinx uses.

Hysteresis and speed are NOT mutually exclusive, especially on an ~80MHz CCLK line, that WILL be driven much slower (and with slower edges) in many designs : it is bad engineering to NOT deploy it.

You now have customers adding 'band-aid' solutions around your devices because of this, and seem more motivated to fielding excuses than driving a fix.

-jg

Of course there is a solution. You can set the default behavior to the slow, safe interface. Then a few clock cycles into the bit stream a bit flips the interface to allow the higher speed, "watch out for yourself" inteface. I seem to recall that other Xilinx parts had something like this in the bit stream. It was likely way back in the XC4000 days, so maybe Peter would remember.

Yes, this is the sort of response I would expect from you Austin, the know-all, be-all reply that shows you know exactly what is wrong with every other engineer in the world. SI needs to be addressed, but that does not require the expenditure of a multi thousand dollar tool that won't produce didly unless you know exactly how to get the right data into it and that include data the designer has no control over.

Just relax a bit and consider that not every design requires a simulation tool to assure that SI is handled properly and the board won't blow up. The idea of adding some safety circuitry to deal with a little noise on the CCLK line is not a terrible thing. Perhaps you could take this back to the chip designers rather than complain about the 'engineers' who buy your parts.

To the engineer who wants to solve the problem of using an imperfect transmission line for the CCLK, you might try considering that you can solve the SI issues without treating the signal as a high speed clock. The SI issue is created when the length of the signal line is long compared to the rise time of the driver on the line. You can use the high falutin' termination techniques that will prevent reflections and such from messing up your signals, or you can use a driver with a slow edge rate so that the reflections don't create extra transitions in your CCLK line. It may seem like a "silly" thing to do, but I am surprised that the FPGA is the only part that responds poorly to non-monotonic edges or ringing on the configuration clock line.

I have not tried to design in a slow driver, but even if you can't find a small IC that will do the job, I can draw up an emitter follower transistor circuit with an RC that should give you complete control over the edge rate. The dual NPN/PNP comes in a package as small as

1.6 mm sq. which is about like an 0606 resistor. So the total circuit size is the same as using four 0603 components.

Jim,

We also have customers who know SI, and perhaps end up with a resistor for proper termintion.

But I will mention it.

Thank you,

Austin

Rick,

OK. I never complained about the engineers who use our parts. I pointed out that there are those who just don't seem to be doing their jobs (IMHO).

And I do not know everything. In fact, I have already posted that I know very little: I poll others here at Xilinx prior to my responses. I am flattered that you thought I actually come up with all of this all on my own!

And, I do suggest that a little SI goes a long way. When was the last time you tried HyperLynx? With the little I know, even I can use it easily.

Anyway, thanks for reminding me of the dual speed modes. I recall a terrible customer issue that involves the dual speed use, where the low speed worked fine, and the high speed did not. Why? No SI engineering. So they built it in slow mode, and then changed to fast bitstreams for production.

Results: line down, and plane flights for all the designers ("How could you do something so stupid!"). Maybe one disaster is insufficient to kill a good feature?

OK, I have said I am going back and discuss a more forgiving input with designers, and I have said SI is a good thing, and saves money.

Please don't put words in my mouth, (or ideas in my head that I never could possibly have had -- I am just not that smart!)

Aust> Aust>

Good grief, I *know* how to do stuff like this. I just don't like being forced to.

John