Verilog Coding Guidelines -Part 1

1. Naming Conventions

1.1 Character set

Use only the characters [a-z][A-Z][0-9] $ and "_" in the identifiers used for naming module, ports, wires, regs, blocks etc.

Do not use escaped identifiers to include special characters in identifiers. Do not use the character "_" as the first or last character of an identifier. Do not use numerals as first character.

Do not use capital letters for identifier except Parameter and define

Example:conventions.v

1.2 Case sensitive

Use lower case letters for all identifiers leaving the upper case letters for macros and parameters. Do not use the mixed case style. Also, ensure that all the identifiers in the design are unique even in a case insensitive environment.

Example:

module // keyword Module // unique identifier but not keyword

MODULE // unique identifier but not keyword Identifier

Name: fifoReadPointer. Use: fifo_read_pointer- instead.

1.3 No keywords

Do not use Verilog keywords as identifiers.
Avoid keywords from both the HDLs as RTL code of a re-usable design may have to be made available in both languages.

Example:

input –keyword

output –keyword

1.4 Use meaningful Names

Create identifiers by concatenating meaningful words or commonly used acronyms separated by character "_".

Example:

Use en_state_transition instead of est or en_st_trn.

1.5 Identifier length, and number of parameters

Do not to use very long identifiers. This is especially true for parameters. Design unit names of parameterized modules are created by concatenating instance names, values and parameter names during design elaboration. Limit the maximum number of characters in an identifier to 25.

1.6 Parameter/Define naming convention

Parameter and Define must be declared in Capital Letter.

Example:

Parameter DATA_WIDTH=3’b111 ; `define EXAMPLE

1.7 Module names

Name the top level module of the design as _top. Module name & file name must be identical This is typically the module containing IO buffers and other technology- dependent components in addition to module _core. Module _core should contain only technology independent portion of the design. Name the modules created as macro wrappers _wrap.

Example:

module test (port1,port2,…);
.............
.............
.............
endmodule

The file should be saved as test.v

1.8 Instance names

If the module has single instance in that scope use inst_ as instance name. If there are more than one instance, then add meaningful suffixes to uniquify the names. Remember that the instance name in gate level netlist is a concatenation of RTL instance name and all the parameter ids and values in the instantiated module.

• A module may be instantiated within another module
• There may be multiple instances of the same module
• Ports are either by order or by name
• Use by order unless there are lots of ports
• Can not mix the two syntax's in one instantiation
• Always use module name as instance name.

Example:

memory memory_instance

syntax for instantiation with port order:
module_name instance_name (signal, signal...);

syntax for instantiation with port name:
module_name instance_name (.port_name(signal), .port_name (signal)… );

1.9 Blocks names

Label all the always blocks in the RTL code with meaningful names. This will be very useful for grouping/ungrouping of the design in synthesis tool and will result in better error/info messages. It is a standard practice to append the block labels with "_comb" or "_seq" depending on whether it is combinatorial or sequential.

Example:


1.10 Global signals

Keep same names for global signals (rst, clk etc.) in all the hierarchies of the design.
This should be true for any signal which are used in multiple design hierarchies. The actuals and formals in instantiation port maps should be the same IDs.

1.11 Clock signals

Name the clock signal as clk if there is only one clock in the design. In case of multiple clocks, use _clk as suffix.

Example:

pci_clk, vci_clk.

Never include the clock frequecy in clock signal name (40MHz_clk) since clock frequencies often change in the middle of the design cycle.

1.12 Reset signals

Name the reset signal as rst if there is only one reset in the design. In case of multiple resets, use _rst as suffix.

Example:

pci_rst, vci_rst.

1.13 Active low signals

All signals are lowercase alpha, numeric and underscore only. Use _n as suffix.

Example:

intr_n, rst_n, irdy_n.

Avoid using characters ’#’ or ’N’ as suffixes even in documents.

1.14 Module Hierarchy

A hierarchical path in Verilog is in form of:

module_name.instance_name.instance_name

top.a.b.c is the path for the hierarchy below.

1.15 Use of Macros

Macros are required to be used for any non-trivial constants, and for all bit-ranges. This rule is essential both for readability and maintainability of code. Having two inter-connected modules, each of which defines a bus as '17:0' is a recipe for disaster. Busses are preferably defined with a scheme such as the following:

`define BUS_MSB 17

`define BUS_LSB 0

`define BUS_SIZE (`BUS_MSB-`BUS_LSB+1)

`define BUS_RANGE `BUS_MSB:`BUS_LSB

This will minimize the number of places that have to be changed if the bus size must be changed.

1.16 MEMORY DECLARTION

Memories are declared as two-dimensional arrays of registers.

syntax: reg [msb:lsb] identifier [first_addr:last_addr] ;

where msb:lsb determine the width (word size) of the memory first_addr:last_addr determine the depth (address range) of the memory

1.17 Abbreviation

Use consistent abbreviation as shown:

Signal Naming Abbreviation