Spartan-3A Starter KitでCMOSカメラ・ディスプレイ回路２０（デジカメ機能）

”Spartan-3A Starter KitでCMOSカメラ・ディスプレイ回路１９（DDR2 SDRAMコントローラのバグフィック）”でDDR2 SDRAMコントローラのバグフィックができたと思ったが、画像のドットが変化しているのが見える。もしかしたら、まだ、DDR2 SDRAMコントローラがおかしいのか？とおもって、デジタルカメラ機能を付けてみた。
つまり、スイッチをONにすると、連続的にCMOSカメラからの画像をディスプレイに表示するが、OFFにすると、フレームの最後でCMOSカメラのデータを取り込まないようにする機能をつけてみた。そうすると、ピタリと画像が止まって画像のドットは安定している。10分ほど見ていたが問題なさそうだった。これでDDR2 SDRAMコントローラは大丈夫そうだということがわかった。デジカメ機能は面白いので、もっと取れるように機能をつけてみようと思った。640X480の画面ならば、128枚取れるが、8枚ほど保存できるようにしてみようかな？（白黒でやってみています。白黒もいい感じかもしれません。白黒画像は余り見たことないし。。。）
やはりCMOSカメラからのデータがふらついているということがわかったが、これで正常なのかどうか判らない？
（YUV-RGB変換処理は8ビットですが、ディスプレイへの出力は抵抗分割の4ビット値です）

次に、うまくカラーにならないという問題がある。これは、デジカメ機能を使用して、画像の書き込みを止めた上で、ChipScope ProのVIO機能のSYNC_OUTからアドレスを出力して、DDR2 SDRAMコントローラに入力し、出てきたデータをSYNC_INで読むという作戦で行こうと思う。それをTCLスクリプトで読みだしてファイルに仕立てる。そのファイルを変換ソフトウェア（これから自作する）で、YUV-RGB変換を施してBMPファイルフォーマットにしてパソコンで見てみようと思う。
”ChipScope ProのVIOを使う１”、”ChipScope ProのVIOを使う２”、”ChipScope ProのVIOをtclスクリプトで制御”参照。

これでうまくいかない場合は、CMOSカメラのSCCBをつないで、RGB444フォーマットで出力するようにしようと思う。

水戸芸術館、那珂湊お魚市場

今日は、夏休み最後の日曜日ということで、またまた、小6の娘と奥さんと水戸方面に行ってきました。最初に漫画好きの娘が観たかった水戸芸術館の新次元　漫画表現の現在という展示を見てきました。


原画の展示やBECKの無音ライブ、のだめカンタービレの原画やカラーイラスト（自動演奏ピアノで音楽を鳴らしていました）などなど、楽しめました。ここには、本格的なパイプオルガンも設備されていて、その演奏も聞くことができました。荘厳な感じですね。教会音楽にぴったりなんでしょう？

その後は、那珂湊お魚市場に行って、お寿司を食べてきました。いやー。人がいっぱい、お寿司を食べるのに1時間近く待ちました。人も多いが車も多い。抜け道通らないとなかなか行き着かないです。。。




カニと巨大な鯖の開きを買ってきました。今日は蟹だそうです。
帰りに高速を降りてから、かすみがうら市でナシを買ってきました。４Lのナシ5個で1,000円でした。かぼちゃをおまけにいただきましたよ。市場に出せない規格外のかぼちゃだそうです。でも、外見はそれほど悪く無いです。。。こういうのを市場に出せないから値段が高くなるんですよね。。。

まつりつくば2010

昨日は、まつりつくば2010に奥さんと小6の娘と行ってきました。今年からTXのつくば駅周辺と研究学園駅周辺に開催地が分散されましたが、やはりメインの開場はつくば駅周辺です。
車が止められないと思ったので、1つ先の万博記念公園駅に車を置いてTXで行くことにしました。万博記念公園駅についたらいつも空いている駐車場が満車です。みんな考えることは変わりがないみたいです。なんとか1台空いているのを見つけて駐車することができるようになりました。TXに乗ってつくば駅へ。電車も浴衣を着た人が沢山いました。やはり祭り気分です。つくば駅に着くと、ペデストリアンに上がりました。周辺はいろいろな屋台でいっぱい。テキ屋もいたのですが、普通のお店が出店としてでいている屋台もいっぱいでした。焼きそば、たこ焼き、ステーキ、やきとり、広島風お好み焼き、枝豆などを買って食べました。特にステーキは柔らかくて美味しかったです。500円でした。
このころ、高校に行っていた高校生の娘も合流。一緒に食べました。高校生の娘は、余り人ごみが好きじゃないということで、バスで帰りました。我々はその辺をお散歩。人がいっぱいいました。下のステージではコンサートをやっていましたよ。


ふらふらしているうちに暗くなってきたので、ペデストリアンから土浦学園線（道路です。まつりつくば中は東大通りから西大通りまでを通行止めにして、祭りをします）に降りました。そうすると、ねぶたがいました。人もいっぱい。。。最初は身動きが取れなかったですが、広い道路との交差点に来るとスペースが有って観やすかったです。




（カメラを引いて取ると、ねぶたは明るので白浮きしてしまいます）
さて、三井ビルの前が広くて見やすいので、そこに移動して、見ていました。前にはタリーズコーヒーので店も出ていましたよ。その前を何基もお神輿が通りました。家の地元の神輿も出ていました。SとUと2基も出ていました。








獅子回しも出ていました。珍しいですね。


神楽？の山車も出ていました。これまた珍しい？

ModelSim XE III 終了

ツイッターで知ったのですが、ModelSim XE III 及び、ModelSim XE III Starter が2010年12月10日以降、ダウンロード、CDの提供とも停止されるそうです。ModelSim XE III をサポートするISE Design Suite は12.3が最後となるようです。
後継はやはり、ISimということになります。
ネタ元、ModelSim Xilinx Edition-III ブロードキャスト製品の製造中止通知

Spartan-3A Starter KitでCMOSカメラ・ディスプレイ回路１９（DDR2 SDRAMコントローラのバグフィック）

”Spartan-3A Starter KitでCMOSカメラ・ディスプレイ回路１８（DDR2 SDRAMコントローラのバグ）”でDDR2 SDRAMコントローラにバグがあることがわかったので修正を試みた。
まずは、シミュレーションで問題の状態が再現できれば、バグフィックスに最適な環境となるので、Veritak シミュレーションによるバグの再現に努力した。そうすると、バグが再現できた。
Veritak シミュレーションによるバグ波形を下に示す。


前回のChipScope Proの波形と見比べると、同様にプリチャージ・コマンドの前にREADコマンドが発行されていることがわかる。


バグを再現できたので、どこがバグっているかを調べた。そうすると、Controller.vにバグがあった。現在、バンクをアクテイブにしているときは、以前のROW、バンクアドレスとこれから発行されるREADやWRITEのアドレスを比較して違っていたら、プリチャージしてアクティベート・コマンドを発行するようにステートマシンが組んであったが、その比較するところにバグがあった。早速修正して、もう一度シミュレーションを行った。それを下図に示す。


きちんとプリチャージしてから、アクティベート、READコマンドの順になった。
次に修正後のChipScope Proの波形を下に示す。


シミュレーション同様に修正されたことがわかる。
さて、ここまでうまく行ったので、今度はディスプレイにCMOSカメラの画像を表示してみる。まずは白黒でやってみた。それが下図。


やったーー。。。ノイズは見事になくなった。が、モアレのような感じがある。これは、RGB4ビット幅なので、しかたないのかな？それに画素がちらついている感がある。

DDR2 SDRAMコントローラにバグが有ることがわかったので、以前のダウンロード用のソースも変更したいと思う。ちなみにバーストテストでは、WriteデータをすぐにReadしているので、ROWアドレスやバンクが変わらずに、バグがでなかった。今回はWriteとReadを非同期で行っているので、バグがわかった。やはり、検証方法の考察は大事だということがわかった。と言っても売り物のIPとしてだしているわけではないので、ゆっくりと検証したいと思う。今やっているアプリも自作のDDR2 SDRAMコントローラの検証としてもやっているつもりなのだ。

Spartan-3A Starter KitでCMOSカメラ・ディスプレイ回路１８（DDR2 SDRAMコントローラのバグ）

この前から悩んできた画面のノイズだが、どうやら自作のDDR2 SDRAMコントローラのバグである可能性が大きくなってきた。
問題の部分を捉えたChipScope Proの画面を下に示す。（ちなみにCMOSカメラを基板に実装してからChipScope Proも安定してかけられるようになった）


Xカーソルのddr2_input_address は0x18D84で、Oカーソルのddr2_input_address は0x080ACになっている。Xカーソルの方はCamere ControllerがDDR2 SDRAMに書いた時のアドレスで、Oカーソルの方がVGA Contoroller が非同期FIFOの半分の量をバーストで読み出すアクセスになる。
この際にバンクが異なると、このDDR2 SDRAMコントローラは1バンクのみアクティブにできるので、バンクをプリチャージしてからアクティベートコマンドを入れて、READコマンドを送る必要がある。
ところが、ここでは、1つREADコマンド（ピンクの四角）を入れてから、バンク・プリチャージ（緑の四角）して、それからアクティベート・コマンド、READコマンド（黄色の四角）□を入れている。最初のREADコマンドのバンクやROWアドレスが異なるので、異なったアドレスのデータが出ていた。これがバグであるようだ。
下に示すように、バンクが違わない場合は、データに問題はないようだ。ROWアドレスが違う場合もプリチャージが必要だが、この場合は前のCamere ControllerのWriteがChipScope Proでみえていないのでわからない？


これでバグのでる条件はわかったので、次はシミュレーション環境で同じバグが出るかどうかを確かめて、バグが出たらバグを修正する。シミュレーション環境ででないようだったら、モデルを修正したりして、実機の動作をシミュレートできるようにすることが肝心だと思っている。シミュレーション環境でバグが出てHDLを修正するのと、ChipScope Proで信号を見ながらHDLを修正するのでは、デバック効率に雲泥の差があると思っている。
ともかくバグが特定できて？（まだわからないし、複数バグがある可能性もあるが。。。）良かったと思っている。

＃やはり検証は大事だと思う。DDR2 SDRAMコントローラを作った頃は意識していなかったが、アサーションを入れておけば良かった。シミュレーションでアサーションエラーが出ていれば、すぐにバグが分かった可能性がある。

Spartan-3A Starter KitでCMOSカメラ・ディスプレイ回路１７（検証回路）

”Spartan-3A Starter KitでCMOSカメラ・ディスプレイ回路１６（基板とコネクタ）”のユニバーサル基板とソケットを使用して、Spartan-3A Starter KitとCMOSカメラを接続する接続基板を日曜日にFPGA-CAFEで作成した。（FPGA-CAFEのすすたわりさんお世話になりました。ありがとうございました。）


早速、家に帰ってやってみたが、やはり接続ケーブルをアルミフォイルでまいた時と出力画像に変化はなかった。出力画像は白黒では表示はされているがノイズが見える。カラーでは色がおかしいというものだ。

やはり、DDR2 SDRAMでデータがたまにおかしいデータを読み出しているのでは？という仮定のもとに検証回路を作成することにした。
CMOSカメラのデータの代わりにカウンタで+1したデータをDDR2 SDRAMに書き込み、読み出したデータが正常でないときはエラーを表示する回路を検証用に作成して検証することにした。
現在、検証回路をデバック中だ。これでDDR2 SDRAMコントローラがおかしくないときには、CMOSカメラからのデータにノイズが乗っていることになるはず？

奥さんのノートパソコン

今日は奥さん用のノートパソコンが来た。Lenovo G560 067958J [ブラック]だ。A-PRICEで代引き手数料込みで、63,431円でした。
今年は小6の娘のノートパソコンも購入したが、奥さんも自分用のパソコンが欲しいということで購入した。どっちもLenovoにした。安い割にスペックが良い。奥さんのパソコンはOpenOffice.orgくらいしかやらないので、i5だけれどもメモリは2GBのノートパソコンを購入した。娘のLenovoは表面が光沢仕様で個人用ということだったが、今度のはつや消しで、ビジネスっぽい。この方が好感が持てる。タッチパッドもつや消しでこっちの方が反応が良い。娘のは反応が鈍い感じだ。
Windows Updateも大体終了して、後はGoogle Chromeとプリンタドライバをインストールする。Lenovoはレスキュー用のメディアが付いていないので、自分でバックアップ用DVDを作る必要があるので、それで終わりかな？

2010/8/22の日記

昨日は、小6の娘と久しぶりにシネプレックスつくばで映画を見てきた。映画は”魔法使いの弟子”、B級映画という感じだったが、コンピュータグラフィクス満載でそれなりに楽しめた。
9月になったらBECKを観に行こうと思う。実はBECKのコミックスは全巻持っている。

午後からは、FPGA-CAFEでSpartan3A Starter KitとCMOSカメラを接続する変換基板を作った。いえながさんとお話できた。すすたわりさん、木工手伝いしますよ。お世話になりました。
変換基板はできてやってみたが、やはりノイズはなくならない？本格的に検証パターン、検証回路を作って、DDR SDRAM系、アービタをテストしてみようと思う。

Spartan-3A Starter KitでCMOSカメラ・ディスプレイ回路でのOVLアサーション１

”Spartan-3A Starter KitでCMOSカメラ・ディスプレイ回路６（シミュレーション２）”でVerilogで書いたアサーションをOVLに書きなおしてみたいという希望を書いたが、実際にOVLアサーションに書きなおしてみることにした。
OVLについては、私のブログのまとめサイトのアサーション事始めを参照のこと。
AccelleraのOVL(Open Verification Library)のダウンロードサイトに行くと、Ver.2.5が出ていたので、これをダンロードしてから始めると良いと思う。

まずはVGA_Display_Controllerから、VerilogアサーションをOVLに変更してみる。ここでのアサーションは下のように非同期FIFOのoverflowとunderflowを検出するアサーションだ。

    // アサーション
    // synthesis translate_off
    always @ (posedge clk_ddr2) begin
        if (reset_ddr2)
            ;
        else begin
            if (afifo_overflow) begin 
                $display("%m: at time %t ERROR : FIFOがフルなのにライトした",$time);
                $stop;
            end
        end
    end
    always @(posedge clk_cam) begin
        if (reset_cam)
            ;
        else begin
            if (afifo_underflow) begin
                $display("%m: at time %t ERROR : FIFOが空なのにリードした",$time);
                $stop;
            end
        end
    end
    // synthesis translate_on

これを、OVLに変更するために、ovl_never を使用し、以下のように変更した。

// synthesis translate_off
`include "std_ovl_defines.h" // std_ovl_defines.hをインクルード
// synthesis translate_on

...............

    // synthesis translate_off
    wire [`OVL_FIRE_WIDTH-1:0] fire_overflow, fire_underflow; // fire用の信号を定義
    // synthesis translate_on

    ...............
    
    // synthesis translate_off
    ovl_never #(
        `OVL_ERROR,            // severity_level
        `OVL_ASSERT,        // property_type
        "ERROR : FIFOがフルなのにライトした", // msg
        `OVL_COVER_DEFAULT,    // coverage_level
        `OVL_POSEDGE,        // clock_edge
        `OVL_ACTIVE_HIGH,    // reset_polarity
        `OVL_GATE_CLOCK    // gating_type
    ) afifo_overflow_assertion (
        clk_ddr2,
        reset_ddr2,
        1'b1,
        afifo_overflow,
        fire_overflow
    );
        
    ovl_never #(
        `OVL_ERROR,            // severity_level
        `OVL_ASSERT,        // property_type
        "ERROR : FIFOが空なのにリードした", // msg
        `OVL_COVER_DEFAULT,    // coverage_level
        `OVL_POSEDGE,        // clock_edge
        `OVL_ACTIVE_HIGH,    // reset_polarity
        `OVL_GATE_CLOCK    // gating_type
    ) afifo_underflow_assertion (
        clk_cam,
        reset_cam,
        1'b1,
        afifo_underflow,
        fire_underflow
    );
    // synthesis translate_on

最初にstd_ovl_defines.hをインクルードする。次にfire用の信号を宣言する。その次にovl_neverを書いた。”OVL（Open Verification Library）を試してみる７(OVLチェッカの概要）”を引用する。

ovl_never : test_exprが決して真にならないことをチェックする。例えば、サイコロの値をdice_cntとすると、test_exprはdice_cnt>6と表される。dice_cntが7以上になればアサーション・エラーとなる

詳しくは（OVLの使い方や値の意味は）、OVLをダウンロードして、解凍したファイルのstd_ovl\docs\pdfdocsの下のovl_lrm.pdf(Accellera Standard OVL V2 Library Reference Manual)を見てもらうとわかると思う。

最初のパラメータ (severity_level) の`OVL_ERRORは、重要性のレベルでアサーションエラーだとERRORを出力する。“severity level”には、OVL_FATAL、OVL_ERROR、OVL_WARNING、OVL_INFOがあるそうだ(Accellera Standard OVL V2 Library Reference Manual参照、以下略)。

2番目 (property_type) の`OVL_ASSERTは、assertやassumeのプロパティだ。OVL_ASSERTはX/Zのチェックを含んだassert。OVL_ASSERT_2STATEは、X/Zのチェックを無視したassert。後は、OVL_ASSUME、OVL_ASSUME_2STATE がある。

3番目 (msg) は、アサーションエラーの時のメッセージ。

4番目 (coverage_level) は、coverage_level。`OVL_COVER_DEFAULTは、std_ovl_defines.hで OVL_COVER_BASICと定義されている。これをOVL_COVER_CORNERにすると、ovl_rangeで、min値とmax値になったときに”OVL_COVER_POINT : OVL_RANGE ”が表示される。
OVL_COVER_SANITY はチェックしている値が変化したときに、”OVL_COVER_POINT : OVL_RANGE ”が表示される。
後は、OVL_COVER_STATISTIC、OVL_COVER_NONE、OVL_COVER_ALL がある。

5番目 (clock_edge) は、クロックエッジで立ち上がりでチェックするか（OVL_POSEDGE）、立ち上がりでチェックするか（OVL_NEGEDGE）。

6番目 (reset_polarity) は、リセットの極性。アクティブハイ（OVL_ACTIVE_HIGH）か、アクテイブロー（OVL_ACTIVE_LOW）

7番目 (gating_type) は、enableに対してどう振舞うかを表す。OVL_GATE_CLOCKの場合はenableがFALSEの場合はチェックを停止し、なにもしない。カウンタや初期値は変更されない。
OVL_GATE_NONEの場合はenableを無視する。OVL_GATE_RESETの場合はenableがFALSEの場合はリセットする。

今度は信号の方で、最初の clk_cam は、アサーションのためのクロック。

2番目の reset_cam は同期リセット。

3番目の 1'b1 は、enableで、パラメータの7番目のgating_typeに関連する。

4番目の afifo_overflow は、チェックの条件だ。ここがTUREになると、パラメータの3番目のメッセージが出力される。

5番目の fire_overflow は、3ビット幅のfireで、ビット0はアサーションが失敗した時に1になる。ビット1はX/Zチェックが失敗した時に1になる。ビット2はCoverイベントがあったときに1になる。

さて、OVLをシミュレーションしてみよう。”OVL（Open Verification Library）を試してみる２（Veritakを使用する）”で行ったように、Defineが必要になる。

-Define OVL_VERILOG
-Define OVL_INIT_MSG
-Define OVL_COVER_ON
-Define OVL_ASSERT_ON
-Define OVL_MAX_REPORT_ERROR=1

上に示すDefineを行った。このうち必須なのは、OVL_ASSERT_ONとOVL_COVER_ONかな？
次に、std_ovl フォルダをincludeフォルダとして登録した。ライブラリフォルダとしても登録した。

-include_dir ../../../../OVL/std_ovl
-lib_dir ../../../../OVL/std_ovl

OVL Ver.2であれば、

-lib_ext vlib

は必要ない。
これで準備OKなので、Veritak-Basic Ver.3.80Dで、コンパイルしてシミュレーションしてみた。下がその結果だ。


2つのfireは、ずっと発火しないまま、つまりエラーがでない状況だ。これは良いことなのだが、fireが発火するシミュレーションが、”OVL（Open Verification Library）を試してみる４（OVL_range）”にあるので参照のこと。

CQ出版のセミナに行ってきました

昨日は、CQ出版社のセミナ”開発効率を引き上げるディジタル・ハードウェアの検証技法”に行ってきました。
非常に中身の濃い内容で、とても勉強になりました。いや難しかったので、勉強しようという気になりました。というところでしょうか？
内容はSystemVeriogの紹介、VMM（Verification Methodology Manual for SystemVerilog）の使い方を学んできた。かなり中身の濃い内容で、これで13,000円は安いです。
SystemVeriogはほとんどC++の用にオブジェクト指向で、クラスを書いて、メンバやメソッドを書いて行くのを初めで知りました。dynamic array, queue, semaphore, mailbox, infterface, program。interfaceはあまりセミナではやらなかったけど、レベルの違うモデル同士を結合しやすくなるんではないかと期待しています。より抽象度があがったHDLですね。ガベージコレクションが必要な理由もわかりました。SystemVeriogシミュレータを自作するのはものすごいことですね。
VMMはvmm_dataでデータを作り、vmm_xactorでデータを処理して、vmm_envで環境を整備するというような流れということがわかりました。（間違っているかもしれません）vmm_envは、良いと思いました。実行手順を明確に書き分けられます。手順が明確になりますね。
ModelSimのAltera版やXilinx版ではrandomizeが使えないそうです。ModelSimのAltera版やXilinx版で動作するVMMもどきのファイルももらってきました。後で、検討してみたいと思っています。
アサーションはOVLを使えということでした。
本当に内容の濃い値段を遥かに超えたお買い得感のあるセミナでした。やはり、早くXilinxのXSTやISim, Veritak（あくまで、私の希望なので、気になさらないでください）がSystemVeriogに対応してくれると良いですね。Alteraは一部対応でしたっけ？
PowerPoint272枚分のカラーの資料も頂いて、嬉しかったです。今度、このようなセミナがあったらまた参加したいです。UVMも学んでみたいです。
そうそう、Verification Engineerの戯言さんにお会いして、お昼をご一緒させていただきました。いろいろお話が出来てとても楽しかったです。ありがとうございました。いろいろ検証も学んで行こうと思いました。

そういえば、Spartan-3A Starter KitでCMOSカメラ・ディスプレイ回路で回路が完成したら、OVLのアサーションを入れて試すという予定がクリアされていないことに気が付きました。取り敢えず完成したわけではないですが、OVLアサーションに変更してみようと思います。（OVLはJuly 2010にVer.2.5になったようです。Verification Engineerの戯言さんにも紹介されています）OVLは（他のは知りませんが。。。）論理合成可能というところも良いですね。論理合成して、出力をLEDや何らかの形で出力すると実機でのアサーションが出来て、バグの解決が劇的に早くなることが期待できると思っています。

Cyclone III のお勉強１

SDR SDRAMコントローラは、単体で作るか、SOPC Builderベースで全体を構築してIPを使うか？もう少し検討することにした。
さて、DE0に使用されているFPGAのCyclone3について、何も知らないので、マニュアルで勉強することにした。
Cyclone III デバイス・ハンドブックのChapter 1. Cyclone III デバイス・ファミリの概要を読んで勉強する。

・ロー・パワー65 nm FPGA（XilinxではVirtex-5が65nmのようだ。廉価版ではSpartan-3シリーズが90nm、Spartan-6シリーズが45nmなので、Xilinxの廉価版は65nmがないみたい）
・PLLのみ、DCMは入っていない
・DDR2 SDRAMとか最大400Mbpsのメモリインターフェイスに対応する
・I/OはXilinx同様に色々設定できる。

DE0のFPGAの型番は、EP3C16F484C6Nだったので、EP3C16というCyclone III シリーズ。
Chapter 1. Cyclone III デバイス・ファミリの概要の表1–1. Cyclone III FPGA デバイス・ファミリの特長を下に引用させていただく。


ロジック・エレメントが15,406、メモリ504Kビット、マルチプライヤも56個、PLL4個、グローバル・クロック/ネットワーク20個のかなり大きなFGPAだ。
パッケージは484 ピン FineLineボール・グリッド・アレイ（FBGA）で、346個のIOポートが使える。

Spartan-3A Starter KitでCMOSカメラ・ディスプレイ回路１６（基板とコネクタ）

”Spartan-3A Starter KitでCMOSカメラ・ディスプレイ回路１５（CMOSカメラ搭載基板）”で頼んだ、ユニバーサル基板とソケットが今日来た。
ライトアングルヘッダが間に合わないので、これで上向きだがカメラをマウントする基板を作ろうと思う。
予定では、22日（日）のFPGA-CAFEに行って作らせてもらおうと思う。

DE0のSDR SDRAMコントローラ１

昨日は娘の具合が悪くなってしまったので、ジブリ美術館には行こうとしたのだが、四谷で引き返してしまった。TXを降りる頃はだいぶ回復していたので、良かった。チケットと往復の電車賃がもったいなかったが、まあこんなこともあるということで。。。ジブリ美術館は、ひところの全く予約が取れない状況ではなく、土日でも予約が取れる様なので、９月１２日に予約した。今度はいけると良いな？と思う。これで、夏休みの旅行は全滅で、１つも行けなかった。。。

さて、Spartan-3A Starter KitでCMOSカメラ・ディスプレイ回路は、今度の日曜日にFPGA-CAFEで、ユニバーサル基板とソケットのハンダ付けさせてもらうことにしようと思っている。ライトアングルヘッダは在庫がなく遅れるそうなので、取り敢えずカメラを上向きに付けようと思っている。
次に、AlteraのボードのDE0にCMOSカメラをつなぎたいと思っているので、まずはSDR SDRAMのコントローラをつくろうと思っている。いままでのDDR2 SDRAMコントローラとバックエンドへの入出力インターフェースを合わせれば、今までの回路が使いまわせるはずだ。
SDR SDRAMコントローラはVHDLはシミュレーションが終了して、コンパイル（Alteraではコンパイルでよかったですよね？）する段階になっている。ただ、DE0用ではないため、DE0の使用している、SDR SDRAMに合わせたチューニングが必要な状態だ。Verilogバージョンは作りかけで止まっているので、完成させて、こっちを使おうと思っている。SDR SDRAMはDDRよりも実装が楽になるはずだ。
Avalonバスのマスタデバイスの作り方が分かれば（CMOSカメラの出力をマスタデバイスとして作れれば）、SDR SDRAMコントローラはあるのだが、自分で構築すると作る必要がある（のですよね？）。

SDR SDRAMコントローラとは関係ない、なくもないが、AlteraのFIFOはFWFTモードがあるのだろうか？
Alteraでは、同期FIFOのことはSCFIFO(Single-Clock FIFO)、非同期FIFOのことはDCFIFO（Dual-Clock FIFO)とよぶようだ。DCFIFOで入力データ幅と出力データ幅の異なるFIFOもMegaWizard Plug-In Manager で作ることができたのだが、FWFTに出来るかどうかわからないし、overflow, underflow出力も出せないのだろうか？チェックはしているみたいなのだが、overflow, underflow出力が出せれば、実機でアサーションとして使えるのだが。。。ユーザーズ・ガイドを読んで勉強することにする。


SCFIFO and DCFIFO Megafunctions User Guide を読んでいてわかったのだが、XilinxのCore Generator のFIFOのFWFTモードと同じモードは、Show-ahead synchronous FIFO mode と言うらしい？


でも性能へのペナルティがあると書いてあるがなぜだろう？いろいろ謎なことが多いが、ユーザーズ・ガイドを読むしかないかな？
（Quartus 2のバージョンは9.1です）

（追記）
もしかして、”the q output must be registered in normal mode and unregistered in show-ahead mode for the DCFIFO.”だから性能が悪くなるのかな？

最近のブログの検索語

今日までで夏休みは終了。ものすごく暑いので、早く仕事に行きたい気がします。仕事が待ち行列に入っているので、早くやりたいと思っています。18日は、画像処理をして、19日は出張。CQ出版社のセミナ、”開発効率を引き上げるディジタル・ハードウェアの検証技法”に参加します。20日はとても大切な仕事があります。
今日は三鷹の森ジブリ美術館に行ってきます。とても楽しみです。朝が早いので通勤渋滞に巻き込まれてしまうかも？

さて、今日のお題は私のブログの検索語。夏休みも半分を過ぎて終了に近いということで、最近は自由研究の検索が多いです。もう少し早く自由研究を始めたほうが良いと思いますが、終盤も近くなって焦ってきた方が多いのでしょうか？


上の図は昨日（16日）の検索語のランキングですが、FPGA関連の検索を抑えて、自由研究関連の検索が上位に来ています。自由研究をやっていない小学生、中学生頑張ってください。
そう言えば、娘とやった自由研究も2年前か？あれ以来面倒だと言って、自由研究をやってくれなくなりました。非常に残念です。私はやりたくてウズウズしているのに。。。野帳、論文、ポスターと3つセットで揃えないとだめというのが面倒なんだそうです。他の課題にしているみたいです。絵とか。絵が得意ですから仕方ないかもしれません？

Spartan-3A Starter KitでCMOSカメラ・ディスプレイ回路１５（CMOSカメラ搭載基板）

いや、暑いです。17日まで、夏休みなので家にいます。現在の室温は35度です。暑いです。温湿度計も壊れてしまいました。買わないと。。。文体が変わります。

やはり、CMOSカメラを接続するケーブルが長すぎるようなので、秋月電子でユニバーサル基板とソケットを買って、基板上で配線することにした。買った部品は以下の通り。（結局、Verilogコードを修正したのは1箇所だけで、後は今のところ、配線長やノイズが原因らしい？）
1. ピンソケット（メス） ２×２０ （４０Ｐ） C-00085
2. ピンソケット（メス） ２×８ （１６Ｐ） C-02761
3. 両面スルーホールガラス・ユニバーサル基板　Ｃタイプ　めっき仕上げ　（７２ｘ４８ｍｍ）　日本製 P-03231

秋月電子でもaitendoでもライトアングルヘッダが見つからなかったので、CMOSカメラは上に向けてマウントするしかないかな？と思っていたら、思いがけなくアマゾンジャパンで日本航空電子のライトアングルヘッダ40Pを見つけたので、これで、基板を2枚使って、CMOSカメラを横向きにマウントすることができる。

部品が来るまではやることがないので、DE0用のSDR SDRAMコントローラでも作っていようと思う。VMMも勉強したい。でも、ものすごく暑い。

Spartan-3A Starter KitでCMOSカメラ・ディスプレイ回路１４（カラー化）

やっと、CMOSカメラの画像が出てきて一安心。画像が寄っている原因はわかった。シミュレーション用にVGAコントローラのアドレスを途中から始めているからだった。（”Spartan-3A Starter KitでCMOSカメラ・ディスプレイ回路６（シミュレーション２）”の parameter VGA_CON_STAR_ADDR = 19'd307000; を参照。やはり、インプリメント用のソースを直しては駄目だ。どうしてもソースを修正するときはifdef を使って、シミュレーションときだけparameter を変えたほうが安全だと思われる）
それを修正したら、大体直ったのだが、今度は反対がわによってしまった。16番地からアドレスをスタートさせたら丁度良くなった。（今のところ原因はわからないが、数が違っているのではないようだ）
下の画像は0番地からスタートさせた時の画像。
まずはテストパターン。


白黒画像。


次にカラーにしてみたが、色がおかしい。下の画像は蛍光灯で写した画像。ピンク色になってしまう。まだまだ、検討課題が多いが、基板を作ってから評価するつもり。

Spartan-3A Starter KitでCMOSカメラ・ディスプレイ回路１３（画像が出てきた）

いろいろうまくいかないSpartan-3A Starter KitでCMOSカメラ・ディスプレイ回路だが、配線にアルミフォイルを巻いたら、だいぶましになってきた。やはり、配線を短くしようと、秋月電子でコネクタと基板を買ったので、アダプタ基板を作ろうと思っている。秋月電子がお盆休みで休みなので、来週になるとおもう。

さて、いろいろやってみているが、ChipScope Proを入れると、規模によっては上手く動かないことがあるようだ。一旦、ChipScope Proを外すと、テストパターンが出てきた。


やった。これで少なくともDDR2 SDRAMとVGAコントローラはOKだ。しかし、少しずれているようだ。本当ならば、黒いところかは始まるはず。。。
CameraコントローラをCMOSカメラからの画像に切り替えて、インプリメントして、ダウンロードしてみたところ、画像が出てきた。でも完全におかしい。


また、いろいろ試行錯誤したが、よくならない。もしかすると、と思って、カメラのピントを思い切って、ぐるぐる回してみたら画像が出てきた。


やったーー。。。画像がでました。。。でも、右にずれている。。。ともかくよかったが、ノイズも見える。まだ改善点はたくさんあるな。。。
ともかくズレを治そうと思っている。テストパターンと比較したところ、右に208ドット程度ずれているみたいだ。
進展があったので、やる気が出てきた。しかし、ChipScope Proを入れると、うまくいかなくなってしまうことが多いのが難点だ。デバックが難しい。今のところ原因はわからない？

Spartan-3A Starter KitでCMOSカメラ・ディスプレイ回路１２（ノイズ？）

”Spartan-3A Starter KitでCMOSカメラ・ディスプレイ回路１１（ChipScope Pro)”で、Core Generator IPの非同期FFIFOの動作がおかしいという記事を書いた。

あれからいろいろやってみたが、治らない。そこで、試しに、いままでLVCMOS33だったCMOSカメラのI/O信号規格をLVTTLに変更してみた。そうすると、少し長く動作するようになった。これは、やはりPCLK関係のノイズかな？と思い、試しにコードにアルミフォイルを巻いてみた。そうしたところ、overflow, underflow は起きなくなった。基板からのノイズを拾っていたのだろうか？やはり、Core Generator のIPの動作がおかしいなんて、どこかおかしいと思った。。。


これで、overflow, underflow は起きなくなったので、制御系は大丈夫そうだ。データがまだおかしいので、デバックを続ける。
下の図が、Camera Contorller とVGA Display Contorller の非同期FIFO IPのChipScopeの波形だ。overflow, underflow は起きなくなったことがわかる。



（追加）
ChipScopeを盛大に入れると、overflow, underflow が起こることがある。ChipScopeを入れなければ、overflow, underflowは起こらないみたい。

阿見のアウトレット、映画のヒックとドラゴンを見てきました

昨日から17日まで、お休みです。まあ、お休みでもCMOSカメラ・ディスプレイ回路のデバックもしています。

今日は、午前中、阿見のアウトレットショップに行ってきました。圏央道がかなり出来ていて30分くらいで、楽に行けました。おしゃれな感じのブランドショップが並んでいます。素敵な感じです。


娘たちや奥さんはトリンプで下着を買ったりしましたが、私は店の中に入るわけにもいかずに、外でメールチェックをしながら待っていました。アシックスやアディダスも出ていたので、アシックスでTシャツを1枚買ってきました。お昼はフード・ガーデンのラーメン屋（中華そば　いちや）で食べたのですが、黄色い細めんでかん水が効きすぎて、麺が固めでした。スープにもかん水の味が溶けていて、いまいちでした。
やはり、あまり、私のような男が行くところではないという結論を得て帰ってきました。牛久大仏は近くに見えましたよ。

午後からは、映画に行ってきました。ヒックとドラゴンです。3Dでみました。
あまり期待していなかったのですが、私は面白かったです。娘も面白かったと言っていました。

Spartan-3A Starter KitでCMOSカメラ・ディスプレイ回路１１（ChipScope Pro)

Spartan-3A Starter KitでCMOSカメラ・ディスプレイ回路をChipScope Proで観察してみた。
Camera_Contorller.vのcam_cont_afifoのoverflowフラグが1になってしまうのが問題だ。現在のCamera_Contorller.vはカメラのデータが正常に表示されるかを確認するために0からインクリメントしたデータをDDR2 SDRAMに書き込んでいる。Camera_Contorller.vの全ソースを下に示す。

// CAMERA_CONTROLLER
// カメラデータを書き込むためのDDR2 SDRAMアドレスを出力する
// YデータとUVデータを出力する。フォーマットはUYVY
// 2001/07/24：cam_cont_afifoに2つ以上のデータがあることを示すためにrd_data_countを出力ポートに追加する

`default_nettype none

module Camera_Controller (
    input    wire    clk_cam,    // 25MHzのCMOSカメラ用クロック
    input    wire    clk_ddr2,    // 133.33MHzのDDR2 SDRAM用クロック
    input    wire    reset_cam,    // clk_cam 用リセット
    input    wire    reset_ddr2,    // clk_ddr2 用リセット
    input    wire    cam_href_2d,     // CMOSカメラからのHREFのラッチ出力(2クロック遅延）
    input    wire    master_sync,     // 同期信号
    input    wire    [7:0]    cam_data_2d,    // CMOSカメラからの輝度データ
    output    reg        [18:0]    address,    // アドレス
    output    wire    [31:0]    data_out,    // VYUY8ビットフォーマットの画像データ出力
    input    wire    addr_enable,    // アドレス・イネーブル
    input    wire    data_enable,    // データ・イネーブル
    output    wire    afifo_empty,    // cam_cont_afifo はempty 
    output    wire    [3:0]    afifo_rd_data_count,     // cam_cont_afifoのread data count
    output    wire    afifo_overflow, // cam_cont_afifo はoverflow
    output    wire    afifo_underflow    // cam_cont_afifo はunderflow
);
    
    reg [7:0] uv_ff;
    wire afifo_wr_en;
    wire [15:0] afifo_din;
    reg y_pos;
    wire afifo_full;
    
    parameter UV_state =    1'b0;
    parameter Y_state =        1'b1;
    reg YUV_state;
    
    reg    [7:0] count;
    
    // 非同期FIFO Write(16ビット幅、32深度）、Read（32ビット幅、16深度）
    cam_cont_afifo cam_cont_afifo_inst (
        .rst(reset_ddr2),
        .wr_clk(clk_cam),
        .rd_clk(clk_ddr2),
        .din(afifo_din), // Bus [15 : 0] 
        .wr_en(afifo_wr_en),
        .rd_en(data_enable),
        .dout(data_out), // Bus [31 : 0] 
        .full(afifo_full),
        .overflow(afifo_overflow),
        .empty(afifo_empty),
        .underflow(afifo_underflow),
        .rd_data_count(afifo_rd_data_count) // Bus [3 : 0] 
    );
    
    // UまたはVを保存しておくFF、UYVYで出てくるので、UまたはVを保存しておいてYが出てきた時点でcam_cont_afifoに書き込む
    always @(posedge clk_cam) begin
        if (reset_cam)
            uv_ff <= 0;
        else
            uv_ff <= cam_data_2d;
    end
    
    // U,VとYを表すステートマシン
    always @(posedge clk_cam) begin
        if (reset_cam)
            YUV_state <= UV_state;
        else
            case (YUV_state)
                UV_state :
                    if (cam_href_2d)
                        YUV_state <= Y_state;
                    else
                        YUV_state <= UV_state;
                Y_state :
                    YUV_state <= UV_state;
        endcase
    end
    
    // afifo_din はuv_ff とcam_data_2d を連結
    // assign afifo_din = {uv_ff, cam_data_2d};
    assign afifo_din = {count, count};
    // cam_cont_afifo のwr_en はYUV_state がY_state の時
    assign afifo_wr_en = (YUV_state==Y_state) ? 1'b1 : 1'b0;
    
    // テスト用カウンタ
    always @(posedge clk_ddr2) begin
        if (reset_ddr2)
            count <= 0;
        else begin
            if (master_sync)
                count <= 0;
            else if (YUV_state==Y_state)
                count <= count + 8'd1;
        end
    end
    
    // アドレス用カウンタ　640*480 = 307,200(hex 4b000)をカウントする
    always @(posedge clk_ddr2) begin
        if (reset_ddr2)
            address <= 0;
        else begin    
            if (master_sync) // 1フレーム終了したので0に戻す
                address <= 0;
            else if (addr_enable)
                    address <= address + 19'd4; // DDR2 SDRAMは1回の書き込みで4つの16ビットデータを書き込むため
        end
    end
endmodule

`default_nettype wire

cam_cont_afifoには、Core Generator で生成した非同期FIFOを使用している。
ChipScopeで観察した波形を下に示す。


一番上の信号のcamc_afifo_overflowが1の時にトリガーがかかるようになっている。/Cam_Cntrler_inst/cam_cont_afifo_inst/wr_en が非同期FIFOの書き込み信号で、この信号は25MHzで動作する信号だが、ChipScopeのクロックは125MHzなので、複数クロックでトグルしている。/Cam_Cntrler_inst/cam_cont_afifo_inst/rd_en が125MHz動作の信号で、これは1パルスで非同期FIFOの読み出しを行う。
おかしいのは、/cam_cont_afifo_inst/wr_data_countが06から急に3F（青と赤のカーソルで囲まれた部分）になってしまうことだ。それでfullとなって、更に書き込むため overflow してしまうようだ。rd_data_countもおかしい？
どこが悪いのか？良くわからない？もしかして、リセット関係が悪いのだろうか？ヒゲが出てたりして？

Spartan-3A Starter KitでCMOSカメラ・ディスプレイ回路１０（波形観察）

Spartan-3A Starter KitでCMOSカメラ・ディスプレイ回路がうまく動かないので、OV7670からの信号をオシロスコープで観察してみた。
やっている様子の写真を下に貼る。


上の写真はPCLKとD0にICクリップをかけているところ。下に波形の写真を示す。


上がPCLKで下がD0だ。Singleでやったのに、D0おかしいんじゃないの？１日くらい、これがおかしいと思っていた。しかし、よく見てみると、どうも線が太すぎる？よくよくオシロスコープの設定を検証すると、等価時間サンプルモードになっていた。上の写真のEquがそうだ。これをノーマルサンプルモードに戻したら、ちゃんと波形が見えてきた。


（アースが少し遠いところで取っているので、波形が乱れ気味ですが、もう少し良い波形だと思います）、HREF,VSYNCなども問題ないようだ。（プローブをかけている状態では、FPGAがクロックを受けられないようで、ディプレイがNO SIGNALになってしまいます）
VGA Display Controllerの非同期FIFOのアンダーフローが出ているので、これを検証することにする。

2010年8月7日の日記

Spartan-3A Starter KitでCMOSカメラ・ディスプレイ回路はデバック中で、DDR2 SDRAMの動作周波数は133.33MHzではタイミングエラーが出てしまうので、下限値である125MHzに変更した。これでタイミングエラーは無くなった。

カメラからのPCLKは25MHzのクロックが来ていることをオシロスコープで確認した。HREFやVSYNCも来ていたが、波形が余り綺麗ではなかった。思ったより波形が汚い。やはりPCLKをDCMで受けると出力クロックが出なくなることがあるようだった。よって、PCLKのDCMを外すことにした。やはり、フラットケーブルは問題があるのだろうか？そういえばデータを1本も見ていないので、見ることにする。
カメラのコントロール回路にバグがあっておかしかったので修正した。これでだいたい画像が全画面に見えてきたが、どうも暗い感じというか、余り画像がはっきり見えない。
次は、DDR2 SDRAMとVGAコントローラが大丈夫かどうかを調べる。方法としては、カメラのコントローラを書き換えて、カメラのデータではなく、自分でデータを作って、DDR2 SDRAMに書き込んで、狙ったパターンが画像としてみえるか？を検証することにする。

今日は出勤で、夏休みの中学生に自由研究のお手伝いをする。音の波形を中学生に見せたり、ボイスチェンジャーで音を変えたりしてみる。今年の目玉？は外に出て、せみの声を録音してこようと思っている。パソコンのフリーソフトを使っているので、ノートパソコンであれば外に持ち出すことができる。

明日はPROSUME 2010を見てこようと思っている。参加できないのは残念だが、観に行こうと思っている。

PlanAheadでエリア制約をかける方法の覚えがき

PlanAheadでエリア制約を書ける方法は、”Spartan3A Starter KitのDDR2 SDRAMコントローラのインプメントをPlanAheadでフロアプラン”で一応書いたのだが、やり方を書いてなかったので、今回やるのに迷ってしまった。そこで今回はやり方も書いておこうと思う。

現在デバック中のSpartan-3A Starter KitでCMOSカメラ・ディスプレイ回路を使用する。使用するISEのバージョンはISE12.1。インプリメント後の配置をPlanAheadでいじるのではなく、配置配線前にエリア制約をかけてみることにする。
Project NavigatorのProcessesペインの下のUser Constraints -> Floorplan Area/IO/Logic (PlanAhead) をダブルクリックした。


PlanAheadが起動する。この時、Deviceビューにする。


さて、ddr2_sdram_cont_instにエリア制約をかける。ddr2_sdram_cont_instで右クリックして右クリックメニューから、Draw Pblockを選択する。


右のDeviceビューでドラックしてエリア制約の領域を指定すると、New Pblockダイアログが開く。OKボタンをクリックする。


これで、ddr2_sdram_cont_instの領域を指定することができたので、Save Designアイコンをクリックして、エリア制約を保存する。


PlanAheadを終了する。
UCFファイルを見ると、下のような制約が追加されている。

# PlanAhead Generated physical constraints

INST "ddr2_sdram_cont_inst" AREA_GROUP = "pblock_ddr2_sdram_cont_inst";
AREA_GROUP "pblock_ddr2_sdram_cont_inst" RANGE=SLICE_X24Y40:SLICE_X39Y87, SLICE_X0Y40:SLICE_X23Y95;
AREA_GROUP "pblock_ddr2_sdram_cont_inst" RANGE=MULT18X18_X0Y5:MULT18X18_X0Y9;
AREA_GROUP "pblock_ddr2_sdram_cont_inst" RANGE=RAMB16_X0Y5:RAMB16_X0Y9;

Spartan-3A Starter KitでCMOSカメラ・ディスプレイ回路９（インプリメント３）

”Spartan-3A Starter KitでCMOSカメラ・ディスプレイ回路８（インプリメント２）”の続き。

133.33MHzクロックのデータパスの遅延が8.891nsec となって、制約の7.5nsec を満足できない。（分けあってISE12.1）
以前に、ddr2_burst_testプロジェクトを133.33MHzに変更して、インプリメントしたときはタイミングがメットしていた。


何で、タイミング制約を満足できないのだろうか？よしということで、ddr2_burst_testプロジェクトのddr2_sdram_cont の配置制約をすべていただいて、CMOSカメラ・ディプレイ回路の配置制約として使えば、タイミングを満たすことができるのでは？と考えたので、実行してみた。
”PlanAheadで配置配線後の配置制約をUCFに書き出す”の手順でddr2_burst_testプロジェクトの配置制約をUCFファイルに出力して、それを、CMOSカメラ・ディプレイ回路のUCFにコピーした。それでインプリメントをしてみたが、所々で制約がエラーになってしまった。エラーを1つ1つコメントアウトして、インプリメントが通るようになった。下が、書き換えたUCFだ。


エラーが出たところをコメントアウトしてある。
これでインプリメントしたが、やはり、タイミングエラーがなくならない。下図にTiming Analyzer の表示画面を示すが、かえって悪くなってしまった。


ddr2_burst_testプロジェクトからコピーした制約は削除した。
今度はcam_pclkのCLOCK_DEDICATED_ROUTEを削除して、上手くタイミングエラーが出なくなるかどうかを確かめてみることにした。

NET "cam_pclk" CLOCK_DEDICATED_ROUTE = FALSE;
PIN "clk_cam_dcm_inst/DCM_SP_INST.CLKIN" CLOCK_DEDICATED_ROUTE = FALSE;

を削除して、clk_cam_dcm_instは下図の右側のDCMを使用するので、clk_cam_dcm_instが使用するクロックを左側4つのグローバルクロック入力のどれかを使用すれば良いはず。基板の制約でそのグローバルクロック入力ピンには接続はできないが、もし接続できたら、タイミングエラーが発生しないのかを調べる。ここでは、D11のグローバルクロック入力に、cam_pclkの入力ピンを仮に設定してみることにした。（D11はグローバルクロック入力の左端。長四角の下に三角が付いたコンポーネントです）

# NET "cam_pclk" LOC = A12;
NET "cam_pclk" LOC = D11;

これでインプリメントしてみたが、やはり、タイミングエラーがなくならない。


ddr2_sdram_cont 内で完結してる、7.5nsecのクロック1周期分よりデータパスの遅延が長くなったという、言わばまっとうなタイミングエラーだけに、ソースの修正が必要かな？
しかし、ddr2_burst_testプロジェクトで大丈夫というのを確認していただけに、納得ができない。。。

PlanAheadで配置配線後の配置制約をUCFに書き出す

以前に、”PlanAheadで配置配線後のクリティカルパスを修正し、配置制約をUCFに書く”で、配置配線後のクリティカルパスを修正して、配置制約をUCFに書き出す方法を書いたが、今度は配置配線後にそのコンポーネントの配置の制約をUCFファイルに書き出す方法を書いておく。

それではProject NavigatorからPlanAheadを起動する。
Project NavigatorのProcessesウインドウのImplement Designを展開し、その中のPlace & Routeを展開する。Analyzer Timing / Floorplan Design (PlanAhead) をダブルクリックして、PlanAheadを起動する。（下図は以前の図を使用しています。違うプロジェクトが表示されています）


今、ddr2_sdram_cont_instのコンポーネントの配置をすべて制約としてUCFファイルに書きたいとする。
やり方は、左のNetlistウインドウからddr2_sdram_cont_instを選択して、右クリックして、右クリックメニューを表示する。右クリックメニューからSelect Primitives を選択する。


右のDeviceウインドウにddr2_sdram_cont_instのプリミティブが白くハイライトされる。


配置を固定する。白くハイライト（選択）されたプリミティブの上で右クリックして、右クリックメニューからFix Instances を選択する。


これれで、選択されたプリミティブは位置を固定できたので、今度はUCFに書き出そう。
FileメニューからSave Designを選択するとUCFに配置制約が書き出される。
下が書き加えられたddr2_sdram_cont_instのコンポーネントの配置制約だ。


（注：PlanAheadではスライスなどの構成要素をプリミティブと読んでいるようなので、PlanAheadを使用しているときはプリミティブと呼ぶことにします。それ以外は、コンポーネント(FPGA Editor)と呼ぶことにします。ツールごとに名前が統一されていないですね。）

Google Chrome でPDFを開くとエラーになる

私はGoogle Chromeをメインのブラウザとして使っているが、近頃PDFファイルのリンクをクリックして、PDFを表示しようとすると、下のようなダイアログが出てエラーになってしまっていた。（現在のバージョンはChromeは5.0.375.125, Adobe Reader 9.3.3）


これを何とかしようとネットで検索したら、”Google ChromeでPDFが開けない (Adobe Reader 9.2.0)”がヒットした。この記事によるとAdobe Readerの環境設定のインターネットをいじれば解消する人のことだった。やってみたところエラーが解消できた。この記事では3つの項目のチェックを外していたが、1つだけチェックを外せばうまく行ったので、紹介する。
まずは、Adobe Readerを立ち上げて、編集メニューから環境設定を選んでダイアログを表示させる。左のペインのインターネットを選択する。”Web表示用に最適化を許可”のチェックを外す。


これでOKボタンをクリックすると、Google Chromeで問題なくPDFを表示することができるようになった。良かった。

（2010/08/10：追記）
”バックグラウンドでのダウンロードを許可”のチェックも外さないとだめみたいです。

Spartan-3A Starter KitでCMOSカメラ・ディスプレイ回路８（インプリメント２）

武内さんのご指摘で、クロックドメインのバグを修正して、TIG制約をコメントアウトして、やってみようと思ったが、clk_camのクロックが間違っていた。sysclkをDCMに通した25MHzを使ってしまった。正しくは、CMOSカメラから帰ってきたcam_pclkをDCMを通して、25MHzのクロックとする必要があった。
修正したところ、Placeでエラーが発生した。エラーの内容を下に示す。

ERROR:Place:1012 - A clock IOB / DCM component pair have been found that are not placed at an optimal clock IOB / DCM site pair. The clock component ＜clk_cam_dcm_inst/DCM_SP_INST＞ is placed at site ＜DCM_X1Y3＞. The clock IO/DCM site can be paired if they are placed/locked in the same quadrant. The IO component ＜cam_pclk＞ is placed at site .
This will not allow the use of the fast path between the IO and the Clock buffer. If this sub optimal condition is acceptable for this design, you may use the CLOCK_DEDICATED_ROUTE constraint in the .ucf file to demote this message to a WARNING and allow your design to continue. However, the use of this override is highly discouraged as it may lead to very poor timing results. It is recommended that this error condition be corrected in the design. A list of all the COMP.PINs used in this clock placement rule is listed below. These examples can be used directly in the .ucf file to override this clock rule.
< NET "cam_pclk" CLOCK_DEDICATED_ROUTE = FALSE; >
< PIN "clk_cam_dcm_inst/DCM_SP_INST.CLKIN" CLOCK_DEDICATED_ROUTE = FALSE; >

現在は下の制約で、dcm_DDR2_clk_dcmをいいところに配置しているのが問題だろうか？

INST "dcm_CAM_DDR2_clk_inst/dcm_DDR2_clk_dcm" LOC = DCM_X2Y3;

状況をPlanAheadで見てみたが、dcm_DDR2_clk_dcmを取り敢えず、隣のDCM_X1Y3の位置に替えてみることにした。

INST "dcm_CAM_DDR2_clk_inst/dcm_DDR2_clk_dcm" LOC = DCM_X1Y3;

下がPlanAheadで見たdcm_DDR2_clk_dcm。


これでインプリメントしてみたところ、今度はdcm_DDR2_clk_dcmがエラーになってしまった。

ERROR:Place:1012 - A clock IOB / DCM component pair have been found that are not placed at an optimal clock IOB / DCM site pair. The clock component ＜dcm_CAM_DDR2_clk_inst/dcm_DDR2_clk_dcm/DCM_SP＞ is placed at site ＜DCM_X1Y3＞. The clock IO/DCM site can be paired if they are placed/locked in the same quadrant. The IO component ＜sysclk＞ is placed at site ＜PAD54＞.
This will not allow the use of the fast path between the IO and the Clock buffer. If this sub optimal condition is acceptable for this design, you may use the CLOCK_DEDICATED_ROUTE constraint in the .ucf file to demote this message to a WARNING and allow your design to continue. However, the use of this override is highly discouraged as it may lead to very poor timing results. It is recommended that this error condition be corrected in he design. A list of all the COMP.PINs used in this clock placement rule is listed below. These examples can be used directly in the .ucf file to override this clock rule.
< NET "sysclk" CLOCK_DEDICATED_ROUTE = FALSE; >
< PIN "dcm_CAM_DDR2_clk_inst/dcm_DDR2_clk_dcm/DCM_SP.CLKIN" CLOCK_DEDICATED_ROUTE = FALSE; >

このへんの配線リソースは厳しいのだろうか？
ここでユーザーズガイドを見てみようということで、”Spartan- ジェネレーション FPGA ユーザー ガイド v1.4 (日本語版)”を見てみた。
DCMを見てみると、そうか上下のDCMはグローバル用で、左右のDCMは左右それぞれのクロックネットワーク用なんだ！！！知らなかった。。。
次に、47ページの”図 2-2 : Spartan-3E/3A/3AN/3A DSP の内部区画ベースのクロックインフラストラクチャ”を見たら原因がわかった。上にグローバルクロック入力は8つあり、DCMは2つあるがそれぞれ近い方の4つのグローバルクロック入力がそれぞれDCMにつながるようだ。下に、図 2-2の一部を転載させていただく。


だから、dcm_DDR2_clk_dcmをDCM_X1Y3に移動したらエラーになったんだ！！！
dcm_DDR2_clk_dcmをDCM_X2Y3の位置に戻した時のPlanAheadの画面を下に示す。


それでは、cam_pclkのGCLKの位置を変える必要があるということだと思う。でも、配線がないので変えられない。。。しょうが無いので、下の制約を加えてインプリメントした。

NET "cam_pclk" CLOCK_DEDICATED_ROUTE = FALSE;
PIN "clk_cam_dcm_inst/DCM_SP_INST.CLKIN" CLOCK_DEDICATED_ROUTE = FALSE;

そうしたら、clk_ddr2のパスでタイミングエラーが発生してしまった。


かなりハマってきてしまったが、心を落ち着けて、状況を検討してみることにする。

７月のFPGAの部屋のアクセス数

７月のFPGAの部屋のアクセス数は、46.212アクセスでした。皆さん、見ていただいてありがとうございました。
アクセスの月別集計を見ると平日にアクセスが多くて、土日は少ないようです。


今度は、７月の検索語のトップ30です。


一番上は”fpgaの部屋”でした。夏休みなので、自由研究も上位です。手押しカンナ盤が上位に来ているのが意外でした。需要があるのかな？tortoisesvnも上位ですね。
今後とも、よろしくお願いします。

Spartan-3A Starter KitでCMOSカメラ・ディスプレイ回路７（インプリメント）

Spartan-3A Starter KitでCMOSカメラ・ディスプレイ回路のインプリメントを行った。
DDR2 SDRAMのUCFは以前作ったDDR2_burst_testからほとんどコピーした。後の、CMOSカメラ関係のUCFはPlanAheadを使って配置した。VGA信号関係は、他のところからコピーして修正した。UCFが完成したので、早速ISE12.1でインプリメントをしてみた。インプリメント結果を下に示す。


LUTの使用率は8%だった。Timinigエラーが1つある。これを見てみよう。Project Navigator のProcessesウインドウのImplement Design -> Place & Route -> Generate Post-Place & Route Static Timing -> Analyze Post-Place & Route Static Timing をダブルクリックしてTiming Analyzerを立ち上げる。下がTiming Analyzerの画面。


（2010/08/04：修正）（このTimingエラーは、overflowやunderflowの結果を保持しようとして、保持回路を付けたときにクロックドメインを間違えたため発生したエラーでした。クロックドメインを修正したら発生しなくなりました。訂正致します。この記事は、ネットを使用したTIG制約の例として残しますが、原因となったエラーはバグでした）
IPを使った非同期FIFOのoverflow やunderflow がエラーとなっている。clk_ddr2(133.33MHz)からclk_cam(25MHz) へのパスがエラーとなっている。本来、非同期FIFOはWrite, Readの依存関係がないクロックを入れて使うものあり、その辺のことは考えてあるので、clk_ddr2とclk_cam間の制約は無しで良いはずである。しかもインスタンスがよくわからないということがあるので、clk_ddr2とclk_cam間のすべての制約を無視するように設定する。現在の回路はclk_ddr2, clk_cam間のやりとりはすべて非同期FIFOのIPを通すか、タイミング的に十分で問題ない様に考えてある（はず？）。
それで、TIG制約を使用して、clk_ddr2とclk_cam間の制約を除外することにする。
Project Navigator のProcessesウインドウのUser Constraints -> Create Timing Constrains をダブルクリックしてConstrains Editor を立ち上げる。
まずは、clk_ddr2とclk_camのグループ制約を作成する。左のConstraint Type からGroup Constrains -> DownSteram Elements By Nets を選択する。clk_ddr2とclk_cam のグループ制約を作る。


次はTIG制約を作ろう。左のConstraint Type からTiming Constrains -> Exceptions -> Paths を選択する。
右上の欄に、TS_CLK_DDR2_to_CAM制約を追加する。


これでTIG制約はできたので、保存すると下の制約がUCFファイルに追加された。

#Created by Constraints Editor (xc3s700a-fg484-4) - 2010/08/03
NET "clk_cam" TNM_NET = TMN_CLK_CAM;
NET "clk_ddr2" TNM_NET = TMN_CLK_DDR2;
TIMESPEC TS_CLK_DDR2_to_CAM = FROM "TMN_CLK_DDR2" TO "TMN_CLK_CAM" TIG;

これでもう一度インプリメントすると、タイミングエラーが無くなった。


これで、インプリメントは終了したので、いよいよSpartan-3A Starter kitにダウンロードして確かめてみるのだが、コネクタの配線（電源）を間違えるとCMOS基板がだめになってしまうので慎重にやることにする。