# 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

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.

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.

I haven't learned Verilog, only VHDL and even that with the explicit <register>_ff <= <register_nxt> pattern when I need flips flops and I never felt like there is anything difficult about VHDL

Is the North American insistence on teaching Verilog what's setting up students for failure since Verilog looks a bit more like a sequential programming language at first glance?

VHDL is based on Ada, so it also inherits from sequential programming models.

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

I thought that if you have some idea about how hardware works, it is kind of more or less obvious whether something is synthesizable or not.