RTL coding guidelines - Doing it right the first time!

* Document in detail interface timing and signal descriptions, clock and reset strategy, modular view of the design and FSMs prior to RTL coding.

* Have a comment “header” for each module with functionality description, version and a log of past changes. This can be managed using a revision control system like CVS.

* Do not include more than one module in one file and the module name should match the filename in the design.

* Be generous while adding comments where necessary - like inputs and outputs.

* Indent your code and use Emacs verilog mode for connectivity to keep it error-free. Refer to Veripool’s guide on AUTOs.

* Split the design into separate modules based on clock domains.

* Use separate always @ blocks for sequential and combinational logic. Always use non-blocking assignments for sequential logic and blocking assignments for combinational logic.

* Avoid “parallel_case full_case” compiler directives and always add a default clause for case statements.

* Do NOT assign the same variable in more than one always@ block.

* Use “if-else” only for priority encoders and case statements for parallel states.

* Avoid inferring latches in the design, clock gating and instantiating gates in the design to keep it technology independent.

* Register all inputs and outputs in the design to ease timing closure.

* Use dual stage synchronizer cells available in the library than two stage flops for synchronization.

* Use reset synchronizers for asynchronous resets. Add DFT bypass muxes for reset and clock controllability where necessary.

* Avoid combinational loops in the design to aid timing analysis and DFT

* Avoid using clock as data for flop inputs for hassle free DFT insertion.

* Do not mix posedge and negedge flops in the same module where possible.

* Always separate the combinational and sequential logic in a FSM with two always@ blocks.

* Always code with design reuse in mind - For example, FIFOs can be made generic and can be customized by passing parameters while being instantiated.

* Remember the thumb rule - Be conservative in what you transmit and be generous in what you receive

* Parenthesize all operations without depending on the reader to figure out the precedence of operators.

* Add assertions where necessary to aid verification

* Lint your design for syntax/sematic checks and clock-reset policies.