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

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

サウンドチャネルの決定

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

変更前後のブロック図

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

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

前のブログ 次のブログ

ルール

大変便利なemacs verilog modeですが、最上位でうまく行かなかったので調査したところ、以下のようなことが分かりました。

中間階層で、下位モジュールインタフェースをパススルーして上位に上げる場合のルールは、

• /*AUTOINPUT*/及び/*AUTOOUTPUT*/

最上位(テストベンチのように)で、信号がその階層内で留まる場合のルールは、

• /*AUTOREGINPUT*/及び/*AUTOWIRE*/

と記述します。

ちなみに、 /*AUTOINPUT*/と/*AUTOREGINPUT*/が同時に存在する場合は /*AUTOINPUT*/が勝ち、/*AUTOOUTPUT*/と/*AUTOWIRE*/が同時に存在する場合は、/*AUTOWIRE*/が勝つようです。

実施結果

まず中間階層に相当する、原始のverilog fileを示します。下位モジュールの信号を上位に上げる場合なので、/*AUTOINPUT*/及び/*AUTOOUTPUT*/と記述し、さらにインターフェース部分には/*AUTOARG*/と記述します。

これに対してC-c C-aを実行すると、以下のように補完されます。

次にテストベンチ相当の、原始のverilog fileを示します。下位モジュールからの信号はこの階層内で留まるため、/*AUTOREGINPUT*/及び/*AUTOWIRE*/と記述します。

これに対してC-c C-aを実行すると、以下のように補完されます。

前のブログ 次のブログ

6809 IPは、Verilogステートマシン設計されているため、Vivadoのロジックシミュレータでステート毎に値をチェックして行きました。飛び先である\$FF12を用意されているものの、PCに書き込まれていないことが判りました。とは言え、JMP命令は正しくデコードされ、内部信号のop_JMP(JMP命令であることを示すデコード信号)は正しく出力されています。

ステート遷移を修正し、レジスタ書き込みで終わっている箇所をジャンプステートに修正し、さらに、PCへの書き込みアサートを追加しました。

ステートの遷移は、修正前が、0f,16, 17, 18, 19, 11, 12, (09=次の命令フェッチ)のようになっているのに対して、修正後は0f, 16, 17, 18, 19, 1b, (09=次の命令フェッチ)のように遷移し、かつ、オレンジ色で示したk_write_pc信号がアサートされ、new_pcである\$FF12\$FF12がPCにセットされています。結果として正しく\$FF12にジャンプしています。

修正前は誤ってステートが、\$11(SEQ_GRAL_ALU), \$12(SEQ_GRAL_WBACK)と、レジスタ書き込みのステート遷移となっているのに対して、修正後は\$1b(SEQ_JMP_LOAD_PC)と、JMP命令のステートに遷移しています。

例えばメインフレームのような大型機をどのようにテストしているかと言えば、もちろん単体命令をひとつづつテストすることも行いますが、キャッシュ、仮想記憶、ページングの記憶階層があります。そのためのタイミングによるバグの可能性があるので、ランダム試験を実施します。命令を乱数で発生し、ただし不正命令とはならないように制約をかけ、ソフトシミュレータで正解値を取得します。これを論理シミュレータにかけ、結果値であるレジスタの値やメモリの値が正しいかをチェックします。メモリの値はひとつずつチェックすることなく、領域のチェックサムを取ることで確認します。

さらにこれを発展させ、実機にランダムプログラム生成プログラムを載せて、実行時に正解値を生成しチェックします。一見バグ値どうしを比較してOKとなりそうですが、いろいろと条件を変え、命令をページクロスさせて前半と後半でキャッシュやページのヒットミスを変えることで、演算値が変わることがあり得ます。これはプロセッサがパイプライン動作していることから、バグによってはタイミングによって結果が変わることがありうるためです。

ということで、メインフレーム並みの信頼性を保証するなら、上記のようなテストを実施しなければなりません。

前のブログ 次のブログ

FM=7のハードウェアエミュレーションをFPGAで実行するプロジェクトを遂行していましたが、FM-7のROMイメージもZ80カードI/Fを用いることにより、すんなり抜き出すことができました。

それをVivadoに持ち込むにあたって、COEファイルという形式に変換し、OpenCoresからダウンロードした6809を動かしたのですが、動作しないようです。実機の動作と比較するために、実機にはロジックアナライザを接続しました。

前記事のArduino-Z80I/FカードにはFM-7の内部バスが現れているので、実はArduinoは動かさなくても、ロジックアナライザを接続すれば、メインCPUである6809の動作が把握できます。ロジックアナライザも昔は数百万円したかと思いますが、私の購入したものは17,000円くらいでした。これで32CH 200K 400MSa/sですから、アドレス、データ、主要制御信号を観測するのに十分です。

●Arduinoマイコンが870円(送料別) https://www.banggood.com/RobotDyn-Mega-2560-PRO-Embed-CH340G-ATmega2560-16AU-Development-Module-Board-With-Pin-Headers-For-Arduino-p-1397734.html

●ボード作成が5枚で4.9 USD https://www.fusionpcb.jp/

●コネクタは少々高くて743円(送料別) https://jp.rs-online.com/web/p/pcb-headers/6020498/

●ロジックアナライザは消耗品ではないので高いですが、それでも17,299円 https://www.banggood.com/Hantek-4032L-Logic-Analyzer-32Channels-USB-Oscilloscope-Handheld-2G-Memory-Depth-Osciloscopio-Portat-p-1376105.html

のように比較的気軽に試すことができます。

さて、このような環境でFPGAのシミュレーションを実行したら、おかしな点を見つけました。具体的にはJMP命令が動作しません。著者に連絡を取り、報告したところ、「It doesn't surprise me that a couple (or more) things do not work.」とのことで、自分でなんとかするしかなさそうです。FM-7システムの中で6809をデバッグするのは大変なので、新たに図のような単体テスト環境を作成しました。

6809 CPUに、リセット、クロック、ROMを接続しただけです。RAMはありません。このROMに以下のようなテストプログラムを置き、実行させたところ、

FF00　　　　　　　　　start　 org　　 \$ff00
　　　　　　　　　　　
FF00　8EFF12　　　　　　　　　ldx　　 #lab1
　　　　　　　　　　　;　　　 jmp　　 0,x
FF03　6E00　　　　　　　　　　fcb　　 \$6e,\$00
　　　　　　　　　　　
FF05　8EFF15　　　　　lab2　　ldx　　 #lab3
FF08　6E01　　　　　　　　　　jmp　　 1,x
　　　　　　　　　　　　　　　
FF0A　8EFF12　　　　　lab4　　ldx　　 #lab1
FF0D　6E84　　　　　　　　　　jmp　　 ,x
FF0F　7EFF0F　　　　　　　　　jmp *
　　　　　　　　　　　　　　　
FF12　7EFF05　　　　　lab1　　jmp　　 lab2
FF15　12　　　　　　　lab3　　nop
FF16　7EFF0A　　　　　　　　　jmp　　 lab4
　　　　　　　　　　　
FFFE　　　　　　　　　　　　　org　　 \$fffe
FFFE　FF00　　　　　　　　　　fdb　　 start
　　　　　　　　　　　;
0000　　　　　　　　　　　　　end

最初の\$FF03番地のJMPを、JMPせずに実行してしまいます。JMP命令でもインデックスアドレシングのみ動作しないようです。ちなみに、JMP ,XとJMP 0,Xは動作は同じですが、オペコードは異なります(\$6E,\$00と\$6E,\$84)。が、動作が同じであるため、JMP ,Xと書いてもJMP 0,Xのオペコードがアセンブラから出力されるため、やむなく上記のようにFCBで記述しました。

前のブログ 次のブログ

IRQ/FIRQが正常動作したので、メインCPUとサブCPUの協調動作を実行してみます。

1. メインCPU

   • サブCPUのreadyを待つ
   • サブCPUをhaltする
   • 共有メモリにデータを書き込む
   • 共有メモリの先頭のMSB=0で指示とする
   • サブCPUのhaltを解除する

2. サブCPU

   • リセット後サブCPUの状態はハード的にbusy
   • サブCPUの状態をreadyにする
   • 共有メモリの先頭のMSB==0となるのを待つ
   • サブCPUの状態をbusyにする
   • 共有メモリの内容をデコードする

このフローに基づき、協調動作のシミュレーションを行ったところ、正しく動作しました。

前のブログ 次のブログ

タイムチャートを見直すと、例外処理中でEフラグをクリアする処理は入っていますが、一方のセット信号が初期状態からずっと不定です。このため、Eフラグが不定となっているようです。従って、セット信号を初期状態でネゲートします。

k_set_eの初期化をしたところ、正しく動作しました。このIPは総じて割込みの実装が中途半端にしかされておらず、割込みは実質テストしていないようです。プロセッサにおいて割込みが動作しないのは致命的であり、使い物になりません。

前のブログ 次のブログ

次にFIRQを実装します。同様にFフラグセット、クリア論理を入れましたが、割込みハンドラまでは正しく動作するものの、RTI命令の実行時にスタックを過剰に回復しています。積んだ以上に回復するという、いわゆるスタックアンダーフローを起こしてしまいます。

まず、FIRQの動作を見てみると図153.2のようになります。Eフラグをクリアしてからpushすると書かれていますが、クリアされずXとなっています。

次に、RTIの動作を見てみると図153.2のようになります。Eフラグは0であるべきなので、スタックからはCCR及びPCのみが回復されるはずです。が、タイムチャートではさらに他のレジスタも回復しているようです。

この誤動作の原因は、CCR[7]のEフラグが不定となっていることです。従って、図153.2にあるとおり、例外処理中でEフラグをクリアする処理を入れれば動作するはずです。

前のブログ 次のブログ

割込み禁止のCCRへの反映を遅延させるタイミングを作り出しました。全レジスタの退避が終わった後のベクタフェッチは前々稿によれば、SEQ_MEM_READ_Hステートですが、そのタイミングでレジスタにCCR書き込みを指示することを考えます。このステートにはexceptionでない場合というif文がありますが、注目する場合はexception中なので、ちょうどelseの部分に以下の文を記述します。

if (k_set_i) begin
k_set_i_timing <= 1;
k_set_i <= 0;
end

k_set_i_timingとして、k_set_iを遅延させたCCR反映タイミング信号を作り出し、これをレジスタに与えます。なお、このk_set_iはSEQ_IRQステートに入った時点でセットし、一方、RTI命令でk_clear_iをセットします。

これにより正しく割込みが入り、割り込みが禁止されたかと思ったのですが、RTIから戻るところで再度割込みが入る現象が起きました。解析すると、割込みハンドラで割込み原因をクリアしたにも関わらず、CPU内部で割込みをまだ保持していることが原因と判りました。そのため、RTI実行により割り込み許可された途端にまた割り込み処理に移行してしまいます。そこで以下のように、割込み要因を無視するタイミングゲート処理を入れたところ、正しく動作するようになりました。

(修正前)
if (!k_reg_irq[2])
k_reg_irq <= { k_reg_irq[1:0], (!cpu_irq_n)};
　

(修正後) if (!k_reg_irq[2])
k_reg_irq <= { k_reg_irq[1:0], (!cpu_irq_n & !k_set_i & !k_set_i_timing)};

このタイマ割込みによるハンドラの実行と復帰は、タイマの周期で正しく繰り返されます。割り込みハンドラでは正しく割り込みが禁止され、RTIにより割り込み許可として元のプログラムに戻ります。元のプログラムではタイマ割り込み待ち状態となり、タイマ割り込みが入ると再びスタックへのレジスタ退避やベクタフェッチ等の割り込み処理を行います。

前のブログ 次のブログ

そこで、CCRを参照して割込みに入る入らないを決定させようとしたら、ソースコードで以下のような定義文を見つけました。

// flags used in MC6809_cpu.v
`define FLAGI regs_o_CCR[5]
`define FLAGF regs_o_CCR[6]
`define FLAGE regs_o_CCR[7]

前稿の図150.1のCCR構成を見てもわかるように、FLAGIのビット位置が誤っています。Iフラグの位置はbit5ではなくbit4です。これを正しいbit位置の4に修正したところ、ベクタフェッチの後に再度IRQステート遷移する動作は無くなり、フェッチしたアドレスに飛び、飛び先である割込みルーチンを実行するようになりました。

ところが、不具合がありました。割込みルーチンで割込み原因クリアをしているにも関わらず、再度の割込みが入りません。

前稿では、図151.1のタイムチャートに示すように、Eフラグと同タイミングで仮にIフラグもセットするように修正しました。ところが、スタックにCCRを退避する前にIフラグを割込み禁止にしたため、割り込み禁止状態のCCRが退避され、割り込みルーチンの最後で回復されたものです。つまりIフラグのセットが早すぎたわけです。

正しくは、図151.2の6809割込みにあるように、IフラグはCCRを退避してからセットしなければなりません。安直にEフラグと同タイミングでセットしたため、割込みが再度かからなくなってしまったものです。

前のブログ 次のブログ

調査の結果、割込み後のIRQマスクをCCRに全く反映していませんでした。ちなみに、CCRの仕様は6809マイコン・システム設計作法によれば、以下の図のようになっています。

これだと動作が分からないのですが、その次に以下のような説明があります。

ついでにEフラグの説明も載せておきます。

Verilogソースコードを見ると、CCRのうち、Iフラグは全く設定されていないようですが、EフラグはIRQ割込みの際にセットされていたので、とりあえず、Eフラグを立てるタイミングでIフラグにコピーしました。本来は割込みの種類によりIフラグとFフラグのセット仕分けをしなければなりません。

ところが、タイムチャートのようにIフラグをセットしたので、これで正常動作するかと思ったのですが、動作は変わりません。Iフラグは参照もされていないようです。つまり、このIPの割込みは全く動作しないということができます。

前のブログ 次のブログ