DWM付録FPGA基板でトラ技PICとROMの推論の続きになります。
前回は、トラ技12月号のPIC12F508をDWM付録のSpartan-3E基板に載せました。
ROMは組み合わせ回路でしたが、せっかくSpartan-3Eに載せるのでブロックRAMにしたいものです。一応成功したのでご報告です。
トラ技12月号のRTLは、2段のパイプラインになっています。命令フェッチと解釈実行の2つです。ジャンプ命令やサブルーチンコールの直後の命令は実行しないような制御を行っています(p.111参照)。
制御はcmdClrという信号です。この信号があるクロックのときにHだと次のクロックの命令はNOPとして扱われます。図だと命令2がジャンプ命令なので、次の命令3は実行されず、さらに次のクロックで飛び先の命令10が実行されます。
どんな回路になっているかを簡単な図にしてみました。
現在のcmdをデコードした結果としてのcmdClrによって次のクロックで実行される命令がメモリから読み出したものになるかNOPになるかが決まります。
Spartan-3EのブロックRAMはFF出力なので、アドレスを出した次のクロックにデータが読めます。上の図のままだと、cmdもFF出力なので1命令1クロックでなく2クロックになってしまいます。
そこで、以下のように回路を変えてみました。
ブロックRAMにできるようにメモリの出力にFFを移動しました。1命令1クロック動作できるように、cmdは組み合わせ回路の出力にしました。つじつまを合わせるためにcmdClrをFF出力にすることで、1クロック遅れにしました。
タイミングチャートは元のものと似ていますがcmdClrが1クロック遅れになっていて、現在実行している命令をNOPにするのかどうかになっています。
変更したRTLは、かなりぐちゃぐちゃになっているので載せません。
合成結果は、回路規模 260slice (前回295slice)、動作周波数 64.291MHz (前回59.291MHz)になりました。ブロックRAMを使っているので、プログラムサイズが大きくなってもslice数は増えません。DWM付録基板のSpartan-3E xc3s250eにはブロックRAMが12個載っているので、最大24kバイトまでROMを増やせることになります。
前回は、トラ技12月号のPIC12F508をDWM付録のSpartan-3E基板に載せました。
ROMは組み合わせ回路でしたが、せっかくSpartan-3Eに載せるのでブロックRAMにしたいものです。一応成功したのでご報告です。
トラ技12月号のRTLは、2段のパイプラインになっています。命令フェッチと解釈実行の2つです。ジャンプ命令やサブルーチンコールの直後の命令は実行しないような制御を行っています(p.111参照)。
制御はcmdClrという信号です。この信号があるクロックのときにHだと次のクロックの命令はNOPとして扱われます。図だと命令2がジャンプ命令なので、次の命令3は実行されず、さらに次のクロックで飛び先の命令10が実行されます。
どんな回路になっているかを簡単な図にしてみました。
現在のcmdをデコードした結果としてのcmdClrによって次のクロックで実行される命令がメモリから読み出したものになるかNOPになるかが決まります。
Spartan-3EのブロックRAMはFF出力なので、アドレスを出した次のクロックにデータが読めます。上の図のままだと、cmdもFF出力なので1命令1クロックでなく2クロックになってしまいます。
そこで、以下のように回路を変えてみました。
ブロックRAMにできるようにメモリの出力にFFを移動しました。1命令1クロック動作できるように、cmdは組み合わせ回路の出力にしました。つじつまを合わせるためにcmdClrをFF出力にすることで、1クロック遅れにしました。
タイミングチャートは元のものと似ていますがcmdClrが1クロック遅れになっていて、現在実行している命令をNOPにするのかどうかになっています。
変更したRTLは、かなりぐちゃぐちゃになっているので載せません。
合成結果は、回路規模 260slice (前回295slice)、動作周波数 64.291MHz (前回59.291MHz)になりました。ブロックRAMを使っているので、プログラムサイズが大きくなってもslice数は増えません。DWM付録基板のSpartan-3E xc3s250eにはブロックRAMが12個載っているので、最大24kバイトまでROMを増やせることになります。
FFをBRAM側に移動したんですね。MUXの片方がNOPで固定値なので、こちら側にはFFは必要ないですからFFも増えないですね。
動作周波数もうまくBRAMを使うことが出来たので上がって、良かったです。
そのうち、私も、simさんの猿まねで、載せてみるかも。
オリジナルの方は、「メモリ」の前にアドレスを出力する「FF」があって、この「FF」の出力から「メモリ」「MUX」「FF」までの経路がクリティカルパスになると思います。「メモリ(ROM)」というのは実際には巨大なデコーダなので、時間的に相当厳しいと思います。
改造版の方は、「BRAM」または「cmdClr」の「FF」出力から「MUX」「decode」「FF」までの経路がクリティカルパスになるはずです。「decode」を「BRAM」の限界まで最適化できたら、もっと速く出来ますね。
おかげさまでなんとかなりました。
微妙に性能があがってるっぽいのはよかったです。前回のコメントをいただいて自分なりに整理して返事を書いたのが、よかったのだと思います。
ええ、ぜひともトライしてみてください。できあがってもLEDチカチカくらいですが、それはそれで楽しいです。
速度的にも回路規模的にもブロックRAM化はぜひともやってみたかったです。
static timing reportを見てみるとブロックRAMからcmdClrのFFがクリティカルになっていました。さらに速くするなら、パイプラインを多段化するんでしょうね。
260/2448sliceなので、まだまだ拡張できそうです。