Hacker News Reader

Comment by noescape | Hacker News Reader

Is it impossible to do hardware development in C and automatically convert C to Verilog? https://en.wikipedia.org/wiki/C_to_HDL

What does one lose if they do this? Why isn't this conversion more common?

View on HN

>Is it impossible to do hardware development in C and automatically convert C to Verilog?

Yes, it is. C can be converted to Verilog only if you structure the C code as if it were Verilog.

You have to understand that, fundamentally, the CPU is a lie. It is an illusionary abstraction layer fashioned out of bare transistors that pretends to be a von Neumann architecture machine, with a nice set of registers, a instruction pointer, and so forth that chugs dutifully through assembly language instructions, one after another. (Note that nothing about the von Neumann architecture requires binary; for example, the Babbage Analytical Engine computed in decimal.)

At the transistor / gate level, _everything_ is parallel until you impose some order on it and build in clocks and flipflops and so forth to impose some sort of structure and chronological ordering on things. Few, if any, high-level languages are equipped to describe that in any sensible way.

Verilog, VHDL, and so forth are not "weird". These HDLs, while not without their warts, describes the underlying reality of computing. It is assembly language and the high-level languages that are "weird".

(edit: grammar fixes + clarifications)

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.

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.

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!

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.

You know how you can't just compile normal C to a GPU and expect a speed up because the underlying computational models are so different? It's like that, just a few orders of magnitude worse.

To look at it another way, what does one gain? Hardware is highly parallelizable and HDLs give you that capability by default. Verilog is a really easy language to learn. The hard part is learning how to do hardware design.

One gains not needing to learn another language. I know C, I don't know Verilog or VHDL. I know how to debug C, I don't know how to debug Verilog.

If I can write a working C program, why can't I make working hardware?

Knowing how to debug C won't help you. There is no state machine running your code. Stepping through instructions doesn't apply.

Debugging HDL involves looking at timing waveforms in a simulator.

Could one write a state machine running the code? VMs do.

You can do a lot with Verilog as long as you don't intend for it to run on an actual FPGA. You can initialize registers to values, print to a console, and add in hardware delays for timing. Simulation is what Verilog was meant to do in the first place. Once you want to actually synthesize the code and run it on some hardware, you have to get more creative in how you layout your code. Like having a reset input for the module so it can trigger certain events whenever you want (i.e. register initialization). So when you write your testbench, you must activate the reset input (or have something similar to a reset button on your actual hardware) before trying to use the module otherwise all the registers will just have random junk values. In my class projects we would always have a dedicated reset button on the board that would need to be pressed before you could test the design. In a production design, the reset would be tied to some sort of automatic reset (like a one shot timer or a microcontroller) when the device powers up.

Reply on news.ycombinator.com