Design Compiler(DC) Optimization commands to reduce negative slack?

Hi,
I tried to synthesize a 64-bit adder. It's pure combinational. When I set the virtual clk to 1GHz. The timing report is

And for 2GHz clock, the timing report is

They are both negative. But I think if Design Compiler uses the optimization method for 2GHz in 1GHz case, I can have a positive slack (0.9-0.62 = 0.28) for 1GHz case. It seems with proper optimization, my circuit should be able to run in 1GHz. Is this assumption valid? And if so, how do I tell DC to use the optimization method for 2GHz which it currently uses in 1GHz case.

Don't forget this is only logical synthesis, and the real go/no-go decision happens at physical synthesis.

As to why you would get the numbers you are seeing, that is actually pretty common. Synthesis will "try harder" based on how far from the target frequency it is.

Thanks for your explanation. I still have 2 questions.

1. Is it possible to tell DC to try "hard" enough to meet the target frequency, instead of giving up.
2. If my goal is 1GHz, should I use 2GHz in logical synthesis first and use its result for floor planning? Or it really doesn't matter, the negative slack would be resolved in later stage?

Your assumption is wrong.

The effectiveness off DC timing optimization is not propotional to the input frequency.
The faster the clock, the harder DC optimize your circuit. But over some range of high frequency, you will see little difference in timing result.

Your paths are external, so its timing also depended on its interfaces with outside logic.
Also, this is ideal latency clock. More things to tell at PnR phase.

But the difference between 0.92 and 0.4 data arrival time is rather big. And can I do PnR with negative slack? I thought I have to save some room for real clock latency and other physical effect in PnR stage to meet the timing requirement.
Thanks!

ammmmlol said:

Thanks for your explanation. I still have 2 questions.

1. Is it possible to tell DC to try "hard" enough to meet the target frequency, instead of giving up.
2. If my goal is 1GHz, should I use 2GHz in logical synthesis first and use its result for floor planning? Or it really doesn't matter, the negative slack would be resolved in later stage?

Click to expand...

for 1) you can try incremental optimisation. should help.
for 2) different designers will tell you different things. in the past the norm was to over constrain logical synthesis and then relax during physical synthesis. these days, with advanced nodes and all, I see folks trying to get a really close to final timing at each step. correlation is a big issue now.

ammmmlol said:

But the difference between 0.92 and 0.4 data arrival time is rather big. And can I do PnR with negative slack? I thought I have to save some room for real clock latency and other physical effect in PnR stage to meet the timing requirement.
Thanks!

Click to expand...

For ideal clock stage, you only can take care about setup timing. You can see how fast your design can run.
When doing PnR setup and hold timing needed to be met. You can adjust both clock and data path delay to meet timing requirement. So, theoricaly you can.

In case of your design, it has only external paths.
Once it is connected to top level design, you can negotiate with another blocks which it is connected to relax the constraints.

slutarius said:

For ideal clock stage, you only can take care about setup timing. You can see how fast your design can run.
When doing PnR setupand hold timing needed to be met. You can adjust both clock and data path delay to meet timing requirement. So, theoricaly you can.

In case of your design, it has only external paths.
Once it is connected to top level design, you can negotiate with another blocks which it is connected to relax the constraints.

Click to expand...

I still have some questions.
1. How do I know how fast my design can run from logic synthesis? From my example, 1GHz clock constraint gives me 0.92 data arrival time, while 2GHz constraint gives me 0.62. They give me different answers, which one should I use to determine the speed of my circuit?

2. When I do the PnR, should I use my original RTL code, or gate-level code from DC? From what I learnt, I should use the gate-level code. Can I expect PnR tool fix the timing violations in my gate-level code?

3. Right now, I have driving cell, input delay and output delay in my constraints. When it connect to top level design, I can relax the above constraints by adjusting the I/O of blocks that it connect to. So timing violation may be fixed. Is it what you meant?

Thanks!

Here are my answer, hope it helps:

1. On synthesis, timing is 0 clock latency. So, it mean that timing result is all about your data path which represented for what logic your have.
In both cases of your results, you still see timing violations, it means your logic can not work with that speed in silicon or FPGA ideally. I dont know yet about your other margin or constraint.
Once you see timing violation on synthesis result, it meant that you have to do some analysis for data path logic, clock freq and constraints that you used. Or try another technology libraries.

If you only do gate level design preparation, and you have intention to do timing optimization on PnR step, you can ignore synthesis timing violation. But I seldom do that.

2. PnR need gate level design and, Yes, PnR tool has timing optimization engine, of-course PnR tool takes care clock and data path.

3. Yes. It is possible neighbour blocks still have margin for you. Or say, their data path can be optimized more.

- - - Updated - - -

Be aware of area overhead once you use higher speed in synthesis.
And also, rerun the 2Ghz design with the constraint 1Ghz to see the timing met or not.
This can be useful sometimes.

The DC optimization mechanism is based on cost. There're 3 costs that are timing related: WNS Cost, Max Delay Cost & Endpoint TNS Cost. The Max Delay Cost will not be printed unless you set the "compile_log_format" variable. You can modify Max Delay Cost by using "group_path" command, and Endpoint TNS Cost by "group_path -weight" command. For your first case, you can try increasing the path group weight to 100, so that DC will see a -2 slack instead of a -0.02 slack, and more likely to clean up the violation.

If you're using DC2016, try "create_auto_path_groups" command.

As you're focusing on logic depth, pay attention to the Mapping Optimization phase at the beginning of compilation. The logic level of critical paths is unlikely to be well optimized in later steps(Delay Optimization, High Effort Optimization, etc.).