« Prev | Next » Xilinx VivadoプロジェクトをALINT-PROへ自動変換 はじめに アルデックのALINT-PROデザイン検証ソリューションは、スタティックRTLおよびデザイン制約コードの解析を行い、デザインサイクルの初期段階でデザイン上の重要な問題を発見します。この製品は、FPGA開発者が大規模なFPGAデザインや、大容量・高性能のFPGAハードウェアを含むマルチプロセッサ・システムオンチップデバイスを設計する際の課題を解決します。 本製品は、Xilinx®, Intel® or Microchip®のFPGAをターゲットとしたデザインのルールチェックを最小限の設定で実行することをサポートします。また、FPGAベンダライブラリの最新バージョンも提供しています。これらのライブラリはあらかじめビルドし、デフォルトでインストールされ、高度なタイミングチェックやCDCルールチェックのために設定されています。 FPGA設計者を支援するためにALINT-PROは、最も一般的なFPGAデザイン環境であるXilinx Vivado®およびIntel FPGA Quartus®からの自動プロジェクト変換を提供します。 ALINT-PROは、プロジェクトのコードをALINT-PROのネイティブ環境へのインポートを自動化します。プロジェクトの自動変換機能は、設計者がALINT-PROでFPGAプロジェクトのスタティック検証の準備と実行を行うことに役立ちます。変換の一環として、ワークスペースとプロジェクトを作成し、コードと設定が入力されるため、設計者はスタティックコード検証をすぐに実行できます。 事前準備 Xilinx VivadoとALINT-PROの最新版をインストールする必要があります。Vivadoを動作させるためのライセンスと、アルデックのライセンスを要求する必要があります。 Xilinx Vivadoプロジェクトの変換 プロジェクトの変換を実行するには、GUIを使用する方法と、コンソールから変換コマンドを実行する方法があります。 ALINT-PRO GUI Toolsメニュー | Convert | XPR Projectをクリックします。 Vivado Design Project Suiteのの.xprファイルへのフルパスを指定します。 自動生成するALINT-PROプロジェクトディレクトリのパスを指定します。 注意: デフォルトではALINT-PROプロジェクトは、XPRプロジェクトファイルが存在するのと同じディレクトリに作成されます。 図 1: Convert XPR Project Wizard Nextをクリックします。 ワークスペース構造が表示されます。 XPRプロジェクトに存在しないプロジェクトファイルへのリンクが含まれている場合、これらのファイルは赤でマークされます。変換を中止してVivadoプロジェクトのネイティブ開発環境で修正することを推奨します。 図 2: Workspace Structure Finishをクリックします。 コンソールからの変換コマンド コマンドラインを使用してプロジェクトを変換するには、コンソールウィンドウからconvert.xpr.projectコマンドを実行します。このコマンドの構文は次のとおりです： GUIベースのルートに比べて、変換コマンドには-forceや-ip_modeなどのオプションがあります。 -force オプション プロジェクトをALINT-PRO™環境に変換した後、プロジェクトのルール選択を変更したり、除外を追加したりできます。Vivadoプロジェクト内でRTLコードを開発し続けることもできます。 その場合、変更したVivadoプロジェクトをALINT-PROでスタティック検証用に再変換することができます。 注意: デフォルトでは、ALINT-PROはポリシーや除外などのプロジェクト固有のプロパティを繰り返し変換のために保持します。-forceオプションを使用すると、すべてのプロジェクトのプロパティがデフォルトにリセットされ、すべての除外が削除され、生成された各プロジェクトのグローバルポリシー設定が適用されます。 -ip_mode オプション 最初にスクリプトはVivadoプロジェクトの.xprファイルを解析して、プロジェクトに関連するすべてのファイルとプロジェクトのIPデザインを抽出します。 "OOC" (Out Of Context) IP モード: Parsing IPデザインごとにIPのRTLファイルを含むALINT-PROプロジェクトが作成されます。 暗号化されたコードを持つすべてのIPデザインは、IP_PROJECTSにまとめられます。一方、オープンソースコードを含むすべてのIPデザインは、IP_OOC_PROJECTSフォルダにまとめられています。 プロジェクトのデザインファイルは、xil_defaultlibという名前のメインプロジェクトに置かれます。 次に、生成された各プロジェクト（IP_OOC_PROJECTSの全プロジェクトを含む）について、elaboration、synthesis、constraintの各フェーズが実行されます。 次に各OOCプロジェクトに対して、スクリプトはブロックレベル制約を生成し、メインプロジェクト（xil_defaultlib）に追加します。 ブロックレベルの制約条件の生成は、project.generate.constraints.toplevelコマンドを使用して行われます。同時にスクリプトは各IPプロジェクトのスタブファイルを生成し、メインプロジェクトに追加します。これによりフルデザイン合成やリンティングの際、IPラッパユニットはグレーボックスとみなされて、その内容はリンティング時に処理されません。 同時に生成されたブロックレベルのタイミング制約は、フルデザインのリンティングとCDC解析のためにIPブロックのタイミング特性を提供します。 oocモードはプロジェクト変換のデフォルトです。 メインプロジェクト（xil_defaultlib）でリンティングを実行することに加えて、ユーザーは暗号化されていないコードを持つ任意のIPに対してリンティングとCDC解析を実行できます。 メインプロジェクトのリンティングを実行するたびにIPプロジェクトも処理されます。 これはメインプロジェクトのパース用プリマクロスクリプトによって自動的に行われます： 図 3: Parse IPデザインが安定している場合、メインプロジェクトと一緒にIPプロジェクトのそれぞれを処理し続ける必要はありません。このような場合、ユーザーはプリマクロコードを削除することができます。また、選択したIPプロジェクトをスクリプトから削除することで、その処理を無効にすることもできます。 最後に、このスクリプトはメインプロジェクト (xil_defaultlib) にもXilinxデザイン制約ファイルを追加します。ALINT-PROはXilinx固有のデザイン制約コマンドをサポートしていない場合があるため、CDC解析を適切に行うためには制約ファイルのチューニングが必要になります。また、アルデック固有のリセットデザイン制約を制約ファイルに追加して、デザインのリセット構造を正しく検証できるようにする必要があります。 注意: 暗号化されたデザインIPはソースコードが利用できないため、自動的に制約を生成することはできません。したがって、暗号化されたデザインIPブロックごとに、手作業で記述したブロックレベルの制約ファイルを追加する必要があります。 暗号化されたコードがプロジェクトに存在する場合、変換スクリプトは、欠落しているユニットのブラックボックスを生成するオプションを有効にし、コンパイラが未定義のデザインユニットを受け入れることを可能にします。 次の図は変換されたプロジェクト構造を示しています。オープンソースのIPプロジェクトはIP_OOC_PROJECTS内でグループ化され、暗号化ソースのIPプロジェクトはIP_PROJECTS内にあります： 図 4: プロジェクト構造 "global" IP モード: このモードでは、暗号化されていないコードを持つすべてのアウトオブコンテクストIPデザインがメインプロジェクトに追加されます。これらのIPデザインのために別プロジェクトが作成されることはありません。 どちらのIPモードのアプローチでもリンティングやCDC検証に使用することができます。 大規模なプロジェクトでは、インスタンス化されたIPデザインを抽象化することで、メインプロジェクトのサイズと複雑さを軽減できるOOCアプローチが好ましいです。これらのIPデザインは、個別のプロジェクトでリンティングツールを使って検証し、コードが損なわれていない場合はメインプロジェクトの解析から除外できます。 Previous article Next article
