Effective RTL coding rules to avoid
Simulation Shoot-thru
Udit Kumar1, Bhanu Prakash1, Olivier Florent1,
Paras Mal Jain2, Anshu Malani2, Shaker Sarwary2
1STMicroelectronics
2Atrenta
Inc.
Name, Affiliation and email
Author Name
Affiliation
Email
Udit Kumar
STMicroelectronics
udit-hed.kumar@st.com
Bhanu Prakash
STMicroelectronics
bhanu.prakash@st.com
Olivier Florent
STMicroelectronics
olivier.florent@st.com
Paras Mal Jain
Atrenta Inc.
paras@atrenta.com
Anshu Malani
Atrenta Inc.
anshum@atrenta.com
Shaker Sarwary
Atrenta Inc.
shaker@atrenta.com
Abstract
RTL simulations do not consider timing in all aspects and therefore, the results
produced by simulation may differ from silicon behavior. Simulation can miss
design bugs due to limitations in simulator. These differences are due to
incorrect estimation of propagation time between clock and data paths causing
data to propagate earlier than in silicon. This problem is known as shoot-thru.
We faced a silicon failure which prompted us to understand how shoot-thru
situations occur during simulation, identify these situations with higher accuracy
of analysis and fix them with minimal impact using simple RTL coding rules.
We teamed up with Atrenta to automate efficiently the check of those coding
rules.
What is Shoot-thru?
4
 When any signal jumps over an extra register within
one clock cycle.

E.g. Input “din” crosses 2 register within one clock cycle.
dint
din
D
D
cint
clk
dout
In silicon => gate delay
In simulator => events
Shoot-thru:
(events in data path ) <= (events in clock path)
How Simulation Shoot-thru occurs?
5
din
dint
D
dout
D
Reason : Extra Delta
delay in Clock Path
clk
cint
clk
0>1
dint
0>1
cint
0>1
dout 0>1
clk
cint
din
dint
dout
Consequence : “dout”
same as “din” within
single clock
Will Verilog coding rules help?
6
 blocking assignment in
combination blocks and
// Input data sampling
always @ (posedge clk, negedge rst_n) begin
if (rst_n==1’b0)
dint <= din;
else
dint <= din;
end
 non-blocking in sequential

Not, always safe….
// Capture data on divided clock
din
clk
D
dint
cdiv
dout
D
cint
Extra Delta-delay in Clock Path
always @ (posedge cint, negedge rst_n) begin
if (rst_n==1’b0)
dout <= 1’b0;
else
dout <= dint;
end
// Sequentioal clock generation
always @ (posedge clk, negedge rst_n) begin
if (rst_n==1’b0)
cint <= 1’b0;
else
cint <= !cint;
end
Non-blocking assignments consume delta delay
Case 1: Verification can miss Shoot-thru
 User specification was to transfer “din” to “dout” in 1 cycle
 Extra flop was a mistake but not caught by RTL verification.
If Simulation has shoot-thru => “din” will be captured at “dout” in 1 cycle
=> All tests pass as per user specification
din
dout
dint
D
D
cint
clk
Silicon fails as “din” will be captured at “dout” in 2 cycles
=> one cycle extra delay vs. Specification
 Existence of One extra flop causes silicon failure.
7
Case 2: Verification can miss Shoot-thru
8
 User specification was to transfer “din” to “dout” in 2 cycle
 However, shoot-thru may cause simulation failure
 User fixes it by adding an extra flop
dout
din
D
D
Simulation Fails
clk
din
dout
D
D
D New
Flop
clk
din
clk
Simulation Passes
after rtl changes
dout
D
D
D
Silicon Fails
Potential Gap in design flow
Functional Specification
HDL
Functional Design
Equivalence
check
Gates
Silicon
Pros: Verification at gate level
represents Silicon.
Cons: Huge data base and run
time.
Verification
Synthesis
N/l Simulation
Physical design
Verification
Gate Level
Simulation
can detect
shoot-thru
So, How to detect shoot-thru issues?
 By using an improved simulator?

NO, as root cause of problem is that RTL Simulation has no
notion of timing delay & Hold checks.
 By doing Gate level simulation?

Yes but it is very costly.
 By using robust RTL coding rules?

Yes! this is easy and efficient (see subsequent slides)
10
Rule 1 - Force scheduling of data
 Force physical time delay in Sequential data assignments
 Signal is delayed in ‘physical time’, instead of ‘delta’ time.
Verilog
VHDL
dint <= #1 din ;
dint<= din after 1 ns;
dint
din
clk
D
dout
D
cint
This adds an extra delay in data path
11
Rule 2 - No ‘physical delay’ in clock path
12
after 1ns
din
dint
D
clk
dout
D
 Delay on clock paths
competes with delay on
Data path
cint
after 1ns
 Clock vs Data scheduling
still un-reliable
No unwanted delay on clock path
Rule1 + Rule2 ensures no risk of shoot-thru
i.e data is updated after clock
Automation with SpyGlass RTL checker
13
Rule 1 – Reports missing needed
delay in data path
dout
din
D
D
If delta delay is different between
launch and capture flop, add delay
on launch flop
clk
cint
din
clk
dint
dout
D
D
cint
Rule 2 – Reports extra delay
(Physical) present in clock path
Easy to identify shoot-thru prone RTL
Checker catches Real Silicon Issues
 Missing delay was causing silicon failure
Missing delay at source
dout
din
tck
D
D
logic
Buffer, Clock gating etc.
 Unintentional delay in clock path found on another chip

User specified physical delay on source flop - Still problem
occurred due to physical delay specified on clock path
din
tck
D
D
clkD
Extra delay in clock divider
dout
14
Conclusion
15
 Simulators create events and schedule them, but with no
notion of timing checks across data and clock events
 Shoot-thru impacts RTL Simulation and may cause false
simulation behavior, masking the real issues
 Simple RTL coding rules can prevent the problem to
occur


Possibly add physical delays on data path to force scheduling
Avoid physical delays on clock path
 Spyglass RTL checker can help you to efficiently check
those rules and removes need of costly gate level
simulations.
 Next Steps

Extend the SpyGlass checks to ensure that every output
interface is having delayed assignment