THE VLSI HOMEPAGE

• 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.

Share This