Add option to change internal bit representation of Clash types

[martijnbastiaan]

Consider the following data type:

data A
  = A (Unsigned 4)
  | B (Unsigned 4) (Unsigned 4)
  deriving (Generic, BitPack)

Right now:

>>> pack (A 2)
10010....

where the .s are indicating undefined. This behavior matches what Clash will generate in the HDL: whenever it converts the data type to a std_logic_vector-like. While this is completely fine in terms of functionality, interoperability between tools might suffer. For example, BlueSpec uses the following:

>>> pack (A 2)
1....0010

Other tooling might use "one-hot" constructors, like so:

>>> pack (A 2)
10....0010
>>> pack (B 2 2)
0100100010

Integrating with these tools thus requires the user to manually write these conversions. Pretty annoying!

Ideally, Clash would offer the option to configure this behavior. The easiest way would probably be a Cabal flag.

[leonschoorl]

Maybe we could use backpack to parameterize clash-prelude over the used bit representation.

[martijnbastiaan]

How stable is that? Is it actually used in the Haskell ecosystem?

[christiaanb]

We should have a flag as to whether Clash pads with undefined bits between the constructor bits and field bits (BlueSpec), or pads LSBs with undefined bits (Current Clash behaviour)

[christiaanb]

@martijnbastiaan Can this issue be closed now that we have support for custom bit-representations?

[martijnbastiaan]

What I'm proposing here is a flag to switch representations by default. So yeah, most (all?) if this can be mitigated by using custom repr annotations. If there's no plan to add this we can close the issue I think.