Value circuits new

[cchalmers]

The value level circuit syntax I originally started work on 6 years ago! master...value-circuits

This was written with the anthropic's new fable model. I also got it to add significantly more testing.

This gets you pretty close to being able to write everything with circuit syntax! Mealy machines can be done with a registerC:

accum :: Circuit (Signal dom Int) (Signal dom Int)
accum = circuit \(SignalV i) -> do
  SignalV acc <- registerC 0 -< SignalV acc'
  let acc' = acc + i
  idC -< SignalV acc'

It also supports multiple clock domains (although you don't get a great error when you mix them up):

dualCounter :: Circuit (Signal domA Bool, Signal domB Bool) (Signal domA Int, Signal domB Int)
dualCounter = circuit \(SignalV enA, SignalV enB) -> do
  SignalV n <- registerC 0 -< SignalV (if enA then n + 1 else n)
  SignalV m <- registerC 0 -< SignalV (if enB then m + 1 else m)
  idC -< (SignalV n, SignalV m)

and DSignalC support (makes sure all groups have the same delay):

  dpipeC :: Circuit (DSignal dom d Int) (DSignal dom (d + 1) Int)
  dpipeC = circuit \(DSignalV i) -> do
    DSignalV a <- dregisterC 0 -< DSignalV (i + 1)
    idC -< DSignalV (a * 2)

I've tested this enough internally that I'm happy with it. The only issue that came up is the lazyness which has been fixed.

[martijnbastiaan]

RIP Fable..

I find that I typically mix and match Circuit and non-Circuit constructs, maybe it makes sense to also allow this in lets? Perhaps then split Fwd and Signal (de)construction? E.g., something like:

accum :: Circuit (Signal dom Int) (Signal dom Int)
accum = circuit \(Fwd (Values i)) -> do
  Fwd (Values acc) <- registerC 0 -< Fwd (Values acc')
  let acc' = acc + i
  idC -< Fwd (Values acc')

~

accum :: Circuit (Signal dom Int) (Signal dom Int)
accum = circuit \(Fwd (Values i)) -> do
  let
    Values acc = register 0 (Values acc')
    acc' = acc + i
  idC -< Fwd (Values acc')

Not sure about any of this, just floating an idea.

[cchalmers]

I'll think about it but adding support in general Haskell expressions and bindings might open a whole can of worms. Right now, since it's limited to the "arrow land", it's relatively simple without much in the way of edge cases (I hope).

I'm generally in favour of keeping the plugin simple and predictable at the cost of a bit of verbosity. You can always use helpers (something like onCSignal :: (Signal dom a -> Signal dom b) -> Circuit (CSignal dom a) (CSignal dom b)) to promote something to Circuit land, or use idC to bridge in or out of value land.

[martijnbastiaan]

Yeah, makes sense. I'd rather have less magic too.

[rowanG077]

I like this a lot. It makes circuit notation fit much more naturally with standard Clash code.

Could you add write-ghc-environment-files: always to the cabal.project? This ensures that a standard cabal build + cabal test works.

[rowanG077]

Why use internals here? This seems to work just fine:

registerC :: HiddenClockResetEnable dom => a -> Circuit (Signal dom a) (Signal dom a)
registerC a = Circuit $ \(s :-> ()) -> (() :-> register a s)

[rowanG077]

Same here

[rowanG077]

This drops value groups with no outputs. This means code like this is accepted:

deadLet :: Circuit (Signal dom Int) (Signal dom Bool)
deadLet = circuit \(SignalV a) -> do
  let bad = P.not a
  idC -< SignalV (0 :: Int)

Where that should be a type error imo.

[rowanG077]

This is maybe a bit of a nit, but it would be nice if this would work:

valueAsPattern :: Circuit (Signal dom (Int, Int)) (Signal dom (Int, Int))
valueAsPattern = circuit \(SignalV p@(a, b)) -> do
  idC -< SignalV p

That can also just be an issue, doesn't need to be fixed now imo.

[rowanG077]

Should pragmas/fixities annotation move as well, like:

valueLocalInline :: Circuit (Signal dom Int) (Signal dom Int)
valueLocalInline = circuit \(SignalV a) -> do
  let
    {-# INLINE inc #-}
    inc x = x + 1
  idC -< SignalV (inc a)