in our design we use a number of generated clocks, i.e. the main clock is for instance divided by 13339. The clock dividers are specified as generated_clock in the SDC file. Now, we would like to build a clock tree for the main clock including the generated clock domains. This should be possible with the ThroughPin feature of the clocktree spec. However, we are unsure of how to correctly define our scenario using ThroughPins. Do we actually need to specify a ThroughPin entry for every bit of the counter that divides the clock? Or is this the wrong approach anyway?
We have tried some approaches by now but still cannot achieve timing closure on our design, so we would be thankful for any suggestions and background explanations.
Have you tried using the automatic clock tree specification generation available in encounter?
If not, please refer the user manual/ command reference manual for createClockTreeSpec or clockDesign -genSpecOnly
The automatic clock tree specification determines the ThroughPins automatically based on the timing constraints.
Please review the generated ctstch file and modify according to your needs.
Hope this is helpful.
thank you for your suggestion. We tried that but the ThroughPin section was empty in the resulting file. However, with this we were unable to reach timing closure.
Have you checked the clock trace file?
This can be generated using ckSynthesis -check [-forceReconvergent] after specifying the cts spec file.
The trace file would give a good idea as to how the tool traces the clock path based on the AutoCTSRootPin definitions in ctstch file.
Sometimes the ThroughPins are not "explicitly" defined in the ctstch file created automatically. But this can always be verified by checking the trace file.
Thank you for your hints, that was very helpful - we considered the ThroughPin spec to be mandatory for every generated clock, this does not seem to be correct.
We checked the clock trace, it shows that the registers in questions are sinks of the clock tree, so you are right, the ThroughPin does not seem to be necessary here. However, we do not reach a setup WNS better than -3 ns for the generated clock during postCTS and postRoute optimizations - even though there is enough space and the divided clock is really slow.
Do you have any other suggestions where we might locate the problem? According to the clock trace, the clock tree does not seem to be the problem.
I would suggest next running the Timing Debugger. By looking at the failing paths visually, you may see what the issue is. Make sure to look at the Timing Interpretation tab - this will flag some potential issues as well.