VivadoHLSでの高位合成中のエラーについて

Question

VivadoHLSで高位合成中にこのようなエラーが出て処理が進まなくなります．
何が悪くてこのような状態になっているのかわかりません．わかる方は教えていただけないでしょうか．
また、UNROLLディレクティブを適用すると合成が通るようになりますが、RTLシュミレーションが終わらなくなります。（本来十分もあると終わるシュミレーションのはず。もしかすると何日も回し続けるとおわるかもしれない）

INFO: [HLS 200-10] ----------------------------------------------------------------
INFO: [HLS 200-10] -- Implementing module 'triangleCount' 
INFO: [HLS 200-10] ----------------------------------------------------------------
INFO: [SCHED 204-11] Starting scheduling ...
0x00007FF989265208 (0x0000000000000000 0x0000025859708280 0x00000258541A2020 0x0000000000000000), ?save_object_ptr@?$pointer_oserializer@Vxml_oarchive@archive@boost@@VTransition@DBFsm@fsmd@@@detail@archive@boost@@EEBAXAEAVbasic_oarchive@234@PEBX@Z() + 0xB5078 bytes(s)
0x00007FF989263A0C (0x0000000000000000 0x0000000000000000 0x0000025859708280 0x00007FF9898D5285), ?save_object_ptr@?$pointer_oserializer@Vxml_oarchive@archive@boost@@VTransition@DBFsm@fsmd@@@detail@archive@boost@@EEBAXAEAVbasic_oarchive@234@PEBX@Z() + 0xB387C bytes(s)
0x00007FF9892DB9A3 (0x0000000000000000 0x0000025859E7D600 0x0000025858E9D120 0x00007FF989287899), ?save_object_ptr@?$pointer_oserializer@Vxml_oarchive@archive@boost@@VTransition@DBFsm@fsmd@@@detail@archive@boost@@EEBAXAEAVbasic_oarchive@234@PEBX@Z() + 0x12B813 bytes(s)
0x00007FF9892DE4B5 (0x000002585D49BD70 0x0000025859E7D600 0x0000006814DF61A8 0x0000025859E7D600), ?save_object_ptr@?$pointer_oserializer@Vxml_oarchive@archive@boost@@VTransition@DBFsm@fsmd@@@detail@archive@boost@@EEBAXAEAVbasic_oarchive@234@PEBX@Z() + 0x12E325 bytes(s)
0x00007FF989338484 (0x000002585D8B4D70 0xFFFFFFFFFFFFFFFE 0x000002585D4C9960 0x0000006814DF6330), ?save_object_ptr@?$pointer_oserializer@Vxml_oarchive@archive@boost@@VTransition@DBFsm@fsmd@@@detail@archive@boost@@EEBAXAEAVbasic_oarchive@234@PEBX@Z() + 0x1882F4 bytes(s)
0x00007FF989338844 (0x000002585D4C9960 0x0000025859E7CFC0 0x000002585D4C9960 0x0000006814DF64F0), ?save_object_ptr@?$pointer_oserializer@Vxml_oarchive@archive@boost@@VTransition@DBFsm@fsmd@@@detail@archive@boost@@EEBAXAEAVbasic_oarchive@234@PEBX@Z() + 0x1886B4 bytes(s)
0x00007FF98933B241 (0x0000006814DF63F0 0x0000025858B1E730 0x0000025858461260 0x0000006814DF64F0), ?save_object_ptr@?$pointer_oserializer@Vxml_oarchive@archive@boost@@VTransition@DBFsm@fsmd@@@detail@archive@boost@@EEBAXAEAVbasic_oarchive@234@PEBX@Z() + 0x18B0B1 bytes(s)
0x00007FF98907DC4B (0x0000025858B1E730 0x0000025858B1E730 0x0000025858B1E730 0x0000006814DF6660), ?main@Syn@@YAHHPEAPEAD@Z() + 0x4CC09B bytes(s)
0x00007FF988BAEB51 (0x0000006814DF6710 0x0000000000000000 0x00007FF989E7D9F0 0x0000000000000000)
0x00007FF9B5E2EB1C (0x0000025854308C60 0x0000000068353EC3 0x00000258589BCE30 0x0000025852687640), ??1TclManager@xpcl@@QEAA@XZ() + 0x257C bytes(s)
0x00007FF9B5E325D9 (0x00000000683D5A20 0x0000000000000000 0x000002585D7D44D0 0x000000006839AC3C), ?setResultObj@TclCommand@xpcl@@QEAAXPEAUTcl_Obj@@@Z() + 0x49 bytes(s)
0x00000000682D11FC (0x0000000000000000 0x0000025800000003 0x0000025854297B00 0x000002585D7D44D0), Tcl_ListMathFuncs() + 0x58C bytes(s)
0x00000000682D218E (0x0000025852687640 0x000002585D7D44D0 0x0000000000000003 0x0000000000000003), Tcl_EvalEx() + 0x99E bytes(s)
0x00000000682D2E0F (0x0000000000000000 0x00000258542977F8 0x0000000000000001 0x0000000000000002), TclEvalObjEx() + 0x32F bytes(s)
0x00000000682DADCA (0x00000258542977F8 0x0000025852687640 0x0000025852687640 0x0000000000000000), TclDumpMemoryInfo() + 0x33FA bytes(s)
0x00000000682D11FC (0x0000000000000000 0x0000000000000002 0x00000258542977F8 0xFFFFFFFFFFFFFFFF), Tcl_ListMathFuncs() + 0x58C bytes(s)
0x0000000068316238 (0x0000025852687640 0x0000025856E0C470 0x00000258542976A8 0x0000025800000000), Tcl_ExprObj() + 0x1868 bytes(s)
0x00000000683612F4 (0x0000000000000000 0x0000025852687640 0x00000258542976A8 0x0000000068380E7B), TclObjInterpProcCore() + 0x74 bytes(s)
0x00000000682D11FC (0x0000025800000000 0x0000000000000002 0x00000258542976A8 0xFFFFFFFFFFFFFFFF), Tcl_ListMathFuncs() + 0x58C bytes(s)
0x0000000068316238 (0x0000025852687640 0x0000025856EF5680 0x0000000000000001 0x0000000000000000), Tcl_ExprObj() + 0x1868 bytes(s)
0x0000000068314FEC (0x0000000000000001 0x0000025852687640 0x0000000000000FFF 0x0000000068381E42), Tcl_ExprObj() + 0x61C bytes(s)
0x00000000682D2E8D (0x0000000000000000 0x0000000000000001 0x00000258589B8360 0x0000000000000008), TclEvalObjEx() + 0x3AD bytes(s)
0x00000000682D2ACD (0x000002585D708960 0x0000000000000000 0x0000000000000000 0x00000258589B8360), Tcl_EvalObjEx() + 0x1D bytes(s)

Comments

[yohhoy]

何に解決にもならないかもしれませんが、出力されているメッセージはプログラム異常終了時のコールスタックトレースのように見えます。(関数呼び出し履歴とアドレス・各フレームの先頭メモリダンプ) ツールチェインの一部が異常終了しており、全体としては処理ストールを起こしているのかもしれませんね。

Answer 1

この手の問題で良く経験するのは、元のCのプログラムにHLSに関係無いレベルで問題がある場合が多いです。たとえば、初期化されていない変数をアクセスしている、配列の外側にアクセスしているなど。

一般のCのプログラムでは、初期化されていない変数の値は、毎回変化することも実際にあります。配列の外側アクセスは、本当に外側にアクセスします。
しかし、HLSの場合は、建前はどうであれ、変数は0に初期化されます。int a[16] 対して、a[n] == a[n&15] になります。配列の外側 たとえば、a[16]へのread / write は、x86で実行するるときは、問題が露見しないことが多いのですが、HLSではほぼ確実に露見します。

問題点を探すには、 memory debugger を使うと良いのですが、プログラムが小さすぎると、valgrindでは検出できないケースも多いようです。

ハードになる部分だけではなく、テストベンチに問題があっても当然、sim結果は、期待した感じになりません。例示されているエラーログが、HLS側で作られたものであれば、問題は、テストベンチの問題かもしれません。テストベンチが値を渡すときに渡せないのでしょう。グローバル変数を介してのハードの部分の処理はうまくいきません。コンセプト的には、以下のようなものです。

int a ;
int main () { ...
 int *p = &a ;
 a = .. ;
 func(p) ;
}
void func(int *p) { 
}