FPGA Central

I've reviewed the docs briefly but didn't find this information.

I'm playing with a XC3S400 in a 256 BGA on the Digilent board. If I were to
use all the available I/O pins to drive LEDs (that's 104 of them), and do
something silly like turn 'em all on at once, will I exceed the maximum
current draw of the chip and let out the magic smoke?

The eight red LED's on the board are driven directly from the I/O pins
through 390 ohm resistors.

I am planning on attaching a green LED to each of the 96 I/O pins exposed on
the connectors through 390 ohm resistors.

Thx,

-Nevo

Do your homework:
Build one such interface, then measure the supply voltage and the
voltage on either side of the 390 Ohm resistor. Use simple math to
clculate the current, and also the power dissipation inside the chip,
for this one instant. Then multiply the power by 96.
I am quite sure that the current will be below 1 A, and thus no
problem. But you might think about the on-chip power dissipation.
All you need is a multimeter and high-school math.
Peter Alfke
========================
Nevo wrote:
> I've reviewed the docs briefly but didn't find this information.
>
> I'm playing with a XC3S400 in a 256 BGA on the Digilent board. If I were to
> use all the available I/O pins to drive LEDs (that's 104 of them), and do
> something silly like turn 'em all on at once, will I exceed the maximum
> current draw of the chip and let out the magic smoke?
>
> The eight red LED's on the board are driven directly from the I/O pins
> through 390 ohm resistors.
>
> I am planning on attaching a green LED to each of the 96 I/O pins exposed on
> the connectors through 390 ohm resistors.
>
> Thx,
>
> -Nevo

Peter,

Where did the 1A maximum come from? That's the figure I couldn't find in my
quick look at the datasheet.

Thanks!

-Nevo

"Peter Alfke" <[email protected]> wrote in message
news:[email protected] ups.com...
> Do your homework:
> Build one such interface, then measure the supply voltage and the
> voltage on either side of the 390 Ohm resistor. Use simple math to
> clculate the current, and also the power dissipation inside the chip,
> for this one instant. Then multiply the power by 96.
> I am quite sure that the current will be below 1 A, and thus no
> problem. But you might think about the on-chip power dissipation.
> All you need is a multimeter and high-school math.
> Peter Alfke
> ========================
> Nevo wrote:
>> I've reviewed the docs briefly but didn't find this information.
>>
>> I'm playing with a XC3S400 in a 256 BGA on the Digilent board. If I were
>> to
>> use all the available I/O pins to drive LEDs (that's 104 of them), and do
>> something silly like turn 'em all on at once, will I exceed the maximum
>> current draw of the chip and let out the magic smoke?
>>
>> The eight red LED's on the board are driven directly from the I/O pins
>> through 390 ohm resistors.
>>
>> I am planning on attaching a green LED to each of the 96 I/O pins exposed
>> on
>> the connectors through 390 ohm resistors.
>>
>> Thx,
>>
>> -Nevo
>

There is no max Icc spec. But I find 1 A acceptable, since we often see
3 W power dissipation...
I think there is a (very conservative) spec that wants to keep the
current per pin below 10 mA (I think 20 to 30 mA is fine), and it looks
like all that is not really your problem.
Peter Alfke, Xilinx Applications (from home)
===================================
Nevo wrote:
> Peter,
>
> Where did the 1A maximum come from? That's the figure I couldn't find in my
> quick look at the datasheet.
>
> Thanks!
>
> -Nevo
>
> "Peter Alfke" <[email protected]> wrote in message
> news:[email protected] ups.com...
> > Do your homework:
> > Build one such interface, then measure the supply voltage and the
> > voltage on either side of the 390 Ohm resistor. Use simple math to
> > clculate the current, and also the power dissipation inside the chip,
> > for this one instant. Then multiply the power by 96.
> > I am quite sure that the current will be below 1 A, and thus no
> > problem. But you might think about the on-chip power dissipation.
> > All you need is a multimeter and high-school math.
> > Peter Alfke
> > ========================
> > Nevo wrote:
> >> I've reviewed the docs briefly but didn't find this information.
> >>
> >> I'm playing with a XC3S400 in a 256 BGA on the Digilent board. If I were
> >> to
> >> use all the available I/O pins to drive LEDs (that's 104 of them), and do
> >> something silly like turn 'em all on at once, will I exceed the maximum
> >> current draw of the chip and let out the magic smoke?
> >>
> >> The eight red LED's on the board are driven directly from the I/O pins
> >> through 390 ohm resistors.
> >>
> >> I am planning on attaching a green LED to each of the 96 I/O pins exposed
> >> on
> >> the connectors through 390 ohm resistors.
> >>
> >> Thx,
> >>
> >> -Nevo
> >

Peter .. he WAS doing his homework, and forced to ask the list because
XILINX continues to refuse to specify the part completely. Your
"process" for determining this does NOT provide the answer for other
than ONE part, at ONE voltage, at ONE temperature. The process does NOT
provide any clue about how the next 1 million parts will perform, nor
does it provide a defective screening limit to return high current
parts that are well outside of specification (which XILINX refuses to
provide).

Your answer to this poster, isn't any better than the XILINX answer to
mine last winter.

John

Peter Alfke wrote:
> Do your homework:
> Build one such interface, then measure the supply voltage and the
> voltage on either side of the 390 Ohm resistor. Use simple math to
> clculate the current, and also the power dissipation inside the chip,
> for this one instant. Then multiply the power by 96.
> I am quite sure that the current will be below 1 A, and thus no
> problem. But you might think about the on-chip power dissipation.
> All you need is a multimeter and high-school math.
> Peter Alfke
> ========================
> Nevo wrote:
> > I've reviewed the docs briefly but didn't find this information.
> >
> > I'm playing with a XC3S400 in a 256 BGA on the Digilent board. If I were to
> > use all the available I/O pins to drive LEDs (that's 104 of them), and do
> > something silly like turn 'em all on at once, will I exceed the maximum
> > current draw of the chip and let out the magic smoke?
> >
> > The eight red LED's on the board are driven directly from the I/O pins
> > through 390 ohm resistors.
> >
> > I am planning on attaching a green LED to each of the 96 I/O pins exposed on
> > the connectors through 390 ohm resistors.
> >
> > Thx,
> >
> > -Nevo

[email protected] wrote:

> Peter .. he WAS doing his homework, and forced to ask the list because
> XILINX continues to refuse to specify the part completely. Your
> "process" for determining this does NOT provide the answer for other
> than ONE part, at ONE voltage, at ONE temperature. The process does NOT
> provide any clue about how the next 1 million parts will perform, nor
> does it provide a defective screening limit to return high current
> parts that are well outside of specification (which XILINX refuses to
> provide).
>
> Your answer to this poster, isn't any better than the XILINX answer to
> mine last winter.

To give this a reference point, here is an example from over the
fence, of a Philips data sheet :

http://www.standardics.philips.com/p...df/pca9506.pdf

Notice they specify:
Maximum power
Maximum current per pin
Idd Max
Gnd Max
Total Iol, recommended
and Vol Mins, for Vcc and Temp limits

This device is a LED driver, and yes, that is the level of spec a
designer could reasonably expect to find in a data sheet, when designing
for LED drive usage.

-jg

"Nevo" <[email protected]> wrote:

>I've reviewed the docs briefly but didn't find this information.

They specify a maximum current of 24mA sink/source per pin. For 96
pins, this would add up to 2.3 A.

--
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl

Nico Coesel wrote:
> "Nevo" <[email protected]> wrote:
>
> >I've reviewed the docs briefly but didn't find this information.
>
> They specify a maximum current of 24mA sink/source per pin. For 96
> pins, this would add up to 2.3 A.
>
> --
> Reply to nico@nctdevpuntnl (punt=.)
> Bedrijven en winkels vindt U op www.adresboekje.nl

For the OP question, assuming 3.3V I/O power and a typical forward
voltage on the LED of 2V, then the total current into the device is
about 320mA (3.33mA per pin) which should be fine.

Note that LED forward voltage varies quite a lot - at low currents it
may be as low as 1.5V (for some devices). That would add about 50% to
the total, to ~450mA total. Without knowing the exact device it's hard
to be really specific.

I second the comment about incomplete specs - in this particular case,
I don't think the OP has anything to worry about though.

Cheers

PeteS

"Nevo" <[email protected]> wrote in message
news:uOvDg.5670$zc2.3643@trnddc06...
> I've reviewed the docs briefly but didn't find this information.
>
> I'm playing with a XC3S400 in a 256 BGA on the Digilent board. If I were
> to use all the available I/O pins to drive LEDs (that's 104 of them), and
> do something silly like turn 'em all on at once, will I exceed the maximum
> current draw of the chip and let out the magic smoke?
>
> The eight red LED's on the board are driven directly from the I/O pins
> through 390 ohm resistors.
>
> I am planning on attaching a green LED to each of the 96 I/O pins exposed
> on the connectors through 390 ohm resistors.
>
> Thx,
>
> -Nevo
>

That's a really naff way of driving LED's.

Instead drive them from the FPGA IO configured as open collector (ie
tristate with the tristate buffer input connected to ground, and the
tristate control as your input. Then connect the LED to the IO, supplying
the other end of the LED via a resistor to your supply.

That way you considerably reduce the FPGA power dissipation to that of the
saturated output drivers - the bulk of the power being dissipated in the
external resistors.

Slurp

"Slurp" <[email protected]> wrote:

>
>"Nevo" <[email protected]> wrote in message
>news:uOvDg.5670$zc2.3643@trnddc06...
>> I've reviewed the docs briefly but didn't find this information.
>>
>> I'm playing with a XC3S400 in a 256 BGA on the Digilent board. If I were
>> to use all the available I/O pins to drive LEDs (that's 104 of them), and
>> do something silly like turn 'em all on at once, will I exceed the maximum
>> current draw of the chip and let out the magic smoke?
>>
>> The eight red LED's on the board are driven directly from the I/O pins
>> through 390 ohm resistors.
>>
>> I am planning on attaching a green LED to each of the 96 I/O pins exposed
>> on the connectors through 390 ohm resistors.
>>
>> Thx,
>>
>> -Nevo
>>
>
>That's a really naff way of driving LED's.
>
>Instead drive them from the FPGA IO configured as open collector (ie
>tristate with the tristate buffer input connected to ground, and the
>tristate control as your input. Then connect the LED to the IO, supplying
>the other end of the LED via a resistor to your supply.
>
>That way you considerably reduce the FPGA power dissipation to that of the
>saturated output drivers - the bulk of the power being dissipated in the
>external resistors.

Xilinx FPGAs (like almost all digital CMOS devices) have complementary
push/pull output stages. It doesn't matter whether you sink or source
current, the output stage will be saturated in either case unless the
programmed output current is exceeded.

If an FPGA is used, I think it is easy to connect the LEDs in a matrix
and deploy a nifty multiplexing scheme.

--
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl

Nico Coesel wrote:
> "Slurp" <[email protected]> wrote:
>
> >
> >"Nevo" <[email protected]> wrote in message
> >news:uOvDg.5670$zc2.3643@trnddc06...
> >> I've reviewed the docs briefly but didn't find this information.
> >>
> >> I'm playing with a XC3S400 in a 256 BGA on the Digilent board. If I were
> >> to use all the available I/O pins to drive LEDs (that's 104 of them), and
> >> do something silly like turn 'em all on at once, will I exceed the maximum
> >> current draw of the chip and let out the magic smoke?
> >>
> >> The eight red LED's on the board are driven directly from the I/O pins
> >> through 390 ohm resistors.
> >>
> >> I am planning on attaching a green LED to each of the 96 I/O pins exposed
> >> on the connectors through 390 ohm resistors.
> >>
> >> Thx,
> >>
> >> -Nevo
> >>
> >
> >That's a really naff way of driving LED's.
> >
> >Instead drive them from the FPGA IO configured as open collector (ie
> >tristate with the tristate buffer input connected to ground, and the
> >tristate control as your input. Then connect the LED to the IO, supplying
> >the other end of the LED via a resistor to your supply.
> >
> >That way you considerably reduce the FPGA power dissipation to that of the
> >saturated output drivers - the bulk of the power being dissipated in the
> >external resistors.
>
> Xilinx FPGAs (like almost all digital CMOS devices) have complementary
> push/pull output stages. It doesn't matter whether you sink or source
> current, the output stage will be saturated in either case unless the
> programmed output current is exceeded.
>
> If an FPGA is used, I think it is easy to connect the LEDs in a matrix
> and deploy a nifty multiplexing scheme.
>
> --
> Reply to nico@nctdevpuntnl (punt=.)
> Bedrijven en winkels vindt U op www.adresboekje.nl

The OP is driving the LEDs with about 2.5 - 3.3 mA. That's not very
bright in the first place, so any multiplexing scheme would need to
change the resistors.

That said, doing it by multiplexing (driving with about 15mA pulses for
example) would minimize multi-pin currents.

Cheers

PeteS

Nevo wrote:

> I've reviewed the docs briefly but didn't find this information.
>
> I'm playing with a XC3S400 in a 256 BGA on the Digilent board. If I were to
> use all the available I/O pins to drive LEDs (that's 104 of them), and do
> something silly like turn 'em all on at once, will I exceed the maximum
> current draw of the chip and let out the magic smoke?
>
> The eight red LED's on the board are driven directly from the I/O pins
> through 390 ohm resistors.
>
> I am planning on attaching a green LED to each of the 96 I/O pins exposed on
> the connectors through 390 ohm resistors.

LEDs do not need 20mA, in most cases, 1mA is
clearly visible.

Rene
--
Ing.Buero R.Tschaggelar - http://www.ibrtses.com
& commercial newsgroups - http://www.talkto.net

"PeteS" <[email protected]> wrote:

>Nico Coesel wrote:
>> "Slurp" <[email protected]> wrote:
>>
>> >
>> >"Nevo" <[email protected]> wrote in message
>> >news:uOvDg.5670$zc2.3643@trnddc06...
>> >> I've reviewed the docs briefly but didn't find this information.
>> >>
>> >> I'm playing with a XC3S400 in a 256 BGA on the Digilent board. If I were
>> >> to use all the available I/O pins to drive LEDs (that's 104 of them), and
>> >> do something silly like turn 'em all on at once, will I exceed the maximum
>> >> current draw of the chip and let out the magic smoke?
>> >>
>> >> The eight red LED's on the board are driven directly from the I/O pins
>> >> through 390 ohm resistors.
>> >>
>> >> I am planning on attaching a green LED to each of the 96 I/O pins exposed
>> >> on the connectors through 390 ohm resistors.
>> >>
>> >> Thx,
>> >>
>> >> -Nevo
>> >>
>> >
>> >That's a really naff way of driving LED's.
>> >
>> >Instead drive them from the FPGA IO configured as open collector (ie
>> >tristate with the tristate buffer input connected to ground, and the
>> >tristate control as your input. Then connect the LED to the IO, supplying
>> >the other end of the LED via a resistor to your supply.
>> >
>> >That way you considerably reduce the FPGA power dissipation to that of the
>> >saturated output drivers - the bulk of the power being dissipated in the
>> >external resistors.
>>
>> Xilinx FPGAs (like almost all digital CMOS devices) have complementary
>> push/pull output stages. It doesn't matter whether you sink or source
>> current, the output stage will be saturated in either case unless the
>> programmed output current is exceeded.
>>
>> If an FPGA is used, I think it is easy to connect the LEDs in a matrix
>> and deploy a nifty multiplexing scheme.
>>
>> --
>> Reply to nico@nctdevpuntnl (punt=.)
>> Bedrijven en winkels vindt U op www.adresboekje.nl
>
>The OP is driving the LEDs with about 2.5 - 3.3 mA. That's not very
>bright in the first place, so any multiplexing scheme would need to
>change the resistors.
>
>That said, doing it by multiplexing (driving with about 15mA pulses for
>example) would minimize multi-pin currents.

With multiplexing, the OP could do without resistor and use DCI or
current limiting in the FPGA. Saves a whole bunch of resistor. DCI
would be nice because the current can be adjusted by an 1 resistor (or
potmeter).

--
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl

It seems like everybody agrees that this is not a problem.
But there remains the complaint about "missing specs".
Obviously, a dedicated LED driver should specify the current per pin,
and also total. That device has little else to spec.
An FPGA has already thousands of other, more important specifications.

So we do not specify max current per pin.
There are two limitations: power and metal migration.
For a given current, the power depends on the voltage drop, and it
depends on the strength of the output, and that is programmable. This
would make the spec very complicated.
Moreover, power per individual pin is not so important, since silicon
is such a good thermal conductor.
The other constraint is metal migration, which has become better since
we now use Cu instead of Al in the metallization. 40 mA is tolerable
"forever".
The real limitation is the junction temperature, which depends on total
device power consumption in conjunction with the thermal resistance.
And we specify this exhaustively.

In short:
Don't worry about the current (if it is below 40 mA per pin
continuously).
Instead, worry about the junction temperature.
And Xilinx gives you lots of data to figure that out.

Peter Alfke, Xilinx Applications (from home)
=====================
Rene Tschaggelar wrote:
> Nevo wrote:
>
> > I've reviewed the docs briefly but didn't find this information.
> >
> > I'm playing with a XC3S400 in a 256 BGA on the Digilent board. If I were to
> > use all the available I/O pins to drive LEDs (that's 104 of them), and do
> > something silly like turn 'em all on at once, will I exceed the maximum
> > current draw of the chip and let out the magic smoke?
> >
> > The eight red LED's on the board are driven directly from the I/O pins
> > through 390 ohm resistors.
> >
> > I am planning on attaching a green LED to each of the 96 I/O pins exposed on
> > the connectors through 390 ohm resistors.
>
> LEDs do not need 20mA, in most cases, 1mA is
> clearly visible.
>
> Rene
> --
> Ing.Buero R.Tschaggelar - http://www.ibrtses.com
> & commercial newsgroups - http://www.talkto.net

Nevo,

Answers in line, below,

Austin

Nevo wrote:
> I've reviewed the docs briefly but didn't find this information.
>
> I'm playing with a XC3S400 in a 256 BGA on the Digilent board. If I were to
> use all the available I/O pins to drive LEDs (that's 104 of them), and do
> something silly like turn 'em all on at once, will I exceed the maximum
> current draw of the chip and let out the magic smoke?

Two specifications here you must observe: absolute maximum junction
temperature, and IO pin absolute maximum voltages. For what you
describe, this being a transient, firstly, the IOs remain tristate until
your design has control over them, so as long as YOU do not turn them
all on at once, your question is even simpler to answer: nothing
happens. No problem.

If you do turn them all on at once, then you would have to leave them ON
until the junction temperature went nuts (assuming you had no heatsink
or airflow, and your power supply had the current). That is the ONLY
way to damage the device from what you have so far described.

> The eight red LED's on the board are driven directly from the I/O pins
> through 390 ohm resistors.

OK. What strenth setting are you placing on the IO driver? If the
strength chosen is something like LVCMOS 24 mA, then the IR drop on the
driver is very small, and there is practically no power developed in the
device, and you really have nothing to worry about.

But, if you chose the weakest driver, then the driver dissipates power,
and the device will get hotter. As long as you stay below the abs max
temp, no damage.

I would choose the weakest and slowest driver, just for the signal
integrity issues, but I would watch that the internal power stayed
within my overall package power dissipation budget.

> I am planning on attaching a green LED to each of the 96 I/O pins exposed on
> the connectors through 390 ohm resistors.

And this is important, why? Seems to me how they are wired has nothing
to do with your question. My personal preference are those blue leds,
they are much ***ier than red, yellow, or green.


The IOB is incredibly robust: after all the PCI and GTP+ IO standards
specify currents of 45 mA to 70 mA being there forever, so we had to
design it to take that. The number Peter mentions of 10 mA is when you
force the pin to go below ground, or above Vcco, as then you are forward
biasing the IO device diodes, either pumping electrons into the
substrate, or pushing them into the Vcco rail. 10 mA is there as a
guideline. We certainly still need to observe the abs max specs, even
then, for device temperature, and pin and supply voltages.

Perhaps the specification is too simple, as we allow you to do many
bizarre things (which may not be very useful, but they will not cause
any damage, or reduce the device lifetime).

Perhaps you are not usd to FPGA design, where you have to have many
choices, and are in complete control? Our specification is written to
allow you to do whatever it is you desire.

In fact, the more specifications we add to the data sheet, the less
useful the device is, and the more business we potentially lose. A case
where more is not better, and less is ideal. In fact, even less abs max
would be even better (we only place a specification there when we know
it will affect reliability).

After all, we are a FPGA, and you decide what it will do, not us. As
long as it works, and is within the abs max specs, it won't hurt the device.

>So we do not specify max current per pin.
>There are two limitations: power and metal migration.
>For a given current, the power depends on the voltage drop, and it
>depends on the strength of the output, and that is programmable. This
>would make the spec very complicated.
>Moreover, power per individual pin is not so important, since silicon
>is such a good thermal conductor.
>The other constraint is metal migration, which has become better since
>we now use Cu instead of Al in the metallization. 40 mA is tolerable
>"forever".

What's the corresponding mA value for Al .. ?

Despite copper being a better conductor,

It is all nonsense, as the copper interconnect is thinner, and requires
a barrier material (making the conductor even more thin).

Like I said in my posting:

If PCI and GTL require 45 mA nd ~ 70 mA forever, you can bet that the IC
designers made sure that all associated connections were designed to
meet the worst possible case currents, flowing there.

Austin

[email protected]d wrote:
>> So we do not specify max current per pin.
>> There are two limitations: power and metal migration.
>> For a given current, the power depends on the voltage drop, and it
>> depends on the strength of the output, and that is programmable. This
>> would make the spec very complicated.
>> Moreover, power per individual pin is not so important, since silicon
>> is such a good thermal conductor.
>> The other constraint is metal migration, which has become better since
>> we now use Cu instead of Al in the metallization. 40 mA is tolerable
>> "forever".
>
> What's the corresponding mA value for Al .. ?
>

Austin Lesea <[email protected]> wrote:

>Perhaps the specification is too simple, as we allow you to do many
>bizarre things (which may not be very useful, but they will not cause
>any damage, or reduce the device lifetime).
>
>Perhaps you are not usd to FPGA design, where you have to have many
>choices, and are in complete control? Our specification is written to
>allow you to do whatever it is you desire.
>
>In fact, the more specifications we add to the data sheet, the less
>useful the device is, and the more business we potentially lose. A case
>where more is not better, and less is ideal. In fact, even less abs max
>would be even better (we only place a specification there when we know
>it will affect reliability).

Sorry, but I'm finding this statement a total disregard towards
Xilinx's customers. Because Xilinx's datasheets lack important
information on how the IOB are grouped together and the clock
distribution limits resulting from that grouping, I have to do an
extensive re-design of a PCB. The only way to find out about severe
limitations in a Xilinx is by bumping your head at least once for each
limitation. Some may call that learning, I call it wasting customer's
time and money. May I introduce the term 'sales droid approved
datasheets'?

So don't give me crap about 'less is better'. Less simply means too
little. If you are afraid to lose business, have a simple datasheet
and an extensive datasheet. Designers that want to push parts to the
edge without hassle really need the latter.

--
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl

Nico Coesel wrote:

> So don't give me crap about 'less is better'. Less simply means too
> little. If you are afraid to lose business, have a simple datasheet
> and an extensive datasheet. Designers that want to push parts to the
> edge without hassle really need the latter.


Amen ...

Nico,

You posted:

"
datasheets lack important information on how the IOB are grouped
together and the clock distribution limits resulting from that
grouping
"

Could you be more specific? What is it that you found to be missing?
Which part? Which package? What 'important information'? We spend
quite a bit of time on the IO specifications, I would like to understand
better what you felt is missing.

Thank you,

Austin

Austin Lesea wrote:
> Nico,
>
> You posted:
>
> "
> datasheets lack important information on how the IOB are grouped
> together and the clock distribution limits resulting from that
> grouping
> "
>
> Could you be more specific? What is it that you found to be missing?
> Which part? Which package? What 'important information'? We spend
> quite a bit of time on the IO specifications, I would like to understand
> better what you felt is missing.
>
> Thank you,
>
> Austin

Well, as a user of these parts, I'll give you a few

[Relates to all packages I have ever used]

1. What is the maximum ICC of a particular Vcco? This relates directly
to block I/O Pd.

2. What *is* the maximum power dissipation of a particular I/O block?
I/O blocks are at the edge; as such they have their own power / heat
issues. Knowing what the maximums are would help. You could spec max
temp, provided you **thoroughly** specified the I/O block so I could
calculate it based on speed, incidentally.

3. What is the thermal distribution profile? There is core, and there
is I/O. Each has their own effect on the die, but it may well be
important to me to know that profile (it has been in the past).

4. What is the thermal profile of the Clock managers? When things get
fast, they also get hot. I need to know the power dissipation of a DCM
based on inputs and outputs.

I am sure others will drop their comments in

Cheers

PeteS

PeteS, let me give you a few answers:
PeteS wrote:

> 1. What is the maximum ICC of a particular Vcco? This relates directly
> to block I/O Pd.
i suppose you mean the maximum allowed Icc, an absolute max
specification.
>
> 2. What *is* the maximum power dissipation of a particular I/O block?
> I/O blocks are at the edge;
In Virtex-4 and all future Virtex parts, the I/O is no longer at the
periphery
> as such they have their own power / heat
> issues. Knowing what the maximums are would help. You could spec max
> temp, provided you **thoroughly** specified the I/O block so I could
> calculate it based on speed,
speed, strength, voltage, output loading, dc and capacitive....
>
> 3. What is the thermal distribution profile? There is core, and there
> is I/O. Each has their own effect on the die, but it may well be
> important to me to know that profile (it has been in the past).
I personally think that this is a secondary effect, given the thermal
properties of silicon. Just my opinion.
>
> 4. What is the thermal profile of the Clock managers? When things get
> fast, they also get hot. I need to know the power dissipation of a DCM
> based on inputs and outputs.
Same as above.
>
> I am sure others will drop their comments in
They are welcome. But let's keep the tone civilized.
Peter Alfke

Ask, and ye shall ...

See below,

Austin

-snip-

> 1. What is the maximum ICC of a particular Vcco? This relates directly
> to block I/O Pd.

What standard? What load?

Perhaps you do not have a signal integrity simultion tool?

Or Hspice? Since it is YOUR problem, all we can do is provide with the
tools to answer it.

We provide the IBIS and spice models you need to do this.

> 2. What *is* the maximum power dissipation of a particular I/O block?
> I/O blocks are at the edge; as such they have their own power / heat
> issues. Knowing what the maximums are would help. You could spec max
> temp, provided you **thoroughly** specified the I/O block so I could
> calculate it based on speed, incidentally.

What standard? What load? See answer above.

By the way, some devices have IOBs in the interior (all V4 and V5).

> 3. What is the thermal distribution profile? There is core, and there
> is I/O. Each has their own effect on the die, but it may well be
> important to me to know that profile (it has been in the past).

Are you concerned about thermal gradient? Don't be: we do that
engineering so you do not have to. Worry about maximum power
dissipation and Tj. There are estimation tools, and finally, better
tools to figure power (XPower) but it requires you to have good
simulation vectors (just like you would if you had the same ASIC
estimation requirement).

> 4. What is the thermal profile of the Clock managers? When things get
> fast, they also get hot. I need to know the power dissipation of a DCM
> based on inputs and outputs.

Nope. You do not. We do the hard part, so you do not have to.

If you feel like designing ASICs, go get a job doing that. I am not
stopping you. If you want to design FPGAs, submit a resume (we are hiring).

hi

seems like you problems would be solved if only LED manufactures made
surface mount LET.

= Light Emitting Transistor

not impossible, an would only draw a base current much less than
collectoer current. would be three pin and more complex production, but
would save on possible buffers.

the output dive on the fpga is limited by current heating, which is not
that high in the off or on states, but high capacitance led would
dissipate large Watts in output of fpga.

second factor is resistive loss in bond wires, have to be of a certain
size to fit so many on the chip. maybe vcc drops on chip due to heat
and cannot switch as fast reliably, so try a lower speed operation?

pulse the led output at 20% mark to 80% space as you will not notice
too much above 100Hz and save power too.

use high efficiency led, as i understand they are less than 10%
efficient anyhow.

wire half the other way with 0 = on instead of 1 = on to distribute
power drain between + and - rails.

cheers

http://indi.joox.net

OFSIC in design, at documentation interface stage. then we shall move
onto code.

i am in the market for employment.

london area, min 500 uk pound per wk. pro rata 40 hrs.

parttime prefered, about 20hrs per wk.

can only telework if get full time internet, and rented place.

c.v. e.g. http://indi.joox.net

cheers