The-OpenROAD-Project
More accurate STA without CCS/SI
I found this paper that combines spice with NLDM STA that results in a more accurate timing model. Perhaps we could look at this as an alternative to implementing CCS and SI, if our current approach fails.
https://utd-ir.tdl.org/bitstream/handle/10735.1/6333/ETD-5608-013-WANG-8922.39.pdf?sequence=6&isAllowed=y
Seems like the method is pretty reasonable. Basically use NLDM to find all the questionable critical paths where the impedance is much greater than the resistance, or wherever there's a question around whether or not a path might be a violation.
Then you take those paths, and extract them into spice netlists. Run them through spice and you have a really accurate critical path.
We could do the same thing for SI, but a little bit differently. We would take all the areas where we think timing could be violated by SI issues then bloat the netlist to include all the long parallel wires next to that netlist, extract that into spice and run the worst case scenario.
In OpenROAD we can just take ngspice, or one of it components and statically link it in, and then we'd have a relatively transparent SI/CCS solution. Should be more performant compared to full CCS as well
Simulating critical paths is nothing new. OpenSTA already has write_path_spice. It isn't always simple as you have to form the correct stimulus and initial conditions to actually get spice to work.
Many designs will have loads of critical paths near zero slack (that the nature of optimization). I think you'll wind up simulating a tremendous amount. It also makes optimization much harder to implement. Glitch noise is a separate analysis for which there is no slack involvement and won't easily be handled this way.
I view this as a 'better than nothing' approach but not a replacement for CCS. I'm curious to hear what Tom thinks.
It seems like even if we spend an enormous amount of compute power on it, it would be better than nothing.
@QuantamHD this could work for final signoff timing, but would not work in optimization. We need an accurate and fast model for optimization that can be run in the context of incremental timing. This would also be helpful for QA of a current source model when we have it.
Maybe as a hybrid model you could optimize based on a depessimized (0% buffer) NLDM incremental timing, and use the spice model to pick up any errors, and fix as a final step with an incrementally perssimized (increase by buffer by 2%) NLDM on any broken nets.
From what I've been reading it should also be possible to identify which paths would be the most likely candidates for the Miller effect. So we could run spice on those nets in the optimization loop as well.
@QuantamHD yes, that is how it was done 20 years ago. Its very slow in runtime but workable when there are only a small number of violations.
We have a lot more cpu compute then 20 years ago! :-)
We have a lot bigger chips that we did 20 years ago ... same Moore's law at work.
We have a lot bigger chips that we did 20 years ago ... same Moore's law at work.
Well, the designs done on 130nm have actually gotten smaller as they are mainly microcontrollers rather than high performance CPU hardware (as the high performance CPU has moved to more advanced nodes).
We have a lot bigger chips that we did 20 years ago ... same Moore's law at work.
Well, the designs done on 130nm have actually gotten smaller as they are mainly microcontrollers rather than high performance CPU hardware (as the high performance CPU has moved to more advanced nodes).
You don't need CCS for 130nm, you need it for advanced nodes.
I guess the question is would this be a beneficial thing to work on between now and a ccs implementation, or should we just start figuring out how to make a ccs implementation from scratch?
I would rather make progress towards our desired state than take a side trip that doesn't contribute to the end goal.