自作CPUで遊ぶ 8

前回のデザインをベースにしてCPUをMicroBlazeに変えてzumi32版との違いを色々と見てみた。MicroBlazeの設定はzumi32と同等にするために乗算器等は入れずにBarrel Shifterのみとした。

このデザインでImplementしUtilizationを見てみた。MicroBlazeの部分はSlice LUTsが1053だった。これに対してzumi32は1066と同程度の規模だった。但し、規模は同程度だが内訳はかなり違う。レジスタ数は770(MicroBlaze)に対して512(zumi32)。LUT as Logicは851(MicroBlaze)に対して1022(zumi32)。LUT as Memoryは7(MicroBlaze)に対して0(zumi32)。zumi32はF/Fをあまり使っていない。これが動作速度を上げられない要因なのかも知れない。

次に前回と同等のプログラムをMicroBlazeに実装し、生成されるコードの規模や処理速度を見てみた。コンパイルされたelfのtext、data、bssのサイズはそれぞれ 1588、276、3112だった。 これに対して、zumi32はLinkerが出力したmapファイルから各セグメントのサイズを見ると、textが0x284 (644)、dataが0xc (12)、bssが0 とかなり違う。textは約1KByteもの開きがある。最適化オプションは何れも-O2にしている。

MicroBlazeのelfを逆アセンブルしてmain()の部分を見てみた。命令数は31なのでかなりコンパクトだ。これで何故text sizeが1.588Kバイトになるのか謎だが、もしかするとstartup部や例外処理などのコードが大きいのかも知れない。 1KByteは１命令32bitなので命令数にして256命令分。。小規模なFPGAにCPUを実装する場合等は結構厳しいサイズかも知れない。

一方、zumi32をコンパイルして得られたアセンブラは以下のようだった。命令数が38もあるが、while loopの部分のみを抜き出してMicroBlazeのコードど比較すると以下のようだった。

zumi32の命令数が多いのは命令セットの違いもあるが、gccをzumi32にportingした時の私の工夫が足りていないのが要因だろう。 zumi32は遅延分岐があるが遅延スロット部をnopで埋めている。最適化の部分をもっと工夫すればMicroBlazeと同等にはなる筈だ。ちなみに手動で最適化すると命令数は14まで削減できる。

次に、それぞれのデザインとプログラムでXsimでsimulationしてwhile loopを１回実行する時間を見てみた。zumi32のプログラムはgccでコンパイルしたコードをそのまま使った。 上がzumi32、下がMicroBlazeの波形だ。MicroBlazeが11.37usecに対してzumi32は18.31usecと1.6倍も遅い。上で見たとおり命令数の差はあるが19:22なので1.15倍程度の差でしかない。したがって遅い要因は命令数の差だけでは無い。

速度を遅くしている要因はload命令のlatencyと分岐時のfetch unitとexecution unit間のlatencyにあった。そこでそれらを修正し、且つzumi32のコードを手動最適化したコードに入れ替えて再度simulationをしてみた。 その結果、while loop１回の処理時間は10.1 usecまで短縮することが出来た。

MicroBlazeより約12%速くなった。但し、手動で最適化したコードを使った場合なので現状のgccを使い続ける限りはMicroBlazeと同等になるんじゃないかな？と思う。 

前向きに捉えるとzumi32-gccにはまだまだ伸びしろがある。！！！ってことだが。。。これを改善するのは大変なんだよな。 portingに数年を要したからなー。

まぁ・・・、でも 最小構成とは言えベンダー製のCPUの性能にかなり近づけているというのは嬉しいことではある。