バレルシフタ ２段にして改善(お詫び 大きな間違いあり)

追記：@ikwzmさんから。https://gist.github.com/ikwzm/5558633　
バイト単位でシフトすべきところを4bit単位でやってました。あああ
ご指摘ありがとうございました。

※前段の 8byteシフト間違ってる気がしてきた。多分3bit分を<<5した時点ですべて'0'になってしまってるはず

(1)組み合わせ回路のシフトについて、下xx bitを削っていくような間違いをしていました。書きなおしたのは以下。
https://gist.github.com/houmei/5555418

(2)＜＜演算子を使ったbyte shiftは、いったん幅[6:0]の下位3bitを'000'とし、上位にシフト量を入れることで書き直しました。

比較結果：
349LE/214.92MHz (Megafunction)

343LE/214.55MHz (シフト演算子)

291LE/335.46MHz (組み合わせ回路)

ただし、組み合わせ回路によるものは(1)の間違いあり。

反省：見積もりに検証していない回路を軽い気持ちで使うと大失敗

以下は間違いありです。

　扱うbit幅が大きくなるとLE数は増え動作周波数は落ちていくバレルシフタ。ここでシフト量を制限したらどうなるか傾向を見てみた。例えば1bitシフトする/しないだけなら大幅にセレクタ数が減るはず。
以下の様なコードでシフト量を1,2,4,8...と変えながら試してみる。上位モジュールからは
sll64_partial #6 SLL(source,value,sftout); // partial shift
の様に呼び出す。

module sll64_partial (indata,val,outdata);
	parameter width=6; //[6:0]
	input [63:0] indata;
	input [width:0] val;
	output [63:0] outdata;
	assign outdata=indata<<val;
endmodule

結果は以下のとおり。
 64bitを部分シフト

[0:0] 129LE/615.38MHz

[1:0] 136LE/413.56MHz

[2:0] 143LE/357.65MHz

[3:0] 210LE/270.71MHz

[4:0] 285LE/250.38MHz

[5:0] 384LE/223.31MHz

[6:0] 390LE/220.17MHz

では、最初にバイト単位でシフトして次にビット単位で8つまでシフトするようにしてみる。
シフト量のnnnnxxxのうち、nnnnはバイトでのシフト量、xxxはビットのシフト量とする。nnnnについてはシフトする量がデータ幅をあふれたらall0とする。


ソースはこちら：https://gist.github.com/houmei/5541783 

コンパイル結果は207LE/284.41MHzとなった。組み合わせ回路でべたに書いた283LE/105.06MHzよりよい。

※以下も怪しい
　もし、もっと追求するとしたらbit幅の組み合わせを変える(4-3を3-4)、段数を増やす(2-2-3)、一部組み合わせ回路にしてみる、など。やりだすときりがなくなるけど構造的な改善である程度の性能が出たらしばらく放置して他に着手したほうがいいかも。

　あと、QuartusIIにはMagawizard Plugin Managerというのがあって、用途に合わせたライブラリが使える。今回の用途にはGates→LPMCLSHIFTというのが使えた。verilogやVHDLのインターフェース部分がソースとして出力されるのでこれを呼び出して使用する。

QuartusII 12.1 バレルシフタの記述比較

　前回、メモ：QuartusII 12.1 バレルシフタの記述とTimeQuestによる速度評価の続き。

　バレルシフタの入力、出力を64bitとすると、シフト量は0～64になる。つまりシフト量の指定に6bit＋1必要。これらをfunction文による自前の組み合わせ回路と＜＜演算子による記述で比較してみた。

ソースはこちら：https://gist.github.com/houmei/5522404 

　function文によるRTLはこのようになる。(8bit幅)
 
　コンパイル結果は以下。27LEで3段。



　＜＜演算子によるRTLはこんな表示。


　コンパイル結果。32LE4段。



　このような感じで4～64bitまでの組み合わせ回路によるバレルシフタと演算子によるバレルシフタについて、LE数と動作周波数で比較した。
 

　横軸は4,8,16,24,32,48,64が等間隔に並んでいるのに注意。組み合わせ回路はLE数が少なくて済むが、8～16bitのあたりで速度が逆転する。これを配置配線後の回路でみると、こうなっている。

組み合わせ回路によるもの：


＜＜演算子によるもの：

　＜＜演算子でコンパイラに任せたほうが、LEがまんべんなく散らばっているようにみえる。LE自体のディレイよりも配線のディレイが大きいように思える。
16bitくらいの大きさまでなら組み合わせ回路で手書きしたほうがいいが、回路をケチる必要がなければコンパイラに任せたほうがいい。


　＜＜の演算子で書くならparameter文で指示したら良さそうと思うでしょう？実験した。上位モジュールからは
 sllp #(63) SLL(source,value,sftout);
の様に書いてparameter文を使ったsllp.vを呼び出すようにコンパイルしてみる。すると、24bitで以下の様な結果となった。 
24bitでの＜＜演算子 / parameter文によるもの
128LE,295.33MHz / 133LE,280.74MHz

　bit幅によってはまったく同じではないことがあり得る。なんでわざわざこれを試したかというと、20年くらい前に論理合成ツールを使った時に怪しい挙動を経験したため。なので、ギチギチに詰める必要がある場合はいろいろ疑ってみたほうがいいかもしれない。

追記：@ikwzmさんにfor文を使った書き方を教えてもらいました。https://gist.github.com/ikwzm/5523178　398LE/199.76MHz
ちょっと8byteシフト＆8bitシフトの組み合わせで64biシフタを構成したら210LE/310.95MHz

メモ：QuartusII 12.1 バレルシフタの記述とTimeQuestによる速度評価

　ALTERAのFPGA開発環境 QuartusII 12.1、Verilog HDLでバレルシフタを記述し、組み合わせ回路の動作速度をQuartusIIの機能であるTimeQuestで計ってみた。ターゲットはCycloneIII EP3C16F484C6(Terasic DE0)。I/Oのアサインはせずコンパイルのみ。

　バレルシフタは組み合わせ回路なので、最初はI/Oから入出力をとってそのまま接続していた。しかしこれではTimeQuestで評価されない。前後をFFではさむとfmaxが計算された。
 


　これに気づいたのはTimeQuestによるタイミング解析を学ぶ (1/3) 、FPGAの動作スピードを改善するポイントとは？ (1/2)を読んでから。ディレイ計算はゲートの出力側から入力側に向けて積算して求めるものと思っていた。

ソースはこちら：https://gist.github.com/houmei/5510474　

　コンパイル後、[Tools]→[Netlist Viewers]以下のツールで回路を見ることができる。
→[RTL Viewer]でRTLの、→[Technology Map Viewer(Post-Fitting)]で配置配線後の回路を表示する。

[RTL Viewer]
 

[Technology Map Viewer(Post-Fitting)]


　Compilation ReportのTimeQuest Timing Analyzerの項目に最大動作周波数が載っている。ここのSlow 1200mV 85C Modelを開く(電圧が低く、温度が高い方が厳しい条件となる)。 ここのFmax Summaryを見ると712.76MHzとあり、これが最大動作周波数。