Add Q/V method prodecure option for input pin capacitance

[e-dworkin]

New Q/V method procedure for pin capacitance. The default is to use the ac-sweep but can be toggled in the YAML with the new key under Simulation: input_capacitance_procedure: (ac_sweep or qv_method).

The procedure uses estimates for simulation time that may not work for all cells. In the future these parameters should be made more configurable and be more intelligently determined.

[infinitymdm]

Overall looks great. Just a few small issues.

• Rename the procedure to something more descriptive. Open to suggestions; see comment on the generator name.
• Analyze whether parameters (t_slew and t_wait in particular) are independent of capacitance results. If independent, no change needed. Otherwise, add configuration keys for setting these values from YAML.
• Add rise_capacitance and fall_capacitance to liberty output.
• Justify the decision to average q_rise and q_fall or allow users to specify criterion.

More detail in the review comments.

[infinitymdm]

Is an average actually the best thing to do here? Would it be preferable to return the larger (i.e. more pessimistic) capacitance value?

This might be a place where a criterion argument (similar to procedures.combinational.delay) is appropriate. That way you can leave the choice up to users.

[e-dworkin]

Changes based on the review comments:

• Renamed the procedure to "charge_integration" from "qv_method"
• t_slew and t_wait could impact the accuracy of the pin capacitance measurement. Configuration keys were added as charge_integration_t_slew and charge_integration_t_wait.
  • The default for t_slew is to use the fastest of the provided data_slews for that cell. It is assumed that the user is inputting a reasonable range of slews for a particular cell, so this approach will always be physically possible and does not break if the user overrides the default time unit (ns). The slew rate was not found to significantly affect the accuracy of the results. However, longer simulation time allows for more leakage current to corrupt the measurement. The leakage current's effect on the pin capacitance is negligible enough not to warrant compensating for it with an additional DC operating point simulation, but that is the reason for selecting the min(data_slews) as opposed to some other value.
  • The default for t_wait is 1000*t_slew. The wait time is not physically related to the slew rate so it feels arbitrary to base t_wait on t_slew, but doing so has a few advantages. Since the simulation time step is determined by t_slew, using a multiple of t_slew for t_wait leads to a consistent simulation time (with the defaults, 10k timesteps). As t_wait grows (relative to t_slew), more and more compute is required to run the simulation. In my testing, all cells reached 99% accuracy within 100*t_slew so setting the default to 1000x seems reasonable for most use cases.
  • If we're willing to sacrifice extra compute, we can make the calculation more robust by running a DC operating point simulation to account for leakage (or somehow obtaining that information from the leakage_power procedure). We can also run an initial simulation to estimate the settling time and ensure t_wait is the optimal value. Those improvements can be implemented in the future, potentially as opt-in settings for "higher accuracy" or "higher confidence" in the YAML.
• rise_capacitance and fall_capacitance are now reported alongside capacitance in the Liberty output
• The capacitance attribute is now reported as the larger of the rise and fall capacitances, rather than as the average.

Let me know if there is anything else that requires urgent attention

[infinitymdm]

Looks good to me. Thanks for contributing this!

[rovinski]

The capacitance attribute is now reported as the larger of the rise and fall capacitances, rather than as the average.

Just popping in to note that for simulators, the only time that capacitance is really used over rise_capacitance or fall_capacitance (if all 3 are provided) is when the direction of a transition is unknown, such as for early vectorless power estimations. In this case, it should be assumed that there are on average an equal number of rise/fall transitions, so the average capacitance value would result in the most accurate results. I would recommend defaulting to the average rise/fall capacitance. Some simulators in fact ignore capacitance and manually calculate the average of rise/fall_capacitance for these situations.