Live data from Hacker News

Why hardware development is hard: Verilog is weird

danluu.github.io

31–40 of 54 posts

Re: Why hardware development is hard: Verilog is weird

#31
post #11
post #2

The problem is that Verilog/VHDL isn't a "programming language" in the sense that C, Lisp, Haskell, or Python are programming languages. So approaching them with a programming language mindset is asking for a lot of pain and misunderstanding. HDLs like Verilog and VHDL describe digital circuits, not algorithms and instructions for manipulating data. If C code is akin to instructions for getting to a grocery store and…

Just chiming in with the standard Lisp response: HDL's can be done in Lisp, and have been done in Lisp. You just define a DSL for it.

At least since the 1980's, see AIM-953.

Re: Why hardware development is hard: Verilog is weird

#32
So um, why do they hate Haskell?

"it's politically difficult", "scary", "one person suggested banning any Haskell based solution"

Just going by his description (as I don't know much about hardware design except a single uni course ~15 years ago), it sounds as if a functional programming language like Haskell would be a perfect fit?

"one person suggested banning any Haskell based solution" -- that's pretty much literally calling a taboo on Haskell.

The article doesn't really name any reasons for this, can anyone here explain, maybe?

The only reason I can imagine would be perhaps that if you've got some seasoned veteran hardware developers living breathing verilog that are used to doing it "this way" for decades, they will be adverse to change, especially if it means learning a new programming language, perhaps in particular if it means a new paradigm or because of Haskell's pure/mathematical/function theoretical bend? (I'm just guessing here)

However (and this is where I'm most probably certainly wrong), if you're developing systems that cost 8 figures to prototype, and the current solutions are super slow and/or inaccurate to test, shouldn't even seasoned veterans, at least some of them, be able to swallow their pride?

Re: Why hardware development is hard: Verilog is weird

#33

So um, why do they hate Haskell? "it's politically difficult", "scary", "one person suggested banning any Haskell based solution" Just going by his description (as I don't know much about hardware design except a single uni course ~15 years ago), it sounds as if a functional programming language like Haskell would be a perfect fit? "one person suggested banning any Haskell based solution" -- that's pretty much litera…

Functional programming doesn't make sense for this sort of thing as you can't define a circuit recursively. Mitrion-C is an example of a higher-level functional language aimed at configuring FPGAs. It's pretty useless unless you have insider knowledge on how the system works.

Re: Why hardware development is hard: Verilog is weird

#35

So um, why do they hate Haskell? "it's politically difficult", "scary", "one person suggested banning any Haskell based solution" Just going by his description (as I don't know much about hardware design except a single uni course ~15 years ago), it sounds as if a functional programming language like Haskell would be a perfect fit? "one person suggested banning any Haskell based solution" -- that's pretty much litera…

Functional programming doesn't make sense for this sort of thing as you can't define a circuit recursively. Mitrion-C is an example of a higher-level functional language aimed at configuring FPGAs. It's pretty useless unless you have insider knowledge on how the system works.

> you can't define a circuit recursively

Could you elaborate on this? Depending on what you mean, I might have a direct counter-example.

Re: Why hardware development is hard: Verilog is weird

#36

Earlier quoted context omitted.

Functional programming doesn't make sense for this sort of thing as you can't define a circuit recursively. Mitrion-C is an example of a higher-level functional language aimed at configuring FPGAs. It's pretty useless unless you have insider knowledge on how the system works.

> you can't define a circuit recursively Could you elaborate on this? Depending on what you mean, I might have a direct counter-example.

please show that example anyway :P pretty sure skylan_q means you'd run out of hardware gates if you try something infinite?

Re: Why hardware development is hard: Verilog is weird

#37
post #36

Earlier quoted context omitted.

> you can't define a circuit recursively Could you elaborate on this? Depending on what you mean, I might have a direct counter-example.

please show that example anyway :P pretty sure skylan_q means you'd run out of hardware gates if you try something infinite?

Well, you can define a combinational circuit as something that has n inputs and m outputs and it is one of:

* a gate,

* a circuit that takes two inputs and produces two outputs by swapping the order,

* a circuit that takes one input and produces one output,

* a circuit that takes one input and produces no outputs,

* the circuit obtained by taking two circuits and composing them in serial,

* the circuit obtained by taking two circuits and composing them in parallel.

This produces a simple inductive definition for combinational circuits. Synchronous, sequential circuits can be obtained by taking a combinational circuit and connecting the first n outputs to the first n inputs via D flip-flops. If you want asynchronous circuits, you can add another combinator that takes a circuit and a connects the first n outputs to the first n inputs without the flip-flops.

With these definitions, it's quite straight forward to manipulate circuits in a functional manner.

Re: Why hardware development is hard: Verilog is weird

#38

So um, why do they hate Haskell? "it's politically difficult", "scary", "one person suggested banning any Haskell based solution" Just going by his description (as I don't know much about hardware design except a single uni course ~15 years ago), it sounds as if a functional programming language like Haskell would be a perfect fit? "one person suggested banning any Haskell based solution" -- that's pretty much litera…

> "one person suggested banning any Haskell based solution" -- that's pretty much literally calling a taboo on Haskell.

Personally, I would love to call this nonsense out: Say, "OK, you get to lead a team that is prohibited from using any Haskell-based solution. My team will compete with yours and must use a Haskell-based solution. May the best team win."

Re: Why hardware development is hard: Verilog is weird

#39

Earlier quoted context omitted.

Functional programming doesn't make sense for this sort of thing as you can't define a circuit recursively. Mitrion-C is an example of a higher-level functional language aimed at configuring FPGAs. It's pretty useless unless you have insider knowledge on how the system works.

> you can't define a circuit recursively Could you elaborate on this? Depending on what you mean, I might have a direct counter-example.

A circuit that calculates the nth Fibonacci number or performs quicksort. I imagine any synthesis would have to generate something that is effectively an iterative solution: instead of producing n identical circuit blocks for n calls of the function, it would only have one circuit used over and over again. But this defeats the ability to exploit the potential parallelism that could be achieved in the execution of the algorithm.

Re: Why hardware development is hard: Verilog is weird

#40

Earlier quoted context omitted.

given how difficult hardware synthesis with existing HDLs is right now I don't know if that'll happen anytime soon Synthesis sometimes feels like a great blind spot in the hierarchy of abstractions. It is hard, critical, and yet appears to be developed only by niche players. the fact that logic takes so long to synthesize and simulate really has little to do with Verilog's deficiencies IMO it has everything to do wit…

I think the issue here is that Synthesis and Place and Route tools are squarely in the Computer Science Algorithms domain. Hardware engineers in general don't have the background for that kind of work. And software engineers don't crossover to the hardware side often. So the people suffering with the "slow" tools etc, are usually not in a very good position to do anything about it. But really, the slow side is in the…

IIRC, most of the time these just end up boiling down to 3-SAT, which will make the average Computer Science person throw up their hands in the air and say "it's NP-Hard, you can't make it more efficient" (even though NP is still an open problem).

I think there's one EE/CE professor at my university working on the SAT solvers that form the crux of the optimizers in most of these tools, but at the end of the day it's still a bunch of heuristics that, worst case, run in O(2^n) time.

Post reply on HN