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

--- Quote Start ---

Right now I have a DE2-70 kit in my hand.

--- Quote End ---

Ok, I have one of these kits.

--- Quote Start ---

I have known about this and I've developed a build using the 8MB flash on the DE2 kit. I must use flash because I don't want to lose the data when the FPGA chip is power down.

--- Quote End ---

If you connect your DE2-70 to a PC via JTAG or Ethernet or serial, then you could always download to the board once it is powered on, eg., using System Console you can write from your PC into the SDRAM on the board. I just modified a design I created for the DE0-nano SDRAM and it works fine with the two SDRAMs on the DE2-70.

--- Quote Start ---

It's just an example of what I want to do, which might be a little misleading. Anyway, I may have to set as many as 400+ pins.:cry:

--- Quote End ---

400 pins on what? An external device controlled by your DE2-70? Whether or not 400 pins is an issue depends on how fast you have to update them. If they pin states do not need to be updated rapidly, then a shift-register with double-buffered output registers is a simple solution (the double buffering allows you to shift a new value and then update all the values at once).

--- Quote Start ---

Your suggestion of using a SPI flash seems feasible. But I don't know where is the serial interface of the FPGA chip and how to use the EPCS chip as a SPI flash. Would you mind pointing me out how to deal with this problem?

--- Quote End ---

There are Qsys components for accessing the flash. However, you've already figured out how to use the parallel flash, so I don't think the serial flash offers you any advantage.

--- Quote Start ---

If I can load the data every time I start up the FPGA from the flash on the board, without having the JTAG circuit connected, that will be my best choice! Or maybe I have to use the JTAG and BIST commands.

One more thing, I said my data could be as large as 1MB. However, the size of the data depends the circuit I test. For most circuit, the data is no more than 200KB. So we can assume the maximum size of the data is 256KB.

--- Quote End ---

So what is wrong with using the parallel flash then?

The fact that you have not *clearly* explained what you are trying to do, indicates to me that we should still continue to discuss this. If you cannot clearly explain your objective to someone else, then you must not understand it yourself or perhaps are just having trouble explaining it, either way, if you can successfully explain to me what you need to do, and why these options are not suitable, then hopefully we can find a solution that is acceptable.

Cheers,

Dave

Hi Dave,

It's really a pleasure to have such discussion with you!

First let me briefly illustrate my purpose and why I come here to seek for help. As I mentioned, I'm doing some research of FPGA chip testing. My research is application-oriented, which means I only test the LUTs being configured after downloading the codes. To achieve this, I need to calculate a serials of testing vectors(set for input pins, that's what I said as controlling the inputs) for each circuit so that I can know there is a fault in specific LUT by observing the exceptions of the output pins. Right now I want to add a self-test state for application circuit every time the chip start up with the method of finite state machine. Therefore, I need to use the AS mode and have the testing vectors data stored in a flash.

To avoid to trouble of designing PCB and establishing FPGA system with external storage and configuration chip, I choose to use a DE2-70 kit. But I need to make sure that my method is compatible to other FPGA chips. According to my knowledge of the practical industrial world, there is hardly a circuit in FPGA uses more than 400 input pins. Besides, for most circuit downloaded into the FPGA chip, the size of the sum of testing vectors is smaller than 1MB.

The toughest problem I face is where to store the testing vectors, which may change the entire structure of my Verilog codes. The parallel flash of 8MB takes about 50 I/O pins from FPGA chip including address pins, data pins and control pins, which I assume too many. That's why I'm considering using a serial flash.

--- Quote Start ---

400 pins on what? An external device controlled by your DE2-70? Whether or not 400 pins is an issue depends on how fast you have to update them. If they pin states do not need to be updated rapidly, then a shift-register with double-buffered output registers is a simple solution (the double buffering allows you to shift a new value and then update all the values at once).

--- Quote End ---

Usually, the speed is not an essential problem so I consider the serial flash a better choice. If we face a circumstance in which we have to care about the speed, then we should use parallel flash. Besides, I've used the double-buffer structure in the build of parallel flash because I can only read 16 bits from the flash once and there is often more than 16 input pins in the application circuit.

Again, I should appreciate you for being so patient and discussing such detailed problem with me.

Best Wishes,

Miao

--- Quote Start ---

First let me briefly illustrate my purpose and why I come here to seek for help. As I mentioned, I'm doing some research of FPGA chip testing. My research is application-oriented, which means I only test the LUTs being configured after downloading the codes. To achieve this, I need to calculate a serials of testing vectors(set for input pins, that's what I said as controlling the inputs) for each circuit so that I can know there is a fault in specific LUT by observing the exceptions of the output pins.

--- Quote End ---

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. For example, how do you know that the FPGA vendor does not have additional circuits over-and-above those that they describe in their data sheets. Surely they do.

--- Quote Start ---

According to my knowledge of the practical industrial world, there is hardly a circuit in FPGA uses more than 400 input pins.

--- Quote End ---

I would not say that. I use boards with 5 1020-pin FPGAs, and plan on using hundreds of boards with ~2000-pin FPGAs.

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 Start ---

The toughest problem I face is where to store the testing vectors, which may change the entire structure of my Verilog codes.

--- Quote End ---

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 Start ---

The parallel flash of 8MB takes about 50 I/O pins from FPGA chip including address pins, data pins and control pins, which I assume too many. That's why I'm considering using a serial flash.

--- Quote End ---

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 Start ---

Again, I should appreciate you for being so patient and discussing such detailed problem with me.

--- Quote End ---

I think the biggest problem you will face with this idea is that, depending on how detailed your tests need to be, Altera might not be willing to provide you the information you need.

So far your explanation has not convinced me that you understand how and what typical FPGA usage is. In my experience, I design logic, I simulate it (run extensive test vectors, etc), I synthesize it (with pin and timing constraints), and then I download it, and 99% of the time "it just works". Sure, if I have new hardware, I may have to deal with a few issues, but with something like a DE2-70 board, I have no concerns that the board will not work or the FPGA will not work. So "where" in this scheme would your research provide any benefit? If Altera have already done their job, then there is nothing left for you to do.

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.

Cheers,

Dave

This 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

Hi Miao,

Thanks for the additional details. However, I still think your idea will suffer from a lack of information from the manufacturer.

I have FPGAs that have functional errors, i.e., a bad logic cell inside them somewhere. I tried finding an Altera tool that would let me scan and test the entire chip, but that information is proprietary, and I could not locate any tools. The BIST BSDL files only provide information on the external I/O pins, not the internal scan chains, so they are no help when trying to test an FPGA internals.

The only way I could see scanning and detecting errors in an FPGA is to run scan vectors through the internal scan chains that are used when the device is configured, i.e., a test system would exercise the LUT/ALM logic by using the scan chain to load the LUT/ALM lookup table, and then use the scan chain to scan in new input values and read the output values, and confirm they match the expected values. All of these tests would be performed on a device that is not configured. 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.

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?

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. I cannot see how it would be possible to provide 100% test coverage using the fabric to test itself.

I would really like to have a tool that would allow me to perform a complete verification of the functionality of the internals of an FPGA. However, given that Altera does not already provide one, I'm not sure you will succeed.

Cheers,

Dave

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

Hi Miao,

Thanks for your responses, they show that you had already considered my concerns, and appreciate the difficulty of your task :)

--- Quote Start ---

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.

--- Quote End ---

It depends on the device you are planning on using, and the configuration mode you select. I'm fairly certain you can configure the interface as an SPI flash master, since that is how you would read the flash from a NIOS II processor. However, I'm not sure you can change the direction of DCLK and make it an input, eg., so that you have an SPI slave. I would not be too concerned about that though. Your application can easily use the SLD Virtual JTAG component and use JTAG directly to access the FPGA fabric. The SLD Virtual JTAG gives you a way to bring the JTAG signals and some parallel signals into the FPGA fabric - but not the scan chain of the FPGA fabric. Here is some notes;

https://www.ovro.caltech.edu/~dwh/correlator/pdf/vjtag.pdf

the JTAG-to-Avalon-MM bridge is based on a variation of this component

https://www.ovro.caltech.edu/~dwh/correlator/pdf/altera_jtag_to_avalon_analysis.pdf

Good luck with your testing!

Cheers,

Dave

--- Quote Start ---

I want to make sure whether I can handle this with just one DE2 board

--- Quote End ---

The JTAG cores work on any Altera board.

If you cannot figure out how to use them, ask for help.

Cheers,

Dave

Hi Dave,

It's a pity that I have to continue my work when I'm back to school because I accidentally broke my board at home. I've read your document about Virtual JTAG, but I'm not aware of where the SLD suit you mentioned is. I've searched it on my computer and the Altera website. But I haven't find it so that I don't know where to type in the commands in your file, especially the commands in the appendix B.

Thanks for replying!

Best wishes,

Miao