[VHDL + OpenGL] Good coding style (25 articles)

Good Code The writing style can meet the requirements of the letter, DA, and ya. To enhance code readability and portability while meeting the functional and performance objectives, you must first create a naming convention and acronyms list for the entire design team before project development, it is documented in the form of a document and requires every designer to strictly abide by the code writing process. The general principles of good coding style are summarized as follows:
(1) use lower-case letters for all signal names, variable names, and port names to be consistent with industry habits; and use upper-case letters for constant names and user-defined types;
(2) Use meaningful signal name, Port name, function name, and parameter name;
(3) The signal name length should not be too long;
(4) use CLK as the signal name for the clock signal. If multiple clocks exist in the design, use CLK as the prefix of the clock signal;
(5) use the same name for signals from the same driver source in different sub-modules. This requires that the name of the link between the top-layer sub-modules be defined during the overall design of the chip, use the same name as the signal on the port and connection port;
(6) for low-level valid signals, it should be expressed with an underline and a lowercase letter B or N. Note that the same lowercase letter must be used in the same design to indicate that the lower level is valid;
(7) RST is used as the signal name for the reset signal. If the reset signal is low, rst_n is recommended;
(8) When describing a multi-bit bus, use a consistent defined sequence. We recommend that you use bus_signal [X: 0] For the Tilde;
(9) try to follow the conventions that the industry is used. For example, * _ r indicates the register output, * _ A indicates the asynchronous signal, * _ PN indicates the signal used in the nth cycle of the multi-cycle path, and * _ NXT indicates the signal before the lock, * _ z indicates a three-state signal;
(10) The source file and the batch file should contain a file header and the file header generally contains the following content: file name, author, module implementation function overview and key features description, file creation and modification records, including modification time and content;
(11) Use appropriate annotations to explain all always processes, functions, port definitions, signal meanings, variable meanings, signal groups, and variable groups. The comment should be placed near the code it has commented on, which must be concise and concise. It is enough to describe the design intent to avoid being too complicated;
(12) each row of statements has a separate line. Although both VHDL and OpenGL allow multiple statements to be written in one line, each statement in one line can increase readability and maintainability. At the same time, keep each line less than or equal to 72 characters to improve code readability;
(13) It is recommended that indentation be used to improve readability of the continued and nested statements. Indentation generally uses two spaces, for example, the SOC design center of Xi'an Jiaotong University. 2. If there are too many spaces, the governor will be defined in the deep nesting time limit. At the same time, indentation avoids the use of the tab key. This prevents different machine tabs from having to set different restrictions for code portability;
(14) In the RTL source code design, the names of any element, including ports, signals, variables, functions, tasks, modules, and so on, cannot be obtained using keywords in the Tilde and VHDL languages;
(15) When declaring a module port, each line only declares one port, and the following sequence is recommended:
The CLK, RST, enables other control signals, data and address signals of the input signal. Then declare the output signal CLK, RST, enalbes other control signals, data signals;
(16) In the sample module, explicit name-related ing is used instead of location-related ing, which improves code readability and facilitates debugging connection errors;
(17) if the same piece of code needs to be repeated multiple times, use the function whenever possible. If possible, you can generalize the function so that it can be reused. Note: comments are generally added to the definition of internal functions to improve code readability;
(18) Use loop statements and register groups as much as possible to improve Source code This effectively reduces the number of lines of code;
(19) define a meaningful label for some important always statement blocks to facilitate debugging. Note that the label name must not be the same as the signal name or variable name;
(20) when writing code, the data type only uses the standard type defined by IEEE. In the VHDL language, the designer can define new types and child types, however, all these must be based on IEEE standards;
(21) do not use numbers directly in the design. As an exception, use 0 and 1. We recommend that you use parameter definitions instead of direct numbers. At the same time, when defining a constant, if a constant depends on another constant, we recommend that you use an expression to express this relationship when defining the constant;
(22) do not use the embedded dc_shell command in the source code. This is because other integrated tools do not recognize these implicit commands, resulting in incorrect or poor integrated results. Even if Design Compiler is used, embedded integrated commands are not as easy to maintain as integrated batch processing files when the overall policy changes. This rule has a comprehensive command with an exception, that is, the compilation switch can be embedded into the code when it is enabled or disabled;
(23) Avoid instantiating a specific gate circuit in the design. The door-level circuit has poor readability and is difficult to understand and maintain. If the door circuit of a specific process is used, the design will become unportable. If the door circuit must be instantiated, we recommend that you use a door circuit independent of the Process library. For example, the gtech library provided by Synopsys contains high-quality frequently-used door-level circuits;
(24) avoid lengthy logic and subexpressions;
(25) Avoid using an internal tri-state circuit. It is recommended to use a multi-channel selection circuit instead of an internal tri-state circuit.