Finds and loads Verilog or SystemVerilog source files—generally
the first step toward using VL to work with a hardware design.
Most Verilog designs involve many files spread out across multiple
directories. To really load a high-level module top, we typically need
- start by parsing its file, say top.v or top.sv, then
- figure out which supporting descriptions are used within top and
- use a search procedure to load these supporting descriptions from library
VL's top-level function for loading Verilog files, vl-load,
implements such a scheme. It has various options (see vl-loadconfig)
that allow you to specify the search paths and extensions to use when looking
for files, etc. A typical command to load a design might look something like
(defconsts (*loadresult* state)
:start-files (list "top.v")
:search-path (list "/path/to/lib1"
:include-dirs (list "/path/to/includes1"
:defines (make-vl-initial-defines "FORMAL")
The resulting *loadresult* will be a vl-loadresult, which among
other things will contain the vl-design that has been loaded. The next
step after loading is typically to annotate the design using vl-annotate-design, and then to further processing it in whatever way is
suitable for your particular flow.
Supported Constructs and Workarounds
For general background on what VL supports, see supported-constructs.
A common problem when working with a Verilog or SystemVerilog design is that
you want to process the design with many tools, and these tools may not all
support quite the same constructs. One common way to work around these issues
is with preprocessor directives. For instance, you might write
... something VL can't handle ...
... replacement for VL ...
Note that vl-load does not automatically set up any such `define
directives by default, but it's easy to give custom defines in your vl-loadconfig.
Besides the preprocessor, VL also supports a special comment syntax that can
be used to hide VL-specific code from other tools:
//+VL single-line version
/*+VL multi-line version */
For instance, if you need your modules to work with an old Verilog
implementation that doesn't support Verilog-2005 style attributes, you might
write something like:
//+VL (* my_attribute *)
assign foo = bar;
VL will still parse the (* my_attribute *) part since it is in this
special comment. VL also provides a special, more concise syntax for
Note that you can also disable these special comments with the strictp
option on your vl-loadconfig.
- Limited preprocessor for Verilog.
- Options for how to load Verilog modules.
- Internal state object used throughout the VL loading routines.
- A lexer for Verilog and SystemVerilog.
- A parser for a subset of Verilog and SystemVerilog.
- Merge newly found Verilog descriptions with previously loaded
descriptions, warning about any multiply defined descriptions.
- Alternative to vl-find-file that can take a list of
- Main function for loading a single Verilog file.
- Return value from vl-load.
- How VL and other tools handle the scope of `defines.
- Determine where to load a file from, given its (absolute or relative)
name and a list of directories to search.
- Attempt to find and load any missing modules.
- Representation of an arbitrary, top-level element.
- Read an entire file into a list of extended characters.
- Top level interface for loading Verilog sources.
- Characters with additional annotations.
- Wrapper for vl-load-main that also reports errors or (with
some configuration) can print other information.
- Try to load a description from the search path.
- Determine which descriptions we still need to load.
- Mechanism for attaching warnings to particular modules or
other design elements.
- Extend vl-load-description to try to load a list of descriptions.
- Load a list of files.
- Warnings about comments like // synopsys translate_off.
- Prefix for lines produced by the loader.
- Print summary information (e.g., warnings, numbers of modules loaded,
etc.) after modules have been loaded.
- A list of vl-description-p objects.