I don't see a difference. The modicum of skill has just moved disciplines.

A Chimpanzee with a torque wrench could render a car unsafe to drive, but I'd like to see him upload a new firmware.

Regardless, I don't see why it's felt that people employed by the car company are infallible. As a freelance engineer I move from company to company. There's a large proportion of engineers out there that have their hands tied because of office politics, are buried under red tape, are brow-beaten because of unrealistic deadlines or just aren't very good. These guys make mistakes, and often have to live with the bugs because the cost to fix them (financial or political, as deemed by their boss) is too great.

Customers are trusting their lives to this code. They should be allowed to see how good it is. Open it up and let people review and improve the code.

Yep, this is the right attitude. Use the language that has the type checking and strict structure, and then when the shackles come off people have already formed good habits.

I've done about 8 years of VHDL and so prefer it to Verilog, mainly because I'm more familiar with it, but I've had lots of conversations with Verilog engineers over the years saying "You can't do X with VHDL because it's too strict" and it's never true. Learning VHDL was tough, but doing it (and I've got a similar tale with Haskell for software) was what advanced my skills of RTL coding the most.

The key is not to fight the restrictions, but to understand why they are there and to see what they allow you to forget about. It's sounds almost zen, but sometimes restrictions let you flow. ...but never forget. The aim is to describe hardware, so you need to have in mind what hardware you want to synth at the end of the day. As such the language is always second to good hardware design.

I disagree with the statement that everybody has switched to System Verilog. I've worked with a few companies introducing it, and System Verilog is exactly the reason I want to go back to working with VHDL. It's horrible.

My take on it it is that a load of C++ engineers looked at Verilog and thought "What this needs is object orientation!" completely ignoring the fact that hardware description languages are OO by nature. After all, what is a module if not a method of encapsulating design leaving just a public interface.

The result is a horrible mess of a bi-polar language that can't decide if it's a software language or a hardware one, and the two sides don't really want to talk to each other. Add to that the fact that all of the design patterns that are being used with it are software patterns that don't map well to hardware, that most hardware engineers don't know, and you just get a big steaming pile when you try to introduce it to a company.

The EDA vendors love it because it's giving them a new set of tick boxes they can sell their wares on, but I've yet to see it do anything that I couldn't do in straight verilog / VHDL + a little PLI/FLI, and I've been working as a system verilog application engineer for one of the EDA companies. ...oh and it's really slow (as in orders of magnitude).

Bookmarks are what your after and they came in a couple of versions ago.