HLS コンポーネント フローを使用する場合、適切に記述されていない C/C++ 関数を合成して、インプリメンテーションの詳細を解析して関数が正しく機能しない原因をつきとめるのが時間の無駄であることがあります。そのため、高位合成の最初の手順は、適切に記述されたテストベンチを使用してシミュレーションを実行し、RTL コードを生成する前に C 関数が正しいことを検証することです。適切なテストベンチを記述すると、C 関数を RTL シミュレーションよりも短時間で実行できるので、生産性が上がります。C/C++ を使用してアルゴリズムを開発して合成前に検証する方が、RTL コードを開発してデバッグするよりもはるかに高速です。
テストベンチには、main()
関数と、必要なサブ関数が含まれます。これらのサブ関数は、合成に指定されている最上位関数に含まれません。main 関数は、スティミュラスを供給して合成用の関数を呼び出し、その出力を消費して検証することにより、そのテストベンチから関数が正しく機能するかどうかを検証します。
次に、セルフチェック テストベンチの重要な機能を示すコード例を示します。
int main () {
//Establish 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;
}
テストベンチは最上位関数を複数のトランザクションで実行し、さまざまなデータ値を適用して検証する必要があります。テストベンチの質は、どれだけ多様なテストを実行できるかによります。また、C/RTL 協調シミュレーションの実行 に説明されるように、RTL シミュレーション中に II を計算する場合は、テストベンチで合成された関数を繰り返し呼び出す必要があります。
上記のセルフチェック テストベンチでは、関数の結果 output.dat が output.golden.dat の既知の良い結果と比較されます。これは、セルフチェック テストベンチの 1 例です。最上位関数を検証する方法は多数あるので、コードに適切なテストベンチを記述する必要があります。
HLS コンポーネント フローでは、main()
関数の戻り値は次のとおりです。
- 0: 結果が正しいことを示します。
- 0 以外: 結果が正しくないことを示します。
テストベンチから 0 以外の値が返されることがあります。複雑なテストベンチには、エラーのタイプによって異なる値を返すものもあります。C シミュレーションまたは C/RTL 協調シミュレーション後にテストベンチから 0 以外の値が返されると、エラーまたはシミュレーション エラーがレポートされます。
main()
関数の戻り値はシステム環境により解釈されるので、移植性と安全性のため、戻り値を 8 ビットの範囲に制約することをお勧めします。シミュレーションの結果の質は、使用するテストベンチによります。テストベンチが正しい結果を返すことを確認するのはユーザーの責任です。テストベンチで 0 が返されると、シミュレーションで何が発生していたとしても、シミュレーションで問題は検出されなかったと判断されます。