Division instructions take more cycles when the divisor is larger than the dividend, is this intended?

[sammy17]

I noticed that division instructions take more cycles when the divisor is larger than the dividend (when it should return 0).
I noticed this as a side channel.

Could you please let me know if this is the intended behavior of the MulDiv unit or a side effect of the current implementation (not intended / performance bug)?

I am seeing the same behavior in BOOM as well.
How to reproduce:
tests_div.zip

# Test test_rocket_div_sml.elf has the case where the dividend is smaller than the divisor. This takes 128237 cycles. 
./simulator-chipyard-RocketConfig +verbose test_rocket_div_sml.elf 2>&1 | spike-dasm |& tee run.rocket.div.sml.1.log

# Test test_rocket_div_lrg.elf has the case where the dividend is larger than the divisor. This takes 128156 cycles. 
./simulator-chipyard-RocketConfig +verbose test_rocket_div_lrg.elf 2>&1 | spike-dasm |& tee run.rocket.div.lrg.1.log

PS: Edited the commands and cycle counts for Rocket.

[sammy17]

Hi All, Can anyone please comment on this? I want to know whether this was intended while writing the MulDiv module. Thanks in advance.

[jerryz123]

The divEarlyOut parameter to the MulDiv unit enables breaking out of the divider state machine earlier for special cases.
Even if you set that to false, you'll see in the source code that the state machine takes an extra cycle for divisions when the output needs to be negated.

This behavior is actually a performance feature, not a bug.

[sammy17]

Thanks for the response.

[sammy17]

I just realized that in my Multiplier.scala, divEarlyOut is set to false.
That means I was seeing this difference in timing even when the feature is disabled (unless the config value is overridden somewhere else).
I am using DefaultConfig for Rocket and SmallBoomConfig for BOOM.
Is this timing difference (81 cycles) expected when the feature is disabled or am I missing something here?

[jerryz123]

You can open uop the Multiplier in the waveform to see the request/response pattern. 81 cycles seems high. But its possible some other microarchitectural effect is at play here.

[sammy17]

Thanks for the pointers, I will take a look when I get a chance. I tried to reduce the effect from other instructions by executing nops before and after the div instruction in the tests I attached. So it should not be an effect from other instructions (unless nops affect div).