Aldecs ALINT-PRO design verification solution performs static RTL and design constraints code analysis to uncover critical design issues early in the design cycle. The product helps FPGA developers rise to the challenge of designing large FPGA designs and multiprocessor system on chip devices that include high-capacity and high-performance FPGA hardware.
The solution supports running rule checks for designs that target FPGAs from Xilinx, Intel or Microchip with minimal setup. It also offers the latest versions of FPGA vendor libraries, which are pre-built, installed by default, and pre-configured for advanced timing and CDC rule checks.
To help FPGA designers, ALINT-PRO provides automated project conversion from the most popular FPGA design environments - Xilinx Vivado and Intel FPGA Quartus. ALINT-PRO automates the import of a projects code into the native ALINT-PRO environment, whereas the automated project conversion functionality helps the designer prepare and run static verification of FPGA projects in ALINT-PRO. As part of the conversion, workspaces and projects are created and populated with code and settings, allowing designers to immediately run static code verification.
There are two ways to run project conversion, either by using the GUI or by running a conversion command from the console.
Click on Tools | Convert | QPF Project.
Specify the full path to the Quartus Design Project Suite with its .qpf file.
Specify path to the automatically generated ALINT-PRO project directory.
Note: By default, the output ALINT-PRO project will be created in the same directory where the QPF project file resides.
Figure 1: Convert QPF Project Wizard
Workspace Structure will be presented. In instances where the QPF project contains links to non-existing project files, these files will be marked in red, and it is recommended to halt the conversion and fix the Quartus project in its native development environment.
Figure 2: Workspace Structure
Conversion Command from console
To convert the project using command line, run convert.qpf.project command from the console window. The command has the following syntax:
Compared to the GUI-based route, the conversion command provides more options, including such options as -force and -ip_mode.
After project conversion into ALINT-PROs environment, you may change the projects rules selections, add waivers, etc. You may also continue to develop RTL code within Quartus projects. Then, the changed Quartus project can be converted again for static verification in ALINT-PRO.
Note: By default, ALINT-PRO will keep project-specific properties such as policy and waivers for the repeated conversions. Using the -force option will reset all project properties to the default one, removing all waivers and using Global policy setting for each generated project.
First, the script parses Quartus project .qpf file to extract all project-related files as well as project IP designs.
"OOC" (Out Of Context) IP mode:
For each IP design, the script creates a separate ALINT-PRO project filled with IP RTL files.
All IP designs with protected code are grouped in IP_PROJECTS. Whereas all IP designs with open source code are grouped in an IP_OOC_PROJECTS folder.
The project design files placed in main project named xil_defaultlib.
Elaboration, synthesis and constraint phases happen next for each generated project (including all projects from the IP_OOC_PROJECTS).
Next, for each OOC project, the script generates block-level constraints and adds them to the main project (xil_defaultlib).
The block-level constraints generation is performed using project.generate.constraints.toplevel command. At the same time, the script generates stub files for each IP project, adding them to the main project. Then, during the full design synthesis and linting, the IP wrapper units will be considered as gray-boxes and their content will not be processed during the linting.
At the same time, generated block-level timing constraints provide timing characterization of IP blocks for the full design linting and CDC analysis.
The ooc mode is the default for the project conversion. In addition to running linting on the main (xil_defaultlib) project, users may run linting and CDC analysis for any IP with non-protected code. Every time a user runs the main project linting, the IP projects will be processed as well.
This is done automatically by the main projects parse pre-macro script:
Figure 3: Parsing
If IP designs are stable, there is no need to keep processing each of the IP projects along with the main project. In this case, users may remove the pre-macro code. Alternatively, users may disable the processing of selected IP projects by removing them from the script.
Lastly, the script adds Quartus Design Constraints files to the main (xil_defaultlib) project as well. The constraint file may require some tuning for proper CDC analysis, as ALINT-PRO may not support Quartus-specific design constraint commands. Also, Aldec-specific reset design constraints must be added to the constraint file to enable proper verification of the designs reset structures.
Note: Protected design IP cannot be automatically constrained, as their source code is unavailable. It is therefore necessary to add manually developed block-level constraint files for each of the protected design IP blocks.
In cases where protected code exists in a project, the conversion script enables an option to Generate black boxes for missing units, allowing the compiler to accept the undefined design units.
The following figure illustrates a converted projects structure, with the open-source IP projects grouped under IP_OOC_PROJECTS and source-protected IP project residing under IP_PROJECTS:
Figure 4: Project Structure
"global" IP mode:
In this mode, all the out-of-context IP designs with non-protected code is added into the main project. No separate projects will be created for these IP designs.
Both IP mode approaches can be used for linting and CDC verification.
For large projects, the OOC approach is preferable as it reduces the size and complexity of the main project by abstracting instantiated IP designs. These IP designs could be verified with linting tools in their separate projects, and then excluded from main project analysis if their code remain intact.