Automated Conversion of Xilinx Vivado Projects to ALINT-PRO

Introduction

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.

Getting Started

You will need to install Xilinx Vivado and the latest version of ALINT-PRO. You will need to request a license to run Vivado and request a license for Aldec.

Xilinx Vivado Projects Conversion

There are two ways to run project conversion, either by using the GUI or by running a conversion command from the console.

1. ALINT-PRO GUI

   • Click on Tools | Convert | XPR Project.

   • Specify the full path to the Vivado Design Project Suite with its .xpr 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 XPR project file resides.

     

     Figure 1: Convert XPR Project Wizard

   • Click Next.

   • Workspace Structure will be presented. In instances where the XPR 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 Vivado project in its native development environment.

     

     Figure 2: Workspace Structure

   • Click Finish.

2. Conversion Command from console

   • To convert the project using command line, run convert.xpr.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.

-force option

• 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 Vivado projects. Then, the changed Vivado 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.

-ip_mode option

• First, the script parses Vivado project .xpr file to extract all project-related files as well as project IP designs.

"OOC" (Out Of Context) IP mode:

1. Parsing

   • 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

2. Elaboration, synthesis and constraint phases happen next for each generated project (including all projects from the IP_OOC_PROJECTS).

3. 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.

4. 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

5. 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.

6. Lastly, the script adds Xilinx 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 Xilinx-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.

7. 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.