pcb&bitstream

[geobsd]

hi kolja
1999 look ot of date !
anyway if peoples want to damage fpgas they bought they will have
better result with an axe !
i asked bit-stream spec to not spend time to find how to not damage my
fpgas
if you insist they will sell undamagable fpgas (that simply don't work
at all)

 

[Ed McGettigan]

On Mar 19, 10:48 am, Kolja Sulimma <ksuli...@googlemail.com> wrote:

On 15 Mrz., 02:28, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:

You can fry an FPGA with VDHL and vendor synthesis software.
This has been demonstrated at the FPL conference a decade ago.

I am quite surprised about this. Can you provide any additional
material on how this was achieved?

There aren't any scenarios, other than internal tri-state contention,
that I can come up with to make this happen with a proven tool chain.

It was at FPL1999 that someone presented this as a sidenote in a
presentation about some
other topic. They said they were able to damage Altera FPGAs by
instantiating ring counters.
This resulted in spontaneous applause by the Xilinx crowd in the
audience but the presenter
made clear that this attack also applies to Xilinx Fpgas and that it
is computationally infeasible
to detect such attacks.

I just browsed through the list of papers of that conferencehttp://www.informatik.uni-trier.de/~ley/db/conf/fpl/fpl1999.html
but can't remember, which paper it was.

There were some prominent people from Xilinx present (Peter Alfke,
Steve Trimberger, Steve Guccione and some other Steve). Maybe one of
them remembers.

Kolja Sulimma
cronologic

What you remember as a ring counter was probably a ring oscillator
that was used to get a high frequency clock to drive the rest of the
FPGA logic with a high toggle rate. Without system level
considerations and monitoring the power requirements could easily push
the device into a thermal region that would damage the device. The
HDL and bitstream itself is perfectly valid, it is the thermal
management that is to blame for the destruction. The failure points
would likely be wide spread through the device.

This failure mode isn't the same as a badly constructed bitstream
violating DRC rules and creating device damage that would be difficult
to detect as it may only exist at a few points within the device.

Recent Xilinx FPGAs with the System Monitor feature (renamed to XADC
in the 7 Series families) have the ability to shutdown the device if
the junction temperature exceeds user defined values. This can be
used to prevent this type of thermal damage, but it would not be able
to prevent localized damage due to bad bitstreams.

Ed McGettigan
--
Xilinx Inc.

 

[glen herrmannsfeldt]

Ed McGettigan <ed.mcgettigan@xilinx.com> wrote:

On Mar 19, 10:48 am, Kolja Sulimma <ksuli...@googlemail.com> wrote:

(snip)

It was at FPL1999 that someone presented this as a sidenote in a
presentation about some
other topic. They said they were able to damage Altera FPGAs by
instantiating ring counters.

(snip)

What you remember as a ring counter was probably a ring oscillator
that was used to get a high frequency clock to drive the rest of the
FPGA logic with a high toggle rate. Without system level
considerations and monitoring the power requirements could easily push
the device into a thermal region that would damage the device. The
HDL and bitstream itself is perfectly valid, it is the thermal
management that is to blame for the destruction. The failure points
would likely be wide spread through the device.

The designs that I am interested in have many signals changing
on average every other clock cycle, and clocked as fast as I can
get the design to run. I have wondered when that will cause thermal
problems, such as requiring a heat sink.

This failure mode isn't the same as a badly constructed bitstream
violating DRC rules and creating device damage that would be difficult
to detect as it may only exist at a few points within the device.

Well, a small ring oscillator would cause local heating, which
may be enough to damage a small portion of the device.

Recent Xilinx FPGAs with the System Monitor feature (renamed to XADC
in the 7 Series families) have the ability to shutdown the device if
the junction temperature exceeds user defined values. This can be
used to prevent this type of thermal damage, but it would not be able
to prevent localized damage due to bad bitstreams.

That should work for heating over the whole array, but maybe not
good enough for a localized ring oscillator.

Though shouldn't DRC be able to detect ring oscillators?
Is it that hard to do?

-- glen

 

[Ed McGettigan]

On Mar 19, 6:49 pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:

Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:
On Mar 19, 10:48 am, Kolja Sulimma <ksuli...@googlemail.com> wrote:

(snip)

It was at FPL1999 that someone presented this as a sidenote in a
presentation about some
other topic. They said they were able to damage Altera FPGAs by
instantiating ring counters.

(snip)

What you remember as a ring counter was probably a ring oscillator
that was used to get a high frequency clock to drive the rest of the
FPGA logic with a high toggle rate.  Without system level
considerations and monitoring the power requirements could easily push
the device into a thermal region that would damage the device.   The
HDL and bitstream itself is perfectly valid, it is the thermal
management that is to blame for the destruction.   The failure points
would likely be wide spread through the device.

The designs that I am interested in have many signals changing
on average every other clock cycle, and clocked as fast as I can
get the design to run.  I have wondered when that will cause thermal
problems, such as requiring a heat sink.

This failure mode isn't the same as a badly constructed bitstream
violating DRC rules and creating device damage that would be difficult
to detect as it may only exist at a few points within the device.

Well, a small ring oscillator would cause local heating, which
may be enough to damage a small portion of the device.

Recent Xilinx FPGAs with the System Monitor feature (renamed to XADC
in the 7 Series families) have the ability to shutdown the device if
the junction temperature exceeds user defined values.  This can be
used to prevent this type of thermal damage, but it would not be able
to prevent localized damage due to bad bitstreams.

That should work for heating over the whole array, but maybe not
good enough for a localized ring oscillator.

Though shouldn't DRC be able to detect ring oscillators?  
Is it that hard to do?

-- glen

It sounds like you have a pretty aggressive design and if there is a
lot of logic in the design than it would be possible to exceed Tj
without a heat sink. The Xilinx XPE (estimator) and XPA (analyzer)
can help you out with determining the expectated power and thermal
requirements. See http://www.xilinx.com/power for more details.

I wouldn't be worried about a ring oscillator creating any significant
localized heating in an FPGA to the point that it would damage the
device. Ring oscillator circuits are used extensively in the device
testing and I've never heard of an RMA linked to anything that even
remotely resembled damage due to localized Tj extremes.

If you do have ring oscillators in your design you will get some
warnings in the timing analysis, but otherwise they are permitted as
there isn't anything wrong with a ring oscillator.

Ed McGettigan
--
Xilinx Inc.

 

[rickman]

On Mar 19, 3:59 pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:

On Mar 19, 10:48 am, Kolja Sulimma <ksuli...@googlemail.com> wrote:

On 15 Mrz., 02:28, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:

You can fry an FPGA with VDHL and vendor synthesis software.
This has been demonstrated at the FPL conference a decade ago.

I am quite surprised about this. Can you provide any additional
material on how this was achieved?

There aren't any scenarios, other than internal tri-state contention,
that I can come up with to make this happen with a proven tool chain.

It was at FPL1999 that someone presented this as a sidenote in a
presentation about some
other topic. They said they were able to damage Altera FPGAs by
instantiating ring counters.
This resulted in spontaneous applause by the Xilinx crowd in the
audience but the presenter
made clear that this attack also applies to Xilinx Fpgas and that it
is computationally infeasible
to detect such attacks.

I just browsed through the list of papers of that conferencehttp://www.informatik.uni-trier.de/~ley/db/conf/fpl/fpl1999.html
but can't remember, which paper it was.

There were some prominent people from Xilinx present (Peter Alfke,
Steve Trimberger, Steve Guccione and some other Steve). Maybe one of
them remembers.

Kolja Sulimma
cronologic

What you remember as a ring counter was probably a ring oscillator
that was used to get a high frequency clock to drive the rest of the
FPGA logic with a high toggle rate.  Without system level
considerations and monitoring the power requirements could easily push
the device into a thermal region that would damage the device.   The
HDL and bitstream itself is perfectly valid, it is the thermal
management that is to blame for the destruction.   The failure points
would likely be wide spread through the device.

This failure mode isn't the same as a badly constructed bitstream
violating DRC rules and creating device damage that would be difficult
to detect as it may only exist at a few points within the device.

Maybe I am not familiar with the damage you are referring to. If you
send a badly constructed bit stream to a part that violates DRC rules,
how does it damage a part other than causing overheating? Are you
saying that there exists configuration settings that do damage through
over voltage application to some feature in the chip?

Recent Xilinx FPGAs with the System Monitor feature (renamed to XADC
in the 7 Series families) have the ability to shutdown the device if
the junction temperature exceeds user defined values.  This can be
used to prevent this type of thermal damage, but it would not be able
to prevent localized damage due to bad bitstreams.

Has Xilinx been able to cause this damage?

Rick

 

[Ed McGettigan]

On Mar 19, 11:17 pm, rickman <gnu...@gmail.com> wrote:

On Mar 19, 3:59 pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:





On Mar 19, 10:48 am, Kolja Sulimma <ksuli...@googlemail.com> wrote:

On 15 Mrz., 02:28, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:

You can fry an FPGA with VDHL and vendor synthesis software.
This has been demonstrated at the FPL conference a decade ago.

I am quite surprised about this. Can you provide any additional
material on how this was achieved?

There aren't any scenarios, other than internal tri-state contention,
that I can come up with to make this happen with a proven tool chain.

It was at FPL1999 that someone presented this as a sidenote in a
presentation about some
other topic. They said they were able to damage Altera FPGAs by
instantiating ring counters.
This resulted in spontaneous applause by the Xilinx crowd in the
audience but the presenter
made clear that this attack also applies to Xilinx Fpgas and that it
is computationally infeasible
to detect such attacks.

I just browsed through the list of papers of that conferencehttp://www.informatik.uni-trier.de/~ley/db/conf/fpl/fpl1999.html
but can't remember, which paper it was.

There were some prominent people from Xilinx present (Peter Alfke,
Steve Trimberger, Steve Guccione and some other Steve). Maybe one of
them remembers.

Kolja Sulimma
cronologic

What you remember as a ring counter was probably a ring oscillator
that was used to get a high frequency clock to drive the rest of the
FPGA logic with a high toggle rate.  Without system level
considerations and monitoring the power requirements could easily push
the device into a thermal region that would damage the device.   The
HDL and bitstream itself is perfectly valid, it is the thermal
management that is to blame for the destruction.   The failure points
would likely be wide spread through the device.

This failure mode isn't the same as a badly constructed bitstream
violating DRC rules and creating device damage that would be difficult
to detect as it may only exist at a few points within the device.

Maybe I am not familiar with the damage you are referring to.  If you
send a badly constructed bit stream to a part that violates DRC rules,
how does it damage a part other than causing overheating?  Are you
saying that there exists configuration settings that do damage through
over voltage application to some feature in the chip?

Recent Xilinx FPGAs with the System Monitor feature (renamed to XADC
in the 7 Series families) have the ability to shutdown the device if
the junction temperature exceeds user defined values.  This can be
used to prevent this type of thermal damage, but it would not be able
to prevent localized damage due to bad bitstreams.

Has Xilinx been able to cause this damage?

Rick- Hide quoted text -

- Show quoted text -

This is well off the original topic....

If "this damage" refers to localized thermal issues then not to the
best of my knowledge. Hot spot (localized) thermal imaging analysis
is done on new parts to determine if any issues exist and occasionally
something in a hard block (PowerPC, BlockRAM, PCIe, etc) is found and
corrected in a mask step before production.

If "this damage" refers to exceeding the junction temperature then yes
this is a real issue and high temperatures with voltage will damage
the part. This is a common technique used for device lifetime
reliability testing with both over voltage and over temperature
conditions used as acceleration factors to reduce the time required
for testing.

Ed McGettigan
--
Xilinx Inc.

 

[geobsd]

On Mar 20, 6:16 pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:

This is well off the original topic....
not so far ed, you stated that bit-stream spec published will make bad

bit-streams in use and that will damage fpgas
so the discuss went on fpgas damages
and this is interesting !
so please continu all

 

[jay]

Ed McGettigan <ed.mcgettigan@xilinx.com> wrote:

On Mar 19, 6:49 pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:
On Mar 19, 10:48 am, Kolja Sulimma <ksuli...@googlemail.com> wrote:

(snip)

It was at FPL1999 that someone presented this as a sidenote in a
presentation about some
other topic. They said they were able to damage Altera FPGAs by
instantiating ring counters.

(snip)

What you remember as a ring counter was probably a ring oscillator
that was used to get a high frequency clock to drive the rest of the
FPGA logic with a high toggle rate. Without system level
considerations and monitoring the power requirements could easily push
the device into a thermal region that would damage the device. The
HDL and bitstream itself is perfectly valid, it is the thermal
management that is to blame for the destruction. The failure points
would likely be wide spread through the device.

The designs that I am interested in have many signals changing
on average every other clock cycle, and clocked as fast as I can
get the design to run. I have wondered when that will cause thermal
problems, such as requiring a heat sink.

This failure mode isn't the same as a badly constructed bitstream
violating DRC rules and creating device damage that would be difficult
to detect as it may only exist at a few points within the device.

Well, a small ring oscillator would cause local heating, which
may be enough to damage a small portion of the device.

Recent Xilinx FPGAs with the System Monitor feature (renamed to XADC
in the 7 Series families) have the ability to shutdown the device if
the junction temperature exceeds user defined values. This can be
used to prevent this type of thermal damage, but it would not be able
to prevent localized damage due to bad bitstreams.

That should work for heating over the whole array, but maybe not
good enough for a localized ring oscillator.

Though shouldn't DRC be able to detect ring oscillators?
Is it that hard to do?

-- glen

It sounds like you have a pretty aggressive design and if there is a
lot of logic in the design than it would be possible to exceed Tj
without a heat sink. The Xilinx XPE (estimator) and XPA (analyzer)
can help you out with determining the expectated power and thermal
requirements. See http://www.xilinx.com/power for more details.

I wouldn't be worried about a ring oscillator creating any significant
localized heating in an FPGA to the point that it would damage the
device. Ring oscillator circuits are used extensively in the device
testing and I've never heard of an RMA linked to anything that even
remotely resembled damage due to localized Tj extremes.

If you do have ring oscillators in your design you will get some
warnings in the timing analysis, but otherwise they are permitted as
there isn't anything wrong with a ring oscillator.

Ed McGettigan
--
Xilinx Inc.

My own testing has shown this. I've been pretty abusive to one particular
S3E with ring oscillators, and it's ticking along just fine.

 

[glen herrmannsfeldt]

jay <jay@jayt.org> wrote:

(snip, I wrote)

Well, a small ring oscillator would cause local heating, which
may be enough to damage a small portion of the device.

(someone else wrote)

I wouldn't be worried about a ring oscillator creating any significant
localized heating in an FPGA to the point that it would damage the
device. Ring oscillator circuits are used extensively in the device
testing and I've never heard of an RMA linked to anything that even
remotely resembled damage due to localized Tj extremes.

(snip)

My own testing has shown this. I've been pretty abusive to one particular
S3E with ring oscillators, and it's ticking along just fine.

It seems to me that the smallest is one inverter. If you do that
with a single CMOS inverter, I believe it just sits at the switch
point dissipating power. (In the CD4000 days, we were cautioned
not to leave inputs floating, as they can float to the switch
point.) In an FPGA, the routing delay might be long enough to
allow oscillation.

-- glen

 

[Gabor]

On Wednesday, March 23, 2011 2:53:54 PM UTC-4, glen herrmannsfeldt wrote:

jay <j...@jayt.org> wrote:

(snip, I wrote)
Well, a small ring oscillator would cause local heating, which
may be enough to damage a small portion of the device.

(someone else wrote)
I wouldn't be worried about a ring oscillator creating any significant
localized heating in an FPGA to the point that it would damage the
device. Ring oscillator circuits are used extensively in the device
testing and I've never heard of an RMA linked to anything that even
remotely resembled damage due to localized Tj extremes.

(snip)
My own testing has shown this. I've been pretty abusive to one particular
S3E with ring oscillators, and it's ticking along just fine.

It seems to me that the smallest is one inverter. If you do that
with a single CMOS inverter, I believe it just sits at the switch
point dissipating power. (In the CD4000 days, we were cautioned
not to leave inputs floating, as they can float to the switch
point.) In an FPGA, the routing delay might be long enough to
allow oscillation.

-- glen

In an FPGA you can't get close to the simplicity of
a single inverter. Even if you consider a LUT programmed
to invert its input, you still have some additional
buffering in the feedback path. So I wouldn't expect
to be able to reproduce the linear feedback behavior
of an unbuffered CMOS inverter. It might be too fast
to clock anything useful in the FPGA but a single
looped back "inverter" would probably still oscillate.

-- Gabor

 

[glen herrmannsfeldt]

Gabor <gabor@alacron.com> wrote:

(snip, I wrote)

It seems to me that the smallest is one inverter. If you do that
with a single CMOS inverter, I believe it just sits at the switch
point dissipating power. (In the CD4000 days, we were cautioned
not to leave inputs floating, as they can float to the switch
point.) In an FPGA, the routing delay might be long enough to
allow oscillation.

In an FPGA you can't get close to the simplicity of
a single inverter. Even if you consider a LUT programmed
to invert its input, you still have some additional
buffering in the feedback path. So I wouldn't expect
to be able to reproduce the linear feedback behavior
of an unbuffered CMOS inverter. It might be too fast
to clock anything useful in the FPGA but a single
looped back "inverter" would probably still oscillate.

Yes, that is what I thought. I should have been a little stronger
in my wording, but, not having actually tried it, "probably"
seemed safe to me.

-- glen

 

[mac]

I no langer have the piece, but I used to keep a X. Chip that had holes
blown through the lid when it got reloaded from a bsd ROM. My understanding
is that most chips now verify a checksum on loading.

--
mac the naĂŻf