Set external-source variables. Most test-bench environments, except a few, use some external components. These could be components that are shared across projects, verification IP, or verification methodology libraries. By defining a variable that points to the external source, these external components could be referenced, which is one of the easiest ways of doing this.
Do note that if an environment variable points to the external component, this particular variable can be used directly. There would be no need to define a variable, as described in this section. The UBus project depends on the UVM library. You must define a variable named UVM_HOME to point to the installation location of the UVM library. We will refer to this variable when specifying the files for SVEditor to parse.
Select Window->Preferences from the main Eclipse menu. Navigate to the General->Workspace->Linked Resources category, as shown in Fig 2. Select the ‘New’ button, and specify the name of the variable and path to the file or folder. In this case, we specify ‘UVM_HOME’ as the variable and the location where the UVM library is installed.
Creating argument files. Source files include paths, and the other directives are specified to SVEditor via an argument file. Argument files should have a ‘.f’ file extension. For the UBus project, it is necessary to create a single argument file to specify file and include paths. First, select the UBus project in the ‘project explorer,’ and then select New->File from the context menu. Specify the name of the new file as ‘ubus.f,’ then select ‘Finish.’
It is important to determine the file paths that should be specified in the argument file. Currently, the UBus project uses a ‘Makefile’ to compile the sources. Expand the examples sub-directory of the UBus project, then open the ‘Makefile.questa’ file.
Locate the comp target within the ‘Makefile.’ From the compilation command we can determine the files that must be specified to SVEditor (refer Fig. 4).
From this command, we can see the following tasks need to be done:
1. Specify an include path to ‘sv’ directory
2. Specify ‘examples/ubus_tb_top.sv’ as a source file
Unfortunately, we’re not quite done yet. The UVM examples specify core include paths and root files as part of the definition of the VLOG variable. The VLOG variable is defined in the common ‘Makefile.questa’ file.
From the definition of the VLOG variable, you can see that we also need to specify the following:
1. Specify an include path to ‘${UVM_HOME}/src’
2. Specify ‘${UVM_HOME}/src/uvm_pkg.sv’ as a source file
3. Enter the following information in the argument:
[stextbox id=”grey”]+incdir+${UVM_HOME}/src
${UVM_HOME}/src/uvm_pkg.sv
+incdir+examples
+incdir+sv
examples/ubus_tb_top.sv[/stextbox]
Note that content-assist for paths in the argument file can be triggered with ‘CTRL+SPACE.’ The screenshot shows content assist being invoked on the ${UVM_HOME} directory (refer Fig. 4).
Specify project properties
After setting up the argument file, we now must configure the UBus project to point to the argument file. Select the UBus project as shown, then select ‘Properties’ from the context menu. Select the ‘SystemVerilog Project Properties’ category. Now, select the ‘Add’ button to add a new argument file. Select the ‘Add Project Path’ button in the resulting dialogue box, then select ‘ubus.f’ in the file browser.
Rebuild the project and check the results
Finally, we need to rebuild the project index and confirm that the project paths are properly specified. The index can be rebuilt by selecting the UBus project, then selecting ‘Rebuild SV Index’ from the context menu. After the project index is rebuilt, source files managed by the index will be shown with a small blue dot in the project explorer. Note that the source files, and files included by the root files, are annotated with a blue dot. Note that files that are not included in the index, such as the Makefiles, are not annotated with a blue dot.
Recent changes in SVEditor
1. For nearly every SystemVerilog language feature, moving from scanner-based source analysis to a recursive-descent parser has been achieved. A few language features, inclusive of assertions, are still analysed via a scanner. But these are now in the minority, and will eventually be handled via the full parser.
2. The persistence strategy has been modified to depend on a translation-unit-based cache backed by filesystem storage. This increases the granularity of the cache, and doesn’t allow unnecessary portions to reside in memory.
3. The opening of the textual and structural components of a file have been decoupled. In the new release, the textual element of the file is immediately displayed in the editor. Meanwhile, a background thread works on any required parsing tasks to obtain the structural element of the file.
According to the developer, this strategy would allow important new functionality to be introduced and evaluated, while still admitting daily users of SVEditor to continue to utilise the stable release.
What’s new in SVEditor 1.2.8
1. An issue that resulted in certain operators not being correctly coloured in the editor was corrected. Operator lists were stored in different places in the code, but now all the operators are listed in the SVOperators class.
2. An off-by-one line numbering issue with the Argument File editor was corrected. This issue caused errors to be annotated one line off from where they should have been positioned.
3. There is now an enhanced argument-file editor to react to resource-variable changes.
4. A build issue with the 1.2.7 version, which caused the template-instantiation wizard not to load, has been corrected.
5. Support has been enhanced for editing files (that were not a part of an index), but within a project where configuration of indexed files occurs. This happens frequently, for example, when a new file is added to a project. With these enhancements, macro-definitions are pulled from the project’s index.
6. A bug that involved ‘selected-word highlighting’ for words containing regular-expression character was corrected.
7. A bug that involved ‘first_match’ in an assertion was corrected.
8. A bug that involved ‘within’ being used within an assertion was corrected.
The future of SVEditor
There are many helpful features that developers would want to add to SVEditor. These include:
1. Locating references in the project sources to classes, methods, fields, etc.
2. Re-factoring support–renaming classes, methods, etc.
3. A more detailed analysis of the source structure.
4. Support for large design descriptions and the test bench.
5. Further distinguish the task of editing from parsing the source structure.
Download latest version of the software: click here
