The Automatic Generation of Merged-Mode Design Constraints Subrangshu K. Das, Texas Instruments Ajay J. Daga, FishTail Design Automation Aishwarya Singh, Texas Instruments Vikas Sachdeva, FishTail Design Automation In this presentation, I am going to talk about a joint work between TI and FishTail to automatically create merged-mode design constraints for a very complex multi-media IP --- built almost 80-85%s grounds up

Constraints Development Challenges Number of operating modes supported in a design today has increased tremendously (>20) Each operating mode could be unique in terms of its timing requirements Constraints designer needs to understand all these “unique” timing requirements and capture them in the constraints If we step back and really think why developing timing constraints have become extremely difficult, it is really because of the fact that “Number of operating modes…..” This is not just limited to functional modes but test-modes as well. In reasonably complex IPs using core-based testing, the number of modes could easily be between 20-30 Each new operating mode brings along with it a unique set of timing requirements - -different from the rest o fthe modes

Prior Solutions Single-mode implementation flow Using most timing-critical “operating” mode E.g., if freq. clkb > freq. clka, SDC-1: set_case_analysis 1 sel Single timing-critical mode is extremely rare Multi-mode implementation flow Separate constraint files for each “operating” mode SDC-1: set_case_analysis 0 sel SDC-2: set_case_analysis 1 sel Easy to create but tool run-times become prohibitive beyond 2-3 modes (on complex IPs) Merged-mode implementation flow Created by collapsing constraints for multiple “operating” modes into one No case-analysis SDC-1: set_clock_groups –logically_exclusive –group clka –group clkb Effort intensive and error-prone No easy way to review FF1 FF2 clka clkb 1 sel Merged-mode implementation flow No case-analysis: This could be highly pessimistic in many cases like for example if clka = 100 MHz and clkb = 150 MHz, the path would get timed at 200 MHz! Effort intensive  because it requires extensive design knowledge! So what is the ideal solution? Ideal would be if we could feed in SDC-1/SDC-2 (i.e. constraints for all the operating modes supported by the design) to a tool, which can then generate merged-mode SDC-1 constraints automatically – that we can then feed into P&R and STA tools! Ideal Solution: Designer creates individual mode SDC files and a tool automatically collapses them and also generates the clock-exceptions!

Key Components for “automation” FF1 FF2 clka clkb 1 sel Ability to define boolean condition required to propagate a clock signal from one node to another Ability to calculate dot-product between two sets of boolean expressions to see if 2 clocks can interact or not False-path if dot-product == 0 TI and Fishtail collaborated to enhance Focus (formal tool) to handle above and generate exceptions automatically during merging

Enhancements in Focus Mode-table Case-analysis to block clock propagation Clock-propagation false-path Logically-exclusive Partially-exclusive

Automated Constraints Generation Flow

Focus Results Design Statistics No missing / erroneous exceptions Complex IP with ~1.6 Million instances Multiple clocks (~25) with highest clock frequency being 266 MHz ~30 operational modes including test modes Merged-mode # of set_clock_sense (stop propagation) # of generated clocks (partially-exclusive) # of clock exceptions # of case-analysis generated Run time Memory Usage Capture 17 30 133 2 4 hr 9.2 GB Func-PBIST 56 1 3 3 hr 6 min 9.37 GB Shift 12 8 107 3 hr 16 min 9.21 GB P1500 61 248 4hr 40 min 9.34 GB No missing / erroneous exceptions Constraints un-touched in the course of the entire P&R and STA flow

Focus helped catch design bugs! DFT clock implementation is complex and is custom-built for every IP Verifying DFT clock implementation is difficult using conventional techniques for scenarios like: Ensure ATPG shift and ATPG capture clocks do not interact in any of the operating modes No timing paths in the design between 2 ATPG capture clocks (programmed for simultaneous capture) in TFT However constraint designer assumes above when writing constraints Design implementation bug can easily get un-detected till late in the design or worse after Si! Focus formally proves if 2 clocks are mutually-exclusive and then generates clock-exception in merged SDC Absence of clock-exceptions (clock-crossing report) with help of clock-propagation/interaction reports helped catch implementation bugs (>5) DFT clock implementation is complex and is custom-built for every IP Clock-crossing report:  Implementation did not match intent

Conclusions Described how Focus was used to Automatically generate merged-mode constraints from mode-table spreadsheet Automatically generate clock-exceptions to remove pessimism Helped reduce constraint development cycle-time by a factor of 2-3X No last-minute heart-aches due to constraint bugs!!  Described how Focus helped in catching implementation bugs that could have been missed in conventional verification

Thank You

Mode-table spreadsheet Configuration ports Operating Modes Configuration registers Back

Case-Analysis to Block Clock Propagation FF1 FF2 CLKA CLKB 1 mux1 1 1 SEL1 MODE1 MODE2 SEL1 1 SEL2 SEL2 1 Modes being Merged MODE1 MODE2 set_case_analysis 1 mux1/s Back

Clock Propagation False-path FF1 FF2 CLKA TCLK 1 mux1 1 mux3 TESTMODE CLKB 1 mux2 SEL set_clock_sense –stop_propagation –clocks {TCLK} [get_pins mux3/b] Back

Logically-Exclusive Clocks FF1 FF2 AUXCLK0 ICG PICLK0 AUXCLK0 1 mux1 SE = 0 SE SE = 1 PICLK0 – functional clock AUXCLK0 – shift clock SE – scan enable set_clock_groups –logically_exclusive –group AUXCLK0 -group PICLK0 Back

Partially-Exclusive Clocks CLKA CLKB FF1 FF2 FF3 FF4 1 mux1 create_generated_clock mux1/Z –name clka_1 –master_clock CLKA create_generated_clock mux1/Z –name clkb_1 –master_clock CLKB set_clock_groups –physically_exclusive –group CLKA –group CLKB Back