MKRVIDOR4000_graphicsの中身を見てみる

Quartus Prime LiteでMKRVIDOR4000_graphicsの中身を見てみます。

projectディレクトリの中にMKRVIDOR4000_graphics_lite.qpfがあるので、これをQuartus Prime Liteで開いてみます。

左の方のProject Navigatorのところでソースツリーっぽいところ(Entity)が見えて、ここに MKRVIDOR4000_graphics_top があるので、これをクリックすると、そのソースコードが開きました。トップレベルモジュールの verilog ソースコードのようです。端子の定義と信号の定義、出力バッファ近傍のセレクタなどがあるようです。

Project NavigatorでIP Componentsを選択し、EntityのところでMKRVIDOR4000_graphics_lite_sysをダブルクリックすると、Platform Designerが開いてIPマクロ間の接続の全体像が少しわかります。nios CPUのメモリマップもここで確認することができて、niosの命令バスはオンチップメモリとQSPIフラッシュメモリからフェッチできるようになっているようです。(SDRAM ARBITERとsdramのところを編集するとSDRAMからのアクセスもできるように修正できるっぽい雰囲気です)

上の方の再生ボタンみたいな Start Compilation をクリックすると論理合成して、配置配線、タイミング解析をしてくれます。Task のパネルに進捗が表示されて、完了すると、Entityのところに各モジュールの構造がツリー状に表示されました。このあたりをもう少し見ていくといろいろわかりそうです。

一方で、VidorBitstream-releaseディレクトリの下にipというディレクトリがあり、ここにIPコアのコードが入っているようです。各モジュールの softcore というディレクトリの下にFPGA側のniosのコードが入っています。graphicsの描画処理は ip/GFX/softcore/src/gfx.c というソースの中の gfxRpc() の中で受け取ったリモートプロシージャコールのパラメータに応じて描画関数を呼び出していました。

また、VidorBitstream-release/project/MKDVIDOR4000_graphics/build/software/launcher_lite_bspの下にsummary.html というファイルがあり、これがnios側の諸情報のようです。この中にLinkerのSectionに関する情報があり、nios側のコードもデータもbssもheapもオンチップメモリ上に配置されているようです。また、mem_init.mk というファイルによるとリセットベクターも 0x00a00000 となっているようで、これはメモリマップによればやはりオンチップメモリのようです。nios上のコードはniosとは関係なくオンチップメモリ上に転送しているのかもしれません。(FPGAのコンフィギュレーション時に書き込まれるんでしょうかね??)

まだまだ弄るといろいろわかりそうですが、時間もかかりそうです。

VidorBitstreamがビルドできるようになりました

MKRVIDOR4000_graphicsのサンプルスケッチが中途半端に表示がされる原因についてもわかりました。

中途半端に表示がされるのは、サンプルスケッチ VidorDrawLogo の冒頭にある

のFPGA側での処理が遅いことと、初期化時にそもそも白で全面クリアされていること、ARM側の処理でFPGA側の処理完了を待っていてもタイムアウトするほど遅いことが原因です。初期化時にそもそも白で全面クリアされているので、その上に処理の遅いfillRect()が同色で描画されても、画面上は何も見えません。fillRect()の処理が終わった後に描画要求が飛んでくる部分だけが見える、というわけです。

その証拠に、

と色を変えてやると、ちょっとずつ青く塗っていく処理と、その後で一部の文字が描画されるのがわかります。

というわけで、fillRect()の部分をコメントアウトすることで無事に表示されるようになりました。

まとめ

Linux Mint 19.1 上の Quartus Prime Lite Edition 18.1で MKR Vidor 4000 のFPGAのコードをビルドする場合は以下の点に注意。

  1. apply_quartus_patches.shでパッチを当てる際には、arduino_generic_quad_spi_controller2_sw.tcl に対するパッチ適用は失敗するので、手動で適用すべし。
  2. スケッチサンプルの冒頭のfillRect()はコメントアウトすべし(もしくは、色を変えた上で、Arduinoライブラリの中の VidorMailbox.cpp の冒頭のMB_TIMEOUTを大きく伸ばすべし)

おまけ

Arduino側(ARM側)のライブラリを見ていてARM側からは以下のようにFPGA側にリクエストが伝わるようです。

Vidor_GFX.cpp ⇒ VidorMailbox.cpp ⇒ VidorJTAG.cpp ⇒ jtag_host.cpp ⇒ JTAG信号線

グラフックスの関数はリモートプロシージャコール(rpc)のパラメータの配列(uint32_tの配列)に変換されて、VidorMailbox.sendCommand() が呼び出されます。パラメータはVidorJTAG.writeBuffer()の引数として渡されますが、最終的には jtag_host.cpp で1ビットずつJTAG信号としてFPGA側へ転送されます。すべてソフトウェアでJTAG信号を生成しているようなので、コマンドの転送自体が遅そうです。Mailboxへのコマンド送信後の応答待ち時間は VidorMailbox.cpp の冒頭の MB_TIMEOUT で定義されていて、5000ms=5秒になっているようです。
FPGA側の処理については調べていないのでこれからです。

VidorBitstreamがビルドできない原因を探ってみました

気を取り直して、MKRVIDOR4000_graphicsがビルドできない原因を考えてみます。

まずは改めてビルドして気になるところを洗い出してみます。

途中で

というところがあって、arduino_generic_quad_spi_controller2が絡んで致命的にだめな感じです。

~/intelFPGA_lite/18.1/ip/altera/pgm/arduino_generic_qpsi_controller2 の下でリジェクトされたパッチが2つあったのですが、そのうちの対象の一つが arduino_generic_quad_spi_controller2_sw.tcl というファイル名なので、何か関連がありそうです。リジェクトされたパッチ arduino_generic_quad_spi_controller2_sw.tcl.rej を見てみます。

この中に、

というようなところがあるので、なんか関連はありそうです。arduino_generic_quad_spi_controller2_sw.tcl の中をみても、なぜリジェクトされたのかイマイチよくわかりません(適用されても良さそうな気がする)が、とにかく手動で適用してみます。(追記: 要は、arduino_generic_quad_spi_controller2_sw.tcl というファイルの中の16行目からの10行くらいと、50行目からの11行くらいのところにある「altera_generic_quad_spi_controller2」を「arduino_generic_quad_spi_controller2」に書き換える、ということです。)

もう一つのarduino_generic_qspi_controller2_hw.tclに対して1箇所失敗している方はかなり雰囲気が違うので、まずはこのまま再トライしてみることにしてみます。

ということで、当該箇所では特にエラーなく完了しました。

・・・ということで試してみると、

4:3サイズで全面白になった後、しばらく経ってからこんな表示に。
まあ、全く動いてないわけではないので、だいぶ進歩しました^^;

VidorBitstreamをビルドしてみる

Arduino MKR VIDOR 4000のFPGA部分については、githubのvidor-librariesにいくつかサンプルがあるようです。この中の、VidorBitstreamが詳しそうな感じなのでVidorBitstreamのReadmeを読みながら作業してみます。

冒頭の部分は要約すると、「対象はFPGA開発プロセスに慣れたユーザーである」「FPGAのネイティブ開発はサポートは難しいので限定的」ということみたいです。

ディレクトリ構成は以下の通りのようです。

  • IP IPブロックのソースコード。
  • projects 各ボード用のサンプルプロジェクト。
  • constraints 各ボード用の制約ファイル。ピン配置とタイミング制約を含む。
  • TOOLS FPGAイメージを生成するためのスクリプトとツール
  • distrib コンパイル中にツールチェーンによって作成されたディレクトリ。プロジェクトをコンパイルすることによって作成されたArduinoライブラリが含まれている。

リポジトリのダウンロードと展開

まずはリポジトリをダウンロードして展開します。まず、VidorBitstreamをZIPでダウンロード。ダウンロードしたVidorBitstream-release.zipを~/intelFPGA_liteディレクトリの下に移動し、ここに展開しました。

NIOS II Command Shellの起動

NIOS II Command Shellを開いてシェルスクリプトを起動する必要がある、ということなのですが、Windows版はStartメニュー内にあるようですが、Linux版はnios2edsディレクトリ内にあるようなので、

として起動します。プロンプトは一切変わらないようなので、要注意かもしれません。
(Windows版はCygwinが起動するようですが)

QuartusのIPにパッチ適用

次に、QuartusのIPにパッチをあてます。

うーん、~/interlFPGA_line/18.1/ip/altera/pgm の下のファイルでいくつかパッチ当てに失敗してしまったようですが、このまま進めてみます。

makeCompositeBinaryのコンパイル

make_composite_binary.goをコンパイルするためにはgoが必要ですのでインストールします。

引き続いて、コンパイルします。

TOOLS/scriptsディレクトリにパスを通す、ということなのですが、どうするか考えた挙句、NIOS II Command Shellの実体であるintelFPGA_lite/18.1/nios2eds/nios2_command_shell.sh を修正して、

を179行目付近(env_var_prepend が unset される前あたり)に1行追加して対応しました。

VidorGraphicsのリポジトリダウンロードと展開

VidorGraphicsのリポジトリをZIPでダウンロードして、ダウンロードしたVidorGraphics-release.zipを~/intelFPGA_liteディレクトリの下に移動し、ここに展開しました。

VidorGraphicsのビルド

展開した VidorGraphics-release をビルドしようとしたのですが、 projects ディレクトリがありません。実際には VidorBitstream-release/project の下に、MKRVIDOR4000_graphics ディレクトリがありました。なので、先のリポジトリダウンロードも意味がなかったことになります。

で、結局、別のシェルを起動して、ビルドにトライします。

ということで、11分くらいで一応正常終了したようです。ちなみに使用したPCのスペックは、

  • Intel(R) Core(TM) i3-3220T CPU @ 2.80GHz
    (CPUファンはCeleron G530のものの方が大型で冷えそうなのでそちらを使用。実際TDPもG530の方が大きい。)
  • マザーボード ASRock H61M-ITX
  • メモリ 8GB
  • SSD Crucial CT120M500SSD1(120GB)
  • OS LinuxMint19.1 MATE 64bit

といったところです。

生成したファイルをArduino IDEに取り込む

ビルドに成功すると、VidorBitstream-release ディレクトリの下に distrib というディレクトリができて、更にその下に MKRVIDOR4000_graphics ディレクトリができていました。このディレクトリをZIPで圧縮して、MKRVIDOR4000_graphics.zip を作成します。

Arduino IDEで「スケッチ」→「ライブラリをインクルード」→「ZIP形式のライブラリをインストール」で ~/intelFPGA_lite/VidorBitstream-release/distrib/MKRVIDOR4000_graphics.zip を指定してインストールします。すると、 ~/Arduino/libraries の下に展開して取り込まれました。スケッチ例にもカスタムライブラリのスケッチ例として取り込まれました。

同様に、MKRVIDOR4000_peripheralsでもビルドしてみました。

distribの下の MKRVIDOR4000_peripherals ディレクトリをそのまま~/Arduino/libraries の下にコピーしてもライブラリとして認識されるようです。

生成したものを動かしてみる

Arduino IDE上でカスタムライブラリのスケッチ例を動かしてみました。

  • そもそも書き込みにめったに成功しない・・・・
    ⇒ HDMIケーブルを刺していると、そもそもリセットがなかなか掛からない。
  • HDMIケーブルを抜いてから書き込んでみる
    ⇒ VidorDrawLogoは全く動いてない・・・。VidorEncoderも動いている気がしない・・・。うーん。パッチ当てに失敗しているあたりが関係しているのだろうか・・??

なんか、ARM側とFPGA側の通信が全くうまく行ってない気がする。とりあえず、また明日・・・orz

Quartus Prime Lite と ModelSim Starter をインストール

昨日ダウンロードした Quartus Prime Lite Edition と ModelSim Start Edition をインストールします。といっても、やり方がわからなかったので、適当です。^^;
OSはもちろんLinuxMint19.1 MATE edition 64bitです。

ホームディレクトリにダウンロードした以下のファイルをおいてあります。

  • ModelSimSetup-18.1.0.625-linux.run
  • Quartus-lite-18.1.0.625-linux.tar
  • QuartusLiteSetup-18.1.0.625-linux.run
  • cyclone10lp-18.1.0.625.qdz

この状態で実行属性をつけて、動かしてみました。

すると、ウィザードが立ち上がり、何も考えずに勧めていくと、途中でダウンロードしたファイルをすべて検出した状態でインストールするソフトウェアをすべて表示してくれました。

さらに進めていくと、

という表示が出て、勝手に起動する模様・・・・に見えましたが、

というエラーを出して止まっていまいました。

として、インストールしたディレクトリを削除して再度トライするも、やっぱりだめ。今度は、

を実行してから、再度インストールしたディレクトリを削除してトライ。今度は

という画面が出て、フル機能版のライセンスを買うか聞いてきます。趣味・勉強の範囲なので、そんな余裕もないので、真ん中を選んで実行してみます。

という感じで、Quartus Prime Lite Edition が無事に起動しました。

しかし、デスクトップにショートカットは生成されませんでしたので、デスクトップを右クリックして「ランチャの生成」で手動でランチャを作っておきます。

  • 名前は「Quartus Prime Lite Edition」
  • コマンドは「/home/(ユーザー名)/intelFPGA_lite/18.1/quartus/bin/quartus」
  • アイコンは「intelFPGA_lite/18.1/quartus/adm/quartusii.png」

として作成しておきます。作成したものをダブルクリックすると起動することを確認しておきます。

さらに、こちらの情報によるとModelSimを動かすには、32bit用のライブラリが要るらしいので以下の手順でインストールしておきます。

MicroHDMI-HDMIケーブルを入手

昨日ポチったHDMIケーブルは無事に届きました。

こちらの記事を参考に、ブートローダの更新、VidorGraphicsライブラリの追加、スケッチ例のVidorLogoDrawの書き込みを行ったところ、接続してあるHDMIディスプレイに無事に表示がされました。

インテルFPGAプログラムに登録して、インテル® Quartus® Prime 開発ソフトウェア・ライト・エディション(ライセンス不要、無償)をダウンロードします。自分は(相変わらず)Linux版をダウンロードしました。tarアーカイブで6.2GBという巨大なものです。4MB/s程度しか出ず、時間がかかります。

ここで待っている間にシミュレータについて調べます。昔からModelSimの規模と性能の限定版があるはずなので・・・と思ったら、「ModelSim* – Intel® FPGA Starter Edition ソフトウェア」というのがあって、無償で10000ラインまでというものがあるのですが、なんとWindows版しかありません。・・・と思ったら、いろいろリンクを辿っていたら、Linux版にたどり着きました。ダウンロードページの「個別ファイル」の中にあるようです。この中から、とりあえず

  • Quartus Prime (includes Nios II EDS)
  • ModelSim-Intel FPGA Edition (includes Starter Edition)
  • Cyclone 10 LP device support

のダウンロードも仕掛けて今日は寝ます。

Arduino MKR VIDOR 4000を入手

FPGAが載っているArduinoがあるのをTwitterで知って、ついポチってしまいました。アメリカからドイツ経由で2週間強、ようやく届きました。

届いたら、箱がやや潰れてました(泣)。中身は帯電防止袋なしで、帯電防止スポンジに刺さった状態のArduino MKR VIDOR 4000がゴロッと入ってました。幸い、外観上の異常はなさそうです。

で、使い方を調べていたら、HDMIケーブルはMini HDMIじゃなくて、Micro HDMIが必要なことが判明。早速アマゾンでポチりました。

搭載しているチップは、

  • CPU Atmel ATSAMD21
  • FPGA Intel Cyclone10 10CL016YU256C8G
  • DRAM Alliance Memory AS4C4M16SA-7BCN
  • FLASH Winbond 25Q16DVN1G

のようです。CycloneがALTERAのロゴでなくなっているのは時代を感じさせられるのと、Allianceのメモリは昔痛い目にあったので大丈夫なのか不安です(笑)。

しかし、もうチップの刻印が見えない見えない(涙)。ルーペで必死に見ました。

このルーペは40年ほど前に父がドイツに出張した際に買ってきてくれたお土産です。残念ながら、自分が小さい頃だったので、こんなものに頼らなくても小さな文字までバッチリ見えたので扱いを雑にしていたため、レンズの中央部分に細かい傷がたくさんできていて、かなり見辛くなってしまっています。

レンズをよく見ると、ESCHENBACH W-GERMANY という刻印が見えます。W-GERMANYは西ドイツ製ということだと思います。(当時はまだ西ドイツと東ドイツに分かれていて、ベルリンの壁もあった時代です)

で、ESCHENBACHって何かと調べたら、メーカーの名前(ブランド)のようで、実は同じ(に見える)モデルが今では国内でも買えるようです。

ESP32搭載可能なFPGAボード

Hack a dayを見ていたら、新しいFPGAボードの記事が出ていました。搭載しているFPGAがLatticeというのがちょっと好みがわかれそうな気がしないでもないです。このボードの仕様一覧をみていて気づいたのですが、仕様をざっと並べると

  • FPGAは Lattice ECP5 LFE5U-85F-6BG381Cで、84KのLUTと3.7Mbitのメモリを内蔵
  • JTAG I/F用のFT231XSを搭載
  • 32MBのSDRAMを搭載(DDR2とかじゃないので、設計が楽なはず^^;)
  • コンフィグ用を兼ねた4-16MBのフラッシュ(まだ容量確定してないのかな?)
  • MicroSDスロット搭載
  • LED11個、ボタン7個、4極3.5mmジャック
  • 0.96インチのカラーOLEDディスプレイが取付可能
  • ESP-32取付可能(WiFi越しに独立してJTAGをWebで操作可能っぽい!)
  • 無線用アンテナ(27,88−108,144,433MHz)搭載
    (88-108MHzはFMラジオ受信用、他は無線リモコンの受信用ですかね。後者は日本では使えないと思いますが)
  • ADC搭載

ということで、ケーブルレスでFPGAのコンフィグができそうです。JTAGつなぐのめんどくさいのでケーブルレスで行けるのなら面白そうです。ただ、価格帯は$60〜$200ということみたいなので、具体的に何かネタ(と時間と気力)がないとちょっと手が出ないかも。

MAX10評価ボードが欲しくなった

たまたまネットを彷徨っていたらMOUSERでMAX10の評価ボードを見かけました。

A/Dコンバータを内蔵していて、Arduinoのシールドが搭載可能。ロジック規模は8000LEのものを搭載しているようなので、NiosIIプロセッサも余裕で入るでしょう。(評価ボードの詳細はここに記載があります)

NiosIIはgccでサポートされていますから、『NiosII版Arduino類似IDE』+『高速処理が必要なところはFPGA内にハードウェアマクロで記述』+『もちろんA/Dは使用可能』という環境が登場するかもしれません。(本家ArduinoにもないD/AもPWMではなくデルタシグマDAを実装すれば実現できてしまいますし、回路規模さえ入れば必要なだけ入れられますからねぇ・・)

・・・おもわずポチりそうになりましたが、ALTERAの開発ツールのページを見ると、他にもいくつか安価な評価キットがあるようなのでしばらく様子見することにします。(その前に、DE0を使いこなせよ、という話が・・)

それにしても、ある程度の規模までの用途であればFPGA1個に全てが入っていってしまう感じですね。かつての電卓戦争を思い出します。こうして少しずつハードウェアとソフトウェアの境界がなくなっていくのでしょう。

<追伸>
FPGA上にArduinoに似た環境を作る試みはすでにXilinxのFPGAで行われているようです。こちらはAVR互換コアと32bitコアを96MHzで駆動するZPUinoという環境の2種類があるようです。

EPM570T100C5Nを動かしてみた

MAX7000Aはどうしようもないので、ITプラザへ行ってオプティマイズのMAX2 CPLDボードを買ってきました。

さくさくっと組み立てます。QFPがハンダ付け済みなので楽ちんです。

今回はブレッドボードとの組み合わせで使うので、ピンソケットを部品面に載せて、ブレッドボード上に置きます。

スイッチの入力に応じてLEDがチカチカするところまで行きました。

しかしながら、やはりCPLDは同期回路を動かしてなんぼです。

3.3Vで動くオシレータがなかったので、余っていたPIC12F675をコンフィギュレーションビットで「内部オシレータ・CLKOUTイネーブル」に設定して1MHzクロックを出力させるようにして接続し、CPLDのクロック入力としてLEDをチカチカさせました。

参考になるかわかりませんが、ソースを置いておきます。BLINKLED.vhd.zip
(端子の指定は別途行ってください)
F/Fのリセットもやってない(そもそもリセット信号を入れてない)とか、スイッチの入力を直接カウンタのイネーブルにつないでる(本来ならF/Fを2回通して同期化すべき)とかありますが、動作確認レベルなので端折っています。