カメラはできた、ここが始まりだ

基板を渡されてから一年くらいで、なんとかカメラを作り終えました

このカメラを買ってくれる予定のお客さんのところに持っていって

お見せしました

この時のカメラは1000x1000の解像度で500fpsぐらいのものでした

最近は一般的なカメラでも200fps以上のスローモーションは撮影できるので

あまり大した印象はありませんが、当時は、こんなカメラが作れるのかと

たいそう気に入ってもらいました。

私はこの時の会社にはアルバイトで入社して、一年間かけてカメラを作りました

カメラができるまではタダ飯喰らいで、心苦しかったですが。

このカメラで一年間で、5000万円くらいの売り上げが上がり

ようやく自分の食い扶持が稼げる様になりました。

一人前の社会人として大手をふって街を歩けます

小さな会社に入社して良かった事は、会社に依存しない生き方を常に意識する事ができる様になった事です

何しろ、４人しか働き手がいないこの会社、自分の分が稼げなければ会社と共に自分もアウト

その感覚はとても大事だったなと思います

今はもう少し安定しておりますが、気を抜いた事はありません

さて、食い扶持はカメラが稼いでくれる事になりましたが

そのままでは廃れていってしまうので、次の製品へと踏み出す訳ですが

人生は一筋縄では行かないのです・・・

NiosIIを知る

FPGAの中に入れるCPUについては、最初のカメラを作っている最中に知りました。

最初にその事を知った時は「え？CPUってそんな簡単に実装できちゃうの？」と言う感覚でした（簡単ではなかったけどね）

最初のカメラにはCPUは実装しませんでしたが

次第に、CPUの実装は可能にしておかないといけない事を知りました。

HDLのロジックで記述する事が出来れば、1クロック(10nsecとか）単位でデータを処理できます。64bit並列で処理すれば800MB/secとかの処理が可能です（ even more! )

反対にCPUで処理をするとどうでしょう？

実装の仕方にもよりますが、データを読み込んで処理して出力するだけで数usec使ってしまいます。

ですが、CPUを乗せておくと、細かい制御がC（C++)言語で記述する事が出来ます

ハードウェア部分の開発は、この頃コンパイル時間で５分かかっていました

今は、大規模になってきて２０分くらいですが、複雑なシステムを構築する人等は１日かかる事もある様です。

なので、パラメータを変更する程度の事で合成等はしていられない訳です

そういう部分をソフトウェアでサポートします

 ともあれ最初のカメラを作り終える頃から、「あ～、そうか～、本当はCPUが入るのが当然なのか～」という事が分かり始めました

けれど、そこから、実際にFPGAの中にCPUを組み込んで自在に使える様になるまで

それはそれは長い時間がかかりました

カラーイメージセンサ

基板の事ばかり書いていたので、カメラを作るお話をしていた事を

すっかり忘れていました。

さて、前述した通り、私が作っていたカメラは、モノクロカメラですが

実は、同じ構成のまま、イメージセンサだけ乗せ換えれば、このカメラは

カラーカメラに生まれ変わります

いったいどうなってるんだろう

相変わらず言葉足らずの上司にベイヤーと言うキーワードを聞いて調べてみました

一般的には、カラーを表現するには、撮影する側（カメラ）もそれを映し出す側（モニタ）も、赤、緑、青の３つの色から構成されます

これらの組み合わせで、様々な色を表現しています

これに対して、モノクロカメラは、色の区分けが無く、該当するピクセルの明るさのみで表現されます

つまり、一つの画素を表現するのに、情報量が3倍違う訳です

液晶モニタに水滴をちょっとたらすと、ピクセルが拡大されて色が分かれているのが分かります

さて、ここで問題です

カラーを表現するには、上述の様に３倍のデータバスが必要です

なのに何故、モノクロと同じ回路でカラーが動作するのでしょう？

答え：各ピクセルに色の役割を与えて交互に送るから、それがベイヤー

ベイヤーフォーマットでは、

赤、緑、赤、緑・・・

緑、青、緑、青・・・

と言うピクセルの配列が続きます

赤のピクセルは何を行っているかと言うと、ピクセルの上に赤以外の波長をカットするフィルタが取り付けられていて、赤の光のみを取り込みます。

信じられないかも知れませんが、一つ5um平方の上にフィルタが取り付けられています

ベイヤーカラーフィルター

 実際にベイヤーカラーの絵をそのまま表示すると

こうなります

R G B 鬼

え？モノクロじゃん

更に拡大すると

RGB鬼拡大

なんかボツボツしています

これはどういう事かと言うと、読み出した明るさをそのまま表示しても

それは輝度値を表示する＝モノクロ表示となってしまいます

ベイヤーフォーマットは、各ピクセルを表示する為に、周辺画素から色情報をもらってきます

例えばフォーカスしているピクセルが赤だとすると、そこには赤しか情報がありませんから、このピクセルの緑の情報は、上下左右にある緑の平均を使用します

また、青の情報は斜め四隅の平均を使用します

それじゃあ情報量が一部欠損しちゃわない？と言う疑問が出てきます

それは正しい疑問ですが、実際には、そんなに気になりません

RGB復元

こうしてベイヤーフォーマットを知りました

カラーセンサーは当然必要で、しかもモノクロと同じ機構で作れるので

とても良いのですが、「カラーとモノクロの２種類がある」

ただそれだけで、色々な苦労を背負う事になりました

FPGAがいっぱいいっぱい

SDRAMの調整も終息に向かって、最終調整に向かう頃、とても苦労したのが

FPGAのリソースが殆どなくなってきた事です

75%くらい消費していました。

後25%も残っているように思いますがFPGAのコンパイルは消費リソースが増えるとより苦しくなってきます。例えば90%とかになると、ほぼそれ以上は何も入らないです。

この回路をいじっていた当時、私は新入社員で、基板が出来上がっていたので

この回路のままなんとかしなければいけないと思っていました。

素人にとって、出来上がった電子回路基板と言うのは、絶対的で、置き換えるとかの発想は全くありませんでした。

そんなわけでこのFPGAのまま完成させていきました。

実は私の上司にとっても、AlteraのFPGAを採用するのは初めてで、実際に使った事がなかった様なので、以下の事を報告しましたが、何も聞いてくれませんでした。

・リソースがいっぱいいっぱいになってギリギリ

・ロジックエレメントが増えるとコンパイルの時間がかかる

・配置配線が毎回違ってタイミングが変わってしまう

何度も報告しましたが、これらは後に上司が自分でFPGAをコンフィグレーションするまで理解してもらえませんでした。

今になって思う事ですが、この上司の開発は、「回路図ファースト」だったのですが、FPGA開発の基本（と言うか理想）は、「FPGAファースト」なのだと思います

これはどういう事かと言うと、まずFPGAを含めたシステム全体のブロック図を作成し

そこに基板が出来ていると仮定して、FPGAのロジックを書き連ねる

シミュレーションを行い、FPGAの内容がある程度完成したところで、最適なFPGAを探す。リソースが不足していれば大き目なFPGAにして、リソースがだぶついていれば、よりリーズナブルなFPGAに変更する。

そうする事によって、FPGAの致命的なミスマッチを防ぐ事が必要なのだと思います。

私の上司は、FPGAが一般的な物になる前から回路図を引き続けていて、仕様検討の段階で的確にICを選定するのがとても得意でした。それ故にFPGAの選定も仕様検討の段階で行い、回路図も間違えはありませんでした。

おかげで、私の提案はどうにも聞き入れてもらえませんでした。

一つの要因として、私は可愛げが無かった事もあるのかと思います。

FPGAの開発と言うより、仕事をするものの心得として、周囲の人間と円滑にコミュニケーションを取れる事は大事だなと痛感しています。

私の上司は最後まで私の意見を取り入れる事はなく、何をするにも私には確認を取らず

いきなり回路を書いて、基板を作ってから指示をする事を繰り返しました。

幸い、FPGAもどんどん進化したおかげで、容量不足に悩む事は少なくなりましたが

やりづらさは依然として続きました。

上司を説得する能力の低かった私は、結果として開発効率を上げる事ができず

ひいては、社内の生産性を理想値より下げてしまいました。

今は反省しています。

デジタルだけが課題じゃない

ハンダ付け

SDRAMを操作するときにとても苦労したのは

ロジック的には間違っていない筈なのに、なんでかデータが合わない事がありました

クロック信号の回路を見直すと、変な所に抵抗とコンデンサがついている

上司に聞くと終端抵抗だと言う

電子回路に馴染みのなかった私は、伝送経路の途中（最後）に抵抗を付けたら

信号の伝送がおかしくなっちゃうんじゃないか？と思い質問したが、上司からは終端抵抗は必要だと一言言われただけだった

私は納得がいかないと、すぐに試してみたくなる性分で

終端抵抗を全部外しました

するとどうでしょう、信号は全くでたらめになってしまいました。

やはり終端抵抗は必要だったのです

ですが、ここで私はこう思います

この抵抗を外して信号が乱れたならば、適切な値を見つければ信号が正しくなるのではないか？

なので、色々な値を試してみました。

無限大に近いと抵抗を外した時と同じなのであまり意味がないし

０Ωだと信号が出ないので、こちらも無意味

最初についていた値（47Ω）が適切な気もするが、それでは意味がない

最終的に行き着いたのは、100Ωにして、コンデンサを外す

と言う結論でした。

今でもどうしてこれが適切な値だったかは、分からないのですが

ともかくこれで動きました

他にも山ほどやる事を抱えていた私は、これで良しとしました

他にチェックする人がいる訳でもないですし

私はこれが動き出して売れてくれないと稼ぎがゼロのまま、もうすぐ一年経ってしまうのです。論理的な正しさを求めている場合ではないのです

SDRAMの工夫

SDRAMロジックの調整を始めた私は、何度も挫折しそうになりました。

そのうちの一つは、アドレスの指定です

前回PCIのロジックで説明したのと同じように、アドレスを指定した後で、続くアドレスに、連続してデータを送って行きます

このアドレスの指定が難しくて、同じアドレスバスを使って、カラム・ロウを指定します

RAS#とCAS#と言う信号が用意されていて、RAS#がアクティブ(=low)になっている時はrawアドレス（行アドレス）を指定し、CAS#がアクティブになっている時は、columnアドレス（列アドレス）を指定します。

この様にして、少ないアドレスバスで、大きいアドレス空間を制御できるように

同じアドレスバスを使って二つのアドレスを指定できるようにしてあります

例えるなら、１個が4096のアドレスを持ったボックスを1024個用意すると、4GBのアドレスを表現できます

と言った感じです

また、PCIバスで学習した様に、アドレスを指定した後は、データを連続的に書き込み/読み出しをします

これにより、アドレスを指定するオーバーヘッドは限りなくゼロに近づきます

また、データバスは、書き込み・読み出し、双方向で行える様になっており

同じバスを共有します

この為、書き込み・読み出しが重複するとデータレートが圧迫されますが

実際には、ここが大きなボトルネックになる事はありません

特にハイスピードなカメラを作っていると、高速に動作しなければいけないのは

一方的に書き込む時は、高速性が求められますが、読み出しは、それ程即応しなくても

問題にはなりませんでした

membox

SDRAMという大敵

最後の壁になったのはSDRAMでした

と、言うより、とても面倒くさそうだったので、最後まで手を付けなかったのがSDRAMです。

さてここで問題です、FPGAでSDRAMをコントロールするにはどうしたら良いでしょうか？

・・・・

はい、正解です。IP-Coreを使います。

「正解です」と言ったのは、それが常識だからです。

何度も書きますが、私はそういう常識を全く知らずに仕事を始めたもので

IP-Coreの使い方で知っていたのはFIFOとSRAMとPLLくらいでした。

UARTすら自作していましたもので。

外部のデバイスへのアクセスは、全て自作していました。

SDRAMへのアクセスが、その最大のものとなりました。

デバイスの配線を調べます、DQ[0:63]とか、RAS ,CAS,WE等が繋がっている事を確認します

これは、どうするかと言うと、デバイスを一旦外し、FPGAの各ピンをアウトプットに設定します（インプットに設定する方法もありますが、この時はシグナルタップが使えなかった。）カウンタを作成して、各ビットに割り当てます。

50MHzのクロックでカウンタを作成すると、bit0の周期は40nsecになりますbit1は80nsecとなります。これらをオシロスコープで確認していきます。

そうやって全てのピンの繋がりを確認して行きました。

カメラの配線ではポカをしていた上司ですが、基本的にはこの上司の回路はしっかりしていました。

実は、この上司を含め、私がFPGAを担当した回路では、DRAMが動かなかったことはありませんでした。いつもとても不安なのですが、その分だけ慎重だったからかもしれません。

そうやって一つ一つの信号を確認した後はマニュアルに沿って信号を入れていきます

信号はほとんどアクティブlowなので、信号をHighにしておけば悪さはしません

そこで最初に行ったのは、readですcas,rasとアドレスをセットすれば 

そこに書かれたデータが読み出せます

まずは２回同じ値が読み出せれば、読み出しは動いてるんだろうと考えて

試すところから始めました・・・

SDRAM the last boss