7 ms·

VHDL's Crown Jewel

e7h4nz 6mo ago
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 blocking assignments for combinational logic—fail as soon as the scenario becomes slightly complex. Verilog is suitable when you already have the circuit in your head and just need to write it down quickly. In contrast, VHDL forces you to think about concurrent processes in the correct way. While the former is faster to write, the latter is the correct approach. Even though SystemVerilog added some patches, the underlying execution model still has inherent race conditions.
- tverbeure 6mo ago
  I used to be a huge VHDL proponent, talk about the delta cycle stuff, give VHDL classes at work to new college grads and such. And then I moved to the West Coast and was forced to start using Verilog. And in the 21 years since, I’ve never once ran into an actual simulation determinism issues. It’s not bad to have a strict simulation model, but if some very basic coding style rules are followed (which everybody does), it’s just not a problem. I don’t agree at all with the statement that Verilog fails when things become too complex. The world’s most complex chips are built with it. If there were ever a slight chance that chips couldn’t be designed reliably with it, that could never be the case. Anyway, not really relevant, but this all reminds me of the famous Verilog vs VHDL contest of 1997: https://danluu.com/verilog-vs-vhdl/ https://danluu.com/verilog-vs-vhdl/
  - e7h4nz 6mo ago
    On a practical level, you're right, most of my team's work is done in Verilog. That being said, I still have a preference for the VHDL simulation model. A design that builds correctness directly into the language structure is inherently more elegant than one that relies on coding conventions to constrain behavior.
    - tverbeure 6mo ago
      My memory is definitely rusty on this, but you can easily construct cases where the VHDL delta cycle model creates problems where it doesn’t for Verilog. I remember inserting clock signal assignments in VHDL to get a balanced delta cycle clock tree. In Verilog, that all simply gets flattened. I can describe the VHDL delta cycle model pretty well, and I can’t for Verilog, yet the Verilog model has given me less issues in practice As for elegance: I can’t stand the verboseness of VHDL anymore. :-)
      - y1n0 6mo ago
        Reassigning clocks to another signal name will quickly get you into trouble in ways the just don’t happen on real hardware.
        tverbeure 6mo ago
        Have you heard about clock buffers and hold violations?
        y1n0 6mo ago
        No, is that the latest craze?
    - JoachimS 6mo ago
      The question for me is, where do I catch, describe the physical reality the model describes? A simulation model can be very elegant. But does it represent how physical things really behave? Can we even expect to do that at RTL, or further down the design flow? As the name suggest, we are talking about transferring data between registers. In the RTL that is what I can expect to describe. At the end of the day, what I write will become an electrical circuit - in a FPGA or an ASIC (or both), having the complex exact modelling with wire delays, capacitance, cross talk, cell behavior too early makes it impossibly to simulate fast enough to iterate. So then we need to have a more idealized world, but keeping in mind that (1) it is an idealized world and (2) sooner or later the model will be the rubber on the road. To me, Verilog and SystemVerilog allow me to do this efficiently. Warts and all. Oh, and also, where in my toolchain is my VHDL model translated/transformed into Verilog? How good is that translation? How much does the dual licensing cost. Things like mixed language simulation, formal verification between a verilog netlist and RTL in Verilog, mapping to cell libraries in Verilog. Integration of IP cores written in SystemVerilog with your model? Are the tools for VHDL as well tested as with code in Verilog? How big is the VHDL team at the tool vendor, library vendor, IP vendor, fab vendor compared to the Verilog, SV team? Can I expect the same support as a VHDL user as for Verilog? How much money does a vendor earn from VHDL customers compared to Verilog, SV? How easy is it to find employees with VHDL experience? VHDL may be a very nice language for simulation. But the engineering, business side is messy. And dev time, money can't be ignored. Getting things as fast and cheap as possibly still meeting a lot of functional, business requirements is what we as engineers are responsible for. Does VHDL make that easier or not?
  - formerly_proven 6mo ago
    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 with a tool does not mean the tool didn't impede (or vice versa, enable) the result. It just says that it's possible. A qualitative comparison with other tools cannot be established on that basis.
    - Joel_Mckay 6mo ago
      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 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
      - rzerowan 6mo ago
        How does this compare to chisel [1] , i never could get around the whole scala tooling - seemed a bit over the top. Though i guess it is a bit more mature and probably more enterprisey [1]https://github.com/chipsalliance/chisel https://github.com/chipsalliance/chisel
        Joel_Mckay 6mo ago
        > i never could get around the whole scala tooling scala is popular in places like Alphabet, that apparently allow go & scala projects in production. However, I agree while scala is very powerful in some ways, it just doesn't have a fun aesthetic. If one has to go spelunking for scalable hardware accelerators, a vendors linux DMA llvm C/C++ API is probably less fragile. For my simple projects, one zynq 7020 per node is way more than we should ever need. =3
      - 6mo ago
- lifis 6mo ago
  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 any software written in those languages. So it doesn't seem important at all. In fact, for software simulation of hardware you'd want the simulation to randomly choose anything possible in hardware, so the Verilog approach seems correct.
  - oelang 6mo ago
    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.
- thesz 6mo ago
  > 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. This is what I use when I play with hardware simulation in Haskell: type S a = [a] register :: a -> S a -> S a register a0 as = a0:as -- combinational logic can be represented as typical pure -- functions and then glued into "circuits" with register's -- and map/zip/unzip functions. This thing also separates externally visible events recorded in the (infinite) list of values from externally unobservable pure (combinational) logic. But, one can test combinational logic separately, with property based testing, etc.
buildbot 6mo ago
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 partially.) ((Shai-Hulud Desires the Verilog))
- tverbeure 6mo ago
  AFAIK, creating latches is just as easy in Verilog as in VHDL. They use the same model to determine when to create one. But with a solid design flow (which should include linting tools like Spyglass for both VHDL and Verilog), it’s not a major concern.
  - nickelpro 6mo ago
    SystemVerilog basically fixes this with always_comb vs always_latch. There's no major implementation which doesn't handle warning or even failing the flow on accidental latch logic inside an always_comb.
- hrmtst93837 6mo ago
  [flagged]
  - buildbot 6mo ago
    That does sound like my experience…
  - tverbeure 6mo ago
    > Once the design gets past toy size, Do you consider 800+mm2 slabs of 3nm of silicon still toy size? Because there's a very high chance that those were written in Verilog, and I've never had to chase sim vs synthesis mismatches. > Verilog gives you enough rope. Yes. If you don't know what you're doing and don't follow the industry standard practises.
- 6mo ago
arianvanp 6mo ago
Sounds like reachability problem in Petri nets to me?
CorrectHorseBat 6mo ago
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?
- artemonster 6mo ago
  Draw yourself an SR latch and try simulating. Or a circuit what is known as „pulse generator“
  - CorrectHorseBat 6mo ago
    Those are analog circuits, if you put them in your digital design you are doing something wrong.
    - kryptiskt 6mo ago
      All circuits are analog when physically realized, the digital view is an abstraction.
    - artemonster 6mo ago
      dont know if trolling. SR latch you can do with 2 NANDs, or NORs there are plenty of *digital* circuits with that functionality, and yes, there are very rare cases when you construct this out of logic and not use a library cell for this. pulse circuit is AND(not(not(not(a))),a) also rarely used but used nonetheless. to properly model/simulate them you would need delta cycles
      - CorrectHorseBat 6mo ago
        I'm not sure if you are trolling. 99.999% of digital design is "if rising edge clk new_state <= fn(old_state, input)", with an (a)sync reset. The language should make that the default and simple to do, and anything else out of the ordinary hard. Now it's more the other way around.
artemonster 6mo ago
Please stop bickering about verilog vs vhdl - if you use NBAs the scheduler works exactly the same in modern day simulators. There is no crown jewel in vhdl anymore. Also type system is annoying. Its just in your way, not helping at all.
- alain94040 6mo ago
  You're not wrong, but blocking assignments (and their equivalent in VHDL, variables), are useful as local variables to a process/always block. For instance to factor common sub-expressions and not repeat them. So using only non-blocking assignments everywhere would lead to more ugly code.
  - artemonster 6mo ago
    Ofc blocking assign is used too and even it that always_comb case scheduler splits eval/assign into 2 phases!
Taniwha 6mo ago
I'm a long time verilog user (30+ years, a dozen or so tapeouts), even written a couple of compilers so I'm intimate with the gory details of event scheduling. Used to be in the early days that some people depended on how the original verilog interpreter ordered events, it was a silly thing (models would only run on one simulator, cause of lots of angst). '<=' assignment fixed a lot of these problems, using it correctly means that you can model synchronous logic without caring about event ordering (at the cost of an extra copy and an extra event which can be mostly optimised away by a compiler). In combination 'always @(*)' and '=', and assign give you reliable combinatorial logic. In real world logic a lot of event ordering is non deterministic - one signal can appear before/after another depending on temperature all in all it's best not to design depending it if you possibly can, do it right and you don't care about event ordering, let your combinatorial circuits waggle around as their inputs change and catch the result in flops synchronously. IMHO Verilog's main problems are that it: a) mixes flops and wires in a confusing way, and b) if you stay away from the synthesisable subset lets you do things that do depend on event ordering that can get you into trouble (but you need that sometimes to build test benches)
- Taniwha 6mo ago
  BTW my really big peeve about modern verilog is that it never picked up {/} as synonyms for begin/end - my experiments (20 years ago) showed that it was an easy extension, the minor syntactic ambiguities were trivally fixable
xihe-forge 6mo ago
[dead]
jeffreygoesto 6mo ago
Reminds me a lot of "Logical Execution Time" and the work of Edward Lee ("The Problem With Threads") for a software equivalent. Determinism needs sparation of computation from communication.
SilverBirch 6mo ago
Needs a [2010] tag. In almost all modern hardware development you'll have coding guidelines along the lines of "Always use blocking assignments for comb logic, always use non-blocking for sequential logic". You end up back at the same place as VHDL, by nature SystemVerilog is much weaker typed than VHDL. So you have to just have conventions in order to regain some level of safety.
latenode 6mo ago
VHDL gets treated like a legacy language nobody wants to touch but the people who actually use it tend to be very serious about why they still do.
zackmorris 6mo ago
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 into the best college that you can, because as long as you're learning stuff, you might as well learn the most rigorous way of doing it. --- It's these sorts of nuances that make me skeptical of casual languages like Ruby and even PHP (my favorite despite its countless warts). I wish that we had this level of insight back during the PHP 4 to 5 transition, because so many easily avoidable mistakes were made in a design-by-committee fashion. For example, PHP classes don't use copy-on-write like arrays, so we missed out on avoiding a whole host of footguns, as well as being able to use [] or -> interchangeably like in JavaScript. While we're at it, the "." operator to join arrays was a tragic choice (they should have used & or .. IMHO) because then we could have used "." for the object operator instead of -> (borrowed from C++), but I digress. I often dream of writing a new language someday at the intersection of all of these lessons learned, so that we could write imperative-looking code that runs in a functional runtime. It would mostly encourage using higher-order methods strung together, but have a smart enough optimizer that it can handle loops and conditional logic by converting them to higher-order methods internally (since pure code has no side effects). Basically the intermediate code (i-code) would be a tree representation in the same form as Lisp or a spreadsheet, that could be transpiled to all of these other languages. But with special treatment of mutability (monadic behavior). The code would be pure-functional but suspend to read/write outside state in order to enforce the functional core, imperative shell pattern. A language like that might let us write business logic that's automatically parallelized and could be synthesized in hardware unmodified. It would tend to execute many thousands of times faster than anything today on modifiable hardware like an FPGA. I'd actually prefer to run it on a transputer, but those fell out of fashion decades ago after monopoly forces took over.
- 0xsn3k 6mo ago
  maybe clash [1] would be interesting to you then? [1] https://clash-lang.org/ https://clash-lang.org/
gsmecher 6mo ago
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 arithmetic: for VHDL, this was an extension to the IEEE libraries, and didn't require a change to the underlying language (think of how c++'s std:: evolves somewhat separately from compilers). Verilog's type system is insufficiently expressive to add fixed-point types without changes to the language itself. This positions VHDL better for e.g. low-precision quantization for AI/ML. In any case, the VHDL/Verilog language wars are over, and while VHDL "lost", it's clear the victory was partly Pyrrhic - RTL probably has a polyglot future, and everyone's waiting (with mixtures of resignation and hope, but very little held breath) for something better to come along.
- oelang 6mo ago
  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.
  - gsmecher 6mo ago
    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...
seertaak 6mo ago
Interesting article; I've always been fascinated and intimidated by FPGA programming - it's one of the few remaining "dark arts" of software engineering. > VHDL’s delta cycle algorithm is its crown jewel. It gives you built-in determinism. Let us treasure it - Verilog doesn’t have anything like it. At the same time, you will agree with me that there is nothing too complicated about the concept. I agree with you -- and thank you!

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 blocking assignments for combinational logic—fail as soon as the scenario becomes slightly complex. Verilog is suitable when you already have the circuit in your head and just need to write it down quickly. In contrast, VHDL forces you to think about concurrent processes in the correct way. While the former is faster to write, the latter is the correct approach. Even though SystemVerilog added some patches, the underlying execution model still has inherent race conditions.

tverbeure 6mo ago
I used to be a huge VHDL proponent, talk about the delta cycle stuff, give VHDL classes at work to new college grads and such. And then I moved to the West Coast and was forced to start using Verilog. And in the 21 years since, I’ve never once ran into an actual simulation determinism issues. It’s not bad to have a strict simulation model, but if some very basic coding style rules are followed (which everybody does), it’s just not a problem. I don’t agree at all with the statement that Verilog fails when things become too complex. The world’s most complex chips are built with it. If there were ever a slight chance that chips couldn’t be designed reliably with it, that could never be the case. Anyway, not really relevant, but this all reminds me of the famous Verilog vs VHDL contest of 1997: https://danluu.com/verilog-vs-vhdl/ https://danluu.com/verilog-vs-vhdl/
- e7h4nz 6mo ago
  On a practical level, you're right, most of my team's work is done in Verilog. That being said, I still have a preference for the VHDL simulation model. A design that builds correctness directly into the language structure is inherently more elegant than one that relies on coding conventions to constrain behavior.
  - tverbeure 6mo ago
    My memory is definitely rusty on this, but you can easily construct cases where the VHDL delta cycle model creates problems where it doesn’t for Verilog. I remember inserting clock signal assignments in VHDL to get a balanced delta cycle clock tree. In Verilog, that all simply gets flattened. I can describe the VHDL delta cycle model pretty well, and I can’t for Verilog, yet the Verilog model has given me less issues in practice As for elegance: I can’t stand the verboseness of VHDL anymore. :-)
    - y1n0 6mo ago
      Reassigning clocks to another signal name will quickly get you into trouble in ways the just don’t happen on real hardware.
      - tverbeure 6mo ago
        Have you heard about clock buffers and hold violations?
        y1n0 6mo ago
        No, is that the latest craze?
  - JoachimS 6mo ago
    The question for me is, where do I catch, describe the physical reality the model describes? A simulation model can be very elegant. But does it represent how physical things really behave? Can we even expect to do that at RTL, or further down the design flow? As the name suggest, we are talking about transferring data between registers. In the RTL that is what I can expect to describe. At the end of the day, what I write will become an electrical circuit - in a FPGA or an ASIC (or both), having the complex exact modelling with wire delays, capacitance, cross talk, cell behavior too early makes it impossibly to simulate fast enough to iterate. So then we need to have a more idealized world, but keeping in mind that (1) it is an idealized world and (2) sooner or later the model will be the rubber on the road. To me, Verilog and SystemVerilog allow me to do this efficiently. Warts and all. Oh, and also, where in my toolchain is my VHDL model translated/transformed into Verilog? How good is that translation? How much does the dual licensing cost. Things like mixed language simulation, formal verification between a verilog netlist and RTL in Verilog, mapping to cell libraries in Verilog. Integration of IP cores written in SystemVerilog with your model? Are the tools for VHDL as well tested as with code in Verilog? How big is the VHDL team at the tool vendor, library vendor, IP vendor, fab vendor compared to the Verilog, SV team? Can I expect the same support as a VHDL user as for Verilog? How much money does a vendor earn from VHDL customers compared to Verilog, SV? How easy is it to find employees with VHDL experience? VHDL may be a very nice language for simulation. But the engineering, business side is messy. And dev time, money can't be ignored. Getting things as fast and cheap as possibly still meeting a lot of functional, business requirements is what we as engineers are responsible for. Does VHDL make that easier or not?
- formerly_proven 6mo ago
  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 with a tool does not mean the tool didn't impede (or vice versa, enable) the result. It just says that it's possible. A qualitative comparison with other tools cannot be established on that basis.
  - Joel_Mckay 6mo ago
    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 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
    - rzerowan 6mo ago
      How does this compare to chisel [1] , i never could get around the whole scala tooling - seemed a bit over the top. Though i guess it is a bit more mature and probably more enterprisey [1]https://github.com/chipsalliance/chisel https://github.com/chipsalliance/chisel
      - Joel_Mckay 6mo ago
        > i never could get around the whole scala tooling scala is popular in places like Alphabet, that apparently allow go & scala projects in production. However, I agree while scala is very powerful in some ways, it just doesn't have a fun aesthetic. If one has to go spelunking for scalable hardware accelerators, a vendors linux DMA llvm C/C++ API is probably less fragile. For my simple projects, one zynq 7020 per node is way more than we should ever need. =3
    - 6mo ago
lifis 6mo ago
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 any software written in those languages. So it doesn't seem important at all. In fact, for software simulation of hardware you'd want the simulation to randomly choose anything possible in hardware, so the Verilog approach seems correct.
- oelang 6mo ago
  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.
thesz 6mo ago
> 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. This is what I use when I play with hardware simulation in Haskell: type S a = [a] register :: a -> S a -> S a register a0 as = a0:as -- combinational logic can be represented as typical pure -- functions and then glued into "circuits" with register's -- and map/zip/unzip functions. This thing also separates externally visible events recorded in the (infinite) list of values from externally unobservable pure (combinational) logic. But, one can test combinational logic separately, with property based testing, etc.

buildbot 6mo ago

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 partially.) ((Shai-Hulud Desires the Verilog))

tverbeure 6mo ago
AFAIK, creating latches is just as easy in Verilog as in VHDL. They use the same model to determine when to create one. But with a solid design flow (which should include linting tools like Spyglass for both VHDL and Verilog), it’s not a major concern.
- nickelpro 6mo ago
  SystemVerilog basically fixes this with always_comb vs always_latch. There's no major implementation which doesn't handle warning or even failing the flow on accidental latch logic inside an always_comb.
hrmtst93837 6mo ago
[flagged]
- buildbot 6mo ago
  That does sound like my experience…
- tverbeure 6mo ago
  > Once the design gets past toy size, Do you consider 800+mm2 slabs of 3nm of silicon still toy size? Because there's a very high chance that those were written in Verilog, and I've never had to chase sim vs synthesis mismatches. > Verilog gives you enough rope. Yes. If you don't know what you're doing and don't follow the industry standard practises.
6mo ago

arianvanp 6mo ago

Sounds like reachability problem in Petri nets to me?

CorrectHorseBat 6mo ago

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?

artemonster 6mo ago
Draw yourself an SR latch and try simulating. Or a circuit what is known as „pulse generator“
- CorrectHorseBat 6mo ago
  Those are analog circuits, if you put them in your digital design you are doing something wrong.
  - kryptiskt 6mo ago
    All circuits are analog when physically realized, the digital view is an abstraction.
  - artemonster 6mo ago
    dont know if trolling. SR latch you can do with 2 NANDs, or NORs there are plenty of *digital* circuits with that functionality, and yes, there are very rare cases when you construct this out of logic and not use a library cell for this. pulse circuit is AND(not(not(not(a))),a) also rarely used but used nonetheless. to properly model/simulate them you would need delta cycles
    - CorrectHorseBat 6mo ago
      I'm not sure if you are trolling. 99.999% of digital design is "if rising edge clk new_state <= fn(old_state, input)", with an (a)sync reset. The language should make that the default and simple to do, and anything else out of the ordinary hard. Now it's more the other way around.

artemonster 6mo ago

Please stop bickering about verilog vs vhdl - if you use NBAs the scheduler works exactly the same in modern day simulators. There is no crown jewel in vhdl anymore. Also type system is annoying. Its just in your way, not helping at all.

alain94040 6mo ago
You're not wrong, but blocking assignments (and their equivalent in VHDL, variables), are useful as local variables to a process/always block. For instance to factor common sub-expressions and not repeat them. So using only non-blocking assignments everywhere would lead to more ugly code.
- artemonster 6mo ago
  Ofc blocking assign is used too and even it that always_comb case scheduler splits eval/assign into 2 phases!

Taniwha 6mo ago

I'm a long time verilog user (30+ years, a dozen or so tapeouts), even written a couple of compilers so I'm intimate with the gory details of event scheduling. Used to be in the early days that some people depended on how the original verilog interpreter ordered events, it was a silly thing (models would only run on one simulator, cause of lots of angst). '<=' assignment fixed a lot of these problems, using it correctly means that you can model synchronous logic without caring about event ordering (at the cost of an extra copy and an extra event which can be mostly optimised away by a compiler). In combination 'always @(*)' and '=', and assign give you reliable combinatorial logic. In real world logic a lot of event ordering is non deterministic - one signal can appear before/after another depending on temperature all in all it's best not to design depending it if you possibly can, do it right and you don't care about event ordering, let your combinatorial circuits waggle around as their inputs change and catch the result in flops synchronously. IMHO Verilog's main problems are that it: a) mixes flops and wires in a confusing way, and b) if you stay away from the synthesisable subset lets you do things that do depend on event ordering that can get you into trouble (but you need that sometimes to build test benches)

Taniwha 6mo ago
BTW my really big peeve about modern verilog is that it never picked up {/} as synonyms for begin/end - my experiments (20 years ago) showed that it was an easy extension, the minor syntactic ambiguities were trivally fixable

xihe-forge 6mo ago

[dead]

jeffreygoesto 6mo ago

Reminds me a lot of "Logical Execution Time" and the work of Edward Lee ("The Problem With Threads") for a software equivalent. Determinism needs sparation of computation from communication.

SilverBirch 6mo ago

Needs a [2010] tag. In almost all modern hardware development you'll have coding guidelines along the lines of "Always use blocking assignments for comb logic, always use non-blocking for sequential logic". You end up back at the same place as VHDL, by nature SystemVerilog is much weaker typed than VHDL. So you have to just have conventions in order to regain some level of safety.

latenode 6mo ago

VHDL gets treated like a legacy language nobody wants to touch but the people who actually use it tend to be very serious about why they still do.

zackmorris 6mo ago

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 into the best college that you can, because as long as you're learning stuff, you might as well learn the most rigorous way of doing it. --- It's these sorts of nuances that make me skeptical of casual languages like Ruby and even PHP (my favorite despite its countless warts). I wish that we had this level of insight back during the PHP 4 to 5 transition, because so many easily avoidable mistakes were made in a design-by-committee fashion. For example, PHP classes don't use copy-on-write like arrays, so we missed out on avoiding a whole host of footguns, as well as being able to use [] or -> interchangeably like in JavaScript. While we're at it, the "." operator to join arrays was a tragic choice (they should have used & or .. IMHO) because then we could have used "." for the object operator instead of -> (borrowed from C++), but I digress. I often dream of writing a new language someday at the intersection of all of these lessons learned, so that we could write imperative-looking code that runs in a functional runtime. It would mostly encourage using higher-order methods strung together, but have a smart enough optimizer that it can handle loops and conditional logic by converting them to higher-order methods internally (since pure code has no side effects). Basically the intermediate code (i-code) would be a tree representation in the same form as Lisp or a spreadsheet, that could be transpiled to all of these other languages. But with special treatment of mutability (monadic behavior). The code would be pure-functional but suspend to read/write outside state in order to enforce the functional core, imperative shell pattern. A language like that might let us write business logic that's automatically parallelized and could be synthesized in hardware unmodified. It would tend to execute many thousands of times faster than anything today on modifiable hardware like an FPGA. I'd actually prefer to run it on a transputer, but those fell out of fashion decades ago after monopoly forces took over.

0xsn3k 6mo ago
maybe clash [1] would be interesting to you then? [1] https://clash-lang.org/ https://clash-lang.org/

gsmecher 6mo ago

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 arithmetic: for VHDL, this was an extension to the IEEE libraries, and didn't require a change to the underlying language (think of how c++'s std:: evolves somewhat separately from compilers). Verilog's type system is insufficiently expressive to add fixed-point types without changes to the language itself. This positions VHDL better for e.g. low-precision quantization for AI/ML. In any case, the VHDL/Verilog language wars are over, and while VHDL "lost", it's clear the victory was partly Pyrrhic - RTL probably has a polyglot future, and everyone's waiting (with mixtures of resignation and hope, but very little held breath) for something better to come along.

oelang 6mo ago
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.
- gsmecher 6mo ago
  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...

seertaak 6mo ago

Interesting article; I've always been fascinated and intimidated by FPGA programming - it's one of the few remaining "dark arts" of software engineering. > VHDL’s delta cycle algorithm is its crown jewel. It gives you built-in determinism. Let us treasure it - Verilog doesn’t have anything like it. At the same time, you will agree with me that there is nothing too complicated about the concept. I agree with you -- and thank you!