Effective RTL coding rules to avoid Simulation Shootthru

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 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 l When any signal jumps over an extra register within one clock cycle. ¤ din E. g. Input “din” crosses 2 register within one clock cycle. dint 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? din clk dint D dout D Reason : Extra Delta delay in Clock Path cint clk 0>1 dint 0>1 cint 0>1 dout 0>1 clk cint dint dout 5 Consequence : “dout” same as “din” within single clock

Will Verilog coding rules help? // Input data sampling l blocking assignment in combination blocks and always @ (posedge clk, negedge rst_n) begin if (rst_n==1’b 0) dint <= din; else dint <= din; end l non-blocking in sequential ¤ din clk Not, always safe…. D dint cdiv 6 dout D cint Extra Delta-delay in Clock Path // Capture data on divided clock always @ (posedge cint, negedge rst_n) begin if (rst_n==1’b 0) dout <= 1’b 0; else dout <= dint; end // Sequentioal clock generation always @ (posedge clk, negedge rst_n) begin if (rst_n==1’b 0) cint <= 1’b 0; else cint <= !cint; end Non-blocking assignments consume delta delay

Case 1: Verification can miss Shoot-thru 7 l User specification was to transfer “din” to “dout” in 1 cycle l 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 l Existence of One extra flop causes silicon failure.

Case 2: Verification can miss Shoot-thru 8 l User specification was to transfer “din” to “dout” in 2 cycle l However, shoot-thru may cause simulation failure l 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 Equivalence check Gates Silicon Functional Design Pros: Verification at gate level represents Silicon. Cons: Huge data base and run time. Verification Synthesis N/l Simulation Physical design Verification

So, How to detect shoot-thru issues? 10 l By using an improved simulator? ¤ NO, as root cause of problem is that RTL Simulation has no notion of timing delay & Hold checks. l By doing Gate level simulation? ¤ Yes but it is very costly. l By using robust RTL coding rules? ¤ Yes! this is easy and efficient (see subsequent slides)

Rule 1 - Force scheduling of data l Force physical time delay in Sequential data assignments l 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 1 ns dint D dout D l Delay on clock paths competes with delay on Data path cint clk after 1 ns l Clock vs Data scheduling still un-reliable No unwanted delay on clock path Rule 1 + Rule 2 ensures no risk of shoot-thru i. e data is updated after clock

Automation with Spy. Glass 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 cint clk dint D D dout cint Rule 2 – Reports extra delay (Physical) present in clock path Easy to identify shoot-thru prone RTL

Checker catches Real Silicon Issues l Missing delay was causing silicon failure Missing delay at source din tck D D dout logic Buffer, Clock gating etc. l 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 clk. D Extra delay in clock divider dout 14

Conclusion 15 l Simulators create events and schedule them, but with no notion of timing checks across data and clock events l Shoot-thru impacts RTL Simulation and may cause false simulation behavior, masking the real issues l 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 l Spyglass RTL checker can help you to efficiently check those rules and removes need of costly gate level simulations. l Next Steps ¤ Extend the Spy. Glass checks to ensure that every output interface is having delayed assignment