Pull up resistors on Spartan 3 mode pins

At last, a clear, rational statement. Thanks.

I can't say that solves my problem though. I have little doubt that there is any issue to the pullups working if you just leave them open. The fact that they are such a low resistance seems to me to make it a near certainty that they will pull up properly if left open.

This board is currenly ready to come out of layout with the only remaining issues, SI on the data and address bus which we think is due to an overly agressive TI IBIS model, it does not match the units we can measure; and this stupid pullup resistor issue.

There is little doubt in my mind that the stiff internal pullups make an external pullup unnecessary. I spoke with the engineer who had spoken with the Xilinx factory person and I had trouble finishing a sentance without being interrupted. It is very likely that she misunderstood what Xilinx was saying to her. I expect she was told that the pull *down* resistors needed to be tied directly to GND and/or the distinction between the pull ups and pull downs was not made. The fact that the data sheet and app notes show direct connections to Vaux and GND does not make the matter any more clear.

Just to be very clear that the difference between a resistor pullup and a direct connection is not splitting hairs, we have a current part on a board that does not work correctly because of a similar issue. The pin has three states for setting an I2C bus address; high, low and open. Seems the part is having trouble distinguishing the difference between high and open with most reistor values. That data sheet also did not make it clear what value resistor was required as well as the level of noise immunity on the input.

That engineer is working a lot of unpaid overtime at the moment. I prefer to get this ironed out before I am done with layout and can still make a change if *required*.

Reply to
rickman
Loading thread data ...

This could be digital territory but the analog aspects - pullups that are unaffected by HSWAP_EN - are forced upon the designers for pins - such as the JTAG - that no engineer should suspect would be pulled up by the silicon.

And the Spartan3 devices have an explicitly low pullup impedance that should be virtually immune to any crosstalk that's applied to an unconnected pin. I'd expect the antenna of connecting a 10 kohm resistor to the internal 3 kohm pullup would introduce more noise than leaving the pin unconnected.

A multimeter is nice if a board that *isn't* strapped to VCC or GND is readily available - not usually the case when someone's designing their first board with this series of devices - but it still provides only an order of magnitude idea of what's happening on the pin. Tolerances on pullup and pulldown currents don't need to be tight so they aren't. I

*will not* design a production board that relies on measurements to determine acceptable operation. The silicon *must* be tested to analog parameters that will guarantee operation in the board environment I design to.

An engineering mind is of little use when you have to submit to a design review with other engineers - some of which haven't designed with the device or know the documentation as thoroughly as someone who has - and must have documentation to support any action items produced from the review.

Trivial subjects deserve trivial answers. There have been no answers that I have seen in these threads. _____

Will the mode pins which appear to always have external pullups independent of the HWSWAP_EN pin behave fine when no external resistors are connected? Will the ~3kohm equivalent pullup impedances in unconnected pins work *just as well* or better than an external 4.7kohm pullup resistor to an imaginary mode pin with no internal pullup?

If the answer is "sure, no problem" where do we assure the fellow engineers that the pins will behave properly on power up (e.g., once the POR thresholds are passed, will those internal pullups have the full logic level established with internal pullups)? Is there a design issue such that POR from external pullups of nominal impedance willnot produce valid operation? Where could I possibly devine what the minimum pulldown resistor is to establish guaranteed behavior allowing an external jumper to change the mode pins?

These are trivial issues. With no documented answers. The last request from rickman was specifically - quoted in full:

rickman wrote: > People here are driving me crazy insisting that the Xilinx factory has > told them that you *MUST* tie the mode pins to either Vaux or GND. > After finding all the info in the data sheet and talking with support, > it looks pretty clear to me that the S3 parts have a very stiff > internal pull up and there is no need for an external pull up of any > kind, resistor or direct connection to Vaux. >

Do you believe that the trivial answer *has* been fully illustrated by Steve Knapp or others in these threads?

There isn't a great desire to spend time and attention to trivial matters when there are problems like Multi-Gigabit transceivers out there. If we lose the trivial details, we lose the ability to design for error free production because of trivial misunderstandings.

All ricman wants is to get the fellow engineers off his back on a trivial issue. All I want is an understanding of how the pins behave that I connect for "trivial" functionality such as the JTAG pins that I

*could not configure* to operate as part of a chain - I had to give the Spartan3 its own chain. The problems I had are probably trivial but I was unable to work past them without extreme measures.
Reply to
John_H

But is that if externally strapped to ground as someone at the factory appears to have informed rickman's group or unconnected such that the internal pullups guarantee operation all the time?

The discussion has a technical problem as the source. His steps may be slightly different but in my ISO9000 dictated compliance from years ago, if a design review produces an action item that says "check if the mode pins must be strapped to the rails directly because I saw that done on a Xilinx official application note" then that item must be followed up with a documented response providing evidence to address the original concern.

This technical problem - guaranteeing the design will operate as expected to the satisfaction of picky reviewers - cannot be addressed with the information at hand either through the data sheets, the FAE (incorrect info - we're all human), or through this forum.

- John Handwork Exclusively Xilinx for 8 years now

Reply to
John_H

Peter-

I think that type of thinking shows a problem. Engineers can't use your devices if they a) can't trust your documentation, b) can't get a straight answer from Xilinx experts to augment the documentation in an official and formal manner that stands up to design review, and c) have to spend weeks messing around with configuration just to get the part up and running before they can even try advanced features.

I would turn this around and say: if you can't handle basic configuration issues, then how can you be trusted to handle MGT issues?

What happens when you next decide that inner workings of a BUFGMUX are "trivial"? I can't get a straight answer on that either.

I always worried important Xilinx people were thinking like this. Please I hope it's not really the case.

-Jeff

Reply to
Jeff Brower

Let me repeat: If you want a mode pin to be interpreted as all High, you can do one of three things, and all are correct:

  1. do nothing
  2. use external pull-up of any value
  3. strap to Vcc

If you want a mode pin to be interpreted as Low, do one of two things:

  1. strap to ground
  2. use a resistor of 330 Ohm or lower to ground.

The mode pins have an internal pull-up resistor during configuration. Once the FPGA has been powered up, and the configuration memory has been cleared, the INIT pin goes High, and this Low-to-High transition on INIT samples the levels on the mode pins. At any other time, (earlier or later) the levels on the mode pins are irrelevant to the FPGA configuration process, or to its operation.

For people who prefer not to think, we can also be dictatorial: "You must strap mode pins to either Vcc or ground." It sure works 100% of the time, but it is not the only possible way.

This has been described in many generations of Xilinx data books, ever since I was responsible for them in the late 'eighties and early 'nineties, and the behavior of the mode pins never changed in our

18-year history. Peter Alfke
Reply to
Peter Alfke

Well, the real issue is: who's in charge of the design? The point of engineering is (I theorize) not that you do what other people say, but that you think.

And can't you demonstrate the pullup strength with a milliammeter?

John

Reply to
John Larkin

At risk of you thinking I am asking another dumb question, I have seen any number of devices that sample some input pin at a given point in the startup. There are microprocessors as well as FPGAs that do this. But I never see any setup and hold timing data on these pins. If I am driving the mode pins on a Xilinx FPGA from some other device, any idea how long I need to drive them to the proper state? Is the hold time from INIT_B going high significantly more than 0 ns? How about the setup time? I am asking because one option I am considering is to control these signals directly from the DSP operating at 200 MHz. At these speeds, I want to make sure the mode states don't change too soon after INIT_B goes high and I need to know what to tell the software person.

Reply to
rickman

Another benefit of define of Tsu, Th for Mode/INIT_B, is that it is then quite clear that they ARE edge sampled.

-jg

Reply to
Jim Granville

In 18 years, and with over 100 000 designers using our parts, nobody has ever asked that particular question. I assume we have no intentions of 100% production-testing this particular parameter (requiresd of a spec it in the data sheet), but I could produce a well-educated estimate of the longest set-up and hold time requirement, "guaranteed by design". My guess is that 1 microsecond is super-safe, but I will check. Peter Alfke

Reply to
Peter Alfke

Peter, you're an incredible ambassador for Xilinx, and a top-notch engineer from what I can tell. Whatever your salary is and whatever your options yield for you, you're worth it. (No B.S. intended.) I hope your boss reads this newsgroup. You and Austin, and Steve Knapp when he feels like it, are the bomb.

I just wish you guys would make all of your software free, including Plan Ahead ChipScope, and EDK. Then I would truly love you. Seriously, you should do that. And charge per hour for tech support, whatever it takes to offset the cost of developing and supporting the tools. Then super-smart guys like me (i.e., cash-poor consultants) would be able to use the tools for free and only the dummies would have to pay. (I was serious up until the last sentance.)

Best regards, Rob

Reply to
RobJ

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.