Narrow down by specifying conditions
現在1888件がヒットしています。check
Verification Issues in FPGA Development
 |
The increase in verification man-hours in FPGA development has become a problem due to the increase in the circuit scale integrated in FPGA and the improvement in performance/function of FPGA. There are three main reasons for the increase in verification man-hours. 1. The size and complexity of the design is beyond what one person can comprehend 2. The number of iterations of "RTL correction ⇔ verification" has increased 3. FPGA compilation (logic synthesis and placement and routing) time has increased |
1. 2. When it becomes difficult to identify the cause of the problem. The iteration of increases. 2. Bad things. and 3. is multiplied (compile time X times), so the verification effort grows exponentially.
As FPGA design becomes more efficient through high-level synthesis, etc., the scale of the circuit becomes even larger, and the number of man-hours required for verification increases.
Now, as a method to reduce the verification man-hours, we will introduce a method of successfully combining actual machine verification and simulation, and a new verification method that is different from them.
Actual machine verification and simulation
Some FPGA designers still don't do simulations. Actual machine verification and simulation have the opposite characteristics as shown below, so if you combine them well, you can reduce the verification man-hours.
| Actual machine verification | simulation | |
|
Strong Points |
・Verification speed is very fast ・A wide range (entire system) can be verified |
・Verification can be performed immediately after correcting RTL |
| Cons |
・There are many steps from correcting the RTL to verifying the actual device |
・Validation speed is slow |
Table 1. Advantages and disadvantages of physical verification and simulation
Real device verification can find defects quickly by operating not only the FPGA but also the entire system at high speed.
However, I am not very good at finding and fixing the cause of a problem (debugging), even when I find a problem. It may take several days just to perform one physical verification after fixing the RTL. Also, if the actual machine is operated without sufficient verification, the important board may be damaged.
Conversely, simulations are good at debugging work. Recent simulators not only check expected values, but also find internal state defects during simulation, automatically search for the cause of indeterminate (X), automatically link RTL and simulation waveforms, etc., for debugging. It has a lot of useful functions. The speed of the simulation is much slower than the actual machine, but if you cut out only the problem parts and verify it, you can verify more than dozens of turns in a day. Of course, since the verification is done on the software, the board will not be damaged, so you can verify it to your heart's content.
Step-by-step verification method
If you have engineers who specialize in verification, create a testbench from the perspective of finding bugs. While using this test bench to perform simulation verification, a separate team conducts thorough physical device verification in parallel to create a highly complete design and test bench. Verification man-hours are required, but the verification period is shortened because multiple people work in parallel.
If the circuit design and the verification design are the same, the testbench is created from the viewpoint of the circuit operation, so finding bugs tends to be delayed. In this case, if you develop with the flow below, you can reduce iterations and shorten the overall verification time.
| step | Purpose | Verification method |
| During RTL design | Confirmation of desired functions written in specifications | Simulation (logic verification) |
| Validating Concerned (Assumed) Bugs | ||
| Unexpected Bug Verification | Simulation (random verification) | |
| After logic synthesis | Timing verification, performance verification |
Static timing analysis |
| After programming | Verification of the entire system including environmental conditions | Actual machine verification (system verification) |
| Unexpected Bug Verification | ||
| Debugging after finding a bug | Simulation (logic & timing verification) |
Table 2. Verification method by step
RTL design time
"Functions written in the specifications that we want to achieve" are checked by simulation for each block. The bug of this "function to be realized" will not be dragged until the actual device verification. Confirm that the test bench for the "function you want to realize" uses the "code coverage" of the simulator to perform the minimum verification.
In "concerned (assumed) bug verification", a verifier, who can consider things from a different perspective than the circuit designer, creates a test bench to find bugs and confirms them through simulation.
"Unexpected bug verification" is a dangerous place from the designer's point of view, "known verification points" such as state machines, "input conditions of each block", "verification points newly found in actual machine verification", etc. , the testbench uses constrained random testing to automatically generate unpredictable patterns and verify them in simulation. In addition, formal verification that can be verified without using such simulations and test benches is a method recommended for FPGA designers who mainly verify actual devices. Formal verification is described separately.
After logic synthesis
For timing verification, use a tool for static timing verification that has a short verification time.
Altera's static timing verification tool "TimeQuest" can be used free of charge.
If you are unsure about the logic synthesis results, compare the logic with a logic equivalence verification tool or check the logic with a simulator.
After programming
Co-verification of the entire system, including FPGA, is performed at high speed using actual equipment.
If you find a defect inside the FPGA, it will be debugged using a simulation that considers logic and timing, so use the fastest simulator possible. Debugging here is done just before the product is shipped, so the debug time greatly affects the product shipping time.
By setting assertion constraints on newly discovered verification points as "known verification points" in actual device verification, you will not forget to verify even if the design is reused.