[Traster]

I don't think the languages are the real problem. It's the tooling that sucks. The fact that simulation generally comes from a different vendor to the synthesis means that the simulation environment will implement the behaviour of the language, not the behaviour of the target device. This means you can never verify your design without a full hardware test - at which point you can't probe signals. That could be fixed if someone simulated devices accurately rather than simulating the specification of the language. This is exacerbated by synthesis warnings that range from "I one hot encoded your state machine as has been common since 1984" to "Yo dawg you forgot to reset this signal, so the set and reset priority are unclear, I'm gunna just fuck the whole of your design for ya". We all enjoy those post-synthesis log parsing scripts! By the way - they can't fix the logging because Cisco/Nokia/DoD have spent decades parsing those logs and if you change them you'll break their workaround.

Secondly, because the people who understand FPGAs are hardware engineers the tool vendors hire hardware engineers (and software engineers who are willing to tolerate hardware engineers) to write their software, the result is tools written using the development practices of the dark ages.

End of rant.

[willis936]

In defense of the poor hardware engineer: HDLs are not like other programming languages. You are literally writing a netlist of a circuit. Hardware engineers are hired to write FPGA code because it is a hardware design problem, not a software one.

[rowanG077]

I really disagree with this. HDLs are exactly like other programming languages. What in your mind makes HDLs fundamentally different to software languages? Your point about netlists doesn't convince me at all since you aren't creating netlists with a HDL. A description written in a HDL can be turned into a netlist.

[willis936]

Have you ever worked with HDLs before? The thing you are working on Is a netlist, not abstract code. As the name implies, you are describing hardware rather than abstract software. The layers of abstraction are ones that are built by the programmer (or defined in hardware block libraries) rather than ones from a language. HDLs do not have a single entry point. Every line of code runs concurrently with every other line of code. It simply is not like typical programming.

[rowanG077]

Yes I have used HDLs. You are working on a creating a hardware configuration. But you are not writing a netlist. That is like saying when you are writing a software program that you are "working on the machine code". The only difference between a HDL and "software" languages is a different set of restrictions. Every software language/framework or whatever also has unique restrictions. The restrictions HDLs have are not in any significant way tangibly different then those that exist in the software land.

You have software languages as well where "every line of code runs concurrently". Any dataflow framework for instance. That's not even to name functional languages where evaluation of statements can be done completely in parallel based on data dependencies.

Software is a lot more then the old c style run a program line by line until it hits the end of main().

[zoltanlehoczky]

I agree with the tooling issue. One of the reason we started Hastlayer was the viewpoint that "I'm a .NET developer with Visual Studio and everything else. Why would I want to use this thing created by Xilinx/Altera (Intel)?"