User Tools
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
verilog_coding_standards [2019/04/25 11:31] jgoeders |
verilog_coding_standards [2020/05/11 17:30] (current) |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| ====== SystemVerilog Coding Standards ====== | ====== SystemVerilog Coding Standards ====== | ||
| **HDL**s (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. | **HDL**s (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. | ||
| + | |||
| + | <color red> | ||
| + | NEW video standard recently added... See below!! | ||
| + | </color> | ||
| + | |||
| + | === Videos === | ||
| + | If you are asked to attach a video to your project, please do it as follows. | ||
| + | |||
| + | There is a about a 150MB limit to the size of video you can upload. On a cellphone at default resolution that is not that long. | ||
| + | You can try to reduce the recording resolution but, at least on an iPhone, you cannot reduce it much. If it is too large, you can try | ||
| + | one of the following: | ||
| + | |||
| + | * Process it using a program to convert it to a 640x480 size video. That should be big enough. | ||
| + | * Upload it to one of Youtube, Dropbox, Google Drive, or Box and enter a link where the TA's can find it instead of actually uploading your video to LearningSuite. | ||
| + | * Find a website that will let you upload and it it will downconvert it for you. CAUTION: these are notorious for installing junk on your computer so be careful if you go this route and use it as a method of last resort. | ||
| + | |||
| + | Of these, Youtube is pretty painless but any of the second group will work. | ||
| + | |||
| === Files=== | === Files=== | ||
| * A new **.sv** file will be created for every SystemVerilog module you create. | * 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**. | + | * 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: | * Each .sv file will have a header as follows: | ||
| - | <code> | + | <code verilog> |
| /*************************************************************************** | /*************************************************************************** | ||
| * | * | ||
| Line 15: | Line 33: | ||
| * | * | ||
| * Author: <Your Name> | * Author: <Your Name> | ||
| - | * Class: <Class, Section, Semester> - ECEN 220, Section 1, Fall 2018 | + | * Class: <Class, Section, Semester> - ECEN 220, Section 1, Winter 2020 |
| * Date: <Date file was created> | * Date: <Date file was created> | ||
| * | * | ||
| Line 24: | Line 42: | ||
| </code> | </code> | ||
| - | === Module Definitions === | + | * Each file should include the ''`default_nettype none'' macro directive. |
| - | * 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). | + | |
| === Signals === | === Signals === | ||
| - | * All signals will be of type 'logic'. (The keywords 'wire', 'reg', and 'var' will never be used.) | + | * Signal types: |
| - | * Signal names: | + | * Declare module inputs as ''input wire logic'' |
| - | * Start with a lower case letter. | + | * Declare module outputs as ''output logic'' |
| - | * Are descriptive ('clrTimer' instead of 'n7'). | + | * Declare internal signals as ''logic'' |
| - | * Will have a '_n' suffix for active low signals (eg. 'write_n'). | + | * The keywords ''reg'', and ''var'' are not allowed to be used, and ''wire'' can only be used for inputs as described above. |
| - | * Local signal declarations will come just after the module definition and its port declarations. | + | * Signal names: |
| - | * 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;'. Any initializations you want done to your registers will be done explicitly via the assertion of signals such as 'clrTimer' and the like. | + | * Are descriptive (''clrTimer'' instead of ''n7''). |
| + | * Will have a ''_n'' suffix for active low signals (eg. ''write_n''). | ||
| + | |||
| + | * 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;''. | ||
| + | /*Any initializations you want done to your registers will be done explicitly via the assertion of signals such as 'clrTimer' and the like.*/ | ||
| === Comments and Indenting === | === Comments and Indenting === | ||
| * Indentation will be used in the code to show its structure. | * 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. | + | * 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. | + | * 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. | + | |
| === Design Requirements === | === Design Requirements === | ||
| - | * 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 <nowiki><=</nowiki> operator. The only assignment operator allowed in ''assign'' statements and ''always_comb blocks'' is the = operator. |
| - | * The only assignment operator allowed in an 'always_ff' block is the <nowiki><=</nowiki> 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. |
| - | * 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. | + | * 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. |
| + | /* * 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. | * 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. | + | * 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. |
| - | === Other === | + | === Suggested Style=== |
| - | * When modules are instantiated hierarchically, the instance name will be all uppercase. | + | * 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. |
| + | * Local signal declarations will come just after the module definition and its port declarations. | ||
| + | * In programming (as well as HDL-based design) there are two common ways of naming signals so that their meaning is obvious. | ||
| + | * One way is called camel case and consists of starting the signal name with a lower case letter and then capitalizing subsequent words as in: clearTimer, resetConfigurationRegisters, or launchMissile. | ||
| + | * The second way is to make everything lower case and use underscores to separate the pieces as in: clear_timer, reset_configuration_registers, and launch_missile. | ||
| + | * Choose one of these two styles, be consistent, and use descriptive signal names. | ||
| + | * Similarly, there are common ways of naming modules and constants. For modules, it is common practice to start their names with a capital letter as in: EventCounter or InitializationRegisters. For constants (sometimes called parameters in SystemVerilog), it is common to make them uppercase as in INITVAL, THRESHOLD, or DATAWIDTH. | ||
| + | * Why would any of this be important? In a large design with literally 100,000's of signals and 1,000's of modules, this will add uniformity to the design to help make the code more readable and maintain-able. | ||
| - | [[ta:tutorials#verilog_coding_standards| TA Feedback] | + | |
