Max tran violations

When Encounter does not fix violations, it is usually due to the fact that fixing the violation would either violate some other higher priority constraint or the design is overconstrained. For example, if the violating transition is on an output port, check the load on the output port in the constraints file. It may be that the load is so high that the design is incapable of driving the load to the desired transition time.

• Check your constraints file to see if you are overconstraining the design.
• Use "setOptMode -verbose true". This tells Encounter to give a more detailed report during optimization.

Thanks Scrivner. I used the -verbose true options and it is excluding clock nets from optimizing. *info: Start fixing DRV iteration 1 ...
*** Starting dpFixDRCViolation (383.5M)
*info: 4 don't touch nets excluded
*info: 17 io nets excluded
*info: 264 clock nets excluded
*info: 490 violations may not be fixable:
*info:     490 violations on clock net (remark C).

Why is the tool ignoring clock net from optimizing? Thanks again for your quick and helpful response. 

The tool assumes that you are happy with the performance of your clock tree and that it is optimized for skew. If it were to try to change the clock tree, it will change the skews and possibly create new timing violations. If you want to repair transitions in the clock tree, you can try using the ckECO command. But fixing transitions in the clock tree may make skew worse.

I usually let the clock tree violate transition constraints in favor of better skew results. Unless the clock tree transitions are outrageously slow (which they shouldn't be since CTS should not let them), I leave them alone.

I just wanted to add that it's common practice to have a tighter transition constraint on the clock trees than the rest of the design. For example, maybe the max tran for the design is 900 ps, but for my clocks I want 400 ps. This is specified in the clock spec file:

SinkMaxTran     400ps
BufMaxTran      400ps

The report generated after CTS will show if these transition limits were met. Even if they violate slightly, we usually move on because we know the transition is tight in the first place. I don't think violations of the 400ps clock spec would show up in the general transition violation report, so you wouldn't have to filter them out.

- Kari

 Pay attention to the mark behind the transition violations in the report.

The one marked as dont_touch_net and clock_net will be ignored by the opt enginee.

 You need to double check with your logical design engineer .

Some non clock tree instance will be marked as clock tree so that the transition violation wont be fixed.

I usually manually fix this kind of transition violation.