One engineer's nine comments on the FPGA Project

. Work with people. Taking our hardware engineers as an example, we usually need software cooperation during testing. a complicated job for hardware may seem like a few lines of simple code for software engineers. So
If you want to work with others and listen to others' opinions, a new know-how can be generated to speed up testing and development. There is at least no harm in giving a back-to-end explanation.

2. the test should be done by others. Developers treat their products as if they were looking at themselves. Most of them did not have the courage to discover their shortcomings. One is self-esteem, and the other is to avoid extra work. So even if there is a problem
Seriously, it is hidden. However, this is not feasible for projects, so testing and verification must be done by others.

3. More time to think. After a problem occurs, do not rush to modify it. We need to think about the possible causes, and draw out the possible causes using the debug pin or chipscope.

4. reuse existing debug
Pin. Many times, a lot of test signals are generated during the test process, but you forget to reuse them after a long time. In fact, when a problem occurs, you can observe the existing debug-pin or
It is enough to find the root cause of the problem, without the need to introduce a new pin, and waste time merging and Par.

5. The timing of simulation is sufficient. With the design principle of clock synchronization, the functions of digital circuits can be verified through simulation. Simulation results and FPGA-
Image is equivalent. Of course, FPGA should follow the same design principle: clock synchronization. Therefore, we must first ensure the clock synchronization feature of the par results. The path between registers
It must be completed within one clock cycle. (Of course there are exceptions with other constraints .) Both setup and hold requirements must be met for FPGA Devices. Once timing-error occurs
To eliminate the error. Because the error exists, it means that the main premise of clock synchronization has been damaged. At this time, the result obtained by simulation is not equivalent to that obtained by FPGA. Continue the test.
It makes no sense.

6. Pay attention to the uncontrollable interface section. Timing between registers in FPGA can be used to check whether there is a problem through the par report. However, the interface with the outside world is full of questions. We generally use
Through the Input-delay and output-delay to constrain the Interface part. Since the assumption delay is applied from the very beginning, even if there is no timing-
Errors. Taking my ongoing test as an example, the loopback test inside the module is completely normal, but once it passes through the cable, it will be generated immediately after it passes to the other FPGA.
Many error codes. Since there is no problem with simulation, it is inevitable that a certain assumption of ours has a problem, especially the assumption of clock synchronization will not be satisfied. At this time, we have to do everything we can
The interface can also meet the assumptions, or adjust the design to adapt the unsatisfactory interface to the ideal interface.

7. report the situation to the direct supervisor and seek various possible permits. If you are too reluctant to report the situation to your boss directly, you must bear all the responsibilities in case of any inconsistency. If you report the situation to your supervisor in advance and obtain
Permit, then all consequences are within the controllable range. For example, when a job is busy and assigned to a new job, it cannot be easy. The problem should be explained to the supervisor and a feasible solution should be prepared in advance for the supervisor to take the test.

8. External interfaces are the biggest obstacle. As mentioned above, if there is no problem with timing in FPGA, it is generally the same as the simulation result. The problem is that external interfaces, including cable connections, are not in our
For example, the latency is still normal at 40 MHz within the exact control range, but unexpected situations may occur at 80 MHz. So try to use the verified "cable --
Frequency "combination. You can also use the device to measure and confirm the delay characteristics of the external interface. In this way, targeted adjustments can be made. My recent lesson was to spend a whole month adjusting and testing the internal conclusion.
Structure, but still fails. The result shows that the 80 MHz signal (Data + enable + others) cannot be transmitted in parallel due to the cable problem. If the signal is changed to 40 MHz, it will pass.

9. The result after combining PR must be equivalent to the code. As mentioned above, simulation and timing are sufficient. The premise here is that the PR results are equivalent to the original code. To confirm this, we need to grasp all
The contents of warning, error, and warning are not completely negligible. Pay special attention to the following content in the comprehensive report: unused ports, removal
Redundant logic, latch inference, simulation mismatch, and so on. Enter keywords in the report to search.