• 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. SDC file-HOLD and Setup Time

Stats

  • Locked Locked
  • Replies 14
  • Subscribers 90
  • Views 23013
  • 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

SDC file-HOLD and Setup Time

archive
archive over 18 years ago

Hi,
I am just starting using the nano encounter tool. I just wonder if the sdc file we give to the encounter tool should be the same as SDC file we give to the RTL compiler?
I want to connect my synthesized block to a memory with specific setup hold time. Does anyone has an idea how to give the encounter tool the specific setup time and hold time? how to put a constrain on its output and input port for setup and hold time?

Thanks,

Houman
 


Originally posted in cdnusers.org by houmanh
  • Cancel
Parents
  • archive
    archive over 18 years ago

    Hi,

    In my sdc, there are "if { [info exist some_variable_name] } { ... #for RTL ...} else { ... # for gate level ... }

    The different can be due to many reasons, like uncertainty, different in clk pin name (e.g. for RC, in RTL it is called clk, but in gate it can be other names), negative hold check for set_clock_gating_check (RC or primetime might not support negative clock gating check), constraint related to compression logic for ATPG, or mbist (does not exist in RTL), generated clock for RTL (RC does not support generated clock appear in the dotlib, but FE is able to support) etc etc.

    I usually load in another SDC constrain file during P&R (loadTimingCon -incr). What is in this file has to do with the strategy you want to due with timing closure etc. For example, I will tune some clocks during physical synthesis, or force keep some cells, or disable some timing arc (e.g. due to FE does not support rise/fall_{from/to/through} yet. Just be careful that what should not be in the additional SDC when performing sign-off STA.

    For your other question on connect a block to the memory, I think it is related to "set_output_delay -min/max" and "set_input_delay -min/max". Consider adding a virtual clock to the I/O.

    Regards,
    Eng Han


    Originally posted in cdnusers.org by EngHan
    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
Reply
  • archive
    archive over 18 years ago

    Hi,

    In my sdc, there are "if { [info exist some_variable_name] } { ... #for RTL ...} else { ... # for gate level ... }

    The different can be due to many reasons, like uncertainty, different in clk pin name (e.g. for RC, in RTL it is called clk, but in gate it can be other names), negative hold check for set_clock_gating_check (RC or primetime might not support negative clock gating check), constraint related to compression logic for ATPG, or mbist (does not exist in RTL), generated clock for RTL (RC does not support generated clock appear in the dotlib, but FE is able to support) etc etc.

    I usually load in another SDC constrain file during P&R (loadTimingCon -incr). What is in this file has to do with the strategy you want to due with timing closure etc. For example, I will tune some clocks during physical synthesis, or force keep some cells, or disable some timing arc (e.g. due to FE does not support rise/fall_{from/to/through} yet. Just be careful that what should not be in the additional SDC when performing sign-off STA.

    For your other question on connect a block to the memory, I think it is related to "set_output_delay -min/max" and "set_input_delay -min/max". Consider adding a virtual clock to the I/O.

    Regards,
    Eng Han


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