• 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. Two sdc files and one design

Stats

  • Locked Locked
  • Replies 4
  • Subscribers 92
  • Views 16789
  • 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

Two sdc files and one design

tsahi
tsahi over 16 years ago
Hi friends,

My name is Tsahi, I am electronics student and beginner in place and route field.

One of the inputs of place and route is the timing constraints (sdc file).

In our mini project there are two sdc files:

1)  Pre cts  SDC file

2) Post cts SDC file

Can someone explain me why is the reason to make to two files and not use just single constraint file.

I attached the files to one zip file in comparing to each other (the left is pre cts, on the right hand post cts) and changes are marked.

Thanks,


Tsahi.
sdc.zip
  • Cancel
  • BobD
    BobD over 16 years ago

    Hi Tsahi,

    Typically, separate preCTS and postCTS files are used to adjust the values associated with "set_clock_uncertainty" and sometimes the set_min/max_delay values to account for propagated clocks.

    However, in your case (thanks for the attachment, it is very helpful) it appears that the postCTS SDC contains the following types of additions:

    1. Removal of "set_clock_transition" statements

      Removing these constraints should *not* be necessary in Encounter because
      postCTS the actual propagated clock values should override the SDC-asserted transition times.

    2. Addition of "set_propagated_clock" statements

      Encounter will automatically append "set_propagated_clock" statements for each clock tree you build within Encounter. So long as your create_clock target == your AutoCTSRootPin, manually propagating the clocks postCTS with "set_propagated_clock" statements isn't necessary. If for some reason the create_clock target does *not* align with your AutoCTSRootPin, adding set_propagated_clock statements for each logical clock is necssary and may be why these are added.

    3. A single addition of a set_clock_latency statement for one of the clocks.

      The postCTS SDC contains "set_clock_latency 2 [get_clocks wb_bus_clock]" so that the values in the postCTS file for set_min/max_delay statements are still valid when the internal clocks have been propagated.

    Hope this helps,
    Bob

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • tsahi
    tsahi over 16 years ago
    Dear bob,

    Thank you for "speedy" answer.

    From your point of view :

    1) Is these really minor changes between the pre and post sdc's files ?

    2) Does these minor changes can affect the design (any design), if it does what is it

    meaning (in general of course)?

    Thank you for the kind attitude.

    Regards,
    Tsahi.

     
    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • BobD
    BobD over 16 years ago

    You're welcome!

    The first 2 items are minor (or perhaps meaningless depending on the caveats I mentioned in italics above). The 3rd item (set_clock_latency) is actually quite important and if not included it would invalidate your IO timing.

    Thanks,
    Bob

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • Kari
    Kari over 16 years ago

    I just wanted to mention that the set_propagated_clock statements can also be important if you're not using Restore Design to bring your data up in Encounter. Most of the time, we read in verilog, def, and SDC (Import Design, defin, loadTimingCon) and if it's a postCTS design, we need to have the set_propagated_clock lines in the SDC file. So we always have a postCTS SDC file, even if that's the only difference. (We call the preCTS file design.ideal.sdc and the postCTS file design.prop.sdc.)

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel

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