Synopsys Design Constraints

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

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

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

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

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

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

  1. set_driving_cell

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

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