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.

Clock Statements

"create_clock"
"create_generated_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_uncertainty"
"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.

False path Specifications

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.

Specifying operating conditions

“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.

Specifying Ideal Networks – No optimizations required

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.

set_input_delay

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.

set_max_delay

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.

set_driving_cell

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

set_load

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.

Recommended for you

17 Comments

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.

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.

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.

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.

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.

Can you please recommend what is the best approach to decide on input_delay for a signal driven by clock having period say “t” ns and set-up time of the flip flop is “tsu” ns? Is it always (t-tsu) OR any specific % of t? either 50% or 60% of t?

It’s not always a percentage. You need to arrive at the value while timing budgeting. i.e. if you are specifying the delay for a block’s pin, you need to see where the synchronous input is coming from and account for that external delay with respect to clock edge.

You may go with a % value if you do not have clarity on the environment.

Question is do you have any timing requirement for your chip? If yes, you need to verify that the chip timing is as you intended for the design. SDC is a method wherein you can specify the timing constraints to various stages of the flow, for implementation and analysis.