New feauture in Spartan-6 FPGA's: SELF DESTRUCT !!

Bitstreams must not contain a sync word followed by all 1=92s. This
condition might
cause damage to the device.

Is this an feature or bug? should this go into ERRATA and be fixed
ASAP??

Antti

On Jun 24, 2:14=A0pm, Antti <Antti.Luk...@googlemail.com> wrote:
> Bitstreams must not contain a sync word followed by all 1=92s. This
> condition might
> cause damage to the device.
>
> Is this an feature or bug? should this go into ERRATA and be fixed
> ASAP??
>
> Antti

Someone might have a use for that...

Andy

On Jun 24, 11:17=A0pm, Andy <jonesa...@comcast.net> wrote:
> On Jun 24, 2:14=A0pm, Antti <Antti.Luk...@googlemail.com> wrote:
>
> > Bitstreams must not contain a sync word followed by all 1=92s. This
> > condition might
> > cause damage to the device.
>
> > Is this an feature or bug? should this go into ERRATA and be fixed
> > ASAP??
>
> > Antti
>
> Someone might have a use for that...
>
> Andy

Altera making Xilinx-Virus?

humm that not so funny actually...
Antti

Antti wrote:
> Bitstreams must not contain a sync word followed by all 1�s. This
> condition might
> cause damage to the device.
>
> Is this an feature or bug? should this go into ERRATA and be fixed
> ASAP??
>
> Antti

Perhaps Spartan 6 can be added to this list!!

http://en.wikipedia.org/wiki/Halt_and_Catch_Fire

Antti wrote:
> Bitstreams must not contain a sync word followed by all 1�s. This
> condition might
> cause damage to the device.
> 
> Is this an feature or bug? should this go into ERRATA and be fixed
> ASAP??
> 
> Antti

This has been confirmed to be an error in the document and will be 
updated in the next revision.

It is possible to damage an FPGA with a badly corrupted bitstream, but 
it takes more than a sync word followed by ones to do this.

Ed McGettigan
--
Xilinx Inc.

On 25 June, 23:31, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:
> Antti wrote:
> > Bitstreams must not contain a sync word followed by all 1=92s. This
> > condition might
> > cause damage to the device.
>
> > Is this an feature or bug? should this go into ERRATA and be fixed
> > ASAP??
>
> > Antti
>
> This has been confirmed to be an error in the document and will be
> updated in the next revision.
>
> It is possible to damage an FPGA with a badly corrupted bitstream, but
> it takes more than a sync word followed by ones to do this.
>
> Ed McGettigan
That could potentially be an interesting feature. I can't remember
exactly now, but Motorola - now Freescale - had a DSP that can blow
itself up if you overdrive the PLL and some security folks did use
that to some end.

-M

On Jun 24, 12:14=A0pm, Antti <Antti.Luk...@googlemail.com> wrote:
> Bitstreams must not contain a sync word followed by all 1=92s. This
> condition might
> cause damage to the device.
>
> Is this an feature or bug? should this go into ERRATA and be fixed
> ASAP??
>
> Antti

Hmm, I put this in the same category as a warning stating "DO NOT
CRAWL ACROSS BROKEN GLASS."

What are the odds of "accidentally" sending a sync. word followed by a
few million '1' bits?  I'm sure that someone must have done it, hence
the errata notice.  I'm not sure this would be worth a $1M mask spin
to fix (unless there are more important issues as well).

You can damage lots of semi's by misprogramming them.  Have the
outputs from two interface devices fight on a bus and just watch the
gladiatorial fun!

-- Steve Knapp
   Prevailing Technology, Inc.
   www.prevailing-technology.cm

On Jun 26, 7:04=A0pm, Prevailing over Technology <steve.kn...@prevailing-
technology.com> wrote:
> On Jun 24, 12:14=A0pm, Antti <Antti.Luk...@googlemail.com> wrote:
>
> > Bitstreams must not contain a sync word followed by all 1=92s. This
> > condition might
> > cause damage to the device.
>
> > Is this an feature or bug? should this go into ERRATA and be fixed
> > ASAP??
>
> > Antti
>
> Hmm, I put this in the same category as a warning stating "DO NOT
> CRAWL ACROSS BROKEN GLASS."
>
> What are the odds of "accidentally" sending a sync. word followed by a
> few million '1' bits? =A0I'm sure that someone must have done it, hence
> the errata notice. =A0I'm not sure this would be worth a $1M mask spin
> to fix (unless there are more important issues as well).
>
> You can damage lots of semi's by misprogramming them. =A0Have the
> outputs from two interface devices fight on a bus and just watch the
> gladiatorial fun!
>
> -- Steve Knapp
> =A0 =A0Prevailing Technology, Inc.
> =A0 =A0www.prevailing-technology.cm

its not that, only 11's
you did not read all the fine print

scenarion 1:
start programming, erase, write sync written, POWER OFF, POWER ON FPGA
---> PUFFFF BLOW UP

the above is not 1:MIO odds case or is it?

now, i did include partial info, not only 11111 but also "just bad"
bit file can damage
i mean bit files that are INVALID, without proper CRC and trailer

and this seems to be so SEVERE and common to happen, that xilinx
issued special case HOW TO WRITE FLASH
(in order to prevent blow up)

so from Xilinx docs for S-6

procedure for writing nv memories for S-6
ERASE
skip over sync (do not write it), WRITE the bitstream
seek back, write SYNC

for any other FPGA except S-6 this like procedure for configuration
memory is not required or recommended

ASFAIK at least

of course it is possible to write KNOWN BLOW UP MY FPGA bitstream, but
those would be
valid bitstreams that will overstress the silicon, but INVALID
bitstreams (that should not release
the FPGA to be functional) should not damage the FPGA...

imho


Antti

Antti.Lukats@googlemail.com <Antti.Lukats@googlemail.com> wrote:
(big snip)
 
< scenarion 1:
< start programming, erase, write sync written, POWER OFF, POWER ON FPGA
< ---> PUFFFF BLOW UP
 
< the above is not 1:MIO odds case or is it?
 
< now, i did include partial info, not only 11111 but also "just bad"
< bit file can damage
< i mean bit files that are INVALID, without proper CRC and trailer
 
< and this seems to be so SEVERE and common to happen, that xilinx
< issued special case HOW TO WRITE FLASH
< (in order to prevent blow up)

I had thought that previous FPGA families (I might be remembering
XC4000 series) didn't exit reconfiguration mode until a valid CRC
was seen.  That would make it unlikely that a random or incomplete
bit stream would cause damage.  It seems that isn't the case anymore.

-- glen 

On Jun 26, 8:28=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> Antti.Luk...@googlemail.com <Antti.Luk...@googlemail.com> wrote:
>
> (big snip)
>
> < scenarion 1:
> < start programming, erase, write sync written, POWER OFF, POWER ON FPGA
> < ---> PUFFFF BLOW UP
>
> < the above is not 1:MIO odds case or is it?
>
> < now, i did include partial info, not only 11111 but also "just bad"
> < bit file can damage
> < i mean bit files that are INVALID, without proper CRC and trailer
>
> < and this seems to be so SEVERE and common to happen, that xilinx
> < issued special case HOW TO WRITE FLASH
> < (in order to prevent blow up)
>
> I had thought that previous FPGA families (I might be remembering
> XC4000 series) didn't exit reconfiguration mode until a valid CRC
> was seen. =A0That would make it unlikely that a random or incomplete
> bit stream would cause damage. =A0It seems that isn't the case anymore.
>
> -- glen

yes, ASFAIK all FPGA's except Spartan-6 remain in CONFIG mode
until valid CRC and post-amble...

well, i think it all is really ES errata
but for some reason there is no errata sheet available, and it is
described in regular datasheet

Antti