Choosing a hardware description language is rarely just a matter of syntax. Existing IP, team knowledge, target technology and the verification environment shape the decision. VHDL, Verilog and SystemVerilog can all appear in the same development workflow. At each boundary, identify what is actually being described: synthesizable hardware, an abstract model or a test environment. Successful simulation alone does not establish that a circuit can be implemented.
Language and the subset used
VHDL is defined by IEEE 1076; the standard page referenced here lists IEEE 1076-2019. SystemVerilog is defined by IEEE 1800, whose 1800-2023 edition covers design and verification. The existence of a standard edition does not mean that every editor, simulator or synthesis tool implements its entire scope identically. IEEE 1076-2019: VHDL; IEEE 1800-2023: SystemVerilog.
A project should therefore avoid vague requirements such as “modern VHDL”. Name the approved language version and document exceptions with a reproducible example. The same applies to SystemVerilog constructs. A compiler may accept a file while the synthesis tool rejects parts of it or generates a different hardware structure from the one intended. The specific toolchain determines this boundary.
VHDL: Types as part of the interface
VHDL makes many type decisions explicit. This is particularly helpful when interfaces and arithmetic must be maintained over a long period. A bit vector initially describes a sequence of values; a suitable numeric type gives it an arithmetic interpretation. That precision sometimes requires additional conversions, but it makes assumptions reviewable. Code review should therefore examine types and ranges as well as operators.
-- Eigenes VHDL-Beispiel für eine explizite Verbreiterung:
-- a und b sind unsigned(7 downto 0), sum ist unsigned(8 downto 0).
sum <= resize(a, sum'length) + resize(b, sum'length);The operands are widened before addition, leaving room for the carry. Widening a result only after an addition has already been performed at insufficient width cannot recover a lost carry. This example illustrates a general review question that applies independently of the chosen language: where are width, signedness and interpretation established?
Use Verilog and SystemVerilog deliberately
Teams often encounter Verilog in existing IP, netlists and established projects. SystemVerilog adds language facilities for structure and verification. RTL and testbench code still need separate consideration. A class or dynamic data structure in the test environment is perfectly compatible with a static hardware interface in the DUT. They describe different responsibilities within the same test system.
When modernising a project, first establish a few clear conventions: explicit port types, defined process intent, consistent assignment rules and a reviewable reset style. Mechanically changing filename extensions does not improve a design. Every migration should be protected by the existing test suite, even if the new notation is shorter or initially looks easier to understand.
Check mixed-language boundaries
A mixed-language project does more than connect two text files. Names, vector directions, widths, parameters and value ranges must agree at the module boundary. Unknown states, initialisation, time resolution and the binding of specific implementations deserve particular care. A test that drives only zero and one can miss problems involving uninitialised or high-impedance values.
Start with a small boundary test. Examine one interface property at a time: simple bit transfer first, then vectors, followed by parameterisation and reset. Record the expected result independently of the internal implementation. This separates a language-interoperability problem from a functional defect in the design itself. With encrypted third-party IP, the vendor’s approved simulator configuration is another relevant constraint.
Verification follows the task
A VHDL DUT does not necessarily require a VHDL testbench; an existing team architecture may make another language appropriate. Conversely, a small VHDL testbench is often a direct starting point for checking a VHDL module. Assess maintainability, available libraries and debugability together. Switching language solely for a perceived increase in professionalism can introduce extra boundaries without improving verification depth.
A concrete failure case helps the decision. Can developers navigate from an error message to the correct source? Is the meaning of a transferred value unambiguous? Can the scenario be rerun outside the graphical interface? Strong answers reduce dependence on individual specialist knowledge. In the long term, this usually matters more than the shortest possible notation for a single process.
A sustainable project contract
Document the language and version for each source group, the libraries used, the expected interfaces and the separate entry points for synthesis and simulation. Review changes to that contract as carefully as RTL changes. The article on libraries and reproducible projects covers organisation; the self-checking testbench makes functional intent executable.
Sources and date
Research checked on 19 October 2026. IEEE 1076-2019: VHDL, IEEE 1800-2023: SystemVerilog.