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

21–30 of 65 posts

Re: VHDL's Crown Jewel

#21

Post by SilverBirch »

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?

What do you mean by simulate? Do you want the language to be aware of the temperature of the silicon? Because I can build you circuits whose behaviour changes due to variation in the temperature of the silicon. Essentially all these languages are not timing aware. So you design your circuit with combinatorial logic and a clock, and then hope (pray) that your compiler makes it meet timing.

The fundamental problem is that we're trying to create a simulation model of real hardware that is (a) realistic enough to tell us something reasonable about how to expect the hardware to behave and (b) computationally efficient enough to tell us about a in a reasonable period of time.

Re: VHDL's Crown Jewel

#22

Post by formerly_proven »

tverbeure wrote: post #3
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 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),…

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.

Re: VHDL's Crown Jewel

#23

Post by JoachimS »

tverbeure wrote: post #11
JoachimS wrote: post #8

Earlier quoted context omitted.

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…

> where in my toolchain is my VHDL model translated/transformed into Verilog? It's not? Why would it? As much as I like Verilog, VHDL is a first class RTL language just like Verilog. I've done plenty of chips that contain both VHDL and Verilog. They both translate directly to gate level. These days, most EDA tools use Verific parser and elaborator front-ends. The specific tool magic happens after that and that API is…

Involved in FPGA and ASIC projects since 1997. Predominantly in Europe, nowadays more Asia and some in the US. Since ~2010 I have only seen VHDL in small chops targeting only FPGAs, and in government-heavy projects like defence and space. Nowadays these are also by and large SV. The ratio is something like one in VHDL for 20 Verilog, SV projects. They teach VHDL at universities, and then ppl get to experience SV as soon as they enter the market.

Typical issues are still as given before. Many small IP vendors, esp for communication, networking are using and understand, support only SV. I agree on SV for verification is a big driver.

Re: VHDL's Crown Jewel

#24

Post by audunw »

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 we end up with delta cycles.

Re: VHDL's Crown Jewel

#25

Post by CorrectHorseBat »

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“

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

Re: VHDL's Crown Jewel

#26

Post by SilverBirch »

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.

Re: VHDL's Crown Jewel

#27

Post by Joel_Mckay »

formerly_proven wrote: post #22
tverbeure wrote: post #3

Earlier quoted context omitted.

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),…

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

Re: VHDL's Crown Jewel

#28

Post by lifis »

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

Re: VHDL's Crown Jewel

#29

Post by rzerowan »

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

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

Re: VHDL's Crown Jewel

#30

Post by ithkuil »

SilverBirch wrote: post #21
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?

What do you mean by simulate? Do you want the language to be aware of the temperature of the silicon? Because I can build you circuits whose behaviour changes due to variation in the temperature of the silicon. Essentially all these languages are not timing aware. So you design your circuit with combinatorial logic and a clock, and then hope (pray) that your compiler makes it meet timing. The fundamental problem is t…

"All sensors are temperature sensors, some measure other things as well"
Post reply on HN