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

Antti.Lukats@googlemail.com <Antti.Lukats@googlemail.com> 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 <gah@ugcs.caltech.edu> wrote:

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

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=A0am, "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=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."

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" <gah@ugcs.caltech.edu> wrote in message 
news:h233ph$de8$1@naig.caltech.edu...
> 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 <ed.mcgettigan@xilinx.com> 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=A0am, 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. =A0 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. =A0On more than one
> occasion the bitstreams were loaded into the wrong device leading to
> catastrophic failure of the device. =A0This 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=A0pm, 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

Antti.Lukats@googlemail.com 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.