Live data from Hacker News

Verilog Is Weird

danluu.com

21–30 of 131 posts

Re: Verilog Is Weird

#21
post #6

Oh boy, this is a sore subject for me. It's pretty obvious that Verilog and VHDL, modeled after C and Ada respectively, both imperative languages, follow a drastically mismatched paradigm for hardware design, where circuits are combined and "everything happens in parallel". It becomes even more obvious when you have tried a functional alternative, for example Clash (which is essentially a Haskell subset that compiles…

One thing I don't quite understand about using Haskell for circuit design is that at a first glance it also seems like pure functional programming has an impedance mismatch with what the circuitry physically does. (For reference, I've programmed in Haskell extensively before.) For example, much of Haskell directly or indirectly relies on recursion -- but this nearly nonsense when talking about silicon! There's no cal…

Why do you feel there is a mismatch? Any digital circuit can be modeled with a pure function that transforms an input stream of values to an output stream of values. And that is actually precisely what Clash does.

Regarding recursion. I believe Clash does support a limited form of recursion. Namely if you prove every recursive call leads to the problem size strictly decreasing. e.g. recursion on a vector of size n must mean every recursive call is applied to a vector of smaller size.

Re: Verilog Is Weird

#22
post #6

Oh boy, this is a sore subject for me. It's pretty obvious that Verilog and VHDL, modeled after C and Ada respectively, both imperative languages, follow a drastically mismatched paradigm for hardware design, where circuits are combined and "everything happens in parallel". It becomes even more obvious when you have tried a functional alternative, for example Clash (which is essentially a Haskell subset that compiles…

Verilog definitely sucks but I think the problem with new HDLs (Clash, Bluespec, Chisel etc) is they don't necessarily make the hard bits of hardware design easier, they just help with the tedious stuff that whilst annoying ultimately doesn't take up much of your time. For example a good type system definitely makes module interfaces cleaner, saves you having to dig through warnings/lint reports to find stupid errors…

Wow, didn't know that Bluespec was open sourced. I used in my Computer Architecture class for assignments 6 years ago, and my experience was that it was much much better than Verilog (the type system was far better) but there was too little learning material/documentation out there on the Internet.

Re: Verilog Is Weird

#23

Earlier quoted context omitted.

One thing I don't quite understand about using Haskell for circuit design is that at a first glance it also seems like pure functional programming has an impedance mismatch with what the circuitry physically does. (For reference, I've programmed in Haskell extensively before.) For example, much of Haskell directly or indirectly relies on recursion -- but this nearly nonsense when talking about silicon! There's no cal…

Why do you feel there is a mismatch? Any digital circuit can be modeled with a pure function that transforms an input stream of values to an output stream of values. And that is actually precisely what Clash does. Regarding recursion. I believe Clash does support a limited form of recursion. Namely if you prove every recursive call leads to the problem size strictly decreasing. e.g. recursion on a vector of size n mu…

How does (non-tail) recursion work there. That inherently requires a stack, unless you limit the recursion depth and give each recursion step its own circuit.

I could imagine limiting yourself to a specific subset of haskell keeps things under control, but the mis-match seems obvious. At least from the pov "just write haskell but compile to an fpga instead of a binary".

Re: Verilog Is Weird

#24
I think that really the hard part of learning to design chip stuff really is other stuff - understanding where/how to use storage (flops) and combinatorial logic - and simultaneity: how to handle things that happen at the same time.

Initially you really need a strong understanding of digital logic (not a language), in particular pipelines.

Once you have that stuff in your head you can turn to verilog (or vhdl or whatever) and learn how to map these ideas into the language

In System Verilog it's easy this is the only way to reliably make synthesisable flops:

    bit a, b;
    always @(posedge clk)
         a 
And you can make combinatorial logic 2 ways:

    wire c; bit d;
    assign c = a&b;
    always @(*)
        d = a&b;
They'll make the same gates, notice the use of = vs "always X" just means loop waiting for X, '*' means "anything important changes"

That's it, the most important concepts you have to get your head around, everything else is just this at scale - also please ignore the async reset in the "Verilog is Weird" example - they tend to be timing nightmares in the real world, use a synchronous reset instead.

One more thing - Verilog is an early object oriented language - modules are objects - but they are static, the entire design can be elaborated at compile (or synthesis) time - why? because you can't new or malloc more gates on the fly on a real chip - almost everything in verilog is static by design (it does support local variables in functions but anything that's vaguely recursive wont make gates in synthesis)

Re: Verilog Is Weird

#25
post #6

Oh boy, this is a sore subject for me. It's pretty obvious that Verilog and VHDL, modeled after C and Ada respectively, both imperative languages, follow a drastically mismatched paradigm for hardware design, where circuits are combined and "everything happens in parallel". It becomes even more obvious when you have tried a functional alternative, for example Clash (which is essentially a Haskell subset that compiles…

> So that basically leaves the intersection of people that are both enthusiastic software engineers with an affection for e.g. Haskell, and also enthusiastic in building hardware. But outside of my own projects, it just leaves me longing for the world that could exist.

It seems to me that a shop made exclusively of people with this background would be massively more productive, and quite an attractive place to work for anyone with the relevant skill sets.

What keeps such a shop from existing? The need for domain specific knowledge? Or does scale require too many people? Are hardware design shops usually in house and thus harder to out-source? General worries about communicating with customers expecting verilog? Worries about being able to on-board new people?

Honestly, despite all of the above, I think a haskell based FPGA quick itteration hardware design shop sounds amazing. If I had any kind of experience with hardware design I would jump at the chance to join. Even without that experience this sounds worth a shot, but I fear that lack of experience might be why I think this is feasible.

Re: Verilog Is Weird

#26
post #18
post #12

Earlier quoted context omitted.

It's remarkably strange that someone who appears to be blogging semi-professionally thinks it's reasonable to publish an article of this sort without a date attached. Maybe Verilog doesn't change much, but statements like "Commercial vendors are mostly moving in the other direction" and "There have been a number of attempts [...] but they've all fizzled out" are date-sensitive.

>It's remarkably strange In the old days there was a movement / trend / opinion / hype cycle ( or whatever you want to call it ) that articles without date was a way to make it ever green.

I wonder if this is similar reasons to why lots of CS papers seem to never have the date on?

Re: Verilog Is Weird

#27
post #23

Earlier quoted context omitted.

Why do you feel there is a mismatch? Any digital circuit can be modeled with a pure function that transforms an input stream of values to an output stream of values. And that is actually precisely what Clash does. Regarding recursion. I believe Clash does support a limited form of recursion. Namely if you prove every recursive call leads to the problem size strictly decreasing. e.g. recursion on a vector of size n mu…

How does (non-tail) recursion work there. That inherently requires a stack, unless you limit the recursion depth and give each recursion step its own circuit. I could imagine limiting yourself to a specific subset of haskell keeps things under control, but the mis-match seems obvious. At least from the pov "just write haskell but compile to an fpga instead of a binary".

Sorry, I edited my comment and added a part about recursion.

So you are right that not all of Haskell is compileable using Clash. But that also isn't the goal. You are using Haskell to describe your digital circuit. That generally is very different from writing a normal Haskell program. It just so happens that Haskell is good at both.

Re: Verilog Is Weird

#28
post #26
post #18

Earlier quoted context omitted.

>It's remarkably strange In the old days there was a movement / trend / opinion / hype cycle ( or whatever you want to call it ) that articles without date was a way to make it ever green.

I wonder if this is similar reasons to why lots of CS papers seem to never have the date on?

Some academic types seem to believe that no paper should ever bear a date other than the date of formal publication. Not quite sure why that is, the date of a draft seems like incredibly helpful information to me.

Re: Verilog Is Weird

#29
post #3
post #2

When you design hardware you need to take into account all possible input and output values. This shall be done also for SW but ...

that's we use formal verification or formal contracts, not just test driven development. do we, or am I alone on this?

Are you even doing it for all your code ... come on be honest ;)

Re: Verilog Is Weird

#30

Earlier quoted context omitted.

Verilog definitely sucks but I think the problem with new HDLs (Clash, Bluespec, Chisel etc) is they don't necessarily make the hard bits of hardware design easier, they just help with the tedious stuff that whilst annoying ultimately doesn't take up much of your time. For example a good type system definitely makes module interfaces cleaner, saves you having to dig through warnings/lint reports to find stupid errors…

Wow, didn't know that Bluespec was open sourced. I used in my Computer Architecture class for assignments 6 years ago, and my experience was that it was much much better than Verilog (the type system was far better) but there was too little learning material/documentation out there on the Internet.

Bluespec was not open sourced.

There is now an open-source Bluespec compiler based on the little public information that is available about Bluespec.

So it is likely that it is not compatible with the full Bluespec, even if can synthesize published examples of Bluespec.

There are some research papers and the code at:

https://www.cl.cam.ac.uk/~djg11/wwwhpr/toy-bluespec-compiler...

Post reply on HN