Synopsys Design Constraints

Timing closure is the big whale for most P&R designers. You get it done, and then you can wash your hands off all those annoying designers and get to work cleaning up and beautifying your layout. So I thought of starting my P&R cheat sheet with an introduction to timing closure, and what best to address than the mighty SDC constraints, the bane of all our existence. You get the SDC right, you win half your battle. But it is not so simple. SDC you get from the synthesis tool might have very well served its purpose there, but to get it do a pretty good job in layout requires some time spent on understanding and iterating the design.

For the newly anointed, what exactly is the SDC? Its expands to Synopsys Design Constraints, and is how we specify design intent, especially timing intent of the design so the P&R tool can do a good job of meeting them.

So what does SDC specify? Let me list them out in the order of importance for a P&R engineer.

  1. Clock Statements
  2. "create_clock"

    These are the single most important constraints in any SDC. You HAVE to get the clock statements correct. You might have to go talk to the synthesis guy and the designer over and over again to get this correct. They tend to specify clocks wherever they please. Do not assume it correct if you see 40 main clocks and 60 generated clocks in your design. See if you can get it simplified. Make sure you have a pretty good understanding of the clock structure of the design. Ask for a clock diagram.

    You will probably also have some extra statements with respect to the clock, like
    "set_clock_transition -rise/fall "

    Do not worry about these. You might have to worry about the uncertainty in a timing critical design, but that is not going to be a major road block in your flow while you are trying to clean up the timing closure flow. set_clock_uncertainty ensures sufficient margin for your design and it is important to meet your timing with some uncertainty.

  3. False path Specifications
  4. set_false_path statements are your friends. However not specifying any valid false path can make your P&R tool try to fix bogus violations and go overnard or area and runtime. So before you start the P&R, ask which clocks are synchronous to each other, and which clocks aren’t. Some examples.

    set_false_path -from [get_clocks clock1] -to [get_clocks clock2] set_false_path -from [get_ports port1]
    Do a placement and if you see a lot of violations with big numbers, dump the reports on to the designer. See if any are false paths the tool does not understand.

  5. Specifying operating conditions
  6. “set_operating_conditions” statements specify the operating conditions for the design. With the advent of multi-corner,multi-mode algoriths, you might be specifying more than one operating condition statements nowadays. Take note of the -analysis_type used by the P&R. Usually STA tools use on_chip_variation, but P&R could use bc_wc as a default. See which analysis_type you should use for your process and library.

  7. Specifying Ideal Networks – No optimizations required
  8. The SDC from synthesis may also give you some “set_ideal_network” statements. My suggestion is to remove these, and use “set_dont_touch” in your flow for valid ideal networks (like analog nets you don’t want buffered irrespective of the transition violations). You will probably see ideal_network statements on clock, reset etc. You should set the clock in your flow as ideal with tool specific commands. TCL based tools like ICC & Encounter will let you use “set_ideal_network” in the flow. Rest of the high fanout nets which were not synthesised in synthesis should get tree/buffer structure while placement.

  9. set_input_delay
  10. You will probably see a lot of these as well. Usually harmless, but see if they are not to scale. Sometimes designers can set an input_delay on each port irrespective of functionality or the relevant clock. Check for such flow issues.

  11. set_max_delay
  12. You usually see it in a couple of pins where the flow warrants it. I see that in some tools, the tool cannot honour these constraints if the actual cell pin is not mentioned. The input SDC can have these constraints on hieracrchical module ports. If you see that the constraint is not met, change the constraints by tracing the actual driver and fanin of the ports.

  13. set_driving_cell
  14. If the synthesis specifies some driving cell for input ports, and you will also get these in your SDC from synthesis.

  15. set_load
  16. The load specification for output ports are set using this command. set_driving_cell and set_load are commands to make sure that the interface to your P&R block will not cause transition or capactiance violations when connected to external circuitry in a chip.

There are countless other commands in SDC format, but these are the most common. Try to simplify your SDC as much as possible, and you can pin point the errors and issues easier.


  1. Ritesh

    Hi Sini,
    Thanks for touching a basic topic, want to request if you can add following data also, probably it might help to understand this topic much better :-

    1):- clock period margin number for Synthesis Vs PD.

    2):- Clock handling in multimode, like if a clock is having three or four frequency target like turbo, func & scan, how does tools is going to handle this & what is expected out from SDC for these mode. probably add these numbers from your current SDC would help to make these important decision.

    1. mm Sini Mukundan

      STA tool will report clock gating hold error on both i/ps I presume. Fixing the STA error isn’t the solution. Best not to do something like that with regular gates. IF you have legitimate design requirement to AND the two clocks, use a latch to get some control on the signals.

    1. mm Sini Mukundan

      There are all considered hard constraints. However, the tool may not be able to meet them and in that case, it will be reported as violations, rather than the tool giving up the entire run.

  2. Gautham


    I started learning SDC recently. I have a single bit signal crossing from one clock domain to another. Obviously a synchronizer is used. Can you please let me know how to constrain the path from source clock domain to destination domain.


  3. Marjan

    Hi Sini,
    Should I extract this sdc file from dc compiler by using write_sdc command, and then read it in the IC compiler? Doesnt tool know these constraints itself?
    I also have some max cap violations, how can I fix them? Can I add or change some constraints in this file?
    I would appreciate your help in advance.

    1. mm Sini Mukundan

      Yes. But you need to review and the sdc before using it in ic compiler.

      Look at the cause of the cap violations. If they are due to drive strength of the driver, you can chose to add dont_use constraints for low drive strength cells. Else you may have fix each case. Limiting net lengths may also help.

  4. dev


    If I have two set_load commands with different loads; first one for [all_outputs] and second one for just one clock output port, would the second override the first one?


Leave a Reply

Your email address will not be published. Required fields are marked *