Vitis HLS フローでの検証には、大きく分けて 2 つのプロセスが含まれます。
• C プログラムが正しく必要な機能をインプリメントするかどうかを確認する合成前の検証。
• 生成後の RTL コードが問題なく動作するかどうかを確認する合成後の検証。
どちらのプロセスもシミュレーション (「C シミュレーション」および「C/RTL 協調シミュレーション」) と呼ばれま す。
合成前に、合成する関数を C シミュレーションを使用したテストベンチで検証する必要があります。C テストベンチ
には、Vitis HLS プロジェクトで合成される関数を呼び出す最上位関数main()が含まれます。テストベンチには、そ
の他の関数を含めることもできます。理想的なテストベンチには、次のような特徴があります。
• テストベンチにはセルフチェック機能があり、合成される関数からの結果が正しいかどうかを検証する。
• 結果が正しい場合はテストベンチから main() に値 0 を返し、正しくない場合は 0 以外の値を返す。
Vitis HLS の GUI で [Run C Simulation] ツールバー ボタン をクリックすると、次の図に示す [C Simulation Dialog]
ダイアログ ボックスが開きます。
図 20: [C Simulation Dialog] ダイアログ ボックス
[C Simulation Dialog] ダイアログ ボックスには、次のオプションが含まれます。
• [Launch Debugger]: C コードをコンパイルし、[Debug] パースペクティブを 開きます。[Debug] パースペクティブ から左上の [Synthesis] パースペクティブ ボタンをクリックすると、合成表示に戻ります。
• [Build Only]: ソース コードとテストベンチをコンパイルしますが、シミュレーションは実行しません。このオプ ションは、コンパイル プロセスをテストして、シミュレーション前にビルドに関する問題を解決するために使用 します。コマンド シェルからシミュレーションを実行可能な csim.exe ファイルが生成されます。
• [Clean Build]: コードをコンパイルする前に既存の実行ファイルおよびオブジェクトファイルをプロジェクトから
削除します。
• [Optimizing Compile]: デフォルトではデザインはデバッグ情報をイネーブルにした状態でコンパイルされ、そのコ ンパイルを解析およびデバッグできるようになっています。[Optimizing Compile] オプションを使用すると、デザ インをコンパイルする際により高いレベルの最適化エフォートが使用されますが、デバッガーで必要とされる情 報は追加されません。これにより、コンパイル時間は増加する可能性がありますが、シミュレーション実行時間 は削減されます。
ヒント: [Launch Debugger] と [Optimizing Compile] オプションを同時に使用することはできません。[C Simulation Dialog] ダイアログ ボックスでいずれかをオンにすると、もう一方がオフになります。
• [Enable Pre-Synthesis Control Flow Viewer]: [Pre-Synthesis Control Flow] ビュー に説明する合成前の制御フロー レポートを生成します。
• [Input Arguments]: テストベンチの main() 関数で必要となる入力を指定します。
• [Do not show this dialog box again]: [C Simulation Dialog] ダイアログ ボックスが表示されなくなります。
ヒント: [Project] → [Project Settings] をクリックし、[Simulation settings] を選択すると、[C Simulation Dialog] ダイ アログボックスを再び表示されるようになります。
ダイアログ ボックスで [OK] をクリックすると、C コードがコンパイルされて、C シミュレーションが実行されます。
シミュレーションの実行中、コンソールにテストベンチからの printf 文が表示されます。シミュレーションが問題 なく完了すると、コンソールに次のメッセージが表示されます。
INFO: [SIM 211-1] CSim done with 0 errors.
INFO: [SIM 211-3] *************** CSIM finish ***************
Finished C simulation.
シミュレーションが正常に実行されなかった場合は、エラーが返されます。
@E Simulation failed: Function 'main' returns nonzero value '1'.
ERROR: [SIM 211-100] 'csim_design' failed: nonzero return value.
INFO: [SIM 211-3] *************** CSIM finish ***************
[Launch Debugger] オプションを選択すると、自動的に [Debug] パースペクティブに 切り替わり、次の図に示すよう なデバッグ環境が開きます。シミュレーションが開始し、コードをステップ実行して関数を確認およびデバッグでき ます。これは完全なデバッグ環境で、コードをステップインおよびステップオーバーしたり、ブレークポイントを指 定したり、コードで変数の値を設定したりできます。
図 21: C デバッグ環境
ヒント: [Synthesis] パースペクティブ ボタンをクリックすると、標準の合成ウィンドウに戻ります。
テストベンチの記述
Vitis HLS デザイン フローを使用する場合、適切に記述されていない C 関数を合成して、インプリメンテーションの 詳細を解析して関数が正しく機能しない原因をつきとめるのは時間の無駄です。そのため、高位合成の最初の手順は、
適切に記述されたテストベンチを使用してシミュレーションを実行し、RTL コードを生成する前に C 関数が正しいこ とを検証することです。適切なテストベンチを記述すると、C 関数を RTL シミュレーションよりも短時間で実行でき るので、生産性が上がります。C を使用してアルゴリズムを開発して合成前に検証する方が、RTL コードを開発して デバッグするよりもはるかに高速です。
Vitis HLS ではこのテストベンチを使用して、C シミュレーションがコンパイルされて実行されます。コンパイルする
際に [Launch Debugger] オプションをオンにすると、C デバッグ環境を開いて、C シミュレーションを詳細に解析で
きます。Vitis HLS では、Vitis HLS での C/RTL 協調シミュレーションに説明されているように、このテストベンチを
使用して合成の RTL 出力が検証されます。
テストベンチには、main()関数と、必要なサブ関数が含まれます。これらのサブ関数は、Vitis HLS での合成に指定 されている最上位関数に含まれません。main 関数は、スティミュラスを供給して合成用の関数を呼び出し、その出力 を消費して検証することにより、合成用の最上位関数が正しく機能するかどうかを検証します。
重要: C シミュレーションを使用したコードの検証 に説明されているように、C シミュレーションを起動するときに テストベンチに入力引数を指定できますが、シミュレーション中にテストベンチにユーザーがインタラクティブに 入力することはできません。Vitis HLS の GUI にはコマンド コンソールがないので、テストベンチ実行中にユーザー 入力を受信することはできません。
次に、セルフチェックテストベンチの重要な機能を示すコード例を示します。
int main () {
//Esablish an initial return value. 0 = success int ret=0;
// Call any preliminary functions required to prepare input for the test.
// Call the top-level function multiple times, passing input stimuli as needed.
for(i=0; i<NUM_TRANS; i++){
top_func(input, output);
}
// Capture the output results of the function, write to a file // Compare the results of the function against expected results ret = system("diff --brief -w output.dat output.golden.dat");
if (ret != 0) {
printf("Test failed !!!\n");
ret=1;
} else {
printf("Test passed !\n");
}
return ret;
}
テストベンチは最上位関数を複数のトランザクションで実行し、さまざまなデータ値を適用して検証する必要があり ます。テストベンチは、実行されるさまざまなテストでのみ有効です。また、Vitis HLS での C/RTL 協調シミュレー ション に説明されているように、RTL シミュレーション中に II を計算する場合は、テストベンチで複数のトランザク ションを供給する必要があります。
このセルフチェック テストベンチでは、関数の結果 output.dat が output.golden.dat の既知の良い結果と比 較されます。これは、セルフチェック テストベンチの 1 例です。最上位関数を検証する方法は多数あるので、コード に適切なテストベンチを記述する必要があります。
Vitis HLS デザイン フローでは、main() 関数の戻り値は次のとおりです。
• 0: 結果が正しいことを示します。
• 0 以外: 結果が正しくないことを示します。
テストベンチから 0 以外の値が返されることがあります。複雑なテストベンチには、エラーのタイプによって異なる 値を返すものもあります。C シミュレーションまたは C/RTL 協調シミュレーション後にテストベンチから 0 以外の 値が返されると、Vitis HLS でエラーまたはシミュレーション エラーがレポートされます。
ヒント: main() 関数の戻り値はシステム環境により解釈されるので、移植性と安全性のため、戻り値を 8 ビットの 範囲に制約することをお勧めします。
シミュレーションの結果の質は、使用するテストベンチによります。テストベンチが正しい結果を返すことを確認す るのはユーザーの責任です。テストベンチで 0 が返されると、シミュレーションで何が発生していたとしても、Vitis HLS ではシミュレーションで問題は検出されなかったと判断されます。
テストベンチ例
ザイリンクスでは、合成用の最上位関数はテストベンチとは分けて記述し、ヘッダー ファイルを使用する方法をお勧 めします。次に、HLS プロジェクトの最上位関数 hier_func が次の 2 つのサブ関数を呼び出すデザインのコード例 を示します。
• sumsub_func: 加算および減算を実行。
• shift_func: シフトを実行。
データ型はヘッダー ファイル ファイル (hier_func.h) で定義されています。関数のコードは次のとおりです。
#include "hier_func.h"
int sumsub_func(din_t *in1, din_t *in2, dint_t *outSum, dint_t *outSub) { *outSum = *in1 + *in2;
*outSub = *in1 - *in2;
}
int shift_func(dint_t *in1, dint_t *in2, dout_t *outA, dout_t *outB) { *outA = *in1 >> 1;
*outB = *in2 >> 2;
}
void hier_func(din_t A, din_t B, dout_t *C, dout_t *D) { dint_t apb, amb;
sumsub_func(&A,&B,&apb,&amb);
shift_func(&apb,&amb,C,D);
}
最上位関数には複数のサブ関数を含めることができますが、合成できるのは 1 つの最上位関数のみです。複数の関数 を合成するには、それらをサブ関数として 1 つの最上位関数にまとめます。
次に示すヘッダー ファイル (hier_func.h) に、マクロの使用方法と、typedef 文を使用することでコードの移植性 および読みやすさを向上できることを示します。
ヒント: 任意精度 (AP) 型には、typedef文で任意精度型を使用できること、それにより最終的な FPGA インプリメ
ンテーションでエリアとパフォーマンスの両方を向上するために変数のビット幅を調整できることが説明されてい ます。
#ifndef _HIER_FUNC_H_
#define _HIER_FUNC_H_
#include <stdio.h>
#define NUM_TRANS 40 typedef int din_t;
typedef int dint_t;
typedef int dout_t;
void hier_func(din_t A, din_t B, dout_t *C, dout_t *D);
#endif