FPGA verification. What is it?
By the will of fate, I have been involved in the verification of FPGA configurations for several years. And from the very beginning I was struck by the small number of information on this issue.
If not all, then many have heard about FPGAs. Perhaps some even worked closely with them, but I think a lot less people came across the verification of projects on FPGAs. Today I will talk about the verification process.
Functional verification on the FPGA is the process of finding and correcting errors in the FPGA configuration (hereinafter referred to as firmware). Tell me why verification is needed because everything can be fixed at the stage of debugging FPGA in hardware. It is possible, but extremely difficult.
Firstly, in the hardware, the search for functional errors is a rather laborious and long process. This results in delays in project completion. For a serious enough project, debugging can take weeks and months. Verification allows you to find and correct most of the functional errors at the model stage.
')
Will you say that an experienced FPGA developer does not make mistakes or makes them extremely small? Makes! And quite a lot.
Verification allows you to detect not only current errors, but also potential errors that may appear in future projects using blocks.
Verification can be divided into the following stages:
As you know - a competent approach to the development of TK eliminates many problems throughout the project. Verification TOR should describe the full and comprehensive set of functions and features of the unit that need to be verified. Ideally, the verification team should write a verification team verification team. This is extremely important especially with a small experience of the verifier who will be engaged in testing. The composition of the TZ should include the following items:
• listing all the blocks that will be part of the project and whose work should be checked;
• enumeration of all modes of operation, functions, and project capabilities that require verification;
• enumeration of functions and maintenance classes that will be reused from other projects (for example, a set of functions for calculating checksums or working with data communication interfaces).
Naturally, the writing of the TOR should begin after receiving all the necessary information on this project.
The planning process is possibly the most important and most neglected stage of functional verification. Creating a verification plan is determined by developing strategies and tactics for working with a project before it starts. The verification plan is a guide for the project team. Without a competent verification plan, teams often choose the wrong way to search for errors.
The verification plan includes a set of all tests with a detailed description.
Verification plan is the main document for the FPGA verification team. All further work will be based on this document. Synopsys and Cadence recommend starting all “foreign monsters” of systems on a chip with a verification plan before starting the development of maintenance. In essence, the verification plan represents a more detailed verification specification.
In the detailed description of each test, all necessary programmable parameters, current operating modes, input, output and reference data should be indicated.
It must be remembered that the development of the configuration of the FPGA and the development of TO must begin and run in parallel. This procedure is optimal in terms of the minimum project development time, because the verification processes take up more than 70% of the development time of the entire project.
Based on the information from all previous stages, you can start creating a test environment (hereinafter referred to as MOT). THAT it is customary to write in programming languages ​​created specifically for verification purposes, because they have all the necessary tools for this. System Verilog is one of the most suitable languages. This language is quite similar to C ++ along with encapsulation, polymorphism, inheritance.
When developing a test environment, it is highly recommended not to forget about “reusability”. If there are no suitable functions, then write them taking into account possible future use. If there are functions, then use. It is required to organize maintenance in such a way that each test can be modified without the possibility of damaging other tests. This will relieve problems in the future, because in the process of testing, you still have to make some changes in the maintenance code.
At this stage, the verifier has to work most closely with the developer. During the tests, errors will be detected, and they will be detected. If they don’t, then your MOT is not working properly. After an error is detected, you are required to inform the developer about the error. Then, after correction, the verifier needs to rerun the test and verify that the error has been fixed.
Ideally, it would be to use bug tracking systems to communicate between the verifier and the developer. This will allow later to track down what problems are often found in a particular project, or in one or another developer. But at the same time there will be evidence that the verifier does not eat his bread for good reason.
I think it should be added that not every developer does not always admit his mistakes. In this case, it is necessary to refer to the TK, which should clearly describe the work of the project.
If not all, then many have heard about FPGAs. Perhaps some even worked closely with them, but I think a lot less people came across the verification of projects on FPGAs. Today I will talk about the verification process.
Functional verification on the FPGA is the process of finding and correcting errors in the FPGA configuration (hereinafter referred to as firmware). Tell me why verification is needed because everything can be fixed at the stage of debugging FPGA in hardware. It is possible, but extremely difficult.
Firstly, in the hardware, the search for functional errors is a rather laborious and long process. This results in delays in project completion. For a serious enough project, debugging can take weeks and months. Verification allows you to find and correct most of the functional errors at the model stage.
')
Will you say that an experienced FPGA developer does not make mistakes or makes them extremely small? Makes! And quite a lot.
Verification allows you to detect not only current errors, but also potential errors that may appear in future projects using blocks.
Verification can be divided into the following stages:
- Development of TZ;
- Development of a verification plan;
- MOT development;
- Testing;
1. Development of TK for verification
As you know - a competent approach to the development of TK eliminates many problems throughout the project. Verification TOR should describe the full and comprehensive set of functions and features of the unit that need to be verified. Ideally, the verification team should write a verification team verification team. This is extremely important especially with a small experience of the verifier who will be engaged in testing. The composition of the TZ should include the following items:
• listing all the blocks that will be part of the project and whose work should be checked;
• enumeration of all modes of operation, functions, and project capabilities that require verification;
• enumeration of functions and maintenance classes that will be reused from other projects (for example, a set of functions for calculating checksums or working with data communication interfaces).
Naturally, the writing of the TOR should begin after receiving all the necessary information on this project.
2. Development of a verification plan
The planning process is possibly the most important and most neglected stage of functional verification. Creating a verification plan is determined by developing strategies and tactics for working with a project before it starts. The verification plan is a guide for the project team. Without a competent verification plan, teams often choose the wrong way to search for errors.
The verification plan includes a set of all tests with a detailed description.
Verification plan is the main document for the FPGA verification team. All further work will be based on this document. Synopsys and Cadence recommend starting all “foreign monsters” of systems on a chip with a verification plan before starting the development of maintenance. In essence, the verification plan represents a more detailed verification specification.
In the detailed description of each test, all necessary programmable parameters, current operating modes, input, output and reference data should be indicated.
3. Development of MOT
It must be remembered that the development of the configuration of the FPGA and the development of TO must begin and run in parallel. This procedure is optimal in terms of the minimum project development time, because the verification processes take up more than 70% of the development time of the entire project.
Based on the information from all previous stages, you can start creating a test environment (hereinafter referred to as MOT). THAT it is customary to write in programming languages ​​created specifically for verification purposes, because they have all the necessary tools for this. System Verilog is one of the most suitable languages. This language is quite similar to C ++ along with encapsulation, polymorphism, inheritance.
When developing a test environment, it is highly recommended not to forget about “reusability”. If there are no suitable functions, then write them taking into account possible future use. If there are functions, then use. It is required to organize maintenance in such a way that each test can be modified without the possibility of damaging other tests. This will relieve problems in the future, because in the process of testing, you still have to make some changes in the maintenance code.
4. Testing
At this stage, the verifier has to work most closely with the developer. During the tests, errors will be detected, and they will be detected. If they don’t, then your MOT is not working properly. After an error is detected, you are required to inform the developer about the error. Then, after correction, the verifier needs to rerun the test and verify that the error has been fixed.
Ideally, it would be to use bug tracking systems to communicate between the verifier and the developer. This will allow later to track down what problems are often found in a particular project, or in one or another developer. But at the same time there will be evidence that the verifier does not eat his bread for good reason.
I think it should be added that not every developer does not always admit his mistakes. In this case, it is necessary to refer to the TK, which should clearly describe the work of the project.
Source: https://habr.com/ru/post/262693/
All Articles