• Skip to main content
  • Skip to search
  • Skip to footer
Cadence Home
  • This search text may be transcribed, used, stored, or accessed by our third-party service providers per our Cookie Policy and Privacy Policy.

  1. Community Forums
  2. Digital Implementation
  3. Multi point CTS implementation

Stats

  • Locked Locked
  • Replies 5
  • Subscribers 92
  • Views 19385
  • Members are here 0
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Multi point CTS implementation

vamsi611
vamsi611 over 11 years ago

I have a netlist and def with single clock port clk.

I want to implement multi point cts with 4 clocks(clk1,clk2,clk3,clk4).They are equilent to clock port clk.

What are the flow steps in encounter to  implement this multipoint CTS.

(How can create 4 new clock ports and remove old clock port clk, how to take care of clock connectivity in the design and implementation of multi point CTS)

  • Cancel
Parents
  • fitz
    fitz over 11 years ago

    Been there done that , but I would not do it the same way again.
    We used multiple  discrete  DLL drops points for a main clock in a physically large block.
    Basically we would run a regular placeDesign and then disconnect all of the clock leafs and reconnect them to the closest DLL with a tcl script.
    All fun and games until you get to timeDesign and realize you are now essentially randomly crossing clock domains.
    Even more fun when you add clock gating and  DFT scan reorder mode to the mix.

    Next time I would restrict the multiple clock domains to follow the logical hierarchy and the placement floorplan fences.
    i.e. moduleA has a placement fenceA and uses clkA , moduleB has a placement fenceB and uses clkB etc. etc.
    That way the manual clock edits to the verilog are simple you can predict / anticipate potential domain crossings timing issues.

    The KISS principle rules ( Keep It Simple Stupid ) especially where clock is concerned.

    First try a single central clock drop point, if your block is not too convoluted clockDesign with tuning can do a very good job.
    If you are trying to reduce total insertion delay,  manually route the top level clock tree root net to a central location in each of your hierarchical blocks.
    You will have to run some spice simulations to determine the optimal root routing style, start with, top two metals, double wide, quad via, double spaced.

    Shawn


     

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
Reply
  • fitz
    fitz over 11 years ago

    Been there done that , but I would not do it the same way again.
    We used multiple  discrete  DLL drops points for a main clock in a physically large block.
    Basically we would run a regular placeDesign and then disconnect all of the clock leafs and reconnect them to the closest DLL with a tcl script.
    All fun and games until you get to timeDesign and realize you are now essentially randomly crossing clock domains.
    Even more fun when you add clock gating and  DFT scan reorder mode to the mix.

    Next time I would restrict the multiple clock domains to follow the logical hierarchy and the placement floorplan fences.
    i.e. moduleA has a placement fenceA and uses clkA , moduleB has a placement fenceB and uses clkB etc. etc.
    That way the manual clock edits to the verilog are simple you can predict / anticipate potential domain crossings timing issues.

    The KISS principle rules ( Keep It Simple Stupid ) especially where clock is concerned.

    First try a single central clock drop point, if your block is not too convoluted clockDesign with tuning can do a very good job.
    If you are trying to reduce total insertion delay,  manually route the top level clock tree root net to a central location in each of your hierarchical blocks.
    You will have to run some spice simulations to determine the optimal root routing style, start with, top two metals, double wide, quad via, double spaced.

    Shawn


     

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
Children
No Data

Community Guidelines

The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.

© 2025 Cadence Design Systems, Inc. All Rights Reserved.

  • Terms of Use
  • Privacy
  • Cookie Policy
  • US Trademarks
  • Do Not Sell or Share My Personal Information