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.
Jean Nicolle wrote:
> 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?
VVCAUX also powers DCMs and more see the datasheet
Jean Nicolle wrote:
> 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?
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.
> Jean Nicolle wrote:
> > 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?
>
> 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.
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).
"PeteS" <[email protected]> wrote in message
news:[email protected] oups.com...
> rickman wrote:
>
>> Jean Nicolle wrote:
>> > 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?
>>
>> 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.
>
> 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
>
PeteS wrote:
> 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.
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
will bounce.
If you want to contact me after that, try figuring out what
the next valid address will be...
"Sean Durkin" <[email protected]> wrote in message
news:456a8e5d$[email protected]..
> PeteS wrote:
>> 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.
> 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
>
....except for the differential termination bit. That seems to be powered
from VCCO. Pure genius.
Cheers, Syms.
Symon wrote:
> "Sean Durkin" <[email protected]> wrote in message
> news:456a8e5d$[email protected]..
> > PeteS wrote:
> >> 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.
> > 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
> >
> ...except for the differential termination bit. That seems to be powered
> from VCCO. Pure genius.
"rickman" <[email protected]> wrote in message
news:[email protected] ups.com...
> Symon wrote:
>> "Sean Durkin" <[email protected]> wrote in message
>> news:456a8e5d$[email protected]..
>> > PeteS wrote:
>> >> 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.
>> > 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
>> >
>> ...except for the differential termination bit. That seems to be powered
>> from VCCO. Pure genius.
>
> I can't say I understand this. Can you explain?
>
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.
Symon wrote:
> 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.
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
will bounce.
If you want to contact me after that, try figuring out what
the next valid address will be...
"Symon" <[email protected]> wrote in message
news:456ae4c0$[email protected]..
> "rickman" <[email protected]> wrote in message
> news:[email protected] ups.com...
>> Symon wrote:
>>> "Sean Durkin" <[email protected]> wrote in message
>>> news:456a8e5d$[email protected]..
>>> > PeteS wrote:
>>> >> 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.
>>> > 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
>>> >
>>> ...except for the differential termination bit. That seems to be powered
>>> from VCCO. Pure genius.
>>
>> I can't say I understand this. Can you explain?
>>
> 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.
>
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.
"Sean Durkin" <[email protected]> wrote in message
news:456af0f9$[email protected]..
> Symon wrote:
>> 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.
> 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.
>
Right, thanks for making that clear Sean. (I remember we had a similar
conversation here some time ago.) I've done the same myself, but only in
prototypes. As you say, it worked fine.
Of course, if Xilinx told us what the actual value was with 3.3V Vcco we
could design the traces to suit. But they won't, because they'd have to have
some kind of spec. which would add cost. As Bob says, a PITA.
Maybe Rick should design in the _DT with Vcco 3.3V and take it along to one
of his legendary 'peer reviews'! :-)
Cheers, Syms.
more S3E DIFF_TERM quirks ( was: vccaux and vccint )
Symon wrote:
>
> 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.
>
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
Re: more S3E DIFF_TERM quirks ( was: vccaux and vccint )
"Brian Davis" <[email protected]> wrote in message
news:[email protected] ps.com...
> Symon wrote:
>>
>> 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.
>>
> 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
>
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?
Re: more S3E DIFF_TERM quirks ( was: vccaux and vccint )
Bob wrote:
>
> 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?
>
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: http://members.aol.com/fpgastuff/lvds_current.pdf
( 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 )
Re: more S3E DIFF_TERM quirks ( was: vccaux and vccint )
"Brian Davis" <[email protected]> wrote in message
news:[email protected] ups.com...
> Bob wrote:
>>
>> 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?
>>
> 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:
> http://members.aol.com/fpgastuff/lvds_current.pdf
>
> ( 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
>
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.
Re: more S3E DIFF_TERM quirks ( was: vccaux and vccint )
Bob wrote:
>
> 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.
>
It scares me too! [1,2]
> Perhaps it is our version of HyperLynx that's the problem. If so,
> I apolgize to Xilinx.
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"