まごころせいじつ堂 - Verilog

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

hardyboy — 2013-05-09T02:06:18+09:00

追記：@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<結果は以下のとおり。
 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 バレルシフタの記述比較

hardyboy — 2013-05-06T08:08:31+09:00

　前回、メモ：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による速度評価

hardyboy — 2013-05-04T01:31:40+09:00

　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とあり、これが最大動作周波数。

CADR 回路図 SPC MEMORY AND POINTER

hardyboy — 2013-02-26T17:59:23+09:00

CADRマシンの回路図を見ていきます。簡単そうな所から。
http://www.unlambda.com/download/cadr/CADR4_schematic.pdf

49ページは18bit+パリティ、32個のメモリでスタック(SPC)を構成。-WCLKに同期。
SPC POINTERは同期式アップダウンカウンタ 74S159を2個。CLK4Fに同期。
SPC POINTERはパワーオンでは不定だが、ポインタの出力SPCPTR4〜SPCPTR0は読めるのでソフトで初期化しろということだろう。スタックのオーバーフロー/アンダーフローはチェックしないので、ソフトの責任で使用しろと書いてある。

　ところで、TTLのみで96ページもある回路図を読むのはなかなかつらいので、信号の生成元とそれを使っている箇所についてのクロスリファレンスが必要かな。気合が足らんと言われそうだが。

CADRソース調査　メモリについて

hardyboy — 2013-02-22T23:45:59+09:00

CADRマシンの回路図をたよりに中で使われているメモリについて調べた。
Retrocomputing - MIT CADR Lisp Machines

@natsutanさんのブロック図を参照してください。
制御パス
データパス

以下はPROMだけど組み合わせ回路で実現：
part_32x32prom_maskright i_MSKR A[4:0] D[31:0]
part_32x32prom_maskleft i_MSKL A[4:0] D[31:0]
part_32x8prom i_DMASK A[4:0] D[7:0]
part_512x49prom i_PROM0 A[8:0] D[48:0]

このうち512ワードのi_PROM0はデータbit46が欠けている。元々のPROMには[48:47,45:0]の48bitが割り付けられている。74S472×12個。

以下はRAM、caddr.vでのソースではメモリ上のパリティはすでに取り除いてある：
part_32x19ram i_SPC A[4:0] D[18:0]　SPC STACK
元は32x2bit 82S21 ラッチ×10個(パリティ付き)

part_32x32ram i_MMEM A[4:0] D[31:0]　B-MEMORY(M-MEMORY)
元は32x2bit 82S21 ラッチ×17個(パリティ付き)

part_2kx5ram i_VMEM0 A[10:0] D[4:0]　VMAP STAGE0
元はRAM 1k×1bit 93425A×12個

part_1kx24ram i_VMEM1_2 A[9:0] D[23:0] VMAP STAGE1,2
元はRAM 1k×1bit 93425A×25個

part_1kx32ram i_PDL、i_AMEM A[9:0] D[31:0] PDL MEMORY、A-MEMORY
元はRAM 1k×1bit 93425A×33個(パリティ付き)が2セット

part_2kx17ram i_DRAM A[10:0] D[16:0]　DISPATCH MEMORY
元はRAM 1k×1bit 93425A×36個

part_16x49ram i_IRAM A[13:0] D[48:0]　INSTRUCTION MEMORY
元はRAM 4k×1bit IN2147×196個

部品としてのRAMは3種類。うちラッチと書いたものはパススルーができる？
INSTRUCTION MEMORYがいちばん大きい。次いでDISPATCH MEMORYで、このあたりを外に追い出せばいけるか。VMAP関連についてはSTAGE0,1,2とcaddr.vソースとの対応付けが今のところはっきりしない。(CADRマシンの前身、CONSマシンのブロック図を参照しているのでその違いかもしれない)

SPC STACK、B-MEMORYのみ中身があるものにしてDE0(CycloneIII EP3C16F484C6)ターゲットで合成してみたら約１時間で4,229/15,408LE (27%)だった。まだ行けそうね。

QuartusIIでCADRのソースをコンパイル　２

hardyboy — 2013-02-22T02:18:18+09:00

QuartusIIでCADRのソースをコンパイル　続き
i_DRAMの中身をカラ(reg 宣言を削りassign DO=DI; とする)にして再度コンパイルしてみた今回は５時間を越えてどんどん進むが停まる気配がない。１０時間で打ち切り、すべてのRAMについて同様に中身をカラにしてみた。どうもreg宣言ばかりで明にRAMに割り当てていないようで、これがLE数を消費する原因と思われた。
結果は以下のとおり。

Flow Status Successful - Fri Feb 22 01:17:37 2013

Quartus II 64-Bit Version 12.1 Build 177 11/07/2012 SJ Web Edition

Revision Name caddr

Top-level Entity Name caddr

Family Cyclone IV GX

Device EP4CGX150DF31I7AD

Timing Models Final

Total logic elements 2,929 / 149,760 ( 2 % )

Total combinational functions 2,860 / 149,760 ( 2 % )

Dedicated logic registers 471 / 149,760 ( < 1 % )

Total registers 471

Total pins 27 / 508 ( 5 % )

Total virtual pins 0

Total memory bits 0 / 6,635,520 ( 0 % )

Embedded Multiplier 9-bit elements 0 / 720 ( 0 % )

Total GXB Receiver Channel PCS 0 / 8 ( 0 % )

Total GXB Receiver Channel PMA 0 / 8 ( 0 % )

Total GXB Transmitter Channel PCS 0 / 8 ( 0 % )

Total GXB Transmitter Channel PMA 0 / 8 ( 0 % )

Total PLLs 0 / 8 ( 0 % )

　2929LEですと？ちょっと少なすぎるみたいだけどもここからRAMを盛っていく。
i_DRAM については外付けのDRAMと勘違いしていたのだがDispatchRAMで17bit幅☓11bitアドレスのStaticRAMだった。主記憶はCADRマシンの外にある。caddrではすでにパリティ用の1bitについては削減してあった。
　あとはクロック周り。osc50mhzを外部からの入力として、以下の接続。
osc50mhz--＞○--osc0--＞○--hifreq1,hifreq2--＞○--hfdlyd--＞○--hftomm(未使用)
hifreq1,hifreq2は実質同じ、hfdlydはさらに位相の遅れたクロックのつもり。
これらを元にディレイラインで30ns,70nsの遅れを作りRAMのサイクル用などに使っている。
また、NAND2個のたすきがけで制御を行なっている場所が５箇所あり、図面のCLOCK DISTRIBUSIONとMASTER CLOCKはPLLを使用したクロック制御モジュールとして起こしてやらなければならないだろう。これに合わせて非同期SRAM部分も合わせるか。

QuartusIIでCADRのソースをコンパイル

hardyboy — 2013-02-21T00:23:21+09:00

LISPマシンCADRの回路図とVerilog-HDLに変換されたソースリストを見て、これ今のFPGAに収まりそうじゃないかなと思って試しにコンパイルしてみた。もともとはすべてTTLで構成されていて、それをそのままVerilogの記述に変換したものと、きちんと書きなおされたものがある。後者はCADDR Reviced CADR Verilogとして公開されているのでこちらを使った。
Retrocomputing - MIT CADR Lisp Machines
　すでに@natsutanさんが三年前に試されているけど、最近のはどうかな？
[Lisp][Verilog][FPGA]cadrのVerilogソースのコンパイルその1

環境：Windows7 PRIMERGY TX100S1(Core2Quad 2.67GHzに差し替えたもの)
QuartusII 12.1 Build 177 64-bit

新規プロジェクトを作成し、ターゲットデバイスを一番LE数の大きそうなものにする。今回はCycloneIV GXにした。制約条件などのオプション指定はなにもなし。コンパイルにかかった時間は4時間23分、結果はFittingに失敗(113%)、LE数は169,005と出た。

Flow Status Flow Failed - Wed Feb 20 18:15:59 2013
Quartus II 64-Bit Version 12.1 Build 177 11/07/2012 SJ Web Edition
Revision Name caddr
Top-level Entity Name caddr
Family Cyclone IV GX
Device EP4CGX150DF31I7AD
Timing Models Final
Total logic elements 169,055 / 149,760 ( 113 % )
Total combinational functions 109,428 / 149,760 ( 73 % )
Dedicated logic registers 136,714 / 149,760 ( 91 % )
Total registers 136714
Total pins 27 / 508 ( 5 % )
Total virtual pins 0
Total memory bits 787,040 / 6,635,520 ( 12 % )
Embedded Multiplier 9-bit elements 0 / 720 ( 0 % )
Total GXB Receiver Channel PCS 0 / 8 ( 0 % )
Total GXB Receiver Channel PMA 0 / 8 ( 0 % )
Total GXB Transmitter Channel PCS 0 / 8 ( 0 % )
Total GXB Transmitter Channel PMA 0 / 8 ( 0 % )
Total PLLs 0 / 8 ( 0 % )

ソースは以下の修正が必要。

・caddr.v 74181.v 74182.v busint.v memory.v rom.v を新規ファイルとしてプロジェクトに追加。（New Files... でVerilog-HDLを指定してコピペ）　lm2clock.vは多分いらない。

・caddr.vのソース修正 `includeをすべてコメントアウト。プロジェクト内のモジュールを多重に読み込むことになるので。
・memory.vのソース修正　initial begin~end部分をコメントアウト。
・busint.vのソース修正　initial begin~end部分をコメントアウトし、always@(posedge clk)部分とalways@(rst_n)部分をalways@(posedge clk or negedge rst_n)として合体させる。

　あとはメモリを外に出す、caddr.vが大きすぎるのである程度のモジュールに分割し面積を減らせるか検討。特にパリティ回路はまるっと削除しても問題なさそう。あとはALUをまとめてしまう、など。