NES on FPGA feat. TangNano series
Gowin社 のFPGAを搭載した Sipeed社 の Tang Nano シリーズに NES on FPGA を移植したメモ。目標は、基本的な『スーパーマリオブラザーズ』から、 ROMサイズの大きい『星のカービィ』『沙羅曼蛇』も動かしたい。
そしてNESの次は…！
Tang Nano シリーズ
Sipeed から販売されている Gowin のFPGAを使用したボードたち。
なお Tang Nano 1K についてはLUT数が少なくNES入らないので割愛。
今回はWindows 10 22H2 にて、Gowin EDA FPGA Designer ver. 1.9.9 (64-bit) を使用。
NES on FPGA 見積もり
Gowin EDA での合成結果では、約3,600LUTsとなった。 また必要なBlockSRAMは、WorkRAMが2kByteとVRAMが2kByteに加え＋αでラインバッファ等がある。 ソフトはPRG-ROM（プログラム）とCHR-ROM（キャラクタ）からなり、 これをどうやってメモリに配置するか、 そしてCPUからのPRG-ROMアクセスと、PPUからのCHR-ROMアクセスをどう捌くかが実装のカギとなる。 ちなみに、PRG-ROMアクセスは約560ns間隔で、CHR-ROMアクセスは約372ns間隔で発生するので、 メモリアクセスはこの時間の間に収めなければならない。NES on FPGA feat. TangNano4K
| 価格 | 約2,000円（2023年8月時点） |
| デバイス | LittleBee GW1NSR-LV4CQN48PC6/I5 （55nm LP embedded flash） |
| リソース | 4,608 LUTs、BlockSRAM 約22kByte |
| メモリ | HyperRAM 8MByte |
| 参考 | Sipeed wiki Tang Nano 4K |
NES on FPGA feat. TangNano4K
— かんな丸！！ (@pgate1) 2024年1月4日
使用率93%でMapper 0のみ実装して、マリオやレッキングクルーをUSB-JTAG経由で送信して動かせました。4KでNESは誰もやってなかったので移植してみたけど、LED１個でデバグつら。 pic.twitter.com/2aKNpUjpHM
メモリマッピング
PRG-ROMとCHR-ROMをHyperRAMに共存させようとしても、 HyperRAMのリードアクセス時間が長いため不可。 このため、PRG-ROMのみHyperRAMに配置し、CHR-ROMは8kByteのBlockSRAMを使用する。 よって動かせるソフトはCHR-ROM（もしくはCHR-RAM）が8kByteまでのものに限られる。BlockSRAM推論
要件としては、1クロックでWriteできることと、 Readした次のクロックおよび永続的にデータを参照できること。 SFL+の記述は従来通りで変更はなく、ここから生成される VerilogHDLでSDPB（Semi Dual Port Block SRAM）に推論される。
ram_8x8k.sflp
circuit ram_8x8k
{
input adrs<13>, din<8>;
instrin write(adrs, din);
instrin read(adrs);
output dout<8>;
mem ram[8192]<8>;
reg dout_reg<8>; // 出力レジスタ使用
if(write) ram[adrs] := din;
if(read) dout_reg := ram[adrs];
dout = dout_reg;
}
HyperRAM
Gowin EDAのHyperRAM_Memory_Interface IPを 49.95 MHz で最短のバースト長16で試したところ、 リードアクセス時間は 686 ns となり、遅すぎてPRG-ROMアクセスが間に合わない。 そこで、バースト無しメモリアクセスコントローラを使用すべく、 以下のPSRAM用コントローラを少し書き換えて使用させて頂いた。 これならリードアクセスが 282 ns で間に合う。 ちなみにGowinのIPは 643 LUTs、今回のコントローラは 118 LUTs で済むのも嬉しい。最初、HyperRAMが動かなくて困っていたけど、 サンプル通りのポート宣言に修正したらポートが正常に割り当てられて動いた。
NES_top.v
// NG：ピンが正常に割り当てられない
output wire O_hpram_ck,
output wire O_hpram_ck_n,
output wire O_hpram_cs_n,
output wire O_hpram_reset_n,
inout wire [7:0] IO_hpram_dq,
inout wire IO_hpram_rwds
// OK：こちらで動作した
output wire [0:0] O_hpram_ck,
output wire [0:0] O_hpram_ck_n,
output wire [0:0] O_hpram_cs_n,
output wire [0:0] O_hpram_reset_n,
inout wire [7:0] IO_hpram_dq,
inout wire [0:0] IO_hpram_rwds
USB-JTAG UART
ソフトROMをFPGA内メモリに配置するには、仮想COMポートを使用したUSB-UARTが楽だが、 残念ながらTangNano4KではUSB-UARTのピンがFPGAに接続されていない。 そこで、USB-JTAG経由でのUARTを使用する。 USB-JTAG UARTには以下を参考にデータ受信UARTモジュールを作成した。参考： Tang-Nano-4Kとパソコンとの、JTAG経由の直接通信
UARTにはJTAGピンをユーザピンとして使用している。 このため、FPGAデータを書き込むと Gowin Programmer からは見えなくなるが、 電源を入れなおせば再度FPGA内にデフォルトデータが書き込まれるので問題ない。 ただしデバグの度にUSB電源とHDMIケーブルを抜き差しするのが非常に面倒だった。注意点として、FPGAデータは SRAM Program を使用すること。 Flash Program で書き込んでしまうと電源を入れなおしてもそれがFPGAに書き込まれてしまうため Gowin Programmer から認識されなくなってしまう。 対処法としては、JTAGSEL（ピン8）をGNDに接続した状態で、JTAGピンをユーザIOとして使用していないデザインを書き込むといいらしい。
PCからはFTDIドライバを使用してFT_Writeでデータを送信する。 データ送信が速いとHyperRAMへのWiteが間に合わなかったので、１バイトずつFT_Writeしている。 最大65535Byteまで送信できるので、マリオの約40kByteは問題なし。
ftdi_send.cpp
// ポートオープン
FT_HANDLE ftHandle;
FT_OpenEx((PVOID)"USB Debugger A", FT_OPEN_BY_DESCRIPTION, &ftHandle);
int send_size = 16 + 32768 + 8192 + 2 + 3;
// Sendサイズセット
uint8 init[3];
init[0] = 0x31; // Writeコマンド
init[1] = (uint8)send_size;
init[2] = (uint8)(send_size >> 8);
uint32 write_size;
FT_Write(ftHandle, init, 3, &write_size); // Writeサイズセット(初期化)
// ROMのロード
FILE *fp = fopen("mario.nes", "rb");
uint8 *rom = new uint8[16+32768+8192];
fread(rom, 1, 16+32768+8192, fp);
fclose(fp);
uint8 begin[1];
begin[0] = 0x00; // Mapper 0
FT_Write(ftHandle, begin, 1, &write_size);
FT_Write(ftHandle, begin, 1, &write_size);
// ヘッダー send
for(i=0; i<16; i++){
FT_Write(ftHandle, rom+i, 1, &write_size);
}
// PRG-ROM send
for(i=16; i<16+32768; i++){
FT_Write(ftHandle, rom+i, 1, &write_size);
}
// CHR-ROM send
for(i=16+32768; i<16+32768+8192; i++){
FT_Write(ftHandle, rom+i, 1, &write_size);
}
uint8 end[1];
FT_Write(ftHandle, end, 1, &write_size);
FT_Write(ftHandle, end, 1, &write_size);
FT_Write(ftHandle, end, 1, &write_size);
delete[] rom;
FT_Close(ftHandle);
映像出力
Gowin EDA で生成できる DVI_TX のIPを使用する。最初、NES解像度を倍にした 512 x 448 で表示させてみたところ、 HDMI-USBキャプチャではスケーリング表示できたが、例のモニタでは表示できなかった。 他のモニタでも確実に表示されるよう、 640 x 480 で出力し 512 x 448 はスケーリングせずに中央に描画させた。
サウンド出力
一応APUもFPGAに入るかの確認のため、サウンド出力は1bitΔΣを通してLEDに接続してる。 IOピンに接続するとノイズになってしまうので、今のところLEDに接続。 音がモヨモヨ光る様子が見て取れる。クロック
メインクロックは 27 MHz を使用可能。 NESの実装見積もりで Fmax 30MHz 程度だったことも考慮し、 DVI_TXクロックを 124.875 MHz とし、NESコア用クロックは5分の1の 24.975 MHz とした。 HyperRAMクロックはNESコアの2倍の 49.95 MHz を使用。NESコアは 25 MHz もしくは 50 MHz をベースに実装しているので、 クロックを 25.2 MHz にした場合、PPUの描画がHsyncに間に合わず、画面が下に流れてしまう現象が発生してしまう。 よって今回は、25 MHz 以下で設定する必要があった。
動作確認
実装はMapper0のみ、『スパーマリオブラザーズ』『レッキングクルー』等が動作した。LED１個でデバグするのは非常につらいので、Gowin Analizer Oscilloscopeを活用した。
レポート
| リソース使用率 | 4,264 / 4,608 LUTs (93%) |
| BlockSRAM使用率 | 9 / 10 (90%) |
| NESコアFmax | 30.7 MHz |
| 論理合成・配置配線時間 | 40 sec |
| FPGAデータ・コード | Tang Nano 4K 用FPGAデータ（GitHub） |
試しにいくつかのMapperを有効化して合成してみたところ、 LUT使用率ほぼ100%になった。 それでも合成・配置配線時間は変わらず、Fmaxも達成している。 Gowin EDA やるじゃん。
NES on FPGA feat. TangNano9K
| 価格 | 約2,300円（2023年8月時点） |
| デバイス | LittleBee GW1NR-LV9QN88PC6/I5 （55nm LP embedded flash） |
| リソース | 8,640 LUTs、BlockSRAM 約58kByte |
| メモリ | PSRAM 64Mbit (32Mbit 2ch) |
| 参考 | Sipeed wiki Tang Nano 9K |
NES on FPGA feat. TangNano9K
— かんな丸！！ (@pgate1) 2024年1月6日
PSRAMが２つ使えてそれぞれPRG-ROM・CHR-ROMとして実装できるので移植難易度は低いですね。使用率は61%程度なのでMapperも複数実装できる。容量の大きいマリオ３や沙羅曼蛇も難なく動きました。 pic.twitter.com/8AEa3zZ0UF
メモリマッピング
PSRAMとして4MByteのダイが２つ載っており2chで使えるので、それぞれPRG-ROMとCHR-ROMとして使用する。 一番楽かもしれない。PSRAM
Gowin EDAのPSRAM_Memory_Interface_HS_2CH_V2 IPを 49.95 MHz で最短のバースト長16で試したところ、 リードアクセス時間は 727 ns となり、遅すぎてPRG-ROMアクセスもCHR-ROMアクセスも間に合わない。 そこで、以下のPSRAM用コントローラを使用させて頂いた。 少し修正すればバーストなしバイトアクセスが可能。 これならリードアクセスが 282 ns で間に合う。 ちなみにGowinのIPは 1017 LUTs、今回のコントローラは 118×2＝236 LUTs で済むのも嬉しい。microSDカード
いわゆるTFカードスロットが付いているので、ROMはここから読み込む。 回路図を見るに、配線はSPIモードの接続のみ。 他FPGAプロジェクトから、SDカードSPIアクセスモジュールとFAT16モジュールを流用する。 FAT16なので、microSDカードは最大2GBまでのものをたくさん用意した。サウンド出力
HDMI-Audio追加 2024/07/28
HDMIでサウンドも出力したかったので、以下の HDMI IP を使わせて頂いた。参考： hdl-util / hdmi
ただ、NES coreからのサウンド出力をそのままHDMIモジュールに接続しても、 クロックドメインが異なるためノイズが乗る。 HDMIモジュール内ではaudio_clkの立ち上がりでAudio信号をホールドしているようなので、 以下のようにaudio_clkの立ち下がりでサウンドを保持することによりノイズは消えた。
NES_top.sv
localparam CLKFRQ = 25000000;
localparam AUDIO_RATE = 32000;
localparam AUDIO_CLK_DELAY = CLKFRQ / AUDIO_RATE / 2;
reg [$clog2(AUDIO_CLK_DELAY)-1:0] audio_divider;
reg audio_clk;
wire [15:0] Audio [1:0];
reg [15:0] s_Audio [1:0];
always @(posedge pixel_clk) begin
if(audio_divider != AUDIO_CLK_DELAY - 1)
audio_divider++;
else begin
audio_clk <= ~audio_clk;
audio_divider <= 0;
// クロックたち下がりでホールド
if(audio_clk) s_Audio <= Audio;
end
end
あと、電源を入れた後に「ブツッ…ブツッ…」という定常的なノイズがあるのが謎（１分くらいで消える）。
他のボードでも出るからHDMI-USBキャプチャが原因か？
映像出力
上記の HDMI IP に移行してもちろん映像は映るものの、 ドットクロックがIP想定25.2MHzのところ、24.975MHzのためか画面がちょっと横にずれる。 HDMIモジュールの入力にオフセット指定できるポートがあるので微調整した。
2025/04/13 追記： どうやらこの HDMI IP から出力されるピクセル座標に合わせて画面信号を入力してやる必要があるらしい。ちょっと面倒。
クロック
NESの実装見積もりで Fmax 30MHz 程度だったことも考慮し、 DVI_TXクロック 124.875 MHz、NESコアクロックは5分の1の 24.975 MHz とした。 PSRAMクロックはNESコアの倍の 49.95 MHz とした。入力クロック 27 MHz から、49.5 MHz および 24.75 MHz を作るより、 まずDVI用のクロックを作って割った方が 25 MHz に近いのはたまたまなのか、 それとも高クロックからクロックツリーを設計すべきなのか。
また、CHR-ROMリードが間に合ってなかったので、 １クロック早くリードリクエストを出せるようにちょっと修正。
動作確認
実装はMapper0,1,2,3,4,73 を実装してみた。 『スパーマリオブラザーズ３』『星のカービィ』『沙羅曼蛇』等が動作した。レポート
| リソース使用率 | 5,190 / 8,640 LUTs (61%) |
| BlockSRAM使用率 | 10 / 26 (39%) |
| NESコアFmax | 34.7 MHz |
| 論理合成・配置配線時間 | 50 sec |
| FPGAデータ・コード | Tang Nano 9K 用FPGAデータ（GitHub） |
USB-UART追加 2024/06/11
ROM入れ替えのために毎回microSDカードを抜き差しするのが面倒だったため、 PCからUART経由でROMを送信できるようにした。 TangNano9KのUSB接続はBL702というチップが使用されているようだ。 UARTモジュールでタイミングを攻めれば、ボーレート230,400×8＝1,843,200 baud まで速度出せることを確認 （実効速度約200kByte/s）。 ついでにUART送信ソフトにキー入力機能を付けて、 キー情報をUART経由で送信しゲームをプレイできるようにした。映像はHDMI-USBキャプチャでOBSに映してて、 UARTでキャプチャできればUSBキャプチャいらないのでは！？と考えたが、 １画面（256x240）は約122kByteなので1fps程度だと気づく （テーブルゲームのようなものならいけそう）。
NES on FPGA feat. TangNano9K：ROMデータをUART経由で送信するアプリ作ったので、ついでにキー操作もUARTで送信してゲームプレイできるようにした！PCにゲームパッドつなげて使えるようにすればもっと操作性良くなるかな pic.twitter.com/KMB6Hr4qTc
— かんな丸！！ (@pgate1) 2024年6月11日
NSF演奏時の画面エフェクト追加 2024/08/09
サウンドが出るようになったので、NSF演奏マッパーも有効にしてみた。 そしてせっかくなのでピアノロール的波形エフェクト回路も移植。
違うFPGAボードだけど動きはこんな感じ。
NSFプレイヤーにピアノロール的波形エフェクト画面を追加してみました。ちなみに３曲目のV.G.NEOは拡張音源のVRC7を使っている曲で、VRC7の本体としてvm2413を使わせて頂いています。 pic.twitter.com/kAPpSmT6zw
— かんな丸！！ (@pgate1) 2022年9月22日
NES on FPGA feat. TangNano20K
| 価格 | 約4,000円（2023年8月時点） |
| デバイス | Arora GW2AR-LV18QN88C8/I7 （55nm LP SRAM） |
| リソース | 20,736 LUTs、BlockSRAM 約103kByte |
| メモリ | SDR SDRAM 8MByte |
| 参考 | Sipeed wiki Tang Nano 20K |
NES on FPGA feat. TangNano20K
— かんな丸！！ (@pgate1) 2024年1月7日
1chipMSXに移植した時と同様に、SDRAM１個をPRG-ROMとCHR-ROMで共有してます。9Kよりも動作周波数上がって、NESコアは約50MHzでいけた。 pic.twitter.com/KKi8Dzhvzm
メモリマッピング
SDRAMが１個なので、PRG-ROMとCHR-ROMを共存させる。 CPUとPPUからのメモリアクセスアービトレーションは必要。SDRAM
他のFPGAプロジェクトから、バースト無しSDRAMコントローラを流用する。 もちろんPRG-ROMアクセスとCHR-ROMアクセスをアービトレーションする仕組みは必要だけど、 NES on FPGA feat. 1chipMSX での実装と同様の構成で動いた。クロック
NESの実装見積もりで Fmax 70MHz いけたので、 DVI_TXクロック 124.875 MHz を 5分の2 してNESコアクロックは 49.95 MHz とした。 SDRAMクロックもNESコアと同じ 49.95 MHz を使用。動作確認
実装はMapper0,1,2,3,4,73 を実装してみた。 『スパーマリオブラザーズ３』『星のカービィ』『沙羅曼蛇』等が動作した。 他のマッパーも余裕で追加できる程度にはリソースが余っている。レポート
| リソース使用率 | 5,240 / 20,736 LUTs (26%) |
| BlockSRAM使用率 | 10 / 46 (22%) |
| NESコアFmax | 68.1 MHz |
| 論理合成・配置配線時間 | 45 sec |
| FPGAデータ・コード | Tang Nano 20K 用FPGAデータ（GitHub） |
microSDカードアクセスとDVI出力とサウンド出力は Tang Nano 9K 同様の実装とした。
ちなみにTFスロット（microSDスロット）はSDモードが使用できるよう配線接続されているので、 そのうちSDモードアクセスモジュールに切り替えてROMの読み込み時間を半分にしたい （NESの場合は数十kByteなので読み込み一瞬だけど、SNESだと数MByteなので読み込みに少し時間がかかる）。 あとはmicroSDHCカードとFAT32のサポートに移行したい。
2024/02/18 追記： microSDHCコントローラとFAT32モジュールを実装し移行した。
Retro Game Emulation Kits
ゲーム操作したかったし音も出したかったため購入。 似非プレステパッド２個付きで約6300円＋ホーン236円＋送料2500円。
こんな感じでセッティング。 反対側にもパッドコネクタを増設できるが、LEDとピン共有されているため今は使用せず。 あとTFスロットがUSBコネクタの裏側にあってmicroSDカードの抜き差しがしづらい…。
2024/05/04： プレステパッドつなげて操作できるようになった。 他のボードにつなげた時とちょっと受信信号がずれる（？）ので少し調整。 付属の似非プレステパッドもオリジナルプレステパッドとほぼ同じアクセスで使用できたが、 振動や感圧は無し。
NES on FPGA feat. TangNano20K：プレステパッドつなげて操作できるようになった。他のボードにつなげたときとちょっと受信信号がずれる（なんでだろ？）ので少し調整。これは自由に動けるようになって喜ぶ人 pic.twitter.com/7fSw8dWnoV
— かんな丸！！ (@pgate1) 2024年5月4日
2024/05/06： ホーンからサウンド出せた。 アンプICのディジタル入力にはバンクIOの制約で3.3Vを使用。 低音が弱いので、三角波の音量を倍にする感じでちょうどいい。
NES on FPGA feat. TangNano20K：おとでた
— かんな丸！！ (@pgate1) 2024年5月6日
ピントは永遠に合わない
HDMIにオーディオ流すのはまた時間が取れたらにしよ pic.twitter.com/Na9rb4XAyc
NES on FPGA feat. TangConsole138K
| 価格 | $129 販売サイト |
| デバイス | Arora V GW5AST-LV138PG484AC1/10 （22nm SRAM） |
| リソース | 138,240 LUTs、BlockSRAM 約765kByte |
| 外部メモリ | SDR SDRAM 32MB×2、DDR3 DRAM 512GB×2 |
| 参考 | Sipeed wiki Tang Retro Console |
NES on FPGA feat. TangConsole
— かんな丸！！ (@pgate1) 2025年4月13日
移植できた！LUT使用率は5%ほど
SDRAM１個で動かしてるのでメモリアクセスは Tang Nano 20K とほぼ同様の実装でok
HDMIオーディオは誤差を抑えたオーディオ用クロック作って音が途切れないようにできたので優勝 pic.twitter.com/1WOJ5vbSho
メモリマッピング
外部SDRAMが２個使用できるが、CSnで選択する配線のため同時アクセスにはSDRAMコントローラの工夫が必要。 とりあえず Tang Nano 20K 同様に、SDRAM１個をPRG-ROMとCHR-ROMで共有する。もう一方のGPIOヘッダにさらにSDRAMモジュールを追加できるようなので買うか。
クロック
50MHzのメインクロックを使用できるので、 HDMIクロック 125 MHz、ピクセルクロック 25MHz。 NESコアクロックは 50 MHz とし、 SDRAMクロックもNESコアと同じ 50 MHz を使用。HDMI
以下の HDMI IP ならDataEnable信号を入れれば画面がズレることもないのでありがたく使わせて頂く。 ただしオーディオ用に3個ほどBSRAMを消費するが、 138KはBSRAMたくさんなので問題なし。 せかっくなので 256 x 224 を 640 x 480（もしくは 1280 x 960）にスケーリングして 4:3 モニタにちゃんと表示させたいね。HDMIオーディオ
初期実装では、HDMIに乗せたオーディオが1秒毎に途切れる現象があった。 原因は 25MHz を 781分周した 32.010kHz をaudio_clkとして使用していたため。 HDMI IP にはサンプリング周波数として 32kHz を指定していたが、 10Hz のずれがバッファ切れを起こしていたようだ。 このFPGAのPLLでは最低 6.25MHz までしか生成できないため、 audio_clkには 積分型カウンタ を使用して生成した誤差0の 32kHz を使用することで音の途切れを解消した。
NES_top.sv
// NG：audio_clk=32.010kHz 音が途切れる
localparam CLKFRQ = 25000000;
localparam AUDIO_RATE = 32000;
localparam AUDIO_CLK_DELAY = CLKFRQ / AUDIO_RATE / 2;
reg [$clog2(AUDIO_CLK_DELAY)-1:0] count;
reg audio_clk;
always @(posedge pixel_clk or posedge sys_reset) begin
if(sys_reset)
count <= 0;
else if(count != AUDIO_CLK_DELAY-1)
count++;
else begin
count <= 0;
audio_clk <= ~audio_clk;
end
end
// OK：audio_clk=32kHz 音の途切れなし
localparam COUNT_WIDTH = 13;
wire [COUNT_WIDTH-1:0] add;
wire [COUNT_WIDTH-1:0] max;
reg [COUNT_WIDTH-1:0] count;
wire [COUNT_WIDTH-1:0] sa;
reg audio_clk;
assign add = COUNT_WIDTH'('d8);
assign max = COUNT_WIDTH'('d3125);
assign sa = count - max;
always @(posedge pixel_clk or posedge sys_reset) begin
if(sys_reset)
count <= 0;
else if(sa[COUNT_WIDTH-1]) // count < max
count <= count + add;
else begin
count <= sa + add;
audio_clk <= ~audio_clk;
end
end
UART
ROMはmicroSDHCカードからのロードをサポートしたが、 Tang Console のボタンではファイルの選択がしづらい。 そこで Tang Nano 9K 同様にPCからUART経由で送信できるようにした。 Tang Console の BL616 だとPCからの送信速度は 3,000,000 baud まで出せた （ただしPCへの受信速度は 230,400 baud までしか出ず、バッファのせいか？）。レポート
| リソース使用率 | 6,573 / 138,240 LUTs (5%) |
| BlockSRAM使用率 | 13 / 340 (4%) |
| NESコアFmax | 69.4 MHz |
| 論理合成・配置配線時間 | 101 sec |
| FPGAデータ・コード | Tang Console 138K 用FPGAデータ（GitHub） |
せっかくUSBポートが２つあるのでUSBパッドをサポートできると良いな。 現状、PCからUART経由で操作できるようにしている。
SNES on FPGA feat. TangNano20K
Tang Nano 20K はファミコン実装には贅沢なので、ついでにスーファミも実装してみた。 LUTが足りないためサウンドDSPはオミット。SNES on FPGA feat. TangNano20K（No sound）
— かんな丸！！ (@pgate1) 2024年1月8日
LUTが足りなくサウンドDSPを除外して使用率73%で実装しました。でもサウンドメモリは必要なのでBlockSRAMを使ってます。本当はSDRAM１個でWorkRAMと共存させたいけどアクセス速度がちょっと厳しくて無理だった。 pic.twitter.com/3IRMiSfHXs
メモリマッピング
VRAM 64kByte は速度が要求されるためBlockSRAMで実装。その他のCPUからアクセスするROMが最大 4MByte、WorkRAM 128kByte、SaveRAM 256kByteはSDRAMを共用する。 ただし、ROMからWorkRAMへのDMAは通常リードとライトが並列に動作するが、 ここでは同じSDRAM内のため並列動作は解除して順次動作としている。
また、SoundRAM 64kByteについてもSDRAMに共存させるつもりだったが、 CPUメモリアクセスとサウンドプロセッサメモリアクセスをアービトレーションしてもアクセスタイムオーバーのため共存は諦めた。 しかし、SNESのCPUはサウンドプロセッサと協調して動作するので、SoundRAMの実装は必須。 結果的には、SoundRAMは4分の1の 16kByte でBlockRAMとして実装した。 観測した限りではあるけど、サウンドドライバはSoundRAMの低アドレス領域（0x0000～0x3FFF）に配置しているケースが多かったので動いている模様。 サウンドDSPをオミットして音を出さないのであれば、後半（0x4000～0xFFFF）の波形メモリ領域が不要であり、このようなトリッキーな実装が可能だった。 なお、8kByteだとバハムートラグーンやクロノトリガーが動かず、 32kByteだとBlockSRAMが足りない。
2024/03/28 追記： アービトレーション回路を修正し、 SDRAMクロックを 99.9 MHz に引き上げ、 配置配線のオプションをタイミング優先にして SoundRAMもSDRAMで共存させることができた。 一応『クロノトリガー』や『バハムートラグーン』のOPデモをパス。 しかしやはりサウンドDSPが入らず音は出ない。 それに、影響ない部分の回路を変更すると動かなくなるし、 そもそもアクセスタイムぎりぎりで動かすためCDCケアしてないので この実装は実験的なものに終わった。
2024/11/08 追記： SDRAMアービトレーション回路とリフレッシュ回路を修正して、 core 24.975 MHz、SDRAM 99.9 MHzで安定して動作するようになった。 SoundRAMサイズが実機同様64kByteとなったので、他のソフトも動くようになったと思う。
クロック
SNESコア実装の見積もりでFmaxが 40MHz 程度だった（速度最適化オプションありだと 46 MHz）ので、 DVI出力用に 124.875 MHz を、SNESコア用にその5分の1の 24.975 MHz を生成した。 SDRAMはSNESコアの2倍の 49.95 MHz を使用する （SoundRAMをSDRAMに同居させる場合は 99.9 MHz）。できるだけSDRAMアクセス時間を短くしたいということもあり、 従来SDRAMリフレッシュはオートランさせていたが、 今回はSNESのDRAMリフレッシュタイミング中にリフレッシュを行うよう修正。 動作としてはこちらの方が実機に近いかな。
2024/11/08 追記：
SNESコアのクリティカルパス箇所の修正と、不要なリセットの削減を行った。
また、リセットがLW（Long Wire、ロジックラインにも使用可能なパス）だったものを、
PRIMARY（グローバル専用ライン）に乗せた。
これによりSNESコアFmax 49.95MHz を達成した
（ただしコア 24.975MHz の方が安定して動作する…）。
リセット信号をグローバルPRIMARYラインに乗せるには２通りの方法があるようだ。
ドキュメントだとグローバルクロックラインとあるが、
リセットも乗せられるらしい。
- 物理制約で指定
記述例：
CLOCK_LOC "sys_reset_6" BUFG = SR;
ここでsys_reset_6は論理合成で生成されるネット名のためHDLを修正すると名前が変わる可能性があるので、 レポートのHigh fanoutから判断して指定する。 - プリミティブを使用
記述例：
DQCE dqce_inst ( .CLKIN(sys_reset), .CE(1'b1), .CLKOUT(g_sys_reset) );
DQCEプリミティブを使用することでHDLでリセット信号を指定できる。 （AroraVの場合はDCE）
動作確認
『ロックマンX』や『FinalFantasyV』等が動作。 『バハムートラグーン』や『クロノトリガー』のオープニングデモをパスした。 セーブデータも読み込めることを確認。SNES on FPGA feat. TangNano20K（No sound）
— かんな丸！！ (@pgate1) 2024年1月8日
大好物なバハムートラグーンのOPデモもパスしました。どろどろ愛憎劇でリメイク待ってる。 pic.twitter.com/pBAiZa2ZrG
SNES on FPGA feat. TangNano20K（No sound）
— かんな丸！！ (@pgate1) 2024年1月9日
セーブデータも読めるようにした pic.twitter.com/jXk2MJ4XYR
レポート
| リソース使用率 | 14,960 / 20,736 LUTs (73%) |
| BlockSRAM使用率 | 46 / 46 (100%) |
| SNESコアFmax | 33.4 MHz |
| 論理合成・配置配線時間 | 150 sec |
| FPGAデータ・コード | Tang Nano 20K 用FPGAデータ（GitHub） |
非同期リセットか同期リセットか
FPGAベンダが出しているHDLコーディングガイド等で、 非同期リセットか同期リセットのどちらかが推奨されていたりする。 GowinEDA はどうかな？と思いドキュメントを探してみたけど見つけられず、 実際に SNES on FPGA で比較してみた。 sfl2vlの -sync_res オプションで容易に非同期・同期を切り替えられる。以下の表は CPU,PPU,DMA 回路をリセットを変更して比較したもの。 なぜか同期リセットの方がLUT少し減ったような気もするけど、 どちらでもあまり変わりなさそう。
| リセットタイプ | 論理合成・配置配線時間 | 使用リソース | Fmax |
|---|---|---|---|
| 非同期リセット | 150 sec | 9,237 LUTs, 4,145 regs | 33.4 MHz |
| 同期リセット | 160 sec | 9,140 LUTs, 4,150 regs | 35.1 MHz |
SNES on FPGA feat. TangConsole138K
というわけで Tang Nano 20K ではサウンドを鳴らせなかったので、 Tang Retro Console Basic 138K に実装した。 と言ってもほぼコア部分をNESからSNESに置き換えた感じ。今回使用したのはSDRAMモジュール＋アクリルカバー付きのもの。 138K LUT のFPGAモジュール（SOM）が載ってるが、60K のものもある。 Single Console はSDRAMモジュール無し（買った人によると付いてたらしいが）、 Retro Console Premium はSDRAMモジュールに加え、 アクリルカバーではなく3Dプリンタ出力したケースとTFカードも付属する。SNES on FPGA feat. TangConsole
— かんな丸！！ (@pgate1) 2025年4月27日
実装できた！
TangNano20KだとサウンドDSPが入らなくて音無しだったけどこっちは138Kもあるので、スーファミ全実装が可能か不可能かで言えば、余裕です（LUT使用率19%）
はじめ動作が不安定なことがあったけど入出力遅延制約付けたら安定したし pic.twitter.com/N50P5IpN60
メモリマッピング
CPUからアクセスする ROM 最大8MByte と SaveRAM 最大256kByte をSDRAMにマッピングし、 WorkRAM 128kByte、VRAM 64kByte、SoundRAM 64kByte をBlockSRAMで賄えた。 つまりROMからWorkRAMへのDMAについて実機同様にReadとWriteを並列化できる。クロック
NES on FPGA feat. TanConsole138K と同様で動いた。 つまり Arora V デバイスにより SNESコアが50MHz動作できた。UART
UART経由でROM送信やゲームコントロールはもちろん、 セーブデータやSPCも送信できるようにした。レポート
| リソース使用率 | 24,658 / 138,240 LUTs (18%) |
| BlockSRAM使用率 | 145 / 340 (43%) |
| SNESコアFmax | 50.1 MHz |
| 論理合成・配置配線時間 | 416 sec |
| FPGAデータ・コード | Tang Retro Console 138K 用FPGAデータ（GitHub） |
サウンドがHDMI直なので多少のノイズがあり、フィルタ回路を実装した方が良さそう。
おわりに
Gowin EDA については、 ファイルパスは絶対パスじゃなく相対パスで管理して欲しい。 あとFPGAデータ生成完了したら音を出して欲しい。
簡単なテストHDLでも、ボードによって動いたり動かなかったりするのは品質にばらつきがあるのかな？
Tang Nano 60K の発売待ってますよ！SipeedさんTang Console 60K/138K が出ました！ありがとうSipeedさん（読みはシペード？）。
移植について
Tang Nano シリーズへの NES on FPGA の移植を通じで、その移植性、 つまりSFLから生成されたVerilogHDLの移植性の高さ、 もしくは Gowin Synthesis の十分な性能を感じることができた。 ゲーミングFPGAボードと言っていいのか分からないけど、 とりあえず SNES on FPGA も動いたのでまんぞく。NESコアとSNESコアは、どちらもクロック１つの完全同期設計であることと、 CPUがマイクロプログラムベースではないためBlockSRAMを使わないで済むことも 移植が容易だった要因だろう。
HDMI-USBキャプチャ
DVI出力をPC画面に表示できるので、デバグするのに非常に役に立った。 DVI_DE信号を見ているようで、通常のモニタではサポートしていない低い解像度でも表示してくれて、 2,500円程度（2023年11月時点）でコスパが良い。 買うならUSB3.0 1080p@60HzをサポートしているMS2130チップを搭載しているものがお勧め。しかし初期実装でHDMI用のピンアサインが中途半端で変な出力してたせいか、 通常時30℃くらいなのが50℃くらいになりノイズが乗って壊れそうになったことがあったので、 そのあたり気を付けましょうという事で。2,500円の中華製HDMI-USBキャプチャなかなか良くて小型モニタいらないね。TangNano4Kのカメラデモ普通に映ってるし。MS2130っていうチップ使ってるらしいhttps://t.co/3lgboU3VvK pic.twitter.com/YpjplBOXou
— かんな丸！！ (@pgate1) 2023年11月7日