Lattice XP2基板にもSRAMを外付けする

　日本のサッカーワールドカップはベスト16で終わった。それでも大健闘である。開催直前のチーム力ではとても予選を勝ち抜けるレベルとは思えなかった。監督の指示次第でああも力が変わるのか。期間が短かったので、選手のフィジカル能力やテクニックが急に上がったわけではないだろう。ちょっとした監督のアドバイスか何かで選手の中の意識の変化が好成績をもたらしたように思う。

　日本代表の変貌振りをたとえに使うのは少々おこがましいが、当研究所の電子工作の最近の状況には似たようなところがある。アナログ液晶モニターにFPGAでカラーバーを出そうとして、うまくいかずイライラして気分が優れなかった。コンポジット同期をあきらめ、同期信号を水平と垂直に分離して、やっと少しましになったが、それでも満足できる鮮やかな色にならない。

　どうしようかと迷った挙句、とにかく出たことにして不承不承、次のステップに移ることにした。ところが次のステップの検討に入った途端、憂鬱な気持ちが、きれいさっぱり晴れてしまったのである。もともと、アナログ液晶は、NTSCのビデオモニターにするために買ったはずで、本来のフォトフレーム用には26万色のデジタル液晶が用意してある。アナログは、これまでの行きがかかり上（たまたま最初買ったモニターがアナログ液晶だった）、何とか完成させようと意地になっていただけということに気が付いた（ビデオDACのBU3616Kが無駄になりそうだが）。

　趣味の電子工作なのに、こんなに目標や、目的にこだわることが馬鹿げていることにもっと早く気づくべきだった。ただ、がた老AVR研究所はあくまでも実用的な目的を持った電子工作をモットーにしている。これは前に何度も書いたが、現役時代に身に付いてしまった所長の一種の職業病である。目的と手段を混同することを極端に恐れ、一旦決めた目標にとことんこだわってしまう癖が直らない。

　と言って、逆に、このこだわりもしつこさもなければ、味も素っ気もない趣味になってしまうような気もする。そう、難しそうなことに挑戦することで気分が高まり、興奮するという効果がある。難しいものだ。考え方の持ちようで楽しみにも苦しみにもなる。

SPIインターフェースを作るステップに入る(7/1/2010)
　FPGAでフォトフレームを作るプロジェクトは、第5ステップのプロセッサーとFPGAのインターフェースを設計する段階に入った（第4ステップのビデオDAC制作は延期）。当初の計画では、プロセッサーとFPGAの間は、シリアルのSPIでつなぐことにしている。動画ではないのでバス接続は始めから考えていない（QVGA程度ならシリアルでもフレームレートを落とした動画くらいは出せるかもしれない）。

　SPIそのものは難しいインターフェースではない。同期クロックがマスター側から供給され、スレーブ(FPGA)はそのクロックを監視していてフレーム（8ビットが通常）ごとにシフトレジスターを動かし、データを移すだけである。UARTよりはるかに簡単だ。

　ここのステップの設計の要点は、SPIそのものより、プロセッサーから大量の画像データをいかに簡易にFPGAがフレームデータとして受け取り、SRAM（VRAM)に展開するか、そのタイミングはどうするか、という全体の構成である。そろそろプロセッサー側のユーザーインターフェースも一緒に考えておかないと具体的な設計が出来ない。なかなか思ったような構成がまとまらない。

　FPGAは電気モーターのように、スイッチを入れれば、勝手に動くだけにしておきたい。VRAMにあるフレームデータを黙々とRGBインターフェースに送ると同時に、プロセッサーからのデータが来れば、誤りなくアドレスの最初から末尾までをSRAMに移す。FPGAはなるべく判断や制御をさせない仕様にしておかないとあとが大変だ。

　データの最初を識別するプロトコルをどうするか迷う。トリガーを何にするか、SPIで一気にデータを送ってもエラーにならないか、ブロック単位でACKを入れるべきか、お手本をウェブで探すが、ここまで詳しく解説しているところは見つからない。自分なりに作るしかないようだ。

　色々検討した結果、プロセッサーからFPGAに送るタイミングは、一番簡単な、SPIのチップセレクトを感知して、ここから一気にデータをシーケンシャルに送り込む方法でやってみることにした。プロセッサーとFPGAの間の距離も短いので、150KBくらいなら問題ないように思われる。まあ、動かしてみて駄目ならそのとき考えればよい。

　次に問題なのが、テスト環境である。作ったインタフェースがうまく動いているか、これだけコンポーネントが多くなってくると、しっかりしたテスト計画をたてておかないと泥沼に落ちると抜けられなくなる。

　プロセッサーは当初、STM32を考えていたが、今のところSDカードのファイルシステムが完全に動いていない。ここの開発をやっている時間が惜しい。とりあえずはAVRのMega128か、Mega328を使ってSPIをテストすることにする。

　デジタル液晶の部分もまだ実装が済んでいない。XP2にSRAMもつけていない。やれやれ、フォトフレームの道はまだまだ遠い。

fpga4fun.comのソースコードに感動する(7/3/10)

　SPIの開発のため、参考書やウェブでお手本にするソースコードを探しているうち、このサイトで、これこそがRTL(Register Transfar Level)設計だと言うVerilogHDLのサンプルソースを見つけ、久しぶりに興奮している。

　このサイトは、FPGAを勉強し始めた頃、ブックマークしてあったが、あまり真剣に読んでこなかった。英語ということもあるが、ソースコードの書き方が、これまで雑誌などに見るスタイルとかけ離れていたため、馴染めず、斜め読みしかしていなかった。

　それが、SPIの勉強がてら、ここのSPIやRS-232C（UARTのこと)のVerilogHDLソースを仔細に読んでみて驚いた。実に簡単に実現している。ここのソースの特徴は、always節がやたらと多いことである。これに対してこれまで参考にしていた雑誌などのサンプルコードでは、alwaysはクロックを作るところと、メインのalwaysくらいしかない。

　ソフト屋からすると、ステートマシンの全体の流れがつかめるので、このほうが見やすい。そして機能ごとにサブモジュールにわけ、サブモジュールが協調して全体が動くというしかけになっている。今までこの作り方に何の疑問も持っていなかった。

　ところが、このサイトのソースコードは、殆どのREG変数(実態はフリップフロップ）単位にalwaysがついており、これらがそれぞれクロックと同期しながら独立して動く。例えば、最終的なUARTの送信データの出力回路は、何とassign文一行である。（変数stateは、別のループで動くステートマシンのステップで、muxbitがデータ）

// combine start, data, and stop bits together
assign TxD = (state<4) | (state[3] & muxbit);

このステートメントだけで、シリアルの一本の送信ラインTxDに、スタートビットから始まる8ビットのデータがボーレート単位に送られ、最後にストップビットが付いて送信されていくことが想像できるだろうか。ソフト屋には無理である。

　RTL(Register Transfar Level)記述という言葉が始めて理解できるソースコードである。そうか、FPGAというハードウエアはこういう風に動くほうが自然なのだ。沢山のサーキットが同期したクロックを貰いながらそれぞれの仕事をし、最終的に必要な出力を出す。良い勉強になった。

結局XP2にも外付けSRAMをつける(7/6/2010)
　あれこれ悩んでいたが、XP2基板にもSRAMを載せることにした。XilinxのチップをDigiKeyに発注するゲタ（送料無料にする品物）がどうしても見つからない。DE0は有力な候補だが、これ以上、開発対象を増やしたくない。となるとXP2基板にも4メガビットSRAMのCY7C1041Dをつけないと先に進めない。

　XP2はSpartan3Eに較べるとI/Oピンは倍近くあるのでピンアサインは余裕である。SRAMの場所は、XP基板の下にし、スペースを稼ぐ。アドレスバス18本、データバス8本、制御線2本、電源を入れれば30本の配線である。ここでも慎重に、アートワークを紙に描き、終わったところをサインペンで消しながらハンダ付けしていく。

　ハンダごてを新調して、UEW線のハンダ付けは飛躍的に早くなった。これまで被覆を熱ではがす工程が、もたもたしていると被覆を炭化させてしまって何度もハンダをつけなおすなど、時間がかかっていたのだが、今度は殆ど一回で、綺麗に泡を吹いて被覆がはがれてくれる。やはり道具には金をかけるものである。

　夜遅くから始めて、深夜(というより明け方)のワールドカップサッカーのキックオフ前にはすべて完成した。計算してみると1本2箇所のハンダ付けに、5分というところだ。まずまずの生産性に満足する（アートワークは済んでいる）。念のためテスターで結線を確認する。UEW線はハンダ付けがされていても、まれに接触不良が起きる。うむ、大丈夫なようだ。

Initial文ではメモリーの初期設定が出来ないとは(7/8/2010)
　SRAMが付いたので、UARTからテストに入る。SPIが動いてSRAMにデータが入ったかどうかを確認するにはUARTが必須だ。デジタル液晶の実装が出来ていないので確認の術がないからだ。

　UARTは、fpga4fun.comのコードではなく、用心して前に動いたコードを入れる。リセットのところを直さなければならない。このあいだ正論理ではまったところである。雑誌の回路図を良く見ると、シュミットトリガーのインバーターがしっかり付いていた。慌て者だから、こういうところを見逃す。

　論理合成する。問題なし。コンフィギュレーションも無事に終わった。あまり期待もせず、UART端末を立ち上げる。ふむ、何もでない。30本の配線だ。最初から動くことを期待するのが間違っている。念のため、リターンキーを押す。ややや、行が変わったぞ。キーボードを押すと、おお、文字がエコーバックされる。何だ、何だ。動いている。

　文字を入れて、リターンキーを押すと、入れた文字が正しく返ってきた。ええー、ちゃんとSRAMまで動いているではないか。しかし、プロンプトの>や、リセットしたあとのメッセージは何も出ない。ソースコードはリセットのところを修正しただけで、何も変えていない。XilinxとLatticeで仕様が違うところがあるのだろうか。まさか。

　何かエラーがでていないか、論理合成のメッセージから確認する。すると、

Initial statement will only initialize memories through the usage of $readmemh and $readmemb. Everything else is ignored

initial begin
MSG[0] <= 8'h0D;  // CR
MSG[1] <= 8'h0A;  // LF
MSG[2] <= 8'h2A;  // '*'
　　　　　・・・

という警告(warning)が見つかった。プロンプトや初期メッセージのデータを収容するところだ。何い、intial文では$readmemhなどを通してでないと、メモリの初期化が出来ないと言っている。何だこれは？ あわてて$readmemhを調べるが、これはファイルから、HEXフォーマットでデータを入れるシステム文で、こんな大げさなことはやりたくない。

　論理合成ツールのバージョンや、グレードでこういうことになっているのかもしれないが、たかだか10数文字のコンスタントに、これだけの手間をとらすのは理不尽だ。ウェブに助けを求めるが、適当な対策は見つからない。

　待てよ、このメッセージはinitial文では駄目と言っている。ということは他では出来るということなのか。試しに、メインalwaysのリセットのところにぶちこんでみた。最初はうまく動かないが、リセットすればデータは入る。

　やった、やった、やりました。論理合成ツールはまんまと騙されて（？）warningがなくなった。ファームを作り直して恐る恐る電源を入れる。おおう、プロンプトが戻ってきた。***FPGA***という初期メッセージも出る。Xilinxのときと違って、全く安定している。改行のないテキストファイルを作ってファイル転送する。これも問題なし。

　いやあ、久しぶりの快感だ。ハンダ付けは完全試合だった。SRAMが正しく動いている。これでSPIのテストの準備は整った。SDカードを読むプロセッサーをマスターとしてFPGAスレーブにSPIでデータを送り、UARTで結果を見るのが次のステップだ。