13 ms·

Verilog Is Weird

162 points by fzliu 5y ago

hulitu 5y ago
When you design hardware you need to take into account all possible input and output values. This shall be done also for SW but ...
- rurban 5y ago
  that's we use formal verification or formal contracts, not just test driven development. do we, or am I alone on this?
  - captaincaveman 5y ago
    Are you even doing it for all your code ... come on be honest ;)
deleted 5y ago
[deleted]
jwilk 5y ago
> 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) 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.
- shadowgovt 5y ago
  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 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 right if you use them anyway, but it risks mis-parsing).
  - jwilk 5y ago
    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 https://datatracker.ietf.org/doc/html/rfc3986#section-2.2
    - shadowgovt 5y ago
      That is, unfortunately, one of those chunks of English that is hard to interpret. "Safe" here isn't really what the RFC is talking about; the RFC is saying that if you take a URI and add or remove percent encoding for those characters, you might change the way that the URI is interpreted (because those characters mean something in the enclosing context). In other words, you can't encode or decode them without risking a change to the interpretation, but whether encoding or decoding is "safe" is going to be context-specific (broadly speaking, the safest thing to do is to encode them and leave them encoded).
      - jwilk 5y ago
        It happens that Wikipedia doesn't care whether parens are percent-encoded or not. So yes, you can use %28%29 instead (), but that's despite them being sub-delims. For example, you definitely should change & (another sub-delim) to %26 in your URLs. And, as I noted earlier, escaping parens wouldn't even help in this case, because it's an underscore that causes the mess.
anyfoo 5y ago
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 to Verilog/VHDL: https://clash-lang.org https://clash-lang.org). The problem is, it is hard, if not downright impossible, to get the industry to change. I have heard many times, in close to literally these words: "Why would I use any language that is not the industry standard". And that's a valid point given the current world. But even for people that are interested, it might just be hard to switch to something like Clash and not give up pretty quickly. Unlike imperative languages, functional languages with a rich modern type system like Haskell are hard to wrap your head around. It's no news that Haskell can be very hard to get into for even experienced software engineers. In 2005, after already having more than a decade of programming experience in C, C++, Java, various Assemblers, python (obviously not all of these for the same time) and many other languages, I thought any new language would mostly be "picking up new syntax" at that point. Yet Haskell proved me very wrong on that, so much that it was almost like re-learning programming. The reward is immense, but you have to really want to learn it. And to my surprise at the time, when I got heavily into FPGAs, the advantage proved to be even stronger when building sequential logic, because that paradigm just fits so much better. My Clash code is much smaller, but also much more readable and easier to understand than Verilog/VHDL code. And it's made up of reusable components, e.g. my AXI4 interfacing is not bespoke individual lines interspersed throughout the entire rest of the code. That's mainly because functional languages allow for abstraction that Verilog/VHDL don't, where often the only recourse is very awkward "generated" code (so much so that there is an actual "generate" statement that is an important part of Verilog, for example). So by now, I have fully switched to using Clash for my projects, and only use Verilog and VHDL for simple glue logic (where the logic is trivial and the extra compilation step in the Verilog/VHDL-centric IDE would be awkward) or for modifying existing logic. But try to get Hardware Engineers who probably don't have any interest in learning a functional programming language to approach such an entirely different paradigm with an open mind. I've gotten so many bogus replies that just show that the engineer has no idea what higher order functional programming with advanced type system is on any level, and I don't blame them, but this makes discussions extremely tiring. 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.
jwilk 5y ago
(2013) according to https://danluu.com/ https://danluu.com/.
- mjw1007 5y ago
  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.
  - ksec 5y ago
    >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.
    - misnome 5y ago
      I wonder if this is similar reasons to why lots of CS papers seem to never have the date on?
      - butlerm 5y ago
        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.
        hobofan 5y ago
        Yes, especially when trying to reconstruct the timeline and context of related research, to help understand the methodology and implicit (lack of) reasoning. With time context one can often go from "why would they do it like that?" to, "given that X wasn't discovered at the time, it makes sense that they did it like that".
tails4e 5y ago
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 avoid, but I don't agree that knowing in your head the hardware that will be generated is a bad thing. Knowing how the hardware will be constructed from your code is key to getting it running at 4Ghz instead of 100Mhz. What your code will infer could be less or more area efficient, etc. Modern synthesis tools do help map sometimes inefficient code to the right hardware, but still knowing what it should create is a positive thing.
- resonious 5y ago
  Looking at the site index, it seems this article was written in 2013.
- IshKebab 5y ago
  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.
Taniwha 5y ago
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 <= b; 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 <=, you typically use the always when you want something more complex "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)
- pjc50 5y ago
  > 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 the assembly and working backwards, which tends to get wrecked by UB or the optimizer at some security-critical point. If the main point of the language is to generate flops, flops should be an explicit primitive! > Verilog is an early object oriented language - modules are objects Maybe, but IMO a more useful place to apply object orientation would be interfaces, which are nets not modules. I should be able to instantiate "AXI bus" somewhere and connect things to it.
hyperman1 5y ago
I wonder why building circuits doesn't use a language comparable to the nand2tetris course. For those who haven't seen it: It gives building blocks like NAND, wires, and an abstraction method, allowing to treat a group of wires and building blocks as a new building block. So you wire up a few gates to, say, an adder, then you can use adders in your circuit. Things like circuit synthesis and timing analysis get trivial. I have the impression digital designers already tend to think in this way. I don't have much experience,so read the next as a question instead of a suggestion: what's wrong with using this as a basis for a new design language?
- gh02t 5y ago
  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 blocks for various functions, many of which are very powerful and might be tuned by the vendor to exploit specific hardware features of your target (the more powerful ones are typically expensive and black box proprietary stuff that you just get input and outputs). They also often provide an actual graphical editor for wiring blocks together, or you can specify connections in a text format. I'm not really professionally experienced with it, but I understand that a lot of the common work in practice is wiring together these pre-made block libraries from vendors more than writing them from scratch.
  - hyperman1 5y ago
    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
    - nobodywasishere 5y ago
xyzzy21 5y ago
Verilog is an unplanned emergent hack... If you want regularity, use VHDL.
dhdc 5y ago
Related: https://insights.sigasi.com/opinion/jan/verilogs-major-flaw/ 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.
- sguav 5y ago
  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.
  - Jtsummers 5y ago
    VHDL springs off of Ada (not an acronym, no need to shout or to bring in the Americans with Disabilities Act into a discussion on programming) syntax, but not its semantics (or, its not a continuation of Ada semantics, it does borrow some of them). PL/SQL (I've never used it) also borrows from Ada's syntax, but not its semantics in any comprehensive sense. This sort of thing was deliberate, similar to how Verilog borrows from C's syntax, or Java apes C's syntax, or JavaScript apes Java's (and C, indirectly). The goal was to extend something familiar with new semantics.
    - sguav 5y ago
      Yes, Ada not ADA, my mistake which ironically Ada's case insensitivity wouldn't have caught :)
throwaway984393 5y ago
I hate math. Not because "math is hard", but because the language of math is hard. It's unintuitive and minimalist and full of obscure runes and intonations and nothing is ever explained simply. Many of its properties are just conventions the first person came up with and nobody ever decided to consolidate all the quirks into a simpler form. It's unnecessarily hard to learn - especially for those with learning disabilities. It turns out there are lots of languages like this. C and Verilog and Assembly, and ... Cantonese, Albanian, Russian, Arabic. Ask people why they're like that and there is always a story, and usually some good reasons (or at least useful qualities). But language is a part of culture, and sadly, culture is incredibly hard to change.
- mathematicaster 5y ago
  You almost got me!
pflanze 5y ago
Previous discussion: https://news.ycombinator.com/item?id=12863455 https://news.ycombinator.com/item?id=12863455 (2016)
absurdfatalism 5y ago
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 https://github.com/JulianKemmerer/PipelineC/wiki
- thrtythreeforty 5y ago
  Maybe you should add a disclaimer, "this is my project" :)
mijoharas 5y ago
Can anyone speak about how VHDL compares to Verilog? does it suffer from the same flaws? how do they compare to one another.
- exmadscientist 5y ago
  They have different flaws. Neither is actually very good. But if you are coming from the perspective of a newbie asking which to learn, there is a solid answer: absolutely, definitely, 100% learn VHDL. Do not learn Verilog. (And ignore anyone who says otherwise.) There are two reasons for this. First, if you learn VHDL, it is then easy to learn Verilog. The reverse is not true. So even if you need to use Verilog later, and because it's more popular you probably will, this will not be difficult for you. The second reason is that VHDL makes certain very bad habits impossible at the language level (including the compiler/synthesizer). VHDL's model for how things happen is better than Verilog's, and prohibits many strange cases that you never actually want to generate. Thus, by learning VHDL, you will naturally train yourself to write code that is structurally better, and this style continues to be very successful in Verilog. In this case Verilog is too permissive: it lets you write bad code that does not map effectively to what you need. This is why it's much easier to move from VHDL to Verilog: you will not have bad habits to unlearn.
jgeada 5y ago
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 have any sensible mapping to hardware. The problem with all these articles is that they start from wrong assumptions and keep going. In practice, industry has no problem using these languages to produce chips with billions of transistors that largely work the first time, with the expected performance and power. As others have mentioned, this industry is conservative, and if there isn't a problem to fix it will remain with the tried and tested. (I'm one of the people named in the Verilog/SystemVerilog standards, worked with Phil Moorby and once upon a time was responsible for chunks of ncsim and vcs)
- ghettoimp 5y ago
  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.
  - jgeada 5y ago
    The industry is extremely conservative. Costs of designing and taping out a modern chip range from $100M to $1B; these are the type of costs that will kill most companies if it goes wrong and very few companies can afford to have it go wrong more than once. Tried and true approaches, small incremental developments are the only way things get done in this space. And the technological moat has many sources, not just Verilog etc. Process technology is continuously evolving and tools need to adapt to all the new physical rules and constraints. What gates are most efficient depends on the problem and the process and even by what the team means by efficient (least power? least energy? most mips/sec? least time to solve a problem? ...) Everyone loves to complain about the tools though, that is universal. They'll just never adopt a new tool that hasn't survived the test of time and had enough successful designs "by someone else" that it doesn't make them nervous about being the first.
apienx 5y ago
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.
- mrintellectual 5y ago
  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.
  - jeffreygoesto 5y ago
    I once read "software describes what the machine shall do, HDL describes, what it shall _be_" and found that pretty accurate.
phendrenad2 5y ago
After using verilog/vhdl for awhile, I learned that trying to be "clever" in ANY way is just going to result in errors and frustration. So I write small dead-simple verilog modules, test them in isolation (icarus verilog is great! Use it with a systemverilog testbench to poke values into your module, and use gtkwave to visually verify the output), and then compose them into a larger design.

162 points by fzliu 5y ago

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

rurban 5y ago
that's we use formal verification or formal contracts, not just test driven development. do we, or am I alone on this?
- captaincaveman 5y ago
  Are you even doing it for all your code ... come on be honest ;)

deleted 5y ago

[deleted]

jwilk 5y ago

> 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) 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.

shadowgovt 5y ago
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 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 right if you use them anyway, but it risks mis-parsing).
- jwilk 5y ago
  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 https://datatracker.ietf.org/doc/html/rfc3986#section-2.2
  - shadowgovt 5y ago
    That is, unfortunately, one of those chunks of English that is hard to interpret. "Safe" here isn't really what the RFC is talking about; the RFC is saying that if you take a URI and add or remove percent encoding for those characters, you might change the way that the URI is interpreted (because those characters mean something in the enclosing context). In other words, you can't encode or decode them without risking a change to the interpretation, but whether encoding or decoding is "safe" is going to be context-specific (broadly speaking, the safest thing to do is to encode them and leave them encoded).
    - jwilk 5y ago
      It happens that Wikipedia doesn't care whether parens are percent-encoded or not. So yes, you can use %28%29 instead (), but that's despite them being sub-delims. For example, you definitely should change & (another sub-delim) to %26 in your URLs. And, as I noted earlier, escaping parens wouldn't even help in this case, because it's an underscore that causes the mess.

anyfoo 5y ago

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 to Verilog/VHDL: https://clash-lang.org https://clash-lang.org). The problem is, it is hard, if not downright impossible, to get the industry to change. I have heard many times, in close to literally these words: "Why would I use any language that is not the industry standard". And that's a valid point given the current world. But even for people that are interested, it might just be hard to switch to something like Clash and not give up pretty quickly. Unlike imperative languages, functional languages with a rich modern type system like Haskell are hard to wrap your head around. It's no news that Haskell can be very hard to get into for even experienced software engineers. In 2005, after already having more than a decade of programming experience in C, C++, Java, various Assemblers, python (obviously not all of these for the same time) and many other languages, I thought any new language would mostly be "picking up new syntax" at that point. Yet Haskell proved me very wrong on that, so much that it was almost like re-learning programming. The reward is immense, but you have to really want to learn it. And to my surprise at the time, when I got heavily into FPGAs, the advantage proved to be even stronger when building sequential logic, because that paradigm just fits so much better. My Clash code is much smaller, but also much more readable and easier to understand than Verilog/VHDL code. And it's made up of reusable components, e.g. my AXI4 interfacing is not bespoke individual lines interspersed throughout the entire rest of the code. That's mainly because functional languages allow for abstraction that Verilog/VHDL don't, where often the only recourse is very awkward "generated" code (so much so that there is an actual "generate" statement that is an important part of Verilog, for example). So by now, I have fully switched to using Clash for my projects, and only use Verilog and VHDL for simple glue logic (where the logic is trivial and the extra compilation step in the Verilog/VHDL-centric IDE would be awkward) or for modifying existing logic. But try to get Hardware Engineers who probably don't have any interest in learning a functional programming language to approach such an entirely different paradigm with an open mind. I've gotten so many bogus replies that just show that the engineer has no idea what higher order functional programming with advanced type system is on any level, and I don't blame them, but this makes discussions extremely tiring. 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.

jwilk 5y ago

(2013) according to https://danluu.com/ https://danluu.com/.

mjw1007 5y ago
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.
- ksec 5y ago
  >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.
  - misnome 5y ago
    I wonder if this is similar reasons to why lots of CS papers seem to never have the date on?
    - butlerm 5y ago
      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.
      - hobofan 5y ago
        Yes, especially when trying to reconstruct the timeline and context of related research, to help understand the methodology and implicit (lack of) reasoning. With time context one can often go from "why would they do it like that?" to, "given that X wasn't discovered at the time, it makes sense that they did it like that".

tails4e 5y ago

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 avoid, but I don't agree that knowing in your head the hardware that will be generated is a bad thing. Knowing how the hardware will be constructed from your code is key to getting it running at 4Ghz instead of 100Mhz. What your code will infer could be less or more area efficient, etc. Modern synthesis tools do help map sometimes inefficient code to the right hardware, but still knowing what it should create is a positive thing.

resonious 5y ago
Looking at the site index, it seems this article was written in 2013.
IshKebab 5y ago
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.

Taniwha 5y ago

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 <= b; 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 <=, you typically use the always when you want something more complex "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)

pjc50 5y ago
> 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 the assembly and working backwards, which tends to get wrecked by UB or the optimizer at some security-critical point. If the main point of the language is to generate flops, flops should be an explicit primitive! > Verilog is an early object oriented language - modules are objects Maybe, but IMO a more useful place to apply object orientation would be interfaces, which are nets not modules. I should be able to instantiate "AXI bus" somewhere and connect things to it.

hyperman1 5y ago

I wonder why building circuits doesn't use a language comparable to the nand2tetris course. For those who haven't seen it: It gives building blocks like NAND, wires, and an abstraction method, allowing to treat a group of wires and building blocks as a new building block. So you wire up a few gates to, say, an adder, then you can use adders in your circuit. Things like circuit synthesis and timing analysis get trivial. I have the impression digital designers already tend to think in this way. I don't have much experience,so read the next as a question instead of a suggestion: what's wrong with using this as a basis for a new design language?

gh02t 5y ago
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 blocks for various functions, many of which are very powerful and might be tuned by the vendor to exploit specific hardware features of your target (the more powerful ones are typically expensive and black box proprietary stuff that you just get input and outputs). They also often provide an actual graphical editor for wiring blocks together, or you can specify connections in a text format. I'm not really professionally experienced with it, but I understand that a lot of the common work in practice is wiring together these pre-made block libraries from vendors more than writing them from scratch.
- hyperman1 5y ago
  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
  - nobodywasishere 5y ago

xyzzy21 5y ago

Verilog is an unplanned emergent hack... If you want regularity, use VHDL.

dhdc 5y ago

Related: https://insights.sigasi.com/opinion/jan/verilogs-major-flaw/ 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.

sguav 5y ago
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.
- Jtsummers 5y ago
  VHDL springs off of Ada (not an acronym, no need to shout or to bring in the Americans with Disabilities Act into a discussion on programming) syntax, but not its semantics (or, its not a continuation of Ada semantics, it does borrow some of them). PL/SQL (I've never used it) also borrows from Ada's syntax, but not its semantics in any comprehensive sense. This sort of thing was deliberate, similar to how Verilog borrows from C's syntax, or Java apes C's syntax, or JavaScript apes Java's (and C, indirectly). The goal was to extend something familiar with new semantics.
  - sguav 5y ago
    Yes, Ada not ADA, my mistake which ironically Ada's case insensitivity wouldn't have caught :)

throwaway984393 5y ago

I hate math. Not because "math is hard", but because the language of math is hard. It's unintuitive and minimalist and full of obscure runes and intonations and nothing is ever explained simply. Many of its properties are just conventions the first person came up with and nobody ever decided to consolidate all the quirks into a simpler form. It's unnecessarily hard to learn - especially for those with learning disabilities. It turns out there are lots of languages like this. C and Verilog and Assembly, and ... Cantonese, Albanian, Russian, Arabic. Ask people why they're like that and there is always a story, and usually some good reasons (or at least useful qualities). But language is a part of culture, and sadly, culture is incredibly hard to change.

mathematicaster 5y ago
You almost got me!

pflanze 5y ago

Previous discussion: https://news.ycombinator.com/item?id=12863455 https://news.ycombinator.com/item?id=12863455 (2016)

absurdfatalism 5y ago

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 https://github.com/JulianKemmerer/PipelineC/wiki

thrtythreeforty 5y ago
Maybe you should add a disclaimer, "this is my project" :)

mijoharas 5y ago

Can anyone speak about how VHDL compares to Verilog? does it suffer from the same flaws? how do they compare to one another.

exmadscientist 5y ago
They have different flaws. Neither is actually very good. But if you are coming from the perspective of a newbie asking which to learn, there is a solid answer: absolutely, definitely, 100% learn VHDL. Do not learn Verilog. (And ignore anyone who says otherwise.) There are two reasons for this. First, if you learn VHDL, it is then easy to learn Verilog. The reverse is not true. So even if you need to use Verilog later, and because it's more popular you probably will, this will not be difficult for you. The second reason is that VHDL makes certain very bad habits impossible at the language level (including the compiler/synthesizer). VHDL's model for how things happen is better than Verilog's, and prohibits many strange cases that you never actually want to generate. Thus, by learning VHDL, you will naturally train yourself to write code that is structurally better, and this style continues to be very successful in Verilog. In this case Verilog is too permissive: it lets you write bad code that does not map effectively to what you need. This is why it's much easier to move from VHDL to Verilog: you will not have bad habits to unlearn.

jgeada 5y ago

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 have any sensible mapping to hardware. The problem with all these articles is that they start from wrong assumptions and keep going. In practice, industry has no problem using these languages to produce chips with billions of transistors that largely work the first time, with the expected performance and power. As others have mentioned, this industry is conservative, and if there isn't a problem to fix it will remain with the tried and tested. (I'm one of the people named in the Verilog/SystemVerilog standards, worked with Phil Moorby and once upon a time was responsible for chunks of ncsim and vcs)

ghettoimp 5y ago
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.
- jgeada 5y ago
  The industry is extremely conservative. Costs of designing and taping out a modern chip range from $100M to $1B; these are the type of costs that will kill most companies if it goes wrong and very few companies can afford to have it go wrong more than once. Tried and true approaches, small incremental developments are the only way things get done in this space. And the technological moat has many sources, not just Verilog etc. Process technology is continuously evolving and tools need to adapt to all the new physical rules and constraints. What gates are most efficient depends on the problem and the process and even by what the team means by efficient (least power? least energy? most mips/sec? least time to solve a problem? ...) Everyone loves to complain about the tools though, that is universal. They'll just never adopt a new tool that hasn't survived the test of time and had enough successful designs "by someone else" that it doesn't make them nervous about being the first.

apienx 5y ago

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.

mrintellectual 5y ago
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.
- jeffreygoesto 5y ago
  I once read "software describes what the machine shall do, HDL describes, what it shall _be_" and found that pretty accurate.

phendrenad2 5y ago

After using verilog/vhdl for awhile, I learned that trying to be "clever" in ANY way is just going to result in errors and frustration. So I write small dead-simple verilog modules, test them in isolation (icarus verilog is great! Use it with a systemverilog testbench to poke values into your module, and use gtkwave to visually verify the output), and then compose them into a larger design.