Programmable Devices
CPLDs, FPGAs, SoC FPGAs, Configuration, and Transceivers
20736 Discussions

Testing of internal resources

Altera_Forum
Honored Contributor II
1,407 Views

Does anyone have a simple code set for testing internal FPGA resources to aide in creating a BIST type test methodology. 

 

Something like a LUT based Pattern generator, the block to be tested (LUT - F/F - RAM), and the Compare block. 

 

This could be either expanded or repeated across the DIE based on size of part. 

The purpose of which is to test the internal structures AND interconnections to verify that a part on a board is 'good'. This test set could be broken up into multiple images with different loads so that I can cover the entire part to be tested. 

 

An on board Processor is available to load and monitor the results. 

 

After the testing, then the desired design will be loaded for run time usage. 

 

All thoughts welcome. 

Thanks.
0 Kudos
8 Replies
Altera_Forum
Honored Contributor II
612 Views

Hi, 

 

Altera's parts are fully tested during manufacturing and are guarenteed to work. Why would you want to perform this testing yourself? 

 

I can tell you that it takes many, many designs to fully exercise every possible connection and resource in the chip for funcitionality. If on top of that you start to worry about what the speed of the chip is, and that every resource passes for speed... 

 

Regards, 

 

Paul Leventis
0 Kudos
Altera_Forum
Honored Contributor II
612 Views

The full testing is understood. My end customer desires to be able to do something similar to BIST to be able to certify that a particular chip is in good working order before inserting the payload design. 

 

The customer is always right. 

 

Thanks, 

Avatar
0 Kudos
Altera_Forum
Honored Contributor II
612 Views

Paul, 

 

What if you have a requirement to run a BIST on every power-up? It's not uncommon in high-reliability applications - especially ones with very long service lives. 

 

As for an answer to the original question, I wonder if it would be possible to somehow use the SEU error detection (CRC_Error) circuitry as part of a device test.
0 Kudos
Altera_Forum
Honored Contributor II
612 Views

This question is indeed very interesting, especially for safety-critical systems. It would be great to get an Altera response on this

0 Kudos
Altera_Forum
Honored Contributor II
612 Views

The CRC_ERROR is available in Stratix and later FPGA devices. It is useful for checking the CRAM bits (Configuration data in the device). So knowing that Altera devices are 100% tested and that the device is still correctly configured if CRC_ERROR pin is not flagging an error should be good enough.

0 Kudos
Altera_Forum
Honored Contributor II
612 Views

While customer being always right is true, the first step is teaching the customer about the matters he/she should be concerned about. FPGAs are not like RAM chips which get exercised at 100% (theoretically) during the normal operation of the product. 

Once you synthesize and route/fit an FPGA design, it will stay in place (using the same LEs) during the lifetime of the product, or until you recompile the design. If you need BIST, implement it into your design, the same way you would do when designing an ASIC. Testing the unused LEs does not make much sense.
0 Kudos
Altera_Forum
Honored Contributor II
612 Views

Hi, 

 

To answer the question, there is no easy way to write a BIST that will test every bit of circuitry you plan to exercise in a design every time you power up. Sorry! 

 

- Paul
0 Kudos
Altera_Forum
Honored Contributor II
612 Views

 

--- Quote Start ---  

Hi, 

 

To answer the question, there is no easy way to write a BIST that will test every bit of circuitry you plan to exercise in a design every time you power up. Sorry! 

 

- Paul 

--- Quote End ---  

 

 

Actually, this is fairly common in high-reliability ASIC designs. There are tools out there (Like Mentor's L-BIST) that will take your design, add the ability to control and observe the design's nodes and give you something like a processor interface for driving the tests. I think these tools could be used on an FPGA design as well, but I think you loose structural control through the FPGA's mapping process, so you end up with something that's more like a functional BIST rather than a structural BIST - the difference being that failures map to structural elements which may not be controllable/observable from the functional test. 

 

I guess what I'm saying is that you can instrument your design so that it's self-checking and get yourself most of the way to a good test at the cost of additional logic utilization. There are tools out there to help you with this. However, you don't get he same level of BIST capability as you would in an ASIC design because you can't insert a test point at every structural node in an FPGA ALM, for example.
0 Kudos
Reply