cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Visitor
Visitor
351 Views
Registered: ‎08-31-2020

Test to detect defective cell in a Virtex 7

Jump to solution

I have a Virtex 7 that I suspect has damaged cells or RAM cells. I already know that one I/O is damaged.

Kinldy advise about the best way to test the Cells and resources of a Virtex 7.

Is it possible to instruct Vivado to do not use certain cells?

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Guide
Guide
253 Views
Registered: ‎01-23-2009

The only explanation I could find up to now is that some cell in that FPGA is not doing what it should.

That is clearly not "the only explanation". A design is only "guaranteed" to run on all copies of an FPGA if the design is completely and correctly constrained. If there are paths that are incorrectly constrained or unconstrained, this can result in designs that work intermittently - it is not uncommon for these to work apparently correctly on some chips and not on others.

There should be a way to test the 100 % of the FPGA resources in production, right? Is this test available?

All FPGAs are 100% tested when they leave the factory. As I said in my earlier post, there is no way to "repeat" these tests in the field; these tests are not released by Xilinx.

Furthermore, it is very uncommon for an FPGA to fail in this way. Most field failures have to do with improper handling, which tends to affect the circuitry around the I/Os - it is very rare for an internal cell to just fail. While nothing is impossible it is certainly extremely uncommon. So before you come to that conclusion I would spend more time on the more common cause of behavior like this, which is incomplete/incorrect constraints. There are others, too, like bad power supplies, board manufacturing defects, marginal signal integrity on the board... Again, most of these are far more common than a random post-production internal FPGA failure.

Avrum

View solution in original post

3 Replies
Highlighted
Guide
Guide
326 Views
Registered: ‎01-23-2009

I am pretty sure there is no supported mechanism to diagnose an FPGA failure.

Furthermore I am also pretty sure that Xilinx doesn't support using a damaged FPGA; the FPGA should be replaced. There is no mechanism specifically for avoiding the use of a resource because it is damaged. That being said, Vivado is pretty flexible; there is almost certainly a way to force an implementation not to use a particular cell (I can think of at least one - defining an exclusive PBLOCK for the CLB that contains the damaged cell and not assign any logic to it)... But again this isn't recommended - if one cell is damaged, there is no way to know what other damage has occurred to the chip - it really should be discarded...

Avrum

Highlighted
Visitor
Visitor
260 Views
Registered: ‎08-31-2020

Hi Avrum,

Thank you for your support, I really apreciate.

It is hard to be sure that the FPGA is damaged. We have the same design in 3 identical FPGA. two of them works as expected and the other one does not.

The only explanation I could find up to now is that some cell in that FPGA is not doing what it should.

There should be a way to test the 100 % of the FPGA resources in production, right? Is this test available?

Regards

 

0 Kudos
Highlighted
Guide
Guide
254 Views
Registered: ‎01-23-2009

The only explanation I could find up to now is that some cell in that FPGA is not doing what it should.

That is clearly not "the only explanation". A design is only "guaranteed" to run on all copies of an FPGA if the design is completely and correctly constrained. If there are paths that are incorrectly constrained or unconstrained, this can result in designs that work intermittently - it is not uncommon for these to work apparently correctly on some chips and not on others.

There should be a way to test the 100 % of the FPGA resources in production, right? Is this test available?

All FPGAs are 100% tested when they leave the factory. As I said in my earlier post, there is no way to "repeat" these tests in the field; these tests are not released by Xilinx.

Furthermore, it is very uncommon for an FPGA to fail in this way. Most field failures have to do with improper handling, which tends to affect the circuitry around the I/Os - it is very rare for an internal cell to just fail. While nothing is impossible it is certainly extremely uncommon. So before you come to that conclusion I would spend more time on the more common cause of behavior like this, which is incomplete/incorrect constraints. There are others, too, like bad power supplies, board manufacturing defects, marginal signal integrity on the board... Again, most of these are far more common than a random post-production internal FPGA failure.

Avrum

View solution in original post