VerilogCreator is a QtCreator plugin. It turns QtCreator into a Verilog 2005 IDE.
The plugin is still work in progress, but it already has enough functionality to analyze existing code bases or to develop new code. The current version supports Verilog 2005 syntax checking/coloring and semantic code navigation/highlighting; there are build configurations for Icarus, Verilator, Yosys and Tcl. Projects can be configured using a file format similar to qmake.
VerilogCreator can either open single verilog files or project configuration files with the suffix ".vlpro".
The vlpro file can be empty; in that case all Verilog files (default suffix ".v") located in the vlpro directory including subdirectories are assumed to be the source files of the project.
Vlpro files follow the same syntax as QtCreator pro files (see http://doc.qt.io/qt-5/qmake-project-files.html), but uses other variable names. The following variables are supported:
SRCFILES += /path/filename.v
SRCFILES += "/path with whitespace/filename.v"
SRCFILES += /firstpath/filename.v /secondpath/filename.v \
/thirdpath_on_new_line/filename.v
SRCFILES += /directory_path1/ filename1.v filename2.v /directory_path2/ filename3.v filename4.v
The variable SRCFILES
lets you add source files explicitly to your project. There are different syntax versions. You can add filenames with absolute or relative paths; if you add a directory path only then the following filenames are assumed to belong to the directory with the given path.
Note that path/filenames including whitespace have to be quoted by " ". Also note that you can add more than one element to a line separated by whitespace and that a \ lets you continue on the next line; this applies to all variables.
SRCEXT = .v .vl .verilog
The SRCEXT
variable can be used to override the expected suffix of verilog files. Default is ".v".
SRCDIRS += dirpath1 dirpath2 dirpath3*
SRCDIRS += dirpath4 -filename1 -filename2 dirpath5 -filename3
With the SRCDIRS
variable it is possible to add all verilog files in a given directory. All files with a suffix specified in SRCEXT are considered. There are different syntax versions. You can add directories with absolute or relative path. If you postfix the path with an "*" then also all subdirectories are implicitly added. If you want to leave out certain files add the filename to the line prefixed with "-".
LIBFILES +=
LIBDIRS +=
LIBEXT =
These variables are used the same way as their SRC counterparts. Use them to add Verilog files which are used but not modified by the present project.
INCDIRS += dirpath1 dirpath2
The variable INCDIRS
specifies where the parser looks for include files (included by the Verilog include compiler directive).
DEFINES += DISABLE_SV_ASSERTION "E203_PC_SIZE 24"
This has the same effect as the Verilog include compiler directive and affects all files. Note that also the syntax corresponds to Verilog defines; since Verilog uses whitespace to separate name and values you have to use quotes in the vlpro file.
There is also a variable BUILD_UNDEFS
by which defines can be deactivated in the command file generated for Icarus, Verilator and Yosys; you could for example define VERILATOR in the vlpro so VerilogCreator can see it but then use BUILD_UNDEFS = VERILATOR
to avoid define warnings in Verilator.
TOPMOD = picosoc
Use TOPMOD to explicitly set the top-level module; this is useful in case there is more than one top-level module in the code base. VerilogCreator does not use this information but hands it over to Icarus, Verilator and Yosys.
SVEXT =
This variable is used to tell the parser which files should be considered SystemVerilog files; default is ".sv"; the parser will enable the SV extension for these files in any case, regardless of the UseSvExtension option.
CONFIG += UseSvExtension
Use this option to enable the SystemVerilog extension for the whole project. Without this option, all files are assumed to be in Verilog 05 format besides the files whose suffix corresponds to one in SVEXT. With the option enabled all files are assumed to be in the supported SystemVerilog 2012 subset.
OTHER_FILES +=
The variable OTHER_FILES
lets you add other than source or library files (e.g. SDF files) to your project. The syntax and semantics are the same as with SRCFILES
.
If enabled (see the SVEXT and UseSvExtension project file options) the VerilogCreator plugin supports the following subset of SystemVerilog as specified in IEEE 1800-2012:
Pre-compiled versions of the VerilogCreator plugin can be downloaded for Windows, Linux and Macintosh as part of the QtcVerilog application.
See here to learn more: https://github.com/rochus-keller/QtcVerilog/blob/master/README.md
Follow these steps if you want to build VerilogCreator yourself:
QTDIR/bin/qmake VerilogCreator.pro
(see the Qt documentation concerning QTDIR).Instead of using qmake and make you can open VerilogCreator.pro using QtCreator and build it there.
Note that on Windows you also have to compile QtCreator/QtcVerilog itself because you also need the lib files for the plugin dll's (i.e. Core.lib, TextEditor.lib and ProjectExplorer.lib). Compiling QtCreator is not an easy task; compiling QtcVerilog is much easier.
Even though I'm using Qt for twenty years and QtCreator for ten years this is my first noteworthy QtCreator plugin. Of course I read all available documentation and watched all available lectures. But still the available information is very sparse, of lesser quality than the Qt documentation and often outdated. So I had to invest half the development time in reverse engineering of the QtCreator 3.4 source code. I don't use QtCreator 4.x yet because I'm working on Ubuntu LTS versions which only have QtCreator 3.x packages and also because I'm fully satisfied with 3.x and the more recent versions run slower and consume more resources.
I'm aware of the Binary and Source Compatibility rules of QtCreator plugins and managed to make the source code compatible with QtCreator 3.4.x to the latest 3.6.1 using ifdefs. But in QtCreator 4.x they not only have changed some function signatures, but also the architecture to a considerable extent. According to my current state of investigation, managing compatibility with a few ifdefs is no longer feasible; instead it seems necessary to maintain different codebases in parallel to be compatible with both QtCreator 3.x and 4.x and cope with the different architectures at the same time. Thus the question arises whether using QtCreator as the basis for the Verilog IDE is an advantage or rather a disadvantage. If you know a better work-around, please send me an email.
All in all it is now clear to me why there are comparatively few plugins for QtCreator in all these years and most of them come directly from the Qt Company. Source and binary compatibility between QtCreator versions is not only complex, but a full-blown nightmare. All the more annoying that many changes to the API seem to be purely cosmetic in nature. Unfortunately, you only realize the size and consequences of this problem when you have developed a sufficiently large plugin yourself and built it for several versions of QtCreator, unless you know the source code of QtCreator very well in several versions, which might only be the case for a few people.
Since I currently consider the effort to reverse engineer each QtCreator version anew and to develop different variants of the code in parallel to be too high, I do it the other way round: instead of adapting the plugin to each major and minor QtCreator version, I offer a simple binary deployment for Linux, Windows and Mac of a lean QtCreator version including VerilogCreator and some other minimal required plugins. See here to learn more: https://github.com/rochus-keller/QtcVerilog.
If you need support or would like to post issues or feature requests please use the Github issue list at https://github.com/rochus-keller/VerilogCreator/issues or send an email to the author.