vccaux and vccint

I'm looking at the Spartan-3e datasheet and I'm surprised in the number of power pins in the PQ208 package. There are

  • 4 VCCINT pins
  • 8 VCCAUX pins
  • 12 VCCO pins

The number of VCCO makes sense (3 per banks), VCCINT could be (maybe the device consumes little), but why 8 VCCAUX? VCCAUX is just used by just 6 pins (4 JTAG pins + DONE and PROG_B). 8 power pins seems overkill for just powering 6 pins.

Am I missing something?

Reply to
Jean Nicolle
Loading thread data ...

VVCAUX also powers DCMs and more see the datasheet

-Lasse

Reply to
langwadt

I know how you feel. I have often wondered why there are so many power and ground pins on these devices. But if you dig into the signal integrity issues you will find that it is amazing that even with this many power and ground pins that the parts can work at all! The packages are not really up to the task of the really high speed I/Os if you are using a lot of them. If you are pushing the quantity and speed of the I/Os at all, you should never try to use a QFP package because of the large inductance.

Although the VCCAUX only powers a few I/O pins, it powers a fair amount of internal logic. Things like the DCMs are especially sensitive to power supply noise so I would not begrudge them a single power pin. I am a bit suprised that they even share the I/O supply with the internal logic since the I/O pins can make some hefty current spikes. It may be that some of the VCCAUX pins are just for I/Os and some are for the internal logic.

Reply to
rickman

On the S3, at least, VccAux powers the JTAG chain, part of the init setup and the DCMs. I don't believe it powers anything else. One might surmise there is at least one power pin (VccAux) that comes in at the bond wire close to each DCM; the DCMs are physically located in the 4 corners and routing power internaly would add noise and other undesirable effects. That would specify a minimum of 5 VccAux pins (4 DCMs, 1 JTAG in anything larger than the XC3S50 which has two DCMs, IIRC).

I don't think I've used a non-BGA FPGA in the last 5 years, because of the lead inductance issues amongst other things (physical space v. pins is also an issue for me).

Cheers

PeteS

Reply to
PeteS

Reply to
Jean Nicolle

It usually supplies input and output buffers for LVDS as well (at least it does in Virtex2 Pro and Virtex 4), even if the bank those IOs are in is supplied with i.e. 3.3V.

cu, Sean

--
The FROM:-address in this posting is valid until the end of
the month only, after that every e-mail sent to this address
 Click to see the full signature
Reply to
Sean Durkin

...except for the differential termination bit. That seems to be powered from VCCO. Pure genius. Cheers, Syms.

Reply to
Symon

I can't say I understand this. Can you explain?

Reply to
rickman

Hi Rick, You can use LVDS receivers in a Vcco = 3.3V bank. As Sean says, it appears they're powered from Vccaux. However, you can only use LVDS_DT receivers if Vcco = 2.5V. Check out the note on Figure 31, DS083. I've posted here a couple of times about this, I don't think I ever found out why it is so. Cheers, Syms.

Reply to
Symon

Well, you CAN use them (i.e. the tools don't stop with an error or give you w warning or anything), but the termination value won't be 100 Ohms. Xilinx doesn't specify what the actual value might be, since they don't recommend using the terminations that way. I've used it successfully on 2 boards with VCCO=3.3V. "Successfully" meaning that it works and the signal at the balls doesn't look that bad.

--
The FROM:-address in this posting is valid until the end of
the month only, after that every e-mail sent to this address
 Click to see the full signature
Reply to
Sean Durkin

I suspect that the output stage for LVDS is always powered by VCCO (but the input side is powered by VCCAUX).

Either way, it really is a PAIN IN THE BUTT that the differential termination only works at a specific VCCO supply voltage -- a REAL pain in the BUTT, Xilinx.

Bob

Reply to
Bob

Other S3E LVDS termination trivia to make note of:

- S3E constraint syntax uses the V4-style DIFF_TERM attribute for the input terminations, see Answer Record 19627

when using 8.2i, first read Answer Record 23829- using DIFF_TERM in the .ucf file is not supported, you need to stick it on an input primitive directly in the HDL instead

- S3E "input-only" pins (IP_Lxx) don't have DIFF_TERMs

- LVDS inputs _without_ DIFF_TERMs have a wide common mode input range

- LVDS inputs _with_ DIFF_TERMs are limited to the much narrower Vod/Vocm range of the associated LVDS _output_ standard to meet the 120 ohm "spec" in the datasheet ( Rdt, table 77, DS312 v3.4, pp120 )

- that 120 ohm termination "spec" is specified only as a typical, without any min/max; is prefixed with a squiggle whenever mentioned in the datasheet; and, the termination is not modeled ( not even as an IBIS series element with static variation ) in the latest (v2.1) S3E IBIS files

- see also Answer Records 17244, 13910

- despite vanishing from the latest Libraries Guide, those handy DIFF_OUT LVDS input buffers are still present in S3E, but the associated tool bugs have gotten worse

Brian

Reply to
Brian Davis

Brian,

This is great information. Thanks for posting it.

I was just doing some HyperLynx sims and saw no difference for the LVDS and LVDS_DT models. I thought it might have been because we're using an older version of HyperLynx.

Why does Xilinx include the LVDS_DT as a separate entity, in the IBIS file, if it's not modeled properly. Well, Xilinx?

Bob

Reply to
Bob

Unless I missed them, there are not any LVDS_25_DT models in the latest Spartan3E IBIS files.

There is an LVDS_25_DT in the V4 models, which is modeled as an IBIS "series" element, called "rterm_100", across the pins of a regular LVDS_25 input model.

This is modeled in V4 as a static resistance with tolerance, which ignores any artifacts caused by a FET termination scheme whose impedance varies with Vid and Vicm ( which I suspect is how they are implemented, but I don't know for sure )

The _DT models in the V4 IBIS files appeared to be working in HyperLynx at some point, if you look on pages 35-38 of those LVDS sims I posted last spring you can see the input swing being terminated by the LVDS_25_DT model:

formatting link

( There were problems at one point with the V2 LVDS_25_DCI models in older versions of Hyperlynx, but those modeled the split terminations by burying the terminator currents in the clamp tables )

Brian

Reply to
Brian Davis

Brian,

It was V4 that I was simulating (LVDS_25_DT). The only way I could get it to work was to manually add in a parallel 100ohm.

I didn't try the DCI version. That version of termination scares me because (normally) the LVDS driver sets the common mode voltage of the pair. With DCI, it has an effect on the common-mode operating point. Xilinx LVDS -> Xilinx LVDS_DCI should work (you would think) but what about other non-Xilinx LVDS drivers into DCI?

Perhaps it is our version of HyperLynx that's the problem. If so, I apolgize to Xilinx.

Bob

Reply to
Bob

It scares me too! [1,2]

I haven't had access to HyperLynx for a few years now, but Mentor's support abstracts say you need better than V7.5 to use terminations modeled using the IBIS series elements: " "TechNote mg42698: HyperLynx: Differential DCI internal termination " If this behavior is modeled using the clamp table currents, " HyperLynx can account for the internal termination during simulation. " If however the model is calling a series IBIS resistor model to model " the internal termination, HyperLynx V7.5 and eqarlier will ignore it. " The work around in this case would be to place a differential " "quick terminator", of the same value, between the two IC pins instead. "

Note that modeling a non-linear, on-die, FET termination as an outside-the-package, ideal, resistive termination might produce HyperLynx simulation results that "are not helpful to anyone" :)

Brian

[1] post describing LVDS DCI modulation artifacts
formatting link
[2] Xilinx Answer Record 13012, plots of DCI LVDS modulation artifacts
formatting link
Reply to
Brian Davis

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.