You're right, there are also interpolating LUTs, for those the output values tend to be circumscribed by the values listed in the edge columns (and rows in case of 2D tables).
Since you seem to have a lot of insight into this material, what is the reason that the cycle budget is spent to that degree? With my limited insight into the world of embedded systems like these I'd imagine a main loop cycling several thousand times per second and none of the inputs generating more pulses than a few KHz you'd imagine that 120 MHz would be ample, what am I missing? Are these chips programmed in some high level language with significant overhead?
(Coding is done in C, following MISRA rules and some internal additional standards. This includes the generated code - this one may not be highly optimized every time. The rest of the SW I could say is pretty much OK optimization wise. Assambler may be also used in some limited scenarios, especially for low level device drivers)
I think what you are missing is the complexity of the models working with the inputs to produce the outputs. The models are much more than a few LUT's here and there. It is just so much to do and you have to do in real time (we actually use real time operating systems, like RTA-OSEK and RTA-OS). Stuff is executed time based (1ms to 1s, with most at 10ms and 100ms) or event based (generated by SW or by interrupts). Events can come faster than 1ms (crank wheels teeth counting at high rpm for example).
Since you seem to have a lot of insight into this material, what is the reason that the cycle budget is spent to that degree? With my limited insight into the world of embedded systems like these I'd imagine a main loop cycling several thousand times per second and none of the inputs generating more pulses than a few KHz you'd imagine that 120 MHz would be ample, what am I missing? Are these chips programmed in some high level language with significant overhead?