effective rtl coding rules to avoid simulation shoot-thru

Effective RTL coding rules to avoid Simulation Shoot-thruEffective RTL coding rules to avoid Simulation Shoot-thru

Udit Kumar1, Bhanu Prakash1, Olivier Florent1, Paras Mal Jain2, Anshu Malani2, Shaker Sarwary2

1STMicroelectronics2Atrenta Inc.

Name, Affiliation and emailName, 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 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? What is Shoot-thru?

When any signal jumps over an extra register within one clock cycle. E.g. Input “din” crosses 2 register within one clock cycle.

4

In silicon => gate delayIn simulator => events

Shoot-thru: (events in data path ) <= (events in clock path)

clk

dintdin dout

cint

D D

How Simulation Shoot-thru occurs?How Simulation Shoot-thru occurs?5

dintdin dout

clk cint

D D

dint 0>1 cint 0>1

dout 0>1

Consequence : “dout” same as “din” within single clock

clk 0>1

Reason : Extra Delta delay in Clock Path

clk

cint

din

dint

dout

Will Verilog coding rules help?Will Verilog coding rules help?6

// Input data sampling always @ (posedge clk, negedge rst_n) begin if (rst_n==1’b0)

dint <= din; else

dint <= din; end

// Capture data on divided clockalways @ (posedge cint, negedge rst_n) begin if (rst_n==1’b0) dout <= 1’b0; else

dout <= dint; end

// Sequentioal clock generationalways @ (posedge clk, negedge rst_n) begin if (rst_n==1’b0) cint <= 1’b0; else

cint <= !cint; end

blocking assignment in combination blocks and

non-blocking in sequential Not, always safe….

dout

clk cint

din dintD D

cdiv

Non-blocking assignments consume delta delay

Extra Delta-delay in Clock Path

Case 1: Verification can miss Shoot-thruCase 1: Verification can miss Shoot-thru7

User specification was to transfer “din” to “dout” in 1 cycle

Extra flop was a mistake but not caught by RTL verification.

dindout

clkcint

dintD D

Silicon fails as “din” will be captured at “dout” in 2 cycles => one cycle extra delay vs. Specification

If Simulation has shoot-thru => “din” will be captured at “dout” in 1 cycle => All tests pass as per user specification

Existence of One extra flop causes silicon failure.

Case 2: Verification can miss Shoot-thruCase 2: Verification can miss Shoot-thru8

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

Simulation Failsdin

dout

clk

D D

Silicon Failsdin

dout

clk

D D D

Simulation Passesafter rtl changes

din

dout

clk

D D D New Flop

Potential Gap in design flowPotential Gap in design flow

Verification

N/l Simulation

Pros: Verification at gate level represents Silicon.

Cons: Huge data base and run time.

Functional Design

Verification

Synthesis

Physical designPhysical design

HDL

Gates

Silicon

Functional Specification

Equivalence check

By using an improved simulator? NO, as root cause of problem is that RTL Simulation has no

notion of timing delay & Hold checks.

10

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)

So, How to detect shoot-thru issues?So, How to detect shoot-thru issues?

Rule 1 - Force scheduling of dataRule 1 - Force scheduling of data11

din dout

clk cint

dint

D D

This adds an extra delay in data path

dint<= din after 1 ns;VHDL

dint <= #1 din ;Verilog

Force physical time delay in Sequential data assignments

Signal is delayed in ‘physical time’, instead of ‘delta’ time.

Rule 2 - No ‘physical delay’ in clock path Rule 2 - No ‘physical delay’ in clock path

Delay on clock paths competes with delay on Data path

Clock vs Data scheduling still un-reliable

12

din dout

clk cint

dint

D D

Rule1 + Rule2 ensures no risk of shoot-thru i.e data is updated after clock

after 1ns

after 1ns

No unwanted delay on clock path

Automation with SpyGlass RTL checkerAutomation with SpyGlass RTL checker13

dindout

clk cint

D D

If delta delay is different between launch and capture flop, add delay

on launch flop

Rule 1 – Reports missing needed delay in data path

Rule 2 – Reports extra delay (Physical) present in clock path

din dout

clk cint

dintD D

Easy to identify shoot-thru prone RTL

Checker catches Real Silicon IssuesChecker catches Real Silicon Issues14

dindout

tck

D D

logic

Missing delay at source

din dout

tck

D D

clkD

Extra delay in clock divider

Missing delay was causing silicon failure

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

Buffer, Clock gating etc.

ConclusionConclusion

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

15