search

clash-lang / clash-compiler

Haskell to VHDL/Verilog/SystemVerilog compiler
https://clash-lang.org/
Other
1.44k stars 154 forks source link

Add option to change internal bit representation of Clash types #572

Open martijnbastiaan opened 5 years ago

martijnbastiaan commented 5 years ago

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 commented 5 years ago

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

martijnbastiaan commented 5 years ago

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

christiaanb commented 5 years ago

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 commented 2 years ago

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

martijnbastiaan commented 2 years ago

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.