Microsoft PowerPoint - RTL coding guidelines []RTL Coding Guidelines
Make HDL Codes readable, modifiable, and reusable.
Achieve optimal results in synthesis and simulation.
DIP/ 4-2
Outline
Overview of the coding guidelines Basic coding practices Coding for portability Guidelines for clocks and resets Coding for synthesis Partitioning for synthesis Designing with memories
DIP/ 4-3
Overview of the coding guidelines Basic coding practices Coding for portability Guidelines for clocks and resets Coding for synthesis Partitioning for synthesis Designing with memories
DIP/ 4-4
Overview of Coding Guidelines - Goals
Use simple constructs and simple clocking scheme Use a consistent coding style, consistent naming conventions, and a
consistent structure for processes and state machines Use a regular partitioning scheme, with All module outputs registered, and with modules roughly of the same size
Make the RTL code easy to understand, by using Comments, Meaningful names, and Constants or parameters instead of hard-coded numbers
DIP/ 4-5
Organize Your Design Workspace (1)
Create a directory structure for storing HDL source, simulation libraries, synthesis scripts and synthesis database.
design
hdl
synopsys_dc.setup
DIP/ 4-6
Overview of the coding guidelines Basic coding practices Coding for portability Guidelines for clocks and resets Coding for synthesis Partitioning for synthesis Designing with memories
DIP/ 4-7
Informational Headers
Rule: include a commented, informational header at the top of every source file, including scripts.
The header must contain: Legal statement: confidentiality, copyright, restrictions on reproduction Filename Author Description of function and list of key features of the module Date the file was created Modification history, including
Date Name of modifier Description of the change
DIP/ 4-8
Code Template /*********************************************************/ // MODULE: CODE TEMPLATE // FILE NAME: template.v // VERSION: 1.0 // DATE: January 1, 1999 // AUTHOR: Jinn-Shyan Wang // CODE TYPE: RTL or Behavioral Level // DESCRIPTION: This template is used to have a coding standard for each Verilog function in your homework and project // © COPYRIGHT 2003 CCU // ALL RIGHT RESERVED. // //MODIFICATION HISTORY: // Date Description // 03/04/2003 /*********************************************************/ // DEFINES
// TOP MODULE
Rules for General Naming Conventions (1)
Document the naming convention.
Let the module name the same as the file name.
Use lowercase letters for all signals, variables, and ports.
e.g. wire clk, rst;
Use uppercase letters for names of constants and user-defined types.
e.g. `define MY_BUS_LENGTH 32
For a RAM address bus, use ram_addr instead of ra.
DIP/ 4-10
Rules for General Naming Conventions (2)
Use short but descriptive names. Note that, during elaboration, the synthesis tool concatenates the module’s
name, parameter names, and parameter values to form the design unit name.
Use clk for the clock signal. More than one clock? → clk1, clk2 or clk_interface …
Use the same name for all clock signals that are driven from the same source.
For active-low signals, end the signal name followed by ‘_n’. e.g. ram2alu_n
Use rst for reset signals. If active low → rst_n
DIP/ 4-11
Rules for General Naming Conventions (3)
When describing multibit buses, use [x:0] instead of [0:x]. e.g. module DW_addinc (
a, b, ci, sum, co,
); input [(‘WIDTH-1):0] a; input [(‘WIDTH-1):0] b; input ci; ….
Use the same or similar names for ports and signals that are connected. (e.g. a=>a; or a=>a1;)
Use case insensitive naming. Don’t use HDL reserved words.
DIP/ 4-12
Rules for General Naming Conventions (4)
Other naming conventions *_r : output of a register count_r
*_a : asynchronous signal addr_strob_a
*_z : tristate internal signal *_pn : signal used in the nth phase enable_p2
*_nxt : data before being registered into a register with the same name
Use a distinctive suffix for state variable names. Recommended names are <name>_cs for the current state, and <name>_ns
for the next state.
Port Ordering
Rule: Declare ports in a logical order, and keep this order consistent throughout the design. Guidelines: One port per line, with a comment following it (preferably on the
same line) Use comments to describe groups of ports Declare the ports in the following order:
Inputs: Clocks Resets Enables Other control signals Data and address lines
Outputs: Clocks Resets Enables Other control signals Data
DIP/ 4-14
Port Ordering - Examples
{ // Inputs:
DIP/ 4-15
Port Maps and Generic Maps
Rule: Always use explicit mapping for ports and generics, using named association rather than positional association. Example 1:
my_module U_my_module( .clk(clk), .rst(rst), …
); Example 2: (see p.92)
Rule: Leave a blank line between the input and output ports to improve the readability.
DIP/ 4-16
Use Functions (1)
Guidelines Use functions instead of repeating the same sections of codes If possible, generalize the function to make it reusable Use comments to explain the function
Example function [`BUS_WIDTH-1:0] convert_address;
input input_address, offset; begin
Use Functions (2)
Example (2) Poor expression usage
// sign-extend both operands from 8 to 16 bits operand1 = {{8 {ls_byte[7] }}, ls_byte }; operand2 = {{8 {ms_byte[7]}}, ms_byte};
Proper use of subprogram // sign-extend an 8-bit value to a 16-bit value function [15:0] sign_extend;
input [7:0] value; sign_extend = {{8 {value[7]}}, value};
endfunction
// sign-extend both operands from 8 to 16 bits operand1 = sign_extend(ls_byte); operand2 = sign_extend(ls_byte);
DIP/ 4-18
Use Loops and Arrays (1)
Guideline: Use loops and arrays for improved readability of the source code. Example:
module my_module( … ); … reg [31:0] reg_file[15:0]; integer tmp;
always @(posedge clk or posedge rst) If(rst) for(tmp=0; tmp<16; tmp++)
reg_file[tmp] <= 32’d0; …
Guideline: Arrays are significantly faster to simulate than for-loops. Use vector operations on arrays rather than for-loops whenever
possible. Example: Poor coding style:
for(i=0;i < WIDTH, i = i + 1) c[i] = a[i] xor b[i];
Recommended coding style: c[WIDTH-1:0] = a[WIDTH-1:0] xor b[WIDTH-1:0];
DIP/ 4-20
Use Meaningful Labels
Guideline: Label each process block <name>_PROC.
Rule: Label each instance with a meaningful name.
Guideline: Label each instance U_<name>.
Keep labels short as well as meaningful.
Rule: Do not duplicate any signal, variable, or entity names. Example: If you have a signal named incr, do not use incr as a process
label – use incr_proc instead.
DIP/ 4-21
Overview of the coding guidelines Basic coding practices Coding for portability Guidelines for clocks and resets Coding for synthesis Partitioning for synthesis Designing with memories
DIP/ 4-22
Coding for Portability --Do Not Use Hard-Coded Numeric Value (1)
“Portable” means: Technology-independent Compatible with various simulation tools Easily translatable between Verilog and VHDL
Guideline: Do not use hard-coded numeric values. Example:
Guideline: Keep the `define statements for a design in a single separate file and name the file DesignName_params.v.
Poor coding example:
Recommended coding example: `define MY_BUS_SIZE 8 wire [`MY_BUS_SIZE-1:0] my_in_bus; reg [`MY_BUS_SIZE-1 :0] my_out_bus;
DIP/ 4-23
Coding for Portability --Do Not Use Hard-Coded Numeric Value (2)
You can use the values 0 and 1 (but not in combination, as in 1001).
Using constants has the following advantages:
Constant are more intelligible as they associate a design intention with the value.
Constant values can be changed in one place.
Compilers can spot typos in constants but not in hard-coded values.
DIP/ 4-24
Coding for Portability --Avoid Embedding Synthesis Commands
Recommendation: Avoid embedding synthesis commands directly in the source code. Example: Such as avoiding embedding dc_shell command.
Others who synthesize the code may not be aware of the hidden commands.
If the design is reused in a new application, the synthesis goals may be different, such as a higher-speed version.
Exceptions: The synthesis directives to turn synthesis on and off must be embedded in the code in the appropriate places.
DIP/ 4-25
Coding for Portability --Technology Independence
Guideline: Use the DesignWare Foundation Library to maintain technology independence.
Guideline: Avoid instantiating gates in the design.
Guideline: If you must use technology-specific gates, then isolate these gates in a separate module.
Guideline: If you must instantiate a gate, use a technology- independent library such as the Synopsys generic technology library, GTECH.
DIP/ 4-26
Coding for Portability --DesignWare Foundation Library
The DesignWare Foundation Library contains improved architectures for the inferable components. Libraries of high-level functions, such as adders, multipliers, comparators,
FIFO’s, and RAM’s. Infer high level functions instead of instantiating them . Users can create their own DesignWare parts for design reuse or for licensing
to other customers.
Technology Library
Coding for Portability --Components in DesignWare Foundation Library
Arithmetic components: Adders, Multipliers, Comparators, Incrementers and decrementers, Sum of
product, Sin/Cos, Modulus, Divide, Square root, Arithmetic and barrier shifters
Sequential components: FIFO’s and FIFO controllers, ECC, CRC, JTAG components and ASIC
debugger
http://solvnet.synopsys.com/cgiservlet/aban/cgi-bin/ASP/dow/dow.cgi
Coding for Portability --Coding with DesignWare Parts
Through HDL inferencing: Mult_OUTPUT <= BUSA * BUSB;
*
DIP/ 4-29
Coding for Portability --GTECH Library
Contain the following components:
1-bit adders and half adders
2-of-3 majority
DIP/ 4-30
Overview of the coding guidelines Basic coding practices Coding for portability Guidelines for clocks and resets Coding for synthesis Partitioning for synthesis Designing with memories
DIP/ 4-31
Guidelines for Clocks and Resets --Ideal Clocking Structure
A simple clocking structure is easier to understand, analyze, maintain, and consistently produces better synthesis results.
Ideal clocking structure is a single global clock and positive edge- triggered flops as the only sequential devices.
clk
Guidelines for Clocks and Resets --Avoid Mixed Clock Edges (1)
Guideline: Avoid using both positive-edge and negative-edge triggered flip-flops in your design. In designs with very aggressive timing goals, it may be necessary to
capture data on both edges of the clock. However, The duty cycle of the clock become a critical issue in timing analysis, in
addition to the clock frequency itself. Most scan-based testing methodologies require separate handling of positive
and negative-edge triggered flops.
Rule: If you must use both PEDFFs and NEDFFs, be sure to Model the worst case duty cycle accurately in synthesis and timing analysis Document the assumed duty cycle in the user documentation Separate them into different modules
DIP/ 4-33
Guidelines for Clocks and Resets -- Bad and Better Clocking Examples
Bad example: Mixed clock
Better example: Positive &
Guidelines for Clocks and Resets --Avoid Clock Buffers
Guideline: Avoid hand instantiating clock buffers in RTL code.
Clock buffers are normally inserted after synthesis as part of the physical design.
In synthesizable RTL code, clock nets are normally considered ideal nets, with no delays.
During P&R, use clock tree insertion tool (such as CT) for creating as close to an ideal, balanced clock distribution network as possible.
DIP/ 4-35
Guidelines for Clocks and Resets --Avoid Gated Clocks
Guideline: Avoid coding gated clocks in your RTL. Clock gating circuits tend to be technology specific and timing
dependent. Improper timing of a gated clock generates a false clock or glitch. Causing a flip-flop to clock in the wrong data.
The skew of different local clocks can cause hold time violations. Gated clocks also cause limited testability, because the logic
clocked by a gated clock can’t be made part of a scan chain. If individual flip-flops need to be gated within a design, the clock
gating should be inserted by a power synthesis tool, so that the RTL remains technology portable.
DIP/ 4-36
Guidelines for Clocks and Resets --Gated Clocks If Necessary
If the design requires a gated clock, model it in RTL using synchronous load registers. Poor Coding Style: Assign clk_p1 = clk and p1_gate;
always @ (posedge clk_p1) begin : ex5-17a_proc … end // ex5-17a_proc
Recommended Coding Style: always @ (posedge clk)
begin : ex5-17a_proc if (p1_gate == 1’b1) begin … end
end // ex5-17a_proc
DIP/ 4-37
Guidelines for Clocks and Resets --Limited Testability Caused by Gated Clocks
Reg C can not be clocked during scan-in, test, or scan-out, and can not be made part of the scan chain.
DIP/ 4-38
Guidelines for Clocks and Resets --Avoid Internally Generated Clocks
Guideline: Avoid using internally generated clocks in your design. Logic driven by the internally generated clock cannot be made part of a scan
chain and then cause limited testability. The internally generated clocks also make it more difficult to constrain the
design for synthesis. As an alternate, design synchronously or use multiple clocks.
Bad example : internally generated clock
DIP/ 4-39
Guidelines for Clocks and Resets --Gated Clocks for Low-Power
Gated clocks are required for many low-powered designs, but they should not be coded in the RTL for a macro.
Guideline: If you must use a gated clock, or an internally generated clock or reset, keep the clock generation circuitry as a separate module at the top level of the design. Partition the design so that all the logic in a single module uses a single clock
and a single reset. top
Clock generation
Guidelines for Clocks and Resets --Avoid Internally Generated Resets
Make sure your registers are controlled only by a simple reset signal.
Guideline: Avoid internally generated, conditional resets if possible. Generally, all the registers in the macro should be reset at the
same time. This approach makes analysis and design much simpler and
easier.
Guideline: If a conditional reset is required, create a separate signal for the reset signal, and isolate the conditional reset logic in a separate module.
DIP/ 4-41
Guidelines for Clocks and Resets --Example of Avoiding Internally Generated Resets
Poor Coding Style: always @ (posedge clk or posedge rst or posedge a)
begin : ex5-18a_proc if (rst a)
reg_sigs <= 1’b0; else begin
… end
… assign z_rst = rst a;
… // in the main module always @ (posedge clk or posedge z_rst)
begin : ex5-18a_proc if (z_rst)
… end
Guidelines for Clocks and Resets --Reset Logic Function
Guideline: The only logic function for the reset signal should be a direct clear of all flip-flops. Never use the reset inputs of a flip-flop to implement state machine
functionality. Reserving reset pins on flops for reset only makes it easier to
generate buffer trees for resets.
DIP/ 4-43
Guidelines for Clocks and Resets --Single-Bit Synchronizers
Guideline: Use two flip-flop stages to transfer single bits between clock domains. Label these flops with distinctive names to allow integrators to
specify metastability-resistant flip-flops and/or analyze metastability characteristics, it they wish. To prevent transfer of glitches, do not connect combinatorial logic
from one clock domain to another.
D Q
CLK2CLK1
Guidelines for Clocks and Resets --Multiple-Bit Synchronizers
Guideline: Do not use multiple copies of a single-bit synchronizer to transfer multiple bit fields (such as FIFO address fields) between clock domains. Instead, use a reliable handshake circuit or multibit coding scheme
such as Gray code.
DIP/ 4-45
Overview of the coding guidelines Basic coding practices Coding for portability Guidelines for clocks and resets Coding for synthesis Partitioning for synthesis Designing with memories
DIP/ 4-46
Coding for Synthesis --Purposes
Following the guidelines in this section will create code that achieves the best compilation times and synthesis results, including Testability Performance Simplification of static timing analysis Gate-level circuit behavior that matches that of the original RTL
DIP/ 4-47
Coding for Synthesis --Infer Registers
Guideline: Registers (Flip-flops) are the preferred mechanism for sequential logic. Use the template Use the design’s reset signal,
as shown in the template, to initialize registered signals. Do not use an initial
statement to initialize the signal.
//process with asynchronous reset always @ (posedge clk or posedge rst_a)
begin if (rst_a == 1’b1)
begin …
DIP/ 4-48
Coding for Synthesis --Avoid Latches
Rule: Avoid using any latches in your design. Exception: you can instantiate technology-independent
GTECH D latches. All latches must be instantiated and you must provide
documentation that lists each latch and describes any special timing requirements that result from the latch. Register files, FIFOs, and other storage elements are examples of
situations in which D latches are permitted.
Note: Use a design checking tool to check for latches in your design.
DIP/ 4-49
Coding for Synthesis --Latches Inferred Because of Missing Conditions
A latch is inferred automatically when a conditional statement is incompletely specified, such as missing else clause for the if statement or missing part of the assignments for the case statement.
always @ (d) begin
case (d) 2’b00: z<=1’b1; 2’b01: z<=1’b0; 2’b10: z<=1’b1; s<=1’b1;
endcase end
if (a == 1’b1) q <= b;
end
Missing case assignment
The above statement will cause the DC to infer a latch enabled by signal “a”.
DIP/ 4-50
Coding for Synthesis --Avoid Inferred Latches
Avoid inferred latches by using any of the following coding techniques Assign default values at the beginning of a process Assign outputs for all input conditions
always @ (d) begin
case (d) 2’b00: z<=1’b1; s<=1’b0; 2’b01: z<=1’b0; s<=1’b0; 2’b10: z<=1’b1; s<=1’b1; 2’b11: z<=1’b0; s<=1’b0;
endcase end
endcase;
endcase;
Coding for Synthesis --Another Example of Avoiding Inferred Latches
Poor coding style: always @ (g or a or b)
begin if (g == 1’b1)
q <= 0; else if (a == 1’b1);
q <= b; end
Recommended coding style:
q <= 1’b0; if (g1 == 1’b1)
q <= a; else if (g2 == 1’b1);
q <= b; end
Coding for Synthesis --If Using a Latch is Unavoidable
When using a latch is absolutely unavoidable, for instance in a PCI design, using the following techniques to achieve testability. Use a MUX to provide either the normal function or the input from an I/O pad
as data to the MUX. The MUX was selected by the mode pin used to enable scan.
DIP/ 4-53
Coding for Synthesis --Avoid combinational feedback
Guideline: Avoid combinational feedback. Combinational feedback means the looping of combinational processes. Combinational feedback causes a number of problems, including making
accurate static timing analysis very hard.
Bad example:
Coding for Synthesis --Specify Complete Sensitivity List
Rule: Include a complete sensitivity list in each of always blocks. The behavior of the pre-synthesis design may differ from that of the
post-synthesis netlist if the complete sensitivity list is not specified.
Synthesis tools as well as design checking tools can detect incomplete sensitivity lists and will issue a warning.
always @(a)
DIP/ 4-55
Coding for Synthesis --Sensitivity List
Combinational blocks The sensitivity list must include every signal that appears on the right side of an assign (<=)
statement or in a conditional expression. Sequential blocks The sensitivity list must include the clock signal that is read by the process.
Guideline: Avoid unnecessary signals in list to prevent from slowing down the simulation speed.
always @ (a or inc_dec) begin
if (inc_dec==0) sum = a+1;
else sum = a-1;
if (rst==0) q<=0;
else q<=d;
Coding for Synthesis --Blocking and Non-Blocking Assignments
Rule: When writing synthesizable code, always use non- blocking assignments in always @ (posedge clk) (sequential) blocks. The non-blocking assignments are order independent. Use of blocking assignments within sequential processes may
cause race conditions, because the final result depends on the order in which the assignments are evaluated. Non-blocking assignment is done using the “<=“ operator.
Use blocking assignments as much as possible within combinational always blocks. Blocking assignment is done using the “=“ operator.
DIP/ 4-57
Coding for Synthesis --Examples of Blocking and Non-Blocking Assignments
Poor coding style always @ (posedge clk)
begin b=a; a=b;
end
Coding for Synthesis --Case versus If-Then-Else
Guideline: The multiplexer is a faster circuit. Therefore. If the priority-encoding structure is not required, we
recommend using the case statement rather than an if-then-else statement.
Synthesis results Case statements infer single level MUX For large multiplexers, case is preferred because faster in cycle-based
simulator If-then-else infer priority encoder useful if you have a late arriving signal
Conditional assignment infers MUX assign z1=(sel_a)? a: b;
DIP/ 4-59
Coding for Synthesis --Case versus If-Then-Else
Circuits built from if-then-else statement
Circuits built from case statement
DIP/ 4-60
Coding state machines
Guideline Separate the state machine HDL description into tow processes,
one for the combinational logic and one for the sequential logic
Guideline In verilog, use `define statements to define the state vector
Guideline Keep FSM logic and non-FSM logic in separate modules
Guideline Assign a default state for the state machine
DIP/ 4-61
Examples of coding state machines
Poor coding style always @(posedge clk)
a <= b+c;
a_nst = b+c;
Outline
Overview of the coding guidelines Basic coding practices Coding for portability Guidelines for clocks and resets Coding for synthesis Partitioning for synthesis Designing with memories
DIP/ 4-63
Partitioning for synthesis
Good synthesis partitioning in your design provides several advantages Better synthesis results Faster compile runtimes Ability to use simpler synthesis strategies to meet timing
DIP/ 4-64
Register all outputs
Guideline For each block of a hierarchical design, register all output signals from the
block Output drive strengths equal to the drive strength of the average flip-flop Input delays predictable
Good examples
Locate related combinational logic in a single module
Guideline Keep related combinational logic together in the same module
Bad example Combinational logic split between modules
Combo logic CCombo
Locate related combinational logic in a signal module
Good example Combinational logic grouped into same module
Combo logic A & B & C
DIP/ 4-67
Separate modules that have different design goals
Guideline Keep critical path logic in a
separate module from non- critical path logic Can optimize the critical path
logic for speed Optimize the non-critical path
logic for area
Separate modules that have different design goals
Good example
Asynchronous logic
Guideline If asynchronous logic is required, partition the asynchronous logic
in a separate module form the synchronous logic
DIP/ 4-70
Merging resources
DIP/ 4-71
Merging resources
DIP/ 4-72
Partitioning for synthesis runtime
Good timing budgets and appropriate constraints can have a larger impact on synthesis runtime than circuit size. A key technique for reducing runtimes is to develop
accurate timing budgets early in the design phase and design the macro to meet these budgets. Most important considerations in partition Logic function, design goals and timing and area requirements
Grouping related functions together
Avoid point-to-point exceptions and false paths
Guideline Avoid multi-cycle paths in your design
Guideline If you must use a multi-cycle path in your design, keep point-to-
point exceptions within a single module, and comment them well in your RTL code.
Guideline Avoid false paths in your design
DIP/ 4-74
Eliminate glue logic at the top level
Guideline Do not instantiate gate-level logic at the top level of the design
hierarchy
Eliminate glue logic at the top level
Good example
Chip-level partitioning
Guideline Make sure that only the top level of the design contains an I/O
pad ring
Pad Top
Clock Generation
Core Logic
Outline
Overview of the coding guidelines Basic coding practices Coding for portability Guidelines for clocks and resets Coding for synthesis Partitioning for synthesis Designing with memories
DIP/ 4-78
Designing with memories
Guideline Partition the address and data registers and the write enable logic in a separate module
Synchronous memory interface Asynchronous memory interface
DIP/ 4-79
Designing with memories