リンティングレグレッションの設定

リグレッションテストスイートとは、かつて「機能していた」デザイン機能が、「回帰」して動作しない時点まで「後退」しないことを確認するための一連のテストです。これらのテストが開発されると、RTLまたはテストベンチの後続リリースまたはチェックインはこのリグレッションスイートでチェックする必要があります。

同様にリグレッションリンティングの検証は、RTLコード品質が設計プロセス中に低品質レベルに「後退」しないことを保証することを目的としています。RTLコードの後続リリースまたはチェックインは、開発期間全体を通してRTLコーディングの高品質を保証するために、このリグレッションリンティングで確認する必要があります。

機能的なリグレッションとは異なり、リントリグレッションではテストケースの開発が不要です。また、リンティングツールは高速に実行されるため、設計者はRTLコードの後続リリースやチェックイン後にコード品質を検証する効率的な方法を得ることができます。

機能的なリグレッション前や、インプリメンテーション（合成）のためのコードをリリースする前に、リンティングチェックを実行することが重要です。リンティングツールは機能およびインプリメンテーション固有のコード問題を数秒で明らかにすることができ、設計者は時間のかかるインプリメンテーションと機能検証の繰り返しから解放されます。

複数のハードコンフィギュレーションオプションを持つデザインでは、リンティングチェックを継続的に実行することが特に重要です。このような設計では、マクロの組み合わせごとに別のデザインバージョンが作成されるため、各デザインバージョンをリンティングツールでチェックする必要があります。コード固有の問題が特定のデザインバージョンでのみ発生する場合があるため、すべてのデザインバージョンを個別にリンティングツールで検証する必要があります。

デザイン検証では、リグレッションは一連の自動テストとして構築されます。自動テストを開発するためには、テストケース本体または検証環境のいずれかに自動チェックを実装する必要があります。これらの自動化されたチェックは、テスト実行の終了時にテストステータス（合格または不合格）を明確に定義します。すべてのリグレッションテストが合格したときにリグレッションは合格とみなされます。少なくとも 1 つのテストが不合格になると、リグレッションは不合格したとみなされます。リグレッションが不合格となると共通リポジトリへのデザイン変更の導入を中止し、コードの修正を開始するよう、開発チーム全体にメッセージがブロードキャストされます。共通リポジトリのコードが修正されると、設計者は通常のワークフローを再開できます。

リンティングリグレッションは、プロジェクトの全期間を通じて非常に役立ちます。デザイン検証のリグレッションとは異なり、リンティングリグレッションは時間が短く、計算量も少なくて済みます。リンティングリグレッションを実行する際の一般的な戦略の1つは、コードリポジトリを定期的にポーリングしてコードの修正を確認することです。変更が見つかると、リンティングツールはスタティックデザイン検証を開始し、その結果、明確な合格/不合格のステータスを生成します。リグレッションが失敗した場合、システムは即座にチームメンバーに失敗を通知し、設計者は複数のコード修正が蓄積される前にコードを即座に修正することができます。

次のアプリケーションノートでは、リンティングリグレッションを設定するための実践的なアプローチを紹介します。まず、スタティックデザイン検証から明確な合格/不合格ステータスを抽出する方法について紹介します。次に拡張可能な自動化サーバーであるJenkinsを使用して、リンティングリグレッションを設定および実行する方法を説明します。Jenkinsオートメーションサーバーは、プロジェクトコードの品質を維持するために、設計者が機能およびリンティングリグレッションを自動化することに役立ちます。

ハードウェアデザインのスタティック検証における合格/不合格ステータスの開発

合格/不合格ステータスの開発により、設計者がスタティックデザイン検証プロセスをさらに自動化し、リンティングリグレッションを設定することが出来ます。この目的のために、設計者は違反してはならないルールを慎重に選択する必要があります。これらのルールにはセベルティ「Error」としてマークする必要があります。セベルティ「Error」のルールが1つでも失敗すると、リント実行プロセス全体も失敗し、標準エラーメッセージが環境に返されます。次の図はALINT-PROのポリシーエディタで選択したルールのセベルティを「Error」に設定しています：

設計チームによってデザインのコーディング、検証、インプリメンテーションに対する要求が異なるため、クリティカルルールの選択に関する共通の戦略を策定することは困難です。しかし若干の修正を加えることで、大半の設計チームに適したリンティング実行ステータスを開発するための以下のステップを提案します：

各ルールプラグインでは「共通の」クリティカルルールが選択されます。
共通のクリティカルルールに加えて、デザインまたはデザインプロセスの要件に応じて追加出来るがあります。

スクリプト「set_regress_status.do」は、ほとんどのALINT-PROプラグインのて共通ルールと追加ルールを定義しています。追加ルールはサブグループにグループ化され、各サブグループは対応する変数を１に設定することで、セベルティ「Error 」をルールセットに追加できます。

次の表は、クリティカルルールの追加サブグループを有効にするTCL変数について説明しています：

Variable	Default	Description
Clock-related requirements
require_single_clock	0	require single clock in current design
require_single_clock_edge	0	require single rising clock edge in current design
Reset-related requirements
require_async_reset	0	Require all sequential design logic to be asynchronously reset
allow_initial_assign	0	Some FPGA vendors allow initial assigns for sequential elements. Set to 1 when initial assignments are allowed
Tools Reuse-specific requirements
require_syn_tool_reuse	0	require RTL code to be re-usable between synthesis tools
require_sim_tool_reuse	0	require RTL code to be re-usable between simulation tools
Timing & Area efficiency requirements
require_timing_efficienty	0	require RTL code to be timing efficient
require_area_efficienty	0	require RTL code to be area efficient
Code-specific requirements
require_no_attributes	0	require an absence of synthesis attributes
require_no_redundancy	0	require no redundancy in RTL code
require_strict_bit_match	0	require strict bit match at signal assignments
require_strict_downto_range	0	require ranges to be strictly down to with the lower range limit equaling 0
Other requirements
require_ip_checks	0	require design to follow commonly-used IP designs' timing requirements
require_strict_dft	0	require RTL code to follow DFT requirements
require_strict_xprop	0	require RTL code to properly propagate X's
require_sv_constructs	0	require design to use more efficient SystemVeriog language constructs for processes and case selection statements

リグレッション設定スクリプトのサンプルは、アルデックのリポジトリで入手できます（末尾の「デモスクリプトのダウンロード」の章をご覧ください）。ユーザはこのスクリプトを修正、共通ルールやクリティカルルールを追加または削除することができます。

リンティングリグレッションのTCL実行ファイルの開発

リグレッションステータスが開発されると、リンティングバッチモードを有効にするために、簡単なTCL実行ファイルを作成する必要があります。リンティング実行ファイルには次の機能が必要です：

ALINT-PROプロジェクトを自動的に作成し、必要な全てのファイルをプロジェクトに追加します。
合格/不合格ステータスの抽出を有効にするために、プロジェクトポリシーを設定します。
プロジェクトを実行します。
エラー/ワーニングレポートを作成します。
失敗した場合、環境にSTDERRメッセージを環境に返します。

次のTCL実行ファイルの例は、上記の要件をすべて実装しています：

Jenkins Extensible Automation Serverでリンティングレグレッションを設定

Jenkinsオートメーションサーバーは、迅速かつ簡単にリンティングリグレッションのセットアップを行うことができ、リポジトリコードの継続的な検証を可能にします。この記事では、一般的に使用されているリビジョン管理システムであるApache Subversion(SVN)でJenkinsベースのリグレッション自動化を使用する方法を紹介します。

この例のために、オープンソースのAquariusプロセッサのコード（OpenCores.orgリソースからダウンロード）をSVNリポジトリに追加しました。また、下記2つのスクリプトを追加しました：

aquarius_policy.do: 合格/不合格ステータスを実装するポリシー設定スクリプト
run_alint.do: ALINT-PROをバッチモードで実行するためのTCL実行ファイル

SVNリポジトリコードの準備ができたら、Jenkinsオートメーションサーバーの設定を開始できます。

Jenkinsをダウンロードしてインストールします。この記事を書いている時点では、最新バージョンはURL https://jenkins.ioで入手できます。インストーラを実行するときは、デフォルトを受け入れてください。注意：Jenkinsをインストールする前に、Javaバージョン8以降のJDK（Java Development Kit）をインストールする必要があります
ウェブブラウザを開き、Jenkinsページ（http://localhost:8080）に移動します。インストールが成功した場合、Jenkinsホームページが表示されます：
Jenkinsのユーザーアカウントを設定し、「New Item 」をクリックします。プロジェクト識別子（アイテム名）を入力し、「Freestyle project」を選択し、「OK」をクリックします：
プロジェクトを設定します：
1. ソースコード管理ツールとして「Subversion」を選択します。
2. Repository URL」オプションにSVNリポジトリのURLパスを入力します。ほとんどの場合、SVNリポジトリサーバーには、SVN固有のsvn://プロトコルかSSHを使用してアクセスできます。この例では、SVNリポジトリはローカルに存在します：
3. 「Build Triggers」セクションで、最後のオプション「Poll SCM」を選択します。このオプションは定期的にコードリポジトリに変更がないかポーリングします。変更が見つかると、次のビルドが開始されます。
4. 「Schedule」セクションで、コードリポジトリをポーリングする期間をcron形式で設定します。このタスクを簡単にするには、crontab.guruエディタ（www.crontab.guru）を使用します。
  
  デバッグの目的で、1分間隔の時間を設定すると便利です。スケジュールウィンドウに、 * * * * * (スペースで区切られた5つの星）を入力するだけです。
5. ビルドセクションで、ビルドステップ「Execute Windows batch command」を追加します。事前に用意した「run_alint.do」スクリプトを使用して、バッチモードでALINT-PROを起動するバッチコマンドを追加します：
6. Post-build Actions」をクリックし、「E-mail notification」を選択します。これにより、ビルド失敗時に自動的にメールが送信されます。「Recipients」フィールドに受信者の電子メールを追加します。
  
  これでプロジェクトコンフィギュレーションが終了し、ここからリンティングレグレッションの実行を開始できます。
リグレッションの実行：「Aquarius"」プロジェクトのリンクをクリックしてプロジェクトのワークスペースに入ります：

「Build now」をクリックして、ビルドスケジュールを開始します。各ビルドは、青（ビルドに合格）または赤（ビルドに不合格）のドットで識別され、クリック可能なビルドID番号が表示されます。不合格のビルドログを確認するには、ビルドID番号をクリックし「Console Output」を確認します。この場合、エラーおよびワーニングログはコンソールに送信されます。

例えば、図のようにビルド#3はデザインエラーにより失敗しています。ビルド#3のコンソール出力にあるリンティングエラーを確認すると、より詳細な情報が得られます：

エラーを修正するには、ALINT-PROをインタラクティブモードで開くことをお勧めします。Jenkinsはすべてのプロジェクトファイルを.zip形式で圧縮しています。ワークスペースのページに移動し、アーカイブをダウンロードしてください：

解凍後、ALINT-PROを起動し、アーカイブからワークスペースファイルを開きます。エラーを修正し、デザイン変更をSVNデータベースにコミットし、Jenkinsを再実行します。次ビルドでは、今度は「合格」ステータスになることが理想的です。Linuxユーザーの場合、Jenkinsのインストール手順は若干異なる可能性があります。プラットフォーム固有のインストールについては、www.jenkins.ioまたはコミュニティサイトを参照してください。例えば、以下のページではUbuntu 16.04でのJenkinsのインストール手順について説明しています: https://www.digitalocean.com/community/tutorials/how-to-install-jenkins-on-ubuntu-16-04

デモスクリプトのダウンロード

set_regress.do: 合格/不合格ステータスを実装するポリシー設定スクリプト
run_alint.do: リンティングレグレッション用のTCL実行ファイル

まとめ

このアプリケーションノートでは、JenkinsオートメーションサーバーでALINT-PROを使用してリンティングリグレッションを設定する方法を実演し説明しました。また、ALINT-PROの実行における合格/不合格ステータスの定義方法についても説明しました。リンティング実行の合格/不合格ステータスを明確に識別することで、設計者はリンティングの自動化、リンティングレグレッションの設定、スタティックコード検証のパワーを適用して、プロジェクトのライフタイム全体にわたってRTLコードの品質と安定性を維持することができます。