[adwn]

... and then suddenly you realize what a horrible, horrible language it is. I'm not exaggerating, it isn't even well-suited for the domain it is mainly used for (i.e., designing digital hardware circuits). For example:

1) Synthesis/simulation mismatch: Your design might work in simulation but not in hardware, and vice versa. Often, this is due to X-value (representing unknown/invalid values) problems.

2) Signed datatypes: If you mix signed and unsigned values in an expression, the result is unsigned. So, if a is unsigned and has the value 4, b is signed and has the value -3, then

  (a * b) < 5

will return 0 (false), while

  ($signed(a) * b) < 5

will correctly return 1 (true). That's because signed datatypes are just an afterthought and weren't officially introduced until 2001, more than 15 years after the language's inception.

3) If an undeclared net is used in an module instantiation, the compiler silently creates a 1 bit net with that name. No error message, no warning. You can turn off that stupid behavior with a compiler directive, but you have to turn it back on at the end of your file, because otherwise its effects are active in all files compiled afterwards, and many third-party sources don't work correctly with this setting.

VHDL is also a bad language, but for very different reasons. And yet, alternative HDLs have a hard time getting traction, for various reasons and non-reasons.

[simias]

Oh I agree, while writing verilog I was amazed people used it to develop something as critical as ASICs. The language is way too forgiving. And it's not like you can release a patch once the thing is on the silicium unless you're working with FPGAs. It was still very interesting to see how hardware was designed and definitely an enlightening experience as far as I'm concerned.

I found verilog very similar to C in a way, if you're not familiar with all the quirks of the language it's very easy to write code that looks completely benign and straightforward and yet ends up blowing up in your face because of an implicit cast or undefined behaviour...

On the other hand there's not much of a "hacker scene" for driving up the innovation for HDLs, unfortunately. And I don't expect the big companies making ASICs and FPGAs to come up with a radical new solution any time soon.

So basically, if one of you HNers want to try their hand at writing a new programming language, consider designing a modern Verilog instead of yet an other Javascript transpiler :)

[zwieback]

This seems true for other areas of EE. I'm continually surprised that our FPGA and board designers use some adhoc horrible homegrown revision control scheme. When I ask them about tools of the trade they usually complain that the solutions are proprietary and not working any better than making numbered backups.

The same is true, maybe even worse, for our MEs.

[swah]

I really enjoyed writing VHDL. I don't remember having problems with unknown values: we used only '0' and '1' for anything that's supposed to be synthesized.

(For testbenches, everything goes..)

     Value set is ('U','X','0','1','Z','W','L','H','-')
     TYPE std_logic IS ( 'U',  -- Uninitialized
                         'X',  -- Forcing unknown
                         '0',  -- Forcing 0
                         '1',  -- Forsing 1
                         'Z',  -- High    impedance
                         'W',  -- Weak    unknown
                         'L',  -- Weak    0
                         'H',  -- Weak    1
                         '-'); -- Don't care

     SIGNAL stdLogicName : STD_LOGIC:='0';
     stdLogicName <= 'Z';

[adwn]

VHDL has the same problem:

  signal x, y: std_logic;
  ...
  x <= 'X';
  ...
  y <= '0' when x = '0' else '1';

will result in y getting the value '1' in simulation, but you don't know what it'll be for synthesis. So if you're unlucky, it'll simulate correctly but fail in hardware. Which is exactly what simulation should protect you from.

And even if you assign only '0' and '1', you might get an 'X' from third-party IP cores.

[swah]

Yep, I agree about IP cores, never really used something like that.

[Igglyboo]

I wholeheartedly agree.

I'm a CSE Major and I took a hardware design class last fall, we programmed and Xilinx FPGA using VHDL.

It was a huge change from everything I had learned before, I had no idea what a latch was and why it was bad to imply them. The thing that bothered me the most was the simulation/synthesis disconnect, the only efficient way to debug a program is by using the simulator because debugging it on the board takes a very long time when changing code. But even after you've debugged it in the simulation it might not even synthesize, which is an even harder "bug" to debug.

[adwn]

> It was a huge change from everything I had learned before, I had no idea what a latch was and why it was bad to imply them.

Exactly. VHDL and Verilog make hardware design twice as hard as necessary: first you have to think about what structures you need, and then you have to figure out how to describe it with the inappropriate tools your HDL gives you (in such a way that the synthesis software correctly recognizes your intent).

[noobiemcfoob]

Not knowing what a latch is or why it is bad seems like more a failure of the class than an inherent problem with Verilog. There are times when a latch is useful and desired (though most often not and most often a normal flop structure is better).

With hardware design, you have to keep in mind that you are modeling hardware. A language that did it all for you might be nice, but you still have to know what framework you are working in. The simulation/synthesis disconnect is inherent to that. You can think of a ton of structures that seem fine at a code level but just don't have a workable analog in silicon. Synthesis in that sense is just another debug tool.

[adwn]

> Not knowing what a latch is or why it is bad seems like more a failure of the class than an inherent problem with Verilog.

You misunderstood the problem: It's not a problem that you can describe a latch, but that it's so easy to make the mistake of describing a latch instead of combinational logic. It's a common mistake and clearly a failure of the language, because two very different intents are described by very similar code.

> The simulation/synthesis disconnect is inherent to that. [...]

No, you're confusing simulation/synthesis mismatch with non-synthesizable code. The former means that simulation gives you different results than the hardware at runtime, which is a very bad thing and should be avoided wherever possible (that's the point of simulation, after all). The latter is unavoidable to a certain degree if the HDL should be usable for simulation.

[noobiemcfoob]

On latches: From experience, I've never had an issue accidentally defining a latch. Simple guidelines (fully describe any case statements or always have an else statement in if branches, use * from Verilog 2005 rather than trying to list all relevant signals) make it more an issue of typos than true unintentional latches and a basic lint flow will identify them quickly.

While I'd accept that perhaps exposing this so easily might be an annoyance in the language, it is hardly a failing.

Synthesis: Again, from experience, this is an issue with your synthesis flow, not the HDL. Synthesis is absurdly complicated, to the point where any team I've been on has at least one guy where that is the entirety of his job. If the generated netlist breaks simulation when your HDL made it all the way through all other flows, more than likely it's an issue with synthesis.

[noobiemcfoob]

The problems you mentioned are all easily bypassed by design guidelines.

1) (At least at the X's point) Don't build designs that rely on X behavior or could result in X behavior. Where I work, X's are completely unacceptable and a sign that something is broken. In general, if writing Verilog to model hardware, don't write non-synthesizeable constructs.

2) Signed datatypes don't make any sense when designing hardware. Verilog treats everything as bit vectors. While 2's complement can implement signed behavior, hardware doesn't know or care about signed types. Again, if modeling hardware, write code that models hardware.

3) This is annoying, but another issue that is stepped around with design practices and not a major problem.

Overall, when talking about Verilog, you have to keep in mind its a language built to model hardware. Most features of modern languages don't make much sense in that context.

[adwn]

1) > Don't build designs that rely on X behavior or could result in X behavior.

Although I agree, you can't completely avoid 'X' values, because third-party cores might return them in output signals.

2) > Signed datatypes don't make any sense when designing hardware.

Now that is just plain and utterly wrong. Of course signed datatypes make sense when designing hardware: You can (and have to) perform arithmetic in hardware, and signed arithmetic is a part of arithmetic.

> Verilog treats everything as bit vectors.

By your argumentation, unsigned datatypes also wouldn't make sense when designing hardware. And yet you need it all the time.

> hardware doesn't know or care about signed types

But the language should care about it. "It's all 0s and 1s in the end" is not an argument for not providing proper abstractions.

3) > This is annoying, but another issue that is stepped around with design practices and not a major problem.

That's like saying "you can avoid bugs if you're really careful". Great. A "feature" which doesn't offer any advantage (because you're supposed to avoid it anyway) and which makes it so easy to make mistakes which won't be seen until simulation, should have never made it into the language.

> Overall, when talking about Verilog, you have to keep in mind its a language built to model hardware.

Exactly. Verilog and VHDL were intended to model hardware, not to design it. Nowadays, they are mostly used to design it.

I don't mean to attack you, but attitudes like yours are the main reason why we're stuck with such crappy, ill-designed, inappropriate languages for hardware design. You're so used to the problems that you don't even see them anymore.

[marcosdumay]

Well, #1 is a problem of the tools, not the language.

[adwn]

No, it's a problem of the language. If the tools wanted to avoid this problem, they'd be non-compliant.