Live data from Hacker News

Verilog Is Weird

danluu.com

71–80 of 131 posts

Re: Verilog Is Weird

#71
post #52
post #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 what…

No, the problem with Verilog is that it tries to be a procedural language like C when digital circuits are inherently parallel and declarative (sequential circuits just being special cases with feedback). VHDL is better, but still pretty bad. Learning digital circuit design on FPGAs would be so much easier if there was a well supported hardware description language that isn't stuck in the 1980s.

You have high-level-synthesis tools on many FPGA vendors tools, using C/C++ or even Python for hardware description. I personally don't think they are superior than typical HDLs, the thing that makes the difference is to think about the circuit you ought to describe, the language you use then is not as important IMHO.

Re: Verilog Is Weird

#72
post #48

Earlier quoted context omitted.

I think you mean block based designs where you define blocks as inputs and outputs with the logic inside, and then you can piece together and group blocks with wires possibly in some sort of visual editor or similar format? This is already how Verilog and VHDL work, they are oriented around functional blocks that you wire together to build up more complex units. Often HDL environments ship libraries of pre-made block…

The different would be that it is never possible to have an unsynthesable design, as long as everything connects together. So the problem designed in the article can't happen if you only have blocks and wires. Maybe a rephrased question is, what causes Verilog or VHDL to be unsynthesable if they are based on this style of block design

There are lots of reasons why some HDL could be unsynthesizable:

- multi-driven nets where two or more signals are driving the same node

- the target not supporting certain features like multi-clocked FFs

- missing components or libraries (not uncommon if you're trying to use VHDL 2008, for example)

- timing analysis failing, meaning the HDL isn't fast enough / the critical path is too long for how fast the fpga is going to go

And while not necessarily being unsynthesizable, a lot of tools like Vivado will heavily optimize the HDL, meaning if you forget to connect a part of the HDL to the output or do something with it, it will be removed from the design.

Re: Verilog Is Weird

#73
post #40

Earlier quoted context omitted.

> Why do you feel there is a mismatch? Can this be because in digital circuits state (memory) plays an important role, while its treatment in a (pure) functional language is not straightforward?

It's straightforward to implement memory in a pure function. For example if you say a digital circuit is a function from infinite list of inputs to an infinite list of outputs. You can create a "register" by simply adding a value to the start of the list. For example in Haskell: delayCircuit xs = 0:xs take 10 (delayCircuit [1..]) -- [0,1,2,3,4,5,6,7,8,9] Whether a function is pure doesn't mean it can't have internal…

> Whether a function is pure doesn't mean it can't have internal state.

This seems to be in direct contradiction to what is written on Wikipedia[1], specifically that "the function return values are identical for identical arguments".

If it has non-trivial internal state, how can it return identical values for identical inputs?

Sadly your example eludes me as I don't know any Haskell so it reads like line noise.

[1]: https://en.wikipedia.org/wiki/Pure_function

Re: Verilog Is Weird

#74

Earlier quoted context omitted.

It's straightforward to implement memory in a pure function. For example if you say a digital circuit is a function from infinite list of inputs to an infinite list of outputs. You can create a "register" by simply adding a value to the start of the list. For example in Haskell: delayCircuit xs = 0:xs take 10 (delayCircuit [1..]) -- [0,1,2,3,4,5,6,7,8,9] Whether a function is pure doesn't mean it can't have internal…

> Whether a function is pure doesn't mean it can't have internal state. This seems to be in direct contradiction to what is written on Wikipedia[1], specifically that "the function return values are identical for identical arguments". If it has non-trivial internal state, how can it return identical values for identical inputs? Sadly your example eludes me as I don't know any Haskell so it reads like line noise. [1]:…

It does have identical return values for identical arguments. That doesn't mean the function can't have internal state. Maybe this is more clear in pseudo code:

    withInternalState(x):

        buf = Int[100000]

        buf.fill(x)

        return buf.sum()
The function is pure yet it uses a very large buffer as internal state. That is the same as a circuit that has a internal state(== memories).

Could you give a description of a circuit that isn't pure, maybe we are talking past eachother.

Re: Verilog Is Weird

#75

Earlier quoted context omitted.

> Whether a function is pure doesn't mean it can't have internal state. This seems to be in direct contradiction to what is written on Wikipedia[1], specifically that "the function return values are identical for identical arguments". If it has non-trivial internal state, how can it return identical values for identical inputs? Sadly your example eludes me as I don't know any Haskell so it reads like line noise. [1]:…

It does have identical return values for identical arguments. That doesn't mean the function can't have internal state. Maybe this is more clear in pseudo code: withInternalState(x): buf = Int[100000] buf.fill(x) return buf.sum() The function is pure yet it uses a very large buffer as internal state. That is the same as a circuit that has a internal state(== memories). Could you give a description of a circuit that i…

What I was thinking of was more like a linear shift feedback register. It has zero inputs and outputs random bits, thanks to its non-trivial internal state.

Or as we were saying, a register. Could for example be a function which takes a read/write flag and a value, writes the value to the internal state if write flag is set, and returns the internal value.

edit: In my softcore I have a function to read/write registers, it modifies global state rather than internal state so would not be pure either.

edit2: I guess my point is, for me "state" is something that is non-trivial, and retained between invocations. Your example is trivial and not retained (it's completely overwritten always).

Re: Verilog Is Weird

#76
post #31
post #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 what…

> 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 Yes, and per the other comment this is a huge limitation of them - you don't have Javascript authors saying "you need to work out what you want in this other paradigm and then translate it". You occasionally see people writing C this way though, by working out what they want from th…

> 'you don't have Javascript authors saying "you need to work out what you want in this other paradigm and then translate it"'

Well, React with the hooks API has basically become that. You need to imagine your code first as computational effects triggered by state dependencies in an implicit stack, and then you translate that into a language where all of that must be represented as either calling functions or passing functions around.

Re: Verilog Is Weird

#77
post #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 what…

>> always @(posedge clk) Is there an option for bothedge clk?

It's not synthesizable, but you could say "always @(clk)" as well.

Re: Verilog Is Weird

#78
post #51

Related: https://insights.sigasi.com/opinion/jan/verilogs-major-flaw/ This is why if you want complete determinism, use VHDL. Unlike verilog, VHDL was developped specifically for describing hardware behavior.

VHDL springs off of ADA, so I wouldn't say it was specifically developed. Anyway, ADA and VHDL are strongly typed, which incidentally works well with critical applications development such as hardware design.

Re: Verilog Is Weird

#79

If anyone is interested in alternatives to Verilog, check out PipelineC. Great for software folks getting into hardware, helps avoid issues like blocking vs non blocking confusion, whats a register, etc. Lots of other features too. https://github.com/JulianKemmerer/PipelineC/wiki

Maybe you should add a disclaimer, "this is my project" :)

Re: Verilog Is Weird

#80
post #11
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…

Logged in just to upvote this and largely agree with you. Verilog/VHDL are stuck at the 1980s coding paradigm level, as if the industry grabbed the first working solution for automated hardware developement and has clung on to it. > The problem is, it is hard, if not downright impossible, to get the industry to change. Yes. I don't think it will until either, say, Intel does it by CEO fiat, like the Amazon memo, or a…

> The hardware industry can't benefit from rapid iteration because every iteration costs a mask set.

Before tapeout there are steps which could benefit I suppose. But as a functional-programming n00b I don't see how that could be the solution. I would argue that improving place and route algorithms to the point that deploying to a (large) FPGA is almost as quick as compiling software would be a huge step forward.

Post reply on HN