Initial blocks vs reset line about clash-compiler HOT 7 CLOSED

We've added register powerup values (or initial blocks) in #498. Any argument used with ~CONST (in a blackbox) will make Clash try extra hard to reduce it to a constant. We've decided not to not explicitely support registers without reset values, to prevent a zoo of functions. However, you could try and use Clash.Signal.Internal.register#, which allows you to specify a different reset value. HDL tools might be smart enough to completely let go of reset logic if you pass undefined there. Alternatively, you could create your own register primitive. For inspiration you can find the current implementation over here.

I believe the PR fixes this issue, so I'm closing this issue. If that's a mistake, please reopen!

from clash-compiler.

This can only work if the reset value is a constant. The blockRam primitive already demands that it's initial value must be a constant in its documentation, but it is not enforced in the front-end of the compiler. Indeed, compilation will only fail once it is already in the code-generation phase.

At the moment, there is no such demand for registers because it is currently initialised through a reset. Perhaps what we can do is use an initial block when the reset value is a constant, something we check at code-generation time.

from clash-compiler.

Hmm, in a synthesizable program the only meaningful way to initialize a register with a non-constant (after constant propagation) is to have topEntity :: A -> Signal B (with no signals in A), right? Without a signal in the return type, or non-signal in the parameter type, the register is provably dead code.

That seems to be a somewhat odd use-case (or perhaps I am unaware of the utility of such things). Perhaps something like unsafeMerge :: CSignal a x -> CSignal b -> CSignal (Or a b) x could be added to recover the lost functionality?

from clash-compiler.

Yeah, that use-case makes no sense. Indeed, the reset value should ultimately be a constant.

On the implementation side, we sometimes end up with code like this:

topEntity x y = ...
  where
    (c,d) = g k p
    e     = f c x
    ...

g k p = (3,k)

f d x = register d x

Where the reset value of register is indeed a constant, but the register function is not applied to a constant. In the current setup for the compiler, and forcing the reset value to be a literal, compilation of the above code will fail at code-generation.

What needs to happen, is that the compiler looks at all the BlackBox definitions and check which primitives need literals for certain arguments. Subsequently, the normalisation phase should try it's hardest to make sure literals end up at those places. The above code would then probably be transformed first to:

topEntity x y = ...
  where
    (c,d) = (3,k)
    e     = f c x
    ...

f d x = register d x

and then to:

topEntity x y = ...
  where
    d     = k
    e     = f x
    ...

f x = register 3 x

Anyhow, it's not as trivial as it might have initially sounded.

from clash-compiler.

Yeah, definitely not so trivial then unfortunately. Pity https://ghc.haskell.org/trac/ghc/wiki/Supercompilation never got merged. Even if it is not good in the general case, I assume it would be really useful for CLaSH.

from clash-compiler.

I have a collegae that went with a supercompilation approach described at: http://www.cs.ru.nl/P.Achten/IFL2013/symposium_proceedings_IFL2013/ifl2013_submission_7.pdf

The problem with supercompilation for me, is that it completely destroys the first-order function hierarchy. I think a nice aspect of CLaSH's current approach, is that the resulting netlist looks very much like the original function hierarchy. I aids in both the understanding of how this "structural" approach to designing (in Haskell) works, and it aids in debugging non-functional aspects of your design (propagation delays and area). That is, it is nice to be able to look at your RTL diagram, and see where your design is using a lot of area, or incurring a lot of propagation delay, and then immideately figure out which function is causing that.

When you destroy the original first-order function hierarchy, those things become (much) harder.

from clash-compiler.

Interesting paper (and sorry I didn't respond earlier--I read this a while back and then forgot to respond).

Good points on legibility post compilation. Taking the opposite tack, I wonder if using macro-parametrized modules could avoid needing monomorphization. Consider this module I wrote:

module BCD #( parameter BITS_IN
            , parameter DIGITS)
            ( input [BITS_IN-1:0] binary
            , output reg [DIGITS-1:0][3:0] digits);
  always_comb @(*) begin
    digits = 1'd0;

    for (integer i=BITS_IN-1; i>=0; i=i-1) begin
      // Add 3 to columns that are >= 5
      for (integer j=DIGITS-1; j>=0; j=j-1) begin
        if (digits[j] >= 5)
          digits[j] = digits[j] + 4'd3;
      end
      digits = {digits, binary[i]};
    end
  end
endmodule

[Finally, I am not sure how much a good idea my original proposal would be even if it were feasible--hooking up the PLL lock to the reset-line is still needed even if the initial value is a constant.]

from clash-compiler.