サウンドFSMの作成(2)

階層化ステートマシンを解説します。基本的にBluespecにおいてはrule文のガードによりステートに入る条件を定義し、rule文の内部でステートの処理を定義します。そこで、ruleを構造化することで、ステートの構造化を実現します。具体的には以下のような構造となります。

    rule ruleSOUND (state.cat == SOUND);

       rule ruleFORMAT (state.func == FORMAT);

          rule ruleS0 (state.step == S0); 
             // call readcount();
             state <= State_t {cat:SOUND, func:READCOUNT, step:S0}; 
             ret <= State_t {cat:SOUND, func:FORMAT, step:S1};
             case (code)
                'h1: romaddr <=     0 + 16;
                'h2: romaddr <=  4318 + 16;
                'h9: romaddr <= 13094 + 16;
             endcase
          endrule

          rule ruleS1 (state.step == S1);
             state <= State_t {cat:SOUND, func:DATA, step:S0};
             romaddr <= romaddr + extend(dcount);
          endrule

       endrule // FORMAT

ruleS0ではcodeによりROMアドレス先頭を決定します。wave formatの16バイト目からフォーマット長取得を行います。readcount()をコールしており、そのリターンはruleS1ステートです。readcount()ではdcount変数に4バイトの数値が得られます。

     rule ruleDATA (state.func == DATA);

         rule ruleS0 (state.step == S0);
             // call readcount();
             state <= State_t {cat:SOUND, func:READCOUNT, step:S0}; 
             ret <= State_t {cat:SOUND, func:DATA, step:S1};
             romaddr <= romaddr + 4; // skip "data"
         endrule

         rule ruleS1 (state.step == S1);
             state <= State_t {cat:SOUND, func:PLAY, step:S0}; 
             romaddr <= romaddr - 1;
         endrule

      endrule // DATA

dcountにデータ長が得られたので、実際のサウンドデータを出力するため、PLAYに移行します。

前のブログ 次のブログ

サウンドFSMの作成

waveフォーマット解析とデータ供給を実行する、メインのFSMの設計を行います。このような小さいFSMであっても階層設計を行います。その理由はソフトウェアと同じで、構造化のためです。最上位ステートは図236.1のようにINIT, SOUNDの2ステートとします。基本的にINITでは外部からサウンドコードが送信されてくるのを待ち、自分のコードであればSOUNDに遷移します。サウンド出力が終了すると、またINITに戻ります。

フラットなFSMではステート変数を整数で持ちますが、階層FSMでは構造体で持つことにします。階層は3階層で、上位2階層が意味のある機能を示し、最下層はステップとします。次に構造体の記述を示します。

    typedef struct {
           Category_t cat;
           Function_t func;
           Step_t step;
    } State_t deriving(Bits,Eq);

上位からカテゴリー、ファンクション、ステップと名付けました。最上位のカテゴリーは先の図のように、 INIT, SOUNDの2ステートからなります。

    typedef enum { INIT, SOUND } Category_t deriving(Bits,Eq);

INITでは中間階層である機能は特になく、2ステートを持ち、LRCLKと同期させます。これはFSMクロックがLRCLKよりも速いため、LRCLKと確率的に位相が合わなくなるためです。

SOUNDでは機能としてFORMAT, DATA, PLAY, READCOUNT, READMEMの5種を持ちます。それぞれの機能は、フォーマット解析、データ長取得、演奏です。さらにそこから呼ばれる共通シーケンス(サブルーチン)として、データ長読み出し、データ1バイト読み出しが存在します。

    typedef enum { FORMAT, DATA, PLAY, READCOUNT, READMEM } Function_t deriving(Bits,Eq);

同階層内にコール関係があり、DATAからREADCOUNTをコールします。さらにREADCOUNTからREADMEMをコールするので、リターンスタックは2段必要です。

最下層のステップの名前には特に意味が無く、シーケンシャルにステートを進めるだけです。シーケンシャルになる理由は、フォーマット解析やROMのデータ待ちなど様々です。

    typedef enum { S0, S1, S2, S3, S4, S5, S6 } Step_t deriving(Bits,Eq);

以上は宣言であり、実際のインスタンシエーションは以下のようにモジュール内部で行います。

    Reg#(State_t) state <- mkReg(State_t{cat:INIT,func:?,step:S0}),
         ret <- mkRegU,
         ret2 <- mkRegU;

ステート構造体stateと、さらに同じ構造を持つ2本のリターンレジスタret, ret2をインスタンスしています。

前のブログ 次のブログ

ROMの作成

図234.2に示したように、サウンドROMが存在するので、BSVで作成します。ROMは合成には使用しませんが、bsimシミュレーションのために、 ROMは書き込まないRAMとして実装します。RAMはBSVではRegFileライブラリを使用します。RegFileは実際には1W5RのマルチポートRAMですが、他のポートは使用しません。

    import RegFile::*;

最初にこの行によりライブラリRegFileを導入します。インスタンスは次の行で行います。同時にROMファイルの内容をロードします。

    typedef Bit#(15) Addr_t;
    typedef Bit#(8) Data_t;
    RegFile#(Addr_t, Data_t) rom <- mkRegFileLoad("sound_data/ch00.hex", 0, 18593);

以下にROMファイルの内容を示します。チャネル0のファイルは3つのサウンドを持つ、18,594バイトのファイルです。

    52
    49
    46
    46
    d6
    10
    :

サウンドの難しさ

映像とサウンドを一致させるには難しさがあります。

• ワンショット --- 映像のほうがサウンドよりも長いため、ひとつの映像事象において複数のサウンドが鳴ってしまう。例えば自弾がどこにも当たらずに飛行して壁で爆発するまでに、発射音が複数回鳴ってしまう。 図235.1 ワンショットNG
• プリエンプション --- 映像よりもサウンドのほうが長いため、2度目の映像事象にサウンドが鳴らない。例えばインベーダが非常に短い間隔で消滅した場合、2度目の消滅音が無視されてしまう。 図235.2 プリエンプションNG これらは一見矛盾するため、解決法を考える必要があります。状態ではなくエッジでサウンドを起動すれば解決できそうです。ただし、サウンド再生中に中断及び再実行可能にする必要があります。 図235.3 ワンショット 図235.4 プリエンプション さらに、ゲーム制御とサウンドのFSMでは動作周波数が30倍も異なり、ゲーム制御FSMからのサウンド指示間隔が短いと取りこぼす可能性があります。しかしながら、実験の結果取りこぼしを対策するためのサウンドキューよりも、リアルタイム性を優先したほうが良いことが分かりました。従って、当初FIFOジェネレータで作成したサウンドキューを廃止して1段のバッファとします。

前のブログ 次のブログ

スペースインベーダーのモジュールの入れ替え

過去にスペースインベーダーをRTLで開発しました。今回はBSVのトライアルとして既存のverilogモジュールの入れ替えを実施します。小さめのFSMであるサウンドFSMを入れ替えますが、合わせて仕様も高級なものにしようと思います。RTLで記述したときは、サウンドチャネルは1個で、優先度判定を行いサウンド割込みを行いました。今回は、サウンドチャネルを複数持って、サウンド重畳を行うことを考えます。そのため、複数の音を出し音量を平均化するような、サウンドミックス回路を新設します。

サウンドチャネルの決定

さて、音は以下の10種類ですが、同時発生を考えて、自機音、インベーダ音1, 2、UFO音の4チャネルとします。また、サウンド演奏中に割込みが入るため、プリエンプティブに設計する必要があります。

変更前後のブロック図

現状のRTL設計でのブロック図をVivadoで表示したものを図234.1に示します。

新仕様のブロック図は図234.2のようになります。色付けの部分が新規設計モジュールです。

前のブログ 次のブログ

前稿で設計したグラフィックディスプレイコントローラですが、あとから振り返るとFIFOが無駄であることに気づきました。早速リファクタリングします。

リファクタリング前のクロックドメインが3つあるのに比べて、リファクタリング後は2つに減っています。それだけでなく、FIFOとメモリをリードしてFIFOに入れる回路の2つを削減しています。これはdual port memoryが本来FIFOの役割を果たすためです。

FIFOとメモリ読み出し回路を削減し、メモリ読み出し回路から出ていたメモリアドレスをグラフィックコントローラから出す変更により、問題なくリファクタリングが達成できました。

前のブログ 次のブログ

FPGAの設計トライアルとしてスペースインベーダを取り上げたブログ記事を書いてきましたが、最初はAvnetのMicroZedボードで、PMOD-VGAとPMOD-I2Sのインタフェースを購入して、入力はボード上のスイッチを使用していました。

開発がほぼ完了した段階で、AvnetからUltra96 ボードが発売されたので、さっそく購入し移植しようとしましたが、Ultra96はPMODインタフェースを搭載していないため、インタフェースボードを設計せざるを得なくなりました。

そのため、Eagleを使用して、PCBを設計し、さらに格安でPCBを製造するベンダを探しました。中国から送られてきたボードに部品を実装し、ジョイスティックを作成し、ゲームを動作させることができました。

この経緯をQiitaに投稿しました。

合わせてYouTubeにも上げています。

前のブログ 次のブログ

組み立てたPCBをUltra96と組み合わせ動作確認を行います。4層だから電源、グラウンドノイズが抑えられるかと思いましたが、2層とあまり変わらず、400mVp-pくらいありました。やや大きい気がします。

2層と言えどもベタ電源、ベタグラウンドとしているので4層と変わらないのか、それとも3端子レギュレータのノイズがかなり強力で、バイパスしきれていないのか不明です。パスコンをかなり入れている割にはあまり効いていない感じがします。

3端子レギュレータの温度上昇が心配だったので、デジタル温度計を繋ぎ、数時間動作させてみました。39度までは上がらないようです。12Vから3.3Vに落としているのでドロップ電圧が大きく、ドロップ電圧×電流の電力を熱として消費するため熱暴走が心配でした。このレベルの消費電力であれば、ヒートシンクは不要のようです。

ところで、前回使用したFusion PCBは実装費用が(BokTechに比べたら)高額だったのですが、今回実装費用を約65 USDも値下げしてきました。比較してみると、この基板を製造費、実装費、部品費、配送料込みで、

と競合であるBokTechを下回る価格を打ち出してきました。従来はBokTechよりも約35 USD高かったのですが、BokTechよりも約30 USDも安くなっています。

そもそも実装費用がこれだけ安ければ、全てSMDにして実装を任せても良くなります。また、部品費用はそのほうが安いものが多いため、メリットがあるでしょう。手ハンダを前提としたスルーホール中心の考え方まで変える必要がありそうです。

追記:セールは2019.8.1で終了したとのこと、ただし、その後も時々セールを実施しているようです。

前のブログ 次のブログ

FusionPCBにオーダーしていたメインPCBが届きました。実装も依頼したので、基板だけよりは時間がかかります。受注から実装完成まで18.94日、DHLによる配送が0.95日でした。FusionPCBは若干高いようですが、DHLの配送料込みなので、他社と価格比較する際はトータルで見る必要があります。

コストを抑えるため、実装はSMD部品のみ依頼し、残りのスルーホール部品はマニュアルによるハンダ付けとしました。

部品を実装したボードをUltra96ボード、PMOD-VGAボード、PMOD-I2S(サウンド)ボード、PMOD-JOY-SWボードと組み合わせて、Space Invadersが正常に動作することを確認しました。

基板図の表、裏の両面を示します。

UltraZedボードでは電源ONでリセットがかかったのですが、プロトタイプボードを実装して電源を入れたところ、電源スイッチをONしなければならないことが分かりました。ところが、Ultra96ボードの電源スイッチがインタフェースボードで隠されて押しにくいことが分かったので、新たに電源スイッチとついでに敵の強さを設定するDIP SWを設けました。回路は他は基本的には変えていません。ソルダーレジスト色は黒にしてみました。

前のブログ 次のブログ

FusionPCBにオーダーしていた基板が届きました。以前の設計時のブログの続きです。

非常に小さい基板で、以下に基板の100円硬貨との比較写真を示します。基板業者は前回と同じFusionPCBで、今回はOSCという速達配送業者を利用して9.9USDでした。基板のみで製造に7.94日、OSCによる配送にシンセンから日本まで3.13日かかっています。シンガポール郵便よりはだいぶ早いですね。9.9USDの内訳は、7.9USDが基板制作代、2.0USDがOSCの配送料のようです。

前回はソルダーレジストを白で製造しましたが、今回は黒にしてみました。Ultra96toPMODボードもオーダーしています。レベル変換ICのみSMDだったので、手ハンダはマイクロスコープ下のハンダ付け作業となり厳しいため、レベル変換ICのみ実装もオーダーしました。

これに部品を実装したものを次の図に示します。

UltratoPMODボードに取り付けて正常に動作することを確認しました。

前のブログ 次のブログ

ゲームの完成

以前の記事で実装したインベーダゲームを、Ultra96及びUltra96toPMODインタフェースボードの組み合わせと、ジョイスティックで動作させることができました。絵も音も、UltraZedボードと全く同様に出ています。

動画のフルキーボードは全く使用していません。Ultra96に上記PMODインタフェースボードを接続し、それにPMOD-VGAボード、PMOD-I2Sボード、自作PMODジョイスティックSWボードを接続し、動画中のジョイスティック及びスイッチにより操作しています。

共通シーケンス

ゲーム自体はまだ改良の余地があり、共通ステートシーケンスをソフトで言うところのサブルーチン化する等のリファクタリングを実施中です。図86.2にその一例を示します。パターンROMからいろいろな形、例えばインベーダ、自機、ベース、UFO等をVRAMに矩形転送するシーケンスは、多用されますが、それぞれにシーケンサを用意していると大変なロジック量になります。これをサブルーチンのように、{ソースX座標、ソースY座標、横幅、縦幅、デスティネーションX座標、デスティネーションY座標}の6個を入力パラメータとして、シーケンスを呼びだすことでシーケンスの共通化が可能です。呼び出す前には戻り番地をリターンレジスタに退避してから呼び出します。呼び出し先で戻るときにはリターンレジスタをステートに代入して戻ります。

本来はプロセッサのソフトウェアで実行する、十分複雑なシーケンス制御をハードウェアで実装してみて判明したのは、まさにプロセッサの進化のリバース(逆行)だということです。FSMシーケンスを共用化する目的で、前述のようにリターンレジスタを実装しましたが、これはプロセッサのリンクレジスタと同じです。

水平マイクロ

現在マイクロプログラム処理をあまり見なくなったのは論理合成のためだと思います。論理合成が無い時代はハードウェア論理を変更するのは大変な作業で、それを簡単にするために、FSMではなくマイクロプログラム処理を考え、ROMの内容を書き換えることで、処理の変更を行ったわけです。今回のFSMシーケンス記述は、いわば、インベーダ処理プロセッサの超水平マイクロを書いているようなものです。ちなみに水平マイクロには、普通プロセッサレベルのISAには存在しない、マルチウェイ分岐等の強力な命令があります。

ESDAツール

最近ではSDSoCなりVivado-HLSなりが使えるので、Cで書こうかとも思いましたが、今回はVerilogで記述してみました。VerilogはCに対するアセンブラとも言われますが、コード量的にはそれほどの差はありません。20年ほど前にESDAツールがあったのですが、最近はどこへ行ってしまったのでしょうか。動作合成が進んだのでなくなったのかもしれません。同じアルゴリズムをCで書いてみると、ESDAが不要かどうかが分かると思います。

前のブログ 次のブログ