Intel FPGA Quartus プロジェクトをALINT-PROへ自動変換



本製品は、Xilinx®, Intel® or Microchip®のFPGAをターゲットとしたデザインのルールチェックを最小限の設定で実行することをサポートします。また、FPGAベンダライブラリの最新バージョンも提供しています。これらのライブラリはあらかじめビルドし、デフォルトでインストールされ、高度なタイミングチェックやCDCルールチェックのために設定されています。

FPGA設計者を支援するためにALINT-PROは、最も一般的なFPGAデザイン環境であるXilinx Vivado®およびIntel FPGA Quartus®からの自動プロジェクト変換を提供します。 ALINT-PROは、プロジェクトのコードをALINT-PROのネイティブ環境へのインポートを自動化します。プロジェクトの自動変換機能は、設計者がALINT-PROでFPGAプロジェクトのスタティック検証の準備と実行を行うことに役立ちます。変換の一環として、ワークスペースとプロジェクトを作成し、コードと設定が入力されるため、設計者はスタティックコード検証をすぐに実行できます。


Quartus II をインストールする必要がありますが、Quartus Primeと最新版のALINT-PROをインストールしても構いません。アルデックのライセンスを申請していただく必要があります。

Intel FPGA Quartusプロジェクトの変換

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


    • Toolsメニュー | Convert | QPF Projectをクリックします。

    • Quartus Design Project Suiteの.qpfファイルへのフルパスを指定します。

    • 自動生成するALINT-PROプロジェクトディレクトリのパスを指定します。

      注意: デフォルトではALINT-PROプロジェクトは、QPFプロジェクトファイルが存在するのと同じディレクトリに作成されます。

      図 1: Convert QPF Project Wizard

    • Nextをクリックします。

    • ワークスペース構造が表示されます。 QPFプロジェクトに存在しないプロジェクトファイルへのリンクが含まれている場合、これらのファイルは赤でマークされます。変換を中止してQuartusプロジェクトのネイティブ開発環境で修正することを推奨します。

      図 2: Workspace Structure

    • Finishをクリックします。

  2. コンソールからの変換コマンド

    • コマンドラインを使用してプロジェクトを変換するには、コンソールウィンドウからconvert.xpr.projectコマンドを実行します。このコマンドの構文は次のとおりです:

    • GUIベースのルートに比べて、変換コマンドには-forceや-ip_modeなどのオプションがあります。

-force オプション

  • プロジェクトをALINT-PRO™環境に変換した後、プロジェクトのルール選択を変更したり、除外を追加したりできます。Quartusプロジェクト内でRTLコードを開発し続けることもできます。 その場合、変更したQuartusプロジェクトをALINT-PROでスタティック検証用に再変換することができます。

    注意: デフォルトでは、ALINT-PROはポリシーや除外などのプロジェクト固有のプロパティを繰り返し変換のために保持します。-forceオプションを使用すると、すべてのプロジェクトのプロパティがデフォルトにリセットされ、すべての除外が削除され、生成された各プロジェクトのグローバルポリシー設定が適用されます。.

-ip_mode option

  • 最初にスクリプトはQuartusプロジェクトの.qpfファイルを解析して、プロジェクトに関連するすべてのファイルとプロジェクトのIPデザインを抽出します。

"OOC" (Out Of Context) IP モード:

  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 desings 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 generats lock-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 project’s 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 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 design’s 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 project’s 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.

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.
We use cookies to ensure we give you the best user experience and to provide you with content we believe will be of relevance to you. If you continue to use our site, you consent to our use of cookies. A detailed overview on the use of cookies and other website information is located in our Privacy Policy.