前回の異様に遅い data packet の対策ですが、異様に遅いとはいわないものの転送途中に fifo が空になる状態を見つけてしまいました. そこで 0x200 byte の深さの 1 data sector 0x800 byte まで増やしてみようという試みです.
しかし資源不足が深刻なため無駄に使っている RAM をどれか減らさねばなりません. 現在の使用状況を記載して考えることにしました.
audio_mixer.adpcm_fifo_singleclock
- 1 M4K, 4bit x 0x400 word
- single clock
先日から地味に行っている audio_mixer の簡素化で dual clock から single clock に変更しました. それはいいとして ADPCM data は他と比べて読み込みの頻度が遅いので 0x400 word もいるのか疑問です. ある程度深さがないと CD からの追記が間に合わなくなります.
audio_mixer.cdda_fifo_single
- 1 M4K, 17bit x 0x100 word
- single clock
adpcm 向け fifo 同様 single clock に変更しました. この fifo はなくせます. 詳しくは cdrom_fifo で説明します.
audio_mixer.msm5205_romtable
- 2 M4K, 12 bit x 0x200 word
- single clock
4 bit の memory data から 12 bit の voice data を算出する過程で利用します. 実使用は 12bit x 0x0188 word のためですから使ってない領域も結構多いのですがつめたらなんとかなるのでしょうか...?
この ROM を使わなくても動的に計算することは可能ですが 120 logic cell 増えます.
mcu.boot_inst_400, 同_100
- 5 M4K, 16bit x 0x500 word
- single clock
MCU の起動から、外部の serial flash memory に入っている命令データを外部の RAM に書き込みます. また MCU に入力された7種類の割り込みの処理もここでやりまして、内部 ROM で片付けるか、外部 RAM で処理するかになります.
内部 ROM は USB 通信経由での flash memory の書き込みをサポートしますので内部データ更新利用で必要です.
命令使用量は 0x500 word のうち 0x4a8 word ぐらい使っておりまして,はみ出ている 0xa8 word をなくせるか何度も検討していますがこれ以上命令を減らすとソフトとして正常に動きません. ある程度ユーザーへの利便性を犠牲にしてまで命令を減らすことも考えましたが、削れるのは 0x80 word 程度でした.
mcu.boot_data
- 2 M4K, 8 bit x 0x400 word
- single clock
現在の使用量は 0x252 bytes ですので 0x100 bytes 程度削れば 1 M4K として運用できる可能性があります. この RAM 領域は空きが多かった経緯がありましたが、最近 TOC data を RAM に全部コピーするようにしましたので、300 bytes も RAM を使うようになってしまいました.
変数はともかく定数テーブルの使用量も多いためそこを削れるか試算したところ 0x60 bytes 程度は削れそうです. しかし stack の容量としては 0x10 bytes は不足です. stack を使いすぎると変数を上書きしてしてしまうのでもっと削る必要があります.
以前のように TOC data を RAM にコピーせずにメモリーカードから読みに行くことも一応可能です. 互換性では CD 読んでる途中に TOC 読みに行くと CD が止まっちゃうのであまりよくないのですがそれが明確な問題にはなっていませんでした. ただその命令や専用レジスタをばっさり削除したので戻すのは気が進みません.
- 1 M4K, 8 bit x 0x200 word
- single clock
PC からの USB 経由でのデータ通信に必要です. fifo をなくす場合は PC から 1 byte ずつ同期をとる必要があり、あまりよろしくありません.
pce_bridge_cpu_vce.colorram
- 2 M4K, 16bit x 0x200 word
- dual clock, dual port
6280 から vce 内部の color RAM を監視し、同じデータを保持します.
6280 側から書き込み, 720p 側から読み込みを行いますので dual clock かつ dual port となります.
この RAM は 1 M4K に削れます. data width を 16 bit とってますが, 必要なのは 9 bit だけです. 9bit x 0x200 words の場合は 1 M4K にできます. 16 bit のほうを使っていたのは bytemask 端子がついているので制御が楽なことと, 9bit のほうをちょっとやってみたらうまくいかなかったしそのときは容量に困っていなかったので放置し、忘れていました.
pce_cpu_linerfetch.backupram
- 4 M4K, 8bit x 0x800 word
- single clock, dual port
PCE 用の backup RAM です. UGX-02 で FeRAM をパラレルからシリアルに変更した都合で、シリアルのバスは PCE の PCE と直結はできないため FPGA 内部にパラレル RAM を設けて動くようにしています.
物理的な設計の話になりますがパラレルの FeRAM が高騰した上に低品質という大変な目に遭いまして、これは 4 M4K も使いますが必要です.
pce_cpu_linerfetch.cdromfifo
- 1 M4K, 8bit x 0x200 word
- single clock
メモリカードの CDROM data を fifo にいれて PCE が読み込みます. 問題の原因はこの fifo の深さが 0x800 word ほしいということでした.
CDDA fifo は2日前まで dual clock でしたので別の fifo として独立しておりました. CDDA と CDROM は並列に動くことはありません signle clock 同士であるのなら 2つの fifo は統合して深さを 0x400 word にしたほうがいいです.
そして他のブロックから 2 M4K を確保して 4 M4K 割り当てれば当初の目的は達成できます. (subchannel fifo は独立してるんでしょうけど増やせば CD-G も見れます)
video.pce_bridge_vce_720p
- 2 M4K, 16 bit x 0x200 word
- dual clock
VDC から出てくる data (= color RAM address) を 720p 制御側にクロックをまたいで渡す fifo です. 720p が読み込み処理をする間に fifo はたまっていきますのでこの深さが必ず必要です.
video.chroma_y
- 1 M4K, 8 bit x 0x200 word
- single clock
VCE で白黒モードのときに RGB からモノクロの値を算出するときに使います.
PCE ではアナログ RGB では適用されません. PCE 側では NTSC でアナログ回路の場合は簡単に色情報をなくせるのでついてる機能です. ディジタルだとわざわざ回路の追加が必要です.
モノクロ機能を有効に使っているソフトもなかったはずなので極端なことを言えばなくしてもいいと思います.
videotomcu:vtom
- 1 M4K, ? bit x 4 word
- dual clock
720pで frame buffer が空いてる時間に MCU が instruction RAM として使うためのタイミング調整です. ここは深さは全くいらないのですが, M4K 使わずに logic cell に割り当てれば 0 M4K にできます. もちろん logic cell 不足にも悩んでいますので割り当てるかは慎重に行う必要があります.
対処すべき順番
ここまで書いてなんとなくわかりました.
- pce_bridge_cpu_vce.colorram の data width 9 bit 化
- cdda と cdrom の fifo の統合
- audio_mixer.msm5205_romtable, video.chroma_y, videotomcu:vtom のうちどれかを削れるか考える
