[joesavage]

Perhaps I'm reading too far into what you wrote, but I'm not sure I agree that the CPU is fundamentally different from other layers of abstraction in computer systems.

All abstractions “lie” in the sense that they present a perspective of the world that is slightly different to the reality — function calls “lie” about the operations that are really being performed, the ISA “lies” about the electronics of the CPU, and transistors “lie” about the underlying behaviour of the universe.

[moftz]

With a CPU, everything is done procedurally. With an FPGA, all the code kind of runs at once. You build your modules and wire them together. The state of the HDL layout is static. There is no stack or heap. If a module is turned on, its doing whatever its supposed to do all the time no matter if you are feeding a real signal into it or not. Imagine threading every possible function you might need in a typical C program and "wiring" everything up with global variables that cannot be initialized at startup. Printf is always printing something and will print out some random garbage at startup unless you tell it to print something else. Simulating larger HDL designs takes a lot of memory because you have to model everything throughout the entire simulation. Simulating a CPU in something like C is much less intensive since you can call an instruction whenever you are ready for it.

[joesavage]

I completely appreciate that “writing hardware” is a totally different problem to writing software, and that hardware comes with its own set of quirks and challenges. I'm just saying that I don't think the CPU is fundamentally different than other abstractions in the stack.

C obviously isn't a good fit for a hardware language — it's designed for software! That doesn't mean that there doesn't exist similarly abstract ways of writing hardware though (that express the inherent parallelism, etc.). It is likely that these “higher level languages for hardware” would result in less efficient hardware solutions, but that's always a trade-off that is made through abstractions. Writing a program in properly scheduled assembly code is going to be a lot more efficient than writing the same program in C.

The difference with hardware in terms of language abstractions is not that it behaves differently to software. We could easily define a programming language that expresses parallelism in a way that would map nicely to hardware. The problem, from my perspective at least (please correct me if you think I'm wrong) is that hardware needs to be extremely efficient — particularly because it cannot be easily changed. As a result, hardware languages don't tend to be particularly abstract. But this doesn't mean that hardware languages couldn't be more abstract!

[moftz]

Probably the highest level of abstraction for Verilog is using something like Altera's IP cores. They are binary blobs intended for a specific FPGA model that can be hooked up like any other module but they are configurable for things like bandwidth, latency, and various inputs. You can use things like floating point arithmetic modules or cores used to create things like phase locked loops, a way to convert an input frequency to a different frequency typically using a multiplier and divider. You don't need to know how these modules work underneath, its proprietary anyway but there are usually reference designs you can look at. For example, with a few clicks you can create something like a VGA driver that could interface with a synthesized CPU to create a terminal for it. You can do some neat things with IP cores but there are probably some issues with using them in a commercial form.