最近使い始めたCmod A7ボード(FPGA)には、基板上に512KバイトSRAMチップがユーザリソースとして搭載されています。前回に引き続き、このSRAMをオリジナル16ビットCPUコアMoscoviumからアクセスできるように機能を追加して行きたいと思います。今回が完結編です。
ここまでの検討結果を踏まえて、外部SRAMユニット(SRAMC512K)の目標仕様を以下とします。
SRAMC512Kユニット目標仕様：
Moscoviumの16ビットアドレス空間は64Kバイトしか無いため、24ビット拡張アドレス空間にマッピングします(下図の通り)。
8MバイトもあったSDRAMと比べると、512KバイトのSRAM領域は、「たったの512Kバイト」なので、ずいぶんと狭い領域に見えますね。SDRAMは、動的記憶方式としたことで物理的なメモリセルサイズが小さくなり、集積度を格段に向上したメモリですから、メモリ容量でSRAMに勝ち目はありません。詳しくはこちらをご参照ください。
SDRAM 8Mバイトも、大きすぎて全く用途が無かった(思い浮かばなかった)ので、512Kバイトもあれば十分ですけどね（１＾＾；）。
設計検討段階で、SRAMアクセスに関してタイミング的な懸案事項が複数ありました。本節では、Vivadoのタイミングシミュレーションを実行して、SRAMのタイミング規定が順守できているかどうか？を確認して行きます。
Vivadoには、論理合成後(post-synthesis)または、配置配線後(post-implementation)のネットリストを使ってシミュレーションする機能があります。
配置配線後の最終ネットリストを使い、負荷付きのタイミングシミュレーションを実行しておきましょう。敢えて前置した「負荷付き」とは、「負荷(既成抵抗と既成容量)を考慮した」という意味です。一般的には、単に「タイミングシミュレーション」で同じ意味となります。
デザインのコンパイル(論理合成・配置配線)によって配線が確定すると、配線層の抵抗率と断面積および配線長から既成抵抗値は判るし、同様に、ある配線に着目した時、その配線層の上下、左右に隣接する配線層との距離や対向している面積などから、既成容量も抽出できます。
この辺りは、Vivadoが配置配線実行時に自動的に計算して抽出してくれています。いつも確認しているSTA結果も、こうして抽出した負荷を考慮して報告されています。
以上の通り、LSIの配線には必ず、既成抵抗と既成容量が付いています。既成抵抗と既成容量を考慮すると、抵抗R×容量C＝時定数τなので、LSIの配線を伝搬する信号には必ず、伝搬遅延が発生します。
この伝搬遅延時間を考慮してシミュレーションする事を(負荷付きの)タイミングシミュレーションと呼んでいます。
以下に、Vivadoを使ったMoscoviumマイコンのタイミングシミュレーション実行手順を示します。
タイミングシミュレーション実行手順：
「普段の論理シミュレーションと同様」とは、書いてみましたが、実は、シミュレーション自体、とても遅くなっているし、論理合成の最適化によって信号名が消えていたり、等、色々と「変わって」います。あんまり、好んで実施したいシミュレーションではありません。できれば、STAで決着できるような設計をしておくのが正解です。
タイミングシミュレーションのタイミング図(例)を以下に示します。
上のタイミング図で、上から中央下あたりまでは、Moscoviumマイコンの内部信号を表示してあります。下方に固まっている、sram_adr，sram_dq，sram_cen，sram_oen，sram_wenが、SRAMとのインターフェイス信号です。
クロックエッジと、信号の変化タイミングに注目すると、各信号の変化点がクロックエッジから遅延していることが判ります。アドレスやデータなどのバス信号線は、ビット毎に伝搬遅延時間が異なるため、クロックエッジから徐々に変化して確定して行く様子も見て取れます。
伝搬遅延無しの論理シミュレーションでは見られないタイミング図ですね。
デフォルトの負荷条件は、「slowコーナのsdfmax」なので、通常、セットアップタイミング側をチェックするパラメータと、なっています。まじめに全部チェックすると、(slow／fastコーナ)×(sdfmax／sdfmin)＝計4通りのシミュレーションを実施しなくてはなりません。「心配」の度合いで、どこまで実行するかは各自の判断です。パラメータは、「Flow Navigatorサブウインドウ ⇒ SIMULATION ⇒ 左クリック ⇒ Simulation Settings」で開く設定ウインドウで変更可能です。
※FPGAなんだから、条件は「typicalコーナのsdftyp」で良かったのだけど、そういう条件は選択できないみたいです。折角タイミングシミュレーションを実施するのなら、せめて、slow×sdfmax条件(セットアップ確認)と、fast×sdfmin条件(ホールド確認)の2通りくらいは実行して確認する事を推奨します。
SRAMデータシートのタイミング規格と照らして問題ないこと、CEN，OEN，WEN等のストローブ信号にグリッジが発生しないことなど、確認済みです。確認結果を以下表にまとめます。
| READ | SPEC | MIN | MAX | TmgSim | Judge | |
| tRC | Read Cycle Time | 8 | − | 39.3 | MET | |
| tAA | Address Access Time | − | 8 | 31.4 | MET | |
| tOHA | Output Hold Time | 2 | − | −7.9 | MET | |
| tACE | CEN Access Time | − | 8 | 30.7 | MET | |
| tDOE | OEN Access Time | − | 4.5 | 30.7 | MET | |
| tHZOE | OEN to High-Z Output | − | 3 | −9.1 | MET | |
| tLZOE | OEN to Low-Z Output | 0 | − | −2.4 | MET(←violation) | |
| tHZCE | CEN to High-Z Output | 0 | 3 | −9.5 | MET | |
| tLZCE | CEN to Low-Z Output | 3 | − | −2.4 | MET | |
| WRITE | SPEC | MIN | MAX | TmgSim | Judge | |
| tWC | Write Cycle Time | 8 | − | 40.0 | MET | |
| tAW | Address Setup Time to Write End | 6.5 | − | 24.0 | MET | |
| tHA | Address Hold from Write End | 0 | − | 16.7 | MET | |
| tSA | Address Setup Time | 0 | − | −5.8 | MET | |
| tPWE1 | WEN Pulse Width (OEN=HIGH) | 6.5 | − | 18.3 | MET | |
| tSD | Data Setup to Write End | 5 | − | 20.5 | MET | |
| tHD | Data Hold from Write End | 0 | − | 16.7 | MET |
※規格値とタイミング図との対応は、こちらの図で確認できます。
TmgSim欄には、タイミングシミュレーションのタイミング図から読み取った値を記載しました。結論としては、Judge欄がすべてメットしていて、問題なしです。なお、タイミング検証の結果、tLZOEが違反(バイオレーション)していたので、OEN端子にもタイミング制約を追加してメットさせました(以下制約)。
このタイミングシミュレーションですが、伝搬遅延無しの論理シミュレーションと比べてシミュレーション時間が長くなっています。しかも、コンパイル(論理合成・配置配線)を実行した時のROMデータでシミュレーションが実行されるため、プログラムを変更したら、もう一度、コンパイル(論理合成・配置配線)から実行し直さなくてはなりません。
コンパイル(論理合成・配置配線)には6分前後(デザインによってはそれ以上)かかるため、気軽に何度も実行する、と言う訳には行きません。実行するテストパタンは厳選しないと非効率です。
また、SRAMチップのビヘイビア記述(IS61WV5128BLL.v)が、アクセスタイミングチェック無しの動作記述となっているため、タイミング違反が有ってもシミュレーションは正常動作してしまう場合があることに留意してください。SRAMのタイミング規定を満たせているかどうか、タイミング図の目視チェックが必要です。
Cmod A7ボード搭載SRAMへのアクセスを実行する、SRAMC512Kユニットを搭載した新規型名NHOC113SR0408を起こしておきました。こちらのエディション表で、その他I/Oユニットの搭載状況を確認して見てください。
Cmod A7ボード用Moscoviumマイコンの設計データ(Vivadoプロジェクト)は、Githubで提供します。以下リンクよりアクセスしてください。
ダウンロード方法などについては、トップのREADME.mdをご覧ください。
デザイン(回路)をCmod A7ボードに書き込む手順については、こちらをご確認ください。
Vivadoでのコンパイル(論理合成・配置配線)結果を以下にまとめます。
コンパイル結果：
追加した出力遅延制約に違反が無いかどうかも、ここのSTA結果で確認してください。
拡張ERAMの動作検証用として作成した、Nihonium用のメモリマーチングテストプログラムを流用して、外部SRAMの動作検証を実行します。ERAMの時には、ロングワードサイズだけでしたが、バイトサイズとワードサイズのマーチングテストも追加しました。
データサイズ毎に、書き込みデータを定数で変更できるようになっています。プログラム先頭付近の以下定数定義で変更可能です。
equ mrch_byte0,0x00 // mrch: byte data
equ mrch_byte1,0xff
equ mrch_word0,0x0000 // mrch: word data
equ mrch_word1,0xffff
equ mrch_long0,0x0000_0000 // mrch: long data
equ mrch_long1,0xffff_ffff
マーチングテストのデータは、一般的に0(0x00)と1(0xff)が基本ですが、上コードの通り変更可能です。違うデータも書き込んでテストしたい場合は、定数を変更後、再アセンブル・再転送してください。
実験用プログラム：test_march_nh.asm
アセンブルしてMoscoviumマイコンに転送すると、シリアルモニタから以下のコマンドを受け付けています。
シリアルモニタコマンド仕様：
一般に、マーチングテストはRAM全面に対するテストパタンです。狙ったアドレスに、狙ったデータが、正しく書き込めない限り、テストは失敗します。実機(FPGA)でのアクセスタイミング検証も兼ねて、今回のSRAM動作検証には、ピッタリのプログラムだと思われます。
アクセス対象のSRAMチップはCmod A7ボードに備わっているので、外部回路などの追加は不要です。Cmod A7ボードをUSBでPCに接続して、実験を進めましょう。以下、実験中の様子です(写真は使い回し)。
実験サンプル：【 】内はシリアルモニタからの送信データ
【marchl,100000,180000】
OK: long marching (0x00100000~0x00180000,0x0004, 0x00035557[us])
【marchw,100000,180000】
OK: word marching (0x00100000~0x00180000,0x0002, 0x0005aaac[us])
【marchb,100000,180000】
OK: byte marching (0x00100000~0x00180000,0x0001, 0x000a5557[us])
バイト／ワード／ロングワードサイズの各マーチングテストを、外部SRAM 512Kバイト全面に対して実行しました。
バイト／ワード／ロングワードサイズでアクセスできて、読み／書きしたデータの期待値も合致、テストとしてはパスしています。設計した回路が正常に動作したと見て良いでしょう。
実験(動作検証)終了です。
Cmod A7ボードのFPGAチップXC7A35Tには、約200Kバイト分のRAMマクロが搭載されており、十分大容量です。それに比べて、8ビット幅でアクセスの遅い外部SRAM 512Kバイトは、ちょっと見劣りしますね。使い道として、高速アクセスが必要な用途には不向きですが、200KバイトのRAMマクロではメモリ容量が足りない用途が有れば、力になってくれる事でしょう。
