adding FPGA grounds...

[Ed Lee]

On Sunday, October 11, 2020 at 10:47:56 PM UTC-7, Ricketty C wrote:

On Monday, October 12, 2020 at 1:10:01 AM UTC-4, Ed Lee wrote:
On Sunday, October 11, 2020 at 10:03:19 PM UTC-7, Ricketty C wrote:
On Monday, October 12, 2020 at 12:23:56 AM UTC-4, Ed Lee wrote:
On Sunday, October 11, 2020 at 8:51:56 PM UTC-7, jla...@highlandsniptechnology.com wrote:
On Sun, 11 Oct 2020 17:46:33 -0700 (PDT), Lasse Langwadt Christensen
lang...@fonz.dk> wrote:

mandag den 12. oktober 2020 kl. 02.27.18 UTC+2 skrev Ed Lee:
On Sunday, October 11, 2020 at 5:20:51 PM UTC-7, lang...@fonz.dk wrote:
mandag den 12. oktober 2020 kl. 02.14.50 UTC+2 skrev Ed Lee:
On Sunday, October 11, 2020 at 4:31:48 PM UTC-7, lang...@fonz.dk wrote:
mandag den 12. oktober 2020 kl. 01.17.12 UTC+2 skrev jla....@highlandsniptechnology.com:
One of my guys is suggesting that we ground unused balls on an FPGA
and compile them to be low outputs, the idea being to reduce ground
impedance and add some damping.

Has anyone done this? Does it help?

I guess I could have an input that controls the tri-states of all such
pins, and also bring out one logic-low to scope, and turn the grounds
on and off and see if it makes any difference.

It\'s an XC7A15T-1FTG256C with 30 ground pins. We could add at least
another 30 fake grounds.

It was recommended on some older xilinx CPLDs, but I think the general
consensus is that it doesn\'t make much difference on modern BGA FPGAs

The compiler should be smart enough to do what\'s best for unused pins.
default is pulldown because it safe no matter what it is connected to,
the tools don\'t know what you connect the pins to on the pcb

if if unused pins are connected to a plane it might help with cooling

Unused pins are likely disconnected from the rest of the fabric; so, probably not much difference.
thermally disconnected ??

If not electrically conductive, it\'s also less thermally conductive.

the thermal resistance of a mosfet depends on whether it on or off??
I\'m sure it does, at some parts per million or billion. That would
make a good grad thesis. Charge mobility and such.


I would just let the compiler decide, unless they explicitly stated otherwise in the spec.
the tools doesn\'t know what the pins are connected to it has to pick something safe

The drivers are likely deactivated, so it\'s doesn\'t matter where it\'s connected to.

yes, when they are not activated it doesn\'t matter so the tools have to keep them deactivated, it cannot assume unused pins are connected to ground and turn them on as extra grounds even if it would be an advantage



We can surely force a bunch of pins to be hard low.

Sometimes, not in this case, a compiler will optimize out stuff that
we want. One trick is to have an input pin influence a lot of logic. I
can hardwire that pin high or low, but the compiler doesn\'t know that
so it can\'t optimize my stuff away.

I bet you could build a state machine that winds to making a hard \"1\"
to accomplish the same thing, but is complex enough that the compiler
doesn\'t realize it.

I was just questioning the effectiveness of using additional cells for cooling. Especially with output buffer cells, heat transfer to pin/pad is much higher than to any other cells. With smaller geometry, interconnections are getting smaller, but the buffer cells need to be relatively bigger to maintain the current capacity. If anything, you can try to space out cells as much as possible, but i doubt you can do any better than the compiler.

You are disputing an idea no one has suggested.

The original suggestion was to compile it low and ground it for cooling, perhaps.
I don\'t think anyone said that. The suggestion was simply \"if unused pins are connected to a plane it might help with cooling\"

Then the suggestion of thermal issues with the mosfet:
>
\"> Unused pins are likely disconnected from the rest of the fabric; so, probably not much difference.
thermally disconnected ??
> If not electrically conductive, it\'s also less thermally conductive.

the thermal resistance of a mosfet depends on whether it on or off??\"

It implies thermal transfer between cells, using mosfet. So, it\'s more than just the physical pads.

As Lasse has said, the issue is not about the electrical connection and so not about \"cells\" on the chip. The issue is the thermal connection between the board and the chip through the balls.

So is just adding more solder to the PCB pads, or making bigger pads.
Again, you seem to not understand the nature of the issue. All pads have the same solder balls. The pads on the PCB can be thermally connected to power planes that spread the heat across the board helping to lower the thetaJA. It is hard to make pads any bigger. The issue is providing either a via in pad or a via with a WIDE dog bone (more of a football) to the adjacent via or vias. In fact, if adjacent pins are picked, they can be \"pooled\" and connected to one another (as well as any pins on the same power rail) with all vias in the area connecting the common copper to the same power plane. This would provide the best cooling in aggregate. I guess you could call this a \"wide\" pad.
Provide a hard thermal connection to the power plane to the ball and you will get some additional cooling.

That will only cool the cell you turn on for cooling, not much for other cells.
It has NOTHING to do with \"cells\" or how they are electrically configured.. NOTHING The balls are just connections between two PCBs. The chip is connected to one PCB and traces and vias in that PCB connect the chip I/Os to the balls on the other side of that PCB which are then soldered to the PCB you design. No good thermal connection is made over the rather thin traces inside the BGA package. The heat is conducted through the substrate to the balls.

BTW, some BGAs using bond wires and others use a flip chip which solders directly to the internal PCB. Take a look at this page with good illustrations.

Gold wires or copper traces are huge, compared to the nm interconnecting fabric.

 

[Ricketty C]

On Monday, October 12, 2020 at 1:59:08 AM UTC-4, Ed Lee wrote:

On Sunday, October 11, 2020 at 10:47:56 PM UTC-7, Ricketty C wrote:
On Monday, October 12, 2020 at 1:10:01 AM UTC-4, Ed Lee wrote:
On Sunday, October 11, 2020 at 10:03:19 PM UTC-7, Ricketty C wrote:
On Monday, October 12, 2020 at 12:23:56 AM UTC-4, Ed Lee wrote:
On Sunday, October 11, 2020 at 8:51:56 PM UTC-7, jla...@highlandsniptechnology.com wrote:
On Sun, 11 Oct 2020 17:46:33 -0700 (PDT), Lasse Langwadt Christensen
lang...@fonz.dk> wrote:

mandag den 12. oktober 2020 kl. 02.27.18 UTC+2 skrev Ed Lee:
On Sunday, October 11, 2020 at 5:20:51 PM UTC-7, lang...@fonz.dk wrote:
mandag den 12. oktober 2020 kl. 02.14.50 UTC+2 skrev Ed Lee:
On Sunday, October 11, 2020 at 4:31:48 PM UTC-7, lang...@fonz.dk wrote:
mandag den 12. oktober 2020 kl. 01.17.12 UTC+2 skrev jla...@highlandsniptechnology.com:
One of my guys is suggesting that we ground unused balls on an FPGA
and compile them to be low outputs, the idea being to reduce ground
impedance and add some damping.

Has anyone done this? Does it help?

I guess I could have an input that controls the tri-states of all such
pins, and also bring out one logic-low to scope, and turn the grounds
on and off and see if it makes any difference.

It\'s an XC7A15T-1FTG256C with 30 ground pins. We could add at least
another 30 fake grounds.

It was recommended on some older xilinx CPLDs, but I think the general
consensus is that it doesn\'t make much difference on modern BGA FPGAs

The compiler should be smart enough to do what\'s best for unused pins.
default is pulldown because it safe no matter what it is connected to,
the tools don\'t know what you connect the pins to on the pcb

if if unused pins are connected to a plane it might help with cooling

Unused pins are likely disconnected from the rest of the fabric; so, probably not much difference.
thermally disconnected ??

If not electrically conductive, it\'s also less thermally conductive.

the thermal resistance of a mosfet depends on whether it on or off??
I\'m sure it does, at some parts per million or billion. That would
make a good grad thesis. Charge mobility and such.


I would just let the compiler decide, unless they explicitly stated otherwise in the spec.
the tools doesn\'t know what the pins are connected to it has to pick something safe

The drivers are likely deactivated, so it\'s doesn\'t matter where it\'s connected to.

yes, when they are not activated it doesn\'t matter so the tools have to keep them deactivated, it cannot assume unused pins are connected to ground and turn them on as extra grounds even if it would be an advantage



We can surely force a bunch of pins to be hard low.

Sometimes, not in this case, a compiler will optimize out stuff that
we want. One trick is to have an input pin influence a lot of logic. I
can hardwire that pin high or low, but the compiler doesn\'t know that
so it can\'t optimize my stuff away.

I bet you could build a state machine that winds to making a hard \"1\"
to accomplish the same thing, but is complex enough that the compiler
doesn\'t realize it.

I was just questioning the effectiveness of using additional cells for cooling. Especially with output buffer cells, heat transfer to pin/pad is much higher than to any other cells. With smaller geometry, interconnections are getting smaller, but the buffer cells need to be relatively bigger to maintain the current capacity. If anything, you can try to space out cells as much as possible, but i doubt you can do any better than the compiler.

You are disputing an idea no one has suggested.

The original suggestion was to compile it low and ground it for cooling, perhaps.
I don\'t think anyone said that. The suggestion was simply \"if unused pins are connected to a plane it might help with cooling\"

Then the suggestion of thermal issues with the mosfet:

\"> Unused pins are likely disconnected from the rest of the fabric; so, probably not much difference.
thermally disconnected ??
If not electrically conductive, it\'s also less thermally conductive.

the thermal resistance of a mosfet depends on whether it on or off??\"

It implies thermal transfer between cells, using mosfet. So, it\'s more than just the physical pads.

That was YOUR uninformed post spouting nonsense. The electrical connections are made by MOSFETS when turned on and have nothing to do with thermal conductivity.

As Lasse has said, the issue is not about the electrical connection and so not about \"cells\" on the chip. The issue is the thermal connection between the board and the chip through the balls.

So is just adding more solder to the PCB pads, or making bigger pads.
Again, you seem to not understand the nature of the issue. All pads have the same solder balls. The pads on the PCB can be thermally connected to power planes that spread the heat across the board helping to lower the thetaJA. It is hard to make pads any bigger. The issue is providing either a via in pad or a via with a WIDE dog bone (more of a football) to the adjacent via or vias. In fact, if adjacent pins are picked, they can be \"pooled\" and connected to one another (as well as any pins on the same power rail) with all vias in the area connecting the common copper to the same power plane. This would provide the best cooling in aggregate. I guess you could call this a \"wide\" pad.
Provide a hard thermal connection to the power plane to the ball and you will get some additional cooling.

That will only cool the cell you turn on for cooling, not much for other cells.
It has NOTHING to do with \"cells\" or how they are electrically configured. NOTHING The balls are just connections between two PCBs. The chip is connected to one PCB and traces and vias in that PCB connect the chip I/Os to the balls on the other side of that PCB which are then soldered to the PCB you design. No good thermal connection is made over the rather thin traces inside the BGA package. The heat is conducted through the substrate to the balls.

BTW, some BGAs using bond wires and others use a flip chip which solders directly to the internal PCB. Take a look at this page with good illustrations.

Gold wires or copper traces are huge, compared to the nm interconnecting fabric.

Which means nothing.

I\'m giving up on you. You literally seem to have no understanding of what is going on inside an IC.

--

Rick C.

--- Get 1,000 miles of free Supercharging
--- Tesla referral code - https://ts.la/richard11209

 

[Ed Lee]

On Sunday, October 11, 2020 at 11:15:08 PM UTC-7, Ricketty C wrote:

On Monday, October 12, 2020 at 1:59:08 AM UTC-4, Ed Lee wrote:
On Sunday, October 11, 2020 at 10:47:56 PM UTC-7, Ricketty C wrote:
On Monday, October 12, 2020 at 1:10:01 AM UTC-4, Ed Lee wrote:
On Sunday, October 11, 2020 at 10:03:19 PM UTC-7, Ricketty C wrote:
On Monday, October 12, 2020 at 12:23:56 AM UTC-4, Ed Lee wrote:
On Sunday, October 11, 2020 at 8:51:56 PM UTC-7, jla...@highlandsniptechnology.com wrote:
On Sun, 11 Oct 2020 17:46:33 -0700 (PDT), Lasse Langwadt Christensen
lang...@fonz.dk> wrote:

mandag den 12. oktober 2020 kl. 02.27.18 UTC+2 skrev Ed Lee:
On Sunday, October 11, 2020 at 5:20:51 PM UTC-7, lang...@fonz.dk wrote:
mandag den 12. oktober 2020 kl. 02.14.50 UTC+2 skrev Ed Lee:
On Sunday, October 11, 2020 at 4:31:48 PM UTC-7, lang....@fonz.dk wrote:
mandag den 12. oktober 2020 kl. 01.17.12 UTC+2 skrev jla...@highlandsniptechnology.com:
One of my guys is suggesting that we ground unused balls on an FPGA
and compile them to be low outputs, the idea being to reduce ground
impedance and add some damping.

Has anyone done this? Does it help?

I guess I could have an input that controls the tri-states of all such
pins, and also bring out one logic-low to scope, and turn the grounds
on and off and see if it makes any difference.

It\'s an XC7A15T-1FTG256C with 30 ground pins. We could add at least
another 30 fake grounds.

It was recommended on some older xilinx CPLDs, but I think the general
consensus is that it doesn\'t make much difference on modern BGA FPGAs

The compiler should be smart enough to do what\'s best for unused pins.
default is pulldown because it safe no matter what it is connected to,
the tools don\'t know what you connect the pins to on the pcb

if if unused pins are connected to a plane it might help with cooling

Unused pins are likely disconnected from the rest of the fabric; so, probably not much difference.
thermally disconnected ??

If not electrically conductive, it\'s also less thermally conductive.

the thermal resistance of a mosfet depends on whether it on or off??
I\'m sure it does, at some parts per million or billion. That would
make a good grad thesis. Charge mobility and such.


I would just let the compiler decide, unless they explicitly stated otherwise in the spec.
the tools doesn\'t know what the pins are connected to it has to pick something safe

The drivers are likely deactivated, so it\'s doesn\'t matter where it\'s connected to.

yes, when they are not activated it doesn\'t matter so the tools have to keep them deactivated, it cannot assume unused pins are connected to ground and turn them on as extra grounds even if it would be an advantage



We can surely force a bunch of pins to be hard low.

Sometimes, not in this case, a compiler will optimize out stuff that
we want. One trick is to have an input pin influence a lot of logic. I
can hardwire that pin high or low, but the compiler doesn\'t know that
so it can\'t optimize my stuff away.

I bet you could build a state machine that winds to making a hard \"1\"
to accomplish the same thing, but is complex enough that the compiler
doesn\'t realize it.

I was just questioning the effectiveness of using additional cells for cooling. Especially with output buffer cells, heat transfer to pin/pad is much higher than to any other cells. With smaller geometry, interconnections are getting smaller, but the buffer cells need to be relatively bigger to maintain the current capacity. If anything, you can try to space out cells as much as possible, but i doubt you can do any better than the compiler.

You are disputing an idea no one has suggested.

The original suggestion was to compile it low and ground it for cooling, perhaps.
I don\'t think anyone said that. The suggestion was simply \"if unused pins are connected to a plane it might help with cooling\"

Then the suggestion of thermal issues with the mosfet:

\"> Unused pins are likely disconnected from the rest of the fabric; so, probably not much difference.
thermally disconnected ??
If not electrically conductive, it\'s also less thermally conductive.

the thermal resistance of a mosfet depends on whether it on or off??\"

It implies thermal transfer between cells, using mosfet. So, it\'s more than just the physical pads.
That was YOUR uninformed post spouting nonsense. The electrical connections are made by MOSFETS when turned on and have nothing to do with thermal conductivity.
As Lasse has said, the issue is not about the electrical connection and so not about \"cells\" on the chip. The issue is the thermal connection between the board and the chip through the balls.

So is just adding more solder to the PCB pads, or making bigger pads.
Again, you seem to not understand the nature of the issue. All pads have the same solder balls. The pads on the PCB can be thermally connected to power planes that spread the heat across the board helping to lower the thetaJA. It is hard to make pads any bigger. The issue is providing either a via in pad or a via with a WIDE dog bone (more of a football) to the adjacent via or vias. In fact, if adjacent pins are picked, they can be \"pooled\" and connected to one another (as well as any pins on the same power rail) with all vias in the area connecting the common copper to the same power plane. This would provide the best cooling in aggregate. I guess you could call this a \"wide\" pad.
Provide a hard thermal connection to the power plane to the ball and you will get some additional cooling.

That will only cool the cell you turn on for cooling, not much for other cells.
It has NOTHING to do with \"cells\" or how they are electrically configured. NOTHING The balls are just connections between two PCBs. The chip is connected to one PCB and traces and vias in that PCB connect the chip I/Os to the balls on the other side of that PCB which are then soldered to the PCB you design. No good thermal connection is made over the rather thin traces inside the BGA package. The heat is conducted through the substrate to the balls.

BTW, some BGAs using bond wires and others use a flip chip which solders directly to the internal PCB. Take a look at this page with good illustrations.

Gold wires or copper traces are huge, compared to the nm interconnecting fabric.
Which means nothing.

What means the gold wires or copper traces of internal PCB conduct heat better than the interconnecting fabric.

> I\'m giving up on you. You literally seem to have no understanding of what is going on inside an IC.

Then inform us what\'s going on inside.

 

[Ricketty C]

On Monday, October 12, 2020 at 2:20:43 AM UTC-4, Ed Lee wrote:

On Sunday, October 11, 2020 at 11:15:08 PM UTC-7, Ricketty C wrote:
On Monday, October 12, 2020 at 1:59:08 AM UTC-4, Ed Lee wrote:
On Sunday, October 11, 2020 at 10:47:56 PM UTC-7, Ricketty C wrote:
On Monday, October 12, 2020 at 1:10:01 AM UTC-4, Ed Lee wrote:
On Sunday, October 11, 2020 at 10:03:19 PM UTC-7, Ricketty C wrote:
On Monday, October 12, 2020 at 12:23:56 AM UTC-4, Ed Lee wrote:
On Sunday, October 11, 2020 at 8:51:56 PM UTC-7, jla...@highlandsniptechnology.com wrote:
On Sun, 11 Oct 2020 17:46:33 -0700 (PDT), Lasse Langwadt Christensen
lang...@fonz.dk> wrote:

mandag den 12. oktober 2020 kl. 02.27.18 UTC+2 skrev Ed Lee:
On Sunday, October 11, 2020 at 5:20:51 PM UTC-7, lang...@fonz.dk wrote:
mandag den 12. oktober 2020 kl. 02.14.50 UTC+2 skrev Ed Lee:
On Sunday, October 11, 2020 at 4:31:48 PM UTC-7, lang...@fonz.dk wrote:
mandag den 12. oktober 2020 kl. 01.17.12 UTC+2 skrev jla...@highlandsniptechnology.com:
One of my guys is suggesting that we ground unused balls on an FPGA
and compile them to be low outputs, the idea being to reduce ground
impedance and add some damping.

Has anyone done this? Does it help?

I guess I could have an input that controls the tri-states of all such
pins, and also bring out one logic-low to scope, and turn the grounds
on and off and see if it makes any difference.

It\'s an XC7A15T-1FTG256C with 30 ground pins. We could add at least
another 30 fake grounds.

It was recommended on some older xilinx CPLDs, but I think the general
consensus is that it doesn\'t make much difference on modern BGA FPGAs

The compiler should be smart enough to do what\'s best for unused pins.
default is pulldown because it safe no matter what it is connected to,
the tools don\'t know what you connect the pins to on the pcb

if if unused pins are connected to a plane it might help with cooling

Unused pins are likely disconnected from the rest of the fabric; so, probably not much difference.
thermally disconnected ??

If not electrically conductive, it\'s also less thermally conductive.

the thermal resistance of a mosfet depends on whether it on or off??
I\'m sure it does, at some parts per million or billion. That would
make a good grad thesis. Charge mobility and such.


I would just let the compiler decide, unless they explicitly stated otherwise in the spec.
the tools doesn\'t know what the pins are connected to it has to pick something safe

The drivers are likely deactivated, so it\'s doesn\'t matter where it\'s connected to.

yes, when they are not activated it doesn\'t matter so the tools have to keep them deactivated, it cannot assume unused pins are connected to ground and turn them on as extra grounds even if it would be an advantage



We can surely force a bunch of pins to be hard low.

Sometimes, not in this case, a compiler will optimize out stuff that
we want. One trick is to have an input pin influence a lot of logic. I
can hardwire that pin high or low, but the compiler doesn\'t know that
so it can\'t optimize my stuff away.

I bet you could build a state machine that winds to making a hard \"1\"
to accomplish the same thing, but is complex enough that the compiler
doesn\'t realize it.

I was just questioning the effectiveness of using additional cells for cooling. Especially with output buffer cells, heat transfer to pin/pad is much higher than to any other cells. With smaller geometry, interconnections are getting smaller, but the buffer cells need to be relatively bigger to maintain the current capacity. If anything, you can try to space out cells as much as possible, but i doubt you can do any better than the compiler.

You are disputing an idea no one has suggested.

The original suggestion was to compile it low and ground it for cooling, perhaps.
I don\'t think anyone said that. The suggestion was simply \"if unused pins are connected to a plane it might help with cooling\"

Then the suggestion of thermal issues with the mosfet:

\"> Unused pins are likely disconnected from the rest of the fabric; so, probably not much difference.
thermally disconnected ??
If not electrically conductive, it\'s also less thermally conductive..

the thermal resistance of a mosfet depends on whether it on or off??\"

It implies thermal transfer between cells, using mosfet. So, it\'s more than just the physical pads.
That was YOUR uninformed post spouting nonsense. The electrical connections are made by MOSFETS when turned on and have nothing to do with thermal conductivity.
As Lasse has said, the issue is not about the electrical connection and so not about \"cells\" on the chip. The issue is the thermal connection between the board and the chip through the balls.

So is just adding more solder to the PCB pads, or making bigger pads.
Again, you seem to not understand the nature of the issue. All pads have the same solder balls. The pads on the PCB can be thermally connected to power planes that spread the heat across the board helping to lower the thetaJA. It is hard to make pads any bigger. The issue is providing either a via in pad or a via with a WIDE dog bone (more of a football) to the adjacent via or vias. In fact, if adjacent pins are picked, they can be \"pooled\" and connected to one another (as well as any pins on the same power rail) with all vias in the area connecting the common copper to the same power plane. This would provide the best cooling in aggregate. I guess you could call this a \"wide\" pad.
Provide a hard thermal connection to the power plane to the ball and you will get some additional cooling.

That will only cool the cell you turn on for cooling, not much for other cells.
It has NOTHING to do with \"cells\" or how they are electrically configured. NOTHING The balls are just connections between two PCBs. The chip is connected to one PCB and traces and vias in that PCB connect the chip I/Os to the balls on the other side of that PCB which are then soldered to the PCB you design. No good thermal connection is made over the rather thin traces inside the BGA package. The heat is conducted through the substrate to the balls.

BTW, some BGAs using bond wires and others use a flip chip which solders directly to the internal PCB. Take a look at this page with good illustrations.

Gold wires or copper traces are huge, compared to the nm interconnecting fabric.
Which means nothing.

What means the gold wires or copper traces of internal PCB conduct heat better than the interconnecting fabric.

I\'m giving up on you. You literally seem to have no understanding of what is going on inside an IC.

Then inform us what\'s going on inside.

I did and you make irrelevant comments. That is why I said you have no idea how a chip package conducts heat to the outside. It\'s not through the bond wires just as it is not through the copper traces. Do you understand what I said about the \"squares\"?

Instead of thinking of a wire as \"conducting\" think of it as a resistance. After all, everything is a resistance, it\'s just a question of how much. A wire with a lot of length relative to it\'s width will not conduct heat well from one end to another.

--

Rick C.

--+ Get 1,000 miles of free Supercharging
--+ Tesla referral code - https://ts.la/richard11209

 

[Uwe Bonnes]

In comp.arch.fpga jlarkin@highlandsniptechnology.com wrote:

One of my guys is suggesting that we ground unused balls on an FPGA
and compile them to be low outputs, the idea being to reduce ground
impedance and add some damping.

Has anyone done this? Does it help?

I guess I could have an input that controls the tri-states of all such
pins, and also bring out one logic-low to scope, and turn the grounds
on and off and see if it makes any difference.

It\'s an XC7A15T-1FTG256C with 30 ground pins. We could add at least
another 30 fake grounds.

If some Nvidia ^H^H^H^H^H Xilinx documents proposes, consider
it. Otherwise not!
--
Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 1623569 ------- Fax. 06151 1623305 ---------

 

[Ed Lee]

On Monday, October 12, 2020 at 12:48:56 AM UTC-7, Ricketty C wrote:

On Monday, October 12, 2020 at 2:20:43 AM UTC-4, Ed Lee wrote:
On Sunday, October 11, 2020 at 11:15:08 PM UTC-7, Ricketty C wrote:
On Monday, October 12, 2020 at 1:59:08 AM UTC-4, Ed Lee wrote:
On Sunday, October 11, 2020 at 10:47:56 PM UTC-7, Ricketty C wrote:
On Monday, October 12, 2020 at 1:10:01 AM UTC-4, Ed Lee wrote:
On Sunday, October 11, 2020 at 10:03:19 PM UTC-7, Ricketty C wrote:
On Monday, October 12, 2020 at 12:23:56 AM UTC-4, Ed Lee wrote:
On Sunday, October 11, 2020 at 8:51:56 PM UTC-7, jla...@highlandsniptechnology.com wrote:
On Sun, 11 Oct 2020 17:46:33 -0700 (PDT), Lasse Langwadt Christensen
lang...@fonz.dk> wrote:

mandag den 12. oktober 2020 kl. 02.27.18 UTC+2 skrev Ed Lee:
On Sunday, October 11, 2020 at 5:20:51 PM UTC-7, lang....@fonz.dk wrote:
mandag den 12. oktober 2020 kl. 02.14.50 UTC+2 skrev Ed Lee:
On Sunday, October 11, 2020 at 4:31:48 PM UTC-7, lang...@fonz.dk wrote:
mandag den 12. oktober 2020 kl. 01.17.12 UTC+2 skrev jla...@highlandsniptechnology.com:
One of my guys is suggesting that we ground unused balls on an FPGA
and compile them to be low outputs, the idea being to reduce ground
impedance and add some damping.

Has anyone done this? Does it help?

I guess I could have an input that controls the tri-states of all such
pins, and also bring out one logic-low to scope, and turn the grounds
on and off and see if it makes any difference.

It\'s an XC7A15T-1FTG256C with 30 ground pins. We could add at least
another 30 fake grounds.

It was recommended on some older xilinx CPLDs, but I think the general
consensus is that it doesn\'t make much difference on modern BGA FPGAs

The compiler should be smart enough to do what\'s best for unused pins.
default is pulldown because it safe no matter what it is connected to,
the tools don\'t know what you connect the pins to on the pcb

if if unused pins are connected to a plane it might help with cooling

Unused pins are likely disconnected from the rest of the fabric; so, probably not much difference.
thermally disconnected ??

If not electrically conductive, it\'s also less thermally conductive.

the thermal resistance of a mosfet depends on whether it on or off??
I\'m sure it does, at some parts per million or billion. That would
make a good grad thesis. Charge mobility and such.


I would just let the compiler decide, unless they explicitly stated otherwise in the spec.
the tools doesn\'t know what the pins are connected to it has to pick something safe

The drivers are likely deactivated, so it\'s doesn\'t matter where it\'s connected to.

yes, when they are not activated it doesn\'t matter so the tools have to keep them deactivated, it cannot assume unused pins are connected to ground and turn them on as extra grounds even if it would be an advantage



We can surely force a bunch of pins to be hard low.

Sometimes, not in this case, a compiler will optimize out stuff that
we want. One trick is to have an input pin influence a lot of logic. I
can hardwire that pin high or low, but the compiler doesn\'t know that
so it can\'t optimize my stuff away.

I bet you could build a state machine that winds to making a hard \"1\"
to accomplish the same thing, but is complex enough that the compiler
doesn\'t realize it.

I was just questioning the effectiveness of using additional cells for cooling. Especially with output buffer cells, heat transfer to pin/pad is much higher than to any other cells. With smaller geometry, interconnections are getting smaller, but the buffer cells need to be relatively bigger to maintain the current capacity. If anything, you can try to space out cells as much as possible, but i doubt you can do any better than the compiler.

You are disputing an idea no one has suggested.

The original suggestion was to compile it low and ground it for cooling, perhaps.
I don\'t think anyone said that. The suggestion was simply \"if unused pins are connected to a plane it might help with cooling\"

Then the suggestion of thermal issues with the mosfet:

\"> Unused pins are likely disconnected from the rest of the fabric; so, probably not much difference.
thermally disconnected ??
If not electrically conductive, it\'s also less thermally conductive.

the thermal resistance of a mosfet depends on whether it on or off??\"

It implies thermal transfer between cells, using mosfet. So, it\'s more than just the physical pads.
That was YOUR uninformed post spouting nonsense. The electrical connections are made by MOSFETS when turned on and have nothing to do with thermal conductivity.
As Lasse has said, the issue is not about the electrical connection and so not about \"cells\" on the chip. The issue is the thermal connection between the board and the chip through the balls.

So is just adding more solder to the PCB pads, or making bigger pads.
Again, you seem to not understand the nature of the issue. All pads have the same solder balls. The pads on the PCB can be thermally connected to power planes that spread the heat across the board helping to lower the thetaJA. It is hard to make pads any bigger. The issue is providing either a via in pad or a via with a WIDE dog bone (more of a football) to the adjacent via or vias. In fact, if adjacent pins are picked, they can be \"pooled\" and connected to one another (as well as any pins on the same power rail) with all vias in the area connecting the common copper to the same power plane. This would provide the best cooling in aggregate. I guess you could call this a \"wide\" pad.
Provide a hard thermal connection to the power plane to the ball and you will get some additional cooling.

That will only cool the cell you turn on for cooling, not much for other cells.
It has NOTHING to do with \"cells\" or how they are electrically configured. NOTHING The balls are just connections between two PCBs. The chip is connected to one PCB and traces and vias in that PCB connect the chip I/Os to the balls on the other side of that PCB which are then soldered to the PCB you design. No good thermal connection is made over the rather thin traces inside the BGA package. The heat is conducted through the substrate to the balls.

BTW, some BGAs using bond wires and others use a flip chip which solders directly to the internal PCB. Take a look at this page with good illustrations.

Gold wires or copper traces are huge, compared to the nm interconnecting fabric.
Which means nothing.

What means the gold wires or copper traces of internal PCB conduct heat better than the interconnecting fabric.

I\'m giving up on you. You literally seem to have no understanding of what is going on inside an IC.

Then inform us what\'s going on inside.
I did and you make irrelevant comments. That is why I said you have no idea how a chip package conducts heat to the outside. It\'s not through the bond wires just as it is not through the copper traces. Do you understand what I said about the \"squares\"?

Yes, copper pads, or big and width traces. Nothing through cell to cell interconnecting fabric.

 

[Klaus Kragelund]

On Monday, October 12, 2020 at 1:17:12 AM UTC+2, jla...@highlandsniptechnology.com wrote:

One of my guys is suggesting that we ground unused balls on an FPGA
and compile them to be low outputs, the idea being to reduce ground
impedance and add some damping.

Has anyone done this? Does it help?

I guess I could have an input that controls the tri-states of all such
pins, and also bring out one logic-low to scope, and turn the grounds
on and off and see if it makes any difference.

It\'s an XC7A15T-1FTG256C with 30 ground pins. We could add at least
another 30 fake grounds.


Won\'t there be a problem at startup, when the IOs are undefined? Then you may short an output to GND destroying the port.

We once did a thorough investigation into a microcontroller startup to clarify how the outputs would behave during ramp up of VDD. Below about 2V it was undefined, so needed to add resistors to pins connected to GND

My guess is that a FPGA has the same kind of ports and reset circuitry, so it will have the same issue

Cheers

Klaus

 

[Ricketty C]

On Tuesday, October 13, 2020 at 2:04:49 AM UTC-4, Klaus Kragelund wrote:

On Monday, October 12, 2020 at 1:17:12 AM UTC+2, jla...@highlandsniptechnology.com wrote:
One of my guys is suggesting that we ground unused balls on an FPGA
and compile them to be low outputs, the idea being to reduce ground
impedance and add some damping.

Has anyone done this? Does it help?

I guess I could have an input that controls the tri-states of all such
pins, and also bring out one logic-low to scope, and turn the grounds
on and off and see if it makes any difference.

It\'s an XC7A15T-1FTG256C with 30 ground pins. We could add at least
another 30 fake grounds.


Won\'t there be a problem at startup, when the IOs are undefined? Then you may short an output to GND destroying the port.

Unconfigured outputs are typically inputs with a light pullup resistor (other than the Spartan 3 devices which had a flaw that resulted in a rather stiff pullup resistor). How would that present a short? Grounding a pullup is a short?


> We once did a thorough investigation into a microcontroller startup to clarify how the outputs would behave during ramp up of VDD. Below about 2V it was undefined, so needed to add resistors to pins connected to GND

So all inputs need a series resistor on FPGAs because you never know the strength of the driver? Our design has switch inputs. If a switch is connecting to ground on power up this will cause a problem? I\'ve never heard anyone make that claim.


> My guess is that a FPGA has the same kind of ports and reset circuitry, so it will have the same issue

But that would be a guess. FPGAs are designed with configuration in mind, in particular the fact that not only do they need to deal with the power up sequence but the whole time a device might be unconfigured. I don\'t think assumptions are valid in this case.

--

Rick C.

-+- Get 1,000 miles of free Supercharging
-+- Tesla referral code - https://ts.la/richard11209

 

[Uwe Bonnes]

Klaus Kragelund <klauskvik@hotmail.com> wrote:

Won\'t there be a problem at startup, when the IOs are undefined?
Then you may short an output to GND destroying the port.

We once did a thorough investigation into a microcontroller startup
to clarify how the outputs would behave during ramp up of VDD. Below
about 2V it was undefined, so needed to add resistors to pins
connected to GND

My guess is that a FPGA has the same kind of ports and reset
circuitry, so it will have the same issue

Cheers

Klaus

There is https://www.xilinx.com/support/answers/12692.html and xapp
689 about that subject.
--
Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 1623569 ------- Fax. 06151 1623305 ---------

 

[Uwe Bonnes]

In comp.arch.fpga jlarkin@highlandsniptechnology.com wrote:

One of my guys is suggesting that we ground unused balls on an FPGA
and compile them to be low outputs, the idea being to reduce ground
impedance and add some damping.

Has anyone done this? Does it help?

I guess I could have an input that controls the tri-states of all such
pins, and also bring out one logic-low to scope, and turn the grounds
on and off and see if it makes any difference.

It\'s an XC7A15T-1FTG256C with 30 ground pins. We could add at least
another 30 fake grounds.

https://www.xilinx.com/support/answers/12692.html and xapp 689
--
Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 1623569 ------- Fax. 06151 1623305 ---------

 

[server]

On 13 Oct 2020 14:57:15 GMT, Uwe Bonnes
<bon@hertz.ikp.physik.tu-darmstadt.de> wrote:

In comp.arch.fpga jlarkin@highlandsniptechnology.com wrote:
One of my guys is suggesting that we ground unused balls on an FPGA
and compile them to be low outputs, the idea being to reduce ground
impedance and add some damping.

Has anyone done this? Does it help?

I guess I could have an input that controls the tri-states of all such
pins, and also bring out one logic-low to scope, and turn the grounds
on and off and see if it makes any difference.

It\'s an XC7A15T-1FTG256C with 30 ground pins. We could add at least
another 30 fake grounds.

https://www.xilinx.com/support/answers/12692.html and xapp 689

Nice links, thanks.

I have a time-critical async signal ripping through this FPGA, and
there is also a 40 MHz clock and some SPI activity. Ground bounce will
add jitter to the critical signal. The ground pins are clustered
towards the center balls, so maybe we can create a bunch of fake,
low-Q grounds around the edges of the chip, with better connections to
the ground plane. We could even play with drive strength.

We\'ll try it and see what happens.



--

John Larkin Highland Technology, Inc

Science teaches us to doubt.

Claude Bernard

 

[Klaus Kragelund]

On Tuesday, October 13, 2020 at 4:49:55 PM UTC+2, Uwe Bonnes wrote:

Klaus Kragelund <klau...@hotmail.com> wrote:

Won\'t there be a problem at startup, when the IOs are undefined?
Then you may short an output to GND destroying the port.

We once did a thorough investigation into a microcontroller startup
to clarify how the outputs would behave during ramp up of VDD. Below
about 2V it was undefined, so needed to add resistors to pins
connected to GND

My guess is that a FPGA has the same kind of ports and reset
circuitry, so it will have the same issue

Cheers

Klaus
There is https://www.xilinx.com/support/answers/12692.html and xapp
689 about that subject.
--
I do not see the mention of the ramp up and how the pins are controlled. In any case, since the voltage is low, and the IO FETs are limited size, one can calculate the max current running during the small duration of time when there might be a short and that current might be small and thus irrelevant. Again, \"might\"...

Cheers

Klaus

 

[Klaus Kragelund]

On Tuesday, October 13, 2020 at 4:49:31 PM UTC+2, Ricketty C wrote:

On Tuesday, October 13, 2020 at 2:04:49 AM UTC-4, Klaus Kragelund wrote:
On Monday, October 12, 2020 at 1:17:12 AM UTC+2, jla...@highlandsniptechnology.com wrote:
One of my guys is suggesting that we ground unused balls on an FPGA
and compile them to be low outputs, the idea being to reduce ground
impedance and add some damping.

Has anyone done this? Does it help?

I guess I could have an input that controls the tri-states of all such
pins, and also bring out one logic-low to scope, and turn the grounds
on and off and see if it makes any difference.

It\'s an XC7A15T-1FTG256C with 30 ground pins. We could add at least
another 30 fake grounds.


Won\'t there be a problem at startup, when the IOs are undefined? Then you may short an output to GND destroying the port.
Unconfigured outputs are typically inputs with a light pullup resistor (other than the Spartan 3 devices which had a flaw that resulted in a rather stiff pullup resistor). How would that present a short? Grounding a pullup is a short?

During ramping of the VDD/supply rail, the reset circuit has not kicked in yet, and the voltage is so low that the CMOS states is not known

We once did a thorough investigation into a microcontroller startup to clarify how the outputs would behave during ramp up of VDD. Below about 2V it was undefined, so needed to add resistors to pins connected to GND
So all inputs need a series resistor on FPGAs because you never know the strength of the driver? Our design has switch inputs. If a switch is connecting to ground on power up this will cause a problem? I\'ve never heard anyone make that claim.
My guess is that a FPGA has the same kind of ports and reset circuitry, so it will have the same issue
But that would be a guess. FPGAs are designed with configuration in mind, in particular the fact that not only do they need to deal with the power up sequence but the whole time a device might be unconfigured. I don\'t think assumptions are valid in this case.

Configuration, yes. But that is a SW configuration, not HW. States are loaded during boot, right?

Cheers

Klaus

 

[Ricketty C]

On Tuesday, October 13, 2020 at 6:40:08 PM UTC-4, Klaus Kragelund wrote:

On Tuesday, October 13, 2020 at 4:49:31 PM UTC+2, Ricketty C wrote:
On Tuesday, October 13, 2020 at 2:04:49 AM UTC-4, Klaus Kragelund wrote:
On Monday, October 12, 2020 at 1:17:12 AM UTC+2, jla...@highlandsniptechnology.com wrote:
One of my guys is suggesting that we ground unused balls on an FPGA
and compile them to be low outputs, the idea being to reduce ground
impedance and add some damping.

Has anyone done this? Does it help?

I guess I could have an input that controls the tri-states of all such
pins, and also bring out one logic-low to scope, and turn the grounds
on and off and see if it makes any difference.

It\'s an XC7A15T-1FTG256C with 30 ground pins. We could add at least
another 30 fake grounds.


Won\'t there be a problem at startup, when the IOs are undefined? Then you may short an output to GND destroying the port.
Unconfigured outputs are typically inputs with a light pullup resistor (other than the Spartan 3 devices which had a flaw that resulted in a rather stiff pullup resistor). How would that present a short? Grounding a pullup is a short?

During ramping of the VDD/supply rail, the reset circuit has not kicked in yet, and the voltage is so low that the CMOS states is not known

During ramp up FPGAs are very current sucking. I\'m not sure a handfull of I/Os shorting would produce much more draw than the chips do anyway. Consider the effective capacitance of all the transistors on the chip having to be charged up.

We once did a thorough investigation into a microcontroller startup to clarify how the outputs would behave during ramp up of VDD. Below about 2V it was undefined, so needed to add resistors to pins connected to GND
So all inputs need a series resistor on FPGAs because you never know the strength of the driver? Our design has switch inputs. If a switch is connecting to ground on power up this will cause a problem? I\'ve never heard anyone make that claim.
My guess is that a FPGA has the same kind of ports and reset circuitry, so it will have the same issue
But that would be a guess. FPGAs are designed with configuration in mind, in particular the fact that not only do they need to deal with the power up sequence but the whole time a device might be unconfigured. I don\'t think assumptions are valid in this case.

Configuration, yes. But that is a SW configuration, not HW. States are loaded during boot, right?

The configuration (not sure what \"states\" are or what \"boot\" is) is loaded during configuration. However, there are circuits to assure the I/O pins are held in a defined state. I can\'t say what they do during the power up period. My concern with that phase has always been the power consumption which can be very spiky and quite high.

--

Rick C.

-++ Get 1,000 miles of free Supercharging
-++ Tesla referral code - https://ts.la/richard11209

 

[Gerhard Hoffmann]

Am 14.10.20 um 05:43 schrieb Rick C:

On Tuesday, October 13, 2020 at 1:14:31 PM UTC-4, Gerhard Hoffmann wrote:
Am 12.10.20 um 18:57 schrieb Rick C:
On Monday, October 12, 2020 at 12:52:19 PM UTC-4, Jim Lewis wrote:
How do you know these pins are not some sort of manufacturing test output pins?

On a networking chip I used (years ago), a couple of the pins that were
documented as power and ground pins were actually mode configuration pins.

He is talking about wiring unused I/O pins that he can specify as grounds or power by assigning a \'0\' or \'1\' respectively. They are not the same as a solid connection to the chip ground or power, but every bit helps. At high frequency the pin inductance is probably higher impedance than the resistance of the internal MOSFET, so the I/O grounds are probably a lot better than nothing. But this is also needed on the I/O power supply as well as ground.


It may be possible to improve ground bounce slightly, but the
on-chip ground connections may be connected only group-wise,

Sorry, not sure what you mean by \"group wise\". Grounds are connected to ground, typically a ground plane. What is \"group wise\"?

groups might be a GTX transceiver , a tile of CLBs, a hard SDRAM
interface.. WE cannot know that, but it could make sense.
We can just bet or try it.

so that the drivers for SDRAM buses etc do not force ground bounce
on the GND of the low level core signals.

Why do you emphasize the ground an ignore the power? The problem comes from the threshold of an input being impacted. The threshold is based on the differential voltage of the power and ground. So is it not correct that the power rail will also impact the input threshold?

Because JL wants to add GND connections. It\'s in the
title of the thread.

And input thresholds do not depend on VDD in the first or second order.
That is determined by active circuitry in the chip and is set by
configuration data.
Remember you can choose 3V3-LVCMOS or 2V5 or 1.8V logic, or whatever.

And for powerup, VDD rise time and monotonous rise is usually specified.

But driving unused outputs to GND cannot be bad since your logic
might require it and there can be no bus fight.

I\'m not clear why you are mentioning \"bus fights\".


Long time ago, I had a bus fight between an XC3020 and a 74AS244.
The AS244 said low, the xc3020 said high. Saying low is the easier
part, but the XC3020 won hands down.
That consumed a lot of current.

Early FPGAs could do that with their on-chip tri-state buses
on their own, just by feeding them corrupt configuration data.

My understanding is that all FPGAs have protections against accepting invalid configurations. I may be mistaken. It\'s just that I am pretty sure this was resolved so long ago that I no longer even give it a thought.

Mentioning XC3020 should give a hint about the time frame.
We had stacks of Compaq-286s then for concurrent runs of apr,
in the hope that there was a usable routing solution the next morning.

I had to study Virtex power up in quite detail when I implemented
configuration memory scrubbing for some space-bound Virtexes that
may encounter radiation and get bit flips in configuration ram.

Yes, that is a different matter. I worked with a guy from NASA for a while who was radiation testing FPGAs and he explained how they would reload the configuration periodically to deal with soft errors. What he never explained was how the circuit functioned while the FPGA was being reloaded.


Mitigation consists of re-loading the configuration ram from
non-volatile memory every few minutes and doing the user land
logic triple module redundant. Refresh must be done before the
errors pile up so badly that the redundancy fails.

So how do you deal with the loss of the FPGA functionality while being reconfigured?


FPGA configuration is a well defined synchronous process controlled
by the configuration clock. Scrubbing is done just like a power up,
but the process is aborted 1 clock before the global reset etc is
executed.

So is the FPGA never stopped? The devices I\'ve worked with start configuration by resetting the entire configuration RAM. It was explained to me that was what was happening that set the minimum configuration time, one full cycle through the process. As long as the configuration pin was held asserted, the process would continue. When you released the signal it would complete the cycle it was on, then accept a new bit stream. I think Xilinx used the INIT pin for the flag that it was ready to be configured which could be paralleled between multiple devices.

The Virtex is never stopped. The user-land circuit continues to run
while the configuration ram contents is rejuvenated in dual port style.
That takes a known number of CCLKs from the activation of the program
command pin. A few CCLKs later, chip re-initialization would start:
global reset etc.
That must not happen, so the configuration clock must be stopped
in time until after the next program command a few minutes later.

Scrubbing does not make the FPGA radiation proof. Important logic
must be triple module redundant.

Since I was not given the Xilinx TMR tool (ITAR..) I wrote a
VHDL library with tmr_slv, tmr_signed etc that looks much like the
normal standard_logic_vector etc and hides most of the redundancy.
I prefer my own library now.


Yes, scrubbing can have unexpected side effects. For example, you
may not use these 2*8 bit CLB RAMs because they are physically
in the configuration RAM.

Unfortunately, the Picoblaze uses these for its registers.
Our software people did not like it that their programs
crashed every few minutes.

I have rewritten the Picoblaze to use ordinary flipflops for its
registers. The performance and area drawback was acceptable.

Cheers, Gerhard

 

[HT-Lab]

Hi Gerhard,

On 14/10/2020 12:38, Gerhard Hoffmann wrote:
...

Mentioning XC3020 should give a hint about the time frame.
We had stacks of Compaq-286s then for concurrent runs of apr,
in the hope that there was a usable routing solution the next morning.
...

Sorry to hijack this thread, I am curious if you have ever flown an
XC3020. I also worked in the space industry about 30 years ago and was
told that we couldn\'t use the XC3020 as it was latchup sensitive. Hence
I had to continue using the Actel 1020 and 1280 which were very
expensive and put a low of pressure on the engineers not to make a
mistake. One oops and you have to burn a new device. This was long
before the Qpro series.

Scrubbing does not make the FPGA radiation proof. Important logic
must be triple module redundant.

Since I was not given the Xilinx TMR tool (ITAR..) I wrote a
VHDL library with tmr_slv, tmr_signed etc that looks much like the
normal standard_logic_vector etc and hides most of the redundancy.
I prefer my own library now. 

I did the same although a bit simper, I build TMR FF\'s in Viewlogic and
used those for the logic. This was before I learned about VHDL.

Yes, scrubbing can have unexpected side effects. For example, you
may not use these 2*8 bit CLB RAMs because they are physically
in the configuration RAM.

Unfortunately, the Picoblaze uses these for its registers.
Our software people did not like it that their programs
crashed every few minutes.

I have rewritten the Picoblaze to use ordinary flipflops for its
registers. The performance and area drawback was acceptable.

I decided to write an 8086 in VHDL a few years later with the same idea,
make an SEU/SET tolerant softcore. We already used an 80186 for our main
OBC like many other satellites in those days. However, some brilliant
ESTEC engineer came along who wrote a far more capable Sparc processor
in about a quoter of the time it took me to write the 8086...

Regards,
Hans.
www.ht-lab.com

Cheers, Gerhard