Chapter 1

Basic Design Constraints

Chapter 1 Basic Design Constraints

This chapter introduces naming conventions and synchronous design issues that
should be kept in mind during the design process, as well as considerations and
cautions relating to asynchronous design, clocks, and hierarchical design.

1.1 Naming conventions

Contents 1.2 Synchronous design
1.3 Initial reset
1.4 Clocks
1.5 Handling of asynchronous circuits
1.6 Hierarchical design

1-1
 1.1. Naming Conventions

1.1. Naming conventions

1.1.1. Basic naming conventions
[1] File names should be as follows: ”<module name>.v”
Chapter 1

recommend 2
[2] Only alphanumeric characters and the underscore ’_’ should be used,
mandatory
and the first character should be a letter of the alphabet
Basic Design Constraints

[3] Key words in Verilog-HDL(IEEE1364), VHDL(IEEE1076.X) must not be used mandatory

[4] Names containing ”VDD”, ”VSS”, ”VCC”, ”GND” or ”VREF” mandatory

must not be used (uppercase or lowercase)

[5] Do not distinguish names by using upper or lower case English letters mandatory
(Abc, abc)

[6] Do not use an ’_’ (underscore) at the end of the primary port name or
recommend 1
module name, and do not use ’_ ‘ consecutively

[7] Add an identifying symbol at the end of the name so the polarity of
recommend 2
negative logic signals is clearly identified (”_X” , ”_N”, for example)

[8] Instance names should basically be the module names. Instance names
recommend 3
that are used more than once should be ”<module name>_<quantity>”

[9] At the top level, module names and port names should consist of 16 or fewer
characters and should not be distinguished by upper or recommend 1
lower case alphabet letters

[10] Do not use the same instance name or cell name as the ASIC library
mandatory
being used

Explanation

Verilog-HDL Keywords (lower case)

always, and, assign, begin, buf, bufif0, bufif1,
case, casex, casez, cmos, deassign, default, defparam,
disable, edge, else, end, endattribute, endcase,
endmodule,endfunction, endprimitive, endspecify, endtable,
endtask, event, for, force, forever, fork, function,
highz0, highz1, if, ifnone, initial, inout, input,
integer, join, large, macromodule, medium, module,
nand, negedge, nmos, nor, not, notif0, notif1,
or, output, parameter,pmos, posedge, primitive,pull0,
pull1, pulldown, pullup, rcmos, real, realtime, reg,
release, repeat, rnmos, rpmos, rtran, rtranif0, rtranif1,
scalared, signed, small, specify, specparam,strength, strong0,
strong1, supply0, supply1, table, task, time, tran,
tranif0, tranif1, tri, tri0, tri1, triand, trior,
trireg, unsigned, vectored, wait, wand, weak0, weak1,
while, wire, wor, xor, xnor

1-2
 1.1. Naming Conventions

VHDL Keywords (do not exist in Verilog-HDL)

abs, access, after, alias, all, architecture,array,
assert, attribute,block, body, buffer, bus, component,
configuration, constant, disconnect,downto, elsif, entity,
exit, file, generate, generic, group, guarded, impure,

Chapter 1
in, inertial, is, label, library, linkage, literal,
loop, map, mod, new, next, null, of,on,
open, others, out, package, port, postpond, procedure,
process, pure, range, record, register, reject, rem,
report, return, rol, ror, select, severity, signal,

Basic Design Constraints

shared, sla, sll, sra, srl, subtype, then,
to, transport,type, unaffected, units, until,
use, variable, when, with

Examples of negative logic signal names

SIGA_X,reset_X,EN2B_X,enb_X

Examples of instance names

Hard_rend Hard_rend( .CLK(CLK), .RST_X(RST_X), ...
USBintf USBintf_0( .CLK(CLK), .RST_X(RST_X), ...
USBintf USBintf_1( .CLK(CLK), .RST_X(RST_X), ...

Example 1-1 Basic naming conventions

Identifiers such as module names , instance names , signal names and port names must
facilitate understanding of the HDL description functions. Names that make debugging
more efficient should be carefully chosen because if different naming conventions are used
by different designers, circuits that were divided into sections by multiple designers will
be difficult to understand when they are integrated. This is why consistent naming con-
ventions are important. Further, if design tools are used to automatically analyze or
modify the circuit structure, uniform command convention being used will allow easier
description of script code.

A single file should contain a single module, but this is unfit for a large design with many
files since it becomes difficult to handle. In this case, multiple modules can be included in
a file, but modules which have no relation to one another should not be included in the
same file. A single file should include modules which have a tree hierarchical structure.
The top module name and file name should be the same.

In the case of Verilog-HDL, the characters !, @, #, $, \, {, } can also be used if an Escape

identifier is used. However, since this cannot be used with VHDL(87) and there is a risk
of problems occurring in the system at a subsequent stage, it is recommended that no
characters other than alphanumeric characters and the ’_’(underscore) be used. [2]

Since keywords defined in Verilog-HDL language specifications are in lower case, a de-
signer would have the advantage of names being easily distinguishable within the code,
provided that identifiers such as designer-defined I/O signal names were defined in upper
case letters. Since Verilog-HDL is case-sensitive, it is possible to define an identifier in
upper case letters in situations such as this with the same spelling as the keyword, al-
though it is not recommended because it could lead to confusion (INPUT, TASK for ex-
ample). In addition to Verilog-HDL keywords, software and VHDL keywords that are used
at later stages should be avoided as well. [3]

1-3
 1.1. Naming Conventions

The use of EDIF, SDF and Windows keywords will not cause problems. Nevertheless, it is
a better practice not to use these keywords. If need be, refer to the following section to
help avoid any possible confusion.
Chapter 1

Avoid using as SDF, EDIF keywords:

ABSOLUTE,cell,celltype,edif,DELAY,HOLD,IOPATH,NET,VIEW,SETUP

Avoid using as a Windows keyword:

Basic Design Constraints

CON,AUX,COM1,COM2,COM3,LPT1,LPT2,PRN,NUL

When a naming convention is specified by a semiconductor technology flow in use, the

convention is prioritized. Specify keywords, usable characters, and the limitation of char-
acters in accordance with the conventions. Semiconductor naming conventions often limit
the usage of upper case or lower case letters. In situations where the same names are
used (e.g. Abc, ABC), logic synthesis tools are used to modify these names. Unless explicit
naming convention rules are specified, these naming modifications will alter one of the
names quite significantly. If names are altered significantly, post-layout verifications will
become very difficult to understand. All names should not be distinguished solely by the
cases of the letters used (e.g. abc vs. ABC, eFG vs. Efg).[5] The use of upper and lower case
letters in comment statements is acceptable.

In VHDL there is a convention which states that the final character must not be ’_’. This
character is sometimes used in gate level verification by VITAL, so please refrain from
using ’_’ at the end of top level module names and port names . In addition, it is also
forbidden to use ’_’ consecutively. [6]

Add an identifying symbol (”_X”,”_N”, for example) at the end of negative logic signals
(suffix). [7] If an identifier is added at the top of signals (prefix), like ”X_”, it becomes
difficult to distinguish it from identifiers of hierarchies or identifiers of delimiting func-
tion . Therefore, to identify negative logic signals, delimit with ”_” at the end followed by
identifying characters such as ’X’ and ’N’. If adding an identifier of clock system at the
end, an identifier of negative logic signal can be used just before it. Describe identifiers
used in the document. As a rule, the same name should be used for the module name and
the file. This makes it easy to generate script when using a simulator or a logic synthesis
tool.

Instance names should be based on the module name and ”< module names >_<quantity>”
if multiple instances exist. [8] If an instance name that does not conform to this naming
convention (all the rules of user definition) is used, explicity describe it in the document.

In order to be used as the IP core, module names in the top level must use only alphabeti-
cal letters or numbers and be 16 or fewer characters in length. Port names should be 16
or fewer characters in length, and must use alphabetical letters, numbers, or ’_’. Names
beginning or ending with ’_’ and names that use ’_’ consecutively are prohibited. To sup-
port systems that are not case sensitive, names should use only upper case or lower case
and cases should not be mixed. [9]

1-4
 1.1. Naming Conventions

Refer to the following sections for rules on file naming, signal naming, pin naming and
module naming, etc .
"1.1.2. Naming conventions of circuit and port names should be considered by the hierarchy"
"1.1.3. Give meaningful names for signals"

Chapter 1
"3.1.3. Standardize description order of module I/O ports"
"3.5.2. File suffix names"

Basic Design Constraints

RTqualify checks all the items of 1.1.1.
Characters used and the limitation on the number of characters may be changed by variables in
the rule file.
1111a(W2) File name "<file_name>" does not match module name "<module_name>".
1111b(W3) Multiple unrelated modules exist in file "<file_name>".
1112a(E) Cell name is not of format specified by cell_naming_style.
1112b(E) Top layer module name is not of format specified by top_module_naming_style.
1112c(E) Module name is not of format specified by module_naming_style.
1112d(E) Function name is not of format specified by function_naming_style.
1112e(E) Instance name is not of format specified by instance_naming_style.
1112f(E) Signal name is not of format specified by signal_naming_style.
1113a(E) Same word as reserved word in Verilog-HDL is used including capital letters.
1113b(E) <category_file_name> reserved word "<*_name>" used as a [signal name | port name
| instance name | cell name | function name | task name | parameter name].
1114a(E) "<*_name>", which includes <category_file_name> reserved word
"<reserve_word>", used as a [signal name | port name | instance name | cell
name | function name | task name | parameter name].
1114b(E) "<*_name>" is formatted in a way that is specified for reserved words.
1115a(E) Identical identifiers (except for different capitalization) used in same module.
1115b(W2) Identical identifiers (except for different capitalization) used in different module.
1116 (W1) Two or more adjacent •e_•f characters used in [module_name | port_name].
1117a(W1) No ID character for low-active signal. (Not to be checked by default setting)
1117b(W1) No ID character for low-active clock. (Not to be checked by default setting)
1117c(W1) No ID character for low-active set/reset signal.
(Not to be checked by default setting)
Limited check is applied to 1117 as positive and negative logics can not be distinguished.
1118a(W3) Instance name "<instance_name>" neither same as the cell name “<cell_name>",
nor includes the cell name.
1118b(W3) Instance name "<instance_name>" not of specified format.
1119a(W1) Top layer module name longer than <n=12> characters.
1.1.1.[10] can be checked by 1113b by registering the library name of the ASIC vendor in
category_file.

Naming conventions are explained in RMM:5.2.1. There is no limitation for the number of
characters in RMM and negative logic has _n at the end.

1-5
 1.1. Naming Conventions

1.1.2. Naming conventions of circuit and port names should be considered by the hierarchy

[1] Module names and instance names should be between 2 and

mandatory
32 characters in length
- A length of 16 or fewer characters is recommended (recommend 2)
Chapter 1

- Instance names with hierarchy should be less than 128 characters

(recommend 3)

[2] Add a hierarchy identification character to the beginning of

recommend 3
Basic Design Constraints

the top level block name

[3] Add the hierarchy identification character of the upper level

recommend 3
to the hierarchy identification character of the sub-block

[4] The first string of an output port name for each block should be
recommend 3
“<hierarchy identification character>” + “_”

[5] Naming conventions for input port names and output port names reference
for each block should be different from those for internal signal names

[6] Output port names and the connected net names should be the same
recommend 2
- Upper level net names and the input port names should be the same
(recommend 2)

Example Code

For each design unit (IP), define a block name (max. 16 characters)

geomet lendar cpuif video ramif

gtex gmap grip gfloat g c on t 'g' is a hierarchy identifier

Create a unique name with minimum characters to use it as a hierarchy identifier

Hierarchical identifier names will be carried to lower layers

Output port names of each block should start with “<block name’s hierarchy id> “ + “ _ “ [4]

g_PX g_PY g_PZ g_DONE --- Output port name of geomet

gt_PX gt_PY gt_PZ gt_DONE --- Output port name of gtex

Example 1-2 Naming following the convention

Explanation
Module name and instance name should be between 2 and 32 characters in length. Some
ASIC vendors have a limitation of up to 32 characters. Logic synthesis tools will change
module or instance names if they exceed 32 characters. Instance names should not be
long because readability decreases when confirming a signal value of the third, fourth or
lower layers of hierarchy by a simulator or confirming timing analysis report. Instance
names of 16 or fewer characters is recommended.

1-6
 1.1. Naming Conventions

A hierarchy created by a designer may be flattened (ungrouped) by tools which is used at

later stages. If it occurs, the instance names of module between the top and the ungrouped
module are added to the top of the signal name and instance name of the ungrouped one.
It becomes problematic at later stages if a hierarchy is deep and the instance name is

Chapter 1
long. Therefore, it is recommended that an instance names including module hierarchy
should be 128 or fewer characters.

A description can be made more readable and debugging efficiency improved by naming

Basic Design Constraints

identifiers such as circuit names, signal names , and instance names in the HDL descrip-
tion with a uniform naming convention that follows the hierarchical structure. If it is
necessary for a circuit to be partitioned and the partitioned modules have identical names,
confusion will be introduced. Care must therefore be given to the instance name and
module name of each level of hierarchy.

The hierarchy identification character is the first letter of the top (root) level instance
name. [2] Also, the hierarchy identification character of the top level will be added to the
beginning of the instance name in the level under that. [3] Example 1-2 illustrates the use
of a unique letter (g, l, c, v, r) as the hierarchy identification character for the first
character of instance names placed at the top level. There are five instances in this case.
The sub-block name under the geomet block adds an identification character (gt, gm,
gr, gf, gn, gc) at the beginning that includes the geomet level identification charac-
ter (g). By adding a hierarchy identification character to the beginning of each hierarchy
name in this manner, it becomes possible to prevent the exact same name from appearing.

The number of identification characters would be too large if the hierarchy identification
characters of the levels under each sub-block consecutively inherit the hierarchy identifi-
cation characters of its upper level.
(Example : geomet(g) -> gtex(gt) -> gt1port(gt1) -> gt1count(gt1c))
It is not essential that all upper level hierarchy identification characters be included in
the hierarchy identification characters of a sub-block, but it is necessary to use at least
the upper hierarchy identification characters at the beginning as well as be unique within
designs.

Using the hierarchy identification characters for each level of hierarchy in the output port
names facilitates debugging. [4] The initial character of the block should be added at the
beginning. This is to make it easier to understand which block a signal is output from
when debugging. Defining module names , signal names , and instance names that con-
form to the naming conventions makes it easier to examine a circuit during debugging
and improves readability of the code.
Be sure to follow these naming conventions during the entire design process.

1-7
 1.1. Naming Conventions

TIM
TREG
TRA_SIG TRA_SIG TRA_SIG
TRADD
Chapter 1

For some cases, T_SIG Add one character that expresses the block at
the beginning of each signal
Basic Design Constraints

Use signal name of output ports

ENCORDER
EGEN
TRA_SIG

Figure 1-1 Naming convention according to hierarchical structure

Figure 1-1 illustrates the naming conventions for module names and signal names in
circuits that have a hierarchical structure. The initial character in the string of the sub-
blocks under the upper level must be a unique character within the same level. Module
names under the sub-blocks add to their beginning one character that indicates a module
name in a top level, making it easier to understand the hierarchical structure by the
module name alone.

Use signal name of output ports for signal names in the hierarchical structure. By doing
so, it allows you to know from which module name that identifier is generated. A general
rule is illustrated in Figure 1-1: when output ports from a lower level end up as an upper
level output, the lower level output port name is used as is.

It would be useful to have a different naming convention for input/output signal names for
a block. [5] One example is to use only upper case characters for the block’s I/O signal
names and to use lower case for the internal signal names . This will simplify distinguish-
ing between external signal names and internal signal names . But these I/O signal names
are often converted to all upper case or lower case after synthesis and layout using an
ASIC vendor’s tools. Therefore, some suggest that either all upper case or all lower case
be used.
However, it is not easy to read names if all upper or lower case characters are used. As
long as you follow the rule described in item 5 of “1.1.1. Basic naming conventions”: “Do
not distinguish names by using upper or lower case English letters”, it will help improve
readability when using both upper case and lower case characters.

It is best that the net name of the upper level to which an output signal name is connected
and the input signal name are the same. [6] The output signal name is used for an input
signal name even when the output signal is input to multiple blocks. This is because
output signals are more important for debugging purposes.

During the initial stage of a collaborative design by a large number of designers, the out-
put port name of the blocks is sometimes unknown. In such a case, an input signal name
cannot follow the rules. At the very least, the output port name and net name should be

1-8
 1.1. Naming Conventions

the same. Top level output ports may lead to confusion if a hierarchy name is included, so
hierarchy identification characters should not be added. This rule does not apply to mod-
ules used more than once like a design library or to the small sub-blocks.

Chapter 1
For a large scale design or block (200K to 1,000K gates equivalent), avoid using multiple
instances of a single module (10K to 20K gate equivalent). The reason for this is when
logic synthesis is applied, the contents of each instance will be optimized differently and
module names will also be altered. It is confusing to have a module name which is differ-

Basic Design Constraints

ent from the RTL description. For large scale blocks (such as those mentioned above),
hierarchical structure is not flattened.

If a signal name is used more than once, the upper net name should basically consist of
”<hierarchy identification character>”+ ”<number added to instance name>”+”_”+”<output
signal name (without hierarchy identification character)>”.

module GEOMETOR ( ...

...
GFLOAT GFLOAT_0( .GF_DATA(GF0_DATA), GF_CARRY(GF0_CARRY),
GFLOAT GFLOAT_1( .GF_DATA(GF1_DATA), GF_CARRY(GF1_CARRY)

Example 1-3 Upper level net name when using multiple instances

With regard to bi-directional bus signals, the upper net name and lower input/output port
name should be the same and an hierarchy identification characters should not be added
because multiple outputs exist.

RTqualify checks all the items of 1.1.2. All naming conventions can be defined by regular
expression. However, checks are based on limited specifications for 1122, 1123 and 1124.

1121a(E) Module name longer than <n=20> characters.

1121b(W3) Module name longer than <n=8> characters.
1121c(E) Module name shorter than <n=2> characters.
1121d(E) Cell name longer than <n=20> characters.
1121e(W3) Cell name longer than <n=8> characters.
1121f(E) Cell name shorter than <n=2> characters.
1121g(E) Instance name longer than <n=20> characters.
1121h(W3) Instance name longer than <n=8> characters.
1121i(E) Instance name shorter than <n=2> characters.
1122 (W3) No layer ID character added to layer name.
1123a(W3) Sublayer does not inherit layer ID character.
1123b(W3) Layer ID character not unique within a single layer.
1124 (W3) Layer ID character not used in output port name.
A large number of warning messages may be output for 1123 and 1124.
If not necessary, exclude them by using ignore_message.

1-9
 1.1. Naming Conventions

1125a(E) Not of format specified by input_port_naming_style.

1125b(E) Not of format specified by output_port_naming_style.
1125c(E) Not of format specified by inout_port_naming_style.
Chapter 1

1125d(E) Not of format specified by top_input_port_naming_style.

1125e(E) Not of format specified by top_output_port_naming_style.
1125f(E) Not of format specified by top_inout_port_naming_style.
1126a(W2) Output port name "<name>" does not match net name "<name>"
Basic Design Constraints

to which it is connected.
1126b(W2) Net name "<net_name>" of higher net does not match input port name
"<port_name>".
1126 will not be checked if the same module is used for two or more times.

With RTqualify, all the numeric values and naming_style can be modified by setting file.

Naming conventions are explained in RMM:5.2.1. RMM recommends using lower case charac-
ters for all names.

1-10
 1.1. Naming Conventions

1.1.3. Give meaningful names for signals

[1] Naming conventions for internal signal names of blocks should be different from
reference
those for input and output ports

Chapter 1
[2] Give meaningful and comprehensive names for internal signal names of reference
hierarchy

[3] Signal names, port names, parameter names, `define names and

Basic Design Constraints

mandatory
function names should be between 2 and 40 characters in length
- The length of 24 or fewer characters is recommended (recommend 2)

Example Code

_X,_N should be added at the end of signal names when using negative logic

if ( !RESET ) if ( !RESET_X )
Q <= 1'b0; Q <= 1'b0;

Explicit naming of positive logic

if ( PLUS_or_MINUS ) if ( PLUS )
Q <= Q + 1'b1; Q <= Q + 1'b1;
else else
Q <= Q - 1'b1; Q <= Q - 1'b1;

Internal signals
DataMemWrite - Memory write signal
DataMemAdr[31:0] - Memory address
pos_GT_cos - Comparison result
Counter_Load_Val - Load signal to register
Hsync_conter_clear - Reset signal of counter

Parameter names
parameter P_Slot_length = 4'd10;
parameter P_Timegrad_length = 3'd3;
parameter P_StvRiseStartPoint= 0;
parameter P_StvFallStartPoint= 8'd111;

Example 1-4 Giving meaningful names

Explanation
Giving meaningful names to signal names and port names improves the readability of a
description and enhances the debugging efficiency. [2] If the internal signal name of
DataMemWrite in Example 1-4 was DMW, it would be difficult for others to understand.
Therefore, give meaningful names using a mix of upper and lower case letters.

If following “1.1.1.[5] Do not distinguish names by using upper or lower case English let-
ters” strictly, only either upper or lower case letters may be used for all the signal names ,

1-11
 1.1. Naming Conventions
port names and module names . However, readability decreases if all of those names are
either all upper or lower case letters. The item of 1.1.1[5] can currently be checked by the
RTL check tool. It is preferable to mix upper and lower case letters after checking by
these kind of tool. A meaningful name is preferred for increased readibility over a short
Chapter 1

simplified name as long as it is between 24 and 40 characters.

Naming conventions should be specified for port names , internal signal names and param-
eter names to distinguish between each other [1]. For example, all port names are in upper
Basic Design Constraints

case letters and internal signal names alone are based on lower case letters. More ex-
amples are that an hierarchy identification character is added to port names and only
parameters names are in upper case letters. In any case, consider naming conventions,
which are easy to understand and unified.

The number of characters in signal names , port names , parameter names , define names
and function names should be between 2 and 40. [3] A tool used at a later stage might
convert a signal name which is too long. Although it is true that a long signal name is
more understandable than a short one, an overly long name makes it unreadable. There-
fore, the basis for signal name should be up to 24 characters in length.

RTqualify cannot judge whether a name is meaningful or not. 1.1.3.[3] checks the number of
characters for each signal name, port name, parameter name define name and function name
separately.

Naming conventions are explained in RMM:5.2.1. RMM recommends using lower case charac-
ter for all names.

1-12
 1.1. Naming Conventions

1.1.4. Naming conventions of include file, parameter and `define (different from VHDL)

[1] Use either ”.h”, ”.vh” or ”.inc” for RTL description and ”.h”, ”.inc”, ”.ht” or ”.tsk”
recommend 2
for test benches as the include file (Verilog only)

Chapter 1
[2] Parameter names should have a different naming convention recommend 3

[3] Do not use parameters with the same name for different modules recommend 3

Basic Design Constraints

[4] Use `define definitions declared in the same module only (Verilog only) recommend 1

[5] Add hierarchy ID characters to parameters, which are used only

reference
within a level of hierarchy

[6] Fixed values should not be connected directly to output ports (recommend 1)
- Fixed values should not be connected to input ports (reference). recommend 1

[7] Parameterize the bit width of ports required for circuits that will be reused recommend 3

[8] Clarify <value> ’b, ’h, ’d, ’o specification for parameters (Verilog only) recommend 1

[9] Specify the bit width if it is greater than 32 bits (Verilog only) mandatory

Example Code

Parameters used in the overall design (include file common.h)

parameter P_MaxDataPacketNum = 11'd1521

parameter P_MinDataPacketNum = 11'd61;
parameter P_Max_streage = 14'd3853;

Parameters used in each layer(include file geomet.h)

parameter P_Geomet_Datalength = 8;
parameter P_Geomet_PxDefalut = 10'd323;

Example 1-5 Naming parameters

Explanation
Whenever possible, put data to be used as parameters into include files thus making it
easy to change parameter values. Distinguish parameters used for the overall design from
parameters used only under particular hierarchies, [3] and place each one into a separate
include file. For Verilog-HDL descriptions, use a relative path name for include files.

Even if there is an include file in the same directory, refer to the next higher level using
”include ../RTL/compara.v”. This should be done to prevent trouble from occurring when
executing an EDA tool in another directory.

You should add the special identification character ”P_” in front of a parameter to distin-
guish it from other signal names [2]. There are two methods to declare a parameter: using
a parameter statement and using `define. `define is regarded as a compile directive and
therefore becomes available inside modules other than the one in which `define is defined.

1-13
 1.1. Naming Conventions

In RTL descriptions, `define on global position and `define in other modules should not be
used. When generating a logic circuit with a logic synthesis tool, each module may be
generated separately. In the case of using `define as described above, it becomes impos-
sible to generate a logic circuit. Of course, it is acceptable to call a file that defines `define
Chapter 1

from an include statement . There are cases when `define may be used outside the module
inadvertently, so beware when using `define . It is advised that these be reviewed with an
RTL check tool.
Basic Design Constraints

It is recommended that parameters which are used in an overall design be defined with a
parameter statement in the include files which are called by each module. To avoid un-
necessary confusion, it is recommended not to use `define as a parameter in overall de-
sign.

It may be preferable to add a hierarchy ID character, as defined in 1.1.2, to parameters

that are used in each level of hierarchy as much as possible so that they are distinguish-
able from other parameters. [5] However, since the identifier ”P_” is added to the top of a
parameter, it may become complicated if another hierarchy ID character is added.

A fixed value should not be connected directly to input/output ports. [6] After applying
synthesis optimization from the upper level hiearchy, ports that are directly connected to
fixed value may become unconnected ports. This situation may cause problems during
logic equivelancy checks. In cases where upper level hiearchy's ports are connected to
fixed values, there should be no problem. However, after applying synthesis optimization,
there might remain some redundant logic. This will increase gate count and should be
considered carefully.

In a parameter, describe ’b, ’h, ’d and ’o clearly when defining any numeric value greater
than 8. In particular, when a value greater than 10 is specified, there is a possibility that
a designer may mistake it for a hexadecimal number. For example, 12 is not ’h12.

Specify bit width in a parameter as much as possible. However, since one parameter value
may be assigned to multiple signals with different bit widths, it is not necessary to indi-
cate it to all.[8] Please note that parameters with no bit width specified have a bit width of
32. Specify the bit width when declaring parameter s greater than 32 bits. [9]

When using constants , use a parameter as much as possible so that check and modifica-
tion may be easily done. However, readability will be decreased if parameterizing all the
constants such as 0,1, numeric value for which all the bits are 1, and clauses in case
statements . In particular, parameterizing all the clauses in a case statement loses bit
image (except for a state machine description) and therefore quality may be decreased. As
for this type of clause, a constant value should be described as is, except when describing
complete parameterization.

It is not always necessary to parameterize all the constants. However, it is better to

parameterize those which are used in many locations and where modification, such as bit
width, is expected.

1-14
 1.1. Naming Conventions

RTqualify checks the following items.

1141 (W1) Extension of include file "<file_name>" not <extension>.
1142a(W3) Not of format specified by parameter_naming_style.

Chapter 1
1143 will be supported in the next version.
1144a(E) Different values are defined by `define in multiple places.
1144b(W1) Character string defined by `define used in another module.
1145 (N) Layer ID character not used in parameter name.

Basic Design Constraints

1146a(N) A [parameter | constant] is used when connecting to an input port in a lower layer.
1146b(W1) [parameter|constant] is directly output to output port.
1147 to be checked by 3151.
1148 (W1) 'd, 'b, 'o, or 'h not specified for a parameter.
1149 (E) Bit width not specified for [constants | parameters] of more than 32 bits.

Note: Item 1.1.4 is a convention only for the Verilog-HDL version.

In the VHDL version, an item similar to this, “1.1.4 Parameter (constant) naming
conventions” is provided.

1-15
 1.1. Naming Conventions

1.1.5. Naming should consider clock systems

[1] Give register output signal names that suggest the clock system or register recommend 3
Chapter 1

[2] Basically, use “CLK” or “CK” for clock signal names, “RST_X” or
recommend 3
“RESET_X” for reset signal names and “EN” for enable signal names.
Add identifiers to the end of these basic names.

[3] Names that suggest the clock reference

Basic Design Constraints

[4] Names that suggest the register reference

Example Code

Example description that suggests the clock

always @(posedge CLK1 or negedge RESET_X) begin
if (!RESET_X)
GT_Preamble_CK1 <= 0;
else if (RE_EtherEnable_CK5)
GT_Preamble_CK1 <= GT_Seripara8bit_CK1;
end

Example description that suggests the register

always @(posedge CLK1 or negedge RESET_X) begin
if (!RESET_X)
GT_Preamble_REG <= 0;
else if (RE_EtherEnable_CK5)
GT_Preamble_REG <= GT_Seripara8bit_REG;
end

Example 1-6 Naming that suggests the clock or the register

Explanation
In order to improve the readability of a description, a signal name based on the clock
system or signal names , which explicitly identify that a signal is a register output signal,
can be given to output signals of a register inference description.

First, decide the basic signal name for the clock signal, reset signal and enable signal.
Then add an identifier to the end of the basic signal name when more than one signals of
the same kind exist.
It is recommended to use basic signal name s of “CLK” or “CK” for a clock signal, “RST_X”
or “RESET_X” for a reset signal and “EN” for an enable signal.
For example, if multiple clocks exist, add one to three characters to the end of “CLK” or
“CK” like “CLK1”, “CLKM” or “CLK_CPU” etc.

Names which suggest a clock system can be given by adding the name of the clock signal
source, to the end of the signal name (ex.”_CK5").

It would be overly verbose to add clock identification to signals for the entire design. How-
ever, knowing which clock each signal is dependent upon is important in systems that

1-16
 1.1. Naming Conventions

employ two-phase or three-phase latch based designs or use asynchronous transfer. A

clock name should be added when designing such circuits.

To clearly distinguish between a signal names of registers (FF, D latch) and combinational

Chapter 1
logic , one option is to add ”_REG” ("_reg", if the signal name is in lower case letters) at the
end of a signal name intended to be a register.

However, in the logic synthesis tool Design Compiler, the instance name of a register is

Basic Design Constraints

”<signal name >_reg” when a gate circuit is generated. If the signal name of a register is
GT_Preamble_REG, as in Example 1-6, the register name of corresponding gate-level cir-
cuit becomes GT_Preamble_REG_reg , which can lead to confusion.

RTqualify checks the following items.

1151a(W3) Clock signal name not added to resister output signal.
(not to be checked by default setting)
1151b(W3) No ID character for a register output signal.
(not to be checked by default setting)
1152a(W3) Clock signal name not of format specified by clock_naming_style.
1152b(W3) Reset signal name not of format specified by reset_naming_style.

General naming conventions are explained in RMM: 5.2.1. RMM describes that "_r" should be
used for "_REG", "_a" for asynchronous signal and "_z" for tri-state signal.

1-17
 1.2. Synchronous design

1.2. Synchronous design

1.2.1. Clock synchronous design
Chapter 1

[1] Designs should use a single clock/single edge as much as possible recommend 1

[2] Do not create a RS latch or FF using primitive cells such as AND, OR mandatory

[3] Do not use feedback in combinational circuits mandatory

Basic Design Constraints

Explanation
Use the synchronous design method in HDL and logic synthesis tools. Using asynchro-
nous clocks makes adding precise design constraints difficult on logic synthesis. Utilize a
single clock with a single edge in your design whenever possible.

Avoid generation of asynchronous clocks inside a circuit

Avoid feedback of combinational circuits

Avoid feedback that spans asynchronous reset

Figure 1-2 Asynchronous circuit and feedback of combinational circuits (avoid these examples)

As designs grow larger, the circuit operating speed is analyzed using static timing analy-
sis tools (Design Compiler, PrimeTime, BuildGates, etc.) instead of logic simulation. In
such situations, analysis becomes difficult if the clock system is complex. [1] In reality,
there are few systems that operate with a single clock and a single edge.
If using multiple clocks, try to minimize the number of clocks.

FF or latches can be created by using primitive cells, but this could be treated by the
timing analysis tool as feedback to a combinational circuit. [2] If combinational circuit
feedback cannot be avoided, use the set_disable_timing setting to avoid the effect of a
feedback loop during timing analysis. [3]

1-18
 1.2. Synchronous design

Circuit designs such as the example in Figure 1-2 above should be avoided, but if your
design requires internally generated clocks, specify create_clock to the output of the FF
that generates the clock.

Chapter 1
Although a looped path that spans over FFs are not a problem, an asynchronous loop that
spans over latches are prohibited. Please refer to "2.4.1. The latch description is clearly
distinguished from the combinational circuit". Moreover, because the loop that spans over
asynchronous reset becomes an asynchronous loop, FF shown in the figure below in Fig-

Basic Design Constraints

ure 1-2 is prohibited.

RTqualify checks the following items.

1211(N) Clock system indication. Judge clock system according to this system list.
1213(E) Asynchronous loop.

Verilint Warning
W408 : Combinational circuit loop is detected
W506 : Description, which may become combinational circuit, is detected

Synchronous design is explained in RMM 3.2.1.

1-19
 1.3. Initial reset

1.3. Initial reset

1.3.1. Use asynchronous reset for initial reset

[1] Using synchronous reset description may cause synthesis to generate

Chapter 1

reference
a circuit that cannot be reset properly.

[2] It is safer to use asynchronous reset for initial reset to a register

- Reset tree synthesis at layout is easy recommend 3
- Values may not be fixed in a gate-level simulation with synchronous reset
Basic Design Constraints

[3] Do not use asynchronous set/reset pins for anything other than initial reset recommend 1

[4] When using synchronous reset circuits, establish a new hierarchy reference
for the register with synchronous reset

[5] Do not use synchronous reset directives for a particular logic synthesis tool recommend 3

[6] Do not have both asynchronous reset and synchronous reset

mandatory
on the same reset line

[7] Do not use a FF with both asynchronous set and asynchronous reset recommend 1

Example Code

(a)
Error example of synchronous reset
RST_X
always @( posedge CLK )
if(RST_X == 1'b0) IN1 Q
Q <= 1'b0;
else if(Q == 1'd1) IN2
Q <= IN1;
else
Q <= IN2;
becomes…
(b)
- With circuit (a), a value is determined
at initial state (Q is unknown) IN2
- When circuit (b) is generated, Q
a value is not determined RST_X
at initial state
IN1

Figure 1-3 Synthesis by synchronous reset description

Explanation
Several different circuits can be generated with the synchronous reset FF inference illus-
trated in Figure 1-3. [1] For example, (a) is a circuit that resets after selecting the input
signal and (b) is a circuit that resets the input signal and then selects the signal.

In logic simulation, the initial FF state is (X) (unknown), but because circuit (a) connects
the reset signal to the gate directly before the FF data input, the data input is defined

1-20
 1.3. Initial reset

since an AND operation is performed with the reset signal even if the FF’s output is ’X’.
In circuit (b), however, the output signal from the FF that is input to the selector is ’X’ and
since the EXOR gate output becomes ’X’ regardless of the input signal value, the FF data
input is always ’X’. As a result, the value for the FF is not defined by the synchronous

Chapter 1
reset signal.

This will not cause any problems as long as a circuit (a) is always synthesized from the
synchronous reset description, but there is no guarantee that such a circuit is always

Basic Design Constraints

generated. [1] Therefore, it is safer to use asynchronous resets in the initial reset. [2]

Example 1-7 shows an example in which a synchronous reset FF description has been
changed into an asynchronous reset FF description. The always construct is activated by
the rising edge clock and the active low reset signal.

Asynchronous description example of initial reset

always @(posedge CLK or negedge RST_X)
if (!RST_X)
Q <= 1'b0;
else
Q <= DATA;

Example 1-7 Asynchronous description example of initial reset (mandatory)

In addition to the above mentioned reason, asynchronous reset is realized during the lay-
out process (Refer to section "1.4.2. Use clock tree synthesis for clock balancing"). Since
some systems inherently only accept asynchronous reset, it is more realistic to specify
asynchronous reset (Refer to section "1.3.3. Be careful about external noise on an initial
reset signal")

Initial reset should be input for asynchronous reset, but other signals must not be input to
the asynchronous set and reset pins[3] because it is difficult to analyze the paths which the
asynchronous set and reset pass through during the timing analysis. In other words,
when using logic synthesis tools or static timing tools to perform an analysis, the timing
path is cut off without taking into account the timing from the register B reset input to
the Q output of register B, as shown in Figure 1-4.
Timing problems like this may occur if sets/resets other than initial reset are used, so it is
recommended that asynchronous set and reset not be used for purposes other than initial
reset.

1-21
 1.3. Initial reset

B C
Chapter 1

Timing analysis
is cutoff
A
Basic Design Constraints

A B C

Figure 1-4 Timing analysis of asynchronous reset path

For a circuit structure like the one in Figure 1-4, a logic synthesis tool (e.g. Design Com-
piler) will not analyze the timing of the path arriving at the B asynchronous reset from
the output of A, unless it is manually specified. Therefore, it is possible that no error will
be reported even if the path has a delay of 1000 ns, and this will not be evident until after
the layout process.

Any resets other than initial resets should be synchronous resets, and should be distin-
guished from asynchronous resets. In the example in Fig. 1-3, the value of the FF be-
comes unknown state X. In this situation, even if the synchronous reset signal is TRUE,
there are cases in which the logic synthesis tool will generate a circuit that may not
assure initialization. If a reset signal is fed by more than two lines, guaranteeing a known
reset state is required. This can be achieved by creating a separate module containing a
FF with an AND gate as seen in Figure 1-5. By creating this extra hierarchical module,
the RTL description in Figure 1-3 will not generate circuit (b) in the same example.

However, in logic synthesis tools, there is a command that is used to flatten hierarchy. If a circuit
hierarchy containing the example in Figure 1-5 is flattened, the resulting circuit's output value
may not be stable. Care must be exercised not to remove the hierarchical structure in this type of
scenario. If the block is ungrouped by this command, values may not be fixed. Take care
not to specify ungroup to this type of block.

1-22
 1.3. Initial reset

Example of synchronous reset circuit using hierarchy

module DFFsyncrst(D,RST_X,CLK,Q,Q_X);
input RST_X,CLK;
output Q,Q_X;

Chapter 1
reg Q;
assign Q_X = ~Q;
always @( posedge CLK ) RST_X
if( RST_X == 1' d0 )
IN1 Q
Q <= 1 'b0;

Basic Design Constraints

else IN2
Q <= D;
endmodule

.. grouped together
DFFsynrst U1(.D(ASIG),.RST_X(RST_X),
.CLK(CLK),.Q(Q));
always @( Q or IN1 or IN2 )
if(Q==1'b1)
ASIG = IN1;
else
ASIG = IN2;
..

Figure 1-5 Synthesis of synchronous reset circuit using hierarchy

If you add the Design Compiler specific directive ”//synopsys sync_set_reset” you could
assure a value with synchronous reset without using a hierarchical FF. Therefore, if you
are not using an additional hierarchy, this directive should be added. However, as this is
only effective with Design Compiler, it will not be possible to use this RTL description if
other logic synthesis tools are used in the future. [5] Also, because this Synopsys directive
is realized in comment lines, syntax cannot be checked and it is recognized as a simple
comment statement even if only a character is wrong. This method cannot guarantee that
a tool always generates a circuit as illustrated above. To ensure that synchronous reset
defines value at gate simulation, there is no other way but the use of hierarchy method as
above.

If one reset line has both synchronous reset and asynchronous reset, synthesis may not be
performed properly. [6] The asynchronous reset line sometimes forms a tree-structure dur-
ing the layout process (Refer to "1.4.2. Use clock tree synthesis for clock balancing"). To
avoid accidentally inserting a buffer or logical operand during logic synthesis with Design
Compiler, set_ideal_net (The specified net is excluded from the limitation of the logic syn-
thesis, the timing analysis, and the design rule) may be put on this reset line. Then, if
this reset line is also input to a FF's synchronous input, that part will not be synthesized
and synthesis will fail as a result. In addition to this, having both asynchronous reset and
synchronous reset may cause other problems during logic synthesis and layout, and they
should not be mixed.

If you do not use any asynchronous reset other than an initial reset, you will only need
either asynchronous reset FF or asynchronous set FF.
Do not use FF with both asynchronous set and reset. [7]

1-23
 1.3. Initial reset

always @(posedge CLK or negedge RST_X or negedge SET_X)

if(!SET_X)
QOUT <= #DLY 1'b1;
Chapter 1

else if(!RST_X)
QOUT <= #DLY 1'b0;
else
QOUT <= #DLY DIN;
Basic Design Constraints

In this description, when RST_X is 0 and SET_X is 0, since QOUT is prioritized on set
signal, output becomes 1. If asynchronous signal SET_X changes to 1 in this case, the
always construct will not be activated until the next clock edge; therefore, QOUT remains
as 1. However, in the behavior of a generated gate-level circuit, QOUT becomes 0. This
will result in RTL and gate level simulations not matching. As seen in this example,
cases in which both RST_X and SET_X are active, or in which a FF has a prioritized set/
reset, the simulation results of RTL and gate-level will not match.

RTqualify checks items except for 1.3.1.[4]. Tools cannot recognize 1.3.1.[4].
1312(W3) Neither an asynchronous set nor a reset for a FF in description.
1.3.1.[3] Checked by 1321 and 1322.
1315(W1) //synopsys sync_set_reset used in a synchronous reset.
1316(W2) An asynchronous reset or an asynchronous set is connected to a FF data
input path.
1317(W1) A FF is used that has both an asynchronous reset and an asynchronous set.

Verilint Warning
W396 : No asynchronous reset for flip-flop.
W392 : The polarity of asynchronous rest is wrong.
W395 : More than one asynchronous reset is detected.

Initial reset is explained in RMM3.2.4.

1-24
 1.3. Initial reset

1.3.2. Reset line hazards

[1] Do not insert logical operands in a reset line at the local module.
recommend 1
In addition, circuits that supply reset lines should be separated
into an individual module.

Chapter 1
- Logic order may be replaced by synthesis
- Hazards cannot be prevented in the RTL description

[2] Do not insert signals other than initial reset to FF asynchronous reset pins recommend 1

Basic Design Constraints

[3] Optimize by keeping in mind the timing of the signal that outputs reference
the reset line

Example Code

Signal with hazard Q

reg[4:0] count; ctl_X
wire REN_X,EN_X,count32_x,ctl_x;
count
assign count32_x = ~(& count) | ctl_x;
assign REN_X = EN_X | count32_x;
EN_X
always @( posedge CLK or negedge REN_X ) Signal without hazard
if(REN_X == 1'b0) becomes...
Q <= 1'b0;
else Q
Q <= D; EN_X

count

ctl_X
Signal with hazard

Figure 1-6 Example of hazard on the reset line

When a combinational circuit generates an asynchronous reset signal, there are situations in
which the enable signal would be separated from the FF as the result of optimization, and
signals with a hazard may drive the reset input. [3] As illustrated in the figure above, this
occurs even if enable logic is inserted before the FF reset signal in an RTL description to avoid
hazards. In this case, depending on the timing of the combinational circuit input signal, a
hazard could develop in the reset circuit and the FF could be reset with unexpected timing.

It would be difficult to discover a problem such as this because hazards are prevented in the
RTL description. As a rule, it is therefore forbidden to directly input signals other than the
initial reset signal to the asynchronous reset pins. [2] In cases in which this type of circuit is
created, use an additional level of hierarchy to group this logic. This method is similar to the
handling of synchronous resets. Refer to "1.3.1. Use asynchronous reset for initial reset" for
further information.

As explained in “1.3.3. Be careful about external noise on an initial reset signal”, an asynchro-
nous reset signal may be supplied as synchronized. Also, logic circuits may be inserted so that
a system reset can be selected.When logic is needed on a reset line, combine that reset line
logic together in the top level ( illustrated in “1.4.1. Creating modules for clock generation
circuits”) as much as possible and directly input the same signal input to all FFs.[1]

1-25
 1.3. Initial reset

RTqualify checks the following items.

1321(W1) Logic on an asynchronous set/reset line.
1322(W3) Output of an internal FF used on an asynchronous set/reset line.
Chapter 1
Basic Design Constraints

1-26
 1.3. Initial reset

1.3.3. Be careful about external noise on an initial reset signal

[1] There is danger of malfunction unless attention is paid to reset lines reference
on the circuit board

Chapter 1
[2] An initial reset may have to be synchronized or else a noise elimination
recommend 3
circuit may be needed

[3] In some systems, an initial reset signal is asserted before the clock reference

Basic Design Constraints

- The asynchronous method is preferred in this case, but a noise
elimination circuit should be added

Explanation
As explained in “1.3.1 Use asynchronous reset for initial reset” an asynchronous reset is
preferred for the initial reset. But operation tends to become unstable when slowly sloped
waveforms or waveforms with a lot of noise are directly input from outside the LSI. Also,
if the asynchronous mode is used for the reset, it may violate Setup and Hold times, be-
cause the rise point of the clock and the rise or fall of the asynchronous reset signal may
occur at the same time. In this situation it is recommended to synchronize before distrib-
ute the waveforms as illustrated below.

If there is a significant concern about the influence of noise, three or five FF stages should
be used, and reset should be only executed when all FF outputs are in the RESET state.

Synchronization of the reset lines Additional noise prevention

Latch by FF

Latch by FF
RST_X
RST_X

Schmitt
trigger I/O

Figure 1-7 Synchronization of the initial reset signal

In some systems, the initial reset signal is asserted before the clock. Some portable con-
sumer electronics automatically turn on the initial reset at the time the power is turned
on. By loading the resistor and capacitor on the reset pin, the voltage rise of the reset line,
as shown in Figure 1-8, slows down in comparison to the voltage rise of power.
However, a clock signal generated by a PLL also will be slower in comparison to the volt-
age rise of power. In most cases the rise of the clock signal becomes even slower than the
reset input. Thus, if the reset signal is synchronized by a FF, as shown in Figure 1-7, the
system would have no reset.

Synchronization is not possible in this type of system, and the reset signal from outside
the LSI, which should be supplied to a FF asynchronous reset input, is input directly.

1-27
 1.3. Initial reset
In this case, asynchronous reset signals are preferred, but it would be better to add some
noise elimination circuitry.

Voltage
Chapter 1

Application Power
Clock
of power Reset
Time
Basic Design Constraints

Figure 1-8 External power and initial reset input

As countermeasures, the use of a Schmitt trigger I/O, a VDD and GND for the I/O pin next
to the reset pin to reduce noise (Figure 1-9), or the addition of a DLY element to prevent
hazards as shown in Figure 1-10, may be applied.

GND

RST_X

VDD

I/O pad

Figure 1-9 Use power pins beside reset pin to eliminate noise

In Figure 1-10, when the value at point A becomes '0', after some delay, the value at point
B becomes '0'. If A then becomes '1' during the time span of the DLY cell (delay element),
the OR output will remain as '1'. Therefore, hazards can be prevented to a certain extent.
Yet, in ASIC design, a DLY cell (or BUFFER) and OR gates are assigned in distant posi-
tions and may end up with values different from the assumed delay value. Take extra care
when inserting such a circuit.

B
DLY cell
RST_X A

Figure 1-10 Noise prevention for reset line by DLY element

In addition, one countermeasure against asynchronous reset noise and malfunction due to
Setup/Hold is to first create stable clock stop states and then input an asynchronous reset
between them.

However, no counter measure is perfect, so please give careful consideration to how the
reset line should be laid out on the board. [1]

1-28
 1.3. Initial reset

RTqualify outputs the following messages at top level mode (--top).

1332(W3) A signal from an external port is input directly into an asynchronous
set/reset line.

Chapter 1
Basic Design Constraints

1-29
 1.4. Clocks

1.4. Clocks
1.4.1. Creating modules for clock generation circuits
Chapter 1

[1] Create modules for circuits that supply clocks separately

recommend 1
- Place gated clocks and multiplication clocks together in a single level of
hierarchy at the top level

[2] Do not perform logic synthesis on clocks reference

Basic Design Constraints

Explanation
Combine circuits such as gated clocks and multiplication clocks that supply clocks to the
internal sub-circuits together in the same level as much as possible.

Clock generation module

Figure 1-11 Creating a clock generation module

Creating a clock generation module and supplying clocks from a single clock generation
module offer the following advantages:

* More manageable clock distribution

Redundant circuits may be generated when the necessary clocks are created at each
level of hierarchy. By centrally controlling clock generation, it is no longer necessary
to consider clock generation at each level of hierarchy. Also, it becomes easier to use
the clock tree optimization function during layout.

* Easily applied clock constraints for each level of hierarchy

Applying clock constraints to internal clocks generated from within a circuit is diffi-
cult. Defining clock constraints is facilitated by supplying clocks from outside a mod-
ule only.

* Easily implemented clock controls during test design

With scan design, it is necessary to enable controlling clock signals from external
pins during scan operation. Scan design is facilitated by placing clocks in separate
modules.

1-30
 1.4. Clocks

The clock line is created with the CTS tool as explained in "1.4.2. Use clock tree synthesis
for clock balancing". Buffers should not be inserted to the clock line during logic synthesis
process. Therefore, the clock line is should not be excluded from the logic synthesis.[2]

Chapter 1
Similarly, reset lines should be made into separate hierarchical structures as in clock
lines. By creating modules for reset generation, it will become easier to apply synthesis
constraints.

Basic Design Constraints

In order to exclude clock and reset lines from the logic synthesis process, it is necessary to
set commands to them. Please refer to "5.2.2.5. set_ideal_net" for more details.

RTqualify checks the following items.

During top level mode (-top) and situation other than in clock generation modules,
1411a(W1) There is a gated clock.
1411b(W1) There is an inverted clock.

Creating clock modules is explained in RMM:5.4.5.

1-31
 1.4. Clocks

1.4.2. Use clock tree synthesis for clock balancing

[1] For clock lines, do not use primitive cells other than dummy buffers reference
on a clock tree
Chapter 1

[2] Clocks should be balanced in accordance with the number of cells to be reference
connected to each clock tree
Basic Design Constraints

Explanation

Adjust skew by
shifting position

Figure 1-12 H-type clock tree optimization

In LSI design, the Clock Tree Synthesis (CTS) tool is used to synthesize the clock after the
placement of each FF in the layout. Figure 1-12 provides an overview of the CTS. The
clock lines extend from the center in an H-shaped tree structure. Wires from each termi-
nal buffer are also arranged in H-shaped structures, supplying the clock to the local FF
from the final terminal buffer.

In these clock lines, the arrival time will vary depending on the number of FFs ultimately
supplied, and the length of the interconnect lines. The CTS tool adjusts at this point by
shifting the position of any given buffer forward to delay the arrival time.

To use the CTS, add a CTS dummy buffer to the circuit. The CTS dummy buffer is in-
serted either into the clock generator module during the RTL description stage, or after
the gate-level net list has been generated. Any buffers or delay cells in the clock lines
aside from CTS dummy buffers are not recommended. In particular, do not use buffers,
etc., in signal lines after the CTS dummy buffer.

The CTS tool generates the clock tree after the CTS dummy buffer, and adjusts the clock
signal arrival time. However, it does not adjust the arrival time between different clocks.
To adjust the arrival time between different clocks, adjust by inserting delay cells (such as
buffers) in the stage prior to CTS. If there are too many clock lines, this adjustment
process becomes laborious.

1-32
 1.4. Clocks

CTS tool capabilities have been enhanced recently, making it possible to adjust delay val-
ues even when gated clocks are present in the clock lines. Even if gated clocks are present,
the placement of a CTS dummy buffer in the stage prior to the gated clock will make clock
adjustments easier during layout. However, when this approach is used, a single clock

Chapter 1
line will be encumbered by a large capacitance, reducing the degree to which power con-
sumption in the clock line can be reduced. (See "3.4.Low Power-Consumption Design".)
Although gated clocks are used to reduce power consumption, they are unable to produce
as much of an effect as anticipated. Because of this, there is also the approach of fabricat-

Basic Design Constraints

ing a clock tree for each gated clock lines. Of course, asynchronous clocks having fre-
quency dividers or differing periods will use different lines.

During design of the LSI, consideration should be given to the number of clock lines.
Additionally, the designer should be aware of the approximate number of FFs connected to
each clock line for load balancing these clock lines. [2]

It may be necessary to fine-tune the timing of input signals to the LSI from the outside or
output signals by the LSI to the outside. These interfaces include: interfaces with the
CPU bus, interfaces with the PCI bus, and the interface with external memory. For LSI
external interface parts that require fine-tuning of the timing, it is recommended that the
clock lines be divided in advance.

As is introduced in "3.3.Design for Test(DFT)", scan registers are inserted into the LSI
using the scan register insertion tool. These scan registers generate structure scan chains
for each clock line. As circuits become larger and individual clock lines are connected to
more FFs, scan paths may become too long, and too many test vectors are output from the
automatic test pattern generator (ATPG) tool. Because of this, the designer may have to
divide the clock lines. When it comes to how the clock lines should be divided, the answer
is dependent on how the circuit is divided into blocks in the layout, and thus the clock
lines often cannot be divided in the RTL design stage. However, it is recommended that
the problem of power consumption (discussed above) and scan line insertion be considered
to some degree when working on the clock lines.

Additionally, it is not possible to insert scan registers for each clock line if the number of
clock lines is too large. In this situation, it may be necessary to switch the clock lines into
a single clock line during the test mode. Moreover, because there is also the issue of
detecting interferences between different clock lines, ("3.3.7. Handling of Different Clocks")
the connecting logic of signal lines between the separate clock lines should also be consid-
ered.

Currently, not only clock lines but also resets and the scanning selections are created with
CTS tools. Therefore, dummy buffers for CTS should also be added in reset and scanning
select lines.

RTqualify checks the following item.

1421(N) There is a buffer cell in a clock line.
It is up to the designer to decide whether this cell is the buffer for CTS.

1-33
 1.4. Clocks

1.4.3. Gated clocks should be used with special care

[1] Avoid inverting logic on the same clock line. Also avoid using gated clocks recommend 2
and using FFs with different edges.
Chapter 1

[2] Do not input a FF output pin to other FF clock pins recommend 1

[3] Using gated clocks is an effective method for achieving low power consumption reference
Basic Design Constraints

[4] Do not supply clock signals to pins other than FF clock input pins recommend 1
(such as D input)

[5] Clock signals should not be connected to black boxes, bi-directional pins
recommend 3
or reset lines

[6] Do not use FFs with inverted edges recommend 1

Explanation
As explained in “1.4.2. Use clock tree synthesis for clock balancing”, the recent CTS tools
(Clock Tree Synthesis) are now able to take clock tree balancing into consideration even
when there are gated clocks or inverted clocks. However, as described above, great care
must be taken when designing the clock lines. [1] As a result, gated clocks or inverted
clocks should be gathered in the clock generator module in the top level, and clocks should
not be generated at the local levels. If you wish to consider using gated clocks at a very
detailed level in order to reduce power consumption that little bit more, use the “genera-
tion of gated clock circuits using EDA tools” explained in “3.4.1. Low Power-Consumption
Design Using Gated Clock”. [3]

The connection of the output of one FF to the clock pin of another FF should also be limited
to the clock generator module located in the topmost level. [2] When the output of an FF
becomes another clock line, the CTS tool cannot take the clock line balancing into consid-
eration.

Do not connect clock signals to anything except for the clock pins of FFs. [4] If the clock
line passes through a logical gate to arrive at the D input of the FF, the logic synthesis
tool cannot perform optimization for that part. Additionally, such a path is extremely
dangerous because the timing cannot be analyzed correctly. Use caution when fabricating
a circuit wherein an external clock circuit is latched by a clock signal within the LSI
(used, for example, finely dividing clock signals ).

Clocks input from outside of the LSI may be connected to clock generator circuits (PLLs
and DLLs). If there is no library provided for these clock generator circuits (PLLs or
DLLs) "black boxes" errors will result when performing simulations and logic synthesis -
make sure these libraries are present.

Also be sure to avoid outputting clocks to bi-directional terminals. Bi-directional termi-

nals must be controlled as either inputs or as outputs during a simulation. Test tools
including the BIST insertion tool cannot determine the direction of these bi-directional
terminals and which may lead to problems. [5]

1-34
 1.4. Clocks

Depending on the ASIC library used, there may be two types of FFs: those that work on a
positive clock edge and those that work on a negative clock edge. When the two types of
FFs are mixed in a circuit, scan register insertion becomes problematic. It is best not to
use FFs that work on an inverted clock. [6] However, it is not a problem if latches that

Chapter 1
work on inverted logic are used only in a single stage (See “1.5.3.Guaranteeing the setup/
hold and margin for synchronous RAM”, “2.4.Latch inference” and “3.3.7.Handling of Dif-
ferent Clocks”).

Basic Design Constraints

RTqualify checks the following items.
1431a(W3) There is a gated clock.
1431b(W3) There is a inverted clock.
1431c(W2) There is a description of a falling edge in the clock line "<clock_name>".
1432a(W1) Output of FF connected to a clock.
1435 (W2) A clock signal is used except for a FF clock.

Gated clocks are explained in RMM:5.4.3 and 5.4.4.

1-35
 1.4. Clocks

1.4.4. Multiple clock systems

[1] Whenever possible, create separate hierarchical blocks for each clock line. reference
Chapter 1

[2] When inputting multiple clocks in the same block, provide an integral
reference
multiple period as a clock constraint

Explanation
Basic Design Constraints

Define clock generation circuits in different levels when clocks consist of two or more
systems. See “1.4.1. Creating modules for clock generation circuits” for the benefits of
placing clocks in different levels.

When creating sub-blocks, create a sub-block for each clock system as often as possible [1]
to avoid a racing problem (see “2.3.1.Unify the description style of FF inferences”) during
simulation and to facilitate clock synthesis during layout. Even if creating a sub-block for
each clock is difficult, avoid inputting multiple clocks in the same block whenever possible
(Figure 3-13).

Figure 1-13 Creating a sub-block for each clock

For external data retrieval such as CPU interfaces, consider creating synchronization
circuits. If external data is stable and its operating frequency is lower than the internal
clock, all signals should be synchronized by the internal clock.

Figure 1.14 shows an example in which a typical CPU interface is created by full synchro-
nization. In this case, the rise of the WR X signal is detected and the values for ADR and
DATA at that time are retrieved. This type of synchronization circuit can be applied only
when CPU interface speed is one half or less than that of the internal clock. As the falling
edge is used to write instead of the rising edge of the WR_X signal, it is valid only when
CPU interface speed does not change.

The CPU interface may take the WR_X signal as a clock signal and retrieve ADR and
DATA as shown in the figure below. In this case, pay attention to metastable measures.
In such CPU interfaces, it is rare to have circuits operate by signal WR_X clock. Further,
if FFs operating with an internal clock system are contained in separate blocks, the cir-
cuit becomes difficult to understand. It is not recommended that blocks be divided for
each clock in a circuit such as this.

1-36
 1.4. Clocks

Detect WR_X fall

CS_X
CS_X
WR_X
To
ADR WR_X
internal

Chapter 1
DATA ADR register

DATA
Inside ASIC and All are
Asynchronous CPUIF Internal clock
Metastable countermeasure

Basic Design Constraints

Asynchronous interface should When internal CLK speed is 2X+ of the CPUIF
be stopped where it enters
Metastable countermeasure Detect WR_X rise

CS_X
When CPU bus is directly supplied
To
WR_X internal
- Timing management register
becomes critical ADR

-Metastable countermeasure at DATA

each register becomes difficult Internal
clock

When internal CLK speed is less than 2X of the CPUIF

Figure 1-14 Creating a CPU interface circuit

When synthesizing circuits that input multiple clocks to the same block, provide a mul-
tiple cycle relationship as much as possible.[2] In the case of clocks that have a 12ns and a
6ns cycle, the logic synthesis tool optimizes with the basic cycle set to 12ns, which is the
least common multiple. The basic cycle is 60ns for clocks with cycles of 12ns and 15ns,
and is 84ns for clocks with cycles of 12ns and 14ns. As the least common multiple in-
creases, optimization and timing analysis takes more time to complete. (See “5.4.4 Mul-
tiple clock optimization” for more information.)

In cases when the actual clock cycle yields a rather large LCM (lowest common multiple)
cycle, it can be adjusted by modifying circuit partitioning and hierarchy. Or, consider
adjusting the clock cycle to yield a smaller LCM cycle during logic synthesis runs.

RTqualify checks the following item.

1442 (N) Multiple clock signals are input into a single module.

Similar topic is explained in RMM 5.4.5.

1-37
 1.5. Asynchronous circuits

1.5. Handling of asynchronous circuits

1.5.1. Consider metastable issues in signals between asynchronous clocks
Chapter 1

[1] To avoid metastable conditions, do not locate logic between mandatory

asynchronous clocks

[2] To avoid metastable conditions, do not locate logic between FF recommend 1

for data retrieval and the next FF
Basic Design Constraints

[3] Do not have a feedback loop at the first-stage FF after transfers mandatory
between asynchronous clocks

[4] Metastable countermeasures should be taken for input from outside

recommend 2
LSIs which are susceptible to noise

[5] To avoid erroneous input data, latch the clock signals and use them reference
as enable signals

Explanation
There is a difficult problem termed “metastable” when transmitting data between asyn-
chronous clocks. In order to solve metastable problems, one must first understand the
operating principles of flip-flops (FFs).

* Operating Principles of FFs

FFs have specified setup times and hold times. In synchronous design, the design
calls for the value of the input signal to remain unchanged for a specific period of time
before and after the rising edge of the clock (termed the “setup time” and the “hold
time” , see Figure 1-15). However, in asynchronous transmission, there is no guar-
antee that these specifications will be fulfilled. A portion of the data will violate the
specifications for setup time and hold time. The metastable problem may occur when
the setup time or hold time specifications are violated.

Figure 1-16 shows the circuit structure of a MOS LSI FF. (1) and (3) in the butterfly
shape are MOS switches. With the MOS switch as its entrance, the structure then
has an inverter loop in its next stage. This loop, in its steady state, either has a ’1’ on
the left side and a ’0’ on the right side, or conversely, is stable with a ’0’ on the left
side and a ’1’ on the right side.

MOS switch and CLK open/close Q

Hold time
Setup time according to Low or High condition

CLK (1) (3)

D
D

CLK (2) CLK (4)

For FF, D value should not change DFF internal circuit

during setup and hold time

Figure 1-15 Setup/Hold time Figure 1-16 DFF Internal circuit

1-38
 1.5. Asynchronous circuits

Let us assume that the left side in the left-hand loop (2) is stabilized at ’0’ and the
right side is stabilized at ’1’. Given this, let us assume that the switch at (1) is
opened. In actuality, over the interval where the CLK signal is low, the left-hand
switch is open. The inverter in the loop is only capable of driving a very low current.

Chapter 1
When a ’1’ signal arrives at the D input, the value that is looped by the inverter is
simply inverted.

Next let us consider what happens when the CLK signal transitions from low to high

Basic Design Constraints

(i.e., at the rising edge) in Figure 1-17. At this time, the left-hand switch (1) is closed
and the right-hand switch (3) is opened. The left-hand loop (2) maintains the value
that it had immediately before the switch was closed, and that value is copied to the
right-hand loop (4). Because of this, the output of the FF will vary according to the
value of the D input as it existed immediately before the rising edge of the CLK sig-
nal.

Conversely, next let us consider what happens when the CLK signal goes from high to
low (i.e. at the falling edge). At this time, the right-hand switch (3) closes and contin-
ues to maintain its previous value. Consequently, the output from the FF does not
change. The left-hand switch (1) opens, and, in order to prepare for the next rising
edge of the CLK signal, the D input value is continuously copied into the left-hand
loop (2).

In an actual LSI, the FFs function as described above. Cells termed “latches”(or “D
latches”) do not have the right-hand loop of the FF structure. Consequently, latches
require less area than FFs.

Q Q

(1) (3) (1) (3)

D D

CLK (2) CLK (4) CLK (2) CLK (4)

When CLK
When CLK is Low
is High

CLK CLK

Figure 1-17 Operation of DFF

* The Metastable State

If in this structure the value of the D input changes from ’0’ to ’1’ immediately prior
to the CLK signal changing from low to high (the rising edge), then the left-hand
MOS switch (1) closes as the D input is changing to ’1’ and thus the ’1’ value is sent to
the left-hand loop (2) for only an instant. If the period of time over which this instan-
taneous ’1’ is present is shorter than the delay time of the loop (2), then the loop (2)
will begin to oscillate. The oscillation of (2) is propagated directly to the right-hand
loop (4), and the oscillating value is output from the FF. (Figure 1-18).

1-39
 1.5. Asynchronous circuits

CLK

D
Chapter 1

Q
Basic Design Constraints

When D is entered at CLK rising, oscillation for

a certain period (metastable condition) occurs
Figure 1-18 Metastable

This oscillating state is propagated to the logic circuits, and thus the logic circuit
may not function properly. This is the metastable problem.
In the design of large logic circuits, it is not possible to perform adequate investiga-
tions for all of the circuits. When the metastable problem is found in circuits that
have already been fabricated, it is difficult to trace back to the causes, presenting a
major impediment to circuit debugging. There is a need for a simple, easily under-
standable approach to the metastable problem.

* Approaches to the Metastable Problem [1] [2]

Figure 1-19 (a) shows an approach to solving the metastable problem. Not only are
FFs placed between the asynchronous clocks CLK1 and CLK2, but after transmission
to CLK2, one more FF is placed, rather than placing logic between the two FFs.
The oscillation from the metastable state does not continue perpetually. The delay
times of the inverters in the FF loops have some variability, so the unstable oscilla-
tions converge to either a ’1’ or a ’0’ constant value. Consequently, as long as there is
convergence in the metastable state by the rising edge of the next CLK, there will be
no influence on the circuitry at the right-hand side of FF or beyond.

There is no precise data on the time required for the metastable state to reach conver-
gence. Because it is difficult for LSI manufacturers to measure this time period, the
times are not publicly disclosed. As a result, no specific times can be provided; how-
ever, these times are estimated to be about 10ns for a 0.18um design rule, and 12ns
for a 0.25um design rule. If the operating frequency at the 0.18um rule is more than
100 MHz, then the delay time that is allowable between FFs is less than 10ns and,
from the perspective of safety, another stage of FFs may be required.

In logic circuits wherein the operating speed is high, the latter stages of the FF ac-
cepts the data without the oscillations from the previous stage of the FF converging.
While one may think that if this is repeated, then the oscillation will not converge
regardless of the number of stages of FF that are used, this is not the case. The
metastable state is a probabilistic phenomenon. When the oscillation from a previous
stage arrives at the FF of the later stage, even if we assume that the oscillation does
not converge, the probability that the lower-stage FF will oscillate is low. Even if
there is no convergence, the amount of oscillation will decline. Additionally, it does
not always take the same amount of time for an oscillation to converge. While most
oscillations do converge, when there is no convergence, the probability that the oscil-

1-40
 1.5. Asynchronous circuits

lation will propagate is extremely low. Consequently, if several stages of FFs are
added, the probability of oscillation in the output of the FFs becomes asymptotically
close to ’0’, so there is no problem in actual application. Regardless of how high the
operating frequency, if some number of FF levels is used, then the oscillation will

Chapter 1
guranteed to converge.

(a) Do not place logic[1]

Basic Design Constraints

CLK1
CLK2

(b) Simple logic only

Do not place logic[2] Do not use feedback[2]

CLK1
CLK2

Figure 1-19 Metastable countermeasure

* Do Not Have a Feedback Loop in the First-Stage FF After Asynchronous Transfer [3]
If, conversely, the CLK1 and CLK2 operating frequencies are not high, then there is
no problem if there is some degree of logic before the next-stage FF, such as shown in
Figure 1-19 (b). However, even when this is the case, there will be problems when
there is feedback to the FF in order to latch data. Depending on the internal feedback
circuitry of a FF, the metastable state being placed on input might destroy the latched
value. As a result, the circuit will malfunction. Because of this, even if the place-
ment of some amount of logic is unavoidable, be absolutely sure not to have feedback.

It becomes difficult to confirm whether or not a circuit is safe when a logic circuit is
inserted after asynchronous transfer. Even if the designer has assembled the circuit
while paying careful attention to the metastable problem, if understanding the circuit
by other designers is difficult, then the result will be much extra work and expense.
The metastable problem is extremely difficult, and the checks are difficult as well. In
order to eliminate this problem, it is best to be thoroughly entrenched in the habit of
not placing logic prior to the next-level FF, even when the operating frequency is low.

* Metastable Countermeasures in Outside Inputs of Noise Sensitive LSIs [4]

The metastable countermeasures must be taken not just when data is exchanged be-
tween asynchronous clocks, but also when signals are input into the LSI from the
outside. Inputs from elements that turn on and off asynchronously (such as switches)
and signals that are supplied from locations that are physically distant on the circuit
board are sensitive to noise, and this noise may cause a metastable state, resulting in
malfunctions. For this type of input signal, it is necessary to handle the metastable
state in the same way as it was handled between asynchronous clocks. It is becoming
more common to have power supply voltages of 3.3V or 2.5V even on circuit boards,

1-41
 1.5. Asynchronous circuits
and recently circuit boards operating at about 1.9V have begun to appear. If the
power supply voltage is low, then the lower the voltage, the more sensitive the device
is to noise. Moreover, the finer feature the design rule for the LSI, the faster the I/O
operating speed will be, making the LSI extremely sensitive to noise.
Chapter 1

* Sending Data Between Asynchronous Clocks [5]

Data transmission that takes only the metastable problem into account can do noth-
ing but simply transmit and enable signals asynchronously. Considerable ingenuity
Basic Design Constraints

is required in cases such as when bus values are transmitted. In Figure 1-20, the
data is latched at CLK1, and this signal is passed to CLK2 using asynchronous trans-
mission. In such a case, if the rising edges of CLK1 and CLK2 are close together and
if the rising edge of CLK1 is applied during the setup time for CLK2, then the problem
will not be one of a metastable state, but rather one in which the value will not be
read correctly.

Because the data signal uses a bus (8 bits wide), the individual signals will arrive at
minutely different times. When these signals are latched, some bits might accept the
value after the value has changed, while some bits might accept the value before the
value has changed. The result is the danger that, if, for example, the value ”36”
should be received, a totally different value may be read in.

DATA 36 FE 36 7F
CLK1(16.23MHz)
CLK2(34.6MHz)
Data cannot be read properly if the CLK2 rise
and CLK1 rise are close to each other

Figure 1-20 Unreadable data between asynchronous clocks

One method by which to safely read data from a bus of some width is the method
where CLK1 is latched by CLK2. As is shown in Figure 1-21, the select signal is the
one in which CLK1 is latched by CLK2. When this is done, if the CLK2 clock period
is less than one third of the CLK1 clock period, then it is possible to receive the data
signal in a safe place without being constrained by setup/hold time violations. How-
ever, at the point in time in which CLK1 is latched by CLK2, there is the potential for
the metastable problem to occur, and thus it is necessary to insert an additional FF
(Figure 1-22, CLK1EN2) and shift the latched CLK1 by one CLK2 cycle. This method
does not substantially increase the size of the circuit, and the circuit can be created
easily; it is really quite simple. See “1.5.2. Use memory in transfers between asyn-
chronous same-period clocks”.

1-42
 1.5. Asynchronous circuits

DATA_CLK1
DATA Q

Chapter 1
Do not place logic
CLK1

CLK1EN CLK1EN2

Basic Design Constraints

CLK2

Figure 1-21 Simple data transfer between asynchronous clocks

DATA_CLK1 36 FF 36 7F
CLK1(16.23MHz)
CLK2(34.6MHz)
CLK1EN
CLK1EN2

Q 36 FF 36 7F

Figure 1-22 Timing diagram

1-43
 1.5. Asynchronous circuits

1.5.2. Use memory in transfers between asynchronous same-period clocks

[1] Use FIFO for transfers between asynchronous clocks with

reference
the same clock period (Clocks have the same period)
Chapter 1

[2] Use frame memory for transfers in asynchronous clock or clocks reference
with different period.

Explanation
Basic Design Constraints

Use FIFOs for data transfers between asynchronous clocks with the same clock period.
Data are input to the FIFO according to the address of the input side free run counter (free
running counter). At the output side of the FIFO, use a different free run counter which
indicates a different address value than the address value at the free run counter at the
input side to read out data. [1]

If there are six FIFO stages, shifting the 3-bit address counter value will prevent the same
address from being simultaneously accessed. In this case, neither the input side clock nor
the output side clock will function erroneously even if a shift of two cycles or less occurs.
However, a reference enable signal is required for data exchanges during the asynchro-
nous period that used this FIFO.

Even if this enable signal is not present, if there is a pause in the data being input, there
is also a method that uses this pause interval to forcibly retrieve an enable signal. If no
enable signal exists and there is no pause in the data, there is no way to safely transfer the
correct data. Using an initial reset as the start signal for a free run counter in a design
can be hazardous.

DATA
Address
CLK1
EN1 Reset free run Reset free run
counter by Address counter by
EN1=1 EN2=1

EN2

CLK2

Figure 1-23 Transfer between asynchronous clocks with the same clock period

Large frame memory (dual port RAMs) is required for transfers between clocks that are
asynchronous but which do not have the same clock period. Similar to data transfer dur-
ing an asynchronous period using FIFO, the reference enable signal determines the ad-
dress values of the input side and output side. If data are output from the input side
consecutively and the duration of each frame is long, then there must be sufficient memory
for that frame. Therefore, it is necessary to carefully examine the architecture to make
sure that it does not grow too large. [2]

The check for this item is not available in RTqualify.

1-44
 1.5. Asynchronous circuits

1.5.3. Guaranteeing the setup/hold margin for synchronous RAM

[1] Guarantee the setup/hold margin mandatory

Chapter 1
[2] Synchronous RAM has a long hold time, so some measures are necessary reference

[3] Margin can be guaranteed by using a latch or by using buffer, inverter

reference
or delay cells

Basic Design Constraints

[4] Allocate RAM to the top level if possible reference

[5] There is also a method for avoiding modification of I/O for each reference
ASIC vendor by creating a general-purpose RAM module and fixing the I/O

Explanation
FFs operating by clock edges have a setup time and a hold time. (Refer to “1.5.1 Consider
metastable issues in signals between asynchronous clocks”.) Besides FFs, cells operating
by clock edges have a setup time and a hold time. Designers should follow this rule when
coding RTL to generate logic circuits using logic synthesis tools.

The RAM that is used inside LSIs and FPGAs is mostly synchronous RAM. Because syn-
chronous RAM operates on the rising edge of the clock just as other circuits do, it can be
used following the same approaches as for other logic circuits. However, synchronous
RAM has an extremely long hold time, and thus one must consider ways to ensure the hold
time. [2]

Hold time violations that occur in synchronous RAM are problems that can be solved by
the execution of commands to ensure the hold times using logic synthesis tools. However,
in some cases the hold time for synchronous RAM may exceed 1ns, and in some cases a
large number of buffers will be inserted in order to ensure the hold time (See Figure 1-24).
At 0.18um, 0.13um, or the like, the delay for one stage worth of buffer is only about 10 or
20ps. If we assume that the RAM hold assurance time is 1ns, then 50 or more buffers
would need to be added. If a large circuit is acceptable, it is a simple matter to use the
logic synthesis tools to ensure the hold time, though it means many buffers may be in-
serted.

ADR
DIN
Synchronous
WR_X
RAM
CS_X

Figure 1-24 Large amount of buffers inserted to guarantee hold time of synchronous RAM

If an increase in the size of the circuit is considered a problem, there is an alternative

method where a latch on the inverted clock is used. As is shown in Figure 1-25, when a
latch on the inverted clock is used before the synchronous RAM, there will be no changes
to the value of this signal when the clock is high. If the hold time value of the synchro-

1-45
 1.5. Asynchronous circuits

nous RAM is less than half of the clock period, this will solve any problems with hold time.
Latches that use the inverted clock have open gates during the interval over which the
clock is low. Even if we assume that there are a large number of logic gates prior to the
latch, the signal passes straight through the latch, and so the effective delay on this path
Chapter 1

becomes one cycle time subtracted by a latch delay time. In other words, by inserting the
latch, it is possible to solve the hold time assurance problem without being particularly
aware of the delay time before the signal arrives at the synchronous RAM.
Basic Design Constraints

ADR
G Previous
DIN stage
ADR h8256 h8257
G Synchronous
WR_X RAM
ADR ?? h8256 ??
G after
CS_X latch Data goes
through while
Low Data does
G
not change

Figure 1-25 Inserting a latch with an inverted clock to guarantee RAM hold time

In Figure 1-26, a BIST circuit is inserted into the RAM for automatic testing. Addition-
ally, when laying out the LSI, the positioning of the RAM should be decided first. If the
RAM is positioned in the topmost level instead of in a deep position in the local levels,
these operations are simplified.[4] However, in during design stages that use RTL descrip-
tion, it may require a large amount of work to move the RAM to the topmost level. For
example, for an IP that uses RAM internally, from a design management perspective it
would be unwise to move the RAM to the topmost level. Thus this should be interpreted as
“layout the RAM in as high a level as possible”.

When RAM is used within the IP, RAM cell names, I/O pin names, and specifications will
vary depending on the ASIC library used. If possible, it is convenient to prepare a stan-
dard RAM interface and reuse the RAM by adopting a method where the RAM is called up
from the ASIC library. [5]

Synchronous RAM BIST circuit Synchronous RAM

ADR ADR
DIN DOUT DIN DOUT

OE OE
RWE RWE
IH
IH BIST circuit
CLK Automatic insert CLK

Figure 1-26 Inserting a BIST circuit into memory

The check for this item is not available in RTqualify.

Designing with memories is explained in RMM:5.7.

1-46
 1.6. Hierarchical design

1.6. Hierarchical design

1.6.1. Consider limitations based on hierarchical scale

[1] Limit the gate size of a single level to 10,000 gates or fewer to ensure safety

Chapter 1
- As the operating frequency becomes higher, keep the size of a single level recommend 2
as small as possible.
- Limit the gate size of a level to 20,000 gates or fewer even when
the operating frequency is low (mandatory)

Basic Design Constraints

[2] Consider hierarchies on a scale of 2,000 to 10,000 gates(basic blocks) to be
the standard, and do not place logic gates in upper levels recommend 1
(Exception: CTS buffers)

[3] The size of basic blocks (on a 2,000 to 10,000 gate scale) at lower hierarchy
reference
is optional

[4] The top most hierarchy should only contain the following types of blocks.
-Clock generation module, reset generation module, RAM, ROM, I/O cells, mandatory
RTL description of the top hierarchy.

Explanation
When an ASIC design is made, they are segmented into each block by taking into account
the functionality and distribution to each designer. When divided into four blocks
(geometo, lendar, cpuif, video), as illustrated in Figure 1-27, if the geometo
block is to a certain extent rather large, then it is split up further into blocks such as
gtexc, gclip, and gmap. In this case, it will end up having hierarchical structures such
as G3DDengin (top level), geometo (upper levels), and gtexc (lower levels).

These hierarchical structures have two important meanings in ASIC design. One is the
segmentation of a hierarchical structure which is easy to verify or easy to reuse. The
other is the allocation of hierarchical modules that are easy to handle using logic synthe-
sis and layout tools.

G3Dengin (RTL top level)

geometo(upper level) lendar(upper level)

gtexc
gclip
(lower level)

gmap

cpuif(upper level) video

geometo is the basic level if its gate size is 2,000 - 10,000

If geometo is large, then the next gtexc down is the basic level

Figure 1- 27 Hierarchical structure of a 3D chip

1-47
 1.6. Hierarchical design
When considering the hierarchy in terms of logic synthesis and layout, there must be a
clear conception of what the basic block (basic level of hierarchical design) will be. The
basic block is constrained by size and structure. The size of the each basic block should
fundamentally be between 2,000 and 10,000 gates. [1] If the size of the four TOP (upper-
Chapter 1

level levels) blocks (geomet, lendar, cpuif, video) is between 2,000 and 10,000
gates, as illustrated in Figure 1-28, then these four blocks will constitute the basic blocks.

If any of the geometo, lendar, cpuif or video blocks is larger than 20,000 gates,
Basic Design Constraints

then the next lower levels (gtexc, gclip, gmap) would constitute the basic blocks.
* Logic synthesis is usually performed from these basic blocks.
* The hierarchical structure of the basic blocks is maintained by logic synthesis
and is passed on to the layout tool.
* Levels below the basic blocks are referred to as sub-blocks.
Sub-blocks' hierarchies are frequently ungrouped when used with a logic synthesis tool,
therefore hierarchical levels are not taken into account when transferred over to the lay-
out tool.

In the RTL TOP hierarchy, only hierarchical blocks should be placed and no logic gates
should be placed directly. [2] If a RTL description is written to generate logic gates in the
TOP hierarchy, it will be problematic to optimize these gates during logic synthesis.
In additions to RTL TOP descriptions, the topmost hierarchy may contain I/O cells, clock
generation modules, RAM and ROM. Logic gates should never be placed directly. [4]

I/O cells G3Dengin

RAM lendar
geometo

ROM

video
Clock
cpuif
generation
module

Figure 1-28 Top level diagram

Logic synthesis is performed at the basic block unit. If there is an RTL description in the
top level that has logic, it may be difficult to synthesize. It will be problematic to increase
operating speed even if logic synthesis using hierarchical compile was performed. If there
are logic gates that do not belong to any level, it will be difficult to place cells in their
proper locations during the layout phase, circuit speed will slow down, and wiring effi-
ciency will decrease.

1-48
 1.6. Hierarchical design

Logic synthesis performance will not be adversely affected if the basic blocks have up to
about 20,000 gates, thanks in part to recent improvements in the performance of logic
synthesis tools. The faster the operating speed required by the circuit, the smaller the
basic block should be made; otherwise, required performance cannot be met. For faster

Chapter 1
operating speed, using a smaller basic block is also advantageous to layout tools. There-
fore, you may wish to keep in mind that the faster the operating speed becomes, the smaller
the basic blocks should be.

Basic Design Constraints

It is not easy to make broad generalizations, but the relationship between the operating
speed and size of the basic blocks will typically depend on which ASIC vendor technology is
being employed or what type of circuit structure is being employed. Therefore, on a scale
of 0.35um, caution is urged for frequencies above about 50MHz, and unless careful consid-
eration is given to the size and structure of these basic blocks, problems could occur dur-
ing logic synthesis or layout when the frequency exceeds 100MHz. It should be considered
vital that the basic block size not surpass 10,000 gates when exceeding 50MHz at 0.35um
or 5,000 gates when exceeding 100MHz.

The limitation of basic block size is one constraint to be observed. However, the circuit
structure constraint noted in “1.6.2. Make basic blocks FF output & combinational circuit
input” is even more important. Size constraints will be meaningless if the circuit struc-
ture constraint is not observed.

RTqualify warns that

1611(W2) There are <number_of_line> lines that generate logic.
Comment, declaration statement and blank lines are not considered for the number of line.
1612(W1) No combinational circuits or FFs should exist in the top layer or layers based thereon.

Chip levels are explained in RMM:5.6.9.

1-49
 1.6. Hierarchical design

1.6.2. Make basic blocks FF output & combinational circuit input

[1] Make all basic blocks combinational circuit input and FF output recommend 3
Chapter 1

[2] When the above is impossible, have the timing path cover no more than
recommend 1
two blocks

[3] The above restrictions do not apply to smaller levels below the basic blocks reference
(2,000 – 10,000 gates in scale)
Basic Design Constraints

Explanation
Output of basic blocks should be FF output whenever possible. [1] By adhering to this rule,
you can gain advantages during the synthesis phase such as:
*Drive capacity and output arrival time from the outputs of basic blocks will be clearer.
*Input delay attributes (set_input_delay) provided during block synthesis and the values
for input drive capacity (set_driving_cell) are given with greater consistency.
As a result, the quality of an optimized circuit can be enhanced.

Also, the timing path can be kept within a single block when such a circuit structure is
employed. As a result, it is possible to prevent excessive loss of speed during layout since
the wiring length is restricted. Consider this to be a mandatory circuit structure for
designs that require tight timing constraints
C D

LOGIC FF LOGIC FF

Figure 1-29 Basic block structure

Nevertheless, it is difficult in actual design to make all basic blocks combinational circuit
input and FF output. In certain situations, FF input and combinational circuit output
will result. Even in these cases, however, you should observe the restrictions in “Figure 1-
30 Make paths two-modules paths if possible”. [2] This is because if there is a path that
passes through the basic block as combinational logic, it becomes very difficult to achieve
speed improvement on this path in the layout.

C D

FF LOGIC LOGIC FF

Figure 1-30 Make paths two-modules paths if possible

1-50
 1.6. Hierarchical design

RTqualify outputs the warning message:

when the number of lines is more than the last figure set by the variable of
basic_block_line_number(default=1000),

Chapter 1
1621(W3) Signal "<name>" outputted from this module as a combinational circuit.
If a path passes combinational circuit at a module, which is larger than the forward figure set
by the variable of basic_block_line_number(default=500), the following message is output.
1622(W1) There is a path that passes through a combinational circuit.

Basic Design Constraints

Register output is explained in RMM:5.6.1.

1-51
 1.6. Hierarchical design

1.6.3. Follow sub-block (the levels below basic clocks) constraints

[1] Limit paths that are critical in terms of speed to within two sub-blocks
reference
inside each basic block, if possible
Chapter 1

[2] If there are any speed issues, stay within three sub-blocks recommend 3
whenever possible
Basic Design Constraints

Explanation
Item “1.6.2. Make basic blocks FF output & combinational circuit input” is not applicable
to sub-blocks (levels below the basic blocks). However, it is not desirable to span a large
number of sub-blocks for designs that are tight in terms of speed. It is advisable to avoid
the use of designs in which timing paths span multiple blocks as much as possible. [1] Try
to keep the timing path to within no more than three sub-blocks, especially if there are
any speed problems. [2]

FF LOGIC LOGIC LOGIC FF

Figure 1-31 Keep paths to within three modules even inside sub-block

Optimizing combinational circuits which span different hierarchical levels presents the
following problems:

* Timing optimization goals are difficult to distribute

If the timing target between FF in Figure 1-31 had been set to 10ns or less, for ex-
ample, the timing goal must be distributed so that the total of each combinational
circuit is 10ns or less. It is difficult to distribute a precise timing that will optimize
each one to the same degree while keeping the structure of each combinational circuit
in mind.

* Optimization is restricted by hierarchy

Logic synthesis tools retain the hierarchical block's I/O ports as long as the hierarchy
is not flattened. When optimizing the logic surrounding the hierarchical block, even
if flattening and structuring makes it possible to improve the timing and area of a
circuit, the optimization process is limited by the hierarchical boundary in order to
preserve the I/O ports.

* Timing paths are difficult to trace

It is not easy to modify the RTL description in order to improve the timing path when
the blocks in each level of hierarchy are created by different designers. When the
timing path is kept within a single level, it is relatively easy to trace and improve.

1-52
 1.6. Hierarchical design

* Floor plan considerations are required

When executing a floor plan, it is necessary to construct physical hierarchies so that
the timing path is kept within a single cluster. When physical hierarchies are seg-

Chapter 1
mented by combinational circuits, there are cases in which the wiring will become
longer and the timing will deteriorate.

When the operating speed is somewhat fast (100Mz at 0.13um), the above restrictions

Basic Design Constraints

must be strictly observed.

RTqualify changes variables and uses 1611 and 1612 to check within sub-blocks..

Configuring combinational logic inside a single module is explained in RMM:5.6.2.

1-53
 1.6. Hierarchical design

1.6.4. Do not insert gates into upper levels of basic blocks

[1] The upper levels of basic blocks should contain only the connections mandatory
of each block
Chapter 1

[2] Paths with severe speed constraints should only contain connection of
recommend 3
each block, even in the sub-blocks

[3] If the scale of a basic block is about 10,000 gates, the number of I/O ports
recommend 2
Basic Design Constraints

should be specified to no more than 200

Explanation

Do not place logic (except for I/O cells and CTS buffers) in the upper levels of basic blocks.[1]
This is because a timing path that spans three blocks will result, as illustrated in Figure
1-32, even if only one AND gate is placed there. This would be in violation of the con-
straint in “1.6.2. Make basic blocks FF output & combinational circuit input”, which states
that the timing paths of basic blocks must span no more than two blocks. If such a path
exists, executing a floor plan in the layout will become more difficult and a very long
timing path may result. There may also be instance names in which logic cells that do
not exist in any basic block cannot be placed in the appropriate positions in the layout.
This will cause a floor plan to become problematic and layouts which take speed into ac-
count to become impossible.

FF LOGIC LOGIC LOGIC FF

Figure 1-32 Inserting a combinational circuit into an upper level hierarchy

When a timing path passes across multiple blocks, it becomes difficult to distribute the
optimum timing constraint necessary for properly optimizing the timing path. Also, when
synthesizing upper level hierarchies in which multiple basic blocks exist (50,000 to 200,000
gates), synthesis will take a long time to run and it will become difficult to use synthesis
methods that improve the operating speed. Any combinational circuits not belonging to
any basic blocks will make certain logic synthesis methods impossible.

Selectors for binding busses are sometimes placed in the upper level hierarchies of designs
in which busses exist. Also, selectors used for sharing I/O pins with test I/O are placed in
the top level (Figure 1-33). You should consider it a prerequisite to at least modularize
such logic.

If modularized, it will become possible to implement synthesis in smaller units on this

block (level of hierarchical design). Also during layout, it becomes possible to place these

1-54
 1.6. Hierarchical design

in each level of hierarchy and to implement an efficient layout. Thus, by placing small
selectors as module in a hierarchical level higher than the basic blocks, paths that span
two or three blocks may exist. Bus signals in particular have a certain degree of width at
16 bits and 32 bits, so the wiring area will expand.

Chapter 1
If possible, try to include such selectors inside some of the blocks in your design. However,
even if a selector to bundle the bus is included inside the ctrl block, the output from alu
will pass through the ctrl block and therefore does not follow the guideline of the timing

Basic Design Constraints

path span being no more than two blocks as stipulated in “1.6.2. Make basic blocks FF
output & combinational circuit input”. Clearly, an unnecessarily long path such as alu
->ctrl->ram ends up being created in the layout.

Test signal output selector

alu ram

ctrl Using hierarchy is necessary

even just for selectors

arbter Selector which binds the busses

It is ideal to have the above two selectors under separate hierarchical blocks

Figure 1-33 Inserting selectors into an upper level

If possible, it is best not to use a bus structure but rather to exchange signals directly,
such as from alu to arbter or from ram to ctrl. It may appear to be disadvantageous
since the number of ports for each module will increase, but this method offers a number
of advantages with current layout tools.

However, since the number of I/O ports for each block increases in a design where signals
are supplied from alu to all the other blocks, and from each of ctrl, ram and arbter to
all the other blocks, there is no other alternative but to choose a bus structure. Whether
it is necessary to assume a bus structure or not is determined at the time of system de-
sign, which is when consideration should be given to how to avoid using such a structure.

When the number of ports for each basic block increases, the number of paths which pass
through many blocks increases as well. In this situation, it may become difficult to perform
placement of basic blocks during the layout (floor plan) process. To increase the degree of
freedom at the time of layout, careful consideration must be given to the number of I/O ports of
each basic block. If the number of gates in basic blocks is about 10,000, 200 or fewer I/O ports
is preferable.

1-55
 1.6. Hierarchical design

RTqualify uses 1611 and 1612 to check 1641 and 1642.

1643(W1) Sum of number of input ports and number of output ports more than <n=200>.
Chapter 1

Elimination of glue logic at the top level is explained in RMM:5.6.8.

Basic Design Constraints

1-56
 1.6. Hierarchical design

1.6.5. Separate the data path section from the controller

[1] Description styles are different for the data path section and the controller reference

Chapter 1
[2] Different synthesis methods can be chosen for the data path section
reference
and the controller

Explanation

Basic Design Constraints

The data path section which consists of arithmetic operators and registers mainly per-
forms data processing. The controller regulates circuit states based on control signals
which originate from external signals and internal signals extracted from internal condi-
tions.

The description for the data path section consists primarily of FFs and operators. The
description for the controller mainly consists of control syntax including encoders/decod-
ers such as if statements or case statements , and state machine descriptions, such as
those described in “2.11. State machine descriptions”. [1]

FF

selector

+/-

barrel
shifter
selector

Figure 1-34 Separation of data path and control

Since descriptions for the data path block primarily consist of operators, most logic syn-
thesis tools perform processes such as allocating resources corresponding to the operators,
sharing resources, and optimizing operational expressions. See “5.6. Circuit synthesis
including operators” for more information.

Because control blocks primarily consist of state machine descriptions, logic operational
expressions, and FF descriptions, most logic synthesis tools perform logic optimization
processes such as structuring, flattening, or optimizing the state machine. See “2.11.State
machine descriptions” for more information. [2]

Separating the data path part from the control part is said to be useful in establishing
policies for RTL description and for logic synthesis. However, paths from the control to
the data path are often critical in terms of timing, and thus the control and the data path

1-57
 1.6. Hierarchical design
must have meaningful hierarchical relationships to each other.
Ideally, it would probably be best for the data path part and the control part to exist as sub
blocks of a basic block. Doing so will cause the paths from control parts to data path parts
to be contained within the same basic block. However, it is difficult to provide both mod-
Chapter 1

ules in the basic block when the size of circuits in the data path is large. Additionally, the
relationship between control parts and data path parts is often not a one-to-one relation-
ship, but rather multiple control parts are related to multiple data path parts.
It is not easy to create the ideal hierarchy structure. It is better to think in terms of basic
Basic Design Constraints

blocks, even more so than separating data path parts from control parts.
The rules described in this section should be considered an additional policy to the rules
described in “1.6.2. Make basic blocks FF output & combinational circuit input”, to be
implemented when possible.

The check for this item is not available in RTqualify.

1-58
 1.6. Hierarchical design

1.6.6. Designate buffer outputs in upper levels with 200,000 or more gates

[1] ASIC I/O cells should be inserted only in the top level or the I/O cell level recommend 3

Chapter 1
[2] In large-scale ASICs, it is not possible to synthesize everything reference
from the top level

[3] When a higher drive buffer is required for the output of a level with
reference
200,000 to 800,000 gates, create a separate module containing only buffers

Basic Design Constraints

Explanation
When performing LSI design, the designer must describe the I/O cells using RTL descrip-
tion. While there is a method in which I/O cells are inserted by logic synthesis tools, this
approach is not particularly practical in the design of large scale LSIs. This is because in
LSIs there are a large number of types of I/O cells (in comparison to FPGA), and because
the I/O cells are updated/changed frequently. It is necessary to check what type of I/O
cells is being used. I/O cells should either be described placed directly in the topmost
hierarchy, or should be described within the module of I/O cells that are placed in the
topmost hierarchy. [1]

The recent increases in speed with which logic synthesis tools run have made it possible to
perform logic synthesis on a relatively large scale. Even logic synthesis of circuits con-
taining as many as 500,000 gates and beginning at the uppermost level can take as little
as four to five hours, or, if on a slow system, the logic synthesis can be completed within
two days. However, when one takes into account the execution time and performance,
500,000 to 800,000 gates is probably about the limit for performing logic synthesis. In
designs in the two to three million gate range, only timing analysis can be done at the
topmost level.[2] In large designs in the two to three million gates range, the creation of a
higher-level module for the basic blocks is extremely important. It is not particularly
desirable for a circuit design to have some modules with 800,000 gates and other modules
with 2000 to 3000 gates, as well as the topmost hierarchy containing 200 or 300 modules.

There are some cases in which it is difficult to completely fulfill operating speed require-
ments using the logic synthesis tool within only the basic blocks. Even if logic synthesis
began with the basic blocks, fine-tuning the timing using circuits in the scope of 200,000
to 800,000 gates is a wise policy. The topmost level in the design of large LSI circuits
should have modules with no more than 200,000 to 800,000 gates.

Special caution is required regarding the inputs and outputs of the 200,000 to 800,000
gate blocks because logic synthesis using hierarchical compile to fine-tune the final cir-
cuit is not performed in the top level. The interfaces between these blocks require long
interconnects in the layout.

When the interconnect lines are long, it is necessary to provide buffers with strong drive
capabilities. Buffers that have strong drive capabilities can be produced by the logic syn-
thesis tool. A delicate balance between the added capacitance and delay values in the
output ports is required as well. Finally, it is difficult to derive an ideal drive capability.

1-59
 1.6. Hierarchical design

If one wishes to place a higher drive buffer, it is probably best to specify the buffer cell
explicitly.

However, when it comes to this buffer, problems may arise in the form that is called di-
Chapter 1

rectly from the RTL description. If the cell is frozen through the use of the “set_dont_touch”
command in logic synthesis for the higher drive buffer called by RTL description, then
this cell itself will not be deleted. However, the output net for this cell may be cut off and
the output of the cell may pass through an indirect route.
Basic Design Constraints

To avoid such circumstances, prepare separate modules for higher drive buffers as shown
in Figure 1-35, and use a method for calling these modules. When this is the case, as long
as "set_dont_touch" is specified for the module, the output network will never be cut off in
this way.

For layers with 200K – 800K gates or more,

do not perform synthesis at levels above
set_dont_touch
blockbuf
the module

For output of each hierarchy, it is desirable

Directly specify to place buffers or inverters of higher drive
HighPower cells

Buffers with higher drive should be created

as a separate module and placed

Fix HighPower cells

using set_dont_touch
When a high drive buffer is placed
directly under a hierarchy, fixed by
Output from other
set_dont_touch, and logic
route
synthesis is performed, it may be
output via a detoured route.

Figure 1-35 Use of hierarchy and placement of buffers

Adding buffers in an output port means not only securing the usage of higher drive cells
but also closing timing analysis within the block. If output signals of a module are used
not only as output ports, but also as internal signals, the delay values inside the module
change depending on additional capacitance connected to the output ports. Therefore,
buffers should be inserted just before the output port to facilitate timing analysis of a
large scale design.

With the latest version of logic synthesis tools, the buffer just before the output port can
be inserted by the command of tools. Please refer to "5.7.4.13 set_isolate_ports" for de-
tails. Buffer insertion just before the output port is not necessary if logic synthesis tools
generates particular buffers.

The check for this item is not available in RTqualify.

1-60