Modify ExpandWhens to process elses as if they were modified whens

[albert-magyar]

chipsalliance/chisel#510 introduces FIRRTL else statements to Chisel's code generation. However, this produced a small (and consistent) area regression in rocket-chip, possibly due to buffering/fanout or other select signal logic.

This PR introduces a minimal change to ExpandWhens to keep Verilog code generation consistent with prior versions of Chisel3.

This pull request causes the following FIRRTL:

  when (a) :
    x <= y
  else :
    when (b) :
      x <= z

to produce the same mux tree structure as the original style emitted by chisel3:

  when (a) :
    x <= y
  when (and(not(a), b)) :
    x <= z

This is desirable as a baseline to make code generation essentially identical while allowing other changes depending on initialization checks to go forward.

[aswaterman]

@albert-magyar want me to check for QoR regression vs. current master?

[albert-magyar]

That would be great! I haven't done the rocket integration tests, so this is still not quite ready to merge pending that.

[aswaterman]

ok, will do this week

[aswaterman]

This Firrtl change is neutral to QoR.

Even with this change, though, the Chisel PR from back in February still causes a regression in QoR. The Rocket test case I used no longer meets timing (not dramatically, of course) but it's too hard to sort out why, since there are thousands of failing paths

[albert-magyar]

Thanks for checking. I guess I will do some more poking in the generated source and see if I might be deepening mux trees or something.

[aswaterman]

Np. If you have a good idea, I can help test it out, but this might require a more thorough empirical approach that I don't have the time/licenses to support.

[jackkoenig]

Given that chipsalliance/chisel#510 was found to no longer harm QoR (and actually have other benefits), I think this PR is no longer desirable.