lec12 1slide per page

7/31/2019 Lec12 1slide Per Page

1/65

The art ofalgorithm to architecture mapping

Adv Digital Design

By Dr. ShoabAhmed [email protected]

Fall 2002

Coding Guide Lines

Engineering Education Trust

Center forAdvanced Studies in Engineering

5-A Constitution Avenue, Software Technology Park. Islamabad, Pakistan.


2/65

Guidelines for writing efficientRTL-level Verilog HDL code


3/65

3Adv. Digital Design By Dr. Shoab A. Khan

Naming Conventions

Rule:All names (signals, variables, modules) in lowercase,

parameters and macros in uppercase characters.Use a single underscore ('_') to separate parts of a name,

don't use it as first or last character.

Example:

BAD: BETTER:

parameter width = 16; parameter WIDTH = 16;

input [width-1:0] DataIn; input [WIDTH-1:0] data_in;


4/65


Active low signals

Rule:Active low signals must end with '_n'.


5/65


Clk and res_n

Rule:All synchronous modules must usean asynchronous active-low reset called "res_n"

a clock signal called "clk".

Explanation:

The names of clock and reset signals should be thesame throughout the whole design.

If multiple clocks are needed, they should use "clk" ascommon suffix, e.g. "bus_clk".

An asynchronous active-low reset is the most commonsupported type of reset found in today's cell libraries.

always@(posedge clk or negedge res_n)

if(!res_n)


6/65


Names

Use meaningful names for variables, signals, modules, FSMstates, etc.

Don't use reserved HDL keywords, either Verilog or VHDL.

Explanation:This makes the HDL code much more readable.

Common pre-/suffixes like 'addr', 'ctrl', 'en', 'data', 'val', etc. help alot to understand the functionality of a design.

Example:BAD: BETTER:

wire w1; wire addr_bus_en;

reg dff6; reg bus_data_val;

// state names s0, s1, s2, ... // state names IDLE, RUN, WAIT, ...


7/65


Comments

Rule:Use comments for modules and every major code block to

describe the functionality.

Explanation:

This enables other designers to understand your logic in a

reasonable amount of time.

Example:

/* - describe the functionality of the module - I/O constraints */

module top (...);

/* implements comb/seq logic for ... */

always @(...) ...


8/65


FSM Implementation Style

Rule:Prefer Moore machines over Mealy FSMs.

Explanation:

Mealy machines have the disadvantage that the

outputs depend on the inputs, which means you haveasynchronous paths in your design.


9/65


Design Methodology

Rule:Find the right balance for your design hierarchy.

Explanation:

Too large modules (with hundreds of lines of HDL

code) may become un-managable and lead tounacceptable tool run times.

Too small modules (with just a few gates) prevent

synthesis tools from finding an optimal implementationfor your logic.


10/65


Registered Outputs

Rule:All major functional blocks must have registered

outputs.

Explanation:

It avoids asynchronous paths running through severalfunctional blocks.

Synthesis tools have a much easier job to meet timing

goals, when designs stick to this rule.


11/65


Combinational Logic

Rule:

Use continuous assignments only for small equations, always blocksfor larger logic. Use only blocking assignments for combinational logic.

Explanation:

Continuous assignments spread over multiple lines of code (e.g. usingif-then-else) become unreadable.

Example:

2-4 decoder using an always block 2-1 MUX using a cont.assignment

always @(din) assign out = (sel == 1'b0) ? a : b;

begin : decode

case (din)

2'b00: dout = 4'b0001;

2'b01: dout = 4'b0010;2'b10: dout = 4'b0100;

2'b11: dout = 4'b1000;

default: dout = 4'bxxxx;

endcaseend


12/65


Sequential Logic

Rule:Use always blocks with non-blocking assignments for sequential logic. Specifyasynchronous behavior first, followed by the normal operation.

Explanation:Asynchronous behavior must be specified at the beginning of an if-then-else

statement to be recognized correctly by synthesis tools, followed by the normaloperation of the cell.

Example:8-bit counter with parallel load

always @(posedge clk or negedge res_n)

begin : main

if(res_n == 1'b0) // asynch. reset

cnt


13/65


Assignment

Use blocking assignments to model combinationallogic within an always block.

Rule:

Use non-blocking assignments to implementsequential logic.

Rule:

Do not mix blocking and non-blocking assignments in

the same always block.

Rule:Do not make assignments to the same variable frommore than one always block.


14/65


Sensitivity List

Rule:Include all signals in the sensivity list of an always blockdescribing combinational logic, that are interpreted (read) withinthe block (signals on RHS of assignments, signals in conditions,

etc.).

Explanation:

This rule ensures that no unwanted latches are inferred duringsynthesis. Why do they appear? Because the goal of thesynthesis tool is a functional equivalent gate-level implementationof your RTL code. So if your sensitivity list misses one signal, a

simulator will not trigger the always block on its transition. Thatmeans, a transition of one of the inputs to the combinational logicblock does not result in an updated output value. To match thisbehavior, the synthesis tool has to insert a latch.


15/65


Example

Example:2-1 multiplexer resulting in an inferred latch

always @(a or sel) // incomplete sensivity list

begin : mux

case (sel)1'b0: y = a;

1'b1: y = b; //


16/65


Rule:Label all begin...end statement blocks.

Explanation:

This can help you to locate design parts during

debugging. Use short but meaningful names, like in allexamples in this guide.


17/65


Case

Rule:If no priority is required, make sure that the different

cases are mutually exclusive.

Explanation:

The synthesis tools checks for overlapping caseswhen it parses the HDL code. If it finds some, the

resulting logic uses a priority scheme. This chained

logic is significantly slower than full parallel logic,which is otherwise build.


18/65


Implement a 4-2 encoder

Two ways to implement a 4-2 encoderBAD:

always @(din)

begin : encode

casex (din)

4'bxxx1: dout = 2'b00; // highest priority!

4'bxx1x: dout = 2'b01;

4'bx1xx: dout = 2'b10;4'b1xxx: dout = 2'b11; // lowest priority!

default: dout = 2'bxx;

endcase

endSometimes it's a good idea to use casex and x's tospecify "don't care" bits. But here all the cases overlapand you end up with priority logic during synthesis!


19/65


Example

BETTER:always @(din)begin : encode

case (din)

4'b0001: dout = 2'b00;4'b0010: dout = 2'b01;

4'b0100: dout = 2'b10;

4'b1000: dout = 2'b11;

default: dout = 2'bxx;endcase

end

At first, this might look like it results in more logic. But

now all cases are mutually exclusive and the synthesistool is allowed to use a parallel implementation for yourlogic, which is significantly smaller and faster!


20/65


Avoid Latch

Rule:Always cover all input patterns, either by specifying

them or using a default case.

If possible, assign "don't care" to the output for the defaultcase.

Explanation:

If not all possible cases are specified and no default

case is given, the synthesis tool infers latches to hold

the output value during the uncovered terms.

Assigning an 'x' is interpreted by a synthesis tool as "don't

care", which gives room for further logic optimization.


21/65


If-Then-Else Statements

Rule:Avoid long if-then-else chains.

Explanation:

Large if-then-else chains are hard to overlook. There

is also again the pitfall of ending up with priority logic,when multiple conditions within one statement overlap.

One should better use a case statement with mutually

exclusive cases.


22/65


Example:

The same 4-2 encoder as above, now with if-then-else

BAD:

always @(din)

begin : encodeif (din[0] == 1'b1)

dout = 2'b00;

else if (din[1] == 1'b1)

dout = 2'b01;else if (din[2] == 1'b1)

dout = 2'b10;

else if (din[3] == 1'b1)

dout = 2'b11;else

dout = 2'bxx;

end


23/65


Port Declarations

A consistent port declaration order can improvethe reusability of your designs.

Rule:List ports in the following order: outputs, clocks/resets,inputs.

Explanation:

This complies to the method defined for Verilogprimitives. Also define one port per line inside amodule for better readability.


24/65


Port Declarations

Rule:Use connection by name when instantiating a submodule.

Explanation:

Following this rule, it is explicitly specified, which signal shouldconnect to which port. Connection by order can introduce errors,when the port order inside the sub-module changes.

Example:BAD:my_submod instance1(data_out, core_clk, data_in);

BETTER:my_submod instance1(.dout(data_out), .clk(core_clk),.din(data_in));


25/65


D Type Flip Flops:

Two things to note about inferring flip flops:Non blocking signal assignment (


26/65


D-type flip flop

reg q;always @ (posedge clk)

q


27/65


D type flip flop with asynchronous reset

reg q;always @ (posedge clk or

posedge reset)

if (reset)q


28/65


D type flip flop with synchronous reset


if (reset)

q


29/65


D type flip flop with gated clock

reg q;wire gtd_clk = enable &&

clk;

always @ (posedge gtd_clk)q


30/65


Data enabled D type flip flop


if (enable)

q


31/65


Negative edge triggered D type flip flop

reg q;

always @ (negedge clk)

q


32/65


Latch

reg q;

always @ (q or enable)

if (enable)

q = d;


33/65


Multiplexers


34/65


Two input multiplexer (using if else)

reg y;

always @ (a or b or select)

if (select)

y = a;

else

y = b;


35/65


Two input multiplexer (using ternary operator ?:)

wire t = (select ? a : b);


36/65


Two input multiplexer (using case statement)

reg w;// mux version 3


case (select)

1'b1 : w = a;

default : w = b;

endcase


37/65


Two input multiplexer (using default assignment and if)

reg p;// mux version 4


beginp = b;

if (select)

p = a;

end


38/65


Three input multiplexer with no priority (using case)

reg s;

always @ (a or b or c or select2)

begin

case (select2) // synopsys parallel_case

2'b00: s = a;

2'b01: s = b;

default: s = c;endcase

end


39/65


Comparator (using assign)

module comparator1 (a,b,c);

input a;

input b;output c;

assign c = (a == b);

endmodule


40/65


41/65


Implementation Technologies


42/65


Synthesis Design Flow


43/65


General Coding Style Guidelines

Unintentional Latch InferenceForif, set default value beforehand or specify

value forelse.

Forcase, set default value beforehand or usedefault in case or

If you know for sure some cases will not occur

use compiler directive // synopsys full case


44/65


Separating Combinational and Sequential Assignments

FSM Outputs

Sequential (Registered) - Can include in

clocked alwaysCominational (Not Registered) - Use

asynchronous always for outputs

If Mealy, depend on inputs as well as statePlace inputs in this case in sensitivity list


45/65


Design Partitioning for Synthesis

StrategiesPartition for design reuse

Keep related combinational logic together

Avoid glue logic, particularly at top level

Register block outputs

Partition by design goal

Partition by compile technique

Keep sharable resources together

Place large SRAMs and DRAMS at top core levelSize blocks based on available computational

resources


46/65


Design Reuse

Partition so that existing designs can be

used in your design

To permit future reuse:Define and document interface thoroughly

Standardized interface

Parameterize the code


47/65


Keeping Related Combinational Logic Together

Reasons:

Default DC cannot move logic across hierarchical

boundaries

Logic optimization cannot cross block boundaries

Group related combinational logic & destination

register togetherImproves logic optimization potential

Enables sequential optimization


48/65


Avoid Glue Logic

Glue LogicSmall amounts of logic added to correct

interface mismatch or add missing

functionality

Eliminating glue logic

Improves logic optimization potentialReduces compile time

At top level, simplifies floor-planning

R i d l


49/65


Register module outputs

If module outputs are not registered:long, complex inter-module delay paths

canexistExample

Simulation speed is slower due tosensitivity

lists that contain more than clock & reset

Example

Drive strengths on inputs to modules differ

R i t d l t t ( ti d)


50/65


Register module outputs (continued)

Negatives

Registering outputs may add clock periods

to system delays for function executionRegistering outputs may severely restrict

module boundary locations

P titi b D i G l


51/65


Partition by Design Goal

Design Goals

Area minimization

Delay minimizationBy partitioning on design goals:

Allows area constraints on logic without timing issues

Allows timing constraints on logic without areaissues

Reduces optimization effort

P titi b C il T h i


52/65


Partition by Compile Technique

Compile TechniquesForcing Structure (factoring)

Forcing Flattening (2-level logic)

Examples:

XOR-heavy error detection and correction

Circuits should be structuredRandom logic should be flattened

Therefore, should not be together in module

K Sh bl R T th


53/65


Keep Sharable Resources Together

Only resources within the same always

can be shared.

K UDR ith th L i Th D i


54/65


Keep UDRs with the Logic They Drive

If duplication to meet timing constraints is

necessary, can do it

Delay may be reduced by reducing the fanout

on a given UDR by duplicating it

I l ti S i l F ti


55/65


Isolating Special Functions

Includes pads, I/O drivers, clock generation,boundary scan, and asynchronous modules

The external interface should be at the top level

and not placed in modules

Special functions that tie to the interface should

be at the next hierarchical level down

Asynchronous functions should be separate

modules at an appropriate level of the hierarchyExample: Figure 3-10 DCUG

Place large SRAMs DRAMS & ROMs at top core level


56/65


Place large SRAMs, DRAMS & ROMs at top core level

Relates to physical design interaction with

synthesis

Large memory structures need to beplaced in the floorplan independently of

logic

Floorplanning is needed to do accurate

timing analysis and control

Example

Size blocks based on computational resources


57/65


Size blocks based on computational resources

Large blocks permit optimization flexibility

Large block my overwhelm workstation in

terms of memory, swap space or processingthroughput

Large blocks my cause excessive compile

times

Thus, need to select workable intermediate size

for blocks

Partitioning for Synthesis


58/65



Register all outputs.

A A B CC



59/65



Separate modules that have different designs

Preferred way

Critical

logic

Non

Critical

Critical

logic

Non

Critical

area

Synthesized data for time Synthesized for area

Control

Avoid Asynchronous Logic


60/65


Avoid Asynchronous Logic

You might be able to convert asynch synchIf required partition asynchronous logic in separate

module

If delay required you may use buffers

A

A A A0 21

For generating a pulse

Merging Resources


61/65


Merging Resources

If ( cnt )

z = a+b

elsez = c+d

better way

using one adder

+

+

a

b

a

c

+ zb

d

Select operands

Resource sharing off

Eliminate glue logic at the top level


62/65


Eliminate glue logic at the top level

In top level you must use only instantiations

C

move this inside

Bad Design

Instantiation of modules

Coding for synthesis


63/65


Behavioral

Coding for synthesis

Simulation

AlgorithmicBehavioral level

RTL for synthesis

FPGAFPGA

RTL

device

Concerned with this one


64/65

Avoid latches


65/65

Avoid latches

Avoid combinational loopback.

Combinational

cloud

Combinational

cloud

Combinational

cloud

lec12 1slide per page

Documents