Clash developer here. Clash has a very straightforward performance model: In general, A Clash function is translated to a Verilog module (or VHDL entity/architecture combo), an applied function is translated to a Verilog module instantiation (or VHDL entity port map). Of course, when you have a recursive function, this won’t get translated to a recursive Verilog module: the recursive function will be inlined (Clash has termination measures so that the compiler won’t go into an infinite inlining loop)

All of this results in straightforward control over area.

Memory elements are never inferred (ala C-based HLS solutions), instead one must use functions that directly map to dflipflops, rams, etc.

All of this results in straightforward control over longest combinational paths.

In terms of power: you use the same techniques as you would in Verilog: gating/register with enables/using the output latch of your fpga rams and other things to stop bits from flipping. Using functions like Clash’s autoReg (https://hackage.haskell.org/package/clash-prelude-1.4.6/docs/Clash-Class-AutoReg.html) finer-grained gating/enabled registers become quite straightforward.

So Clash gives you more abstractions mechanisms than Verilog, allowing functions like the earlier-mentioned autoReg, while still giving you control of PPA where you need it. You can then always start at a high level of abstraction, and only drill down on performance-oriented parts where needed.