effective rtl coding rules to avoid simulation shoot-thru
DESCRIPTION
Effective RTL coding rules to avoid Simulation Shoot-thru. Udit Kumar 1 , Bhanu Prakash 1 , Olivier Florent 1 , Paras Mal Jain 2, Anshu Malani 2 , Shaker Sarwary 2 1 STMicroelectronics 2 Atrenta Inc. Name, Affiliation and email. Abstract. - PowerPoint PPT PresentationTRANSCRIPT
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 [email protected]
Bhanu Prakash STMicroelectronics [email protected]
Olivier Florent STMicroelectronics [email protected]
Paras Mal Jain Atrenta Inc. [email protected]
Anshu Malani Atrenta Inc. [email protected]
Shaker Sarwary Atrenta Inc. [email protected]
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