Most people have encountered this situation: after putting in a lot of effort to fix the code and test files, you excitedly start running simulations, only to find that everything fails, and you have to spend more effort debugging.
This article summarizes two good habits that can improve development efficiency and experience. They are called “habits” because they are ways of working that are not specific to FPGA technology; I even believe they can be applied to all similar development processes.
1. Confirm the Baseline
This means you need to clearly understand the current state of your starting point, ideally a clean and correct one.
Assuming we are developing a new feature based on a certain code base, we need to clarify the current state of the code base. Before we start writing code, it is crucial to confirm whether the existing testbench can run successfully.
If we do not clarify this point, when we finish modifying the code and adding the new feature, and then run the testbench only to find that the simulation fails, we cannot know whether it was due to an existing bug or the new code we added. The debugging process will be very painful, especially when the system is complex.
However, if we confirm that the previous testbench was good, then any simulation errors must be caused by the newly added code, allowing us to directly locate the relevant code for debugging.
2. Accumulate Small Changes
This means making smaller, simpler changes each time, and then accumulating them.
There is a saying in the book “The Unicorn Project”:
If you check after every small change, there will never be a big problem to solve.
Taking the development of a new feature as an example, suppose this new feature requires five major changes in the code base. We can run a simulation after completing each major change to confirm the new baseline. If we choose to complete all five changes first and then run the simulation, there is a high probability of errors, and we will also need to spend a lot of effort debugging.
Another example is performing a code rebase. Throughout the project development cycle, there may be many instances where other colleagues submit code updates to the code base. If we only perform the code rebase at the end of the project, it is easy to imagine that there will be many conflicts, making the rebase more difficult and error-prone, potentially leading to project delays. A better habit is to rebase promptly when there are changes in the code base, so that each rebase has fewer conflicts, allowing us to quickly continue with the next steps of development.
Previous Recommendations
Altera FPGA and High-Speed ADS4249 and DAC3482 LVDS Interface Design
FPGA Fixed-Point and Floating-Point Mathematical Operations – Example Comparison
“180-Day FPGA Development Online Practical Training Course – Fanyi”
ScanAddWeChattojointhegroup“andconnectwiththeofficialeducationaccountofFanyitodiscusstechnicalissuesandshareinsights~
Shareandlikeifyousupport