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

VHDL's Crown Jewel

sigasi.com

Post reply on HN
Print view View original

51–60 of 65 posts

Re: VHDL's Crown Jewel

#51

Post by nickelpro »

CorrectHorseBat wrote: post #49
nickelpro wrote: post #43

Earlier quoted context omitted.

Because it's both slow and terrible? You generally do not want to simulate or describe raw gate-level netlists. Both languages are capable of that. Old school Verilog (not SystemVerilog) is still the defacto netlist exchange format for many tools. It's just aggravatingly slow to sim and needlessly verbose. Feeding high-level RTL to Verilator to do basic cycle-accurate sim has exceptionally fast iteration speed these…

Is it really if you restrict yourself to sensible design practices? You generally want to simulate simple clocked Logic with a predefined clock, most of the time anything else is a mistake or bad design. So just if rising edge clk next_state <= fn(previous_state, input) . It seems to me VHDL and verilog are simply at the wrong abstraction level and by that they make simulation needlessly complicated and design easy t…

I agree basically with everything you're saying, but that's not arguing for raw gate netlists. If anything it's arguing for even higher levels of abstraction where clock domains are implicit semantic contexts.

Many new school HDLs are working in this space and they couldn't be farther from the "representative of what digital circuits are constructed from" idea. Often they're high-level programmatic generators, very far from describing things in terms of actual PDK primitives.

Re: VHDL's Crown Jewel

#52

Post by CorrectHorseBat »

nickelpro wrote: post #51
CorrectHorseBat wrote: post #49

Earlier quoted context omitted.

Is it really if you restrict yourself to sensible design practices? You generally want to simulate simple clocked Logic with a predefined clock, most of the time anything else is a mistake or bad design. So just if rising edge clk next_state <= fn(previous_state, input) . It seems to me VHDL and verilog are simply at the wrong abstraction level and by that they make simulation needlessly complicated and design easy t…

I agree basically with everything you're saying, but that's not arguing for raw gate netlists. If anything it's arguing for even higher levels of abstraction where clock domains are implicit semantic contexts. Many new school HDLs are working in this space and they couldn't be farther from the "representative of what digital circuits are constructed from" idea. Often they're high-level programmatic generators, very f…

In a way is further away, but in another way it's actually closer to how real hardware works: Clock (and reset) trees are real physical things which exist on all digital chips.

Re: VHDL's Crown Jewel

#53

Post by CorrectHorseBat »

audunw wrote: post #24
CorrectHorseBat wrote: post #10

The real question is, why do we even need this? Why don't VHDL and Verilog just simulate what hardware does? Real hardware doesn't have any delta cycles or determinism issues due to scheduling. Same thing with sensitivity lists (yes we have */all now so that's basically solved), but why design it so that it's easy to shoot in your own foot?

The only way to simulate what real hardware does is to synthesise the design, get a net list and do a gate level simulation. This is incredibly slow, both to compile and to simulate. You could, of course, simplify the timing model a lot. In the end you get down to “there is some time passing for the signal to get through this logic, we don’t know how much but we assume it’s less than any clock period”.. in which case…

Real hardware has clock trees. Wouldn't all (most?) problems with delta cycles go away if the HDL understood the concept of clocks and clock balancing?

Re: VHDL's Crown Jewel

#54

Post by 0xsn3k »

zackmorris wrote: post #47

This is great! I remember having this debate back in the late 1990s when I was in college for my electrical and computer engineering (ECE) degree. At the time as students, we didn't really know about nuances like delta cycles, so preferring Verilog or VHDL came down to matter of personal taste. Knowing what I know now, I'm glad that they taught us VHDL. Also that's one of the reasons that it's worth trying to get int…

maybe clash [1] would be interesting to you then?

[1] https://clash-lang.org/

Re: VHDL's Crown Jewel

#55

Post by oelang »

Joel_Mckay wrote: post #27
formerly_proven wrote: post #22

Earlier quoted context omitted.

This actually sounds a bit like a C/C++ argument. Roughly: Yes, you can easily write incorrect code but when some basic coding conventions are followed, UAF/double free/buffer overflows/... are just not a problem. After all, some of the world's most complex software is built with C / C++. If you couldn't write software reliably with C / C++, that could never be the case. I.e. just because teams manage to do something…

There are folks trying to make HDL easier, and vendor neutral. Not sure why people were upset by mentioning the project... https://github.com/amaranth-lang/amaranth While VHDL makes a fun academic toy language, it has always been Verilog in the commercial settings. Both languages can develop hard to trace bugs when the optimizer decides to simply remove things it thinks are unused. =3

VHDL still dominates in medical, military, avionics, space etc. and it's generally considered the safer RTL language, any industry that requires functional safety seems to prefer it.

It's also the most used language for FPGA in Europe but that's probably mostly cultural.

Re: VHDL's Crown Jewel

#56

Post by oelang »

lifis wrote: post #28
e7h4nz wrote: post #2

The Delta Cycle logic is actually quite similar to functional reactive programming. It separates how a value changes from when a process responds to that change. VHDL had this figured out as early as 1987. I spent many years writing Verilog test benches and chasing numerous race conditions; those types of bugs simply don't exist in VHDL. The Verilog rules—using non-blocking assignments for sequential logic and blocki…

I don't understand this: isn't the thing in the article only relevant for software simulations, while in hardware ordering is arbitrary like in Verilog, or at least dependent on wire lengths that are not specified in HDL? (unless you delay the effect to the next clock update, which it seems to me will work the same in all HDLs and targets). And afaik HDLs are almost exclusively used for hardware synthesis, never seen…

It's important to have deterministic simulations and semantics that you can reliably reason about. Both VHDL and SystemVerilog offer this to some extent, but in the case of (System)Verilog the order of value updates is not as strictly enforced. In practice, this means that if you switch to another or a newer simulator, suddenly your testbenches will fail. The simulator vendors love this of course. This hidden cost is underestimated.

No sane hardware engineer would want randomness in their simulation unless they get to control it.

Re: VHDL's Crown Jewel

#57

Post by oelang »

buildbot wrote: post #4

Naively as a West Coast Verilog person, VHDL Delta cycles seem like a nice idea, but not what actual circuits are doing by default. The beauty and the terror of Verilog is the complete, unconstrained parallel nature of it’s default - it all evaluates at t=0 by default, until you add clocks and state via registers. VHDL seems easy to create latches and other abominations too easily. (I am probably wrong at least parti…

(System)Verilog has delta cycles too you know, they call it an event queue, but it's basically the same. It's the direct variable updates that happen outside of this mechanism that cause all the issues. Imho it was a poor attempt at simulation optimization, and now you can't take it out of the language anymore.

Re: VHDL's Crown Jewel

#58

Post by oelang »

gsmecher wrote: post #50

I love that VHDL formalizes Verilog's pragmatic blundering, but emphasizing delta-cycle ordering is "inside baseball" and IMO bad marketing. VHDL's approach is conceptually clean, but from a practical perspective, this ordering doesn't (and shouldn't) matter. Better to emphasize the type system, which make a durable and meaningful difference to users (both experienced and new). My go-to example is fixed-point arithme…

VHDL mostly lost the ASIC consumer market and for some that's the only market that matters, but the hardware design ecosystem is much bigger than that.

I wonder what AI will do to RTL/verification, the rigid nature of VHDL may be a better target for AI than Verilog.

Re: VHDL's Crown Jewel

#59

Post by gsmecher »

oelang wrote: post #58
gsmecher wrote: post #50

I love that VHDL formalizes Verilog's pragmatic blundering, but emphasizing delta-cycle ordering is "inside baseball" and IMO bad marketing. VHDL's approach is conceptually clean, but from a practical perspective, this ordering doesn't (and shouldn't) matter. Better to emphasize the type system, which make a durable and meaningful difference to users (both experienced and new). My go-to example is fixed-point arithme…

VHDL mostly lost the ASIC consumer market and for some that's the only market that matters, but the hardware design ecosystem is much bigger than that. I wonder what AI will do to RTL/verification, the rigid nature of VHDL may be a better target for AI than Verilog.

If AI does anything to the EDA space, I hope it helps break the chokehold the "big 3" have on tooling. Any startup that threatens their dominance gets acquired and disappeared.

I also hope this is coming anyway (see e.g.: KiCad nipping at Altium's heels, and Verilator's recent progress). There is just so much more to do, though...

Re: VHDL's Crown Jewel

#60

Post by buildbot »

oelang wrote: post #57
buildbot wrote: post #4

Naively as a West Coast Verilog person, VHDL Delta cycles seem like a nice idea, but not what actual circuits are doing by default. The beauty and the terror of Verilog is the complete, unconstrained parallel nature of it’s default - it all evaluates at t=0 by default, until you add clocks and state via registers. VHDL seems easy to create latches and other abominations too easily. (I am probably wrong at least parti…

(System)Verilog has delta cycles too you know, they call it an event queue, but it's basically the same. It's the direct variable updates that happen outside of this mechanism that cause all the issues. Imho it was a poor attempt at simulation optimization, and now you can't take it out of the language anymore.

I did not know!
Post reply on HN