Honored Contributor
Honored ContributorThis reply may cost you a little more time. I have to illustrate my thoughts clearly.
--- Quote Start --- You are saying two things here; above you talk about testing LUTs, but now you are talking about testing I/Os. These are *different* things; one is internal to the FPGA, the other is external. --- Quote End --- I'm sorry that there might be some misleading information made you thought I was trying to test I/Os. Indeed, I'm trying to test the LUT, and I need to set my testing vector on the I/O pins. We assume when testing the FPGA chip, faults in LUT are the most important because other faults in a FPGA chip can be equivalent as faults in LUT. --- Quote Start --- This is the part that does not really make sense to me. FPGAs are pre-tested by the manufacturer. The devices "just work". If you are interested in understanding fault tolerance of the devices, then you would need to access more information than the FPGA manufacturers are willing to provide. --- Quote End --- I've known about that. The device does "just work" when we just get it. However, we can't doubt that as we are using the device, some faults may occur in the device. An extreme example can be the FPGA chip used in a satellite, is more easily hit by the particle in the space, which may cause the flip-flop fault in some LUT. The FPGA used in the factory faces quite the same problem. Usually we are unable to take those FPGA chips down but we must make sure they are working correctly. My research deals with the problem above. I'm developing self-testing system for users, not for the manufacturer. Actually there are two method of testing, the application-oriented one and the non-application-oriented one. The one you mentioned is the non-application-oriented one, which means if I want to test the chip, I need to make sure that *ALL* the LUTs works well which takes a lot of time and unfortunately will reduce the life of FPGA chip because such test will configure every LUT on the whole chip for several times. For manufacturers like Altera, they only need to focus on the non-application-oriented test and just test once. While for the users who wants to make sure his FPGA chips works correctly, there's no necessity to test all the LUTs and there is no need to replace the FPGA if there is a fault in the LUT he doesn't use. That's the reason we need application-oriented method. What I am doing right now is to build an application-oriented FPGA self-testing system for anyone who uses FPGA. It's kind of like the BIST in the DE2 board but such BIST is still non-application-oriented. I want to develop an application-oriented one. First, for a specific circuit write in Verilog, I change some structure of the circuit to make the circuit more easy to test and add the self-test state into the Verilog code. Then I generate the testing vectors. After doing that, I download the code into the FPGA in AS mode. Every time the FPGA is powered on, it first load the configuration from the EPCS chip. Then the system is in the self-testing state, load the test vectors from some external storage. After the self-test is done, the FPGA skips to the normal state and works as usual. --- Quote Start --- I would not say that. I use boards with 5 1020-pin FPGAs, and plan on using hundreds of boards with ~2000-pin FPGAs. --- Quote End --- Forgive my ignorance of it. But the quantity of I/O pins doesn't matter. The length of testing vector only depends on the number of the inputs of the application circuit. --- Quote Start --- If the vectors are read by an Avalon-MM master, then the Avalon-MM slave can change without having to change your test code. --- Quote End --- I'm sorry that I have no idea about Avalon-MM master.:( --- Quote Start --- I don't think you are concentrating on the correct aspect of your design. The DE2-70 is already designed, so you may as well use the features it already provides. If you are interested in testing I/O, then you have plenty of signals on the GPIO port to get started with. --- Quote End --- I mean, the DE2-70 is just a platform. It's a reliable one and I can run my testing system on it. But as I mentioned above, I want to develop a system that anyone can use so I have to guarantee the system is compatible. To my best knowledge, when designing a board using FPGA, there is always a recommended consist of the board. For example, we have to use EPCS chip. If I can utilize the EPCS chip to achieve my goal, then probably all the system using FPGA chip from Altera can use my application-oriented self-testing system. --- Quote Start --- These comments are not meant to sound negative. These comments are made to help you understand what you are trying to do. If you can convince me, and others on the group that you have a novel idea that could be implemented, then this group will be happy to help. --- Quote End --- I don't mind negative comments at all even if they are jarring. In fact, they help me develop my thoughts. If I cannot convince you,it's still a pleasure to have such discussion here. Frankly speaking, you really help me a lot.:) Best Wishes, Miao
