« Prev | Next » ALINTクイックスタート・ガイド はじめに ALINTはVHDL、Verilogおよび混在言語のデザイン・ルール・チェッキング（リンティング）ツールで、AISCおよびFPGAデザイン・フローの早期に重要なHDLコードの問題を発見します。Verilog、VHDLおよび混在言語でのコーディング・スタイル、機能および構造の問題を指摘して、デザイン・フロー下流のステージにそれらの問題が広がることを防止します。このクイックスタート・ガイドでは、手順を示しながらALINTデザイン・チェックのフローの全体的な概要を説明します。 デザイン・セットアップ: ソース・ファイル、ベンダー・ライブラリ、クロックおよびリセット、トップ・レベル リント・チェック: 目的の特定およびフローの作成、フローの実行 結果の解析: 参照およびフィルタ、レポートの生成、報告された問題の削減 これらの３つのトピックは、デザイン・リンティングを完了するのに必要な全てです。 ツールを開始する GUIまたはバッチ・モードのどちらかでツールを起動するために、ALINT本体のインストレーション・ディレクトリにある以下のプログラム・スクリプト[1]を使用することができます。 runalint – GUI runalintcon – バッチ（インタラクティブ） ライセンスが有効な場合は、runalintスクリプトを実行した後にALINTの環境（図1）が表示されます。 図1: ALINTの環境（デフォルトのパースペクティブ） ソース・ファイルの追加 ワークスペースをデザインを作成します。これにより個々のファイルをまとめてグループ化し、管理することができます[2]。プロジェクトにファイルを追加するためFile | New | Design...（図2）を選択してNew Design Creation Wizardを実行します。 新しいデザイン名を入力 場所を選択 Finishボタンをクリック 図2: New Design Creation Wizard 新しく作成したデザインを右クリックし、Add | Existing File… （図3）を選択してプロジェクトの全てのファイルを追加します。 図3: プロジェクトのファイルをALINTに追加 必要の無いファイルは、ファイルやファイルのグループを選択してDeleteキーで削除することができます。 注意: デフォルトでは現在のデザインからファイルが除外されますが、ディスクからは削除されません。 デザイン・ファイルが追加されると、プロジェクト固有の設定を行うことができます: コンパイル済みのFPGAベンダーライブラリの追加（必要な場合）、クロックおよびリセットの指定、トップレベル（複数可）の選択、デザイン解析から除外する必要のある任意のファイル、インスタンスまたはデザイン・ユニットの除外定義。 ベンダー・ライブラリの追加 プロジェクトで幾つかのベンダー・ライブラリ（例: Xilinxのunisimなど）のコンポーネントを使用している場合には、ツールがプロジェクトをコンパイルできるようにALINTのデザイン・ライブラリのリストにこれらのライブラリを追加する必要があります。現在追加されているライブラリのリストは、Library Manager で確認することができます。Library Manager の各ライブラリは、グローバルまたはローカルとして追加することができます。図4では、library.cfg の下にリストされるライブラリはグローバルで全てのデザインから参照されます。それに対して quick_start はローカルで現在アクティブなデザインが表示されます。 図4: Library Manager ベンダー・ライブラリを扱う方法の詳細な手順についてはこちらをクリックしてください。要するにwww.aldec.comから事前にコンパイルされたライブラリをダウンロードするか、自分自身でソース・ファイルからコンパイルすることができます。ライブラリが追加されると、Library Manager に表示され、内容はライブラリ・アイコンの三角形をクリックすることにより拡張することができます。 注意: FPGA/ASICベンダーのライブラリのコンポーネントは通常チェックする必要はありません。したがって、ユーザがソースファイルからベンダーライブラリをコンパイルする時にはリンティングを無効にする必要があります。Library Manager にライブラリが表示されると、ALINTのエンジンがその内容を認識して自動的に全てのライブラリ・プリミティブを等価なモデルに置き換えます。これは高度なチップレベルのチェックのためには不可欠です（Xilinx®とAltera®ベンダー・ライブラリのプリミティブに関するネイティブ・サポートの詳細はこちらをクリックしてください）。 クロックおよびリセット信号の指定 デザイン中に内部で生成されたクロックやリセットが無ければ、ツールは全てのクロックおよびリセット・ラインを自動的に検出します。もし内部で生成されたクロックやリセットが何も無ければ、このセクションをスキップして次のステップに進んでください。自動的に検出されたクロックおよびリセットは、エラボレーション時のリンティング中にコンソール・ウィンドウに表示されることに注意してください。これはデザインのリンティング・セッションの2番目かつ最終フェーズとなります。 # ALINT: Info: ...Detected clock signals: bjack.GEN_CLK, bjack.SYS_CLK. # ALINT: Info: ...Detected reset signals: bjack.GEN_RES, bjack.START. 存在しないクロックまたはリセットが指定されている場合は、ツールはそれが見つからないことを報告し、自動的にクロックやリセットを見つけようと試みます。デザイン中で幾つかの内部クロックを生成している場合に（例: PLLのクロック出力が複数）自動検出ができない場合があるので、マニュアルでクロック（複数可）を指定する必要があります。これらを行うには図5に示すようにデザインのPropertiesでクロック信号のリストを編集します。 図5: デザイン中のクロックのリスト リセット信号をマニュアルで指定する必要がある場合には、Design Manager でデザインを右クリックしてProperties | Linting | Entries | Global reset signals で信号のリスト（階層名を指定）を編集します。 注意: デザイン中の全てのクロックには、少なくとも1つ以上の異なったクロック・ドメインが推論されます – データパスのクロック・ドメイン・クロッシングによる機能誤動作の可能性があることをチェックするルールのための重要な情報のソースとなります。このようなルールは異なったクロックドメインをまたがる信号の解析に基づいており、CDCルールとして知られています。デザイン中の2つ以上のクロック・ラインが同期している場合は[3]、正確なCDCに関するチェックを可能にするため、同じドメインに属していることを示さなければなりません。クロックが同期していることを示すには、alint_gclkjoin スイッチを使用する必要があります。Preferences | Linting | Entries | Join clock signal でクロックのリストを編集します。 #CLK_A and CLK_B are joined (marked as synchronized – 1 clock domain inference) -alint_gclkjoin top.cgen.CLK_A top.cgen.CLK_B #CLK_A, CLK_B, and CLK_C are joined (multiple –alint_gclkjoin switches) -alint_gclkjoin top.cgen.CLK_A top.cgen.CLK_B -alint_gclkjoin top.cgen.CLK_B top.cgen.CLK_C ソースファイルを追加し、ライブラリを追加してクロック／リセットを指定すると、デザインをリンティング解析するための準備が完了します。 リンティング・チェック このセクションでは、ALINTがデザインを解析する方法を学びます。実際のデザイン解析プロセスに進む前に、2つの使用可能なアプローチ／手法があることに注意してください。 トラディショナル フェーズ・ベース・リンティング（PBL） このアプリケーションノートでは、トラディショナルなアプローチによる2つの一般的な問題を自動的に解決するためにPBL手法を使用します。 セッション毎にレポートされる違反の数が多い（デザインを多くのルールに対してチェックする際に自然に発生） 偽または無関係の違反に起因する「ノイズ」のハイレベル （トラディショナルなリンティング以上の利点とPBLの詳細についてはこちらをクリックしてください）ツールのインストールとデザインの初期設定が完了したら、効果的にデザイン解析をすぐに開始できるように事前定義されたフロー・テンプレートを使用します。 リンティング・フローの作成 File | New | Flow…を選択し、New Flow Creation Wizard を開始します。フロー名を入力し、フロー・タイプに事前定義されたSTARC_VHDL - Essentials [4]テンプレートを設定します。Attach new flow to the design オプションをチェックすると、図6のように表示されます。 図6: New Flow Creation Wizardの設定 新しいフローの設定が終了したら、Finishをクリックしてフローをデザインに添付します。フローが添付されると、そのフェーズがFlow Manager ウィンドウに表示され、Design Manager でデザイン名の次にフロー名が表示されます。 フローの実行 リンティング・フローは、順番に実行および完了しなければならないインタラクティブなプロセスまたはフェーズのセットです（一般的なフロー図は図7を参照ください）。各フェーズは設計上の問題に対する幾つかのセットと合格基準を持っています – 次のステージを実行する前に、品質要求を満足しなければなりません。 図7: 一般的なリンティング・フロー ここに2種類の合格基準があります。 現在のフェーズの設計品質（Design Quality） – 違反および非違反ルールの重みの比に基づいて計算される整数（User’s Guide | GUI Reference | Linting Windows | Violation Viewer | Design Quality Report Generation Wizardを参照） 違反してはならないクリティカル・ルール（Critical Rules、現在のフェーズで使用するルールから選択） 図8: Flow Manager フローを実行します。 Runボタンをクリックして、Flow Manager（図8）の現在のフローを実行 注意が必要なフェーズでフローの実行が停止 このフェースで検出された違反を修正して#1のアクションを繰り返す 注意: デザインがVHDLまたは混在言語[5]の場合は、最初のフローの実行時にトップ・レベルのデザインユニットの設定（図9）が要求されます。フローを再実行する毎に同じ問い合せがされるのを防止するために Save choice for active design オプションを選択します（必要であれば、この設定はDesign Properties | Linting | General | Top-level design unit でリセットできます）。 図9: トップ・レベルの問い合わせ 現在のフェーズと全体のフロー実行のステータスはFlow Manager （各フェーズに関連付けられたステータス・アイコンを確認）とコンソール・ウィンドウ（ALINT_FLOW_MANAGERが付いたメッセージを確認）の両方で表示されます。 結果の解析 各フェーズの実行結果は、個々の違反データベース（.avdb）ファイルに格納されています。現在の実行フェースが確認を必要とする場合は、フローの実行が停止して実行結果のデータベースが自動的[6]に違反ビューワにロードされます。このセクションでは、リンティング・セッション中に検出されたデザイン・ルール違反を分析するための重要なツールとなる違反ビューワの基本的な機能を説明します。 発生源によるグルーピング 違反ビューワは、その発生源に応じて様々な角度からツール違反へのアクセスを可能にする事前定義されたビューポイント／タブ（図10）があります。例えば: Summary – ルール毎、ソース・ファイル・デザイン・ユニット等、毎に検出された違反の数値データ Sources – ソース・ファイルでグループ化された違反 Design Units – デザイン・ユニット（entity, architecture, module）でグループ化された違反 Instances – インスタンスでグループ化された違反 Rules – ルール番号でグループ化された違反 Rule Levels – ルールの重要度でグループ化された違反（Rule, Recommendation 1-3, Suggestion） 図10: 違反ビューワ 注意: 違反データベースは、関連する幾つかのルール違反を持つ、デザインユニットやインスタンスに関する情報だけを格納しています。言いかえれば、違反ビューワのDesign Unitsタブ以下で、デザインユニットの完全なリストを表示することができない場合があります。または、任意のインスタンスと違反が関連付けられていない場合は、Instancesタブは全く使用できない場合があります（例えば、エラボレーション・タイムのリンティングを実行していない）。 フィルタリング 違反ビューワで使用可能なフィルタ・ツール を使用して、検出された問題のリストを絞り込むことができます。以下のフィルタ基準がサンプル（図11）に設定されています: デザイン・ユニットが"bin2bcd"で始まりかつRecommendation 1以上の重要度を持つ（Rule）違反だけを表示。 図11: 違反ビューワによるフィルタ 注意: フィルタは現在表示している違反に影響しますが、データベース自体は変更されません。フィルタは後で何時でも変更またはリセットできます。 クロス・プロービング 違反ビューワで任意のルールを選択すると、該当する違反メッセージがメッセージ部分にリストされます。クロス・プロービングは簡単で、違反メッセージをダブル・クリックすると違反を起こしているソース・コードの部分／文脈にジャンプします。違反ビューワをアンドックして、ウィンドウの右上端にあるStay on Topオプションを便利に使用できます。この方法で、図12に示すように違反とソースコードを常に表示できます。 図12: ソース・コードへのクロスプロービング 注意: Rule Description Viewerには、常にルールに関する簡単な説明が表示されます（違うルールを選択するとアップデートされます）。 違うフォーマットへのエクスポート 現在の（フィルタされた）ビューまたはデータベース全体を.html、.csv、テキストのようなフォーマットでエクスポートすることができます。 図13: .htmlへの出力例 別のフォーマット（ – .txt, – .csv, – .html）で違反レポートを生成するには、違反ビューワのツールバーにあるエクスポート・ボタンをドロップ・ダウンして使用してください。現在選択されている表示に依存した結果がレポートに出力されます（Rulesタブから生成した.htmlレポートの例は図13を参照）。 除外の管理 デザインには、一定のルールを無効にする必要がある幾つかのブロックまたは文脈が含まれる場合があります。例えば、RTLモデルだけでなくブロックを実装するためのEDIFネットリストを持っている場合などです（このような場合には、RTLモデルはシミュレーションを目的とするためだけに有効であり、合成ルールに照らしてチェックされる必要はありません）。特定の文脈をチェックしてから一定のルールを無効にするような他の幾つかの理由があるかもしれません。ALINTは除外ファイル（.alintexclusions）と除外エディタ – ルールの除外管理のための統一されたメカニズムを提供します。除外する設定を先に作成してデザインに関連付けることができますが、最も便利な方法は違反を解析しながら、違反ビューワから直接除外指定を行うことです。実際の部分に進む前に、基本的な用語を確認します。違反ビューワには、2種類のノードがあります – コンテナとリーフ（図14） 図14: 違反ビューワの異なったノード・タイプ リーフ・ノードが何も持たないのに対して、コンテナ・ノードは１つまたは複数のサブ・ノードを持ちます。ノードの種類によって異なるコンテキスト依存のアクションを確認するため、任意のノードを右クリックします。 コンテナ・ノード – 現在選択されているノード内に存在する全てのソース・ファイル、デザイン・ユニット、インスタンスに対する全てまたは特定の違反ルールを無効にする一括処理 リーフ・ノード – 現在選択されているリーフ内に存在する特定のデザイン・ユニットを個々に無効化 図14に表示している違反データベースの例: blackjack.vを右クリックし、Disable rule(s) for | Design Units | Violated Rules を選択。blackjack.vに記述された全てのデザイン・ユニットに対して、RMM.VLOG.5.2.9.1, STARC_VLOG.1.1.1.3, STARC_VLOG.1.1.3.3 および他に検出された全てのルールが無効となる。 blackjack.vの中にあるRMM.VLOG.5.2.9.1ノードを右クリックし、Disable rule(s) for オプションを選択。RMM.VLOG.5.2.9.1に対して2つの異なった選択が可能: "blackjack.v"（ソースファイル）または"MIXED_BJACK"（ソース・ファイルに記述されたデザイン・ユニット）へのルールを無効化する。 図15: サンプル設定をロードした除外エディタ 実際の運用では、File | New | Exclusions File を使用して除外するカスタムセットを作成することができ、Design Properties | Linting | General | Exclusions File でデザインに関連付けます。それ以降は、違反を分析しながら設定した全ての除外はこのセットに記録されます。ファイル・ブラウザ[7]で表示されている.alintexclusionsファイルをダブルクリックするかまたはFile | Open | File… メニューを使用して、専用の除外エディタ（図15）でいつでも現在の除外を開いて編集することができます。 まとめ ALINTの基本的な機能（GUIに関する事柄）の紹介はこれで終了です。このドキュメントはGUI環境よりもシェルスクリプトを使用する場合に重要なカスタムポリシーの作成や、事前定義されたフローよりも完全なカスタムポリシーを当てにするような、バッチモードのコマンドなどの内容をカバーしていないことにご注意ください。ご覧頂いたように、デザインをロードして事前に設定されたフローの1つに対してチェックを実行するには数分かかります。デザイン・リンティングのセッション中に検出された違反については、それを分析して修正するのに必要な時間を予測することは困難です（それらはデザイン・サイズ、複雑さ、コード品質に依存します）。 参照 [1] これらのスクリプトはツールのインストール・ディレクトリ下にあり、OSによって異なる拡張子を持ちます（.bat - Windows, .sh - Linux）。 [2] ワークスペースとデザインの作成は任意で、全てのリンティングの動作が現在のワーキング・ディレクトリ内でコマンドまたはスクリプト・ファイルを使用して行うことができることに注意ください。 [3] 同期したクロックは一定の周期と位相関係があります。 [4] STARCが付けられた事前定義のフローは日本の半導体理工学研究センター（STARC）によってまとめられたRTL設計スタイルガイドのルールに基づいています。STARCは何年にもわたるASICやFPGA設計の経験を持つ大手半導体企業のコンソーシアムです。その貢献者リストには、富士通、パナソニック、シャープ、ソニー、東芝に限定されず他の多くの企業も含まれています。 [5] Verilogデザインの場合は、トップ・レベルは自動的に検出されます。 [6] 任意のフェーズを実行し、フェーズを右クリックしてView Phase Results を選択することで、マニュアルで検出された違反をロードすることができます。 [7] ヒント: 除外設定をデザインに追加し、Design Manager に表示してダブルクリックでアクセスできるように設定できます。デザインを右クリックしてAdd | Existing File…を使用して.alintexclusions ファイルを追加します。 Previous article Next article
