next theme

ぐはぁ、、
不覚にもインフルエンザに感染してしまった。。
体温は39度近くはなるは、目の奥はガンガン痛いは、吐き気はするはで散々だ。

さて、高速版DDR2Cも形にはなったので次のテーマに進むことにした。
次は32bit CPUの作成だ。
このCPUはRISC型でHarvard architecture、pipelineは3段だ。

このCPUにかっこいい名前を付けようと思ったのだが、安易なものだと既存のどれかとかぶりそうな気がしたので zumi32 にした。

命令一覧は次のとおりだ。体調が悪いので今日はここまで。

高速版のDRAMCを公開した。

高速版のDRAMCと環境一式をここに置いた。
hs_ddr2c_20110120.tbz
(md5sum 545444b58a31e2db59acb1e8049c9326)


・文章を書くのが得意で無いので詳細な説明等は付けていません。
（時間が出来たら後で付け足すかも知れません。）

・詳細はソースを読んで下さい。
・まだ十分な動作確認が出来ている訳では無いので、

バグっている可能性や動作が不安定になる可能性はあります。

参考程度にRTLを眺めるくらいがいいかも知れません。

実機DEBUG8

cifを改造してoneshotで動作するようにした。具体的にはUART経由でtrigger用registerに1を書き込むと、直後の1 frameのみをDDR2に取り込む。

←が取り込んだ画像だ。画像のズレは最初から起きている訳ではなく、徐々に起きていることが判った。また、640x480の領域からははみ出していないので、addressの異常ではなくてやはりdataのfifo側の制御に問題があることが伺える。何かのきっかけでfifoの読み出しが途切れてfifoにdataが残り、それが次の書込み時に読み出されるため画像がずれていっているように思える。mpif (multi port i/f)とDRAMCのdata fifo、command fifo (address系）との間はhandshakeはややこしくなっており、想定出来ていないtimingで辻褄が合わなくなっていたようだ。そこでこの部分をsimpleな回路に変更した。具体的には read/writeに関わらずdata fifoにもcommand fifoにもqueueingを行い、readの場合はdata fifoのdataを読み捨てるようにした。

その結果、ずれは無くなった。

連続取り込みに戻しても問題無し。

やったー！！　\(^o^)/

ばんざ～い！！

あがぃ、ぷからっさー　

苦節１ヶ月、途中断念しようかと思ったことも何回かあったけど、諦めないでよかった。

うれぴー

もちろんtimingは全てMetしている。

配置制約は特にかけていない。
Timing系も周波数と非同期部のTIG制約位だ。

回路規模はdata bus幅が128bitになった関係で、以前の133MHz版よりも増大してしまった。Number of occupied Slicesで比較すると1.6倍だ。BRAMの使用数は3から12と4倍になった。

実機DEBUG 7

lbuf (line buffer)をXGA(1024x768)の領域を処理できるように変更し、1024x768の大きさの画像をDDR2にUART経由で書いて表示させた。

美しい！！

これでcif からの画像のズレがなければ最高なんだが。。これまで調べてきた結果では、cif自体には問題なさそうで、DRAMC内部のwrite data 用 fifoの周辺が怪しそうなんだが、UARTからの書込みだと上手くいって、cifからの書込みだと駄目だということは、burst書込みの時に不具合があるのかな。。。
うーむ、判らん。

実機DEBUG 6

cameraからの画像がズレる問題はまだ原因が判らない。
試しに、UART経由で画像をDDR2に書いて表示させてみた。

UART経由だとズレないんだよなぁー。
勿論DDR2は240MHz動作だ。

いつも殺風景な部屋の画像だったので今回のような画像が表示されると、何だか気持ちが高揚するな。でも、まだ成功とは言えない。
ここんところ気持ちはワクワクしながらずっと焦らされまくっている気がして、いや～んってな感じだ。

実機DEBUG 5

timing errorは潰せて、240MHzでMetするようになり、妙な縦線が表示されることはなくなったのだが、表示位置がおかしい。。あははは・・・、いや、その可笑しいじゃなくて。と、たまにはボケてみたりして。

UART経由で画像の左上に相当する番地にdataを書き込むとちゃんと左上に表示されるので、dramcやlbuf (line buffer)の問題ではなく、cif (camera i/f)側の問題のようだが、これがまたよく判らん。

論理simulationでは異常はない。

もう一息、だと思うんだけどな。

実機DEBUG 4

240MHzでもそれなりの画が表示できるようになってきた。

縦線が5本出ているのは多分camera i/fからの書込みの経路のどこかにまだbugがあるんだろうと思うが、これが中々尻尾が掴めない。

timing もまだ、3項目がmetしていない。

が、それでも結構動いてしまうものだ。

私のへなちょこ設計のため、timingがまだすべてmetできていないが、ここまで動作しているのでSpartan3Aで240MHzで動作するDRAMCは作れると判断してもいいだろうなと思う。

当初目標としていた260MHzは現状のDCMの使い方だと実現できないことが判ったが、例えば前段のDCMで130MHzをつくり、後段のDCMでこれを2倍して260MHzをつくるなどすれば、capture clockの位相調整の粒度は粗くなってしまうが、260MHzは作れると思う。

でも、実感としては安定に動作させることを考えると240MHz程度が上限のような気がする。

実機DEBUG 3

BUGも結構潰せてきて、低周波数ではそれなりの画が表示できるようになってきた。

←は150MHz動作時の出力画像だ。
表示開始位置がずれてしまっているが、画像自体は正常だ。（133MHzでは開始位置も正常になる。）

しかし、今回の設計はbugだらけだ。
上の空でcodingしたのか？→俺
でも、得るものも多々あった。

１にFIFO、2にFIFO、3,4が無くて5にFIFO。
FIFOを征するものはFPGAを征すといった感じか。。

そして←が200MHz動作時の画だ。

現状、timingがmetしていない項目が2項目程ある。これをmetするようにして、表示timingを見直せば200MHz超もいけそうな気がしてきた。

あくまで、気だけど。