Spartan-3 configuration -- peculiar problem

You might try banging some extra dummy bits; sometimes that helps.

John

Thanks John,

The Configuration file _does_ load, though. I think dummy bits might help if the DONE line didn't go high. But it does. The FPGA starts, but the problem is that the INIT line goes low subsequent to the DONE line going high. There are apparently differences in configuration programming between the Virtex/Spartan-2, and the Virtex-2/Spartan-3 that I don't understand well enough. Especially the CRC / AutoCRC differences. I've been studying the doc's, but at this point I'm just confused...

Thanks for the suggestion though.

-Scott

b

We just take a .RBT file from ISE and pass it through a little program that packs it verbatum into our ROM image as binary stuff, up above the uP code (sort of a linker, sort of.) At powerup we bit-bang this into the FPGAs in slave serial mode, plus maybe 32 extra bits for luck. This has worked every time so far, on 4000's and S2's and S3's.

Does the INIT thing matter?

John

Yeah, that's what we do too, just bang out the bit file verbatim.

Maybe it doesn't matter. I checked my older designs, and see that I never monitored the INIT line, so the S2's could be behaving the same way, and I wouldn't know it. Ignorance is bliss? Maybe I should check...

I noticed that the Parallel Programmer 6 pin interface adaptor doesn't use the INIT pin either. That says something...

It only matters in that:

1) The fpga is complaining. I'd hate to get bit by it later on (no pun intended). 2) In this design I use INIT (a dual purpose pin) as an input after config, but it persists as an output. I guess I could cut and jumper, but it would be nice to sort it out and save a board rev.

As a practical matter, maybe I should just ignore it for the time being. File it in the conundrum bin and move on... Again, thanks for the fresh perspective.

-Scott

Are you pulling up INIT?

John

The INIT pin becomes user I/O after configuration. INIT going low indicates a CRC only if it goes low before the startup sequence of the device. If it goes low after the DONE pin has gone high then this does not indicate a CRC error but is rather attributable to the fact that INIT has probably become a user I/O now that the image is loaded and the FPGA has gone through the startup process.

Stephan

John

I _really_ should have ruled out the obvious before jumping to the conclusion that there was some exotic problem...

I had come to the conclusion that the fpga was driving the pin low with a 'galvanic skin resistance' pull-up plus scope probe. Didn't budge from ground, though adjacent inputs pulled-up. Should have been a bit more systematic in that test...

Being a bit more thorough, I just tacked in a 4.7K pull-up, and saw that it (INIT) behaves as it should during config, but only pulls up to ~1/4 VCCO after config. A 1.5K brings it up to ~3/4 VCCO.

It is clear now that there is no config problem and I've been barking up the wrong tree here. Seem's the input is unhappy after config, but the reason is probably a board short, or at worst a stressed IOB. I've been poking and probing it for days, so maybe I induced some ESD damage on the IOB. In any case, no config problem.

A million thanks John, for getting me to look in the right place. I feel a bit foolish for letting myself get out on the configuration tangent...

Thanks.

-Scott

Thanks All

For your considerations and patience.

Problem solved. Mea Culpa. IIFI. A comedy of errors:

Configuration worked perfectly from the get-go. I was convinced there was a config problem because my little 'hello world' LED- BLINKY-THINGY that I had dropped into the top level of the design wasn't causing the LED to blink.

I noticed the INIT line was low and became convinced I had a configuration problem. I chased that for a couple of days.

By chance I left the proto powered for a couple of hours and noticed the LED had turned on. Checked the design and noticed I had miscalculated the clock divisor for the LED blinker by a few orders of magnitude and it was blinking once every 4 hours, instead of once every second. DOH!

By then I had fixated on the INIT line being low, and was ensconced in my theory that the config logic was driving it there, as it 'shoudn't' have been low, by design.

My post-config use of the INIT pin was as an input. However my design wasn't using this particular input at this stage of the proto. The synthesis tool re-defined it as an unused pin.

I had asked bitgen to pull unused pins low.

It all makes sense now. Thanks again all for humoring me.

-Scott

Hey, this stuff is complex and it's easy to miss a detail.

We had one board with a Spartan 2E that wouldn't configure. Everything looked right, and the board was nearly identical to others we've done. If we probed the config lines at the uP, everything looked right but still no success. But then we probed CCLK *at the fpga* for the duration of a load, and it worked! Seems the scope probe capacitance made it work, but no amount of analysis ever hinted why. So we added a

33 pF cap. to the board.

John

John, your problem was caused by the fact that th FPGA CCLK pin (although the driving output) is also the input from which the FPGA itself counts the pulses. An extra glitch at this point, and FPGa and PROM get out-of-synch. Most designers investigate the CCLK line only at the PROM end, and miss the glitch on the FPGA end. I have explained this at least a hundred times, ever since the XC3000 days... Peter Alfke, Xilinx Applications

Sure, but the signal at the FPGA pin was perfect, even if checked with a 500 MHz scope with a fet probe. It's a slow cmos chip driving a short trace. And the board is no different from a dozen similar designs.

But the cap fixed it. I'm an engineer: I don't have to understand it, I only have to make it work.

John

500 MHz (reduced further by the probe) may no longer be sufficient for analyzing such problems. You mentioned that the probe eliminated the problem. That indicates a substantial capacitance. "Slow CMOS chips" are not really slow anymore...

My question is: How many design are out there in the world, functioning with minimal margins? Attention to Signal Integrity is important like it has never been before. Peter Alfke

Usually, you have to understand things in order to make sure that a fix like adding a cap is a solid fix or a just-barely-this-time type fix that might come back to bite you (again) tomorrow.

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

No, a regular passive probe fixed it. The fet probe didn't, but it showed a nice waveform.

It's an MC68332, and they're *still* slow!

Well, tons. In this case, a 10 pF cap fixed it solid, so we went with

33 for luck.

Couldn't agree more.

John

We put a SOT-23 green LED on the DONE pin of all Xilinx chips. It always gives me a warm feeling to see them all light up in sequence at powerup.

John

Yep.

Isn't that the first rule of product design, that you can never have too many LED's? ;)

The old Volvo 240's had a 'Bulb Failure Warning Light' on the dashboard. But what about the case where that bulb failed? Oh no! Infinite recursion...

-Scott

Luckily, in all the cars I've had, the warning bulbs all come on briefly as you turn on the ignition. This way you know if they're working or not! Cheers, Syms.

Obviously, for a logical design, if the BFWL fails, all the other lights come on.

John