		Search-engine friendly clone of the ACL2 documentation.

Getting-started

Supported-constructs

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:

The older esim flow was developed primarily to handle Verilog-2005 designs. It primarily handles RTL-based designs. It has trouble with transistor-level constructs, hierarchical identifiers, inout ports, and fancy procedural statements. It lacks support for most SystemVerilog features.
The newer sv flow provides much better support for SystemVerilog features like structures, arrays, interfaces, and hierarchical identifiers. It does not currently handle transistor-level constructs or simulation constructs like dynamic arrays, tasks, classes, etc.
The vl-lint flow can cope with richer SystemVerilog designs. It is not especially bothered by transistor-level constructs. It cannot handle some simulation constructs, but is able to ignore many constructs when it does not truly understand them.

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 `define and `ifdef-related stuff. It can `include files in the style of the +incdir options for tools like Verilog-XL, NCVerilog, and VCS. It also supports a notion of search paths, which are similar to +libdir arguments.

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.

Subtopics

Vl-patternkey-ambiguity: Notes about our handling of vl-patternkeys.