Posts Tagged with "Design"

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

プチ音の再修正

ゲームFSMからのコマンドにより、サウンドはサウンドFSMで演奏されます。サウンドとサウンドの間は、サウンドが鳴り続けないように、一旦OFFにします。

シミュレーション波形を観測している際に、UFO飛行音は連続して再生されるので、一旦サウンドをOFFにするとプチ音がするのではないかと思い、ONを継続するように変更したところ、却ってプチ音がするようになりました。

確かにステートベース設計の旧版では一旦サウンドをOFFにしていたため、そのように戻したところ、プチ音は聞こえなくなりました。

図%%.1
図500.1 再修正後

修正前はson=False、dout=NULLのためにプチ音が鳴っていると思い、son=True, dout=前データを継続としましたが、却ってプチ音が鳴るようです。波形は再修正後です。

サウンドFSMのアルゴリズム

フラグのON/OFFアルゴリズムを表500.1にまとめました。

表500.1 UFOサウンドアルゴリズム表
No. コード キュー ハンドシェーク(ren) サウンド間 フォーマット&演奏
1 UFO爆発, UFO飛行音 !empty ren <= True son <= False Play
2 UFO飛行音 OFF !empty ren <= True son <= False -
3 UFOフラグ - ren <= False son <= False UFO飛行音Play
4 他FSMコード !empty ren <= False son <= False -

上記でプチ音対策で修正した箇所は表500.1の緑色表示の部分です。一旦son <= TrueとONを継続するように修正しましたが、OFFに戻しました。

図%%.2
図500.2 FSM間ハンドシェーク

まず、通常のサウンドNo.1及び3は以下のフローとなります。

  1. GameFSMはempty == Trueの場合にコードを出力し、同時にOneStageFSMに対してwr_enを発行します。
  2. OneStageFSMはempty = False(=Full)とします。
  3. SoundFSMは正当コードかつempty == False (=Full)を待ち、入力されたらrd_en = TrueをOneStageFSMに返します。
  4. OneStageFSMはempty = Trueとします。
  5. GameFSMはempty == Trueを待ち、入力されたら終了です。
  6. SoundFSMもempty == Trueを待ち、入力されたらrd_en = Falseとします。
  7. SoundFSMはUFOオフコマンドならUFOフラグをOFFして終了します。
  8. SoundFSMはUFOオフコマンドでなければフォーマットをデコードします。
  9. SoundFSMはサウンドをカウント分演奏します。

次に、通常のサウンドで無い場合No.2は、UFOフラグがTrueの時であり、GameFSMのコードがキューに無くてもUFO飛行音を演奏し続けます。

  1. GameFSMはなにもしません。
  2. SoundFSMはUFOフラグ==Trueの場合には、実行しますがrd_en = Trueは返しません。
  3. SoundFSMは内部的にはUFO飛行音と扱います。
  4. SoundFSMはフォーマットをデコードします。
  5. SoundFSMはサウンドをカウント分演奏します。

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

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ドル程度でした。


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

Pipeline processorの設計(19)

posted by sakurai on March 1, 2022 #469

パイプライン制御の一般化

前項までの議論を一般化すれば、ステージSにおいての前段へのウエイト信号$\mathrm{W_{S-}}$と後段への有効信号$\mathrm{V_{S+}}$は

$$ \begin{eqnarray} \mathrm{W_{S-}}&=&\mathrm{W_S }\cup\mathrm{W_{S+}}\\ \mathrm{V_{S+}}&=&N(\mathrm{!W_S }\cup\mathrm{W_{S+}})\ \cap\ !\mathrm{C_{S+}} \end{eqnarray} \tag{469.1} $$ ただし、 $$ \mathrm{W_{S+}}: 下位ステージS+からSへのウエイト信号\\ \mathrm{C_{S+}}: 下位ステージにおけるキャンセル信号\\ N(): 時相論理、次のクロックサイクルの値 $$ とする。

何事も分かってしまえば簡単なのですが、パイプライン制御の秘密は、この論理469.1にあります。


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

posted by sakurai on February 28, 2022 #468

パイプライン制御の無効化論理

図%%.1
図468.1 CV32E40Pパイプライン図(再掲)

一方、後段にバブルを流すinvalidate信号は、EXWBレジスタのC(lear)信号ですが、やや冗長になっています。EXWB.C信号に(467.1)を代入し、ドモルガンの定理を用いて整理すれば、 $$ \require{cancel} \begin{eqnarray} \text{EXWB.C}&=&\text{wb_ready }\cap\text{!ex_valid}\\ &=&\text{wb_ready }\cap\text{(!granted }\cup\text{!wb_ready)}\\ &=&\text{(wb_ready }\cap\text{!granted) }\cup\bcancel{\text{(wb_ready }\cap\text{!wb_ready)}}\\ &=&\text{wb_ready }\cap\text{!granted} \end{eqnarray} \tag{468.1} $$ 使用ゲートは同じで、配線を繋ぎ変えるだけで1段論理になるので、2段通すのは若干無駄な論理のように見えます。論理合成を用いれば上記のように最適化されるでしょうけど。

図468.2に修正後の回路を示します。

図%%.2
図468.2 論理修正後パイプライン制御論理

前稿等で検討したように、パイプラインバブルは後段へ流すものですから、当該ステージ、この場合は<EX>にウエイト要因があり($=\text{!granted}$)、かつ後段である<WB>からウエイトが来ていない($=\text{wb_ready}$)ときに限り、後段を無効化する論理となり、(468.1)は正しいです。そして、この無効化信号は、パイプラインストリームのキャンセルにも用いられます。

パイプライン制御の有効論理

EXWB.Cの反転論理である<EX>有効信号を新たに$ex\_valid$とすれば、 $$ \require{cancel} \begin{eqnarray} ex\_valid&=&\text{!wb_ready }\cup\text{granted }\\ &=&wb\_wait\text{ }\cup\text{ }!exs\_wait \end{eqnarray} \tag{468.2} $$ となります。


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

posted by sakurai on February 25, 2022 #467

既存RISC-Vの研究

このページでパイプライン制御の図を見つけたので、以下に示します。これは4ステージのインオーダーパイプラインプロセッサです。

図%%.1
図467.1 CV32E40Pパイプライン図

パイプライン制御の論理を追ってみます。EXWBは<EX>と<WB>を分離するレジスタです。通常は<EX>の結果を保持するのでEXパイプラインレジスタと呼びますが、もちろん<WB>の入力でもあるため、この設計ではそれをわかりやすいようにEXWBとしているようです。

パイプライン制御のイネーブル論理

まずイネーブル論理を見てみると、 $$ \begin{eqnarray} \text{EXWB.E}&=&\text{ex_valid}\\ &=&\text{ex_ready}\\ &=&\text{granted }\cap\text{wb_ready} \end{eqnarray} \tag{467.1} $$ これは

  • <EX>が正当であるという、後段に対する有効論理、かつ
  • <EX>以降のステージが受け入れ可能という、上段に対するイネーブル(ウエイトの否定)

を同時に意味します。

上段に対するウエイト信号を新たに$ex\_wait(=\text{!ex_ready})$とし、<EX>の許可信号である$\text{granted}$の逆論理を、<EX>のステージウエイトとして新たに$exs\_wait(=\text{!granted})$と名付ければ、

$$ \begin{eqnarray} ex\_wait&=&\text{!ex_ready}\\ &=&\text{!(granted }\cap\text{wb_ready)}\\ &=&\text{!granted }\cup\text{!wb_ready}\\ &=&exs\_wait \cup wb\_wait \end{eqnarray} \tag{467.2} $$ ただし、$wb\_wait=!\text{wb_ready}$

前述のように、ウエイトは、当該段のウエイトに下段のウェイト信号のORを取りながら、上段へパイプラインとは逆向きに同一サイクル中に送るので、これは正しいです。


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

posted by sakurai on February 24, 2022 #466

EIT処理

EIT処理は

  • <MA>においてEITの優先度判定し、最弱のEITを識別
  • EITスタックにEITの分岐先(EITハンドラ先頭アドレス)をストア
  • EIT原因を無効化

以上を繰り返し、最後のひとつに対してはスタックに格納せずにEIT種別による分岐先をPCに格納します。

これはメモリアドレス計算やメモリアクセスを伴うので<ID>のFSMにより実行します。後続の命令はキャンセルされます。以下に具体例を示します。

  • 1の命令の<MA>でそのパイプラインストリームで集められたEIT要因を判定します。前後のストリームは見ません。
  • 後続命令ストリームをキャンセルします。具体的には2, 3, 4, 5までがパイプラインに入っているので全てキャンセルします。
  • <MA>から<ID1>に乗り換えることから、<ID>より前の<IF>と<PC>を持つ、後続の4, 5の命令はキャンセルされるだけでなく、ウエイトされます。
  • <ID1>のFSMが起動され、弱いEIT先行してEIT分岐先をスタックに格納します。この場合はE1が最弱でありスタックに格納すると同時にEIT要因を無効化します。同時にSPを+4します。
  • 次に<ID2>のFSMが起動され、同様にEIT分岐先をスタックに格納します。SPは前パイプライン<EX>からバイパスします。同時にEIT要因を無効化し、SPを+4します。
  • 最後に<ID3>のFSMが起動され、残った最強のEIT分岐先を<EX>で計算します。
  • そのサイクルは分岐先の<PC>と同一であり、6のEITハンドラが起動されます。

図%%.1
図466.1 パイプラインハザード

図%%.2
図466.2 パイプラインハザード


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


ページ: