Notes about the subset of Verilog and SystemVerilog that vl supports.
VL was originally based on our reading of the Verilog-2005 standard, IEEE Std 1364-2005. When page and section numbers are used throughout the VL documentation, they are often in reference to this document. VL now also supports a significant fragment of SystemVerilog, based on our reading of the SystemVerilog-2012 Standard, IEEE 1800-2012.
Verilog and SystemVerilog are huge languages. Accordingly, VL only supports a subset of each language. The precise subset that is supported varies depending on the particular flow that you are using. For instance:
Regardless of the particular flow you are using, all VL tools reuse the same loader, internal representation of Verilog syntax. The loader can read files as either Verilog-2005 or SystemVerilog-2012. Regardless of the input type, we arrive at the same internal representation (essentially SystemVerilog), and supporting functionality like mlib and our printer all work on this same representation.
VL's preprocessor is somewhat incomplete. It basically just supports
The lexer is essentially complete.
Regarding Veriog-2005, the parser doesn't currently support specify blocks and specparams. In some cases it is smart enough to at least skip over the unsupported construct. Depending on what you are doing, this behavior may be actually appropriate (e.g., skipping specify blocks may be okay if you aren't trying to deal with low-level timing issues.)
Regarding SystemVerilog-2012, the parser notably lacks support for SystemVerilog assertions, classes, configs, and probably many other constructs, and many other particular SystemVerilog extensions may not yet be implemented.
VL has some ability to tolerate constructs that aren't really supported, and the general philsophy is that an error in some particular module shouldn't affect other modules. If the parser runs into an syntax error or an unsupported construct, it often only causes that particular module to be skipped. When transforms encounter unsupported things or run into problems, we usually avoid hard errors and instead just add "fatal warnings" to the module with the problem.