Absolute GLS Verification: An Early Simulation of Design Timing Constraints

Download as pdf or txt
Download as pdf or txt
You are on page 1of 25

Absolute GLS Verification

An Early Simulation of Design Timing Constraints

By Ateet Mishra, Deepak Mahajan and Shiva Belwal

TM
Agenda

 Basics Design Flow [ FE-Verif-PD-Verif-FE-PD-Signoff]


 Motivation
 Defining the right scope
 Basics of Design Timing
 How current GLS verification is not absolute.
 Absolute GLS Verification
 Default Delays Modeling
 Different Aspects of Constraint Modeling
 SDF Generation Algorithm
 The new Design Flow
 Future Scope
 Results and Conclusion

TM

1
Basic Design Flow and Challenge
RTL Verification

FE Integration Functional Verification

Logic Freeze

ECOs Gate Level


Netlist &SDF

Physical Design

synthesis placement CTS Setup-Opt Hold-Opt


Dependencies on skew
matched clock delays..
Close to ~ 6 weeks turnaround time to provide SDF !! REALLY ??
Are we doing robust gate level verification ?

TM

2 2
Our Motivation

Close to ~ 6 weeks turnaround time !!


Are we doing robust gate level verification ?

Challenges Or …Opportunities ..!!

Early enablement Adding Robustness

TM

3 2
Defining the right scope…
Static Timing Analysis Static Analysis
 Timing Signoff Across all Process Voltage and Temperature range
 Correct design constraints for all possible Functional/DFT modes

Gate Level Verification Dynamic Analysis


 To model the delay dependencies on Verification Code
 Missing Synchronizers
 Glitches
 Verifying the above applied timing constraints
 Correct design constraints for all possible Functional/DFT modes

The Design will run at required performance of 200 MHz or 190 MHz,
is to be answered by STA Analysis; Needs no Verification.

TM

4
Design Timing Basics

Timing Checks Data

 Setup Timing
FF1 FF2
 Hold Timing
 Other Race Condition
(data to data check)

 Early/Late Modeling Clock


 Technology Derates

1 2 Timing Constraints
To be Verified
 Multi-Cycle Paths
 False Paths
 Asynchronous Clocks

GLS Tool generates “X” if data comes in setup/hold window


Setup-hold window
TM

5
5
Why current GLS verification is not absolute ?

Scenario 1
Single Analysis Mode Timing SDF

There could be no timing violation in single mode, but there is in actual and
being missed in Signoff condition.

Timing is still not met, and will cause Yield Drop.

1 2 3

GLS Verification
Timing
Exception

Multicycle Path of 2 is applied


(which is incorrect)

TM

6
6
Why current GLS verification is not absolute ?

Scenario 2
Dependency on Functional Pattern

It doesn’t fail unless total delay is lying in setup/hold window of capturing flop.
1 2 3
Multicycle Path of 2 is applied
(which is incorrect)
Pass (bcs)

Possibly a check by value Pass (wcs) .. !!


(Robust .. ?)

check by delay value Fail

Setup/hold window

TM

7
7
ABSOLUTE GLS VERIFICATION
Early Simulation of Design Timing Constraints

Self Simulating Environment

Delays are modeled to make GLS fail if timing constraints are wrong !!

A. False Path (through static pins), let cell delays delayed by huge number.

B. Clocks are assumed asynchronous, let them have varied latencies.

C. Multicycle Path, let total data delay just meet the first edge of capture flop.

Simulated SDF

TM

8
8
Modelling the default delays

Data Cell delay


A
Two Attribute of a cell delay Z
• Delay
B
• Functional Arc definition

Default data delays are modeled to Technology Unit Cell Delay.


(For e.g. for C55, it is 110psec)

Clock Cell delay

ZERO !!
Making all the clock edges to arrive at the same time at all the sinks.

TM

9
9
Default Design Timing and Logic Function

Default Environment

Tech

Tech

Tech

Clocking

TM

10 7
Asynchronous Clock Constraints Modelling

Missing Synchronizers in Reset Domain Crossing.


GLS will certainly fail if this asynchronous system FAILS, Due to HOLD Violation.

Reset
Block rb

1 IRC
1 1 1
AUX1
1 1 1
AUX2 Rest of the design
1 1
PLL1
1
PLL0

Technology annotated buffer delay 1

TM

11
11
Asynchronous Clock Constraints Modelling

IP Async clock bug


GLS will certainly fail if this asynchronous system FAILS, Due to HOLD Violation.

Config 1
Baud Clock
IP
IPG Clock
1 1 1

Config 2

1 1 Baud Clock
1
IP
IPG Clock

TM

12
12
Multi Cycle Path Modelling

Required Time (STA) : 2T


Tech
Mod

Mod

Absolute Fail or PASS


Pass if it’s a 2 cycle path
Fail if it’s a single cycle path

Setup/hold window

Individual Buffer Delay in the fanin/fanout cone are adjusted to make path lie exactly in 1 Time period

TM

13
13
False Path Modelling

False through below RED Signal

Tech
Tech

1 11 1 11 Tech

False to the frequency limit – Signal is buffered upto the lowest working frequency

TM

14
14
Absolute GLS SDF Generation
ETS Timing Shell with constraints

Clock Cell/Net delays


annotated to ZERO

Absolute Failure
Data Cell + Net delays
annotated to technology
delay

Wrong Constraints
All static (false) pins are
annotated max delay

Timing Clean
All MCP pins adjacent cell Modeled SDF
Final Timing
delays are modified to edge of
single cycle
Check generation

TM

15
15
The New Design Flow

RTL Verification

FE Integration Functional Verification

Gate Level Netlist and


Simulated SDF
Elaborated Mapped
Netlist

TM

16
Even further early look ahead .. ??

How about Gate level verification at IP level itself ??

IP level verification dominates the SOC verification for internal functionality


(due to its diverse scope)

POSSIBLE .. !!

TM

17 2
Clock Glitch Modelling
Future Road Map (Under exploration…)

A A
Z Z
B B

A A

B B

Z
Z

AND and OR Type gating usually get gating setup/hold check.


What about other clocking cells ?

Glitch modelling will be done only for clock logic and the un-timed signals (SE, Reset)

Data Glitch is anyways ensured by delay glitch signoff done later in STA the design cycle
(To be checked for glitch problems and efficiency)

TM

18
18
Clock Glitch Modelling
Future Road Map (Under exploration…)

Re-convergent Path Glitch Modeling

Reset
Or
Clocking Logic

Any problem in RTL verification ?

se
Or clk

Different re-convergent paths are modeled to different delays

TM

19
19
DFT Pattern generation and GLS verification
Future Road Map (Under exploration…)

DFT GLS Pattern verification

Final SDF are modeled to the difference in single timing


mode and the signoff timing mode.

Will lead to early debug, saving tester time.

TM

20
20
Conclusion

 In Past few NPI’s GLS was enabled immediately after 1st synthesis run

 We caught 2 bugs in the clock path from the early enabled Absolute GLS verification

 Promising to get more bugs.

Fast and Robust,

The Absolute GLS Verification Flow


It’s worthy..!!

TM

21
Backup Slides

enable

100 MHz
200 MHz

Figure 1(A) Valid Multicycle Path (100MHz) as achieved by enable

Module_en

100 MHz
200 MHz

Figure 1(B) Valid Multicycle Path (100MHz) as achieved by data path gating

TM

22
22
Backup Slides

Launch Capture

Clock Clock
gate gate

Figure 2 : Possible 2 level of back to back logical check on shaded flops

TM

23
23
Q&A

TM

Thank You

www.Freescale.com

You might also like