ZedBoardでDSLiteを拡大表示

今回はZedBoardでの作例を書いてみます。
ずいぶん前に製作してたのですが、写真の用意など遅くなって今更ブログに載せてみることになりました。

全体像がこんな感じです。

DS Liteを改造して表示画像をFullHD級にリアルタイム拡大する、というものです。
いわゆる偽トロキャプチャの亜流って感じでしょうか。
拡大等の処理はZedBoard上のZynqで行ってます。
Androidと接続していて、Android側を操作することで拡大率や拡大アルゴリズムを切り替えられるようにしています。

残念なのは改造の都合で、上下2画面の下側しか取り出せなかったことです(^^;

ブロック図にするとこんな感じです。

元の画像は256✕192ピクセルです。対して、表示モニタは1,920✕1,080。
上の写真は拡大無しで表示しているので、左上に小さく出てるな～って感じです。
一応、よって写真とるとこんな感じ。

これを拡大率をあげていくと……こんな風になります。

最終的に縦幅をフルにしたところで5倍ちょっとです。
写真撮ってないですが、もっと高い倍率でも動きます(その場合、当然、元画像の一部分が画面いっぱいに表示されることになります)。

拡大率だけじゃなくて、拡大アルゴリズムも切り替えられます。
両方とも、教科書に載ってる基本のアルゴリズムです。
上がニアレストネイバ、下がバイリニア(ちょっとエッジ強調入れてます)です。
あんまりうまく写真撮れてませんが……。

DS Liteの改造はこんな感じです。
液晶へのフラットケーブルこねくたの半田付け部分にUEWを半田付けしてます。
あと邪魔だったので、GBAカセットのコネクタは取っちゃってます。
半田付けがめちゃ疲れました……。

Android周りは一旦PICマイコン(PIC24FJ64GB002)に接続してからZedBoardに接続してます。
Android-PIC間はMicroBridgeで接続しています。
PIC側の実装は石井さんのmicrobridge-picではなくて、自分で実装したものを使ってます。
PIC-Zynq間はPIC側がマスターのSPIで接続しています。

Androidの画面はこんな感じです。

拡大率をシークバーでずるずるできます。
見た目では分からないのですが、下の黒い領域でピンチイン/ピンチアウトしても拡大率が変わるようにしてます。

とりあえず、わーっと写真披露した感じです。
お小遣いで買えるぐらいのFPGAボードでもFullHD(1,920✕1,080) 60fpsとかが扱えるんだぜ、ということで。

後日、部分部分で取り上げて、もう少し詳しく書くかも?です。

ZedBoardのDDR3 SDRAMチップ

　ふと気づいたのですが、ZedBoardの2012/08/24版の回路図にはDDR3 SDRAMチップは

MT41K128M16HA-187E

となっています。　ですが、Hardware User's Guideには

MT41J128M16HA-15E

と書かれています。　Board Definition Filesのzedboard_RevC_v2.xmlにも

MT41J128M16HA-15E

と書かれています。

　結局、-187Eなのか、-15Eなのかどっちだよ。

　実物は……、直接の型番は刻印されてないんですよね。これに限らず、最近は小さい部品が多くて、刻印見ても型番分かりづらいですよね。

　でも、調べてみると、MicronはWebページにFBGA Decoderというのがあって、FBGAのチップ刻印とパーツ型番の対応を調べられます。

　結論としては、FBGAの刻印 D9LGQ は -15E と対応するので、搭載チップは-15Eの方でした。

　さらに、ZedBoardのサイトをチェックすると、2012/11/08版の回路図が提供されていて、それでは、型番が直っていました。ボードにも色々Errataがあるらしく、赤字でいろいろ書かれていて不安になる回路図です。

　ところで、-187Eと-15Eで何が違うのかというと、主には最大動作周波数みたいです。PCパーツ風に言えば、DDR3-1066かDDR3-1333かということですね。-15Eを666MHzで動かす場合はCL=9ですが、-187Eを533MHzで動かす場合はCL=7になるとのこと。-15Eは533MHzで動かせば-187EとコンパチになりCL=7で動かせるみたいです。

　ということで、ZedBoard開発では実物が-15Eでも、533MHz動作なのでCL=7にセッティングするのが、CL=9に比べて、ホンのわずかアクセスが速くてお得そうです。実際にSDKにExportされるhw_platformのサマリを見た限りでは、-15E設定でもCL=7になっているので、デフォルトで大丈夫みたいです。

Xilinx ISE 14.3

　これまでZedBoard用にはXilinx ISE 14.2を使っていましたが、14.3をインストールしてみました。

　WebPackライセンスでXPS立ち上がるときにラインセスエラーのダイアログ出るのは相変わらずでした。

　とはいえ良くなっている点はあって、まず、新規プロジェクト作成時のボード選択にZedBoardが追加されていました。

　これまではZC702で進めていって、後でZedBoardの情報をImportさせる、としていたので、一手間減りました。

　他にもPlanAheadでも見た目など微妙には変わっているようです。ですが、大きな落とし穴が……。

　BitGenまで進むと、

ERROR:Bitstream:188 - Bad time stamp "MON 29 OCT 10:2:52 2012". Expected "YYYY/MM/DD HH:MM:SS".

といったエラーが出ます。 既にXilinxのサポート情報にも載っていて、「ISE 14.3 - 「ERROR:Bitstream:188 - Bad time stamp"」というエラー メッセージが表示される」によると、

• エラーと出てもbitファイルは生成される
• LANGUAGE環境変数がJapaneseだと発生する
• 14.4で修正予定

だそうです。エラー内容自体がどやねん、って感じですが、エラーと言っておきながらbitファイルは生成されるって……。

　それでも、発生条件が分かったので、回避できるか試してみました。
PlanAheadはバッチファイル(私の場合C:\Xilinx\14.3\ISE_DS\PlanAhead\bin\planAhead.bat)から起動しているので、それの最初の方に

set LANGUAGE=usenglish

と追記してみると、エラー出なくなったみたいです。

　Linuxでは試していないですが、同様の状況なら、LANG環境変数をCかen_USあたりにすれば回避できるように想像できます。

　長く使っている人ならCADツールのロケール周りの問題は珍しくはないですね。

　最近は、よく海外に行く人と話していると「シリコンバレーとか中国系とインド系の人ばっかり」とか聞きますので、ツール開発には英語ネイティブじゃない人が多く加わっていそうですが、それでもソフトウェアのインターナショナル対応は進まないものですね。

ZedBoard未使用ピン

　ZedBoardというかZynqについてなのですが、PL部分の未使用ピンはどうなるのかな？と思ったので調べました。

　Xilinxの開発フローでは未使用ピンの状態はBitGenの時点で決まります。
BitGenはフローの最後に.bitファイルを生成するステップです。

　「コマンドラインツールユーザーガイド」のBitGenの章によると-gオプションで、サブオプションUnusedPinというところになります。

　Version 14.1については、Pulldown, Pullup, Pullnoneのいずれかが設定でき、デフォルトはPulldownだそうです。(デフォルト値はツールバージョンによって変わったことがあった気がします。XilinxじゃなくてAlteraの話だったかもしれませんが…)

　ZedBoardのチュートリアルなどでは、特にBitGenにオプション指定していないので、デフォルトのPulldownになっているのだと思います。

　ZedBoardのような開発ボードでは、FPGA外にいろいろ繋がっているけど全部は使わない、ということが多いので (例えば、SSRAM繋がっているけど使わない、とか)、変なことにならないようにしておきたいです。
　まぁ、気になるなら、使ってないデバイスについてもポート宣言キッチリしてCS#なんかをHigh固定でネゲートするとかすればいいんですが。

　DC特性によれば、Zynq側でのプルアップ/プルダウンは10kΩ以上の抵抗値みたいです。ということで、それより十分に小さい抵抗でプルアップ/プルダウンしている分には外付けのプルアップ/プルダウンが優先されそうです。うーん、でも、それはそれで、電流消費が増えたり、プルアップ/プルダウンに逆らってドライブするのが大変とか、相手のVILとVIHの範囲が云々…、と色々悩ましい感じもしますが。

　ま、ともかく、簡単にZedBoard回路図を見てみると……、

• スライドスイッチ、プッシュスイッチ、LEDは変に電流流れたりすることは無さそう
• Audio Codec、HDMI Transmitterは細かくは見てない。I2Cの外付けプルアップとZynq内部のプルダウンがぶつかっていて少し気持ち悪いかも
• OLED(信号部分)も細かくは見てない
• OLEDの電源スイッチのN-MOSのゲート信号が外付けプルアップ 10kΩとZynq内部プルダウンがぶつかっていて、上のI2Cより気持ち悪い気が

――というので、実はむしろPullup設定の方がいいのでは?という気も。

　とはいえ、ZedBoardのForumとかでも話題に出てないみたいだし。うーん、調べだしたはいいけどスッキリしない感じです……。

ZedBoardクロック周り

　前回の投稿でZynqで気になっている点として「クロック周り」を挙げましたが、ドキュメントを調べたり、開発環境をいじってみて分かってきました。

　まず、PS側はチップ外から供給されるクロックで動きます。まぁ普通ですよね(マイコンによっては内部に発振回路持っていたり色々ですが……)。
　PLLが内蔵されていて、CPU、DDR3 I/F、etc. それぞれに色々な周波数を供給することになるみたいです。

　気になっていたのはPL側で使うクロックはどうなるのか?という点です。結局、

• PS側からのクロック (4系統)
• チップ外からのクロック供給 (&MMCMブロックでのクロック制御)

の2種類のようです。
　ZedBoardの場合は、チップ外からPLへは100MHzが供給されています。

　PS側からのクロックはXPSの画面で、ここをクリックすると……

このようなダイアログが出てきて、設定することができます。

　チップ外からのPLへのクロックについては、これまでのFPGAのように「CORE Generator」で「Clocking Wizard」でMMCME2_ADVやPLLE2_ADVを構成すれば使えるみたいです。

ZedBoard買いました

Zynq搭載ボードのZedBoardを買いました。
まだ、買っただけで本格的には触れていませんが……。

ZynqはXilinxが出した新しいFPGAです。
が、ただのFPGAではなく、ARM Cortex-A9が搭載されています。
というより、

Cortex-A9チップのオンチップペリフェラルにFPGAが載っている

と思った方が近いみたいです。
Cortex-A9はデュアルコアでZedBoardでは最大667MHz動作らしいです。

あとは、

• 513MByte DDR3
• 256Mbit QPI Flash
• SD Card I/F
• 10/100/1000 Ethernet
• USB OTG 2.0
• HDMI Output
• VGA Output
• OLED Display
• FMC

等々が搭載されています。

とりあえず気になっているのは

• クロック周り
• リセット周り
• ブート手順
• プロセッサ側とFPGA側の境界部分

といったところです。

他の方と話していて

• Cortex-A9コアをMMU不使用でOS無しマイコンファームウェアみたいなの実行できるか
• Cortex-A9のデュアルコアをAMPとして、個別に動かす方法

というのも気になりだしました。

MMU不使用というのは、現時点ではマニュアルを確かめられていませんが、
起動後にMMUを有効化しなければ、物理アドレス空間で動くのでは?と思っています。

気になっている点、今後、調べて備忘録もかねてブログに書けたらよいかと。

第1回 関西FPGA・DE0勉強会に行ってきました

先週の土曜日2012/05/19、第1回 関西FPGA・DE0勉強会に行ってきました。

ATNDのページはこちらです。

第0回に続き、今回も発表させていただきました。発表資料を置いておきます。

「コマンドラインでFPGAプロジェクト～Quartus, SOPC Builder編～」

http://www.slideshare.net/iseroid/1fpgade0-fpgaquartus-sopc-builder

この発表のコマンドラインの使い方 (コマンドラインというかフロー自体かな?)、実は@s_osafuneさんの発表内容に関連した問題があります。

.sopcファイルからsopc_builderコマンドなり、GUIのSOPC Builderで.v等をgenerateすると、実行するたびにSYSIDが変化してしまいます。
開発中で試行錯誤中はSYSIDが変化していくのが当然なので問題ありません。

ですが、バージョン管理システムに追加して、複数のユーザやPCで作業しようとすると、問題が顕在化します。

同じ.sopcファイルを元にしていても、論理合成はAさん、ファームウェアのビルドはBさん、といった組み合わせで動かせないのです。

かといって、SOPC Buillderが生成する.vファイル等をまとめてバージョン管理等で保持するのもうまく行きません。SOPC Buillderが生成するファイルに絶対パスが含まれることがあるからです。そのままバージョン管理システムに追加すると、非常に使いづらいものになります(ワーキングコピーを最初に追加した人と同じ絶対パスに配置しないと動かない)。

では、どうするのがよいのか?

私の今の考えでは、GitHub等で公開する場合、複数のユーザが参照しうるが、ユーザ間で共同作業しない、という前提で、.sopcファイルのみをバージョン管理対象とするのがベター、と考えています。
cloneしたワーキングコピーそれぞれで、SOPC構成のgenerate～ファームウェアビルドまでを通して行えば、その中ではSYSID不一致は起こらないはず、というわけです。

何かよい方法をご存知の方がいれば、是非、次回以降の関西FPGA・DE0勉強会で発表をw