Need some help of SRunner Tools! Need some related files!

Hi Dave,

I know the scan chain testing you mentioned. It's a non-application-oriented method. Usually the manufacturer will develop testing tools based on such non-a-o method and it is the developers or the engineers, not the users, who know how to use tools.

--- Quote Start ---

You are proposing configuring a device and then using the user-programmable part of the FPGA for testing itself. This approach has a serious problem, eg. lets say you have an FPGA with a bad LUT/ALM. How do you identify that? Perhaps you are lucky and the LUT/ALM is used to implement a register and a bit in that register cannot be changed. But what happens if the bad LUT/ALM is in the address decoding logic, and you can never reach a particular register or block of registers?

--- Quote End ---

Using the user-programmable part of the FPGA for testing itself seems paradoxical. However, it still can be believed reliable for practical uses. The only way for the FPGA chip to pass the self-testing state is to have all the correct outputs for every testing vector. The most common fault for FPGA is the flip-flop for LUT storage bits. When considering the flip-flop faults, if any logic part in address decoding is bad, the opportunity to remain the outputs all right is so slim that we can usually ignore it.

--- Quote Start ---

I cannot see how it would be possible to provide 100% test coverage using the fabric to test itself.

--- Quote End ---

It's true for all the application-oriented methods so we have to make a compromise between the fault coverage and the testing time. There are two reasons. The first reason is that for a certain application circuit, there might be some fault in the circuit we can observe from the outputs. Besides, as you mentioned, if the faults in the address decoding part happen to guarantee the outputs are all right, they are unable to detect. But these faults only play a really tiny ratio among all the faults. The second reason is decisive. For a-o method, we may fail to detect some faults, but in the circumstance where the FPGA needs frequent testing(mostly when powered on), the reduction of time cost by testing is more important. Also for the reason that frequent non-a-o testing will reduce the life expectancy of the FPGA significantly, we can bear the faults that a-o method can not detect.

--- Quote Start ---

How about this question; if I ask you to scan test the top-row of LUTs/ALMs in an FPGA, how will you do that? Using only the user fabric and the standard Altera tools, you would have to create an HDL instance that exactly matches an LUT/ALM, then you would have to force the place-and-route tool to place those components along the top row (which you might be able to do with the floorplanning tools), and then you would have to link all that logic together in a scan chain so you could test it ... that scan chain would require logic, and most likely need to use the logic you are trying to test.

--- Quote End ---

I don't think I should guarantee the top-row of LUTs in an FPGA is all right when using a-o testing method. If the circuit downloaded into the FPGA uses those LUTs, the faults in those LUTs will definitely be detected. If not, I don't need to care about them because if the remaining of the FPGA is good, the FPGA can still work correctly.

--- Quote Start ---

You cannot use the EPCS interface for this, since it just reads a single data stream and configures the device configuration SRAM cells, i.e., you cannot read any scan chain details via the EPCS interface.

--- Quote End ---

A quetion came to me when I read this. Is the serial interface of the FPGA still usable after configuration? If not, it seems that I can only use a double shift-register behind the inputs if I want to use serial flash and I can not make this out with my DE2 board.

Best Wishes,

Miao