News for hackers. Stuff that matters.
Re:Verifying ARM processors against the official ARM specifi... by ChuckMcM on Wednesday July 27, 2016 @12:03AM (#12170458)
I found the free VHDL tools from Altera and Xilinx to be quite good from a spec completeness point of view. At least for their tools what you "paid" for was a better synthesis back end. I built a 7 segment HEX decoder which should have synthesized to 2 LUTs on a Xilinx chip but it kept synthesizing to 14. I finally spec'd it in VHDL as a series of gates (practically RTL) and that worked. The paid version got it into 2 LUTs pretty much no matter how I specified it.
Re:Verifying ARM processors against the official ARM specifi... by dewster on Wednesday July 27, 2016 @11:15AM (#12173487)
Altera Quartus has supported SV (SystemVerilog) quite well for some time now. I tend to work in 9.1sp2 as that was the last version of Quartus with integrated simulator (waaa!).

Xilinx requires you to use their newer tooling in order to write in SV. As these tools tend to be incredibly bloated, this is a disadvantage IMO (you want to use the earliest and therefore least bloaty tool that does the job).

I started out in VHDL and was forced by the other person on the "team" to learn verilog for a project. As with ANY language, you end up trying a bunch of stuff out to see how things are implemented, what breaks, etc. in order to get your footing. Over time I grew to appreciate the C like nature of verilog - its reduced verboseness over VHDL makes it an easier language to get actual things done in. And it makes switching between C and verilog pretty natural.

I resisted looking into SystemVerilog for forever as I was under the impression that it was more of a systems verification thing, but it is actually just plain old verilog with some incredibly useful extensions for synthesis. The package system is really, really nice. Look online for papers by Stuart Sutherland. No language is perfect, and there are things I would change in SV (support for negative bit indices, less awkward sub vector select, etc.) but SV comes closest to the ideal HDL IMO. HW design via HDL is fascinating, and a strangely small space for the times we live in.

Using high level languages to do clock-based concurrent stuff is IMO insane as it just adds to the chain breakage, and few will be trained and able to easily use the source. Would you listen to anyone who proposed a VHDL to Haskell converter for writing everyday conventional software? HDLs are close to the metal for a reason.