Skip to content

Examples

Jump to bottom
svstuff edited this page Sep 12, 2015 · 16 revisions

Examples for using the parser

Creating the input XML file

The input to the parser is an XML file that specifies include paths, defines and source files.

The simplest way to create this is to use simshim.py in the tools subdirectory:

nano Makefile
# replace vcs for simshim.py in the rule which invokes the simulator
make

You should now have an XML file (probably called stylecheck.xml) in your current directory (or whatever was the cwd when vcs would normally have been executed by make).

This XML file will look something like this:

<project>
  <define><name>MYDEF1</name><value>42</value></define>
  <define><name>MYDEF2</name><value>123</value></define>
  <incdir>/path/to/my/sv/includes</incdir>
  <incdir>/path/to/my/other/sv/includes</incdir>
  <source>/path/to/my/sources/dut.v</incdir>
  <source>/path/to/my/sources/tb.sv</incdir>
</project>

Running the parser

You can now run the parser thusly (see also Build):

cd path/to/parser/clone
./gradlew installApp
./build/install/svparse/bin/svparse path/to/stylecheck.xml

Enable features

The project file created by simshim.py will just mirror the command line parameters you provided to the simulator. Using this will just run the parser as a recognizer, i.e. it will just say yay or nay and not really output anything useful (except messages about syntax errors).

The following sections describe some work-in-progress features that must be explicitly enabled. They are enabled by adding an element to the project xml file, or by creating an additional project file and pointing the environment variable SVPARSE_EXTRA to this file. Settings in the latter will override the main project file. This is useful since you can recreate the main project file (e.g. in a makefile target) without losing your manual changes.

As an example, you can run with some extra features enabled by copying the below into svparse_extra.xml and running as indicated below.

<project>
  <logLevel>DEBUG</logLevel>
  <feature>serialize_to_xml</feature>
</project>

export SVPARSE_EXTRA=svparse_extra.xml
./build/install/svparse/bin/svparse path/to/project.xml

Getting the parsetree

If you want the complete parsetree as XML you can add this feature:

<feature>serialize_to_xml</feature>

You will now have a file svparsetree.gz in your cwd. This is a gzip compressed XML file containing the parsetree. If you want a properly indented decompressed version you can do this:

gzip -c -d ./svparsetree.gz | xmllint --format - > svparsetree.xml

Complexity info

Similar to the above, you get some complexity info by adding <feature>complexity</feature> to the project XML file. It is currently pretty rudimentary and includes per-task/function stats for:

  • raw number of lines (physical LOC)
  • total statement count
  • max logical nesting level

The output is in a yaml file in your cwd. It is trivial to sort this by max nesting level, say, and thus get a list of the N most complex functions/tasks.

Cyclomatic complexity is a planned addition.

Begin/end block style

Add <feature>block_style</feature> to the project XML file.

This will enable a visitor which prints an error to the log for each conditional/loop statement that does not use a begin/end block. E.g. the following will be flagged with filename and line number (both the foreach and the if):

  foreach (env[i])
    if (env[i] == name)
      return ;

Limitations:

  • statements expanded from a macro are skipped (for now) to avoid spurious output.
  • obviously anything filtered by the preprocessor is not considered (e.g. ifdef's).
Clone this wiki locally