@Vengineerの戯言 : Twitter
SystemVerilogの世界へようこそ、すべては、SystemC v0.9公開から始まった
Verilator の フロントエンドは実は、Perl で書かれています。
これ です。
この中に、 BENCHMARKING & OPTIMIZATION という項目があり、Verilator コマンドへのパラメータによってコンパイル時間や実行時間を減らせるか書かれています。
最初は、OPT_SLOWにしておいて、レグレッションでは、OPT_FAST にすればいいのか？
で、この部分だけを、今、評判の DeepL にかけて、日本語にしたのが、下の部分。
いろんなオプションがあるので、試してみる価値あるかな？
特にコンパイル時間が長いとシミュレーションのTUTが長くなっちゃうので。。。
最高のパフォーマンスを得るためには、"-O3 --x-assign fast --x-initial fast --noassert "フラグをつけてVerilatorを実行してください。 O3 フラグはコンパイル時間が長くなり、"--x-assign fast --x-initial fast" はパフォーマンスと引き換えにバグをリセットするリスクを高めるかもしれません。
Verilatedマルチスレッドを使用している場合、C<numactl>を使用して、競合しないハードウェアリソースを使用していることを確認してください。L</"multithreading">を参照してください。
Verilogのコードを少し変更するだけでも大きな効果が得られます。 VerilatorからUNOPTFLATの警告が出ないようにしてください。 あるユーザーは、クロックのゲートに使用するクロックラッチを簡単に変更することでUNOPTFLAT警告を修正し、60%の性能向上を実現しました。
それ以上に、Verilatedモデルの性能は、主にC++コンパイラとCPUのキャッシュのサイズに依存します。
デフォルトでは、lib/verilated.mkファイルは最適化がオフになっています。
これは、シミュレーションの実行時間を犠牲にしてコンパイル時間を改善するためのものです。 デフォルトで最適化を追加するには、3つの変数のうちの1つを設定します。
OPT, OPT_FAST, OPT_SLOW lib/verilated.mk.を使用してください。 または、verilatorコマンドラインで-CFLAGSや-LDFLAGSオプションを使用して、コンパイラやリンカに直接フラグを渡すことができます。 あるいは、一回だけ実行する場合は、コマンドラインで渡してmakeを実行することもできます。
make OPT_FAST="-Os -fno-stack-protector" -f Vour.mk Vour__ALL.a OPT_FAST は高速パスの一部であるプログラムの最適化を指定します。 OPT_SLOW は、スローパスのファイル（トレースも含む）に対する最適化を指定します。 OPTは全体的な最適化を指定し、OPT_FASTとOPT_SLOWが制御するものを含め、すべてのコンパイルに影響を与えます。 最良の結果を得るためには、OPT="-Os "を使用し、"-static "とリンクしてください。 OPT_FAST="-O1 -fstrict-aliasing "を使用しても、ほぼ同じ結果が得られます。 O2 "や"-O3 "のようなより高度な最適化が役立つかもしれませんが、中規模のデザインであってもO3ではgccのコンパイル時間が過大になるかもしれません。
残念ながら、SystemCファイルでオプティマイザを使用すると、コンパイルに数分かかることがあります(SystemCライブラリには、コンパイラを狂わせるような小さなインライン関数がたくさんあります)。
最良の結果を得るためには、GCCよりも約10%速い最新のclangコンパイラを使用してください。 今ではかなり古いGCC 3.2やそれ以前のバージョンでは、ポインタエイリアシング検出の最適化バグがあり、2倍の性能低下を招く可能性があることに注意してください。
一つのコンパイルで多くのシミュレーションを実行している場合は フィードバック駆動型のコンパイルを行うことができます。 GCCでは、-fprofile-arcsを使用して、次に -fbranch-probabilitiesを使用すると、さらに15%程度の値が得られます。
最近のコンパイラはリンク時間の最適化 (LTO) もサポートしており、これは 特にDPIコードでリンクしている場合。 GCCでLTOを有効にするには コンパイルとリンクの両方に対応しています。 LTO は 大規模な設計にも対応しています。
プロファイル駆動型コンパイラの最適化を使用して、実際の デザインでは、最大 30% の改善が得られます。
独自の makefile を使用している場合は、 -DVL_INLINE_OPT=inline で Verilated コードをコンパイルするとよいでしょう。これは関数をインライン化しますが、すべての cpp ファイルを一回のコンパイラ実行でコンパイルする必要があります。
Verilogコードをプロファイリングすることで、さらなるチューニングの可能性が見えてくるかもしれません。Verilatorの--prof-cfuncsを使用し、GCCの-g -pgを使用してください。 その後、oprofileまたはgprofを実行して、C++コードのどこに時間が費やされているかを確認することができます。gprofの出力をverilator_profcfuncを通して実行すると、Verilogのどの行番号に時間が費やされているかを教えてくれます。
終わったら、作者に結果を知らせてください。 Verilatorがどのように比較されているかを把握したいので、追加の改善点を提案することができるかもしれません。
www.DeepL.com/Translator（無料版）で翻訳しました。
How do I get faster build times?
というのもあった。
こちらも、DeepLで翻訳した。
make を実行するときに make 変数 VM_PARALLEL_BUILDS=1 を渡すと、ビルドが並行して行われるようになります。
最新のコンパイラを使用してください。新しいコンパイラの方が速い傾向にありますが、今は比較的古い GCC 3.0 から 3.3 はひどいです。
ccache, distcc, icecream パッケージについてはウェブを参照してください。Verilator がビルドされたときに ccache がインストールされていた場合はそれが使用されます。また、--output-splitオプションも参照してください。
Verilatedモジュールを使用するクラス(トップCPPファイルなど)のコンパイル時間を短縮するために、トップレベルのモジュールに /*verilator no_inline_module*/ を追加するとよいでしょう。これにより、モデルのVerilatedクラスのコード量が減り、トップレベルのC++コードのインスタンス化のコンパイル時間が改善されますが、実行性能のコストは比較的小さくなります。
www.DeepL.com/Translator（無料版）で翻訳しました。
お、tb_top.sv みたいなコードに、/* verilator no_inline_module */ を追加すればいいのか？
