FPGA Central

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

On Jun 24, 2:14*pm, Antti <Antti.Luk...@googlemail.com> 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

Someone might have a use for that...

Andy

On Jun 24, 11:17*pm, Andy <jonesa...@comcast.net> wrote:
> On Jun 24, 2:14*pm, Antti <Antti.Luk...@googlemail.com> 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
>
> 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’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
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*pm, Antti <Antti.Luk...@googlemail.com> 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

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*pm, Prevailing over Technology <steve.kn...@prevailing-
technology.com> wrote:
> On Jun 24, 12:14*pm, Antti <Antti.Luk...@googlemail.com> 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
>
> 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

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

[email protected] <[email protected]> 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*pm, 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. *That would make it unlikely that a random or incomplete
> bit stream would cause damage. *It 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

[email protected] <[email protected]> wrote:
(snip)

> 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

Without making too many guesses about the internal structure
of FPGAs, it might take fewer transistors if some internal
signals are active as the bits are loaded. It sounds like
zeros are good and ones are bad.

-- glen

glen herrmannsfeldt <[email protected]> wrote:

>[email protected] <[email protected]> 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.

I did destroy two Spartan2 devices while developing a JTAG download
implementation and numerous times a chip got very hot.

--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
"If it doesn't fit, use a bigger hammer!"
--------------------------------------------------------------

On Jun 27, 4:29*am, "Antti.Luk...@googlemail.com"
> 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

See Ed's post.
Is this a case of a step-back in the Silicon, or a Step back in the
DOCs ?
Did they explicitly say the CRC check was bypassed ?

["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. "]

Is that 'design-corrupted', but with a valid CRC ?

-jg

On Jun 26, 12:29 pm, "Antti.Luk...@googlemail.com"
<Antti.Luk...@googlemail.com> wrote:
> On Jun 26, 7:04 pm, Prevailing over Technology <steve.kn...@prevailing-
>
> technology.com> wrote:
> > On Jun 24, 12:14 pm, Antti <Antti.Luk...@googlemail.com> 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
>
> > Hmm, I put this in the same category as a warning stating "DO NOT
> > CRAWL ACROSS BROKEN GLASS."

I see it more as a matter of "warning, and don't blame us if...". I'm
sure this doesn't happen often and when it does it is not in any way
intentional or even inadvertent as in, "I didn't think to prevent
that...". I can only think this would be a real fluke, but if your
$1000 chip fries because of such a fluke, someone is going to ask you
a few questions. But then I guess there are no $1000 Spartans, eh?

BTW, aren't you the guy I owe a punch in the nose... er, I mean a pint
of beer? I think you told me that Xilinx "was committed to supporting
partial reconfiguration in the Spartan 3 devices". That wouldn't be
why you fled
Xilinx would it? ;^)


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

I was with you up to this point. "so SEVERE"??? That is a matter of
damned if they do and damned if they don't. The fact that Xilinx has
pointed out a flaw and even taken steps to help users prevent the
inadvertent misuse of the parts certainly shouldn't be used against
them. There has always been the possibility of a bad bit stream
getting past the security logic and doing damage to a chip. Ed's post
above seems to be saying that the reports of the Spartan-6's death has
been greatly exaggerated.


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

How does the chip know a valid bitstream from an invalid one? There
are always bitstreams that the logic can't see as invalid, good
checksum but bad configuration bits.

Rick

-jg wrote:
> On Jun 27, 4:29 am, "Antti.Luk...@googlemail.com"
>> 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
>
> See Ed's post.
> Is this a case of a step-back in the Silicon, or a Step back in the
> DOCs ?
> Did they explicitly say the CRC check was bypassed ?
>
> ["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. "]
>
> Is that 'design-corrupted', but with a valid CRC ?
>
> -jg

Assuming that the bitstream information is correct up until the real
configuration frame data starts, damage may occur with a corrupted
bitstream after that point. Loading all ones can be particular
problematic as most configuration cells are active high.

Configuration of an FPGA is a continual process and as each frame is
filled the data is written in to the actual configuration cells. If a
corrupt bitstream starts connecting multiple drivers with different
states to the same nets then contention can occur and damage may result
if the contention is severe enough and left in that state for long
enough. The CRC check at the end of the bitstream won't avoid the
contention as it is already occurring in the device.

Back in the original Virtex days, we had one customer that had poor
source code control and communication between designers and board techs
coupled with different die sizes on the same board. On more than one
occasion the bitstreams were loaded into the wrong device leading to
catastrophic failure of the device. This was fixed in all future
families with additional header information and configuration state
machine logic to prevent the wrong bitstream from being loaded.

Spartan-6 is as robust in this area than previous Spartan families.

Ed McGettigan
--
Xilinx Inc.

"glen herrmannsfeldt" <[email protected]> wrote in message
news:h233ph$de8$[email protected]..
> It sounds like zeros are good and ones are bad.
>

That's been my experience too...it's due to the pointy-ness of the 1. Those
1s can nick some of the internals of the FPGA which can lead to internal
shorts between power and ground. If you have a bitstream with ~million or
so 1s in them you have a fairly good chance of running into this problem.
The 0s have no sharp edges and generally load just fine, the only problem
can be if some of them inadvertantly become Os which can get stuck in the
bitstream causing blockage and a bloating of the device which will then fail
to load.

KJ

Ed McGettigan <[email protected]> wrote:

< Assuming that the bitstream information is correct up until the real
< configuration frame data starts, damage may occur with a corrupted
< bitstream after that point. Loading all ones can be particular
< problematic as most configuration cells are active high.

Given that many programmable memories clear to 1's, it would
have been convenient to include an inverter such that 1's were
safer than 0's.

I remember in the early EPROM days, I believe the 1702 cleared
to zeros, and then the 2708 cleared to ones. Zero was convenient
for processors with NOP at X'00'.

-- glen

On Jun 27, 3:22*am, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:
> -jg wrote:
> > On Jun 27, 4:29 am, "Antti.Luk...@googlemail.com"
> >> 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
>
> > See Ed's post.
> > Is this a case of a step-back in the Silicon, or a Step back in the
> > DOCs ?
> > Did they explicitly say the CRC check was bypassed ?
>
> > ["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. "]
>
> > Is that 'design-corrupted', but with a valid CRC ?
>
> > -jg
>
> Assuming that the bitstream information is correct up until the real
> configuration frame data starts, damage may occur with a corrupted
> bitstream after that point. Loading all ones can be particular
> problematic as most configuration cells are active high.
>
> Configuration of an FPGA is a continual process and as each frame is
> filled the data is written in to the actual configuration cells. If a
> corrupt bitstream starts connecting multiple drivers with different
> states to the same nets then contention can occur and damage may result
> if the contention is severe enough and left in that state for long
> enough. * The CRC check at the end of the bitstream won't avoid the
> contention as it is already occurring in the device.
>
> Back in the original Virtex days, we had one customer that had poor
> source code control and communication between designers and board techs
> coupled with different die sizes on the same board. *On more than one
> occasion the bitstreams were loaded into the wrong device leading to
> catastrophic failure of the device. *This was fixed in all future
> families with additional header information and configuration state
> machine logic to prevent the wrong bitstream from being loaded.
>
> Spartan-6 is as robust in this area than previous Spartan families.
>
> Ed McGettigan
> --
> Xilinx Inc.

Ed,

this can not be, see SYNC + 1111....
will not even start the configuration as there is no valid pre-amble
and frame header !!!!
so ___none___ of the 1's following the SYNC actually change any bits
of the internal
configuration ram at all...(so FPGA should stay fully UNCONFIGURED!)

if such event still is dangerous, it is more likely similar to the
NBTI problem in
Virtex-4 where silicon was damaged if POWERED and NOT CONFIGURED

so now silicon gets damaged if SYNC seen, but no valid bitstream seen

well, this is how i understand the documentation the way the it is
published.

maybe its error in documentation or in my understanding

Antti

On Jun 27, 12:22*pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:
> The CRC check at the end of the bitstream won't avoid the
> contention as it is already occurring in the device.

Interesting. So when the CRC finally trundles into the device some ms
later,
does that 'disable' config and save the possible contention ?
- if not, what exactly is the CRC for (given that config occurs prior
to it arriving) ?

-jg

[email protected] wrote:
> On Jun 27, 3:22 am, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:
>> -jg wrote:
>>> On Jun 27, 4:29 am, "Antti.Luk...@googlemail.com"
>>>> 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
>>> See Ed's post.
>>> Is this a case of a step-back in the Silicon, or a Step back in the
>>> DOCs ?
>>> Did they explicitly say the CRC check was bypassed ?
>>> ["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. "]
>>> Is that 'design-corrupted', but with a valid CRC ?
>>> -jg
>> Assuming that the bitstream information is correct up until the real
>> configuration frame data starts, damage may occur with a corrupted
>> bitstream after that point. Loading all ones can be particular
>> problematic as most configuration cells are active high.
>>
>> Configuration of an FPGA is a continual process and as each frame is
>> filled the data is written in to the actual configuration cells. If a
>> corrupt bitstream starts connecting multiple drivers with different
>> states to the same nets then contention can occur and damage may result
>> if the contention is severe enough and left in that state for long
>> enough. The CRC check at the end of the bitstream won't avoid the
>> contention as it is already occurring in the device.
>>
>> Back in the original Virtex days, we had one customer that had poor
>> source code control and communication between designers and board techs
>> coupled with different die sizes on the same board. On more than one
>> occasion the bitstreams were loaded into the wrong device leading to
>> catastrophic failure of the device. This was fixed in all future
>> families with additional header information and configuration state
>> machine logic to prevent the wrong bitstream from being loaded.
>>
>> Spartan-6 is as robust in this area than previous Spartan families.
>>
>> Ed McGettigan
>> --
>> Xilinx Inc.
>
> Ed,
>
> this can not be, see SYNC + 1111....
> will not even start the configuration as there is no valid pre-amble
> and frame header !!!!

Yes Antti, you are right. I said this in an earlier post that the
current warning in the S-6 Configuration User Guide is wrong. We will
fix this in the next revision.

Ed McGettigan
--
Xilinx Inc.