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 (秋月)

Eagleによる設計

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

前のブログ 次のブログ

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

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

図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も倍の数になり、シンプルになりません。設計してみたものの嫌になりました。

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

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

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にしてバスを獲得します。

前のブログ 次のブログ