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

11–20 of 65 posts

Re: VHDL's Crown Jewel

#11

Post by tverbeure »

JoachimS wrote: post #8
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.

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

> How easy is it to find employees with VHDL experience?

On the East Coast and in Europe: much easier than finding employees with Verilog experience. (At least that was the case 20 years ago, I have no clue how it is today.)

One thing that has changed a lot is that SystemVerilog is now the general language of choice for verification, which helps give (System)Verilog an edge for RTL design too.

Re: VHDL's Crown Jewel

#12

Post by Joel_Mckay »

JoachimS wrote: post #8
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.

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…

Over the years I have run Altera, Lattice, and Xilinx... and almost all reasonably complex projects were always done in Verilog. If I recall Xilinx fully integrated its Synopsys export workflow a few years back, but not sure where that went after the mergers.

The Amaranth HDL python project does look fun =3

https://github.com/amaranth-lang/amaranth

Re: VHDL's Crown Jewel

#13

Post by artemonster »

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“

Re: VHDL's Crown Jewel

#14

Post by tverbeure »

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?

> Why don't VHDL and Verilog just simulate what hardware does?

Real hardware has hold violations. If you get your delta cycles wrong, that's exactly what you get in VHDL...

They're both modeling languages. They can model high-level RTL or gate-level and they can behave very different if you're not careful. "just simulation what the hardware does" is itself an ambiguous statement. Sometimes you want one model, sometimes the other.

Re: VHDL's Crown Jewel

#15

Post by novachen »

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…

the geographic constraint is probably the real answer to "which is better" for most people. you learn what your team uses, what your local jobs demand. theoretical elegance matters less than "can i get hired next month"

Re: VHDL's Crown Jewel

#16

Post by artemonster »

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.

Re: VHDL's Crown Jewel

#17

Post by Taniwha »

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

'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)

Re: VHDL's Crown Jewel

#20

Post by hrmtst93837 »

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]
Post reply on HN