Model reduction ops logical effort using a binary tree for delay estimation.

[copybara-service]

Model reduction ops logical effort using a binary tree for delay estimation.

This is not quite the optimal way to model them but should be better than the current implementation which is linear.

[allight]

@cdleary You originally wrote this way back in '19. If you have any thoughts about this change or history you can share it would be appreciated.

[cdleary]

@allight I think logical effort model can be "a way to guess at the delay you might get for some operations" if you know the FO4 delay for a given process you're targeting and haven't done delay characterization of certain ops. I think in the delay estimator it was always "one of the ways" you could try to select to get an estimate of delay for a subset of the ops.

I'd say a challenge with current delay model is that there are some very coarse grained ops vs fine grained ops like individual gates and we don't think hard about how the downstream synthesis tool might smash the fine grain small ops like individual NANDs together with (the internals of) other coarse grain ops. Also the optimizer happily will turn things into fine grained ops when it thinks that leads to better delay but it doesn't work super hard to optimize things at that finer grained representation like a synthesis layer would. Doing the "conversion to fine grained" more completely is what g8r was trying to explore and it has a full graph logical effort analysis in there as a result: https://github.com/xlsynth/xlsynth-crate/blob/045e66bd7ebbacc29e9824322c1eb85eaf1708fa/xlsynth-g8r/src/graph_logical_effort.rs#L228 Typically logical effort is a path level analysis on what you suspect is the critical path, so that also makes the one in the book not as much what we tend to look for in the delay model.

Hope that sheds some light, LMK if there's particular things that would be interesting to discuss more.

[allight]

Nice. The critical-path effort is basically how we were thinking about it too. The issue this is specifically solving is that since it didn't consider only the critical path the reduction ops were getting extremely high estimates as the number of bits increased. By changing to model it as a binary tree we get closer to the critical path through the logical operations.

[cdleary]

Yeah I'd maybe note somehow in the comment "although XLS IR makes it look like an nary op might end up as a single nary cell, it'll never get synthesized that way in the underlying synthesizer, so instead we use this binary tree approximation which gets closer to something that would really happen".