Stats

  • Locked Locked
  • Replies 3
  • Subscribers 90
  • Views 15357
  • 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

Clock path crosses data path

archive

Hi,

Would like to know how the following can be handled in Encounter flow.

The data path is from a FF to another FF, and both FF are clocked by the same clock. In the data path, there is an OR gate. One of the input of the OR gate is from a clock source. The other input of the OR gate is data.

As the OR gate is part of a clock network, the placer does not optimise it. Hence, during optDesign, due to the high-fanout of the OR gate, the delay of the OR gate is 200+ns. This result in a huge violation, and the QOR become bad.

I have tried to use "setAnalysisMode noclksrcpath", but since the source of this path is data, the option does not effect.

I workaround by setting a multicycle path from these 2 FFs during physical synthesis, and then remove it before clock tree synthesis. However, is there a better solution for this type of design? Thanks.

Regards,
Eng Han


Originally posted in cdnusers.org by EngHan
Parents

  • Hi ,

    Let me share my view on the above issue,

    I divide this in two two topics like FE-CTS and FE-IPO.

    In the Case of FE-IPO as we know that
    The opt command does not affect the Clock nets. In your case "OR" gate has such problem. So you can not use if it is recognised as a Clock path.

    Work around : Try to make a special SDC with out clock defination and run "optDesign" command for correcting only DRVs  by using only "MaxFanout" switch .

    FE-CTS handling case :  use "fixClockExcludedNetDRV" after exclusing data pin .
    (or )
    We can perform hight fanout synthesys (FE-CTS) , need to prepare new ctstch clock specification file and specify a clock defenation at the output of "OR" gate and run "ckSynthesis" .
    Note on this run : we should not give any clock attributes on such nets and NO route. 
    use : -dontFixAddedBuffers ,"-noAddClockRootProp" "-noFixedNonLeafInst" and Route Clk NO (spec file)etc .

    If you have trace problem on OR gate use "set _case_analysis" in spec file .

    Regards,
    Mohan Ch


    Originally posted in cdnusers.org by mohanch007
Reply

  • Hi ,

    Let me share my view on the above issue,

    I divide this in two two topics like FE-CTS and FE-IPO.

    In the Case of FE-IPO as we know that
    The opt command does not affect the Clock nets. In your case "OR" gate has such problem. So you can not use if it is recognised as a Clock path.

    Work around : Try to make a special SDC with out clock defination and run "optDesign" command for correcting only DRVs  by using only "MaxFanout" switch .

    FE-CTS handling case :  use "fixClockExcludedNetDRV" after exclusing data pin .
    (or )
    We can perform hight fanout synthesys (FE-CTS) , need to prepare new ctstch clock specification file and specify a clock defenation at the output of "OR" gate and run "ckSynthesis" .
    Note on this run : we should not give any clock attributes on such nets and NO route. 
    use : -dontFixAddedBuffers ,"-noAddClockRootProp" "-noFixedNonLeafInst" and Route Clk NO (spec file)etc .

    If you have trace problem on OR gate use "set _case_analysis" in spec file .

    Regards,
    Mohan Ch


    Originally posted in cdnusers.org by mohanch007
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.