[1] https://www.lihaoyi.com/post/SowhatswrongwithSBT.html
[2] http://overwatering.org/blog/2013/12/scala-1-star-would-not-...
Have you seen clash? It sounds like what you want. It really kicks ass - by far the most productivity-boosting and error-reducing HDL strategy I’ve seen. It’s also a subset of Haskell, so you can run your hardware code from a compiled binary or REPL before compiling it to VHDL/Verilog.
I like nmigen, but I have the same preference that hardware should be a first-class component of the language, and strong types are desirable.
Perhaps I'll give Clash a shot - the homepage describes basically all the features I'm looking for. The documentation appears to be excellent.
The learning curve is sort of inherent to the fact that the reason Clash works so well is that semantics of a pure lazy functional language with algebraic data types (very different from what most people learn) almost exactly matches the standard 01XZ semantics of digital circuitry. There’s one very small difference that I’m aware of. The nearly-ideal correspondence is honestly kind of surprising.
If you have the circuit
f :: () -> Int
f () = 3
Vs
g :: () -> Int
g _ = 3
Are the exact same thing in hardware but different in software.
“f undefined” is undefined in software but “g undefined” is not. Neither is undefined in hardware.
This distinction comes up very rarely. Only if you have a parametric circuit that sometimes takes zero-bit inputs (I.e. if the input is unused in some instantiations).
f1 :: (Bit,()) -> Int
f1 (0,()) = 3
f1 (1,()) = 3
-- f1 (0,undefined) is undefined
f2 :: (Bit,(Bit,())) -> Int
-- and so on. Conversely
g2 :: Bit -> Bit -> Int
g1 :: Bit -> Int
g0 :: Int
-- doesn't have this problem but also doesn't work well for busses.
-- The 'obvious' approach
h3 :: (Bit,Bit,Bit) -> Int
h2 :: (Bit,Bit) -> Int
h1 :: (Bit) -> Int
h0 :: () -> Int
-- doesn't work generically; (Bit) isn't a tuple at all,
-- and n-element tuples are totally unrelated to m(!=n)-element tuples
-- (they're literally declared as:
data (a,b) = (a,b)
data (a,b,c) = (a,b,c)
-- in module GHC.Tuple)
However, I would actually make the other claim - nMigen et al don't improve the readability of a hardware block versus Verilog. Verilog does indeed suck for any parametric design though, so the Python metaprogrammability is an obvious win. A dedicated, strongly typed language where the hardware is a first class language feature (or at least appears to be via syntactic sugar/new grammar) would give the best of both worlds in my opinion.
The difficult part is (still) polyglot programs - say, if I have a module written in Silice, which includes a vendor's Verilog block ram model, which is all instantiated by an nMigen harness. LiteX makes this possible (although difficult) to simulate with Verilator, but the quick interactivity of the Jupyter workbench is lost.