フォーラムへの返信
- 投稿
as004で実行されていますでしょうか。
試してみたところ一回目の実行ではエラーが出てしまいましたが、二回目は実行できました。ando@as004:/scratch/Vitis-Tutorials/Getting_Started/Vitis/example/u200/hw
$ ./app.exe
INFO: Found Xilinx Platform
INFO: Loading ‘vadd.xclbin’
terminate called recursively
terminate called after throwing an instance of ‘__gnu_cxx::recursive_init_error’
what(): 中止 (コアダンプ)
ando@as004:/scratch/Vitis-Tutorials/Getting_Started/Vitis/example/u200/hw
$ ./app.exe
INFO: Found Xilinx Platform
INFO: Loading ‘vadd.xclbin’
TEST PASSEDXCL_EMULATION_MODE環境変数がhw_emuに設定された状態のまま、ハードウェア向けにビルドしたxclbinを使ってappを実行されているのではないかと思います（チュートリアルの通りに進めると最後のステップでそうなってしまうと思います。）。
appを実行する前にXCL_EMULATION_MODEをクリアしてみてください。
export XCL_EMULATION_MODE=
./app.exeC=>RTL合成で時間がかかる理由につきましてはおっしゃる通りだと思います。C=>RTL合成で時間がかかるときにその原因をツールが教えてくれると良いのですが、そうはなっていないので、今のところ、タイムアウトしてしまう場合には並列度を調整するくらいしかできることはなさそうです。
返信が遅くなり申し訳ありません。フィードバックありがとうございます。
論理合成は、CoSIMが通ったHLSプロジェクトで、論理合成を有効にしてIPをエクスポートすることで行っています。チェッカーではこちらのコードです。
https://github.com/acri-room/vhls-challenge-checker/blob/master/src/lib/syn_checker.sh論理合成の実行時間を短くするには回路規模を小さくするしかないかと思います。問題によって論理合成を行うかどうか設定していますが、なかなか判断が難しいです。論理合成は基本的にオフにして、採点にかかる時間を短くして、たくさんコードを提出してもらえるようにした方が良いかと感じています。
ご提案ありがとうございます。確かに、合成制約を変えればもっと速くできるのに、というもどかしさはあるかと思います。
一方でHLSによる設計では見積もり上の動作周波数をコントロールするのはなかなか難しく、さらに投稿者が適切な合成制約も見つけなくてはいけなくなるとチャレンジの難易度が上がってしまう心配があります。チャレンジはハードウェアのアーキテクチャを考えてHLSで実現することを中心になるべくシンプルにしておきたいです。
これまでのチャレンジは100MHzで作ってしまいましたが、これらが最初から500MHzであれば問題なかったでしょうか。ご指摘はもっともですので今後作るチャレンジは500MHzにしようかと思いました。
