Source: explanation of digital logic and Verilog design experiment course, personal notes and sorting.
00 importance of specifications
Good programming style is conducive to reduce the consumption of hardware resources and improve the working frequency of the design.
Improve the portability and maintainability of the system.
The format of the program can reflect the basic quality of the programmer and the style of the whole team.
01 naming rules
This part with the basis of C language can be simply skipped and looked at. If there is no foundation, you can skip it. You can summarize and improve it after you have some programming experience.
01-00 named character set
The character set used for naming is composed of letters a ~ z and a ~ z, numbers 0 ~ 9 and underscores.
1 data_bus 2 data_width 3 clk_48M 4 //The use of meaningful names is conducive to literal meaning and easy to maintain 5 6 48M_clk//The name cannot begin with a number 7 data__bus//Underscores cannot be used consecutively 8 data*bus//Cannot contain non alphabetic symbols
01-01 naming case rules
parameter, constant and block label names must be in uppercase;
The signal, variable, structure name (construct) and instance label (instance) must be in lowercase.
It is helpful to distinguish between unchanged and changed data during simulation.
1 module display_led( //Module label lowercase 2 clk_48M, //Clock 3 ledout //LED output 4 ); 5 input clk_48M; //48M System clock 6 output [7:0]ledout;//LED Output control 7 reg [22:0]count; //Counter 8 reg [7:0]led_reg; //LED Output buffer 9 wire led_clk; //LED Display clock control 10 parameter COUNTER=100; 11 assign led_clk = count; //LED Display time control
01-02 name must be unique
Names must be unique without case sensitivity. For example, the names state and state cannot appear in the same design at the same time. Because some EDA tools are not case sensitive.
01-03 naming habits of different types of signals
If a name consists of multiple words, underline is used to increase the readability of the name.
In order to make the signal name meaningful, the corresponding suffix can be selected according to the signal type.
Specific examples are as follows:
|xx_n||Low level active signal||Reset_n|
|xx_pn||Signal with n phases||Enable_p2|
|xx_z||Three state signal||Data_out_z|
|xx_next||State machine signal||Transmit_next|
|xx_test||Test mode signal||Parallel_clk_test|
|clk_xxx||Clock signal (can also be written in this way)||clk_768MHZ|
|rst_xxx reset_xxx||Reset signal|
|st_xxx set_xxx||Set signal|
01-04 priority of multiple suffixes
This is really a little abstract
1 //example 2 ram_1_clk_z_n 3 //structure 4 Operation object serial number_data type(_clk/_next)_Three state signal(_z)_Low level active signal(_n)
01-05 module naming habits
Combine the initials of each word of the English name of the module to form an abbreviation of 3 ~ 5 symbols.
Arithmatic logical unit - ALU
If the English name of the module has only one word, the first three letters of the word can be taken
Decider - DEC
01-06 inter module interface naming
All variable naming is divided into two parts:
The first part indicates the data direction, in which the data sender is first and the data receiver is second;
The first part is capitalized,
The second part is the data name.
All English names with clear meaning in the second part are spelled or abbreviated, the first letter is capitalized, and the rest are lowercase.
The two parts are separated by underline.
Example: cpummu_ Wrreq (write request signal sent by CPU to MMU)
01-07 module internal signal
The signal inside the module is connected by several words, and the abbreviation is required to basically indicate the meaning of this word.
There are three main points:
The general description comment "/ /" is OK
Header comments are a bit cumbersome, but they seem standard.
Notes between modules (always) refer to file header notes
1 //**************************************** 2 //Module name: 3 //Function Description: 4 //****************************************
03 code format
1 module buzzer ( 2 clk_48M, //Clock input 3 beep, //Buzzer control output 4 key, //Key input 5 ledout //LED Display control signal 6 ); 7 //Personally, I think it is useful for complex circuits, but the experimental code does not have to be so. It can be declared directly like function parameters. It can be understood with notes.
1 input clk_48M; 2 input rst; 3 output lcd_en; 4 output [7:0]data_bus; 5 wire clk_lcd; 6 //Follow closely module Statement, one Tab key 7 //The standard requirement is to declare a port on a line
Text writing requirements are similar to C language.
Replace the tab key with four spaces; Because different editing systems may have different tab spacing.
There is only one Verilog statement per line; For long statements, carriage return and indentation methods can be used to represent them as continuous statement lines.
Avoid hard coding; It is recommended to use macros or parameters to define constants and avoid hard coded values. For example:
1 //Hard coding method: 2 input [31:0] data_a; // Enter comparison data A 3 input [31:0] data_b; // Enter comparison data B 4 5 //Parameter definition method: 6 parameter DATA_WIDTH = 32; //Bus data width 7 input [DATA_WIDTH-1:0] data_a; 8 // Enter comparison data A 9 input [DATA_WIDTH-1:0] data_b; 10 // Enter comparison data B
Here are more aesthetic considerations:
Add one or more lines of space between sections
There should be a space between different variables, variables and symbols, variables and parentheses alwaya @ (...)
Leave a space on both sides of logical operator, arithmetic operator, comparison operator and other operators. (exception to singular operator)
When using a "/ /" comment, there should be a space after "/ /"