MKRVIDOR4000_graphicsのサンプルスケッチが中途半端に表示がされる原因についてもわかりました。
中途半端に表示がされるのは、サンプルスケッチ VidorDrawLogo の冒頭にある
vdgfx.fillRect(0,0,640,480,vdgfx.White());
のFPGA側での処理が遅いことと、初期化時にそもそも白で全面クリアされていること、ARM側の処理でFPGA側の処理完了を待っていてもタイムアウトするほど遅いことが原因です。初期化時にそもそも白で全面クリアされているので、その上に処理の遅いfillRect()が同色で描画されても、画面上は何も見えません。fillRect()の処理が終わった後に描画要求が飛んでくる部分だけが見える、というわけです。
その証拠に、
vdgfx.fillRect(0,0,640,480,vdgfx.Blue());
と色を変えてやると、ちょっとずつ青く塗っていく処理と、その後で一部の文字が描画されるのがわかります。
というわけで、fillRect()の部分をコメントアウトすることで無事に表示されるようになりました。
まとめ
Linux Mint 19.1 上の Quartus Prime Lite Edition 18.1で MKR Vidor 4000 のFPGAのコードをビルドする場合は以下の点に注意。
- apply_quartus_patches.shでパッチを当てる際には、arduino_generic_quad_spi_controller2_sw.tcl に対するパッチ適用は失敗するので、手動で適用すべし。
- スケッチサンプルの冒頭のfillRect()はコメントアウトすべし（もしくは、色を変えた上で、Arduinoライブラリの中の VidorMailbox.cpp の冒頭のMB_TIMEOUTを大きく伸ばすべし）
おまけ
Arduino側（ARM側）のライブラリを見ていてARM側からは以下のようにFPGA側にリクエストが伝わるようです。
Vidor_GFX.cpp ⇒ VidorMailbox.cpp ⇒ VidorJTAG.cpp ⇒ jtag_host.cpp ⇒ JTAG信号線
グラフックスの関数はリモートプロシージャコール（ｒｐｃ）のパラメータの配列（uint32_tの配列）に変換されて、VidorMailbox.sendCommand() が呼び出されます。パラメータはVidorJTAG.writeBuffer()の引数として渡されますが、最終的には jtag_host.cpp で１ビットずつJTAG信号としてFPGA側へ転送されます。すべてソフトウェアでJTAG信号を生成しているようなので、コマンドの転送自体が遅そうです。Mailboxへのコマンド送信後の応答待ち時間は VidorMailbox.cpp の冒頭の MB_TIMEOUT で定義されていて、5000ms=5秒になっているようです。
FPGA側の処理については調べていないのでこれからです。