VHDL is ok, Verilog is a sin.

The issue isn't the languages, it's the horrible tooling around them. I'm not going to install a multi GB proprietary IDE that needs a GUI for everything and doesn't operate with any of my existing tools. An IDE that costs money, even though I already bought the hardware. Or requires an NDA. F** that.

I want to be able to do `cargo add risc-v` if I need a small cpu IP, and not sacrifice a goat.

▲ VonTum 2 hours ago | parent | next [-]

Well really, the language _is_ the difficulty of much of hardware design, both Verilog and VHDL are languages that were designed for simulation of hardware, and not synthesis of hardware. Both languages have of similar-but-not-quite ways of writing things, like blocking/nonblocking assigns causing incorrect behavior that's incredibly difficult to spot on the waveform, not being exhaustive in assigns in always blocks causing latches, maybe-synthesizeable for loops, etc. Most of this comes from their paradigm of an event loop, handling all events and the events that those events trigger, etc, until all are done, and advancing time until the next event. They simulate how the internal state of a chip changes every clock cycle, but not to actually do the designing of said chip itself.

I'm tooting my own horn with this, as I'm building my own language for doing the actual designing. It's called SUS.

Simple things look pretty much like C:

  module add :
    int#(FROM:-8, TO: 8) a,
    int#(FROM: 2, TO: 20) b -> 
    int c {
    c = a+b
  }

It automatically compensates for pipelining registers you add, and allows you to use this pipelining information in the type system.

It's a very young language, but me, a few of my colleagues, and some researchers in another university are already using it. Check it out => https://github.com/pc2/sus-compiler

	▲	kevin_thibedeau an hour ago \| parent [-]
		VHDL was designed for specification. Verilog is the one with the warts from its simulator heritage.

▲ blackguardx 3 hours ago | parent | prev | next [-]

You can pretty much do everything in Vivado from the command line as long as you know Tcl...

Also, modern Verilog (AKA Systemverilog) fixes a bunch of the issues you might have had. There isn't much advantage to VHDL these days unless perhaps you are in Europe or work in certain US defense companies.

▲

Cadwhisker 3 hours ago | parent | next [-]

# Here's the general flow for Vivado TCL projects that takes you from source code to a bit-file with no interaction. Read UG835 for details.

create_project -in_memory -part ${PART}

set_property target_language VHDL [ current_project ]

read_vhdl "my_hdl_file.vhd"

synth_design -top my_hdl_top_module_name -part ${PART}

opt_design

place_design

route_design

check_timing -file my_timing.txt

report_utilization -file my_util.txt

write_checkpoint my_routed_design.dcp

write_bitstream my_bitfile.bit

▲

exmadscientist 3 hours ago | parent | prev [-]

The main advantage to VHDL is the style of thinking it enforces. If you write your Verilog or SystemVerilog like it's VHDL, everything works great. If you write your VHDL like it's Verilog, you'll get piles of synthesis errors... and many of them will be real problems.

So if you learn VHDL first, you'll be on a solid footing.

	▲	pclmulqdq an hour ago \| parent \| next [-]
		There is a trend among programmers to assume that everything supported by the syntax can be done. This is not even true in C++, but it's something people think. If you are writing synthesizable SystemVerilog, only a small subset of the language used in a particular set of ways works. You have to resist the urge to get too clever (in some ways, but in other ways you can get extremely clever with it).
	▲	blackguardx 2 hours ago \| parent \| prev [-]
		I think this can just be summarized to "write any HDL like you are modeling real hardware." Both VHDL and Systemverilog were primarily intended for validation and synthesis is a second class citizen.

▲ tverbeure 3 hours ago | parent | prev [-]

Or you could do the right thing, ignore the GUI for 99% of what you’re doing, and treat the FPGA tools as command line tools that are invoked by running “make”…

▲

pclmulqdq an hour ago | parent [-]

This is how most FPGA users interact with vivado/quartus these days.

	▲	tverbeure 4 minutes ago \| parent [-]
		One really wonders when reading some of the comments here…