 |
3 |
ソフトブロック解説 (2) |
 |
引き続きinvader階層です。これはインベーダゲームの中心となる、GameFSM(invader_move)を含む階層です。基本的には、
の2つのモジュールにより、VRAMをR/Wすることにより絵を動かしています。この階層には、さらに以下のモジュールが存在します。
|
2 |
ソフトブロック解説 |
|
ここから、簡単に各ソフトブロック階層の解説をします。全体ブロック図は過去記事に挙げてあります。全体ブロック図において、左から順に、clock階層、メモリダンプモジュール(ソフトブロック階層無し)、invader階層、VRAM階層、graphics階層、sound階層となっています。
図411.1にclock階層の構造を示します。使用されているモジュールは全てXilinx IPです。
の2本です。出力は、
|
31 |
Space Invadersの構成と物量 |
|
ブロック図をIP Integratorで示します。
各階層(ソフトブロック)のリソース使用量を図409.2に示します。
表409.1に示すように、BRAMの割合がかなり大きいです。全部で50個中、39.5個を使用しています。
| リソース | 割合[%] |
|---|---|
| MMCM | 20 |
| BUFG | 25 |
| I/O | 16 |
| BRAM | 79 |
| FF | 6 |
| LUT | 36 |
各階層の配置状況を図409.3に示します。おもしろいことに、サウンドが4つのまとまりに分かれていますが、図409.4のように4つのステートマシン毎に固まっていました。
|
28 |
BSVによる歩行音の改善 |
|
インベーダの歩行音は、現在は隊列に同期して出力されます。インベーダ一匹の歩行処理は60Hzで実施されるため、初期状態では55/60secに一度、最後の一匹では1/60secに一度歩行音が出力されます。
最後の一匹の時に、どうも歩行音が速すぎると思っていたら、過去記事のとおり、インベーダの数に応じた間隔で歩行音が出力され、必ずしも隊列の動作とは同期していないことが判明しました。アニメーションは、インベーダーの数に比例して徐々に速くなるのに比べ、サウンドは段階的に速くなるのは、どのような意図があるのでしょうか？
なるべくオリジナルに近づけるという方針から、今回はこれを実装します。
まず、過去記事の表を実装します。タイマ初期値の最大値は52なので6bitのレジスタが55個必要です。1から55までを使用しており、0を含めた56個を定義しています。
UInt#(6) inv_init_stimer[56] = {5, 5, 7, 9,11,12,13,14,16,16,19,19,19,21,21,21,21,24,24,24,
24,24,28,28,28,28,28,28,34,34,34,34,34,34,34,34,39,39,39,39,
39,39,39,46,46,46,46,46,46,46,52,52,52,52,52,52};
過去記事の歩行音間隔タイマの仕様に示すように、これはタイムアウトした際に、インベーダ数に応じた値でタイマを初期化するための表です。次に、歩行音間隔タイマ本体を実装します。
Reg#(UInt#(6)) inv_stimer <- mkRegU;
次に、サウンドパターンは4から7を繰り返すため、2bitのパターンレジスタを用意します。
Reg#(UInt#(2)) inv_spattern <- mkRegU;
初期化部分です。タイマの初期値は52とします。パターンの初期値は0とします。
inv_stimer <= 52;
inv_spattern <= 0;
隊の先頭で実施していた次のサウンド出力処理を削除します。
// if (inv_ido != END_STATE) seq
// sound(extend(inv_pattern) + 4); // from 4 to 7
// endseq
その代わり、 全てのインベーダについて次の処理を追加します。
// 全てのインベーダについて処理
if (inv_stimer == 0) seq
sound(extend(inv_spattern) + 4); // from 4 to 7
inv_spattern <= inv_spattern + 1;
inv_stimer <= inv_init_stimer[inv_no];
endseq else seq
inv_stimer <= inv_stimer - 1;
endseq
これにより過去記事のような動作を行うはずです。⇒実施したところ、正しく動作したようです。
|
27 |
BSVによるメモリダンプモジュールの設計 (10) |
|
受信したデータは以下の図に示すように、一文字4bitのデータが連続する、VRAM内容を示すログデータです(右側を一部省略)。
VRAMデータ4bitの意味は以下のとおりです。
従って、非画像情報を無視し、次のコードにより画像フォーマットであるPPMに変換します。
log2ppm.c
#include
void main() {
char line[4096];
char ch;
printf("P3\n256 256\n255\n");
for(int y = 0; y <= 255; y++) {
fgets(line, sizeof(line), stdin);
for(int x = 0; x <= 255; x++) {
ch = line[x] - 0x30;
if ((ch & 0x4) != 0) printf("255 "); // R
else printf("0 ");
if ((ch & 0x2) != 0) printf("255 "); // G
else printf("0 ");
if ((ch & 0x1) != 0) printf("255 "); // B
else printf("0 ");
}
printf("\n");
}
}
以下のコマンドによりフィルタを作成します。
$ gcc -O log2ppm.c -o log2ppm
上記のようにフィルターとして実行し、ログデータを画像ファイルに変換します。
$ ./log2ppm putty.ppm
生成されたファイルを画像処理ツールであるgimp2で開くと以下のように正常に受信されています。
以上で、ゲームのメモリダンプ機能がひとおおり完成しました。ゲームの状態を吸い出したのは、これをオートエンコーダによりCNNに認識させるのを目的としています。
|
18 |
インベーダーゲームのソースの研究 (2) |
|
インベーダーゲームのソースの研究を読んで理解したことを記します。
参考にしたUFOスコア表です。
この表には重なりがあるので、実は、表は1つで問題ありません。右に8個シフトすると重なることがわかります。
弊社のBSV実装では以下の表を用いています。
UInt#(5) ufo_score[15] = {10,10,10,5,15,10,10,5,5,10,15,10,10,5,30};
ただし、インデックスの初期値を6としており、7番目から使用することで上記のアルゴリズムを再現しています。まず、インデックスの初期化です。
ufo_score_idx <= 6;
次にインクリメント部です。この表は15エントリしかないので、15でラップアラウンドします。
ufo_score_idx <= ufo_score_idx + 1;
if (ufo_score_idx == 15) ufo_score_idx <= 0;
また、インベーダーゲームは得点の1の位は常に0なので、得点は1/10で記憶しています。
さて、ソースコードの研究によると、少々ズレています。
結果として、上記は実装が微妙に異なるものの、最終的には同一の結果となります。
|
17 |
インベーダーゲームのソースの研究 |
|
インベーダーゲームのソースの研究を読んで理解したことを記します。
参考にしたcellvaderにおいて、敵弾の移動速度は1pixcel/tickでした(tick=1/60sec)。それで特に違和感がなかったのですが、上記資料を見ると、33%も速い4pixcel/3tickとのこと。そのため、3tick毎に4pixcel動かすように修正しますが、注意として衝突判定は1pixcel毎に行う必要があります。そうでないとすり抜けが起きる可能性があります。従って、
タイムフレーム0: 何もしない
タイムフレーム1: 何もしない
タイムフレーム2:
y-1の位置で衝突判定、衝突の場合は衝突処理し中断、非衝突の場合は下へ
y-2の位置で衝突判定、衝突の場合は衝突処理し中断、非衝突の場合は下へ
y-3の位置で衝突判定、衝突の場合は衝突処理し中断、非衝突の場合は下へ
y-4の位置で衝突判定、衝突の場合は衝突処理し中断、非衝突の場合は下へ
y-4の位置に敵弾移動
この3フレームを繰り返すことになります。さらに、インベーダ―数が8未満の場合は敵弾速度が高速化するとのことです。具体的には5pixcel/3tickとなります。従って以下のようになります。
タイムフレーム0: 何もしない
タイムフレーム1: 何もしない
タイムフレーム2:
y-1の位置で衝突判定、衝突の場合は衝突処理し中断、非衝突の場合は下へ
y-2の位置で衝突判定、衝突の場合は衝突処理し中断、非衝突の場合は下へ
y-3の位置で衝突判定、衝突の場合は衝突処理し中断、非衝突の場合は下へ
y-4の位置で衝突判定、衝突の場合は衝突処理し中断、非衝突の場合は下へ
y-5の位置で衝突判定、衝突の場合は衝突処理し中断、非衝突の場合は下へ
y-5の位置に敵弾移動
フリートトーン(fleet tone)、もしくはステップサウンド(step sounds)と書かれていますが、インベーダーの歩行音のことです。同じく参考にしたcellvaderでは、歩行音の発生間隔は1tone/1fleetでした。つまり隊の動作と歩行音が同期しています。ただし、歩行音の発生毎に4種類の歩行音を切り替えます。
ところが、インベーダーゲームのソースの研究では、隊の移動と歩行音は同期しておらず、歩行音間隔の最小は5だとのことです。具体的な表を示せば、オリジナルのアルゴリズムは以下の表318.1のようになります。確かに、現状の実装ではインベーダー数が1になる場合は歩行音が速すぎる気がします。原文には5未満になると不愉快な音になると書かれています。
| インベーダー数[匹] | 歩行音間隔[tick] |
|---|---|
| 55 | 52 |
| 54 | 52 |
| 53 | 52 |
| 52 | 52 |
| 51 | 52 |
| 50 | 52 |
| 49 | 46 |
| 48 | 46 |
| 47 | 46 |
| 46 | 46 |
| 45 | 46 |
| 44 | 46 |
| 43 | 46 |
| 42 | 39 |
| 41 | 39 |
| 40 | 39 |
| 39 | 39 |
| 38 | 39 |
| 37 | 39 |
| 36 | 39 |
| 35 | 34 |
| 34 | 34 |
| 33 | 34 |
| 32 | 34 |
| 31 | 34 |
| 30 | 34 |
| 29 | 34 |
| 28 | 34 |
| 27 | 28 |
| 26 | 28 |
| 25 | 28 |
| 24 | 28 |
| 23 | 28 |
| 22 | 28 |
| 21 | 24 |
| 20 | 24 |
| 19 | 24 |
| 18 | 24 |
| 17 | 24 |
| 16 | 21 |
| 15 | 21 |
| 14 | 21 |
| 13 | 21 |
| 12 | 19 |
| 11 | 19 |
| 10 | 19 |
| 9 | 16 |
| 8 | 16 |
| 7 | 14 |
| 6 | 13 |
| 5 | 12 |
| 4 | 11 |
| 3 | 9 |
| 2 | 7 |
| 1 | 5 |
そのため、現状での隊(rack)の先頭での歩行音処理を廃止し、次の処理を追加予定です。
インベーダーが減るたびに上表を引いて歩行音間隔値を変更するのではありません。それだとタイマーがゼロになる寸前でインベーダーが死ぬと新たなタイマー値がロードされ、歩行音間隔が約2倍の長さとなる不具合が起きる可能性があります。
歩行音が隊と同期はしていても不快な音にならないように、最小を5にするだけで良いような気もしますが。
⇒ブログ記事で実装完了しました。
|
5 |
ゲームFSMとサウンドFSMの連携 |
|
元々Verilog版では、コマンドバッファに書き込むだけで特に何もしなくても動作していました。今回BSVで再設計する際に、サウンドを4chとし、取りこぼしを避けるために考えたのがサウンドキュー(FIFO)でした。
これはVivadoのFIFOジェネレータで作成したため、最小段数でもかなり深く1024段程度となっています。 実験したところ、確かに取りこぼしは無いのですが、一方、サウンドがゲームとズレて行き、まるでサウンドレコーダのような動作になってしまいました。そのため、FIFOを1段に修正しました。FIFOジェネレータでは1段のFIFOは作成できないのでVerilogで記述しました。1段のためFIFOと呼ぶのはおかしいのでコマンドバッファと呼ぶことにします。
コマンドバッファには、ゲームFSMからコマンドが来たことを示すフラグemptyを設け、書き込むと!emptyとなるようにします。サウンドFSMからは!emptyの時に新たにコマンドが来たと判断し、コマンドを読んだ後にemptyに変更します。
Ultra96ではこれで動作していたのですが、Artyボードに移植後に自機増加音が無視されることに気づきました。サウンドFSMが取りこぼしているのだと推測し、再考すると、ゲームFSMが不必要に速いことに気づきました。DSOを接続して調べたところ、96.4%がウェイトだと判明したので、これを1MHzに落としたところ、動作するようでした。
ところが実験すると、依然として自機増加音(コマンドNo.9)が無視されるようです。そこで、ILAを接続して、
を観測しました。最後の内部フラグfNO9は自機増加音がプリエンプトされないように割込みを禁止するためのフラグで、コマンドNo.9を受け付けた際にTrueになる信号です。
従って、コマンドの書き込みの際にemptyである場合のみ書き込み、!emptyの場合は捨てる処理を行います(図271.4のマゼンタ矢印の処理を追加)。
通常ではVivadoからPROGRAM AND DEBUG⇒Open Hardware Manager⇒Open Target⇒Auto Connectとし、Program DeviceによりJTAG経由でFPGAにビットストリームを焼きこみます。しかしながらこれだと電源断によりFPGAのSRAM内容が消えてしまいます。また、FPGAプログラミング用のPCが常に必要です。オンボードFlashにデータを焼きこめばPCを持ち運ぶ必要がなく、電源onでアプリケーションが立ち上がるため、Flashのプログラミングを行います。
最初にFlashへ書き込むデータファイルであるbinファイルを用意します。これは、Tools⇒Setting(歯車マーク)⇒Project Settings⇒Bitstream画面で行います。この画面を開くと複数のチェックボックスが表示されます。その中の、-bin_file*のチェックボックスにチェックします。
これを行ってから、通常どおりPROGRAM AND DEBUG⇒Generate Bitstreamを実施するとWrite Bitstreamが完了しますが、同時にbinファイルが生成されています。場所はbitファイルと同じところで'プロジェクト/プロジェクト.runs/impl_1/'です。
binファイルができたらProgram Deviceの下のAdd Configuration Memoryにより、Add Configuration Memory Device画面が開きます。Flashデバイスの選択が可能なので、この中で"s25fl128sxxxxx0"を選択します。Search窓にs25fl128を入力すれば、候補が3つ現れますがその真ん中です。
リファレンスマニュアルにはJP1でプログラミングモードが決まるとあります。JP1の位置がどちらでもJTAGからは書き込めるとのことです。初期状態はJP1はショートで、SPI-FLASHのモードとなっており、そのまま電源のOFF⇒ONでSpace Invadersが立ち上がりました。
DigilentからArty A7-35ボード(魚拓)を購入しました。このボードはUltra96と比べて本体が約半額と安いだけでなく、(弊社開発の)PMOD変換ボードも不要なので、最も安くSpace Invadersを動かすことができます。
Space Invadersを動作させるには、Artyボードの他に必要なものは以下のとおりです。
図269.1 PMOD I2Sインタフェースとケーブル
図269.2 アンプ付きミニスピーカ
図269.3 PMOD VGAインタフェースとVGA/HDMIインタフェース
図269.4 PMOD JOYスティック・スイッチインタフェース
図269.5 JOYスティック・スイッチ
図269.6 Micro-B USBケーブル
図269.7に、これら周辺を全て接続したArtyボードの写真を示します。
図269.7 Artyボードに周辺を接続
FPGAの世代や遅延、容量は違うものの、基本的には同様に動作するはずです。ところが、一部動作がおかしかったので修正しました。まず、除算器にバグがあるようなので引き算方式に修正しました。スコアを表示する箇所において、各桁表示のため1000、100、10で割る場合がありますが、1000で割った商を誤ることがあるようです。除算をやめ、引けなくなるまで1000、100、10を引く方式に変更したところ、回路規模も小さくなり正常に動作するようになりました。
ゲームFSMクロックを10MHzで設計し、96.4%がウェイトだと判明したので、FSMクロックを1MHzに落としました。自機増加音が無視されることがあるので、クロックを落としたのですが、原因は異なっていました(後述)。
この修正により、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で実行中)を示します。
図269.8 青線が"H"でウェイト中
