Tài liệu Logic Synthesis With Verilog HDL part 4 doc

[ Team LiB ]


14.5 Verification of Gate-Level Netlist
The optimized gate-level netlist produced by the logic synthesis tool must be verified for
functionality. Also, the synthesis tool may not always be able to meet both timing and
area requirements if they are too stringent. Thus, a separate timing verification can be
done on the gate-level netlist.
14.5.1 Functional Verification
Identical stimulus is run with the original RTL and synthesized gate-level descriptions of
the design. The output is compared to find any mismatches. For the magnitude
comparator, a sample stimulus file is shown below.
Example 14-3 Stimulus for Magnitude Comparator
module stimulus;

reg [3:0] A, B;
wire A_GT_B, A_LT_B, A_EQ_B;

//Instantiate the magnitude comparator
magnitude_comparator MC(A_GT_B, A_LT_B, A_EQ_B, A, B);

initial
$monitor($time," A = %b, B = %b, A_GT_B = %b, A_LT_B = %b, A_EQ_B = %b",
A, B, A_GT_B, A_LT_B, A_EQ_B);

//stimulate the magnitude comparator.
initial
begin
A = 4'b1010; B = 4'b1001;
# 10 A = 4'b1110; B = 4'b1111;
# 10 A = 4'b0000; B = 4'b0000;

# 10 A = 4'b1000; B = 4'b1100;
# 10 A = 4'b0110; B = 4'b1110;
# 10 A = 4'b1110; B = 4'b1110;
end

endmodule
The same stimulus is applied to both the RTL description in Example 14-1
and the
synthesized gate-level description in Example 14-2, and the simulation output is
compared for mismatches. However, there is an additional consideration. The gate-level
description is in terms of library cells VAND, VNAND, etc. Verilog simulators do not
understand the meaning of these cells. Thus, to simulate the gate-level description, a
simulation library, abc_100.v, must be provided by ABC Inc. The simulation library must
describe cells VAND, VNAND, etc., in terms of Verilog HDL primitives and, nand, etc.
For example, the VAND cell will be defined in the simulation library as shown in
Example 14-4
.
Example 14-4 Simulation Library
//Simulation Library abc_100.v. Extremely simple. No timing checks.

module VAND (out, in0, in1);
input in0;
input in1;
output out;

//timing information, rise/fall and min:typ:max
specify
(in0 => out) = (0.260604:0.513000:0.955206, 0.255524:0.503000:0.936586);
(in1 => out) = (0.260604:0.513000:0.955206, 0.255524:0.503000:0.936586);
endspecify

//instantiate a Verilog HDL primitive
and (out, in0, in1);
endmodule
...
//All library cells will have corresponding module definitions
//in terms of Verilog primitives.
...
Stimulus is applied to the RTL description and the gate-level description. A typical
invocation with a Verilog simulator is shown below.
//Apply stimulus to RTL description
> verilog stimulus.v mag_compare.v

//Apply stimulus to gate-level description.
//Include simulation library "abc_100.v" using the -v option
> verilog stimulus.v mag_compare.gv -v abc_100.v
The simulation output must be identical for the two simulations. In our case, the output is
identical. For the example of the magnitude comparator, the output is shown in Example
14-5.
Example 14-5 Output from Simulation of Magnitude Comparator
0 A = 1010, B = 1001, A_GT_B = 1, A_LT_B = 0, A_EQ_B = 0
10 A = 1110, B = 1111, A_GT_B = 0, A_LT_B = 1, A_EQ_B = 0
20 A = 0000, B = 0000, A_GT_B = 0, A_LT_B = 0, A_EQ_B = 1
30 A = 1000, B = 1100, A_GT_B = 0, A_LT_B = 1, A_EQ_B = 0
40 A = 0110, B = 1110, A_GT_B = 0, A_LT_B = 1, A_EQ_B = 0
50 A = 1110, B = 1110, A_GT_B = 0, A_LT_B = 0, A_EQ_B = 1
If the output is not identical, the designer needs to check for any potential bugs and rerun
the whole flow until all bugs are eliminated.
Comparing simulation output of an RTL and a gate-level netlist is only a part of the
functional verification process. Various techniques are used to ensure that the gate-level

netlist produced by logic synthesis is functionally correct. One technique is to write a
high-level architectural description in C++. The output obtained by executing the high-
level architectural description is compared against the simulation output of the RTL or
the gate-level description. Another technique called equivalence checking is also
frequently used. It is discussed in greater detail in Section 15.3.2
, Equivalence Checking,
in this book.
Timing verification
The gate-level netlist is typically checked for timing by use of timing simulation or by a
static timing verifier. If any timing constraints are violated, the designer must either
redesign part of the RTL or make trade-offs in design constraints for logic synthesis. The
entire flow is iterated until timing requirements are met. Details of static timing verifiers
are beyond the scope of this book. Timing simulation is discussed in Chapter 10
, Timing
and Delays.

[ Team LiB ]

[ Team LiB ]


14.6 Modeling Tips for Logic Synthesis
The Verilog RTL design style used by the designer affects the final gate-level netlist
produced by logic synthesis. Logic synthesis can produce efficient or inefficient gate-
level netlists, based on the style of RTL descriptions. Hence, the designer must be aware
of techniques used to write efficient circuit descriptions. In this section, we provide tips
about modeling trade-offs, for the designer to write efficient, synthesizable Verilog
descriptions.
14.6.1 Verilog Coding Style
[2]

[2]
Verilog coding style suggestions may vary slightly based on your logic synthesis tool.
However, the suggestions included in this chapter are applicable to most cases. The IEEE
Standard Verilog Hardware Description Language document also adds a new language
construct called attribute. Attributes such as full_case, parallel_case, state_variable, and
optimize can be included in the Verilog HDL specification of the design. These attributes
are used by synthesis tools to guide the synthesis process.
The style of the Verilog description greatly affects the final design. For logic synthesis, it
is important to consider actual hardware implementation issues. The RTL specification
should be as close to the desired structure as possible without sacrificing the benefits of a
high level of abstraction. There is a trade-off between level of design abstraction and
control over the structure of the logic synthesis output. Designing at a very high level of
abstraction can cause logic with undesirable structure to be generated by the synthesis
tool. Designing at a very low level (e.g., hand instantiation of each cell) causes the
designer to lose the benefits of high-level design and technology independence. Also, a
"good" style will vary among logic synthesis tools. However, many principles are
common across logic synthesis tools. Listed below are some guidelines that the designer
should consider while designing at the RTL level.
Use meaningful names for signals and variables
Names of signals and variables should be meaningful so that the code becomes self-
commented and readable.
Avoid mixing positive and negative edge-triggered flipflops
Mixing positive and negative edge-triggered flipflops may introduce inverters and buffers
into the clock tree. This is often undesirable because clock skews are introduced in the
circuit.
Use basic building blocks vs. use continuous assign statements
Trade-offs exist between using basic building blocks versus using continuous assign
statements in the RTL description. Continuous assign statements are a very concise way
of representing the functionality and they generally do a good job of generating random

logic. However, the final logic structure is not necessarily symmetrical. Instantiation of
basic building blocks creates symmetric designs, and the logic synthesis tool is able to
optimize smaller modules more effectively. However, instantiation of building blocks is
not a concise way to describe the design; it inhibits retargeting to alternate technologies,
and generally there is a degradation in simulator performance.
Assume that a 2-to-1, 8-bit multiplexer is defined as a module mux2_1L8 in the design. I
f
a 32-bit multiplexer is needed, it can be built by instantiating 8-bit multiplexers rather
than by using the assign statement.
//Style 1: 32-bit mux using assign statement
module mux2_1L32(out, a, b, select);
output [31:0] out;
input [31:0] a, b;
wire select;

assign out = select ? a : b;
endmodule

//Style 2: 32-bit multiplexer using basic building blocks
//If 8-bit muxes are defined earlier in the design, instantiating
//these muxes is more efficient for
//synthesis. Fewer gates, faster design.
//Less efficient for simulation
module mux2_1L32(out, a, b, select);
output [31:0] out;
input [31:0] a, b;
wire select;

mux2_1L8 m0(out[7:0], a[7:0], b[7:0], select); //bits 7 through 0
mux2_1L8 m1(out[15:7], a[15:7], b[ 15:7], select); //bits 15 through 7

mux2_1L8 m2(out[23:16], a[23:16], b[23:16], select); //bits 23 through 16
mux2_1L8 m3(out[31:24], a[31:24], b[31:24], select); //bits 31 through 24

endmodule
Instantiate multiplexers vs. Use if-else or case statements
We discussed in Section 14.3.3
, Interpretation of a Few Verilog Constructs, that if-else
and case statements are frequently synthesized to multiplexers in hardware. If a
structured implementation is needed, it is better to implement a block directly by using
multiplexers, because if-else or case statements can cause undesired random logic to be
generated by the synthesis tool. Instantiating a multiplexer gives better control and faster
synthesis, but it has the disadvantage of technology dependence and a longer RTL
description. On the other hand, if-else and case statements can represent multiplexers