The "big data" principle of FPGA testability design
At present, the most popular knowledge is “big data”. The core idea of big data is to achieve a deeper and intuitive understanding of the seemingly irregular behavior of society, enterprises and individuals through scientific statistics. The testability of the FPGA can also be used to perform statistical queries on the “small data” inside the FPGA to detect bugs within the FPGA.
Design for testability is not an unpredictable knowledge for FPGA design. The purpose of FPGA testability design is to consider subsequent problem debugging, problem location and other issues at the beginning of the design. To understand design for testability with FPGAs, it’s just a matter of answering a few questions, which are:
- How will the design be tested?
- Design problems, how to quickly locate?
- How to divide the level of faults and isolate the problem at the beginning of the design?
In general, in the debugging phase of the design, if there is a bug, the embedded logic analyzer (chipscope/signaltap) needs to be used to capture the signal that may have problems. In this way, the debugging speed is slower for larger designs (the compilation time is longer and the iteration speed is slower, but it is also a very effective method and a necessary skill for FPGA). So what are the effective methods for the testability of large-scale projects?
(1) Statistical counts.
Statistical counts in FPGA design are not “big data”, but “small data”, for example, for a network interface, how many packets are received, how many packets are sent, how many bytes are received, and how many bytes are sent . For a module, how many calls are received, or how many operations are initiated. For the data flow operation of reading the FIFO, how many frames (frames) are read from the FIFO and how many frames are written to the subsequent FIFO.
These counts undoubtedly require resources, but occupying these resources is valuable. With these counts, the design can be read out by an external processor via the bus interface. So a “big data” graph of the internal design of the FPGA emerges.”
As can be seen from the above figure, the counts in each processing module can be read out through the external CPU, and then a data flow diagram inside is obtained. We can simplify the design to (count A->count B->count C->count D->count E). In actual use, it can be determined according to the occupied resources and the actual required observation points.
Suppose, during the debugging process, we found that there is input and no output suddenly. This is no need to go to the embedded logic analyzer to capture the signal. Through the software of the CPU, all counts can be printed out. In the case of input drive, Assuming that the count C has changed, but the count D has not changed, the processing module 3 is directly located. At this time, there is a problem with the processing, which is simple, direct and effective.
A situation can also be quickly located, with more input but less output, such as the normal input code stream, but the output to the display is indeed lack of frames and fewer frames, which is completely unsmooth. Through counting analysis, the original frame counts C and D should be the same, but the count of D is much less than that of C, indicating that the performance of the processing module 3 is insufficient at this time, or the design is defective. In this way, the key points of the entire design are positioned to the processing module 3.
By analyzing the key counts of each module inside the FPGA to locate and analyze the problem, there is no difficulty in design. However, it needs to be used in conjunction with an external CPU or an FPGA embedded CPU.
Everything has advantages and disadvantages. Adding more counts will increase the usage of resources, so how to balance it? To set a separate bit width for this analysis count, locate `define REG_WIDTH N in the global unified macro definition. At this time, the setting of N can be flexible and diverse, such as 8-bit/16-bit/32-bit and so on. The required logic can be flexibly added based on the remaining amount of resources in the project, after all the values of these counts provide an analysis trial.
(2) Status output.
If we locate a module like the above problem, how to locate the logic problem in the module?
The key to solving this problem is the state machine, which is the same as the output count. In general designs, the state machine is the core of the design, and the CS (current state) signal of the state machine is drawn out. If there is no external output, the current state Status should be IDLE.
For example, in the above, we locate that module 3 is dead at this time, waiting for no more external signals to be input, if the state machine signal in module 3 is not IDLE at this time, if it is in state B_CS at this time, it means that the module is wrong at this time. appears in state B. The B jump must be activated by the signal X. Therefore, the problem of signal X can be directly located. All that’s left is to locate why signal X doesn’t work.
(3) Logic reset.
Another way to divide the FPGA problem or the module problem is the logic reset. The above mentioned reset (architecture design talk), the logic reset, if the A module itself has a logic reset, if the design has no output (commonly called “FPGA is dead” ), if a module is suspected, and the design works normally after the logic reset of the module, it is necessary to locate the module or the connected module affected by the module (the abnormal output of the module causes the next-level module error).
In this paper, the FPGA testability design, non-ASIC speaking, is tested by inserting JTAG/BIST. The purpose is to locate the problem and improve the testability of the FPGA by focusing on how to test the design. In addition, the logic probe is also a direction to solve the test problem (special topic).
The improvement of testability means the increase of debugging methods and the acceleration of debugging speed, instead of blindly relying on embedded logic analyzers. The ability to quickly locate problems is an important manifestation of FPGA R&D capabilities, and design for testability is a powerful assistant for improving this capability.
Haoxinshengic is a pprofessional FPGA and IC chip supplier in China. We have more than 15 years in this field。 If you need chips or other electronic components and other products, please contact us in time. We have an ultra-high cost performance spot chip supply and look forward to cooperating with you.
If you want to know more about FPGA or want to purchase related chip products, please contact our senior technical experts, we will answer relevant questions for you as soon as possible
Our Products