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

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


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

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

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

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

SV32 SV6432 SV6464
OS 32bit/64bit(WOW64) 64bit Only 64bit Only
GUI 32bit 64bit 64bit
Compiler/SimEngine 32bit 32bit(WOW64) 64bit
User Address Space for GUI(Waveform Processing) 2GB 8TB 8TB
User Address Space for Compiler/SimEngine 2GB 4GB 8TB(408A-)
Current Supporting Status
VPI Yes Yes Yes(409A-)
DPI Yes Yes Yes(409A-)
SystemC Yes Yes No
GUI MultiThreading Yes Yes Yes
StateSave Yes Yes Yes(407A-)
SimEngine MultiThreading No No will be supported in future.
Development MainStream * ** ***
Sim Speed 10% Slower(currently)
SV support Very little.
foreach/assignment_pattern/string/
dynamic array/queue/assignment operators/
associative/$unraom/$urandom_range array partially
<- <-(409A-)

So, What’s Great?

World fastest 64bit native code simulator in Windows




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

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

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

4. ベンチマーク結果

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

item シミュレータ 波形なし 波形有り(全波形) OS Machine Remarks
A) ModelSim XE 6.5C 1時間6分 3時間57分 32bit Vista 8GB RAM Q9550 (4CPU) Xilinx EditionでStarterではありません
B) VeritakSV6464-4.09A 5分6秒 7分4秒 64bit Windows7 16GB RAM Athlon2 X2 (2CPU) α version
A/B= 13x 46x

32ビット/WOW64/64bit 環境、CPUによる速度の違いについて(参考)

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

考察


結論