実機DEBUG 2

今回、MULITPORT I/FとCLIENT MODULE間のData幅も128bitに変更したため、
cif (camera i/f)とlif (line buffer)、mpif (multi port i/f)も変更したのだが、
大分bugを作り込んでしまった。
これらを修正して何とか画らしいものが表示されるようになった。

←は240MHzで動作させている。
（capture clockの位相合わせは出来ている。）

正常に表示されていないが、周波数を133MHzに下げても同様の画像になるので、まだbugがあるようだ。これらを潰してからでないと240MHzでの可否判断は出来ない。

実機DEBUG

実機DEBUGを始めた。

全体構成はこれまでと同様で、TCM8230MDの撮像dataをDDR2 SDRAM経由でDVIに出力しているのだが、まずはお約束（？）の砂嵐画面だった。。。orz
Cameraの前で手を振ると、表示も変化するので何某かの読み書きは出来ている風だ。

仮合成

RTLがほぼ出来上がったので仮合成をしてみた。が、250MHzではtimingがmetしない。また、setupやhold error以外でcomponent switching limit errorというのが出る。こんなerror始めて見る。

XilinxのAnswersで調べてみてAR #32109を見つけたが、何だかよく判らん。辛うじてtoolの次のmajor releaseでは修正されるらしいことが判った。また丁度ISE12.4がReleaseされたので早速入手して12.4で合成してみたが、結果は同じだった。

250MHzでは駄目っぽいので240MHzにして合成してみたら、こちらはmetした。

240MHzでは動作させられる可能性があるということか。。。 ムフッ 楽しみだ。

高速版DDR2 SDRAM CONTROLLER

以前のDRAMCは133MHz駆動がやっとという状態だったが、これはSpartan3Aの限界ではなく自分の設計能力の問題だと思う。DRAMCのdebugも落ち着いてきた頃、dvi_encのTMDS serdesの部分は325MHzで動作できており、DRAMCもdvi_encの方式のようにすればもっと高速に動作するものが作れるのではないかという考えが、ふと、浮かんできた。そこで、260MHzで動作するDRAMCの作成に挑戦してみることにした。
深く考えてなくて、思いつきだけで進めているので最終的に失敗する可能性もあるのだが。。
今回作成する高速版のDRAMCは←のような構造にしようと考えている。（冒頭で260MHzと書いたがDCMのCLKINの上限が250MHzの為250MHzに変更している。ただし前段のDCMで50MHzを100MHzに逓倍し後段で100MHzを260MHzにという具合にして260MHzを生成する手段はあると思う。）


以前のDRAMCはCMD QUEUE, WDT QUEUEが境界でそこでclockの載替えを行っていたが今回はPHYの入り口で載替えを行う。tRPやtRFC等のtimingはBC, CPがbf_clk基準で生成・管理する。
133MHz版のDRAMCはBC, CPは133MHz domainに属していたので合成でtimingをmetさせるのに大変だったが、今回は62.5MHzとなるので前回よりはmetしやすくなるだろう。また、他にも利点がある。それはtRP, tRRD, tWTR、…といった時間制約が62.5MHzの１周期以下なので旧版の様にstate machineの遷移を抑止するflagやtimer counterが不要になるという点だ。そのため、BC、CPの構造が旧版に比べて単純化できた。
PHYも構造は単純だ。←はPHY_CPのRTLだ。AsyncFIFOが非emptyになったらreadしてdataをcmd F/Fに転送する。AsyncFIFOがemptyの場合はNOP_CMDをcmd F/Fに転送する。NOP_CMDはCS=L, CKE=L, RAS=H, CAS=H, WE=Hの状態だ。

PHYのdata pathの部分もCP程ではないにしてもやはり構造は単純だ。RTLだと行数が多いの構造図を示す。←はwrite系だ。
ODTはDQの2 clock前に出さなければならないため、pipelineを2段入れてDQ, DM, DQSの方を遅らせている。

←はread系だ。

単発のwriteのsimulation結果
今回、DDR2 SDRAMは8burstに設定する。

※. じつは、このaccessは下の連続writeの次のaccessでDRAMのpageは既にopen状態のため、ACTIVE commandは発行されていない。旧版もそうだが設計しているDRAMCはopen policyで作っており一度row pageをopen (activeにする）と、異なるrow addressへのaccess要求かrefresh要求または上位(multiport i/f)からのclose要求が発生するまではopen状態を維持する。上位からのclose要求とは最終data時にmulti port i/fがmp2dc_lstを1にしてCMD QUEUEに書き込んだ場合で、その場合はprecharge付きreadまたはwriteがDDR2 SDRAMに対して発行される。

←は連続writeのsimulation結果

YUV422を試してみた

これまではTCM8230MDの出力形式はRGB565にしていたが、画像もちゃんと表示できるようになってきたのでYUV422形式も扱えるようにして両者の画像の違いを見てみた。

まずTCM8230MDの出力をcolor bar出力にして、取り込んだ値に変換式を適用してどんな感じのR,G,B値が得られるかを確認した。
←は色配列の確認の為にRGB565で出力させた画像だ。

←の「実測値」がYUV422にして取り込んだ各色の値、その右が変換結果だ。結果が負値は0（赤字）にしてある。

変換結果はR,G,Bのパターン的には問題なさそうなので、verilogで記述してsimulationしてみた。同等の出力が得られている。

左は実際のRTLだ。この部分は65MHzで動作するため、pipelineを３段にしないとtimingがmetしなかった。

 

左がYUV422、右がRGB565だが撮影対象が悪いのか違いがよく判らない。
（左が青味がかっているが肉眼では青味がかっていないので撮影タイミング？かデジカメの問題？と思われる。）
階調が緩やかに変化するような絵じゃないと違いは判らないのかも知れないな。
YUVの場合は乗算回路やpipeline化が必要だったりと回路規模がでかくなってしまうが、
それに見合うほどの画質の違いは感じられないのでRGB565で良い気がする。

さて、TCM8230MDの画像を見るためにFrame bufferを作るという目標は一応達成できた。
この次は以前作成した自作CPUの組み込みに進もうと思っていたのだが、方針を変更して、DRAMCの高速版の作成をしようと思う。目標は260MHzだ。
IP開発は趣味でやっている事なので失敗しても誰に迷惑をかける訳でも無いし、アイデアも浮かんでいる。駄目元で挑戦してみようと思う。

尚、現状のRTL一式はここで公開した。

DDR2 SDRAM CONTROLLERのDEBUG 3

非同期FIFOのMemoryは論理記述していて、XSTにDual PortのBlockRAMに推論させている。これは狙いどおりに推論されていて、Operation ModeもWrite Firstになっているのだが、Block RAMだとあの現象が出てしまうようだ。Block RAMではなく分散RAMを推論するように変えたところ期待通りの画が表示されるようになった。
うーん何か釈然としない。

まだ直したい箇所はあるけれども、
とりあえず、バンザーイ  \(^_^)/

DDR2 SDRAM CONTROLLERのDEBUG 2

だぁー、わかんね。

cifはcameraのdataを貯めて32bit x 16burstでDRAMに書き込むのだが、何故か先頭の2 wordが上手くかけていない。dataが化けているというよりは書き込む番地がズレているように見える。ということはcifではなくてDRAMCの方がバグっている可能性も考えられるのだが？？？
おかしいなぁー、simulationでは異常は見られないんだが。 simulationではOKで実機でNGということはtiming的な問題なのかな？ 非同期FIFOの部分に何かあるのかな?
しかし、timing異常にしては規則的過ぎる気もするのだが？？
あぁ～、ひるましむんやさ。
あと一息なんだけどな。

因みに、DEBUG環境は←のような感じだ。
青と橙の線の先にあるのがcamera基板。
右側のFPGAの上に這っているのがDVI用ケーブルだ。入手性の都合でHDMI用の面実装部品を使っている。こんないい加減な配線でも絵が綺麗なのはdigital i/fのお陰だろう。FPGAが正常動作するようになったらちゃんとした変換基板をP板COMあたりで作ろうかと考えているその時はHDMIコネクタではなくDVI用のコネクタにするつもりだ。