Absorb rocket.DecodeLogic into Standard Library

tl;dr: Proposal to migrate Rocket Chip Decode Quine–McKluskey algorithm into Chisel3 standard library.

Type of issue: feature request

Impact: API addition (no impact on existing code)

Development Phase: proposal

Other information

What is the current behavior?

Users wanting to build a microprocessor need to build a decoder. However, because Chisel and FIRRTL have no notion of actual “don’t cares” and/or the ability to emit casex, this cannot be pushed to the synthesis tool to properly optimize.

Rocket solves this with a Quine-McKluskey implementation inside freechips.rocketchip.rocket.DecodeLogic. This is great, but it requires either code replication or pulling in Rocket Chip for a feature which is, arguably, something that is common to hardware designs and not Rocket designs.

What is the expected behavior?

The standard library (or some other library, e.g,. chisel3.optimization) should expose this API and not Rocket.

What is the use case for changing the behavior?

Moving this and adding documentation would enable users to do QM optimizations for building decoders without having to pull in Rocket.

Any API modifications as a result of the migration would preserve backwards compatibility with Rocket Chip usage. (I don’t know yet if these would be needed or warranted. Likely not.)

Feedback Requested

I’d like feedback from @aswaterman on this.

Notes

Espresso implementations:

• https://github.com/classabbyamp/espresso-logic

[jackkoenig]

An alternative “backend” for a decode logic generator could be to leave the decoder logic as a blackbox and emit a data file that could be used to drive espresso or Verilog generation. Might be a bit of a sledgehammer on a nail, but I don’t think #1198 solves the issue unless we were to add support for unknowns to FIRRTL

[sequencer]

Will commercial synthesis tools support espresso-like mux optimisation with switch case semantics? I think we might need a qor benchmark framework with hammer.