Posts Tagged with "Arty"

既に発行済みのブログであっても適宜修正・追加することがあります。
We may make changes and additions to blogs already published.

デザインのボード間移植

posted by sakurai on June 18, 2021 #424

ArtyボードからUltra96ボードへ

RTLにはボード依存性はありませんが、トップモジュールやIPにはボード依存性があるため、その移植が必要となります。まずトップ配線(ブロック間配線)は、Export Block Designにより、配線情報がTCLにより得られるので、それを入力したいところです。しかし、ボード依存性があるようで、新ボードを設定した上で旧ボードのTCLを読み込むとエラーになってしまいます。そのため、

  • 旧ボードの環境でデザインを構築しておき、新規ボードに変換する

方法により、デザインのボード間移植を実施しました。

新規プロジェクトの生成

最初に旧ボードでプロジェクトを生成します。この段階で必要なものはVerilogソースが全て含まれているsrcディレクトリ、ブロックデザインのTCL、新ボードのXDCのひな形です。

  1. Vivadoの下にプロジェクトフォルダを作成します。その下に、Verilogソースが全て含まれているsrcディレクトリ、ブロックデザインのtcl及び、xdcを配置します。
  2. Vivadoを起動し、Create Project⇒Next⇒RTLプロジェクトを選択し、Verilogソースフォルダを選択します。
  3. 次にconstraintファイルとしてxdcを設定します。
  4. Boardsとして旧ボードを選択します。
  5. FinishによりProjectが生成されます。
  6. IP Integrator⇒Create Block Designを実行します。
  7. BLOCK DESIGN⇒Sources⇒Design sourcesのトップデザインであるdesin_1に対してラッパを生成します。
  8. design_1を選択して右クリックでCreate HDL wrapperを実行するとダイアログが現れます。
  9. Let Vivado ...を選択してOKをクリックします。
  10. オレンジの階層だったものが、design_1_wapperというグリーンの階層が生成されます。
  11. それを右クリックし、Set as topにより、トップ階層とします。
  12. 最下段のTCL Console内で、source C:/Users/<ユーザ名>/Vivado/<プロジェクト名>/design_1.tclを実行します。
  13. ブロックが配置され、ブロック間に配線されます。Diagramを右クリックしてExpand Allし、Regenerate Layoutをクリックします。
  14. タイトルコメントのText sizeを64、Box fill colorを204,255,255とします。

新ボードへ移行

  1. ボードが旧ボードになっているので、PROJECT MANAGER⇒Settingsでダイアログを立ち上げ、Project Settings⇒General⇒Project device:によりボードを新ボードに変更します。
  2. BLOCK DESIGNに、IPのアップグレードを促す指示が出るため、個数をクリックします。Show IP Statusをクリックします。
  3. 最下段のUpgrade SelectedをクリックしIPのアップグレードを実施します。
  4. IPによっては結線が外れていることがあるため、良く見直して、外れていれば接続しなおします。

注意点

coeファイルは相対ディレクトリで記録されますが、tclスクリプトからうまく参照できないようなので、全て絶対ディレクトリ(例:e:\file.coe)として参照できるようにしました。


左矢前のブログ 次のブログ右矢

QSPI Flashへの書き込み

posted by sakurai on June 1, 2021 #410

QSPIへの再書き込み

Artyボードにおいて、基本的には過去記事で示した手順でFlashに書き込みます。ところが、一度Flashに書き込むと、Add Configuration Memory Deviceがグレーアウトされていることがあります。その場合は、

図%%.1
図410.1

このように、JTAGのデバイスを右クリックすると、メニューが現れるので、Program Configuration Memory Deviceをクリックします。すると次の画面が出るので、デバイスを選択し、プログラミングします。

図%%.2
図410.2


左矢前のブログ 次のブログ右矢

Space Invadersの構成と物量

posted by sakurai on May 31, 2021 #409

ブロック図

ブロック図をIP Integratorで示します。

図%%.1
図409.1 ブロック図

リソース使用量

各階層(ソフトブロック)のリソース使用量を図409.2に示します。

図%%.2
図409.2 リソース使用量

表409.1に示すように、BRAMの割合がかなり大きいです。全部で50個中、39.5個を使用しています。

表409.1
リソース 割合[%]
MMCM 20
BUFG 25
I/O 16
BRAM 79
FF 6
LUT 36

モジュール配置

各階層の配置状況を図409.3に示します。おもしろいことに、サウンドが4つのまとまりに分かれていますが、図409.4のように4つのステートマシン毎に固まっていました。

図%%.3
図409.3 モジュール配置図

図%%.4
図409.4 サウンド関係配置図


左矢前のブログ 次のブログ右矢

ゲームFSMとサウンドFSMの連携

posted by sakurai on June 5, 2020 #271

Ultra96においてBSVで開発

元々Verilog版では、コマンドバッファに書き込むだけで特に何もしなくても動作していました。今回BSVで再設計する際に、サウンドを4chとし、取りこぼしを避けるために考えたのがサウンドキュー(FIFO)でした。

図%%.1
図271.1 サウンドキュー

これはVivadoのFIFOジェネレータで作成したため、最小段数でもかなり深く1024段程度となっています。 実験したところ、確かに取りこぼしは無いのですが、一方、サウンドがゲームとズレて行き、まるでサウンドレコーダのような動作になってしまいました。そのため、FIFOを1段に修正しました。FIFOジェネレータでは1段のFIFOは作成できないのでVerilogで記述しました。1段のためFIFOと呼ぶのはおかしいのでコマンドバッファと呼ぶことにします。

コマンドバッファには、ゲームFSMからコマンドが来たことを示すフラグemptyを設け、書き込むと!emptyとなるようにします。サウンドFSMからは!emptyの時に新たにコマンドが来たと判断し、コマンドを読んだ後にemptyに変更します。

図%%.2
図271.2 1段バッファに変更

Artyボード移植後

Ultra96ではこれで動作していたのですが、Artyボードに移植後に自機増加音が無視されることに気づきました。サウンドFSMが取りこぼしているのだと推測し、再考すると、ゲームFSMが不必要に速いことに気づきました。DSOを接続して調べたところ、96.4%がウェイトだと判明したので、これを1MHzに落としたところ、動作するようでした。

ところが実験すると、依然として自機増加音(コマンドNo.9)が無視されるようです。そこで、ILAを接続して、

  • サウンドコマンド
  • サウンドFSMステート
  • コマンドバッファemtpy
  • サウンドFSM内部フラグ(fNO9)

を観測しました。最後の内部フラグfNO9は自機増加音がプリエンプトされないように割込みを禁止するためのフラグで、コマンドNo.9を受け付けた際にTrueになる信号です。

図%%.3
図271.3 ILA波形(NG)

図271.3はゲームFSMクロックを2MHzとして取得したものですが、フラグfNO9がTrueにならず、コマンドNo.9を無視しています。その原因は、サウンドFSMが受け取る前に次のコマンドNo.4を上書きしているためです。

従って、コマンドの書き込みの際にemptyである場合のみ書き込み、!emptyの場合は捨てる処理を行います(図271.4のマゼンタ矢印の処理を追加)。

図%%.4
図271.4 両側でemptyを確認するように修正

このように修正したところ、No.9の次のコマンドが!empty(=buffer full)のため捨てられることにより、図271.5のように受け付けられるようになりました。
図%%.5
図271.5 ILA波形(OK)

FIFOではないので、原理上取りこぼしは防げないものの、実用上これで動作するようです。

左矢前のブログ 次のブログ右矢

posted by sakurai on June 4, 2020 #270

QSPIフラッシュへの書き込み

通常ではVivadoからPROGRAM AND DEBUG⇒Open Hardware Manager⇒Open Target⇒Auto Connectとし、Program DeviceによりJTAG経由でFPGAにビットストリームを焼きこみます。しかしながらこれだと電源断によりFPGAのSRAM内容が消えてしまいます。また、FPGAプログラミング用のPCが常に必要です。オンボードFlashにデータを焼きこめばPCを持ち運ぶ必要がなく、電源onでアプリケーションが立ち上がるため、Flashのプログラミングを行います。

binファイルの作成

最初にFlashへ書き込むデータファイルであるbinファイルを用意します。これは、Tools⇒Setting(歯車マーク)⇒Project Settings⇒Implementation画面で行います。この画面を開くと、Write Bitstream(write_bitstream)という選択枝が現れ、その下に複数のチェックボックスが表示されます。その中の、-bin_file*のチェックボックスにチェックします。

図%%.1
図270.1 bin_fileにチェック

これを行ってから、通常どおりPROGRAM AND DEBUG⇒Generate Bitstreamを実施するとWrite Bitstreamが完了しますが、同時にbinファイルが生成されています。場所はbitファイルと同じところで'プロジェクト/プロジェクト.runs/impl_1/'です。

binファイルの焼きこみ

binファイルができたら、Add Configuration Memoryにより、Add Configuration Memory Device画面が開きます。Flashデバイスの選択が可能なので、この中で"s25fl128sxxxxx0"を選択します。Search窓にs25fl128を入力すれば、候補が3つ現れますがその真ん中です。

図%%.2
図270.2 FLASHデバイスの選択

選択したらOKをクリックします。するとプログラミングが始まり、30秒程でプログラミングが完了します。

実行

リファレンスマニュアルにはJP1でプログラミングモードが決まるとあります。JP1の位置がどちらでもJTAGからは書き込めるとのことです。初期状態はJP1はショートで、SPI-FLASHのモードとなっており、そのまま電源のOFF⇒ONでSpace Invadersが立ち上がりました。

図%%.3
図270.3 JTAG接続なしにSpace Invadersが動作


左矢前のブログ 次のブログ右矢

posted by sakurai on June 3, 2020 #269

Arty A7-35ボードの購入

DigilentからArty A7-35ボード(魚拓)を購入しました。このボードはUltra96と比べて本体が約半額と安いだけでなく、(弊社開発の)PMOD変換ボードも不要なので、最も安くSpace Invadersを動かすことができます。

必要な周辺

Space Invadersを動作させるには、Artyボードの他に必要なものは以下のとおりです。

Arty A7-35ボードへの移植

除算器を引き算に変換

FPGAの世代や遅延、容量は違うものの、基本的には同様に動作するはずです。ところが、一部動作がおかしかったので修正しました。まず、除算器にバグがあるようなので引き算方式に修正しました。スコアを表示する箇所において、各桁表示のため1000、100、10で割る場合がありますが、1000で割った商を誤ることがあるようです。除算をやめ、引けなくなるまで1000、100、10を引く方式に変更したところ、回路規模も小さくなり正常に動作するようになりました。

FSM clockを1/10に変更

ゲームFSMクロックを10MHzで設計し、96.4%がウェイトだと判明したので、FSMクロックを1MHzに落としました。自機増加音が無視されることがあるので、クロックを落としたのですが、原因は異なっていました(後述)。

60Hzクロックの生成

この修正により、FSMの待ち時間が影響を受けます。1tick=60HzのタイミングをとるのにFSMクロック数を数えていましたが、FSMクロックの周波数が変わるため、外部から60Hzを入力するように修正します。60Hzクロックは、上記FSMクロックである1MHzクロックをバイナリカウンタで\$411B回カウントすることで生成します。さらにFSM内での60Hzクロックとの同期は以下のように行います。countはtick(=16.67msec)の何倍待たせるかを示す引数です。

     repeat(pack(extend(count))) seq
        await(tick == 0);
        await(tick == 1);
     endseq

60Hzクロックの"L"を待ち、もし"L"であれば次に"H"を待つようにします。これにより60Hzの立ち上がりに同期して動作することになります。

このように変更した結果、FSMの処理時間は10倍の約5msecに増加し、60Hzの周期16.67msecの約30%になりました。図269.2の黄線が60Hzクロック、青線がそれによる実行(Hでウエイト中、Lで実行中)を示します。

図%%.8
図269.8 青線が"H"でウェイト中


左矢前のブログ 次のブログ右矢