ALINT Custom Rules Overview


This application note highlights basics of the Application Programming Interface (API) in ALINT and briefly explains the types of rules that can be implemented based on the Language/Semantic Layer of the engine.

The complete API Tutorial is available upon request – contact

Detailed API documentation is shipped with the tool and is available under Help section of main menu.

Rule Types Overview and Their Accessibility via the API

As you can see in the Figure 1, there are several layers (and corresponding rule types) in ALINT engine:

  1. Language/Semantic Level – basic coding standards.

  2. Register Transfer Level (RTL) – pre-synthesis issues.

  3. Synthesis Level – the rules that require results from internal synthesizer.

  4. Chip Level – the most complicated rules that can be checked during the elaboration phase only. The design rule checking process is distributed between two phases – compilation- and elaboration-time. Basic rules are checked at compilation-time phase; advanced rules that depend on parameter values and design hierarchy are checked during elaboration-time phase.

Figure 1: Four Basic Rule Types in ALINT

See Table 1 for examples of rules that can be implemented at this level.

Table 1: Language Level Rule Samples

Areas accessible at this level

Rule examples


Do not assign the same signal more than once in same execution path


Do not use disconnect


Do not mix signed and unsigned operands in the same expression.

Object Types

Use only reg and wire types for declaring signals


Do not use multiline comments

Basic Concepts of the API

Figure 2 is a simplified diagram that reflects the internal structure of the engine from the API perspective.

Figure 2: ALINT API - Simplified Diagram

As show in Figure 2, the interim data layers such as Semantic, Pre- and Post-Synthesis and Chip-Level are available at different stages of HDL code analysis:

  • Semantic – once compilation is over, Design Hierarchy – once elaboration is over.

  • Pre- and Post-Synthesis layers – before and after the launch of internal synthesis engine respectively.

  • Chip-Level – after the launch of the Pattern Matching engine.

And there is the key component called Navigator which actually collects the information from different data layers and provides it to the rule checker functions. A unique design rule checker function is the internal implementation of a design guideline – every rule checker verifies an appropriate guideline and triggers when the guideline is violated. The information is provided in form of various events – every rule checker must subscribe certain type(s) of events – the green path in the Figure 3 illustrates the idea.

Figure 3: Subscribing Events from Navigator

As you can see in the Figure 4, Decision Making Logic is the core part of every checker which processes the events from Navigator and registers rule violations in the Violation Manager whenever this is necessary.

  • Every event can be queried for numerous attributes – additional details that are necessary for the decision making process.

  • Once a violation is registered in the Violation Manager, this component handles all the further tasks related to this violation (save, sort, output, export etc).

Figure 4: Decision Making Logic and Violations Reporting

Custom rules can also have one or more configuration parameters that allow:

  • Setting numeric limits – e.g. maximum branch count in the case construct.

  • Managing templates – e.g. the list of required fields in the file header.

  • Selecting between interpretation modes – e.g. report brief or verbose violation.

Types of Rules that Can Be Implemented at Language/Semantic Level

There are several types of events that are available from Navigator at this level – the rule types directly depend on them. The following subsections briefly describe every type of event available at this level and gives examples of rules that can be implemented based on those event.

Item Events

Item events allow reacting on object declarations – event is associated with HDL handle of declaration object, which can be additionally queried for definition details.

Table 2: Examples of Checkers that Can Be Implemented Based on Item Events

Checker type


Naming conventions

  • Constant name should start from 'C_'.

  • Port names must be in lower case.

Data Types

  • Use only 'std_logic' types for I/O ports.

  • Use synthesizable types only.


  • Range should be in the form [MSB:LSB].

  • LSB of the signal should be 0.


Do not use initializing assignments for signals

Order of declarations

  • First declare inputs, and then declare output.

  • Do not place two or more declarations on same line.

Forbidden declarations

  • Do not use user-defined attributes.

  • Do not use shared variables.

Context Events

Context events are issued when the Navigator enters and leaves the scope of a certain construct –

  • Context entry events are usually used to reset the information which was previously gathered for similar context.

  • Context exit events are usually used to register violations – decision making logic finalizes all the necessary computations by this point.

Table 3: Examples of Checkers that Can Be Implemented Based on Context Events

Checker type


Something within a given context

  • Type of assignments (blocking or non-blocking) must depend on the type of a process (combinational or sequential).

  • Do not mix blocking and non-blocking assignments within the same process.

  • Do not use ‘wait’ statement in procedures.

Expression Events

Expression event is a specialized lower-level facility for handling of the expression trees.

  • Entry and exit from expression node (every expression is internally represented in a form of a graph) – these events are similar to context entry/leave events and indicate that the traversing process is entering/exiting the expression node.

Table 4: Examples of Checkers that Can Be Implemented Based on Expression Events

Checker type


Expression contents related

  • Do not use arithmetic operations within conditional expressions.

  • The order of operations must be defined clearly using () brackets.

  • Do not use hard-coded numbers for characteristics that may change.

Edge Events

Edge events are intended for checking expressions from the sensitivity lists.

Table 5: Examples of Checkers that Can Be Implemented Based on Edge Events

Checker type


Sensitivity list

  • Do not mix signals with and without edges within the same sensitivity list.

  • Polarity of a reset signal must match the signal edge in the corresponding sensitivity list.

  • Only simple single-bit signals must be used under edge (operations are not allowed).

L-Value Events

L-value events are intended for checking left part of expression in the assignment operator.

Checker type



  • The bit width of assignment source (RHS) must match the bit width of destination (LHS).

  • Do not perform multiple assignments to the same signal (multiple drivers).

  • Do not assign negative value to integer.

Lexical Events

Lexical events are used for low-level checks of the code formatting.

Checker type


Code formatting

  • Do not have lines in source code that are longer than 110 characters.

  • Do not use any language other than English in comments.

  • Each port declaration must be followed by a comment.

  • File header of certain format must be included.

Non-Synthesizable Events

Non-synthesizable events are used for handling processes that cannot be synthesized by ALINT engine –

  • Generally, when receiving an event of this type, rule checkers drop the information that has been collected so far and reset the internal data variables to the initial state.

Checker type



This type of event is used as a source of auxiliary information for other checkers – those that process synthesizable contexts only.

Using Custom Rules in ALINT Framework

Here are 3 basic steps to attach a custom rule:

  1. Compile custom rule plug-in source files into a shared library (.dll or .so library file). ALINT is shipped with the GCC compiler which is a great tool for building of custom plug-ins directly in the tool.

  2. Register the library in the ALINT framework to make its rules available for regular operations.

  3. Add custom rules to a policy, configure them, and use for linting.

Figure 5: A Custom Rule in the Violation Viewer

Figure 5 shows an example of how the FIRSTRULE custom rule appears together with predefined rules from basic plug-in in the Violation Viewer.


  • Custom rule checkers are based on the events subscription and processing.

  • Different types of events are available – subscription depends on your custom rule specification.

  • Decision making logic is the core part of a checker that requires the most of actual programming.

  • Once a custom rule is compiled to a library, it can be registered and used as any regular rule.

Applies To:

  • ALINT 2012 Windows

  • ALINT 2012 Linux

Ask Us a Question

Ask Us a Question

Captcha ImageReload Captcha
Incorrect data entered.
Thank you! Your question has been submitted. Please allow 1-3 business days for someone to respond to your question.
Internal error occurred. Your question was not submitted. Please contact us using Feedback form.