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