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.

• 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.
• Every always_comb block must begin by assigning default values to all signals being driven in the block.
• Every always_ff block will include functionality allowing the registers within the block to be set to known values via the assertion of a 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]