Spartan3 Configuration Puzzler

INIT_B is a "dual-purpose" pin. After config it is an I/O. Make sure you haven't inadvertently assigned this pin as an output (this can happen if your .ucf file doesn't specify LOC for all top level module outputs). When in doubt, use FPGA editor to check the pin.

HTH, Gabor

Gabor

I've checked my .ucf file & loaded it into FPGA pin editor & INIT_B isn't inadvertently being used by the design. I'm really quite baffled as to what is going on because the datasheet says that if the CRC is incorrect then the startup sequence is aborted. In this situation I'm assuming the design isn't used to configure the device. Maybe this is an incorrect assumption ?

Dave

You may have the bitgen option for the INIT_B "Persist" set to "No" for this pin, making the INIT_B no longer determined by the configuration logic once you're programmed.

The fact that your design works says that the INIT_B stayed high throughout the startup sequence. The flow diagram in the documentation you were probably looking at shows that a CRC error does not allow you to enter user mode.

Dave,

During configuration, there are several CRC checks. The first makes sure that the bitstream device ID matches that of the device being programmed. The other CRC checks are performed after the final frame of each FRDI read sequence. After the final CRC is completed, the startup sequence begins and DONE goes high (assuming default startup). The IO's are released as well as internal FF's and RAM.

As you are not using INIT as an IO in your design, the default is to attach a weak pulldown on the (all unused) IO. Thus, it is now low. Without knowing what type of file you are using with your u-proc configuration, it is hard to say what is contained in the last frame of the configuration file, but everything you are describing appears to be normal.

You can always specify to leave unused IO as floating or pulled up if you wanted to test this for a sanity check.

-David

Thanks for the suggestions.

I decided to set the INIT_B to an output forced high in my design and hey presto INIT_B goes high. As 'Davide' pointed out, unassigned dual purpose I/O pins are weak pull down. Turns out that there's weak and there's weak! the pull down can be less than 2K so my (fairly weak) pull up lost. So no CRC error after all but I should have read the datasheet in more detail before panicking.

DaveB

You are not the first engineer to have been caught napping by the Spartan 3 "weak" pullups (downs). Where I work, there is a strong tendancy to not act, or even react, but to *over*react to issues. Someone discovered this on a project a couple of years ago and decided to use 0 ohm jumpers to set the config pins. Then when I was drawing up my schematics, like you, I initially used resistors that were inappropriate. When another engineer corrected me and I investigated, I found what the issue was and decided to only add jumpers to ground since the pullups were plenty strong enough to pull up and could not be turned off. That led to a tirade about how 0 ohm jumpers were required in *all* cases on the Spartan 3s, pullup or pulldown. Of course this is not correct, but that day it was no fun being right.

The long and the short of it is that Xilinx does not always get this stuff right and they don't consider this broken enough to fix it. You would think they would note this clearly in the documentation that this part is very different from their other devices.

Starting in the Spartan-3 FPGA Family: Functional Description v1.4 (August

The Spartan-3 I/O pull-up and pull-down resistors are stronger than the "weak" pull-up/pull-down resistors used in previous Xilinx FPGA families. See Table 6, Module 3 for equivalent resistor strengths.

Your design was probably before the data sheet revision but the documentation DOES reflect this change. If you've looked at the S3E data sheet, your comment that "You

They didn't do a good job with the resistor strength in S3, absolutely. They _have_ taken care of the documentation side of things.

I don't agree with this. I had this discussion with Xilinx (mostly in this group) when I was investigating the behavior of all the pullups on all the pins of the Spartan 3. I found that the required information was scattered over multiple sections of the document and stated in different ways that even appear to contradict each other in some ways. Xilinx did make some adjustments to the data sheet, but I think the issue of using the pullup resistors in Spartan 3 devices is complicated enough that the information should be pulled together in one section where it can be found easily and completely. No one has time to read every sentance in a 200 page document. Instead we rely on the tools available for searching the document and typically don't expect to have to find info in multiple places to tell us the *whole* story.

Putting one sentance at the end of one section is not what I would call "taking care" of documentation. Obviously people are still missing this sentance and not realizing that the Spartan 3 pullups are different from the pullups on nearly every FPGA made by any vendor.

If engineers - myself included - are too lazy to RTFM, how _can_ a vendor forcefeed these professionals with the information that they *know* they'll need?

I'd be interested in the how. Very interested in any effective means above and beyond the documentation. If the PULLUPS and PULLDOWNs section is 2 or

With any complicated systems, the ability to communicate every nuance is hampered not by poor documentation as much as by the complexity. Engineers are supposed to be doggedly detailed people. If the datasheet isn't the first line of defense, what is?

That is my point. The information about the pullups is not in three paragraphs. It is scattered throughout the document. Try finding out everything about configuration pins and their pullups. I don't recall all the details I had to pull out of the document, but I remember that I had to read, and reread and then ask Xilinx for clarification on the whole thing.

Yeah, the info may be there, but with it documented in so many places, it is inevitable that some will be missed.

What is your point? I never said the data sheet is the wrong place for documentation. I said this data sheet is not done well and needs a separate section just for the pullups and how they relate to configuration. If I had the time right now, I would go back to the document and show you what I mean. But I just don't have the time to mess with the thing at the moment.

The ONLY way to convey complex information is with exceedingly clear and well organized documentation. This is often hampered by the requirement to meet deadlines which is what I need to do right now...

I would note that this issue existed in Spartan II as well. We (myself and another) were caught out by using an inappropriate pulldown value on the Mode pins, and were pulling our hair out wondering why the part was not always configuring.

Because we had chosen a value just low enough to 'sorta' pull the pins, sometimes it would configure, other times it would not. It was only when we got the voltmeter out and looked at the static levels with resets held that we appreciated the problem.

Cheers

PeteS

My apologies, Rickman. I read the issue as being that the weak pullups aren't weak pullups and that the documentation doesn't come close to specifying that. What I realize now is that your comments were on the pullup/pulldown condition of, specicially, the configuration (or other dual purpose) pins at the various stages of operation.

Yes, the configuration section could have clarified that a bit better; when I went looking for information on the specific behavior of the dual-purpose INIT_B pin, I was left with a slightly hollow feeling one gets when you know you don't have all the information. Different modes may or may not use different dual purpose pins and it's not clear what the condition is of each in the various configuration stages for the different programming modes.

Hi Dave,

Reading the remainder of the thread, it sounds like you've resolved the issue.

It is true that INIT_B flags a CRC error during configuration. After configuration, however, it becomes a full-fledged user-I/O pin.

If the DONE pin goes High, the FPGA has happily and successfully finished configuration, at which point the INIT_B pin is yours for the keeping. If you do not actively use it in the application, the Xilinx ISE softwrare automatically makes in an input pin with a pull-down resistor (never let CMOS inputs float!). On Spartan-3 FPGA, that pull-down resistor can be quite strong, below 1K-ohms for some I/O standards.

I see from the rest of the posting that there is lots of confusion over which pins have pull-ups or pull-downs, when they're active, and which bitstream options control them after configuration. I share your confusion.

As a consequence, we recently released a new Spartan-3 Generation Configuration User Guide that covers the new Spartan-3A FPGA family plus the previous Spartan-3E and Spartan-3 FPGA families. The current version is available for download from Xilinx.com at the following location.

Page 38 specifically covers what to do with the INIT_B pin after configuration to avoid this particular issue.

The table on page 49 also indicates which pins have dedicated, active, internal pull-up resistors that are always enabled during configuration.

As always, we try to make the Spartan-3 FPGA design process as easy as possible and we love to hear how we might improve the documentation or your experience using Xilinx FPGAs. If you have specific improvements, please let us know by clicking the [Feedback] link at the bottom of the user guide, or ...

Steven K. Knapp Applications Manager, Xilinx Inc. General Products Division Spartan-3/-3E FPGAs

--------------------------------- The Spartan(tm)-3 Generation: The World's Lowest-Cost FPGAs.