Linting with ALINT-PRO within Active-HDL

Table of Contents

Introduction

Active-HDL suggests an early-bug-detection flow via the integration with ALINT-PRO. The Active-HDL user has an access to both different linting methodologies supported by ALINT-PRO: full chip-level linting and unit linting. Both methods complement each other and are usually applied at different stages of the design cycle. Unit linting is a relatively new approach that is well combinable with a flat elaboration mode - a special kind of elaboration, which considers HDL design units independent of each other in isolation, and is using the default values of generic parameters. This processing style is highly forgiving of missing elements within designs, such as not yet implemented parts of the hierarchy. This makes unit linting most valuable both when applied to individual source files, independent of other files, and right after files have been modified by a designer. Many highly valuable rule checks are therefore enabled very early, even almost immediately following writing the code itself, thus squeezing the feedback loop for the designer from days or weeks to just a few seconds. The results are presented within the Active-HDL interface, so the designers do not need to stop the workflow and run another tool for the analysis. Unit linting does not eliminate a need to use full traditional linting, as the combination of independent units may create extra issues after integration. So it is also foreseen the direct run of ALINT-PRO for the full linting of the entire workspaces. Involving ALINT-PRO's linting techniques allows detecting various types of bugs, defects and potential problems in the code at an early stage of the design cycle.

Integration Prerequisites

To use the integrated products by Aldec, they both should be installed and licensed. Be sure, that Active-HDL 10.5 (or greater) and ALINT-PRO 2017.12 (or greater) are available. The integration is achieved by a single step: specify the path to ALINT-PRO installation directory in Active-HDL Preferences (open the Linting | ALINT-PRO page and type in the location).

Figure 1. Active-HDL Preferences for ALINT-PRO Integration

Unit Linting

Depending on the current design stage one of the following linting methods should be chosen: full linting or unit linting where a 'unit' is a block of HDL code. Unit linting reveals bugs at the early stages of writing the code and is useful when implementing quick fixes. Also, the unit linting has significant advantages if applied to the incomplete designs. When analyzing individual source files, the missed references are ignored, the design units are elaborated independently with default generics. In such case, ALINT-PRO checks only rules staying within the boundaries of a design unit (about 50% of all the rules).

Unit linting can be utilized by selecting a file(s) in the Design Browser window and then applying the Run Unit Linting pop-up menu item or clicking the corresponding button on the main toolbar.

Figure 2. Unit Linting Start

The same result can be achieved by clicking the Run Unit Linting command on the Design main menu. In any case, the currently selected files are linted by ALINT-PRO, and the violations are reported directly to the Console window in Active-HDL.

For each discovered violation it is available: its severity, violated rule name and level, file name with the exact location, and the violation message. From Console, you can cross probe into the HDL Editor to see the place where the violation occurs. The corresponding source line is wavy underlined. Simply hover it over, and a notification appears and shows all the violations associated with the code line. You can assess what to do about the warning produced and modify the code correspondingly. After the code fixing, rerun the unit linting for the modified file(s).

Figure 3. Unit Linting. Cross-probing to HDL Editor

The unit linting output can be adjusted by customizing the design settings at the Linting | ALINT-PRO | Unit Linting page. Here, the max number of messages and/or the max rule messages to be printed can be limited. Also, the feedback will include all info messages generated during the linting if Verbose output is allowed.

The feature works by calling certain commands in the background, but there is a possibility to customize the flow and policy by passing arguments for the alog/acom commands. For example, custom policy can be set for each run of the unit linting by passing policy script via the -premacro argument. Also violations report can be generated each time if macro file with corresponding command is specified using the -postmacro argument. The scripts will be run before/after execution of the main command respectively.

#File policy.do
project.policy.add -rule STARC_VHDL.*

#File report.do 
project.report.violations -report starc_report.txt

Figure 4. Unit Linting Settings

It is possible to modify the linting policy and add some waivers directly within ALINT-PRO GUI using the pop-up menu of the Design Browser window by right-clicking on the workspace (on ALINT-PRO, click the Open Project Policy or the Open Project Waivers item.) This will result in ALINT-PRO invoking with Policy Editor or Waivers opened. You can customize the default linting policy and set waivers (if necessary). Optionally, the modified policy and waivers can be backup to files as scripts and then be used for the future designs. For more details on using Policy Editor, see the 'Customizing Linting Policy' Application Note. How to handle waivers is described in the 'Using Waivers to Skip Irrelevant Violations' Application Note.

Save all the modifications, close ALINT-PRO, and run unit linting once again. The cycle "Edit-Lint-Review" should be repeated until the possible cleanest output is achieved.

Full Linting

The full linting enhances the coverage of unit linting. All available rules are checked here. In addition to rules verified during the unit lining, the process typically includes: clock and reset trees verification, checks of Clock and Reset Domain Crossings (CDC and RDC respectively), and DFT. It allows analyzing all the source files of the design and elaborates the entire hierarchy as a whole. It means, that the full linting should be applied to a design where all the interfaces between blocks have been defined.

The full linting can be launched from within Active-HDL at a single click according to the project settings specified at the Linting | ALINT-PRO | Workspace Linting page. Here, you can either generate a TCL script or use the existing one. The generated script is located in the ./ALINT-PRO subdirectory of the Active-HDL design directory.

Going with the generation option, you can enable:

overwriting the existing workspace - conversion of the initial Active-HDL workspace will replace the existing ALINT-PRO workspace/project files (if any). If disabled, the structure and properties of the ALINT-PRO workspace will be updated according to the changes made in the Active-HDL workspace. ALINT-PRO specific properties, such as policy and waivers, are not reset during the update.
automatic setting of behavioral description style for the units that cannot be synthesized - just check the Ignore non-synthesizable modules option.
usage of waivers and policy scripts - define the name(s) and location(s).
running the step-by-step design analysis immediately after the ALINT-PRO start; later on, the flow can be switched to the "Efficient CDC debugging" flow. If this option is not checked, the Active-HDL workspace is only converted and loaded in the ALINT-PRO framework.

Figure 5. Workspace Linting Settings

Once you are done with the settings, the full linting of the workspace can be started. Select the workspace node in the Active-HDL Design Browser window, on the pop-up menu click ALINT-PRO, then click Run in Aldec ALINT-PRO. This launches ALINT-PRO where the automatically generated script will be run. You can continue the code analysis in the ALINT-PRO environment tooled for the static analysis. Here:

Project Manager shows the generated workspace and project with the source files.
Flow Manager demonstrates the working flow and provides access to the report generation.
Console is a basic input-output tool.

Figure 6. ALINT-PRO General View

Upon the completion of the analysis, the linting results are available in the Violation Viewer window. Also, you can generate a number of the reports. See the ALINT-PRO help menu, the 'Getting started with ALINT-PRO' and other Application Notes for more information about ALINT-PRO.

Customized Linting

As it was said above, the automatically generated script for full linting can be edited (use the ./ALINT-PRO/alint_pro_<ws_name>.tcl file):

# Basic workspace conversion
convert.activehdl.workspace "C:/Aldec/My_designs/Bjack/bjack.aws"

# Needed for non-synthesizable modules to avoid synthesis errors
project.pref.autosetbehavioralstyle yes

# Run design entry and linting phases for the active project
project.run

To run the customized TCL script with the ALINT-PRO, the Use custom TCL script option should be enabled at the Linting | ALINT-PRO | Workspace Linting page of the design settings. The script location should be defined here as well.

Note: neither design entry settings that can be defined in Active-HDL (language standards, libraries, etc.) nor the project structure should be changed manually for the ALINT-PRO project because they will be overwritten during the next run of linting from Active-HDL.

Initially, any custom script for full linting from Active-HDL should obligatory include the basic workspace conversion command indicating the workspace file name and location as the argument:

convert.activehdl.workspace "C:/Aldec/ALINT/examples/Samples_106_x64/Bjack/bjack.aws"

It results in converting the Active-HDL workspace to the ALINT-PRO's one. If further the initial design structure or its settings are changed within the Active-HDL environment and this command is removed from the script, the changes will not be considered by ALINT-PRO during the full linting (the results of the first full linting run will be used). Otherwise, the convert.activehdl.workspace command may be omitted.

To prevent the synthesis phase from failing (even if the project contains non-synthesizable descriptions), include a special command in the script. It enables/disables the automatic setting of behavioral description style for all the units that cannot be synthesized:

project.pref.autosetbehavioralstyle [-project <project_name>] {[yes | no]}

A custom script should contain all the commands required for the design analysis which is generally executed with project.run. Some useful commands are given below.

project.policy.add -ruleset STARC_VHDL

This command adds the existing rules and rulesets to the project policy.

project.waiver.list

It lists all the waivers set for the project.

project.parse

Use this command to run parsing only.

project.report.violations

This command should be used to print the violations from the project violations database to Console or to a file. It is a part of a vast family of the project.report.* commands.

For the complete list of the commands, address to ALINT-PRO documentation (see Command Reference).

Conclusion

The offered methods of design analysis are quite beneficial for the designers because enables them checking the code and evaluating its quality quickly. Common workflow on mixed-HDL language simulation for ASIC and FPGA designs within the Active-HDL environment can be combined with the ALINT-PRO static code analysis. Two linting methods - full and unit - allow finding defects early in the development process when they are cheap to fix. Unit linting can be used when a design is very incomplete and not all the interfaces between blocks are defined. Run in the background, it makes easier for the individual developers to figure out what is wrong with the code without leaving their environment. Full linting is aimed to help the development teams to verify the almost complete designs when noisy output is eliminated at the unit linting stage.

One-step integration configuration of both Aldec's products is combined with flexible scripting mechanism that helps to reduce the fault fix time.