So if anyone knows, do both of these languages do the same thing or is there another angle I need to evaluate them through?
Since you’re more familiar with Haskell, perhaps have a look at Blarney: https://github.com/blarney-lang/blarney/blob/master/Doc/ByEx... It’s an actively maintained EDSL for circuit design using Haskell as its host language.
Still, I was curious, so I fed it to the Duck, and got links like:
https://www.insystechinc.com/edsl/
Not what was meant, I suspected, which is when I started this reply, and then remembered that other search site everyone seems to like. A search there finally brought up this:
https://wiki.c2.com/?EmbeddedDomainSpecificLanguage
which provided the answer I'm pretty sure I was seeking.
So, for all the rest of us less-enlightened visitors who might not actually know, I believe that EDSL (in this case) means:
Embedded Domain Specific Language
(I got downvoted, I was asking this question genuinely, am I missing something obvious?)
I was always torn on how to describe Clash to an audience whose background I don’t know up front: is it a hardware description ‘language’, or, is it a set of tools, libraries and scaffolding to use Haskell as a method for circuit description?
So yes, Clash is just Haskell. Although it is Haskell with certain GHC language extensions enabled by default plus a type-checking plugin for reasoning about type-level natural numbers.
That’s because the Clash compiler can only translate a semantic subset of Haskell to circuits. We use types to determine how big the circuit will become (fixed-length lists, fixed-depth trees, fixed-width numerics, etc.). So the semantic subset part means that Clash will not translate Haskell programs where the recursion depth is unknown at compile time, nor things like mutation (whether it’s ST or IO) or other I/O like actions.
Finally, why we’ve kept the “Clash is a functional hardware description language” is that unlike approaches such as nMigen, Chisel, Spinal, the Clash compiler translates the actual Haskell source code to VHDL/(System)Verilog. It uses the GHC Haskell compiler to do all the parsing, type-checking and “desugaring”. This means that with Clash you can use all of Haskell’s syntax to describe how the circuit operates, including if-expressions, case-expressions, etc. In the other approaches I mentioned you usually have to use some sort of ‘when’-function to describe run-time choice. So those approaches to me feel more like a “use-language-X-as-a-tool-for-circuit-description”, while Clash, again to me, does really feel more like a hardware description ‘language’.
Does Clash compile to Verilog, as Chisel does, (your comment makes me think it does not)? Or is it that it goes directly to a net-list of transistors (I think that’s the right terminology).
Software source code can't run directly on hardware and has to be either interpreted by an interpreter, or compiled by a compiler. In both cases the source code is transformed into machine instructions. As the term implies these are instructions to the hardware, more specifically a processor, or a processing unit.
Hardware is the physical manifestation of the computer. Most components of a modern computer - CPU, GPU, RAM, SSD drive, USB controller - consist of vast networks of interconnected transistors. By connecting a few transistors together the right way they can express the electrical equivalent of a boolean logic gate (AND, OR, XOR, NOT etc). By connecting logic gates together they can express logic blocks of various types (multiplexers, adders etc). "Zoom out" a few more levels of abstraction and we call the logic blocks "CPU", "RAM", "USB controller" etc.
Many different types of physical objects have been invented that all behave functionally equivalent to a transistor. The first computers were mechanical. For practical and performance reasons, essentially all modern computers use electrical transistors that express boolean logic where logical 0 and logical 1 are represented by different voltage levels.
Going back to machine instructions, these are interpreted by the hardware / boolean logic network / transistors one at a time through the fetch-decode-execute instruction cycle. We call this fundamental interface between hardware and software the Instruction Set Architecture. Some ISAs have variable-length instructions, such as x86, others have only one length, such as RISC-V RV32I. In RV32I all instructions are 32-bit wide. An RV32I CPU fetches one instruction at a time. Each of the instruction's 32 bits are transmitted on a separate wire from memory to the CPU decoder logic block. The decoder logic block in turn is connected to other wires that constitute control signals to other parts of the CPU.
From this perspective let's rephrase your question a few different ways:
Why not use machine instructions to express transistors?
Why not use a sequence of instructions to express the behavior of a billion parts that all move at the same time?
Haskell's syntax and interpreter/compiler tool chain, or any other programming language for that matter is designed to be transformed into machine intructions. Why not use the same syntax and tools to design the hardware that executes those instructions?
Because software design is an abstraction of something inherently sequential, and hardware design is an abstraction of something inherently parallel, massively parallel. Software is "simply" varying voltage levels that represent 0s and 1s, flowing through a labyrinth of billions of transistors in rhythm, all at the same time. The rhythm they are flowing to is the clock frequency. The massively parallel labyrinth is the hardware.
This answer is getting a bit long, but it doesn't even begin to uncover the complexities of hardware. Hardware designers of state-of-the-art chips have to consider things like running different parts of a chip at different clock frequencies, turning parts of for microseconds at a time when they are not used so the chip doesn't burn up, account for the fact that 0s and 1s won't arrive at the intended destination at the same time due to wire length and how "deep" the logic gate network is, and taking these things into consideration when they decide where to physically place parts of a chip.
Nah, you didn't miss anything obvious. To miss something obvious is either subjective, a contradiction in terms or context-dependent. The differences between a programming language and a hardware description language wasn't obvious to you. It is to me.
Does the context of HN assume knowledge of this difference? I sure hope the answer is No! Don't apologize for asking "dumb" questions. I do it frequently, because I learned long ago that I'll likely learn something. More often than not it also turns out that I wasn't the only one confused. The others just didn't know it, or were too afraid to admit it.
Embrace your inner n00b. Ask "dumb" questions. :)
(note: You may very well know some of this already, but it wasn't obvious to me. I seized the opportunity to write an extensive explanation that I hope will help others as well.)
