Unable To resolve Maximum Capacitance Violations + Understanding metada-base-ok.json

[dalyles]

Hello,

I'm running OpenROAD on the IBEX example file and I have come across maximum capacitance violations.

Below is a screenshot of my constraints.sdc file.
The default value for the clock period was 2.8ns but I set it to 3ns to overcome a setup time violation
that occured in a previous run. I also changed the clock period in metadata-base-ok.json to 3ns
in order to match with the clock period value in constraints.sdc.

The main issue that I have here is simply, in what ways can I remedy the maximum capacitance violations?

One approach I did was to go to to the metadata-base-ok.json file and try to increase the "finish__timing__drv__max_cap_limit" from -0.0575862 to 0.20. Unfortunately the result is
still the same.

I also have some further questions:

1. What parameter(s) in the metadata-base-ok.json should be tuned to fix the max cap violations?
2. Were the parameter values in metadata-base-ok.json set up by a human or automatically generated?
3. What was the reasoning behind choosing such values in metadata-base-ok.json?
4. Is there any supporting documentation that explains what the parameters mean in metadata-base-ok.json?

Thank you so much for anyone who's able to help!

[vijayank88]

@dalyles
Nothing to do with metadata-base-ok.json. Its just an metric report file.
config.mk & constraint.sdc is the files you've to tune to get better PPA.
Did you referred this flow tutorial?
About metrics you find here.
Flow tutorial videos available here.

[dalyles]

Hi @vijayank88

Thanks for your reply.
I looked at the resources that you provided me and I wanted to check with you
if installing the autotuner would be the right direction to go in order to resolve
maximum cap violations?

From what I understand, using the autotuner would help generate a design with no
violations in general, right?

Looking forward to your reply.

[maliberty]

You could try adding -slew_margin to repair_design to force it to overfix and see if that helps. The larger the value the more the overfixing.

[dalyles]

Hi @maliberty

Thank you for adding your input.
Just for context, is this command used when running the GUI?
I'm currently running OpenROAD using make.
So withing the context of running make which file
should I be modifying to add -slew_margin to repair_design?

Thanks!

[maliberty]

This command would need to be run as part of your flow. I don't know if you are using OL or ORFS or another.

[dalyles]

Oh yes, I'm using ORFS for my runs if that helps.

[maliberty]

We don't have a control variable but you would add it to

OpenROAD-flow-scripts/flow/scripts/resize.tcl

Line 36 in ec6bc0a

repair_design

If that helps we can add a configuration variable.

[dalyles]

I think if you all add it that would be great, so that others won't have to come across this issue in the future.
Also what do you mean exactly by configuration variable? How does that differ from the control variable that you mentioned?

[maliberty]

I just noticed that you have max cap violations not max slew so you would use -cap_margin

[dalyles]

No worries, your previous answer is also very useful because in other runs I also encounter slew rate violations.

[dalyles]

Runs for other circuits that is.

[maliberty]

Something like

OpenROAD-flow-scripts/flow/scripts/cts.tcl

Line 66 in ec6bc0a

if { [info exists ::env(SETUP_SLACK_MARGIN)] && $::env(SETUP_SLACK_MARGIN) > 0.0} {

where you set SETUP_SLACK_MARGIN in your config.mk and the flow picks it up without having to modify the flow scripts.

[dalyles]

Just for clairty, in the line code given below,

OpenROAD-flow-scripts/flow/scripts/resize.tcl

Line 36 in ec6bc0a

repair_design

The new line would replaced with repair_design -cap_margin -slew_margin?

[maliberty]

Some like repair_design -cap_margin 10 -slew_margin 10

[dalyles]

Just to follow up, is 10 considered a high margin?

[maliberty]

They are percentage arguments so that should be 10% over-fixing. I think you'll have to experiment a bit. We do have some work underway that should help this issue in general.

[dalyles]

Great!
Thanks a lot @maliberty, just by setting the margins to 10 percent for -cap_margin,
I was able to reduce the cap violations down from 18 to 5. I'll continue to play with the values until I can get
it the violation count to converge to zero.

[maliberty]

I'm adding the vars in #1122

[dalyles]

Thanks @maliberty

Is this snipped of code still required though?
repair_design -cap_margin 10 -slew_margin 10

I tried running the updated version of your file without this line of code and
it came back to the original issue of having 18 max cap violations.

[maliberty]

You can set in your config.mk

export CAP_MARGIN = 10
export SLEW_MARGIN = 10

and not have to mess with resize.tcl

[vijayank88]

The default margin is 0. How do we decide how much margin to be used to fix the violations?
Is there any guidelines or rules to calculate MARGIN to overfix it? @maliberty

[maliberty]

Its mostly experimental. We are working on post-grt fixing which should be more accurate as it is near the end of the of flow.