Avoiding RTL coding mistakes

Here's a discussion on RTL coding styles that lead to increased design cycle time and
unnecessary complexity during design closure.
By Anubhav Srivastava and Neha Srivastava
Senior Design Engineers
Freescale Semiconductor India Pvt. Ltd.
SoC designs involve a number of evolution steps. These steps include efficient designing skills, rigorous and exhaustive
verification checks, witty power planning and floor planning , tiring STA closure, and many sign offs until the final chip
is delivered to the customer. The whole flow from architectural level planning to balls-based packaging is so
interdependent that an overlooked fault at ones end earlier in the flow can cause nightmares to the team at the later
stages of the design.
This article discusses careless RTL coding styles which cause increase in design cycle time and unnecessary complexity
at the time of the design closure. Some of the major RTL quality check points are as follows:
1) Floating inputs / Un-driven nets: At the time of writing a RTL code , designer assumes that certain logic will be
optimised while logic synthesis as the output of the logic is not impacting the functionality of the module and hence
he/she leaves the inputs of the logic unconnected. E.g. If a 32 bit IP is used for the same 16 bit application the rest
16 bits are unused.
This may result in a very major problem of floating gate if the concerned logic is not optimised while synthesis.
These floating gates are caught in LVS checks at the time of physical signoff if not specifically searched in synthesis
and placement netlist. This further requires a lot of design review in closing stages of the SoC cycle to decide a
suitable constant value that can be connected at these gates. This problem can be simply avoided by tying all the
unused inputs of such type to a constant value say 1b0 and 1b1 at the time of RTL coding itself which not only
prevents the floating gate problem but also allows synthesis to optimise the logic more intensely.
2) Multi-Driven nets: This RTL coding mistake is quite common, it occurs when the same net in RTL is driven by two
or more drivers. The general cause for this mistake is manual error and this is very difficult to catch with manual
review. The multi-driven nets are processed differently by different tools used in verification and synthesis; these
might result in wrong RTL functionality and further wrong design closure. The multi-driven nets can be caught at
the time of RTL linting or at time of elaboration in synthesis tool. These nets should be removed before design is
further processed hence a list of such nets should be sent to RTL owner for review.
3) The next case of wrong RTL coding is a case which cannot be caught by simple RTL parsing. To understand it, let's
discuss the way a normal flip flop is coded. in Verilog 2K1
always @ (posedge clk or negedge rst_b)
begin
if (~rst_b)
q1 <= 1b0;
else
q1 <= d;
end
The definition ensures a pos-edge flop with an asynchronous reset pin.
Now suppose designer wants to have a signal say rstval as output of this flop at the time when reset is asserted .In this
case he will easily put the code in format .
always @ (posedge clk or negedge rst_b)
begin
if (~rst_b) begin
q1 <= rstval;
else
q1 <= d;
end
EE Times-India | eetindia.com

Copyright 2011 eMedia Asia Ltd.

Page 1 of 4

At the designers level this looks an obvious solution . Now let's see what is the impact of such coding as the RTL goes
forward.
1) Synthesis: This flop will be realised as following:
module test (clk, d, rst_b, rstval, q);
input clk, d, rst_b, rstval;
output q1;
wire clk, d, rst_b, rstval;
wire n_0, n_1, q1;
DFFSRX1 q1_reg (.RN (n_1), .SN (n_0), .CK (clk), .D (d), .Q (q1), .QN ());
OR2XL g36 (.A (rst_b), .B (rstval), .Y (n_1));
NAND2BXL g35 (.AN (rst_b), .B (rstval), .Y (n_0));
Endmodule
The flop is synthesised with an additional OR2 gate and an NAND2B gate ( here B indicates the AN input of NAND
gate is inverted ) . This not only increases gate count but also require a set- reset flop in the library cellset which
might not available for all threshold voltages or Scan conditions .

rst_b

SN
rstval

D
Q

Figure 1: A Set/Reset Flop implementation due to wrong RTL coding.

2) Routing stage: Normally in SoCs asynchronous resets are high fanout nets which go to large number of flops and
require a separate physical synthesis like clock. Every reset net has to be built at a particular latency within a fixed
skew target in order to ensure same state of each flop at the time of reset. This extra logic( OR2 and NAND2B)
which comes along with the set-reset FLOP can make it difficult to achieve delay requirements on these flops (likely
to be the case for high frequency designs).
Normally flip-flops designed have a requirement that set and reset pins should not get asserted at the same time. In
this case the design is prone to such issues as delay matching for the 2 paths (from rstval to sb pin of flop and
from rstval to rb pin of flops) would be very difficult to meet (if not impossible).
3) STA signoff: Normally a set-reset flip flop has a priority on set or reset signal also there is a data to data setup / hold
check between set and reset pins of flop in order to ensure no data is corrupted in case a switching exist between
set and reset pins. This check comes almost in the last stages of timing closure cycle after HFN synthesis and
always test STA engineer to meet such critical requirements.
The most critical impact of such kind of coding is the untimed paths in STA. In STA we normally consider a flip flop
as a timing end point. Also the paths through rb or sb pins are properly timed w.r.t clock reaching this flop by
recovery and removal checks.
Now suppose at the time when asynchronous reset (rst_b is asserted) the signal rstval changes dynamically this
takes the arcs through flip flop (RN-> Q and SN-> Q) as combinational arcs . This means signal rstval is launched by
some flop and is required to be captured by other flop while it passes through a flops set/reset pins .
These type of paths are not usually timed and STA engineer has to take special care by either putting extra
uncertainties or by adding extra modes in his setup to meet this requirement. Unless these timing requirements are
specified very clearly in the Integration guides these paths may not get timed at all.
EE Times-India | eetindia.com

Copyright 2011 eMedia Asia Ltd.

Page 2 of 4

4) Gate Sim Synthesis mismatch: This would impact simulation majorly in the case where CLOCKS are not available
during reset assertion and de asserted. To elaborate, mismatch in simulation is seen, since after synthesis, the q1
will change value if there's a change in rstval. But in RTL simulation, since rstval is not in the sensitivity list, q and
q1 won't be updated if rstval changes. This consumes lots of simulation debug time.
All these problems can be easily avoided by changing the coding style of a flop. We can restructure the code by
putting a mux at the output of flop
-----------always @ (posedge clk or negedge rst_b)
begin
if (~rst_b) begin
q1 <= 1'b0;
else
q1 <= d;
end
--------assign q1_reg_out = rst_b ? q1 : rstval
This code will end all the previous stated challenges. No extra STA check is required as paths will be automatically
timed. Now in the case where it is a must to code a signal value in reset state of flop, the code can be restructured in
order to prevent synthesis to simulation mismatches as:
wire set = ~rst_b & rstval;
wire reset = ~rst_b & ~rstval;
always @(posedge clk or posedge set or posedge reset)
if (reset) q1 <= 0;
else if (set) q1 <= 1;
else q1 <= d;
rst_b

rstval
D

CK

RN
Q

CK

CK

Figure 2: Correct way of RTL coding.

Hence following best design practices right from the beginning is essential to ensure small cycle time, efficient timing
closure and enhanced reliability for our SoCs.

EE Times-India | eetindia.com

Copyright 2011 eMedia Asia Ltd.

Page 3 of 4

About the authors

Anubhav is a senior design engineer working in Freescale Semiconductor India Pvt. Ltd. He has worked on
multiple multi-million gate SoCs in Synthesis and STA domains and currently working as DFT engineer. He
holds a bachelors degree from Motilal Nehru National Institute of Technology (Allahabad Uttar Pradesh
India) .His area of research includes low power designing , formal verification , advanced synthesis
methodologies etc
Neha is a senior design engineer working in Freescale Semiconductors India Pvt Ltd. She has worked on
multiple SoCs in front-end verification domain. She has a bachelor's degree from Birla Institute of
Technology (Mesra Ranchi India). Her areas of interest include low power architectures and their
verification.

EE Times-India | eetindia.com

Copyright 2011 eMedia Asia Ltd.

Page 4 of 4