TABLE OF CONTENTS There have been many sets of coding guidelines published for Verilog, but historically they have focused on the synthesizable subset and the target hardware structures. Writing testbenches involves writing a lot of code and also requires coding guidelines. These guidelines are designed to enhance code maintainability and readability, as well as to prevent common or obscure mistakes.
| Note | Guidelines can be customized. |
The specifics of a guideline may not be important. It is the fact that it is specified and that everyone does it the same way that is important. Many of the guidelines presented here can be customized to your liking. If you already have coding guidelines, keep using them. Simply augment them with the guidelines shown here that are not present in your own.
| Note | Define guidelines as a group, then follow them. |
Coding guidelines have no functional benefits. Their primary contribution is toward creating a readable and maintainable design. Having common design guidelines makes code familiar to anyone familiar with the implied style, regardless of who wrote it. The primary obstacle to coding guidelines are personal preferences. It is important that the obstacle be recognized for what it is: personal taste. There is no intrinsic value to a particular set of guidelines. The value is in the fact that these guidelines are shared by the entire group. If even one individual does not follow them, the entire group is diminished.
| Note | Enforce them! |
Guidelines are just that: guidelines. The functionality of a design or testbench will...
