Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Verilog Is Weird

danluu.com

Post reply on HN
Print view View original

101–110 of 131 posts

Re: Verilog Is Weird

#101

Post by IshKebab »

tails4e wrote: post #14

Any idea when this was written? It seems a bit out dated, and I'm especially surprised at the mention of hardware companies not using linters, that seems insane to me. Lint, Logic Equalivance, CDC, etc are all absolutely required sanity checks on hardware design, irrespective of the language. Also SystemVerilog is quite esperessive. I definitely agree Verilog has many pitfalls you basically get used to and know to av…

SystemVerilog is too expressive. It has more language features and syntax than anything else by an order of magnitude. So insanely complicated.

I can't see anything dethroning it without multivendor support though. Verilator is not enough - you need GUI tools, formal, coverage, etc. and that pretty much means you're stuck with SV.

Re: Verilog Is Weird

#102

Post by apienx »

Title should say "hardware description languages are weird for software people". JS guys have it easier, but for the rest, it takes time to rewire (no pun intended) your brain to think in async terms.

Re: Verilog Is Weird

#103

Post by mrintellectual »

apienx wrote: post #102

Title should say "hardware description languages are weird for software people". JS guys have it easier, but for the rest, it takes time to rewire (no pun intended) your brain to think in async terms.

A concise but not-completely-accurate way I explain it to a lot of pure software folks is that every line of HDL code executes "simultaneously". This can sometimes help them wrap their heads around Verilog/VHDL a bit better.

Re: Verilog Is Weird

#104

Post by jeffreygoesto »

mrintellectual wrote: post #103
apienx wrote: post #102

Title should say "hardware description languages are weird for software people". JS guys have it easier, but for the rest, it takes time to rewire (no pun intended) your brain to think in async terms.

A concise but not-completely-accurate way I explain it to a lot of pure software folks is that every line of HDL code executes "simultaneously". This can sometimes help them wrap their heads around Verilog/VHDL a bit better.

I once read "software describes what the machine shall do, HDL describes, what it shall _be_" and found that pretty accurate.

Re: Verilog Is Weird

#105

Post by jiggawatts »

rowanG077 wrote: post #74
magicalhippo wrote: post #73

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…

That function example is not allowed in Haskell. It's pure functional throughout, not just at "function boundaries".

I agree that conceptually a language can be made where only function boundaries are required to be side-effect free, and internally "anything goes" as long as it doesn't pollute the outside world. This might be a good model for circuit design, especially if using something like an IO monad to store persistent state across clocks, such as flip-flops or registers.

However, this is not what Haskell does, at all. There are no mutation functions like "fill(x)". You have to create the buffer filled with x right from the beginning.

More importantly, in Haskell that buffer is defined with a recursion, so it looks something like: (x,(x,(x)))

Effectively it is an immutable linked list. Any modification involves either rebuilding the whole thing from scratch (recursively!) or making some highly restricted changes such as dropping the prefix and attaching a new one, such as (y,(x,(x))).

Haskell is not LISP, F#, or Clojure. It's pure and lazy, which is very rare in functional programming. It's an entirely different beast, and I don't see how any variant of it is a good fit for circuit design, which is inherently highly stateful and in-place-mutable.

Re: Verilog Is Weird

#106

Post by gh02t »

hyperman1 wrote: post #64
gh02t wrote: 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

Because the logic inside blocks can contain constructs that do stuff that aren't expressible as physical hardware, but are useful for other purposes/otherwise expressible in Verilog (some people think it's an anti-feature such things are even possible to express, but it's open to debate). You still have to implement the content of the blocks somehow, be it grabbing it from a library or writing the logic yourself. I didn't mean to imply that Verilog/VHDL are purely piecing together functional blocks. It's just one of the main abstractions to allow you to compartmentalize, like implementing functions that you can reuse in a traditional programming language. The other reply also goes into some good examples.

You could of course only build on top of very simple blocks that are trivially correct like say piecing together logic gates and other very simple circuit elements, but that kinda defeats the purpose of using an HDL and doesn't scale well. Some of the blocks you get included with your development tools might be quite complex, e.g. entire complex DSP operations that are designed to exploit specific hardware features of your target.

Re: Verilog Is Weird

#107

Post by jwilk »

shadowgovt wrote: post #94
jwilk wrote: post #5

> maybe try copy+pasting that URL That doesn't work either, because the generator dropped the underscore. http://en.wikipedia.org/wiki/Flip-flop_(electronics) Hugo would normally handle such links fine, but earlier on there's an unescaped underscore in "d_out", which makes it go off the rails.

And hugo is technically correct (the best kind of correct) in that parens are in the sub-delims reserved set of characters for HTML ( https://www.ietf.org/rfc/rfc3986.txt section 2.2), and since they're being used in a context where the enclosing language considers parens to have special meaning, they should be octet-encoded in the hugo file. (In practice, my experience with hugo is that it will generally get them ri…

On the contrary, because parentheses are reserved, percent-encoding them is not necessarily safe:

> Percent-encoding a reserved character, or decoding a percent-encoded octet that corresponds to a reserved character, will change how the URI is interpreted by most applications.

https://datatracker.ietf.org/doc/html/rfc3986#section-2.2

Re: Verilog Is Weird

#108

Post by ghettoimp »

jgeada wrote: post #99

This article starts out by assuming that understanding sequential programming is sufficient to understand hardware. Yes, Verilog is a simulation description language, and yes, it can be compiled to hardware. But it is a specific subset that translates to hardware, not the whole language. Large parts of Verilog/SystemVerilog exist to drive stimulus into the model hardware and to observe the results; those parts don't…

Counter-opinion: industry simply has no plausible alternative to Verilog/SystemVerilog and succeeds in producing chips only in spite of the language's glaring flaws.

I worked for several years at a world class company verifying CPU designs. Even into the late 2010s, designers were afraid to use basic features like structs because who knows what tool might not support it correctly. They emulated structures using piles of defines that set all the bit offsets. I wouldn't know how to begin to estimate the amount of senseless work that this led to during debugging. The lack of any type safety was appalling. If you were lucky, you could catch gross type confusion by having a linting tool notice a size mismatch. These tools found hundreds of real errors that should never have compiled in the first place. I could go on and on...

But there's no escaping it. There are so many amazing tools built around it. The vendors love the moat the complexity gives them. The IP developers have huge investments in legacy code bases. Compatibility is worth too much.

Re: Verilog Is Weird

#109

Post by rowanG077 »

jiggawatts wrote: post #105
rowanG077 wrote: post #74

Earlier quoted context omitted.

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…

That function example is not allowed in Haskell. It's pure functional throughout , not just at "function boundaries". I agree that conceptually a language can be made where only function boundaries are required to be side-effect free, and internally "anything goes" as long as it doesn't pollute the outside world. This might be a good model for circuit design, especially if using something like an IO monad to store pe…

Such a function is perfectly allowed and even encouraged, see here where I allocate a mutable array with undefined values and write and read from it in a pure function. Basically replicating the pseudo imperative code I have written before:

https://replit.com/@RowanGoemans/QuarrelsomeUtilizedMicroker...

Using mutable vectors like this is a must if you need to write high performance Haskell code.

I have also written concrete code for magicalhippo in another branch of this thread.

Re: Verilog Is Weird

#110

Post by magicalhippo »

rowanG077 wrote: post #97
magicalhippo wrote: post #92

Earlier quoted context omitted.

I think I get what you're getting at. Still, I would be very interested to see how one would implement a shift register, lets say something like the 74HC165, so I can see how the pure functions interact with the register state.

Here is a simple 64 bit shift register: https://replit.com/@RowanGoemans/AlarmedNutritiousVisitors#m... Runnable using replit. To make it as simple as possible I didn't use Clash and used types available in prelude Haskell (Bool instead of bit, 64 bit integer as register state etc. Every single element in the list represent a value coming out of the register on the rising edge of a clock cycle. You can easily extend…

Much appreciated. I think I get the gist of it, even though it looks very complex compared to the Verilog counterpart. To be fair, my lack of Haskell knowledge doesn't help.

But it's really helpful to get a feel for the different approach.

Post reply on HN