映画（Dr.パルナサスの鏡）を見てきた

今日はイーアスでDr.パルナサスの鏡を見てきた。毎週、映画をみている。とても不思議な映画だった。良いのか悪いのか分からないというのが正直なところだが、後味は悪くなかった気がする。
来週は、@eleの新年会が土曜日に、家具作りサークルの会合が日曜日にある。

キャラクタ生成コントローラのVerilogコーディングは一応終了して、キャラクタを書きまくるステートマシンもできたので、ビットマップVGAコントローラ、キャラクタ生成コントローラ、DDR2 SDRAMコントローラを統合するトップモジュールができたら、もうすぐシミュレーションすることができる。その上にテストベンチが必要だが、クロックとリセットの処理だけで、その他は他のモジュールがやってくれる。

X-fest 2010に行ってきました

今日はAVNET社のX-fest2010に行ってきました。
最初に10時10分から基調講演。代理店商社の役割ということで、申し訳ないですが、あまり関係ない話でした。
次は、ACTIVE-HDLとModelSim DEの話。”Xilinx FPGA検証を効率的に行うActive-HDLのご紹介(アルデック･ジャパン株式会社)、ModelSim DE Simulation and Verification(メンター・グラフィックス・ジャパン株式会社)”
ACTIVE-HDLはModelSimと同様に使えて安いんだよということを言っていました。ModelSim DEはアサーションが出来て手頃？なお値段のようです。他にも魅力的な機能が色々ありました。テキストベースデータフローも良さそう。ModelSim StarterでもOVLアサーションライブラリは使えるとのことなので、やってみよう。

お弁当を食べた。見た目も美味しそうだったが、食べても美味しかった。ごちそうさまでした。

”Spartan-6 Hard Memory Controller を使用した外付けメモリーのインターフェースの設計”
色々な注意点が聞けてよかった。日本語の資料として使えそう。ショックなのはMCBがSecureIPだったこと、ModelSim Starter ではだめで、ISimでシミュレーションする必要があるとのこと。Veritakでもだめだ。

”Spartan-6 ギガビットトランシーバとPCI Expressエンドポイントブロックの設計”
最初のKキャラクタや8B10B、エラスティックバッファなどは、すでに知っていることだった。後半はXilinxのPCIeのエンドポイントブロックについて、詳しい説明が聞けて良かった。しかし、ハードIPのPCIeエンドポイントはやはり、SecureIPで春のISE12.1まで待たなければISimでシミュレーション出来ないとのこと。ModeSim のPEやSEではOKなんだろう？

ティータイム。私はコーヒーが飲めないので、ペパーミント＆ジンジャーティーをいただいた。美味しかった。

”最新FPGA用オンボードDC-DC電源モジュールの提案と最適設計のポイント”
日本エマソンの方が説明された。熱設計やLDOの効率など一般的なこと。それはもうわかっているから、もう少し、具体例を入れて、Virtex-5の電源はこのように設計したとか、実際に設計したボードの具体例、数値を上げて説明して欲しかった。もう1つの電源の話の方がテキストを見たら面白そうだったかも？

”ザイリンクス社製VIRTEX®-6対応PCI Express®用iDMAC®ソリューション”
DMACなので、私の仕事にも関係している。スキャッター・ギャザーDMAなので良いと思ったが、やはり設定レジスタに設定するペナルティが大きい気がする。ホストの論理アドレスの物理アドレスへのマップを読んで、DMACの設定レジスタに設定するペナルティが結構大きいんじゃないか？PIOに比べて1MBくらいからメリットが出ると言っていたし。。。それからローカルバスはビット数が多いが、バイトレーンの入れ替えが大変そうだと思う。アドレス境界がビット幅の境界だったら良いが、そうでないとバイトレーンを入れ替える必要がでてくるんじゃないかと思う。その辺を聞いてきたかった。

ニケボードは抽選とアナウスされていたが、最後に全員に配布されることになった。たぶん数が足りたんだろう。1枚頂いてきた。


コネクタを入れると、iPhoneと大体同じ大きさ。
裏面、コネクタとスペーサがついている。シリアルナンバー0095だろうか？


後で、ニケボードを使ってみようと思う。

（追加）
もらってきたX-festのセミナーのプレゼンを集めた本は見ているだけでも参考になる。とても良いと思う。

何年か前に、出来立ての東京コンファレンスセンター・品川に行ったときには、何か臭くて、（建材か接着剤のにおい？）がひどくて、途中で帰ってきたことがあったが、今回行ったら、まだにおいはするものの、我慢できる範囲でよかった。なんでこんなに臭いのだろうか？

FPGAの部屋の135万アクセス目

自分でFPGAの部屋の135万アクセス目をゲットしました。今後とも宜しくお願いします。


ブラウザはGoogle Chrome4 で、初音ミクのテーマを使っています。拡張機能は便利ですね。。。IE Tabなどを入れています。マウスジェスチャーは入れていません。マウスのホイールを左右に倒すスイッチにブラウザの進む、戻るを割り当てています。

Spartan-6 FPGA SP605 評価キットが来ました

Spartan-6 FPGA SP605 評価キットが来たので、試せるようになりました。
2つ箱が来て、１つは本体のボードと電源（白い箱）です。


SP605の方を開けると、パンフレット、説明書と基板が入っていました。


白い箱の方は12V5Aの電源です。


基板の下にはUSBのミニBケーブルが2本とLANケーブル、CFカード、USBメモリ（ISEのプロジェクトや資料が入っていました）DVI-I―VGA変換プラグが入っていました。


基板の写真です。


これが裏です。スペーサーにゴム足がついています。PCIeコネクタに入れなくてもスタンドアロンで使えますね。


後で、いろいろ試してみようと思います。

キャラクタ生成コントローラをVerilogコーディング中

現在、キャラクタ生成コントローラをVerilogコーディング中だ。ステートマシンをどう構成するかを悩んでしまって、遅れている。やはり倍率があると1段階面倒になって、すぐにできなかった。次に改訂する場合には、今度はフォントをバッファリングするつもりなので、今ちゃんと作っておかないと更に面倒になる。
こんな感じでFIFOはCORE Generator にお任せだ。VerilogコーディングはNotepad++ で書いている。19インチのディスプレイで書いているが、もう少し横幅が欲しい。Verilogソースを2つ並べて余裕があると良いな。。。
現在は右のソースを参照して、左で書いている。include したparameter を見ながら書くと便利。また、Verilogソースが長くなると右のソースを左に複製して、右で書きながら、左でregやwire の定義を書いていたりする。また右で書いているときに、前後のソースを参照したいときは、左で表示しながら右で書くこともある。2画面にしないと、Verilogコーディングができなくなってしまった。。。

今日も映画（アバター）を見てきた。

今日も映画、アバターを3Dで見てきた。初めて3Dを見たが本当に良かった。やはり2Dとは臨場感が違う。細かいことを言えば、画像の深さ方法（Z方向）が段階的かな？と思ったのは思った。しかし、2Dとは比べものにならない。CG使いまくりだろうな？ぜひ3Dで見るべきだと思う。
気持ち悪くなるのを心配していたが、全く問題なかった。万博やディズニーランドでみた3D画像よりもとび出しを少なくしてあるのだう。
3Dテレビに興味はなかったが、今日、3Dの映画を見たことで興味がでてきた。これから3Dの映画を見てみよう。

２つのクロックドメインがある時の同期リセットの入れ方

今作製しているキャラクタ生成コントローラは、65MHzと150MHzの2つのクロックドメインを持つ。ステートマシンやフリップフロップなどは、同期リセットを使用している。その場合に、リセットは1系統、例えば、スイッチからチャタリング除去回路（無い場合もあるけど）を通って、そのままFFなどのリセットに入れたのでは、本当はまずいのではないだろうか？
今まで、仕事では非同期リセットのみだったので、あまり考えなかったが、リセットをそれぞれのクロックで2段に同期化して、それぞれのクロックドメインのリセット信号としてみようと思う。
CORE Generator で作った同期FIFOはそのクロックドメインのリセット信号を与えれば良いが、非同期FIFOはどうだろうか？早速、Fifo Generator を起動してみてみた。


Enable Reset Synchronization というオプションがあった。これで、それぞれのクロックの同期化しているようだ。これだとリセット端子はRST1本だが、Enable Reset Synchronizationのチェックを外すとWR_RST, RD_RSTの2つに分離する。

WR_RST, RD_RSTの2つに分離した状態で、それぞれのクロックドメインのリセット信号を入れてやってみよう。

オーシャンズを見てきた

今日は、オーシャンズという映画を見てきた。NHKのドキュメンタリーの様だった。鳥が飛び込んでイワシを取る様子が凄かった。どうやって撮ったんだろうと思う映像が沢山あった。しかし、ストーリーがないので、眠くなって途中で寝てしまった。
明日は、アバターを見に行く予定。結構、映画を見に行っている。

CORE Generatorで作った分散RAMの同期FIFOのシミュレーション

”CORE Generatorで分散RAM（SLICEM)の同期FIFOを生成１”、”CORE Generatorで分散RAM（SLICEM)の同期FIFOを生成２”で作った同期FIFOをシミュレーションして、どのような動作をするのかを確かめてみた。

まずは、テストベンチを下に示す。

`timescale 100ps / 1ps
module cmd_sync_fifo_tb;

    parameter CLK_PERIOD = 150;

    // Inputs
    reg clk;
    reg srst;
    reg [31:0] din;
    reg wr_en;
    reg rd_en;

    // Outputs
    wire [31:0] dout;
    wire full;
    wire almost_full;
    wire overflow;
    wire empty;
    wire almost_empty;
    wire underflow;
    wire [3:0] data_count;

    integer i;
    
    // Instantiate the Unit Under Test (UUT)
    cmd_sync_fifo uut (
        .clk(clk), 
        .srst(srst), 
        .din(din), 
        .wr_en(wr_en), 
        .rd_en(rd_en), 
        .dout(dout), 
        .full(full), 
        .almost_full(almost_full), 
        .overflow(overflow), 
        .empty(empty), 
        .almost_empty(almost_empty), 
        .underflow(underflow), 
        .data_count(data_count)
    );

    initial begin
        // Initialize Inputs
        srst = 0;
        din = 0;
        wr_en = 0;
        rd_en = 0;

        // Wait 100 ns for global reset to finish
        #1000     srst = 1; // reset
        #1000     srst = 0;
        
        @(posedge clk); 
        #10        rd_en = 1; // なにもFIFOに入っていない時にrd_en=1をしているので、UNDERFLOWが出るはず
        @(posedge clk);
        #10        rd_en = 0;
        @(posedge clk); // 3クロック分Wait
        @(posedge clk);
        @(posedge clk);
        #10        srst = 1; // UNDERFLOW をreset;
        @(posedge clk);
        #10        srst = 0;
        @(posedge clk);
        #10        wr_en = 1; din = 32'h12345678; // 1データ書き込み
        @(posedge clk);
        #10        din = 32'h11223344; // もう1つデータを書き込み
        @(posedge clk);
        #10        wr_en = 0; // 書き込み終了
        @(posedge clk); 
        #10;
        @(posedge clk);
        #10        rd_en = 1; // 1個のデータをRead
        @(posedge clk);
        #10        rd_en = 0;
        @(posedge clk);
        @(posedge clk);
        #10        wr_en = 1; // wr_en を1にして、16個書くとOVERFLOWが出るはず
        for (i=0; i<16; i=i+1) begin
            din <= din +32'h1;
            @(posedge clk);
            #10;
        end

        #1000    $stop;
    end
    
    always begin
       #(CLK_PERIOD/2)    clk = 1'b1 ;
       #(CLK_PERIOD/2)    clk = 1'b0 ;
    end
      
endmodule

最初にemptyの時にrd_enを入れて、Underflowを出そうとしている。リセットしてから、２つデータをWriteしてから、１つReadする。その後で、16回Writeして、Overflowを出させるつもり。
さて、Veritakでプロジェクトを作製してコンパイルし、シミュレーションを走らせる。その結果の波形を下に示す。


同期FIFOにデータがないのにrd_enを1にすると、Underflowが1クロック期間1となった（黒いカーソルの所）。emptyが0になったときにデータが出ているのが確認できる。rd_enを1クロック期間1にすると、次のデータが出力される。Overflowを出すために、ひたすらWriteしていくと、data_countが+1されて、データがWriteされる。驚いたことに0x12でfullが1になった。16深度のはずなのに18深度なの？次のクロックでもWriteするとOverflowが1となった。

次に、First-Word Fall-ThroughでないStandard FIFOを選んだ時の同じテストベンチでのシミュレーション結果を下に示す。Standard FIFOは、data_countが最大4ビットとなった。


こちらはUnderflowは同じだが、fullはWriteしていくと、data_countが0xfから0になって、その時にfullが1になる。16深度ならば、言わば合理的な仕様かな？次にOverflowが出るので、本当に16深度のようだ。

2つの分散メモリ使用の同期FIFOをシミュレーションしてみて、こんなに違うとは夢にも思わなかった。やはりシミュレーションしてみるもんだと思った。

CORE Generatorで分散RAM（SLICEM)の同期FIFOを生成２

”CORE Generatorで分散RAM（SLICEM)の同期FIFOを生成１”の続き。

Optional Flagsだが、Almost Full FlagとAlmost Empty Flagを入れておこう。これらを入れておくと、後ろの段でクリティカルパス回避のためにFFで受けることができるようになる。
主にシミュレーション用にOverflow FlagとUnderflow Flagも入れておこう。どこにもつながなければ、論理合成で削除してくれるだろう。”Next >”ボタンをクリックする。


InitializationではReset関係の設定。同期リセットとした。Reset時のDoutの値は０とした。（デフォルト）”Next >”ボタンをクリックする。


Data Count OptionsでData Countにチェックを入れる。Data Countを使用して幾つ書いたかを知ることができる。Data Count Width は5ビットである（First-Word Fall-Throughの場合）。”Next >”ボタンをクリックする。


FIFO Generator Summaryが表示される。Generateボタンをクリックする。


これで同期FIFOの生成が始まる。生成にはけっこう時間がかかる。これで、cmd_sync_fifoが生成できた。



(2010/01/22:追記）
First-Word Fall-ThroughはData Count Width が5ビットだが、Standard FIFOを選ぶとData Count Width は4ビットとなる。16個目はどうやって表すのだろうか？なぞ？あまりCoreGenのFIFO使ったことが無いので。。。最下位ビットが削除することで、バス幅が切り詰められるとデータシートに書いてある。シミュレーションでFirst-Word Fall-ThroughとStandard FIFOの動作の違いを調べてみた。

CORE Generatorで分散RAM（SLICEM)の同期FIFOを生成１

現在、キャラクタ生成コントローラを作製中だ。
まだ中身はほとんど作っていないが、Char_Gen_Controller.vとCommand_FIFO.v を作った。今回の同期FIFOと非同期FIFOはCoreGenを使って生成する予定のなので、FIFO Generatorで生成する。
自分のブログを見返してみるとCORE Generatorのことを書いていなかったので、やり方を書いてみようと思った。たぶん、だれでも使えると思うんだけど、チュートリアル的な物として書いておこう。

まずはISE11.4のProject NavigatorのSourceウインドウで右クリックをして、右クリックメニューの中からNew Source...を選択する。


New Source Wizardダイアログが開く。左のペインから”IP(CORE Generator & Architecture Wizard)”をクリックする。File Name のテキストボックスにファイル名を入力する。”Next >”ボタンをクリックする。


今回は同期FIFOを生成するので、Memories & Storage Elements を展開し、その下のFIFOsを展開するとFifo Generator 5.3が出てくるので、これを選択し、”Next >”ボタンをクリックする。


Summaryが出るので、Finishボタンをクリックする。


Fifo Generatorが立ち上がる。今回は分散RAM、つまりルックアップテーブルのうちのSLICEMを使用する16深度の同期FIFOを作るので、Common ClockのDistributed RAMのラジオボタンをクリックする。これがBlock RAMだと、当然ながらBRAMを使用する。Independent Clocksを使うと非同期FIFOが生成される。”Next >”ボタンをクリックする。


Read ModeはFirst-Word Fall-Throughを選択する。First-Word Fall-Throughについては、”Virtex4のFIFO（FWFTモード)”で説明している。Standard FIFOを選ぶとRD_ENを1にした1クロック後にReadデータが出てくるが、First-Word Fall-Throughを選ぶと、emptyでなければ、すでにReadデータが出ている。RD_ENは、データを読んだというイネーブルで、1にすると次のクロックで、次のデータが出てくる（emptyでなければ？）。First-Word Fall-Throughの方が使い易いので、いつもFirst-Word Fall-Throughを使っている。
Data Port Parameters を選択する。Write Widthを32に、Write Depthを16に設定する。これで32個のSLICEMが使用されることになる。”Next >”ボタンをクリックする。


（2010/01/21:追記　以前の画像は、First-Word Fall-ThroughでなくStandard FIFOだったので変更しました。）

今日はこの辺で終了とする。

キャラクタ生成コントローラの仕様２

前回、”キャラクタ生成コントローラの仕様”で、キャラクタ生成コントローラ全体の仕様を考えて、ブロック図を書いてみたが、今度はその下のモジュールのブロック図を書いてみた。
まずはコマンド用FIFOのブロック図を下に示す。


CPUのアドレスはアドレスデコーダに入って、アドレスがデコードされる。自分のアドレスで、最下位の番地が0番地の場合は、0番地用FFにデータバスを貯めておく。8番地を書き込んだ時や、0番地のbit14を1にして書き込んだ場合に、0番地用から8番地用FIFOに各番地のFFの内容を一斉に書き込む。書き込まれたコマンドはキャラクタグラフィックプロセッサに送られる。
次は、キャラクタグラフィックプロセッサだが、キャラクタグラフィックプロセッサ、キャラクタジェネレータROM、画像データ書き込み用FIFOを一緒のブロック図に書くことにする。そのブロック図を下に示す。


主に8番地の”キャラクタを書くVRAMの先頭番地”からVRAMアドレスカウンタに入力される。0番地のbit14が1だと、キャラクタを並べて書くので、8番地の内容は無視して、単に4番地のフォントの倍率を掛けたアドレスを計算してVRAMアドレスカウンタにロードする。VRAMアドレスカウンタの出力はアドレス用FIFOに入力されてアービタに出力される。
0番地のキャラクタコードはキャラクタコードアドレスカウンタにロードされ、行方向のカウンタのアドレスと一緒にキャラクタジェネレータROMのアドレスに入力される。キャラクタジェネレータROMから出力された8ビットのフォントデータは、キャラクタデータ判定回路で判定されて、キャラクタの色データか背景データかをMUXで選択される。その後、Write用データ非同期FIFOに入力されて、アービタに出力される。
背景色を書かない設定になっている場合の背景色の時には、アドレス用非同期FIFOにもWrite用データ非同期FIFOにも書かない。
フォントの倍率が1倍でないときは、倍数に応じて、VRAMアドレスカウンタを進めてアドレス用非同期FIFOに出力する。また、キャラクタデータシフトレジスタは進めずにWrite用データ非同期FIFOに同じデータを書き込んで行くことにする。

大体、仕様が決まったので、次はVerilogコードを書いて行こうと思う。

（2010/01/19:追記）CPUとアービタのクロックドメインが異なるを忘れていたので、書き換えました。

親のウッドデッキ完成

”ウッドデッキを作った”で親の所のウッドデッキを作っていたが、昨日完成した。色は平日に親が塗ったので、昨日は組み立て。基本的にユニットなので、ウッドデッキユニット同士をステンレスボルトで固定した。フェンスもステンレスボルトでウッドデッキユニットに固定し、さらにフェンス同士もステンレスボルトで固定。ステンレスボルト代だけで1万円以上の値段だ。ウッドデッキの値段は、塗料まで入れて9万円までいかない程度。ユニットなので、高めだ。
コーナーには4X4材を切って当ててコーススレッドで固定。これを塗り忘れているので、後ほど塗装予定。
今日は親の所の地デジ用のアンテナを上げる予定。本当に忙しい。。。

SCCBインタフェース回路のVHDLコードの1例

SCCBインタフェース回路の説明を、”SCCBインターフェース回路の説明１（SCCB_Reg_Controller.vhd）”、”SCCBインターフェース回路の説明２（freqdiv.vhd、SCCB_reg_values_ROM.vhd）”、”SCCBインターフェース回路の説明３（One_Transaction_SCCB.vhd）”で説明しただけで終わりにしようと思ったが、メールで聞いてきた方がいらした。その方にはご自分で考えてみて下さいということで返事を送ったが、わからなかった場合に解答例を示しておこうと思う。それに意外に欲しい方が多いかもしれない。
必要な方は、SCCB_Reg_Controller一式をここからダウンロードしてください。例によって、保証はありません。自己責任でお使い下さい。再配布の場合は必ずご連絡下さい。
何か、ここをこうするともっと良くなるとか、バグが有るといったことがありましたら、コメントをお願いします。

キャラクタ生成コントローラの仕様

今回はキャラクタ生成コントローラの仕様を書いていこうと思う。
まずは、CPUからのキャラクタ描画の方法だが、コマンドレジスタとステータスレジスタをCPUにアドレスマップする。そして、コマンドレジスタに、CPUからキャラクタデータを書きこむことによって、キャラクタを描画するものとする。CPUからのキャラクタ描画コマンドは、16深度のコマンドFIFOにためられて、キャラクタグラフィックプロセッサ（名前負けかもしれないけど。。。）に送られる。ここでDDR2 SDRAMのアドレスを計算しながら画像データに変換して、画像データ書き込み用FIFOに送る。その際に、キャラクタグラフィックプロセッサは、フォントのデータとして、キャラクタジェネレータROMを参照する。画像データ書き込み用FIFOは、画像データが入ってきたらアービタに画像データのデータ転送を要求して、データ転送を行う。ブロック図を下図に示す。


（2010/01/19:追記）クロックドメインを分けるのを忘れていた。画像データ書き込み用FIFOまでの回路はCPUの動作希望周波数の65MHz動作となり、画像データ書き込み用FIFOは非同期FIFOとして、アービタの出口は150MHz動作とする。

次に下図にキャラクタ生成コントローラのアドレスマップを示す。


オフセット0番地は漢字も持てるように、16ビット幅のキャラクタコード（とりあえずはアスキーコードのみ）とその色データがある。ビット15には背景を描画するかどうかのビットがある。0を指定すると背景も描画する。その色データは4番地のに書かれている。4番地には倍率の設定もある。等倍にフォントを引き伸ばす。これはスムーズィングできれば良いのだが、今のところ単純に等倍にするので、フォントはでこぼこになるが、とりあえずはこれで行くことにする。
8番地にキャラクタを書くVRAMの先頭番地を書き込む。このアドレスにCPUから書きこむことにより、コマンド用FIFOに入力される。同じ属性の同じキャラクタを異なるVRAMのアドレスに書く場合は0番地、4番地に改めて書き込む必要はなく、8番地にVRAMのアドレスのみを書き込む。
さらに、同じ背景色のキャラクタを並べて書く場合は、0番地のbit14を1にしてキャラクタコードと文字の色を0番地に書き込めば、他の番地の書きこむことなしにコマンド用FIFOに投入される。このように２つのコマンド用FIFO投入パスがある。これによって、CPUのIOアクセス数を減らすことができる。
次にステータスレジスタだが、0番地のみステータスレジスタが実装されている。このbit4～0には、コマンドFIFOの残りの容量が割り当てられていて、Readするとその値が読める。最大値は"1000"である。残り容量をCPUが読んで、残り容量分を連続して書き込むことができる。これはFIFOを実装しないで、busyビットを実装するのに比べてCPUのポーリング負荷を減らせる可能性があるが、CPUの書き込みスピードより、キャラクタグラフィックプロセッサが十分に早いと、FIFOが必要ないという可能性も残る。

次回はさらにもう1つ下の仕様を考えて行きたいと思う。

(2010/01/23:変更）
キャラクタ生成コントローラのアドレスマップを変更しました。

(2010/01/31:変更)
キャラクタ生成コントローラのアドレスマップの8番地、VRAMのアドレスを32ビットに拡張しました。

Spartan3A Starter KitのビットマップVGAコントローラのコーディング終了

Spartan3A Starter KitのビットマップVGAコントローラをVerilogでコーディングしてきたが、大体終了した。ISEで論理合成してエラーが出なくなった。これで文法エラーはなくなったと思う。


これでシミュレーションするのが良いのだが、全く図やキャラクタを書く機能が無いので、そこをつけてやらないと表示が出きない。それにマイクロン社のDDR2 SDRAMのモデルからWriteなしにReadした時のデータが"X" になっているのでは？という懸念もある。それならばということで、下図のキャラクタ生成コントローラを先に作ることにした。


通常の状態では、キャラクタ生成コントローラはCPUから設定されるのだが、とりあえずキャラクタを書きまくるハードウェアをつけて、書きまくる状態でテストすることにする。

Digilent社のXilinx Platform Cable USB コンパチ品

Digilent社のXilinx Platform Cable USB コンパチ品がWebサイトに載っています。XUP USB-JTAG Programming Cableだそうです。Webサイトの文章を引用します。

* Compatible with Xilinx Platform Cable USB
* Supports 5V, 3.3V, 2.5V, 1.8V and 1.5V systems
* Compatible with Full-Speed and Hi-Speed USB ports
* Works with ChipScope, EDK, and System Generator
* Indirectly programs SPI and Parallel FLASH memory devices

ChipScopeも使えるそうなので良いですね。
Shippingは3月だそうです。今のところアカディミックしか購入ボタンがありません。89ドルとのことです。写真によると、フライ・ワイヤは別売で、3.95ドルだそうです。これは現在、売っているみたいです。（XUP Fly Wire Assembly）

FPGAにコンフィグするだけならば、たぶん、JTAG-USB Full Speed Module 39.99ドルでも大丈夫だと思います（試してみたことはありません）。JTAG-USB Programming CableでSpartan3 Stater kitにコンフィグしたことはあります。

Spartan3A Starter KitのビットマップVGAコントローラを作製中

Spartan3A Starter KitのビットマップVGAコントローラをVerilogでコーディング中。久しぶりのVerilogなので、だいぶ忘れているところがある。if の後に括弧を書かなかったりして、すっかりVHDLの人になってしまったが、以前自分で書いたVerilogコードを見ながら書いている。
150MHzの動作部分は書き終わって、今度は65MHzつまり1024X768のXGA表示部分を書いている。そういえばXGA解像度なのにVGAコントローラとはおかしいかな？でも、解像度を変更する度に名前が変わるのは嫌なので、VGAで行くことにする。
VHDL, Verilogコード書きには、Notepad++を2列で使用している。19インチディスプレイなので、横が狭い。もう少し横幅のあるディスプレイが欲しい。。。そうすれば、もっとVerilogコードを見やすく表示することができるのに。。。
現在のVerilogコード作成状況を下に示す。


（2010/01/14：追記）
Verilogコーディングは終了したので、ISEで論理合成かけたら、真っ赤にエラーが出た。だいぶ修正したが、まだエラーが残っている。
if の判定式の&& をand に間違ってしまった。最近、VHDLばかりだったので、Verilogの頭になっていない。

ウッドデッキを作った

またまたウッドデッキ制作。今度は親のウッドデッキ。
ジョイフル本田のユニット形式のウッドデッキ。97cm X 97cm のウッドデッキのフレームをボルト連結していってウッドデッキを作る。ステンレスのボルトを外せば、簡単にばらせるのでウッドデッキを外すのも便利。フレームの上にはパティオプレートと呼ばれているスノコをフレームにはめ込めば、お手軽にウッドデッキが完成する。パティオプレートを外せば家の塗装の足場も組めます。フェンスのキットもあってラティスやクロスをはめ込めるようになっている。いつもクロスのフェンスを買っている。
4X4材を買ってきて、15cm 切断して足にしたのだが、165mm の丸のこで89mm は直接切れなかった。T字型の丸のこガイド（こんなに長くないけど。。。）をつけて表から切り込みを入れて、裏かもう一度切りこんで切断した。少し筋がついたけど切れました。足にプレートをつけて、そのプレートをフレームに木ねじ止めするとフレームは完成。下の写真はフレームを4つ並べたところ。

Spartan3A Starter KitのビットマップVGAコントローラの仕様３（レイテンシの測定２）

今回は、ROWアドレスやバンクが異なる（つまりプリチャージ、ACTコマンドを入れなければならない）Write, ReadコマンドがFIFOに詰まっている場合のレイテンシについてシミュレーションしてみた。前回はReadコマンドが詰まっている時というつもりだったが、現在のテストベンチの構成だと、Wrteして、Readという方が修正が楽だったので、たぶんレイテンシに差はないはずなので、この構成でやってみた。
シミュレーションの結果を下に示す。


上図は、DDR2 SDRAMコントローラへのWrite, Read要求用のFIFOがFULLになったところのRead要求を入力してから、Readされた値がoutput_data に出てくるまでの時間を測定している。測定した時間は1340nsec という情けないような値だ。。。これをビットマップVGAコントローラの動作クロック65MHzの周期15.38nsec で割ると、約87クロックとなる。87に一番近い2の累乗は128なので、ビットマップVGAコントローラの非同期FIFOの深度は256とする。深度の半分128word (1word = 16bits) まで減ったらDDR2 SDRAMコントローラへRead要求を出すことにする。
この時のDDR2 SDRAMコントローラのスループットは、上図の区間にWriteコマンドが8個、Readデータが9個出ていたので、(8+9) X 4バースト X 2バイト = 136バイトのデータ転送を行っている。時間は1340nsec かかっているので、101KBytes/sec となる。MegaでなくてKiloだ。。。がっくり。。。フルバーストするとスループットは600MBytes/sec となるので、1/5940となっている。
アクセス毎にROWアドレスが違っていると、このように効率が落ちてしまう。この場合、バンクがいくつあってもスループットには貢献しないので、パソコンでやっても同様になるはずだ。ただし、キャッシュラインの関係でバースト長が長く設定されている場合はもう少しスループットが良くなるはず。それでも倍位かな？

（注）当然、動作クロックが違うとレイテンシ、スループットは異なりますが、性能の比率としては同様になるはずと思っています。

Spartan3A Starter KitのビットマップVGAコントローラの仕様３（レイテンシの測定）

今回はSpartan3A Starter Kitで自作したDDR2 SDRAMコントローラのレイテンシを測定する。Veritakシミュレータでシミュレーションをして、Write、Readのレイテンシを測定する。
本当はReadだけで良いのだが、ついでにWriteのレイテンシも測定したい。
まずはinitialize_end が1（初期化が終了）してから最初のWriteアクセス。これはACT（アクティベート）コマンドを入れているので、レイテンシは多少長い。


この場合のWriteレイテンシは約87nsec となった。（黒いカーソルから赤いカーソルまで）上図で説明すると、read_writeが0の時がWriteなので、addr_fifo_wrenが1の時にアドレスの書き込みとなって、ここでDDR2 SDRAMへのWriteを要求している（同時にWriteデータもFIFOに書き込んでいるはず）。そこからDDR2 SDRAMのWriteした時点までをWriteレイテンシとしている。

同一ROWアドレス、同一バンクがアクティベートされていれば、ACTコマンドを入れずにWriteコマンドやReadコマンドを入れることができる。自作のDDR2 SDRAMコントローラはバンクを１つしかアクティベートしないので、ROWアドレスか、バンクが異なる場合はプリチャージしてACTコマンドを入れる必要があるので、この場合はレイテンシが伸びてしまう。通常はこうなるが、リフレッシュの場合にプリチャージをするので、その後の1発目のWriteは上図のレイテンシとなる。
次にReadの場合のレイテンシを示す。この場合はWriteで書き込んだROWアドレス、バンクと同一なので、ACTコマンドは省略されている。


READ要求を入れてからデータがREADできるまでのレイテンシは147nsec だった。上図で、read_writeが1の時がReadなので、addr_fifo_wrenが1の時にDDR2 SDRAMへのReadを要求している。そこから、Readデータが読み出されるまでをReadレイテンシとしている。
このReadは、プリチャージをしていない場合なので、プリチャージをする場合を考えてみる。Writeの後にReadした時に、プリチャージとACTコマンドが入った場合のWriteコマンドとReadコマンドの間隔は113nsec となった。次に、Writeの後にReadした時に、プリチャージとACTコマンドが入らない場合のWriteコマンドとReadコマンドの間隔は33nsec だった。よって、80nsec がプリチャージとACTコマンドのコストということができると思う。

次にリフレッシュによるレイテンシについて、みて行こうと思う。リフレッシュのタイミングを下に示す。これは次のバーストのためにプリチャージしてACTコマンドを入れたときにリフレッシュが起きて、また同じACTコマンドを入れ直している例だ。下図に示す。


この場合には、上図に示すように、180nsec のレイテンシが増加することになる。

これらのシミュレーション波形を見ると、最悪の場合は、ROWアドレスやバンクが異なる（つまりプリチャージ、ACTコマンドを入れなければならない）ReadコマンドがFIFOに詰まっている場合だと思う。そのような場合をシミュレーションによって創りだすことによって、ビットマップVGAコントローラがRead要求をした時のレイテンシの最悪値を求めたいと思う。

FC2ブログの不具合

どうやら、FC2ブログの不具合？（たぶん）で画像(PNG)のサムネイルが投稿できなくなりました。ブログが書けないので、修復するまで、ビットマップVGAコントローラの記事はお休みします。日記は書きます。私も非常に残念ですが、ご了承下さい。

（追記）
GIFファイルだったらサムネイルを作ってくれるのでGIFでブログを書こうと思います。ですが、今度はパソコンのあるリビングの照明が故障してしまいました。今日、蛍光灯を買ってきて修理しようと思います。今日の夜からFPGAのブログを再開します。

Spartan3A Starter KitのビットマップVGAコントローラの仕様２

”Spartan3A Starter KitのビットマップVGAコントローラの仕様１”の続き。今度はビットマップVGAコントローラの内部構成を考える。
ビットマップVGAコントローラの内部ブロック図を下に示す。

　　　　　ビットマップVGAコントローラの内部ブロック図

上図で、いつもの水平カウンタ、垂直カウンタ、それに伴うHSYNC（垂直同期）、VSYNC（垂直同期）を出力する回路がある。非同期FIFOは150MHzのDDR2 SDRAMコントローラと65MHzのビットマップVGAコントローラをクロックドメインを切り替えるために使用する。非同期FIFOは、ビットマップの画像データをバッファリングしておくためにも使用する。専用の画像メモリが接続されているわけではないため、ビットマップVGAコントローラが画像データを要求しても、すぐには画像データを取得することが出来ない。どうしても画像データのRead要求を発行してからレイテンシが発生してしまう。このレイテンシも変化することが考えられる。例えば、CPUが命令やデータを取得するためにReadデータを読んでいる最中だったら、それが終了するまで、ビットマップVGAコントローラは画像データを取得出来ない。また、もしCPUがメモリを使用していない場合でも、DDR2 SDRAMコントローラにRead要求してからデータが出てくるまでのレイテンシがある。さらに、DDR2 SDRAMがリフレッシュをしている場合も考えられて、その場合には画像データ取得のレイテンシが伸びることが考えられる。
ビットマップVGAコントローラは出力するデータを切らすことが出来ないので、以上で述べてきた最大のレイテンシが発生してもデータを切らすことが無いように非同期FIFOの容量を決定する必要がある。
そして、非同期FIFOからDDR2 SDRAMコントローラへRead要求を出すタイミングを決定する必要がある。ある一定の残り容量のスレッショルドを越えて、データが減った場合にアービタに画像データを要求する方法もあるが、今回は非同期FIFOがつねにFULLになるように制御しようと思う。つまり常にFULLになる様にReadコマンドを発行するわけだ。この方式の欠点は、常にFULLになるように制御するので、Read要求がバーストではなく、シングル転送になり易いことだ。特に非同期FIFOの出力側は65MHzなので、入力側の0.21倍のスループットになっている。こういう構成だと、出ていく方が遅いため、FULLで制御すると確実にDDR2 SDRAMコントローラへのRead要求は単発になるだろう。そうすると効率が悪いか。。。
それでは、やはり、非同期FIFOからDDR2 SDRAMコントローラへRead要求を出すタイミングは非同期FIFOの画像データが3/4か1/2になった時としようと思う。これからRead要求を発行してからReadデータを受け取るまでの最悪のレイテンシを考察してみて、その値でスレッショルド値を決定することにする。非同期FIFOの容量を幾つにするかも、それの考察で決定する。
さて、次にピクセルデータ管理モジュールがある。これは150MHzのクロックドメインに入っている。この詳細なブロック図を下に示す。

ピクセルデータ管理モジュールのブロック図

DDR2 SDRAMの画像データのアドレスをカウントするアドレスカウンタがある。これは1024X768ピクセルカウントすると初期値に戻る。これも将来的には異なるクロックドメイン(65MHz) で動作する回路から初期値を設定できるようにするかもしれない。そのためのインターフェース回路を追加する可能性がある。Readコマンド生成モジュールはDDR2 SDRAMコントローラへのRead要求を生成してアービタに送るモジュールとなっている。

次は、VeritakでのDDR2 SDRAMコントローラのシミュレーション結果を元に最大のレイテンシを考察することにする。アービタのレイテンシも概算で算出して、非同期FIFOのスレッショルド値と容量を決定する。

2009年のFPGAの部屋のアクセス数

2009年のFPGAの部屋のアクセス数は48万7596アクセスでした。皆さん、見ていただいてありがとうございました。

Spartan3A Starter KitのビットマップVGAコントローラの仕様１

以前に作製したSartan3A Starter KitのDDR2 SDRAMコントローラを使ってみるために、グラフィック・コントローラを作って、プロセッサを実装し文字やグラフィックを描画してみようと思う。今のところプロセッサはOpencoresのSH2プロセッサ、Aquariusを考えている。
VGA Video Outputで見てみたが、1024x768, 60Hzで行ってみたい。
1024x768, 60Hzの規格を下に示す。

Pixel Clock 65MHz
Active Video　　　　　　1024ピクセル
Horizontal Front Porch　　 24ピクセル
Horizontal Sync Pulse 　　136ピクセル
Horizontal Back Porch 　　160ピクセル
Vertical Active Video 　　768ライン
Vertical Front Porch 　　　3ライン
Vertical Sync Pulse　　　　 6ライン
Vertical Back Porch 　　　29ライン

ピクセルクロックは65MHzだ。50MHzのクロックをDCMで13/10倍すると65MHzになるので、これを使用する。
DDR2 SDRAMがCPUとグラフィック・コントローラで共有されるUMA（Uniform Memory Access）アーキテクチャとする。Spartan3A Starter Kit のVGAポートのRGBのビット数は4ビットずつなので、合計12ビット。これを2バイトに割り当てると、メモリは約1.6Mバイト必要となる。このデータを1秒間に60フレーム必要とするので、ビットマップVGAコントローラに必要なメモリ帯域は約100Mバイト/秒となる。16ビット幅、DDR2-300の帯域は600Mバイト/秒であるため、メモリ帯域の1/6をビットマップVGAコントローラで使用する。もちろん、リフレッシュやその他無駄な時間があるため、メモリ帯域の占有時間はもっと長くなることが予想されるが、CPUの動作周波数はOpencoresによると、せいぜい50MHzだろうと思うので、メモリ帯域は足りると思われる。（あくまで予想）
DDR2 SDRAMは512Mビットなので、バイトに直すと64Mバイト。そのうちの約1.6Mバイトをグラフィックメモリとして使用する。さらに、CPUがキャラクタを描画するは負荷が重いと思われるので、キャラクタを生成するキャラクタ生成コントローラを付加することにする。
メモリアクセス・データパスのブロック図を下に示す。


上図でビットマップVGAコントローラからのメモリアクセス要求、キャラクタ生成コントローラからのアクセス要求、CPUからのメモリアクセス要求はアービタで優先順位付けされる。ビットマップVGAコントローラからのメモリアクセス要求が最優先でサービスされることになる。
最初の実装では、キャラクタ生成コントローラを実装せずに、ビットマップVGAコントローラとCPUだけを実装することにする。

ISE11.4のXSTとModelSimの差異

今、VHDLコードを書いていて奇妙な現象に遭遇した。ModelSimのシミュレーションでは、問題なく動作しているように見受けられるが、実機が動作しなかった。なぜだろうとかなり調べていたら、XSTとModelSimの解釈が違っているところが見受けられるようだ。
まずは、ソースコードの一部を示す。

library IEEE;
use IEEE.std_logic_1164.all;
use ieee.std_logic_unsigned.all;
use ieee.std_logic_arith.all;

...

constant THRESHOLD_LEVEL : integer := 6; -- 符号化する数値の下限

attribute keep : string;
attribute keep of h_data_th : signal is "TRUE";
attribute keep of h_data_9bits : signal is "TRUE";
begin


...

    h_data_9bits <= ('0'&bram_rd_data) - ('0'&bram_data_1d);
    v_data_9bits <= ('0'&ydata_1d) - ('0'&bram_data_1d);
    d_data_9bits <= ('0'&cam_ydata_2d) - ('0'&bram_data_1d);

...

    -- スレッショルド処理を行ったh, v, d データ
    th_level_9bit <= CONV_STD_LOGIC_VECTOR(THRESHOLD_LEVEL, 9);
    -- th_level_9bit_mi <= not(th_level_9bit-1);
    th_level_9bit_mi <= not(th_level_9bit)+1;
    h_data_th<=(others => '0') when signed(h_data_9bits)>signed(th_level_9bit_mi) and signed(h_data_9bits)<signed(th_level_9bit) else h_data_9bits;
    v_data_th<=(others => '0') when signed(v_data_9bits)>signed(th_level_9bit_mi) and signed(v_data_9bits)<signed(th_level_9bit) else v_data_9bits;
    d_data_th<=(others => '0') when signed(d_data_9bits)>signed(th_level_9bit_mi) and signed(d_data_9bits)<signed(th_level_9bit) else d_data_9bits;

結局は、小さい値を0に丸める回路を生成しようとしている。その場合のth_level_9bit_mi が問題となった。上のVHDLコードでModelSimではエラーやウォーニングなしにコンパイルが通って、シミュレーションでも正しい値が出ていた。


（注：h_data_9bits とh_data_thに 注目すると、h_data_9bits の002 がh_data_th では000 に丸められている）
ISE11.4での結果がおかしいので、ChipScopeを入れて監視しようとすると、h_data_th をKeepしていたはずが、信号がなくなってh_data_th_mi だけになってしまった。(h_data_th_mi <= not (h_data_th-1);、ちなみにどちらも2の補数表示の同じ絶対値のマイナスの数を計算する式)
ChipScope Analyzer の結果を見ると、全く丸めていない。


おかしいので、XSTのレポートを見ると、データ幅がちがうというウォーニングが出ていた。

WARNING Xst:1610 - "C:/HDL/FndISEWork/DWM2008_07/CamDispCntrl_SRAM_MPWavelet_inv/Sources/Camera_Controller.vhd" line 876: Width mismatch. has a width of 9 bits but assigned expression is 10-bit wide.

9ビットの予定なのに10ビットだそうだ。おかしい？
上のVHDLコードの代わりにコメントアウトされている

th_level_9bit_mi <= not(th_level_9bit-1);

に変更したら、XSTのウォーニングもなくなって正常動作するようになった。ChipScope Analyzer の表示画面を示す。今度は、正常にh_data_th がプローブできた。


何がおかしいのか分からないが、XSTでは、少なくとも9ビットのデータをnot して、+1 するとビット幅が増えてしまうことがあるようだ。注意する必要がありそうだ。

宇宙戦艦ヤマト復活篇を見てきた

今日はイーアスつくばに行って、宇宙戦艦ヤマト復活篇を見てきた。やはり、年齢が高めの人が多かった。子供もお父さんと来ていたひとが多いようだった。
話は面白かった。奥さんと私でのめりこんで見てしまった。なぜ宇宙戦艦が大和なのかとか、下から攻撃されたらどうするのか？とか、そもそも宇宙空間でしたがあるのか？とか、翼が無いのに海から後部のメインジェットで上昇できるのか？とか、そもそも大きな宇宙戦艦が惑星の海におりてくるのか？とか、なぜ、ブラックホールに入っても大丈夫なのか？とかを無視すれば、楽しめた。
第1部だそうなので、第2部もあるのだろう。。。

休止状態から復帰した後でネットにつながらなくなる２

”休止状態から復帰した後でネットにつながらなくなる”で、ネットワークアダプタ(有線LAN)の省電力機能を無効にしたが、その後、やはり休止状態からの復帰３回に１回程度、ネットワークが落ちてしまう。
長く止めているとダメのような感じだ？
うちの環境はYahooBBのADSL50Mbpsサービスに加入して、トリオモデムを入れている。このモデムはルーター機能もあり、DHCPはこのモデムがサービスしている。そのポートにパソコンがつながっている。パソコンのネットワークアダプタはデバイスマネージャで見ると、Realtek PCIe GBE Family Controller と認識されている。
さて、休止状態からスタンバイにしてみたが、やはり同じ頻度で復帰するときにネットワークが落ちる。IPを固定アドレスにしてみたが、やはりだめ。
次にデバイスマネージャのRealtek PCIe GBE Family Controller を右クリックしてプロバティを表示させて、詳細設定タブを表示させた。LAN上のウェークアップのシャットダウンの値を”有効”から”無効”に設定を変えてみたが、やはり状況は変化しなかった。


次に、Wake-On-Lan機能を”パターン適合とマジックパケット”から”なし”に変更してみたところ、ネットワークが切れても再接続をしてくれるようになった。（気がする、まだサンプル数が少ないので、わからないかもしれないが、復帰するときにネットワークアイコンが再接続のアイコンになっている）


これで、一安心。頻繁に休止状態やスタンバイ状態に移行させるので、ネットワークが接続出きないととても痛い。１０分以上かかったシミュレーションを終わって、休止状態移行後にデバックの時にネットワークが切れていると、そのままデバックして、終了したら再起動ということがあった。とても不便だった。これで、すべて大丈夫だったら良いのだが？
しかし、これで直ったとしたら原因はなんだったのか？マジックパケットとかが着ているということ？
Realtek PCIe GBE Family Controller のドライババージョンを書き忘れた。日付2009/07/28、バージョン5.736.728.2009。
そうだ。そういえば、”インターネット接続ができない(トラブル)時の解決方法”も参考にしてDNSクライアントサービスも無効にしています。今のところ大丈夫みたいです。今も休止状態から復帰しても大丈夫でした。

(2010/01/04 追記）
今朝はネットワークが死んでいました。確率の問題みたいです。ハードウェアがおかしいのかもしれません。LANボードかUSB-LAN変換ケーブル買おうかな？と思います。

（2010/01/08 追記）
結局うまくいかないので、プラネックスのUSB-LAアダプタを購入しました。快適です。良かった。。。

初詣に行ってきた

昨日は、娘の部屋の三菱エアコンと、キッチンのインバータ40W蛍光灯のインバーターがいかれたのでケーズデンキで買い換えてきた。
エアコンは二階のベランダに設置してあるのだが、コンプレッサーの振動がひどくなってきて、動作させると1階のリビングルームにいると頭が痛くなってしまう。低周波騒音のような感じ、共振してうなっている。室外機の下にお風呂マットや、防振ゴムなどをおいてみたけど変わらず。。。ということでパナソニックのエコポイントがもらえるエアコンに買い換えた。ベランダの構造にも問題があるのかもしれないが、以前は大丈夫だったので、買い換えれば大丈夫だろう。
午後からは初詣に行ってきた。最初に一言主神社に行ってきた。行ったらすごい人、お賽銭の列が凄い。向こうが見えないほど。これじゃ、1時間待ってもお賽銭があげられるどうか分からない？ということで、お参りせずに引き返した。境内には出店の列、半端じゃないかず。。。今川焼きとクレープを買ってきた。
次に、水海道の水海道一高近くの天神様へ。ここは混んでいなかったので、お参りをしてきた。


年末休みから、普段は忙しくて出きないお仕事をしている。だいたいできた。CMOSカメラからの原画像、MP Wavelet変換画像、逆変換画像を5秒ごとに表示する回路。大体、終了したので、ドットマップのVGAコントローラの検討を始めることにする。

ISE11.4 のパッチ

新年あけましておめでとうございます。
新年の最初の記事はISE11.4のパッチがあったことだ。ISE11.4のアップデートがあるかどうか見てみたところ、2つアップデートがあった。1つはアラートだった。


なんか、CORE Generatorに関するXSTのパッチらしい。その行をクリックしてみた。


詳しい情報はMore Info...ボタンクリックするということで、クリックしてみた。
33993 - 11.2/11.3/11.4 XST - "ERROR:Xst:2996 - XST patch Expired"がブラウザに表示された。
それによると、CORE Generatorで新しいコアを生成した時や以前作ったコアを再生成した時に、"ERROR:coreutil - Exception caught when running XST synthesis! ... のエラーが出るようだ。
早速、アップデートを行った。