|
|
|
|
|
|
by noobiemcfoob
4445 days ago
|
|
|
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. |
|
|
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.