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

31–40 of 65 posts

Re: VHDL's Crown Jewel

#31

Post by y1n0 »

tverbeure wrote: post #6
e7h4nz wrote: post #5

Earlier quoted context omitted.

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.

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…

Reassigning clocks to another signal name will quickly get you into trouble in ways the just don’t happen on real hardware.

Re: VHDL's Crown Jewel

#32

Post by Joel_Mckay »

rzerowan wrote: post #29
Joel_Mckay wrote: post #27

Earlier quoted context omitted.

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

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

> 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

Re: VHDL's Crown Jewel

#33

Post by buildbot »

hrmtst93837 wrote: post #20
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…

[flagged]

That does sound like my experience…

Re: VHDL's Crown Jewel

#34

Post by thesz »

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…

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

Re: VHDL's Crown Jewel

#35

Post by nsteel »

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

I disagree. We've produced numerous complex chips with VHDL over the last 30 years. Most of the vendor models we have to integrate with are Verilog, so perhaps it is more popular, but that's no problem for us. We've found plenty of bugs for both VHDL and Verilog in the commercial tooling we use, neither is particularly worse (providing you're happy to steer clear of the more recent VHDL language features).

Re: VHDL's Crown Jewel

#36

Post by kryptiskt »

CorrectHorseBat wrote: post #25
artemonster wrote: post #13

Earlier quoted context omitted.

Draw yourself an SR latch and try simulating. Or a circuit what is known as „pulse generator“

Those are analog circuits, if you put them in your digital design you are doing something wrong.

All circuits are analog when physically realized, the digital view is an abstraction.

Re: VHDL's Crown Jewel

#37

Post by tverbeure »

y1n0 wrote: post #31
tverbeure wrote: post #6

Earlier quoted context omitted.

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…

Reassigning clocks to another signal name will quickly get you into trouble in ways the just don’t happen on real hardware.

Have you heard about clock buffers and hold violations?

Re: VHDL's Crown Jewel

#38

Post by artemonster »

CorrectHorseBat wrote: post #25
artemonster wrote: post #13

Earlier quoted context omitted.

Draw yourself an SR latch and try simulating. Or a circuit what is known as „pulse generator“

Those are analog circuits, if you put them in your digital design you are doing something wrong.

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

Re: VHDL's Crown Jewel

#39

Post by hardolaf »

artemonster wrote: post #13
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?

Draw yourself an SR latch and try simulating. Or a circuit what is known as „pulse generator“

Both SystemVerilog and VHDL have AMS extensions for simulating analog circuits. They work pretty well but you also pay a pretty penny for the simulator licenses for them.
Post reply on HN