adding FPGA grounds...

On Sunday, October 11, 2020 at 7:17:09 PM UTC-4, 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.

What problem are you trying to solve? My experience is when it comes to power distribution systems (PDS) people often try to optimize without knowing if they have a problem. PDS design is one of those things where you can either try actually analyzing the design to know how to design the PDS, or you can throw in a lot of overkill to try to make sure you hit the rabbit.

What will you measure to see the effectiveness of the grounds? The usual concern is ground bounce. For that you would measure an output pulled low with no trace to see (as well as possible) the internal ground voltage. I\'m not sure how well the internal spike will be conducted through the pin drivers. Otherwise you would need to load a design into the chip that would produce similar switching spikes as your real design and see if you get any false triggers on clocks or input corruptions. I suppose a simple input directly driving an output can show a corrupted input level differently than an output at a fixed low level showing the ground bounce directly.

--

Rick C.

- Get 1,000 miles of free Supercharging
- Tesla referral code - https://ts.la/richard11209
 
On Sunday, October 11, 2020 at 8:36:53 PM UTC-4, Richard Damon wrote:
On 10/11/20 7:17 PM, 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.


I have seen some manufactures suggest this. I haven\'t measured it, but I
would guess it could help, at least as long as the FPGA doesn\'t every
try to drive the output high for a moment.

For the final design the outputs would be hardwired to ground eliminating the possibility of driving to any other state.

--

Rick C.

+ Get 1,000 miles of free Supercharging
+ Tesla referral code - https://ts.la/richard11209
 
On 10/12/20 12:40 AM, Rick C wrote:
On Sunday, October 11, 2020 at 8:36:53 PM UTC-4, Richard Damon wrote:
On 10/11/20 7:17 PM, 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.


I have seen some manufactures suggest this. I haven\'t measured it, but I
would guess it could help, at least as long as the FPGA doesn\'t every
try to drive the output high for a moment.

For the final design the outputs would be hardwired to ground eliminating the possibility of driving to any other state.
If they were \'hard wired\' they wouldn\'t be programmable! The issue is
that if in the configuration process, it was possible for a momentary
glitch to turn on the high driver, you would get a current spike. They
do try to avoid this, but sometimes, particularly during the power on
transient, strange things can happen. Some parts definitely will turn on
weak pull ups which will draw power till they get the pull ups
configured off.
 
On Monday, October 12, 2020 at 8:40:57 AM UTC-4, Richard Damon wrote:
On 10/12/20 12:40 AM, Rick C wrote:
On Sunday, October 11, 2020 at 8:36:53 PM UTC-4, Richard Damon wrote:
On 10/11/20 7:17 PM, 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.


I have seen some manufactures suggest this. I haven\'t measured it, but I
would guess it could help, at least as long as the FPGA doesn\'t every
try to drive the output high for a moment.

For the final design the outputs would be hardwired to ground eliminating the possibility of driving to any other state.

If they were \'hard wired\' they wouldn\'t be programmable! The issue is
that if in the configuration process, it was possible for a momentary
glitch to turn on the high driver, you would get a current spike. They
do try to avoid this, but sometimes, particularly during the power on
transient, strange things can happen. Some parts definitely will turn on
weak pull ups which will draw power till they get the pull ups
configured off.

There are protections in the chip to prevent loading a corrupt bitstream. This isn\'t just a simple SPI register load.

No pull up to the power rail burning up an I/O.

--

Rick C.

-- Get 1,000 miles of free Supercharging
-- Tesla referral code - https://ts.la/richard11209
 
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.

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.
 
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.

--

Rick C.

-+ Get 1,000 miles of free Supercharging
-+ Tesla referral code - https://ts.la/richard11209
 
On 10/12/20 10:05 AM, Rick C wrote:
On Monday, October 12, 2020 at 8:40:57 AM UTC-4, Richard Damon wrote:
On 10/12/20 12:40 AM, Rick C wrote:
On Sunday, October 11, 2020 at 8:36:53 PM UTC-4, Richard Damon wrote:
On 10/11/20 7:17 PM, 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.


I have seen some manufactures suggest this. I haven\'t measured it, but I
would guess it could help, at least as long as the FPGA doesn\'t every
try to drive the output high for a moment.

For the final design the outputs would be hardwired to ground eliminating the possibility of driving to any other state.

If they were \'hard wired\' they wouldn\'t be programmable! The issue is
that if in the configuration process, it was possible for a momentary
glitch to turn on the high driver, you would get a current spike. They
do try to avoid this, but sometimes, particularly during the power on
transient, strange things can happen. Some parts definitely will turn on
weak pull ups which will draw power till they get the pull ups
configured off.

There are protections in the chip to prevent loading a corrupt bitstream. This isn\'t just a simple SPI register load.

No pull up to the power rail burning up an I/O.

Maybe newer FPGAs have less problems with it, but I seem to remember
that some FPGAs comming out of configuration (and defaulting to be an
input) into an output, always enabled, driving low, might not complete
keep the high side driver off. These FPGAs specifically defined that
unused pins should be left floating/not connected.

IF the chip designer is presuming that small glitches on enabled output
are unimportant (since they will only be driving inputs), this isn\'t
unreasonable.

Later, with higher density packages, the idea that grounding low driving
outputs could improve (slightly) the ground impedance, made it more
important to avoid these issues.
 
On Monday, October 12, 2020 at 10:33:23 PM UTC-4, Richard Damon wrote:
On 10/12/20 10:05 AM, Rick C wrote:
On Monday, October 12, 2020 at 8:40:57 AM UTC-4, Richard Damon wrote:
On 10/12/20 12:40 AM, Rick C wrote:
On Sunday, October 11, 2020 at 8:36:53 PM UTC-4, Richard Damon wrote:
On 10/11/20 7:17 PM, 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.


I have seen some manufactures suggest this. I haven\'t measured it, but I
would guess it could help, at least as long as the FPGA doesn\'t every
try to drive the output high for a moment.

For the final design the outputs would be hardwired to ground eliminating the possibility of driving to any other state.

If they were \'hard wired\' they wouldn\'t be programmable! The issue is
that if in the configuration process, it was possible for a momentary
glitch to turn on the high driver, you would get a current spike. They
do try to avoid this, but sometimes, particularly during the power on
transient, strange things can happen. Some parts definitely will turn on
weak pull ups which will draw power till they get the pull ups
configured off.

There are protections in the chip to prevent loading a corrupt bitstream. This isn\'t just a simple SPI register load.

No pull up to the power rail burning up an I/O.


Maybe newer FPGAs have less problems with it, but I seem to remember
that some FPGAs comming out of configuration (and defaulting to be an
input) into an output, always enabled, driving low, might not complete
keep the high side driver off. These FPGAs specifically defined that
unused pins should be left floating/not connected.

Can\'t say I follow what you are saying. It\'s not like the I/Os are not configured while the rest of the chip is configured. If unused the I/Os are configured as inputs, either with a light pullup or nothing, I don\'t claim to know the details, but an I/O should never be left floating since that allows the input (which is always connected) to drift to a mid voltage where both high and low FETs are on drawing high current.

When unused, the software takes care of the default I/O configuration. Your reference to the high driver being partly on is probably the pullup which is implemented as a very light FET.

If you configure an output as driving a constant \'0\' (no longer an \"unused\" I/O) it will be driving the output hard to ground. There are various drive strengths and the highest should be used. Connecting the pin to the right power rail will provide some reduction in ground impedance just as a similar act on the high power rail will do the same for the high side.


IF the chip designer is presuming that small glitches on enabled output
are unimportant (since they will only be driving inputs), this isn\'t
unreasonable.

Sorry, I\'m not following. Ground bounce is about outputs switching large currents at the same time driving the ground impedance and driving the chip internal ground high which impacts the threshold voltage for *inputs* causing glitches. I\'m not clear what you are saying about outputs.


Later, with higher density packages, the idea that grounding low driving
outputs could improve (slightly) the ground impedance, made it more
important to avoid these issues.

Sorry, I\'m not following what you are saying at all. What is the issue that needs to be avoided???

--

Rick C.

+- Get 1,000 miles of free Supercharging
+- Tesla referral code - https://ts.la/richard11209
 
On 10/12/20 11:50 PM, Rick C wrote:
On Monday, October 12, 2020 at 10:33:23 PM UTC-4, Richard Damon wrote:

Maybe newer FPGAs have less problems with it, but I seem to remember
that some FPGAs comming out of configuration (and defaulting to be an
input) into an output, always enabled, driving low, might not complete
keep the high side driver off. These FPGAs specifically defined that
unused pins should be left floating/not connected.

Can\'t say I follow what you are saying. It\'s not like the I/Os are not configured while the rest of the chip is configured. If unused the I/Os are configured as inputs, either with a light pullup or nothing, I don\'t claim to know the details, but an I/O should never be left floating since that allows the input (which is always connected) to drift to a mid voltage where both high and low FETs are on drawing high current.

When unused, the software takes care of the default I/O configuration. Your reference to the high driver being partly on is probably the pullup which is implemented as a very light FET.

If you configure an output as driving a constant \'0\' (no longer an \"unused\" I/O) it will be driving the output hard to ground. There are various drive strengths and the highest should be used. Connecting the pin to the right power rail will provide some reduction in ground impedance just as a similar act on the high power rail will do the same for the high side.

If you don\'t understand HOW a FPGA works internally, then you don\'t
really have a basis to comment.

At reset, before the configuration is loaded, the pins will be setup as
inputs, and the designs are careful to make the Power on Reset to
Default Input configuration glitch-less, as it is expected that some of
these pins will be driven by low impedance drivers.

There are also Flash/OTP parts that don\'t have a \'configuration\' phase,
but at power on \'immediately\' configure and might enable before the
output value is fully set.

My comment was that some designs didn\'t switch from Default Input mode
to Enable Low Output in a glitch-less manner, in part because it wasn\'t
expected to be important. An output was expected to be driving a
relatively high impedance load, so a short power on glitch was not
important.

Some chips DID specifically define that unused pins should be left
floating. (The compiler tool converted them to weak outputs of seemingly
random signals). Some actually will disable the input section, so the
mid-level voltage isn\'t a problem (especially useful if the pin can be
multiplexed with analog functions, where mid-level voltages are expected).

Outputs have (at least) two FETs, one to pull high, one to pull low.
Just because you have programmed the FPGA to drive low, doesn\'t mean
that the high driving FET has gone away. Depending on design
requirements, they might be careful to avoid the glitch or they might
not. It costs logic to sequence things to happen in a given order, so if
it isn\'t important, they might not add the logic to prevent the glitch.

IF the chip designer is presuming that small glitches on enabled output
are unimportant (since they will only be driving inputs), this isn\'t
unreasonable.

Sorry, I\'m not following. Ground bounce is about outputs switching large currents at the same time driving the ground impedance and driving the chip internal ground high which impacts the threshold voltage for *inputs* causing glitches. I\'m not clear what you are saying about outputs.
I am talking about an initial power on glitch at the transition from
Power-om/configuration to operation. Grounding an output that has a high
driving glitch can create a significant current spike which can disrupt
power supplies and chip operation.
Later, with higher density packages, the idea that grounding low driving
outputs could improve (slightly) the ground impedance, made it more
important to avoid these issues.

Sorry, I\'m not following what you are saying at all. What is the issue that needs to be avoided???

If a chip does not have a guaranteed glitch-less startup configuration,
don\'t assume it does and tie and output to the \'presumed\' output level
(that you have configured).
 
On Tuesday, October 13, 2020 at 8:35:20 AM UTC-4, Richard Damon wrote:
On 10/12/20 11:50 PM, Rick C wrote:
On Monday, October 12, 2020 at 10:33:23 PM UTC-4, Richard Damon wrote:

Maybe newer FPGAs have less problems with it, but I seem to remember
that some FPGAs comming out of configuration (and defaulting to be an
input) into an output, always enabled, driving low, might not complete
keep the high side driver off. These FPGAs specifically defined that
unused pins should be left floating/not connected.

Can\'t say I follow what you are saying. It\'s not like the I/Os are not configured while the rest of the chip is configured. If unused the I/Os are configured as inputs, either with a light pullup or nothing, I don\'t claim to know the details, but an I/O should never be left floating since that allows the input (which is always connected) to drift to a mid voltage where both high and low FETs are on drawing high current.

When unused, the software takes care of the default I/O configuration. Your reference to the high driver being partly on is probably the pullup which is implemented as a very light FET.

If you configure an output as driving a constant \'0\' (no longer an \"unused\" I/O) it will be driving the output hard to ground. There are various drive strengths and the highest should be used. Connecting the pin to the right power rail will provide some reduction in ground impedance just as a similar act on the high power rail will do the same for the high side.


If you don\'t understand HOW a FPGA works internally, then you don\'t
really have a basis to comment.

Dude, if you can\'t discuss a topic civilly, then don\'t discuss it at all. Either maintain low cones or don\'t reply.


At reset, before the configuration is loaded, the pins will be setup as
inputs, and the designs are careful to make the Power on Reset to
Default Input configuration glitch-less, as it is expected that some of
these pins will be driven by low impedance drivers.

There are also Flash/OTP parts that don\'t have a \'configuration\' phase,
but at power on \'immediately\' configure and might enable before the
output value is fully set.

My comment was that some designs didn\'t switch from Default Input mode
to Enable Low Output in a glitch-less manner, in part because it wasn\'t
expected to be important. An output was expected to be driving a
relatively high impedance load, so a short power on glitch was not
important.

Some chips DID specifically define that unused pins should be left
floating. (The compiler tool converted them to weak outputs of seemingly
random signals). Some actually will disable the input section, so the
mid-level voltage isn\'t a problem (especially useful if the pin can be
multiplexed with analog functions, where mid-level voltages are expected)..

Outputs have (at least) two FETs, one to pull high, one to pull low.
Just because you have programmed the FPGA to drive low, doesn\'t mean
that the high driving FET has gone away. Depending on design
requirements, they might be careful to avoid the glitch or they might
not. It costs logic to sequence things to happen in a given order, so if
it isn\'t important, they might not add the logic to prevent the glitch.

You have done a great job of explaining the configuration of the I/Os but not connected that to the issue at hand which is the use of I/Os as ground connections. You talk about an output driving low and then say the \"high driving FET has gone away\" without explaining the significance. No, transistors on a chip do not \"go away\". So what?


IF the chip designer is presuming that small glitches on enabled output
are unimportant (since they will only be driving inputs), this isn\'t
unreasonable.

Sorry, I\'m not following. Ground bounce is about outputs switching large currents at the same time driving the ground impedance and driving the chip internal ground high which impacts the threshold voltage for *inputs* causing glitches. I\'m not clear what you are saying about outputs.

I am talking about an initial power on glitch at the transition from
Power-om/configuration to operation. Grounding an output that has a high
driving glitch can create a significant current spike which can disrupt
power supplies and chip operation.

You have not explained where this glitch might come from.


Later, with higher density packages, the idea that grounding low driving
outputs could improve (slightly) the ground impedance, made it more
important to avoid these issues.

Sorry, I\'m not following what you are saying at all. What is the issue that needs to be avoided???


If a chip does not have a guaranteed glitch-less startup configuration,
don\'t assume it does and tie and output to the \'presumed\' output level
(that you have configured).

Nothing in digital chips are guaranteed glitchless. That\'s why we provide so much decoupling of the power supply, to damp the glitches. You have not explained yourself at all, but seem t o be simply claiming tying a low output to ground will produce a large glitch on configuration. However, you don\'t really explain this glitch, you simply state the \"high driving FET has [not] gone away\" whatever that means. Why would the high driving FET be turned on at any point in the configuration when the configuration is to drive low?

Perhaps you can review your explanation and find the gap in your logic, because you have failed to explain your logic?

--

Rick C.

++ Get 1,000 miles of free Supercharging
++ Tesla referral code - https://ts.la/richard11209
 
On 10/13/20 10:27 AM, Rick C wrote:
On Tuesday, October 13, 2020 at 8:35:20 AM UTC-4, Richard Damon wrote:
On 10/12/20 11:50 PM, Rick C wrote:
On Monday, October 12, 2020 at 10:33:23 PM UTC-4, Richard Damon wrote:

Maybe newer FPGAs have less problems with it, but I seem to remember
that some FPGAs comming out of configuration (and defaulting to be an
input) into an output, always enabled, driving low, might not complete
keep the high side driver off. These FPGAs specifically defined that
unused pins should be left floating/not connected.

Can\'t say I follow what you are saying. It\'s not like the I/Os are not configured while the rest of the chip is configured. If unused the I/Os are configured as inputs, either with a light pullup or nothing, I don\'t claim to know the details, but an I/O should never be left floating since that allows the input (which is always connected) to drift to a mid voltage where both high and low FETs are on drawing high current.

When unused, the software takes care of the default I/O configuration. Your reference to the high driver being partly on is probably the pullup which is implemented as a very light FET.

If you configure an output as driving a constant \'0\' (no longer an \"unused\" I/O) it will be driving the output hard to ground. There are various drive strengths and the highest should be used. Connecting the pin to the right power rail will provide some reduction in ground impedance just as a similar act on the high power rail will do the same for the high side.


If you don\'t understand HOW a FPGA works internally, then you don\'t
really have a basis to comment.

Dude, if you can\'t discuss a topic civilly, then don\'t discuss it at all. Either maintain low cones or don\'t reply.

YOU, who admitted that they don\'t fully understand the details of how
things work in a FPGA was telling me, who has worked with them from
their beginning, that a phenomenon that I HAVE seen, \"Can\'t Happen\". Who
is talking through their hat?
At reset, before the configuration is loaded, the pins will be setup as
inputs, and the designs are careful to make the Power on Reset to
Default Input configuration glitch-less, as it is expected that some of
these pins will be driven by low impedance drivers.

There are also Flash/OTP parts that don\'t have a \'configuration\' phase,
but at power on \'immediately\' configure and might enable before the
output value is fully set.

My comment was that some designs didn\'t switch from Default Input mode
to Enable Low Output in a glitch-less manner, in part because it wasn\'t
expected to be important. An output was expected to be driving a
relatively high impedance load, so a short power on glitch was not
important.

Some chips DID specifically define that unused pins should be left
floating. (The compiler tool converted them to weak outputs of seemingly
random signals). Some actually will disable the input section, so the
mid-level voltage isn\'t a problem (especially useful if the pin can be
multiplexed with analog functions, where mid-level voltages are expected).

Outputs have (at least) two FETs, one to pull high, one to pull low.
Just because you have programmed the FPGA to drive low, doesn\'t mean
that the high driving FET has gone away. Depending on design
requirements, they might be careful to avoid the glitch or they might
not. It costs logic to sequence things to happen in a given order, so if
it isn\'t important, they might not add the logic to prevent the glitch.

You have done a great job of explaining the configuration of the I/Os but not connected that to the issue at hand which is the use of I/Os as ground connections. You talk about an output driving low and then say the \"high driving FET has gone away\" without explaining the significance. No, transistors on a chip do not \"go away\". So what?

Because it is there, it CAN turn on, at least momentarily, causing a
short from the power rail to your external ground connection, which
wasn\'t supposed to be there by the manufactures design specs. (Pins
declared as outputs need to be driving loads with a given minimum
impedance, not a zero ohms to ground)

IF the chip designer is presuming that small glitches on enabled output
are unimportant (since they will only be driving inputs), this isn\'t
unreasonable.

Sorry, I\'m not following. Ground bounce is about outputs switching large currents at the same time driving the ground impedance and driving the chip internal ground high which impacts the threshold voltage for *inputs* causing glitches. I\'m not clear what you are saying about outputs.

I am talking about an initial power on glitch at the transition from
Power-om/configuration to operation. Grounding an output that has a high
driving glitch can create a significant current spike which can disrupt
power supplies and chip operation.

You have not explained where this glitch might come from.

The output stage gets two inputs (of interest here) from the main FPGA
array. One is an output enable, which for proper operation during power
om reset/configuration needs to be internally biased during that period to
\'disabled\', and a second \'Data\' bit, that since the value isn\'t needed
during this initial phase, might just be left undefined. to define in at
this time either needs a light restive load all the time, burning power
all the time, or a transistor (space) or a more complicated coming out
of config sequencing (again space).

At the moment configuration ends, the system copies the configuration
data from the configuration shift register or flash memory source into
the actual operation registers, at which point the enable will start to
be driven, as well as the data. This action takes a finite period of
time, and unless special care was taken, the output enable my reach the
output before the output low signal does, at which point the output
might glitch high causing the current spike. Since this also happens to
be a high activity point in time, such a spike might disrupt the FPGA.

Later designs often did decide it was worth the cost to sequence things,
so most FPGAs today delay the enabling of outputs a bit to allow the
data paths to settle before outputs are allowed to drive.
Later, with higher density packages, the idea that grounding low driving
outputs could improve (slightly) the ground impedance, made it more
important to avoid these issues.

Sorry, I\'m not following what you are saying at all. What is the issue that needs to be avoided???


If a chip does not have a guaranteed glitch-ln eess startup configuration,
don\'t assume it does and tie and output to the \'presumed\' output level
(that you have configured).

Nothing in digital chips are guaranteed glitchless. That\'s why we provide so much decoupling of the power supply, to damp the glitches. You have not explained yourself at all, but seem t o be simply claiming tying a low output to ground will produce a large glitch on configuration. However, you don\'t really explain this glitch, you simply state the \"high driving FET has [not] gone away\" whatever that means. Why would the high driving FET be turned on at any point in the configuration when the configuration is to drive low?

Perhaps you can review your explanation and find the gap in your logic, because you have failed to explain your logic?

Actually, many designs HAVE located places where glitches in the earlier
simple designs caused enough problems that they have taken care to
reduce or eliminate many of them. For example, most LUTS today are
promised to not glitch if a single input transitions, and the LUT value
for both cases are the same (some earlier designs this was not always
true without special coding).
 
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,
so that the drivers for SDRAM buses etc do not force ground bounce
on the GND of the low level core signals.

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


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.


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.

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.

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.

It is possible that the FPGA controls its own scrubbing.
Having bugs in the TMR logic that controls that scrubbing is ugly.

----

And the mother of the really dumb ones is always pregnant.
I saw someone complain that his FPGA did not really work.
He had used the FPGA ground pins as GND bridges for his
board layout, forcing board currents through the chip! =8( )


Cheers, gerhard
 
On Tuesday, October 13, 2020 at 12:52:19 PM UTC-4, jla...@highlandsniptechnology.com wrote:
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.

I don\'t know why they would insist the added grounds needed to be near the existing grounds. I really can\'t see the advantage. I would expect the added grounds should be as close as possible to the high speed I/Os that are causing the glitches.

By all means, don\'t make your drivers any faster than they need to be. That is the one direct control you have over the problem.

The other factor is that you need the same treatment on the power rail for the output I/Os. There is also a matter of the high speed outputs being broken up. If you spread them in time you will see less impact on the input threshold. So if you have a small number of inputs you wish to protect, you can put them on one output bank, then put the high speed outputs on the other banks with the added grounds and I/O Vdd connections.

I suppose with the die being smaller than the package, it makes sense to keep the added grounds close to the center of the package so their series impedance is minimized. But reducing the ground bounce by staggering multiple outputs switching at once will help a lot more.

If you don\'t have multiple signals switching at once, I suppose you are chasing very small effects and will need to apply every technique you can come up with.

--

Rick C.

--- Get 1,000 miles of free Supercharging
--- Tesla referral code - https://ts.la/richard11209
 
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\"?


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?


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.


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.


It is possible that the FPGA controls its own scrubbing.
Having bugs in the TMR logic that controls that scrubbing is ugly.

----

And the mother of the really dumb ones is always pregnant.
I saw someone complain that his FPGA did not really work.
He had used the FPGA ground pins as GND bridges for his
board layout, forcing board currents through the chip! =8( )

I recall learning not to connect ground traces that way when I was working with 8 bit micros... from someone else\'s experience, not my own. I was told about it.

--

Rick C.

--+ Get 1,000 miles of free Supercharging
--+ Tesla referral code - https://ts.la/richard11209
 
On Wednesday, October 14, 2020 at 7:38:41 AM UTC-4, Gerhard Hoffmann wrote:
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.

Sorry, I\'m simply not following the thought here. The FPGAs I use don\'t organize CLBs in tiles. But more importantly, what does this have to do with grounds? I don\'t recall the source of this info, but grounds are not organized by groups, rather there is a global connectivity for the ground. If grounds were connected to local logic/IOs specifically, they would be much less effective when the loading was not even.


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.

JL *SAYS* he wants to add ground connections, but his actual goal is to reduce the jitter on a signal traversing the chip. He thinks this means dealing with ground bounce, but in reality it means dealing with power bounce as well.

Interesting that he is focusing on mitigating the impedance to ground while not giving so much attention to the other factors that cause bounce, the switching outputs. He did mention something about slowing output drives, but even more important is to stagger output switching times. If you have 16 outputs switching at once and you reduce the drive 2x the bounce reduces by 2x. Stagger the 16 outputs so none switch at the same nanosecond and you reduce the bounce by up to 16x.


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.

LOL! They do not specify exact voltages for any of these I/O types. They switching voltage is almost universally specified as a function of Vcc. The different thresholds selected vary mostly by the varying Vcc spec for the different modes. It\'s not like they have voltage sources compared to the input with differential amps.

Larkin has already shown the propagation delay varies wildly with Vcc, now he is just trying to find the sources of this variation, one of which is ground/power bounce because of the change in threshold for the incoming signal.

Ask him, he\'s always happy to discuss his designs in great detail.


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.

You are talking about a device that has not seen a design win in over 20 years. Yes, I\'ve forgotten nearly everything I knew about them other than they followed the XC2000 series and preceded the XC4000 series. No, I don\'t consider such devices when discussing FPGAs any more than I consider my \'63 Chevy II when discussing automobiles.


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.

I was not aware this was possible. I thought that when the configuration pin is asserted the global set/reset was activated.


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.

Ok. That\'s the easy to understand part. I\'m unclear about initiating configuration while the chip is running. I\'m not aware of any dual buffering of the configuration memory. So while the chip is being loaded any LUTs used as memory or any block RAMs would be clobbered. I guess they can not be used.


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.

Yeah, the picoblaze is not written in RTL, it is instantiated LUTs and registers, the way XC2000 designs were done. Fine if you only want to use it. Not so fine if you want to modify it. They do get consistent performance with it.

--

Rick C.

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

Welcome to EDABoard.com

Sponsor

Back
Top