0.2 Verilog Coding Style
Classification Verilog Tutorial Advanced
A good coding style facilitates the reading, debugging, and modification of code. Although Verilog code can be written arbitrarily as long as the syntax is correct, a messy coding style is often a one-time deal. Sometimes when looking back at the code you have written, you can't see the meaning of the signals or understand the function of the module, and you have to analyze step by step from the logic, which will consume a lot of time and energy to digest, severely affecting the design progress.
In order not to let others or yourself sincerely sigh: "Who the hell wrote this code!" The following are some suggestions for coding style.
About Naming
Signal variables, modules, etc. must use meaningful names, and signal names should also remain unchanged when they are passed between modules, so that the code itself has clear explanatory information and enhances readability.
When there are too many words in the name, you can use capitalization of the first letter or the underscore "_" to splice. I personally prefer the latter, which is clearer.
reg DataToDestinationClock;
reg data_to_destination_clock; // Recommended
It is recommended to use the abbreviation of words to name the signal and to know how to choose, to avoid too long signal naming. For example, clock is abbreviated as clk, destination as dest, source as src, etc.
Cleverly use numbers to represent English letters, such as 2 to represent to, 4 to represent for, which can save a bit of code space.
reg clk_for_test, sig_uart_to_spi;
reg clk4test, sig_uart2spi; // Recommended
Although Verilog is case-sensitive, it is recommended that the names of general functional modules, ports, signal variables, etc. all use lowercase, parameters use uppercase, and some special ports such as power and pad use uppercase. It's just for the convenience of writing code, easy to distinguish constant variables, and you don't have to consider the difference between signals with the same name but different case.
parameter DW = 8; // Constant
reg [DW-1:0] wdata; // Variable
Register variables generally add the suffix _r, and delayed latching variables add the suffix _r1, _r2, etc. There are two main advantages. First, it is easy to operate on data according to the type of variable during RTL design. Second, the signal names in the synthesized netlist often change, and adding a suffix makes it easier to find the corresponding signal variables in the synthesized netlist.
wire dout_en;
reg dout_en_r;
... // The logic of dout_en_r
assign dout_en = dout_en_r;
Other suffixes: _d can represent delayed signals, _t can represent temporarily stored signals, _n can represent low-effective signals, _s can represent slave signals, _m can represent master signals, etc.
Avoid using keywords to name signals, such as in, out, x, z are not recommended as variables.
The file name should be consistent with the designed module name, and the file should contain only one design module as much as possible.
About Comments
At the beginning of each design module, it should include file description information, including copyright, module name, author, date, summary, modification records, etc. For example:
/**********************************************************
// Copyright 1891.06.02-2017.07.14
// Contact with [email protected]
================ tutorialpro.v ======================
>> Author : willrious
>> Date : 1995.09.07
>> Description : Welcome
>> note : (1)To
>> : (2)My
>> V180121 : World.
************************************************************/
Comments should express the meaning of the code concisely, short comments are added after a line of statement code, and long comments are written one line in advance.
// The output bit width is less than the input bit width, calculate the shrinking multiple and the corresponding number of bits
parameter SHRINK = DWI/DWO;
reg [AWI-1:0] ADDR_WR; // Write address
Comments should be written in English to ensure that they can be displayed normally under different operating systems and different editors.
In the port signal, in addition to the general clock and reset signals, other signals should also be commented.
Comments are very powerful, you can use comment information to draw timing diagrams, and even use comments to draw digital circuit structure diagrams.
About Optimization
Use parentheses to determine the priority or logical structure of the program. To avoid design errors caused by operator precedence issues, it is recommended to use parentheses more.