64ビット　Verilog　HDLシミュレータ

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　Apr.11.2012　菅原＠菅原システムズ


１．64ビット化のメリット

1.1 巨大な波形観測が容易に　　
　　メモリを多く積むことによって巨大な波形でも、ストレスなく見れる可能性が高まります。32ビットOS下にあってもシミュレータは、仮想64ビットファイルに波形を出力するので、32ビット4GBの制限はありません。しかしながら、仮に16GB　RAMを積んでいたとしても32ビットOS下では、折角あるメモリが活用されません。結果として、ディスクアクセスがボトルネックになってしまいます。この場合、大幅なシミュレーション速度低下と波形観測のストレスをもたらす結果となるでしょう。
　DDR3を16GB積んでも6000円程度で組める時代になりましたので、費用対効果は、非常に大きいと思います。

1.2　コンパイラの規模制限がなくなる
　一般に、記述のレベルが下になればなるほど（RTL->GATE->SDF付ゲート）、コンパイルにおけるメモリ所要は、大きくなります。コンパイル済みのオブジェクトを生成するのに、時に数倍から数十倍のコンパイルの為のメモリが必要になります。このような状況下においては、生成されるオブジェクトが32ビット空間内に収まるにしても、32ビットシステムではメモリが足りずにコンパイルできない事態が生じていました。64ビットシステムでは、メモリ不足による規模制限がなくなります。


1.3 巨大な配列が記述できる
　　32ビットシステム下では、記述不能な、例えば、32ビットシステムそのものが、記述可能になります。

module large_mem;
	parameter longint MSB=34'h20000_0000;//2*4=8GB 
	byte mem [0:MSB-1];//8GB memory
 
	 initial begin
		 for (longint i=0;i< MSB;i++) begin
　　 			mem[i]=i;
			  if (mem[i] !==(i &8'hff))begin
　　　				$stop;
			  end
    end
   end
endmodule

2. 64ビット化のデメリット
2.1　SIM速度
　64ビット化にそのものによるSIM速度向上は、あまり期待できません..というよりむしろ低下傾向にあります。これは、ポインタのサイズが単純に倍になるために、コード及びデータの所要が増大し、結果としてキャッシュヒット率が下がることによるものです。
（これに対する解決例として、クロスコンパイルによる方法が提案されています。http://www.synopsys.co.jp/products/technology/vcs/cross_compile_tb.html）
X86からX64においては、レジスタ数の64ビット化及びレジスタ数増大により、最適化手法により向上の余地がありますが、それにしても高々10%-20%程度と推察され、ヒット率の低下の影響の方が大きい場合もあると考えます。

2.2　VPI/DPI/SｙｓtemC過去の環境資産の再コンパイルが必要
　当然ながら、32ビットでコンパイルした過去のライブラリは、バイナリ互換ではありませんので、ソースから64ビット環境で再コンパイルしなければなりません。
64ビットシステムでは、DLLのバイナリ互換は全くありませんので、VC++/GCCコンパイラは、シミュレータの指定に合わせて用意する必要があります。環境を構築するのも面倒です。
VC++の場合、32ビットでは、無償版のExpressEditionが使用できたのですが、64ビット版は、SDKをインストールしないと使えません。(また、最近のupdateでSDKをインストールしていても使えなくなったという報告もあります。)

2.3　誤って記述してもコンパイラが落ちないので、解析に手間どる
　1.3の記述は、32ビットシステムでは、すぐに落ちますが、64ビットシステムでは、値を間違えても多分落ちてくれません。仮想メモリが頑張ってしまいますので、無駄にコンパイル時間が長いという結果になる可能性があります。

３．VeritakSVにおける解決策
３．１　ユーザ環境に応じて、下記のリリースをどれでも使用可能

　上の状況に鑑み、次の3種類をリリースしています。

３．２　SimEngineとWaveformProcessingがマルチプロセス
　　波形処理とSimEngine処理は、別プロセスで並列に動きます。DualCPU以上では、波形処理による速度低下を最小にします。

３．３　高速なNative　Code
　VirtualMachineや、Cコンパイラではなく、高速なNativeCodeを生成しています。

３．4．Sim速度低下のないNative　Debugger搭載
　Native　Codeに対応したデバッガを搭載していますので、デバッグモードは存在せず、フル速度で常にデバッグ可能です。

4. ベンチマーク結果

Opencores　よりfpu　を使用。　シミュレーションstart から$finishまでの走行時間を計測

　http://japanese.sugawara-systems.com/systemverilog/benchmark_report_english2.htm

考察

• マシンが違うので、正確な比較ではありません。
• 波形追加による速度低下について、A)Modelsim 32ビットで4倍近く速度がダウンしているのに対して、VeritakSV6464では、50%の劣化で済んでいます。波形プロセシングとシミュレーション処理をマルチプロセスで並列に行っている効果も見逃すことはできませんが、勿論、64ビットシステム-16GBメモリの効果が主たる原因です。
• ModelSimが生成したwlfファイルは、20GB程度でした。SV6464でも同程度のメモリを消費していると思われます。システムの実装容量16GBを超えています。SV6464走行中、task manager を見ていると、およそ14.5GB付近で、メモリ割付は、飽和しています。足りなかった物理メモリは、結局、ディスクアクセスにより補完されるので、仮想メモリによるアクセス低下を防ぐには、物理メモリをより多く積むことが必要となります。

• WOW64により32ビットアプリケーションも64windows上で、走ります(WOW64)が、やはり32ビットの制限を受けてしまいます。(現行のVeritakも同様）　64ビットアプリとして開発されたものでないと上記の効果を得ることはできません。