Arduino自身によるリフレッシュ

DRAMリフレッシュ手法を再考しました。PICでの割込みもArduinoでの割込みも、性能は別として論理的には同じように動作するはずです。そこで、PICで実装する前に、試行としてArduinoに割込みを入れてリフレッシュする方法を検討します。DRAMのリフレッシュタイミング制約によれば16.5 usecに1回リフレッシュパルスを入れる必要があります。Arduino 日本語リファレンスを探したのですが、マイクロ秒で割込みを入れられる関数は無いようでした。このMsTimer2だと、1 msecで割込みを入れて、その代わり、一回の割込みで64回のリフレッシュパルスを発行することになります。

その後、FlexTimer2という、より自由度の高いタイマーが見つかったので、こちらを試します。DRAMのリフレッシュタイミング制約から以下の表261.1を作成しました。これに従い、実験によりタイマを決定します。

表261.1　FlexTimer2の解像度とリフレッシュ回数の対応

解像度	1割込みのリフレッシュ回数	周期
64,000	1	15.6 usec
32,000	2	31.3 usec
16,000	4	62.5 usec
8,000	8	125 usec
4,000	16	250 usec
2,000	32	500 usec
1,000	64	1 msec
500	128	2 msec

既存の基板のポートに対して、D44からZ80コネクタB18(*REFCK)に1本ジャンパー線を配線します。

#define XREFCK 44

割込みをイニシャライズルーチンsetup()で設定します。ここでは解像度を8,000として、割込みを1/8,000 sec=125 usec毎にかけ、refresh関数を呼び出します。

FlexiTimer2::set(1, 1.0/8000, refresh); // call every 125usec "ticks"

また、リフレッシュルーチンは以下のとおりです。

  void refresh() {
    digitalWrite(XREFCK, LOW); 
    digitalWrite(XREFCK, HIGH); 
    digitalWrite(XREFCK, LOW); 
    digitalWrite(XREFCK, HIGH); 
    digitalWrite(XREFCK, LOW); 
    digitalWrite(XREFCK, HIGH); 
    digitalWrite(XREFCK, LOW); 
    digitalWrite(XREFCK, HIGH); 
    digitalWrite(XREFCK, LOW); 
    digitalWrite(XREFCK, HIGH); 
    digitalWrite(XREFCK, LOW); 
    digitalWrite(XREFCK, HIGH); 
  }

このスケッチを実行した波形を図261.1に示します。

図261.1 *REFCKの波形 本来であれば表261.1より、125 usec毎に*REFCKは8回必要ですが、Arduinoの速度が遅いため6回しか発行できていません。8回発行すると、割込み処理だけで能力の限界となります。割込み周期を倍にすると、必要な*REFCK数が倍増するので結局変わりません。

評価プログラムを用いた実験結果は、熱はかけていないものの288秒で打ち切るまでノーエラーだったので、リフレッシュ回路は一応OKと判断します。ただし、DRAMリフレッシュのマージンに頼った実力OKの方式です。能力の大方がリフレッシュという効率も悪い方式なので、PICで改善することを期待します。

---

前のブログ 次のブログ

Arduinoのアクセス法の改善

ArduinoのリファレンスにはdigitalRead()、digitalWrite()という1ピンの入出力しかなく、パラレル入出力が無かったため、過去記事のようなアクセス法を取っていました。検索したところ、Arduino 日本語リファレンスのポート操作(その魚拓)でパラレル入出力が見つかったため、アクセス法を切り替えることにします。そのためポートアサインを以下のように変更します。

図260.1 Arduino Mega 2560 Proの端子図

図260.2 Arduino Mega 2560 Proの端子図(図260.1の右列グリーン枠部分) 図260.2のピンク色のアサイン表が示すように、アドレスはPORTF, PORTK、データはPORTF、制御信号はパラレルの必要は無いですが、PORTCにアサインし直しました。

上記サイトには、

DDRとPORTレジスタは読み書き両方が可能です。PINレジスタは読み取り専用です。

以下はレジスタを表す変数の名前のリストです。

DDRD: ポートD方向レジスタ
PORTD: ポートDデータレジスタ
PIND: ポートD入力レジスタ(読み取り専用)

とのことですが、実際には

DDRD: ポートD方向レジスタ
PORTD: ポートD出力レジスタ
PIND: ポートD入力レジスタ

となっているようです。DDRにより入出力をビット毎に切り替えられ、0が入力、1が出力となっています。 これがあまり表に出てきていない理由は移植性からのようです。digitalRead()のほうが移植性が高いとのことですが、元々8bitのパラレルデータを1bitずつ8回シフトして8bitデータとして使うのは、あまりにも馬鹿げています。

---

前のブログ 次のブログ

DRAMのリフレッシュタイミング

本来は基板設計の前にタイミングを検討しますが、開発環境と合わせて基板を紹介したため、後になっています。まずMB8265-15のデータシートを入手します。以下にZ80によるリフレッシュ手法である$\overline{\text{RFSH}}$リフレッシュタイミングを示します。

図259.1$\overline{\text{RFSH}}$リフレッシュタイミング

表259.1 MB8265-15の動的特性

Parameter	Symbol	MB8265-15
		Min	Max
$\overline{\text{RFSH}}\text{ Set Up Time Referenced to }\overline{\text{RAS}}$	$\text{t}_\text{FSR}$	100	-
$\overline{\text{RAS}}\text{ to }\overline{\text{RFSH}}\text{ Delay}$	$\text{t}_\text{RFD}$	100	-
$\overline{\text{RFSH}}\text{ Cycle Time}$	$\text{t}_\text{FC}$	270	-
$\overline{\text{RFSH}}\text{ Pulse Width}$	$\text{t}_\text{FP}$	150	-
$\overline{\text{RFSH}}\text{ Inactive Time}$	$\text{t}_\text{FI}$	100	-

PICのプログラム

DRAMのタイミング要求からPICのプログラムを検討します。PICの書き込み自体もArduino(Z80側)にやらせることもできそうですが、動作しない等のトラブルの可能性を考え、今回はPicKit4を用いたIn Circuit Programmingを行います。PicKit4上で書き込み、書き込み済みのPICをボード上のソケットにはめ込むことにしました。

PICのプログラムは基本的には前稿のようになります。Xrefckを4回アサートする場合、PICに対して16KHzでタイマー割り込みをかけ、以下のisr (interrupt service routine)を実行します。

初期化

1. 各種レジスタ設定。
2. Rfreq=L、Xrefck=Hを出力(ネゲート)。
3. Z80Wを監視し、Z80WがLのときにのみ割り込み許可。

割込みルーチン(ISR)

1. Rfreq=H、Xrefck=Hを出力 //リフレッシュ要求
2. Rfgnt=Hを待つ
3. Rfreq=H、Xrefck=Lを出力
4. Rfreq=H、Xrefck=Hを出力 (3, 4を4回繰り返す)
5. Rfreq=L、Xrefck=Hを出力
6. リターン

1命令1サイクルでないため、命令数のカット&トライが必要です。

Arduino(Z80側)のプログラム

一方、Arduino(Z80側)ではPICのRfreqを監視し、Rfgntを発行することでバス調停を行います。

過去記事には、

Z80カードは、FM-7の内部バスに対して、別のバスマスタを使用可能にするものであり、メインCPUである6809から$FD05のLSBを1にすれば、メインCPUにHALTがかかり、外部バスマスタであるZ80による内部バスアクセスが可能になるものです

ということから、

1. \$FD05に1を書き込み、6809にHALTを要求する。FM-7内部では*GH($\text{Go}/\overline{\text{Halt}}$, 負論理のHALT信号)がアサートされ、6809がBA=BS=Hとし、バスを明け渡す。
2. Rfgnt=H (初期値)
3. アクセス前に
   　・Rfreq=Lを待つ (リフレッシュ優先のため)。
   　・Rfgnt=Lとする。
4. アクセス(アドレス出力、データ出力、EB/QB出力、データ入力)
5. アクセスの終了時に
   　・Rfgnt=Hとする。
6. 終了時にはアドレスに\$FD05をセットし、EB/QBをアサートせずに6809にバスを明け渡す。

となります。このうち3, 5が今回追加したアクセス法です。このように、お互いに待つ場合はデッドロックの可能性があるため、背理法により無いことを証明しておきます。

• Aruduinoが待つ場合は、上記3.からRfgnt=Hとした上でPICを待つ
• 上記からデッドロックがあるとすれば、Rfgnt=Hのとき、PICがRfgnt=Lを待つ場合
• ところが、PICが待つのはRfgnt=Hであることから、矛盾、よってデッドロックは存在しない

---

前のブログ 次のブログ

PICの開発環境

早速、開発環境とCコンパイラをインストールし、PICプログラマを購入しました。

• 開発環境: MPLAB X IDE https://wak-tech.com/archives/51←無償、この記事のとおりにインストール
• Cコンパイラ: https://www.microchip.com/mplab/compilers←無償、ここで入手
• Microchip製プログラマPicKit4 ￥5,500 (秋月) 図258.1 PICマイコンプログラマ

対象となるPICマイコンは、秋月電子でも入手可能なPIC12F1501-I/Pとします。

• PICマイコン PIC12F1501-I/P @￥70 (秋月)

図258.2 PICマイコン

Eagleによる設計

PICマイコンをプログラマブルタイマーとして使用した回路図V5を図258.3に示します。回路は多いようですが、ほとんどがコネクタであり、Arduinoが1個と今回追加した8pinのICが全てです。他はZ80コネクタ、ロジアナ用ピンヘッダ、PICプログラム用コネクタから構成されます。

図258.3 FM-7IntruderV5の回路図 以前に格安PCB業者を調べましたが、今回は最安だったJLCPCBにオーダーしました。5枚で送料込みで17.95 USDです。ここは安いだけでなく、製造も速くて2～3日で製造します。 図258.4 FM-7IntruderV5の基板図

---

前のブログ 次のブログ

DRAMの"化け"は故障とみなせる

試みに、DRAMのリフレッシュを停めると、どの程度ビット化けが起きるかを実験してみました。 注意点として、データチェックのためにリードアウトすると、リフレッシュとなってしまうということがあります。そのため、1sec毎に故障数をチェックするのではだめで、リフレッシュ停止期間を1secずつ伸ばして行き、壊れているデータの数を計数します。リフレッシュを停止しただけなので、永久故障ではないのですが、機能停止を広い意味で故障として扱うため、ここでは故障(ソフトエラー)と呼ぶことにします。

図257.1 リフレッシュ停止時間に対する故障割合、及び故障密度

図257.1左がリフレッシュ停止時間(sec)に対する故障バイト数の試験数に対する割合(累積故障確率関数)、図257.1右がリフレッシュ停止時間(sec)に対する1秒当たりの故障数(確率密度関数)です。このグラフはジャンクション温度により非常に変化し、当然温度が高いほうが故障しやすいわけです。

この室温では2分間でほぼ全数のバイトが化けていることになります。グラフでは分かりにくいですが、漸近値が99.2%付近となっています。100%にならない理由は、DRAMはリフレッシュが停まると\$00または\$FFになり易く、たまたま正解値が\$00または\$FFだったためと思われます。一致する確率は2/256なので、故障個数の最大は、試験バイト数\$6000個に対して$(1-\frac{2}{256})=99.2186\%$の24,384個になるはずです。実データでは139秒後に24,384個故障し、確率的な一致を除いた最大数になりました。

リフレッシュ試験

DRAM化けの試験プログラムはそのままリフレッシュ回路の試験に使用できます。リフレッシュを停止すると、正規分布を持つ確率密度に従いソフトエラーが起こります。リフレッシュ回路を追加して、さらに厳しい条件となるようにドライヤー等でDRAMを加熱し、この試験プログラムを用いて、2分程度エラーが確認されなければリフレッシュ回路はOKと判断できます。非同期DRAMのタイミングは複雑であり、RASのタイミングが規格割れしただけでソフトエラーを起こすので、試験としてはこれだけでなく、様々なタイミング切り替えを実施するほうが良いと思います。

---

前のブログ 次のブログ

FM-7 ROM吸出し器にDRAMリフレッシュ回路を追加

過去記事において、表記のボードを開発しましたが、DRAMのリフレッシュを失念していました。そこで、前回のオールソフトウエア(?)回路に対して、ハードウエアでリフレッシュ回路を追加します。バイトアクセスはオールソフトウエアで可能なことを実証できたのですが、DRAMリフレッシュは2msec以内に128カラムアドレスにアクセスが必要、という制約があるため、ソフトウエアでは厳しいと思われます。従って、ハードウエアで構成しますが、タイミング回路なので意外に回路規模を必要とします。せっかくArduino 1個で済ませたので、最小の回路構成としたいところです。

アナログタイマーIC 555

最初に思いついたのは小型のタイマーICである555です。ところがこれはアナログICであり、時定数設定のためにRやCを複数必要とします。さらに、リフレッシュ周期だけでなくリフレッシュパルス幅を確保しようとすると、555の2個入りを使用する必要があるだけでなく、外付けCRも倍の数になり、シンプルになりません。設計してみたものの嫌になりました。

図256.1 NE555回路図

プログラマブルタイマーPIC

そこで、プログラマブルタイマーで検討したところ、PICマイコンを使用すれば、開発環境その他は必要となりますが、8pinのIC1個で行けそうです。デジタルのほうがシンプルで、かつ調整も無くて好きです。

図256.2 バス権調停信号図

PICのリフレッシュアルゴリズム

リフレッシュアルゴリズムは以下のように考えています。

• 6809が\$FD05に1を書き、Z80W信号をLにします(Z80W=$6809/\overline{\text{Z80}}$)。
• ArduinoはPICからのバス権の要求RFREQが無ければ、RFGNTをLにしてバスを獲得します。バスアクセスはQB/EBをアサートすることで行います(RFGNT=$\text{PIC}/\overline{\text{Arduino}}$)。
• Z80W信号がLの際に、PICから周期的にRFREQをHとしてバス権要求をArduinoに通知します。
• Arduinoはバスアクセス中であれば終了後にバス権を放し、PICにRFGNTをHとして通知します。
• PICはRFGNTがHであればリフレッシュ可能と判断し、*REFCKをLとします。
• バス調停のオーバヘッドを削減するため、PICは*REFCKは4回アサートします。その代わり、リフレッシュ周期は1/4の16KHzとなります。
• リフレッシュが終了すると、PICはRFREQをLにします。
• ArduinoはPICがバス権を放したと判断してRFGNTをLにしてバスを獲得します。

図256.3 バス権調停タイミングチャート

---

前のブログ 次のブログ

過去ブログの、BSVによるスペースインベーダーの再設計の記事#234~#239, #254をまとめてQiitaに投稿しました。さらに考察を加えています。

BSV (Bluespec SystemVerilog)によるスペースインベーダーの再設計

過去ブログ記事でUltra96ボードを用いた、VerilogHDLによるSpace Invadersゲームの作成を投稿しましたが、その続きです。

図255.1 Qiitaの投稿記事

---

前のブログ 次のブログ

ゲームFSMのアルゴリズム

トライアルの結果、BSVによるゲームFSMが完成しました。過去記事のステートベースのサウンドステートマシンと異なり、ステート分解をしていないため、rule文を一切使用していません。全てbsc(Bluespec Compiler)の、StmtFSMライブラリにステート管理を任せました。

基本的にはCで記述するようにゲームが記述できることが分かりました。例えば、弾の移動及び衝突判定、衝突処理(爆発マーク)、爆発マーク消去等のアルゴリズムを考えると、自弾、敵弾共にアルゴリズムは共通で、疑似コードで書けば、

if (弾爆発タイマ >= 1) {   // 弾爆発中
    弾爆発タイマ++;
    if (弾爆発タイマ == MAX) {
        弾削除;            // 論理的な消去
        弾爆発マーク消去;   // 物理的な消去
        弾爆発タイマ停止;
    }
} else {
    if (弾が出ていない and 弾生成条件) {
        弾生成処理;
        弾発射音;     // 自弾のみ
    }
    if (弾存在) {
        衝突判定;
        if (対象物) {  // 自弾の場合はインベーダ及びUFO、敵弾の場合は自機
            弾削除;          // 論理的な消去
            対象物ステート <= 爆発;
            対象物爆発タイマ <= 0;
        } else if (上下ハズレ || ベース || 弾) { // 弾:自弾の場合は敵弾、敵弾の場合は自弾
            弾マーク消去;
            弾爆発マーク;
            弾爆発タイマ <= 1;
        } else {        // 衝突していない場合
            弾を進める;
        }
    }
}

一方、対象物は、

if (対象物ステート == 爆発) {
    if (対象物爆発タイマ==0) {
        対象物爆発タイマ <= 1;
        対象物爆発音;
        対象物爆発マーク;
    } else {
        対象物爆発タイマ++;
        if (対象物爆発タイマ == MAX) {
           対象物削除;          // 論理的な消去
           対象物爆発マーク消去; // 物理的な消去
        }
    }
}

のようになりますが、StmtFSMを使うと、このようなシーケンスをクロック毎のステートに分解しなくて記述できます。

インベーダのタイミング

某所で質問があったので、タイミングについて解説します。基本の1 tickは1/60秒で、その中で、インベーダ1匹、敵弾全弾、自機、自弾、UFO、スコア等の処理を行います。以下は実際のBSVのメインループのコードです。

 while (game_flag) seq // メインループ
    for (noy <= 0; noy < `Inv_TateS; noy <= noy + 1) seq  // インベーダの行処理
       for (nox <= 0; nox < `Inv_YokoS; nox <= nox + 1) seq // インベーダの列処理
          if (inv_s[nox][noy]) seq // インベーダが生きてれば
             ivader;      // インベーダ処理
             gun;         // 自機処理
             bullet;      // 自弾処理
             for (idx <= 0; idx < extend(max); idx <= idx + 1) seq
                invBullet(idx);  // 敵弾全弾処理
             endseq
             ufo;         // UFO処理
             scores;      // スコア表示
             endJudge;    // 終了判定
             counter <= counter + 1;  // tickカウンタ++
             wait_timer;  // インナーループを1/60secにするウエイト
          endseq
       endseq
    endseq
 endseq
 gameOver;  // ゲームオーバー表示

1tick=1/60secの間に、インベーダ1匹(2ピクセル移動)の処理に対して、自機(1ピクセル移動)、敵弾(1ピクセル移動)、自弾(4ピクセル移動)の処理が行われます。インベーダは初期に55匹存在するので、1/55倍のスピードで始まりますが、最終的に1倍のスピードになります。従って、インベーダを倒すたびにインベーダ全体は速くなり、一方その他の速度は変わらないわけです。

FPGAでの実装では1 tick内にインベーダ全体を移動することは可能ですし、そのような実装も見ますが、ゲーム性が変わってしまいます。具体的には、インベーダ全体の速度が次第に速くならなかったり、後ろのインベーダを撃つことができなくなります。

例えば、インベーダゲームのレインボーは、後ろのインベーダを撃つことにより出現します。インベーダは残りが一匹になると左へは2ピクセルずつ右には3ピクセルずつ移動します。下2段のインベーダは、左右2ピクセルまでの移動では跡が残らない図形になっていますが、3ピクセルだと跡が消えずに残ります。もちろん今回の実装でもレインボーを体験できます。

ゲームFSMの完成

図254.1は、BSVで再設計したゲームFSMにより動作する、インベーダーゲームの動画です。過去記事に書いたように、サウンドが4ch同時発声と高品質になりました。

図254.1 ゲームFSMの完成

---

前のブログ 次のブログ

実行結果

次は、ファンクションの中にシーケンスを組み込み、ゲームFSMの設計トライアルを行います。 シーケンスを人手で分解することは、なるべくしたくありません。ファンクションでシーケンスが定義できれば、インベーダ動作、自機動作等のファンクションを作成し、順番にそれらを呼び出せば良いはずです。

import StmtFSM::*;

interface TestFSM_ifc;
   method Action inp(UInt#(8) inx);
endinterface

(* synthesize *)
module mkTestFSM(TestFSM_ifc);

Reg#(UInt#(8)) i <- mkRegU;
Reg#(UInt#(8)) x <- mkRegU;

function Stmt test1;
   return (seq
      $display("%3d 1-1", $time);
  delay(5);
      $display("%3d 1-2", $time);
   endseq);
endfunction

function Stmt test2(UInt#(8) xx);
   return (seq
      $display("%3d 2-1", $time);
      for (i <= 0; i < xx; i <= i + 1)
         $display("%3d 2-loop-%1d", $time, i);
      $display("%3d 2-2", $time);
   endseq);
endfunction

   Stmt main =
   seq
      $display("%3d fsm1.start", $time);
      test1;
      $display("%3d fsm2.start", $time);
      test2(x);
   endseq;

   mkAutoFSM(main);

   method Action inp(UInt#(8) inx);
     x <= inx;
   endmethod

endmodule: mkTestFSM

このためのテストベンチを示します。あえてモジュール外部からループ回数を入れているのは、ループ回数がダイナミックに(実行時に)決定できるかを確認するためです。ファンクションのループを8回呼び出してみます。

import StmtFSM::*;
import TestFSM::*;

(* synthesize, always_ready, always_enabled *)
module mkTb (Empty);
  TestFSM_ifc test <- mkTestFSM();
  Reg#(UInt#(8)) count <- mkReg(8);

   Stmt main =
      seq
         test.inp(count);
         repeat(40) noAction;
      endseq;

      mkAutoFSM(main);

endmodule

実行結果を示します。test1の次にtest2が呼び出され、ループが8回回ったことを示しています。

 20 fsm1.start
 30 1-1
 90 1-2
100 fsm2.start
110 2-1
130 2-loop-0
150 2-loop-1
170 2-loop-2
190 2-loop-3
210 2-loop-4
230 2-loop-5
250 2-loop-6
270 2-loop-7
290 2-2

---

前のブログ 次のブログ

実行結果

以下に実行結果を示します。

senderFSM 20 FSM started
receiverFSM 20 receiver FSM started
senderFSM 30 Enq 10
senderFSM 40 Enq 20
receiverFSM 40 FIFO popped data 10
senderFSM 50 Enq 30
receiverFSM 70 FIFO popped data 20
receiverFSM 100 FIFO popped data 30

10nsずつ見ていきます。最初の10nsはリセット期間なので、20nsからFSM動作を開始します。

senderFSM 20 FSM started
receiverFSM 20 receiver FSM started

同時にセンダーFSMとレシーバーFSMが動作を開始しました。

senderFSM 30 Enq 10

センダーFSMがデータ10をエンキューしました。FIFOには1段のデータがあるはずです。

senderFSM 40 Enq 20
receiverFSM 40 FIFO popped data 10

レシーバーFSMが10をデキューすると同時にセンダーFSMがデータ20をエンキューしました。FIFOには差し引き1段のデータがあるはずです。

senderFSM 50 Enq 30

センダーFSMのレイテンシは1サイクル10nsなので次々に(FIFO FULLにならない限り)エンキューします。これが最後のデータです。FIFOには2段のデータがあるはずです。

receiverFSM 70 FIFO popped data 20

レシーバーFSMのレイテンシは3サイクル30nsなので、70nsにならないと次データの20がデキューできません。FIFOには1段のデータがあるはずです。

receiverFSM 100 FIFO popped data 30

レイテンシである3サイクル後にレシーバーFSMがデキューしました。FIFOには0段のデータがあるはずです。つまりFIFOは空になったはずです。

波形で見たほうが判りやすいです。エンキュー動作(オレンジの信号)はFIFOがフルでない限り1サイクルで行われるのに対してデキュー動作(ブルーの信号)は3サイクル毎に実行されています。

図252.1 センダーFSMとレシーバーFSM

以上はデータを3つエンキューした場合ですが、ここで4つ目をエンキューすると動作が異なります。図252.2に示すように、3つまではレイテンシ1でエンキューできていましたが、3つめでFIFO FULLとなり、その後はレシーバーFSMのレイテンシが見えてきます。つまりエンキュー動作もレイテンシが3となります。

図252.2 センダーFSMとレシーバーFSM 図252.1でもFIFOがFULLになっているのですが、その時にエンキューが無いのでレシーバー側のレイテンシが見えませんでした。図252.2ではFIFOがFULL状態でエンキューしようとして待たされています。FIFOは2段だということが分かります。

実は、FIFO段数もコントロール可能であり、任意の段数のFIFOを作成するにはmkSizedFIFOFを使用します。

  FIFOF#(Bit#(8)) fifo <- mkSizedFIFOF(2);

mkSizedFIFOFの引数サイズを2とすると、上記と同じ動作を行います。サイズを1にすると、デキューするまでエンキューが待たされる、図252.3のような動作となります。

図252.3 　FIFOが1段の場合の動作 このFIFOライブラリは上記のように良くできていて、FIFOフルの場合等、FIFO がデータを受け取れない場合には自動的にエンキュー動作が抑止されます。普通ならFULLで無い条件でエンキュー動作を行う記述を書かなければいけませんが、その必要がありません。

---

前のブログ 次のブログ