wafer.space Community - Slew and Cap Violations

LibreLane says (https://librelane.readthedocs.io/en/stable/usage/timing_closure/index.html): "Violating maximum capacitance and maximum transition constraints are OK if you don’t have setup/hold vios. It is always good to check them as they are indicators of design issues. For example, a high capacitance on a net means high fanout and/or long interconnect. Also, high transition time means a high capacitive load and leads to a higher short circuit power and delays." My design is passing timing, however I have massive slew and capacitance violations from: bidir_PAD[13] (inout) Fanout: 1 Cap: 3.530755 Slew: 99.174812 Delay: 54.912 Time 72.9128 This is roughly the same for every bidir_PAD. I've been trying to make the pad capacitance more realistic to the .lib files with no luck. Any ideas? (edited)

That's unreadable ...

2:40 p.m.

put the full timing report as a .txt not pasted like that because with discord reformating it's impossible to read it unless you already knows what it says.

2:40 p.m.

Also post a link to your repo so we can refer to the code and config.

@tnt It was tab delimited, so I thought it was semi-redable sorry about that. Updated with a cleaner version.

2:44 p.m.

My code is not open source, I'm using the default project-template sdc and config. The exception is a 90ns clock. (edited)

Trevor Peyton

LibreLane says (https://librelane.readthedocs.io/en/stable/usage/timing_closure/index.html): "Violating maximum capacitance and maximum transition constraints are OK if you don’t have setup/hold vios. It is always good to check them as they are indicators of design issues. For example, a high capacitance on a net means high fanout and/or long interconnect. Also, high transition time means a high capacitive load and leads to a higher short circuit power and delays." My design is passing timing, however I have massive slew and capacitance violations from: bidir_PAD[13] (inout) Fanout: 1 Cap: 3.530755 Slew: 99.174812 Delay: 54.912 Time 72.9128 This is roughly the same for every bidir_PAD. I've been trying to make the pad capacitance more realistic to the .lib files with no luck. Any ideas? (edited)

(my understanding is that this advice was intended for sky130; I do not know how well it applies to gf180mcu)

DESIGN_REPAIR_MAX_SLEW_PCT, DESIGN_REPAIR_MAX_CAP_PCT, GRT_DESIGN_REPAIR_MAX_SLEW_PCT, GRT_DESIGN_REPAIR_MAX_CAP_PCT (edit: and also limiting the max wire length) helped on my design to get better slew/cap. But that slew seems to be very large. Which corner are you looking at? (edited)

All of them!

Meinhard Kissich

DESIGN_REPAIR_MAX_SLEW_PCT, DESIGN_REPAIR_MAX_CAP_PCT, GRT_DESIGN_REPAIR_MAX_SLEW_PCT, GRT_DESIGN_REPAIR_MAX_CAP_PCT (edit: and also limiting the max wire length) helped on my design to get better slew/cap. But that slew seems to be very large. Which corner are you looking at? (edited)

Awesome, didn't know about those, I'll give them a try.

12:52 a.m.

So an update (still in progress): I removed the max_capacitance from the project template SDC and that seemed to help significantly, looks like things are falling back to the .lib files. Is there a major downside to doing this?

12:58 a.m.

Also, this line is from the 7t std cell:

# update these
set ::env(OUTPUT_CAP_LOAD) "72.91" ; # femtofarad from pin I in liberty file

But this is being applied / 1000 to all outputs in the project-template:

set cap_load [expr $::env(OUTPUT_CAP_LOAD) / 1000.0]
puts "\[INFO] Setting load to: $cap_load"
set_load $cap_load [all_outputs]

This seems very low to me for output cells. I upped it to 25000 to have a cap of 25 and it removes most cap violations. Again can anyone inform me if this is a very bad idea and I'm missing something? (edited)

Hi @Trevor Peyton! The default setting of OUTPUT_CAP_LOAD is intended to be used for macros, i.e., circuits that you integrate into a larger circuit. When we implement the macro, we want to consider the external capacitance, which, in the case of standard cells, could be a large buffer e.g. mcu7t5v0__buf_16. From what I see, the input capacitance of the mcu7t5v0__buf_16 is ~0.03683 pF = 36.83 fF, so I'm not sure where the exact number here comes from, but it's close enough. Now, for a chip top-level design we should set OUTPUT_CAP_LOAD to the capacitance that is actually outside of your chip, i.e., whatever your chip will drive. However, if we think about it, from the point of view of the implementation it doesn't really matter what we set OUTPUT_CAP_LOAD to because OpenROAD can't resize that path anyway. The reason is the following: core -> pad -> port -> external capacitance OpenROAD can resize all of the paths inside the core. However, once a signal goes to the pad, that's it. The output of the pad is the bondpad, so nothing can be changed in that path. Given that we set a very low output cap with 72.91 fF, and that the pad is a very strong driver (max cap of 30pF in the libs), I'm surprised that you see violations in this path. Also, increasing OUTPUT_CAP_LOAD should make it harder to meet the maximum capacitance limit.