3 ms·

The problem is that programming abstractions are fundamentally different from those in hardware description languages. Whereas programming abstracts away arbitr

The problem is that programming abstractions are fundamentally different from those in hardware description languages. Whereas programming abstracts away arbitrary manipulation of memory with variables, pointers, and functions, Verilog abstracts away transistor topology and the NP-hard routing problem inherent in FPGA/ASIC design. The former is an abstraction for telling a precisely defined system what to do while the latter describes the system of equations for a (possibly nondeterministic) linear constraint solver. Hardware description languages can never be as abstract as programming languages for the same reason that we can't create a single unifying abstraction for imperative multi and single threaded code: synchronization. Since each algorithm or data structure can have unique memory access/sync patterns, especially once optimized, there is no way to abstract away parallelization so we're forced to work with a large number of low level primitives like queues, locks, etc. In silicon, not only is everything running in parallel but each abstract unit of functionality has many more "degrees of freedom" like synchronization points, clock speeds, and physical location. It's simply impossible to cleanly abstract over all of the little tweaks you have to do in the implementation phase to get your blocks of transistors to synchronize properly.

aninhumer 10y ago
>Hardware description languages can never be as abstract as programming languages I'm not sure what it would even mean for HDLs to be "as abstract" as programming languages. They're different paradigms, and they have different abstractions, so you can't really compare them directly. What I do know is that you can do a lot better than Verilog, because I've experienced it. I worked in Bluespec for a few years and as a language it's so much better than Verilog it's not even funny. Indeed, using it made me stop thinking of Haskell as a programming language, and start thinking of it as a declarative language for constructing imperative programs in the IO monad.
- duaneb 10y ago
  > Indeed, using it made me stop thinking of Haskell as a programming language, and start thinking of it as a declarative language for constructing imperative programs in the IO monad. Yea, the parallels between hardware design and haskell are striking. (Not just haskell, but it is perhaps the easiest to see.) In undergrad, I wrote my basic cpu project (16-bit risc) in haskell, then got it to write the verilog for me. This had the benefit of having an incredibly fast iteration cycle (including testing) paired with the ability to output an actual hardware description at any point. Very powerful. It really hammers home the difference between computation and I/O, a common theme in both CPU design and functional programs. Also—and this is just my opinion—I much prefer declaring the computation with logical combinators rather than manually specifying how the bits are routed. This is much easier in haskell (or any functional language) than it is in verilog.
  - mungoman2 10y ago
    Hm, interesting. Have you written about this anywhere?
petra 10y ago
If you work smartly , there's no inherent conflict between abstraction and efficiency. For example , here's a DARPA project - which uses Chisel to implement an efficient version of the risc-V microprocessors, in an abstract, very productive manner: http://people.eecs.berkeley.edu/~bora/Conferences/2015/ESSCIRC15.pdf http://people.eecs.berkeley.edu/~bora/Conferences/2015/ESSCI...

aninhumer 10y ago

>Hardware description languages can never be as abstract as programming languages I'm not sure what it would even mean for HDLs to be "as abstract" as programming languages. They're different paradigms, and they have different abstractions, so you can't really compare them directly. What I do know is that you can do a lot better than Verilog, because I've experienced it. I worked in Bluespec for a few years and as a language it's so much better than Verilog it's not even funny. Indeed, using it made me stop thinking of Haskell as a programming language, and start thinking of it as a declarative language for constructing imperative programs in the IO monad.

duaneb 10y ago
> Indeed, using it made me stop thinking of Haskell as a programming language, and start thinking of it as a declarative language for constructing imperative programs in the IO monad. Yea, the parallels between hardware design and haskell are striking. (Not just haskell, but it is perhaps the easiest to see.) In undergrad, I wrote my basic cpu project (16-bit risc) in haskell, then got it to write the verilog for me. This had the benefit of having an incredibly fast iteration cycle (including testing) paired with the ability to output an actual hardware description at any point. Very powerful. It really hammers home the difference between computation and I/O, a common theme in both CPU design and functional programs. Also—and this is just my opinion—I much prefer declaring the computation with logical combinators rather than manually specifying how the bits are routed. This is much easier in haskell (or any functional language) than it is in verilog.
- mungoman2 10y ago
  Hm, interesting. Have you written about this anywhere?

petra 10y ago

If you work smartly , there's no inherent conflict between abstraction and efficiency. For example , here's a DARPA project - which uses Chisel to implement an efficient version of the risc-V microprocessors, in an abstract, very productive manner: http://people.eecs.berkeley.edu/~bora/Conferences/2015/ESSCIRC15.pdf http://people.eecs.berkeley.edu/~bora/Conferences/2015/ESSCI...