Issues with buffer selection

[antonblanchard]

In https://github.com/efabless/caravel/issues/41 @rtimothyedwards mentions:

It is also unclear to me why openlane uses "clkbuf" buffers for input buffering. There is no particular need for an oversized balanced buffer just to provide input buffering (other than buffering a clock network).

I also noticed the use of clkbuf and delay buffers in a number of places. Both buffer_ports and repair_design sometimes use clkbuf or dlybuf/dlygate/dlymetal instances. I presume this is due to Resizer::findTargetCell() which loops through sta_->equivCells(). buf clkbuf and dly* cells are all considered equivalent.

Would it make sense to add an option to OpenROAD to disable buffer substitution? The other option is to add another set of don't use cells to Openlane, so that the clkbuf and dly* cells are not available for use by the resizer.

[maliberty]

Is there anything inherently bad about using a clock buffer outside the clock tree? It is usually just better balanced between rise and fall delay.

[RTimothyEdwards]

In theory, I would expect that the clock buffer is larger than the equivalent regular buffer due to the devices sized up to make the output crossing balanced, which will tend to make the layout less optimal and less compact. That said, though, I notice that for the sky130 HD library, the clkbuf_1 is just the buf_1 flipped (why??) and the clkbuf_2 made the pFETs larger but the nFETs smaller, so it's a wash and both cells are the same size. So I guess as long as the resizer has analyzed the timings for the rising and falling edges and chosen the buffer that best optimizes both, then I'll trust the resizer.

[RTimothyEdwards]

I've always wanted to create a system of half-cells where all standard cells are either just the N or the P side, and the synthesis tools just mix and match whatever works best. Why let half your cell slow your system down because you couldn't optimize the N and P sides independently?