HDLs (Hardware Description Languages) like SystemVerilog can be difficult to understand. To make SystemVerilog code more readable and maintainable, you are required to follow coding standards. These standards are explained below. Each lab will be graded against this coding standard.

• A new .sv file will be created for every SystemVerilog module you create.
• The name of any SystemVerilog file you create must match the name of the module it contains. For example, if you have a SystemVerilog file with a module named FourFunctions, the filename will be FourFunctions.sv.

• Each .sv file will have a header as follows:

/***************************************************************************
* 
* Module: <module Name>
*
* Author: <Your Name>
* Class: <Class, Section, Semester> - ECEN 220, Section 1, Fall 2018
* Date: <Date file was created>
*
* Description: <Provide a brief description of what this SystemVerilog file does>
*
*
****************************************************************************/

• Module names start with a capital letter as in Timer.
• Module definitions will always be preceded by a `default_nettype none macro directive and will use the “old” style of module definitions (see textbook Program 8.4.2 for an example).

• All signals will be of type logic. (The keywords wire, reg, and var are not allowed to be used.)
• Signal names:
  • Start with a lower case letter.
  • Are descriptive (clrTimer instead of n7).
  • Will have a _n suffix for active low signals (eg. write_n).
• Local signal declarations will come just after the module definition and its port declarations.
• When signals are declared, they will not use an initializer. For example, this is incorrect: logic nextState = 0;. Rather, signals will be declared as in logic nextState;.

• Indentation will be used in the code to show its structure.
• Each always_ff block and every always_comb block will be preceded by a comment describing its function and how it should operate.
• If the name of a signal is expressive enough (e.g. clrTimer) then a comment describing may not be needed. Otherwise, all signal declarations will have an associated descriptive comment.
• The code for the different sub-modules in a module will be grouped together. For example, the statements associated with the timer circuitry will appear together, followed by the statements associated with the bit counter circuitry, followed by the state machine. Each such section of circuitry will have comments delimiting it.

• Every always_comb block must begin by assigning default values to all signals being driven in the block.
• The only assignment operator allowed in an always_ff block is the <= operator. The only assignment operator allowed in assign statements and always_comb blocks is the = operator.
• All sequential circuits like state machines and counters will include functionality allowing them to be set to known values via the assertion of a 'clr' or 'load' signal. The exception to this may be something like a shift register which will eventually shift in known data and therefore which does not necessarily require an explicit clr or load signal.
• Outputs from counters, state machines, etc. will be combinational except in very rare cases.
• Finite state machines will be coded using the style of the textbook including the use of an enumerated type for the state type, an always_comb for the combined IFL/OFL, and an always_ff for the state register. You may choose whether to use the “normal” state machine coding style shown in the book or the “defensive” style shown in the book.

• When modules are instantiated hierarchically, the instance name will be all uppercase.

[[ta:tutorials#verilog_coding_standards| TA Feedback]