Posts Tagged with "FPGA"

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

サウンドFSM毎に固有のROMを持ちますが、ROMとアクセスアドレス、データの関係表です。各コードは3段のエントリとなっており、それぞれフォーマット格納アドレス、フォーマット長、データ格納アドレス、データ長、サウンド格納アドレス、サウンドデータの順となっています。

表499.1 ROMアクセス表
FSM No. コード アドレス データ
自機音
チャネル(#0)
1 0013, 0012, 0011, 0010 00,00,00,10
002b, 002a, 0029, 0028 00,00,10,b1
002c,002d,002e,002f,... 81,81,82,83,...
2 10f1,10f0,10ef,10ee 00,00,00,10
1109,1108,1107,1106 00,00,22,1b
110a,110b,110c,110d,... 7b,79,7b,79,...
9 3339,3338,3337,3336 00,00,15,4f
3351,3350,334f,334e 00,00,10,b1
3352,3353,3354,3355,... 7c,7c,7b,7c,...
インベーダ音
チャネル(#1)
3 0013, 0012, 0011, 0010 00,00,00,10
002b, 002a, 0029, 0028 00,00,11,e1
002c,002d,002e,002f,... 83,85,84,81,...
インベーダ音
チャネル(#2)
4 0013, 0012, 0011, 0010 00,00,00,10
002b, 002a, 0029, 0028 00,00,04,c5
002c,002d,002e,002f,... 76,77,74,74,...
5 0505,0504,0503,0502 00,00,00,10
051d,051c,051b,051a 00,00,05,f6
051e,051f,0520,0521,... 7a,78,78,77,...
6 0b27,0b26,0b25,0b24 00,00,00,10
0b3f,0b3e,0b3d,0b3c 00,00,05,f6
0b40,0b41,0b42,0b43,... 7a,7b,7a,7a,...
7 1149,1148,1147,1146 00,00,00,10
1161,1160,115f,115e 00,00,08,58
1162,1163,1164,1165,... 78,7a,77,78,...
UFO音
チャネル(#3)
8 0013, 0012, 0011, 0010 00,00,00,10
002b, 002a, 0029, 0028 00,00,65,43
002c,002d,002e,002f,... 7e,78,7b,7b,...
10 6583,6582,6581,6580 00,00,00,10
659b,659a,6599,6598 00,00,07,0a
659c,659d,659e,659f,... 99,86,7a,7a,...

バスアクセスのシミュレーションエラーが出たため、まとめておこうと思い上記の表を作成しましたが、エラーの原因はROMの内容が古かったためでした。


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

posted by sakurai on August 19, 2022 #498

テストケース

設計で最重要なのがテストケース作成です。バグの無い設計のためには、テストケースを網羅的に作成して検証する必要があります。

表498.1 テストケース進捗表
FSM No. テストケース Pass/Fail
No. 内容 V1 (State) V2 (Seq.)
自機音
チャネル(#0)
1 CODE1演奏中にCODE2がプリエンプト可能なこと Pass Pass
2 CODE1演奏中にCODE9がプリエンプト可能なこと Pass Pass
3 CODE9演奏中にCODE1がプリエンプト不可能なこと
(自機増加音が妨げられないこと)
Pass Pass
4 CODE3を無視すること Pass Pass
インベーダ音
チャネル(#1)
5 CODE3演奏中にCODE3がプリエンプト可能なこと
(実際には起こらないため不要)
Pass Pass
6 CODE1を無視すること Pass Pass
インベーダ音
チャネル(#2)
7 CODE4演奏中にCODE5がプリエンプト可能なこと Pass Pass
8 CODE5演奏中にCODE6がプリエンプト可能なこと Pass Pass
9 CODE1を無視すること Pass Pass
UFO音
チャネル(#3)
10 CODE10演奏中にCODE8がプリエンプト可能なこと Pass Pass
11 CODE10演奏後にCODE10OFFが来るまで演奏を継続すること Pass Pass
(12) (11で)CODE10演奏中にプチプチ音が鳴らないこと Pass Pass
13 CODE10演奏中にCODE8がプリエンプトし最後にOFFになること Pass Pass
14 CODE10演奏中にCODE8がプリエンプトしOFFがプリエンプト
した後OFFになること
Pass Pass
15 CODE1を無視すること Pass Pass

プログラムの対称性に鑑み、最小必要パターンのみとしました。パターンは必要に応じ、随時追加削除していきます。


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

posted by sakurai on August 18, 2022 #497

チャネルとコードの対応

表497.1 音データ、コードとサウンドチャネルの関係
サウンドの説明 CODE番号 サウンドチャネル
ON OFF
自機弾発射音 1 自機音チャネル(#0)
自機爆発音 2
自機増加音 9
インベーダ爆発音 3 インベーダ音チャネル(#1)
インベーダ歩行音1 4 インベーダ音チャネル(#2)
インベーダ歩行音2 5
インベーダ歩行音3 6
インベーダ歩行音4 7
UFO爆発音 8 UFO音チャネル(#3)
UFO飛行音 10 10+16

チャネル起動条件

それぞれのサウンドチャネルは別のFSMにより駆動されます。それらの起動条件を上げると、

  • チャネル0(FSM0) ---- (CODE1_ON || CODE2_ON || CODE9_ON) && !empty
  • チャネル1(FSM1) ---- CODE3_ON && !empty
  • チャネル2(FSM2) ---- (CODE4_ON || CODE5_ON || CODE6_ON || CODE7_ON) && !empty
  • チャネル3(FSM3) ---- ((CODE8_ON || CODE10_ON || CODE10_OFF) && !empty) || UFO
  • 例外処理: チャネル3においてはCODE10_ONの場合、OFFが来るまで演奏し続けるようにUFOのフラグを立てますが、起動時にUFOフラグだった場合はコマンドが無くてもCODE10_ONとして起動します。

チャネル終了条件

それぞれのサウンドチャネルは演奏を終了することがあります。カウンタが0になる場合またはプリエンプションです。具体的な終了条件(もしくは割り込み条件)を上げると、

  • カウンタが0になる (|| 以下のプリエンプション)
  • チャネル0(FSM0) ---- ((CODE1_ON || CODE2_ON || CODE9_ON) && !empty) && (current != CODE9_ON)
  • 例外処理: チャネル0(FSM0) ---- CODE9_ONの場合はプリエンプション禁止のため、currentを見てCODE9_ON(自機増加中)だったら割り込まないようにします。
  • チャネル1(FSM1) ---- CODE3_ON && !empty
  • チャネル2(FSM2) ---- (CODE4_ON || CODE5_ON || CODE6_ON || CODE7_ON) && !empty
  • チャネル3(FSM3) ---- (CODE8_ON || CODE10_ON || CODE10_OFF) && !empty
  • 全チャネル(FSM0~3) --- コードがある場合はキューから取り出し先頭に戻ります。

このように、起動条件の例外はUFOフラグが立っている場合であり、終了(割り込み)条件の例外は自機が増加中に割り込まない場合です。


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

posted by sakurai on August 17, 2022 #496

設計方針

前回のBSVによるサウンドFSMの設計においては、ステートベース設計手法により設計しました。ステートベース設計とは、ここでは一連のフローを、クロックサイクルで定義されるステートに分解し、ステートのルールを一つずつ書いていく手法を指します。ただ、Verilogでも同じ手法で設計するため工数は同じであり、高級言語のご利益はありません。

前回の設計では、以前にVerilogでステートベースで設計した経験があるので、階層化ルールを用いて階層化FSMをステートベース設計しました。今回は比較のため、シーケンスベースで設計しようと思います。シーケンスベース設計とは、ここではシナリオを人手でステートに分解せずに、BSVに任せることを指します。

使用コンパイラ

ところが、2021年末にアップグレードのため、bscを再コンパイルしたところ(build 9a7d5e05)、Verilog出力が正しくできなくなりました。具体的にはスタックオーバーフローというエラーが出ます。フォーラムで聞いたところソースを送って欲しいとのことでした。

ソースを送って調べてもらいましたが、スタックを広げるコマンドを実行してもエラーが出るらしく、ソースを改善せよとのことです。ソースは巨大なFSMから構成されるため、FSMを分離したいのはやまやまなのですが、教えられた通り実施しても、bscが一個のFSMにまとめようとするためうまく行きませんでした。やむなく、以前のコンパイラ(build 38534dc)を使い続けることにします。

処理フロー

図54.2は以前の記事に示したもので、FSMはこれをデコードし、音声を出力するものです。

図54.2
図54.2 waveフォーマット例

従って、基本的なフローはこのフォーマットどおりのステートベース設計のものを踏襲します。

  • コード待ち ---- FSM0~3に応じたコードを受け付ける)
  • 例外フラグ ---- UFOの場合はONからOFFまでサウンドをならし続ける等の例外への対処
  • コードに応じてROMの先頭+16にポインタを移す
  • フォーマットサイズを取得し、ポインタをフォーマット長分だけ増加
  • "data"をスキップ
  • データサイズを取得しカウンタにセット
  • ポインタをデータの先頭に移す
  • 終了条件でなければループ
  •  音声データを取り出す
  •  データを出力
  •  ポインタを進める
  •  カウンタを1減らす
  • ループ終端

ここで前回は、上記ループ内部において、インターポレーションのため4クロックからなるサウンド出力を4回繰り返していました。が、出力はループ内では変わらないので、16サイクルに1回出力すれば良いことになります。よって上記のループは16サイクルになるように設計します。


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

posted by sakurai on August 12, 2022 #495

製造(PCBA)費用が安いため、JLCPCBにUltra96toPMODボードを再オーダーしました。グリーン基板はなぜかセットアップやステンシル費用がパープル基板より安いのですが、パープル基板でも他社よりも安いのに加え、今回はクーポン10 USDの割引が使用できるため、今回はパープル基板で製造しました。組み立てもかなり安かったため、今回はレベル変換ICのみ実装したPCBを製造しました。

図%%.1
図495.1 Ultra96toPMODV10 (表)

図%%.2
図495.2 Ultra96toPMODV10 (裏)

パープル基板とグリーン基板を製造し、さらにICを2個/枚×10枚実装した場合の費用の内訳を示します。グリーン基板のほうが半額近い費用です。

表495.1 Ultra96toPMOD Jlcpcbの費用構成
10枚製造時費用内訳 基板色[USD]
パープル グリーン
PCB Price 5.00
Components(TXS0108EPWR --- 20個) 12.05
Extended Components 0.00 2.93
SMT Assembly 0.68
Setup fee 25.00 8.00
Stencil 8.46 1.50
Feeders Loading 1.35 0.00
合計 53.05 30.16
送料(格安:7~12日) 7.68
合計 60.22 37.84
割引 ▲10.00
総計 50.22 27.84

価格表に示すとおり、パープル基板はグリーン基板よりも倍近く高いものの、SMD部品を2個ずつ実装してもらっても1枚5ドル程度でした。


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

posted by sakurai on February 1, 2022 #450

だいぶ前の記事ですが、テストベンチのBSVと、モジュールのBSVからVerilogを生成し、Verilogシミュレーションを実施しました。BSVではテストベンチにおいてクロックとリセットが自動生成され、暗黙的にモジュールに供給されます。一方、Verilogでは明示的にテストベンチにクロックとリセットを供給する必要があります。前の記事では、テストベンチ内にその処理を行う記述をインクルードする方法を用いました。

ここでは、最上位からそれらの信号を供給する手法をとります。これにより、よりスマートにVerilogシミュレーションが実行できます。まず、原始最上位ファイルを用意します。最上位からはテストベンチを呼び出しています。

最上位ファイル:mkTop.v

module mkTop () ;
   /*AUTOREGINPUT*/
   mkTb Tb_inst(/*AUTOINST*/);
  initial begin
    RST_N = 1'b0;
    #30;
    RST_N = 1'b1;
  end
  initial begin
    CLK = 1'b0;
    forever begin
       #5 CLK = ~CLK;
    end
  end
endmodule // mkTop  

これに対して、Verilog-modeのオートコネクションコマンドであるC-c C-aを用いてポートの追加を行えば、

最上位ファイル:mkTop.v

module mkTop () ;
   /*AUTOREGINPUT*/
   // Beginning of automatic reg inputs (for undeclared instantiated-module inputs)                
   reg                  CLK;                    // To Tb_inst of mkTb.v                            
   reg                  RST_N;                  // To Tb_inst of mkTb.v                            
   // End of automatics                                                                            
   mkTb Tb_inst(/*AUTOINST*/
                // Inputs                                                                          
                .CLK                    (CLK),
                .RST_N                  (RST_N));
  initial begin
    RST_N = 1'b0;
    #30;
    RST_N = 1'b1;
  end
  initial begin
    CLK = 1'b0;
    forever begin
       #5 CLK = ~CLK;
    end
  end
endmodule // mkTop              

のように、テストベンチに対してクロックとリセットが接続されます。

最上位、テストベンチ、モジュールを結合した実行ファイルを生成します。エラーが出ることもなく実行ファイルが生成され、実行ファイルによりVerilogシミュレーションを実行すれば、

\$ iverilog mkTop.v mkTb.v mkFibOne.v -o mkFibOne.exev
\$ ./mkFibOne.exev
1
1
2
3
5
8
13
21
34
55
89
144
233
377
610
987
1597
2584
4181
6765
10946

このように、正しくVerilogシミュレーションが行われ、前記事と同じ結果となります。

結論としては、この記事のように自動結合を使用すれば、前記事のようにincludeを埋め込む必要はありませんでした。


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

デザインのボード間移植

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)として参照できるようにしました。


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

敵弾の貫通度の修正 (3)

posted by sakurai on June 17, 2021 #423

実行結果

このように修正した結果、以下の図423.1に示すように、敵弾の種類により貫通度を変えることができました。

図%%.1
図423.1 貫通度の違い

図423.1の下部中央のバリケードの

  • 右側に当たったのは、"Rolling"ショットで貫通度=3
  • 左側に当たったのは、"Plunger"ショットで貫通度=7

と深さが異なります。

以下の図はFPGAボードの動画です。最初に右側にRollingショット、次に左側にPlungerショットが着弾しています。

図%%.2
図423.2 貫通度の違い(動画)

以下の図は前記事のオリジナル動画です。最初に左側にPlungerショット、次に右側にRollingショットが着弾しています。

図%%.3
図423.3 貫通度の違い(オリジナル動画)

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

敵弾の貫通度の修正 (2)

posted by sakurai on June 16, 2021 #422

敵弾種類

敵弾名はインベーダゲームソースの研究から引用しています。図422.1の左から、Squiggly (抵抗器のようなジグザグ)、Rolling、Plunger (パイプつまり直し)と名前がついています。

図%%.1
図422.1 敵弾の種類

図422.2において、敵弾の貫通度は左からそれぞれ3, 3, 7としています。

BSVコードの修正

元々敵弾をランダム(風)に出現させるため、カウンタの値により敵弾タイプを決めていますが、同じように貫通度を決めるテーブルです。

UInt#(3) invBullet_pdval[8] =   { 7,  3, 3,  7, 3,  3,  7, 3}; // pd = penetrating depth

次は貫通度を記憶するためのレジスタであり、敵弾数だけ持つ必要があります。

Reg#(UInt#(3)) invBullet_pd[`INV_BULLET_MAX];

このレジスタを各敵弾にひとつ持たせるために敵弾の同時最大数だけインスタンシエートします。

for (int ii = 0; ii < `INV_BULLET_MAX; ii = ii + 1) begin
 :
   invBullet_pd[ii] <- mkRegU;
 :
end

敵弾発生部において、タイプを決定するのと同じロジックにより、上記の表を引きます。

            invBullet_type[idx] <= invBullet_rand[truncate(counter) & 3'h7];
            invBullet_pd[idx] <= invBullet_pdval[truncate(counter) & 3'h7];

敵弾衝突の一部です。この2つのseq - endseqブロックは元は一つでしたが、base(バリケード)の時だけこの貫通度を使用するように分離します。他の場合は最深(貫通度=7)固定とします。

                endseq else if (fbase) seq
                    eraseInvBullet(invBullet_x[idx], invBullet_y[idx]);     // 現敵弾消去
                    explodeInvBullet(invBullet_x[idx], invBullet_y[idx], invBullet_pd[idx]);   // 次敵弾爆発
                    invBullet_expTimer[idx] <= 1;           // 敵弾爆発タイマスタート
                    voff <= 5; // break 'for'
                 endseq else if (fobj || invBullet_y[idx] >= 225) seq
                    eraseInvBullet(invBullet_x[idx], invBullet_y[idx]);     // 現敵弾消去
                    invBullet_pd[idx] <= 7; // 最深
                    explodeInvBullet(invBullet_x[idx], invBullet_y[idx], 7);   // 次敵弾爆発
                    invBullet_expTimer[idx] <= 1;           // 敵弾爆発タイマスタート
                    voff <= 5; // break 'for'

コール先の爆発ルーチンです。爆発は、爆発マークを表示することで開始します。

// 敵弾爆発
function Stmt explodeInvBullet(
              UInt#(8) destx,
              UInt#(8) desty,
              UInt#(3) pd);
   return (seq
      orArea(43, 16, destx - 3, desty + extend(pd), 8, 8);
   endseq);
endfunction

爆発マーク消去コール部分です。爆発開始から一定時間後に、保存してある貫通度を使用して爆発マークを消去します。

           expEraseInvBullet(invBullet_x[idx], invBullet_y[idx], invBullet_pd[idx]);        // 敵弾爆発マーク消去

コール先の爆発マーク消去ルーチンです。

// 敵弾爆発マーク消去
function Stmt expEraseInvBullet(
              UInt#(8) destx,
              UInt#(8) desty,
              UInt#(3) pd);
   return (seq
      eraseAreaSP(43, 16, destx - 3, desty + extend(pd), 8, 8);
   endseq);
endfunction

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

敵弾の貫通度の修正

posted by sakurai on June 15, 2021 #420

Youtubeの動画の分析

この動画を観察すると、バリケード(シールド)への貫通度が、敵弾の種類によって異なるように思われます。

下図は左端のインベーダからT字型(Plunger)の敵弾が発射されたところです。

図%%.1
図420.1 敵弾1

敵弾が左端のバリケードに着弾しました。深く潜って(貫通度=7)爆発しています。

図%%.2
図420.2 敵弾1爆発

同じく左端のインベーダからジグザグ型(Squiggly)の敵弾が発射されたところです。

図%%.3
図420.3 敵弾2

敵弾が左端のバリケードに着弾しました。浅く潜って(貫通度=3)爆発しています。明らかに敵弾の種類により貫通度が異なっています。

図%%.4
図420.4 敵弾2爆発

動画を観察した限りでは、T字型の敵弾が7、他の敵弾は貫通度=3で爆発するようでした。一方、最下端では7で爆発するようなので、バリケードで爆発する際にのみ、貫通度(penetration distance)を設定することにします。


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


ページ: