XIlinx Spartan 2E stuck in configuration mode

"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)."

I would say that claiming to be "apalled" about engineers who use your parts is "complaining". If not, what *do* you call it?

I think I have a good handle on what you do and don't know. It is the way you present it that "impresses" me.

I used it on my last board. I find that it is *not* easy to use because it depends on having good info and I have little reason to believe many of the device models I have to work with. This was discussed in a recent class I took and many of the participants and the instructor all agreed that many BSDL files contain errors.

If your customer does not understand the implications of using the high speed, why did they attempt it and why, oh why would Xilinx then feel it was a bad feature??? It almost sounds like you are trying to protect your customers from themselves by removing useful features.

I could never put words in your mouth. I don't think there is any more bandwidth left... ;^)

Peter,

Thank you, I had wanted to say something similiar, this harping was seeming too personal + counterproductive.

It says a lot to me and other engineers that Xilinx engineers are participating in these newsgroups. Bitching at them isn't going to give them or similiar engineers from other companies a big incentive to stick around.

Xilinx is a business, they're doing pretty well so they must be doing something right. Nobody's perfect, businesses included. Maybe they're doing the best they can trying to maximize everyone's satisfaction with their products, with limited resources and budget.

I'm a relative newcomer myself so didn't really think it was my place to lecture. Sorry if this email sounds like one.

-Dave

The lecture is no problem, but it is not uncommon for people to go off on Austin. In fact that seems to be a pattern here. Austin says some things that are either rude, arrogant or just plain wrong and people respond appropriately. Then either Peter comes to his rescue asking that we "restore civility" without ever asking Austin to cool his jets or once in awhile someone else chirps in that they "value" Austin's input in this group.

I don't for a minute doubt that Austin makes valuable contributions here. But he is subject to the same treatment as anyone else. If he comes across badly, it can be pointed out to him. I don't consider this to be personal because I would reply likewise to anyone else who posts in the same manner. Often it seems personal just because while most people will respond by acknowledging when they were wrong, that does not seem to happen in this case.

Actually the stuff you find in this group is *very* tame compared to many of the newsgroups. After all, this *is* the Internet.

Sometimes I wonder why representatives from Altera don't post more often, but that likely has to do with the businesslike manner they ususally have. They prefer not to get into public debates with representatives from Xilinx I think.

Understod.

Aust> Aust>

Rick,

I suspect we will continue to agree to disagree,

Thanks for your comments,

Aust> Aust>

I have one board with six Xilinx chips and two SPI chips (a temperature sensor and an eeprom) sharing one CCLK/SPI clock source, all driven by a port pin on a microprocessor. The parts are all over the board, so neither source nor load termination are practical without adding a multi-output clock buffer and star-routing the CCLKs. What a pain. So the easiest answer is to add a TinyLogic schmitt chip adjacent to each Xilinx. Xilinx could add that functionality internally for about a millicent. The two SPI chips, of course, already have schmitts on their clock inputs.

John

Why is a schmitt trigger input an automatic cure for SI issues? All this would do is to raise the bar for the amount of noise on the signal, it does not remove the need to consider SI. If the concern is the reflections and improper termination of transmission lines, I would expect to see ringing much greater than the small margin added by a schmitt trigger. But if the edge rate of the driver is low, then you can live a happy life without the schmitt trigger. Of course even ringing is typically a short lived transient. So if the buffers are rather slow, they may be acting as a low pass filter which is what Xilinx has said they don't want to do to the CCLK input so it can work with high data rates.

I guess I am saying that although it would be nice if the CCLK input had a schmitt trigger input (and was 3.3 volt), you can't expect that to solve SI issues without giving them further consideration!

because it is not always a reflection/SI issue ( as I pointed out to Austin, and I believe he is passing onto the design team )

As the FPGAs get ever-faster, they get LESS tolerant of slow edges, and even small ground bounce on a slow esge, can double clock. [and uC often have deliberately slow edges, for EMC reasons]

A number of (bad) things can occur with slow edges. Very slow edges can cause input buffer oscillation, but even 'moderately slow' edges effectively amplify ground/Vcc bounce.

viz: If the clock is not well clear of the threshold, by the time the current spikes start, you can get double clocking (and thus unreliable config).

John has simply added a device that fixes a real design problem. Note that he mentions the other SPI devices DO have schmitt clocks ?

-jg

I give everything consideration; I'm an engineer, not an "engineer." And I do understand things like termination, reflection, and noise, and I do routinely use pre-layout tools and a 20 GHz TDR system to find out what's actually going on with my PCB designs.

The issue is that as FPGAs get faster, relatively slow (as in 7 ns "TTL" edges) spend a lot of time close to the logic decision point of the CCLK input circuits, and noise margin gets tiny when the CCLK input gets picky about sub-ns-scale wiggles. A low edge rate becomes yet another hazard, not a fix. One of our boards wouldn't configure because we had about 100 mv p-p crosstalk (from some VME bus signals) getting into a slow CCLK edge.

If a single uP pin drives a CCLK net, the signal may go in different directions, requiring multiple terminations, and most uP port pins can't drive loads like that. If it's a single trace that daisy-chains through multiple chips, the lump-loaded trace impedance gets very low, and again it's hard to get a legal drive, and one can expect ugly plateaus and rings on the mid-rise. And even if the termination thing is resolved, slow edges have bad noise margins when driving very fast gates that have no hysteresis. Adding hysteresis would allow me to use slow edges and tolerate quite a bit of noise and crosstalk, and that opens up a lot of design options.

SI doesn't mean that every signal is ns-fast, impedance matched, and terminated. It means that every signal works. If CCLK is a very fragile input, we can drive it, but it takes more parts, more analysis, and more PCB real estate to make it reliable, and Xilinx could make it much easier if they cared to.

And heaven help the kids who connect CCLK to a PC parallel port through a cable, and never get Xilinx chips to come up. They aren't the best prospects as repeat customers when they graduate and start designing in earnest. "Oh we tried Xilinx and WebPack for our senior project, but we never got the damned things to configure, so we used Altera."

John