4 ms·

Your tooling for interactive hardware development should be standard issue. However, I would actually make the other claim - nMigen et al don't improve the rea

Your tooling for interactive hardware development should be standard issue. 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.

wyager 5y ago
> A dedicated, strongly typed language where the hardware is a first class language feature 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.
- thrtythreeforty 5y ago
  Thanks for the recommendation! I've run across it in the past, but I still find Haskell syntax to be absolutely baffling so I was put off by the learning curve. (There's something to be said for sticking to syntax familiar to users of the incumbent - Rust vs C++ springs to mind.) Perhaps I'll give Clash a shot - the homepage describes basically all the features I'm looking for. The documentation appears to be excellent.
  - wyager 5y ago
    There’s definitely a learning curve, but since you’re using a relatively restricted subset of Haskell, you can basically skip learning about things like IO and also most of the Haskell ecosystem, so it’s very manageable. 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.
    - melony 5y ago
      What is the small difference?
      - wyager 5y ago
        Zero-bit busses cannot have an indeterminate value in hardware. However, zero-bit values (Unit) can have indeterminate value in software. 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).
        a1369209993 5y ago
        IIUC, this is actually a general deficiency in the type system for variable-width tuples. Consider: 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) You can actually fix this by (ab)using types of kind `TYPE 'UnliftedRep` and unboxed tuples (type `(# Car, Cdr #)`, value `(# b7, b6543210 #)`), it's just generally not worth the effort.
newhouseb 5y ago
Totally agree, I've been doing a ton of DSLs using Typescript's (super) expressive type system and am holding myself back from writing a full on HDL that compiles down to FIRRTL.
melony 5y ago
Try Chisel, it is production ready and is built on Scala.
- fouric 5y ago
  Chisel builds with sbt, which is extraordinarily slow[1][2][3], and extremely difficult for newcomers to use[1], if not outright poorly-designed. [1] https://www.lihaoyi.com/post/SowhatswrongwithSBT.html https://www.lihaoyi.com/post/SowhatswrongwithSBT.html [2] http://overwatering.org/blog/2013/12/scala-1-star-would-not-program-again/ http://overwatering.org/blog/2013/12/scala-1-star-would-not-... [3] https://duckduckgo.com/?q=sbt+slow https://duckduckgo.com/?q=sbt+slow

wyager 5y ago

> A dedicated, strongly typed language where the hardware is a first class language feature 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.

thrtythreeforty 5y ago
Thanks for the recommendation! I've run across it in the past, but I still find Haskell syntax to be absolutely baffling so I was put off by the learning curve. (There's something to be said for sticking to syntax familiar to users of the incumbent - Rust vs C++ springs to mind.) Perhaps I'll give Clash a shot - the homepage describes basically all the features I'm looking for. The documentation appears to be excellent.
- wyager 5y ago
  There’s definitely a learning curve, but since you’re using a relatively restricted subset of Haskell, you can basically skip learning about things like IO and also most of the Haskell ecosystem, so it’s very manageable. 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.
  - melony 5y ago
    What is the small difference?
    - wyager 5y ago
      Zero-bit busses cannot have an indeterminate value in hardware. However, zero-bit values (Unit) can have indeterminate value in software. 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).
      - a1369209993 5y ago
        IIUC, this is actually a general deficiency in the type system for variable-width tuples. Consider: 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) You can actually fix this by (ab)using types of kind `TYPE 'UnliftedRep` and unboxed tuples (type `(# Car, Cdr #)`, value `(# b7, b6543210 #)`), it's just generally not worth the effort.

newhouseb 5y ago

Totally agree, I've been doing a ton of DSLs using Typescript's (super) expressive type system and am holding myself back from writing a full on HDL that compiles down to FIRRTL.

melony 5y ago

Try Chisel, it is production ready and is built on Scala.

fouric 5y ago
Chisel builds with sbt, which is extraordinarily slow[1][2][3], and extremely difficult for newcomers to use[1], if not outright poorly-designed. [1] https://www.lihaoyi.com/post/SowhatswrongwithSBT.html https://www.lihaoyi.com/post/SowhatswrongwithSBT.html [2] http://overwatering.org/blog/2013/12/scala-1-star-would-not-program-again/ http://overwatering.org/blog/2013/12/scala-1-star-would-not-... [3] https://duckduckgo.com/?q=sbt+slow https://duckduckgo.com/?q=sbt+slow