仕事用PCI-Xモジュール

今日は仕事用のPCI-Xモジュールについて、ちょっとだけ書こうと思う。(あまり書くとまずいので。。。)
最初にホストのパーソナル･コンピュータ(PC)からPCI-Xボードのリソースにアクセスする機能をターゲット機能、逆にPCI-Xボードがパーソナル･コンピュータ(PC)のリソースにアクセスする機能をマスタ機能と呼ぶことにする。
PCI-Xの規格ではターゲット機能を使用して、ホストPCからPCI-XボードのSDRAMのデータをリードしようとするときに、PCI-Xボードがデータを用意できるならば、トランザクションが始まってから16クロック以内にデータを出力する必要がある。なお、すぐにリードするデータを返せない場合は8クロック以内に応答を返す必要がある。これはリトライやスプリット応答などが相当する。

ここでリトライとスプリット応答について説明すると、リトライはPCIの時代からあるもので、”後でもう一度アクセスしてね。。。”とマスタ（PCI-Xではイニシエータ)にお願いするもの、スプリット応答は”今はリード・データが用意できないけど、データが用意できたら、こちらからそちらにデータを送ります。（書き込みます、これがスプリット完了)”というものだ。

133MHz動作で16クロック以内にデータを用意できる (PCI-Xの仕様) 確証が無いため、トランザクションが始まってから8クロック以内にスプリット応答を返して（これもPCI-Xの仕様）、後からスプリット完了でリードするはずのデータをホストPCに送ることにした。ただし、コンフィギュレーション･アクセスは間に合うので通常にリードする。
そうなると、スプリット応答したトランザクションのテーブルが必要になる。後で、データが用意できたら、ターゲット･リードではあるが、マスタ機能を使用して、リード･データをホストPCに送る（これはいわばマスタ･ライト）。つまり、ターゲットのアクセスではあるが、マスタの機能を使用する。
PCI-Xボードがマスタ機能を使用して、ホストPCのリソースをリードする場合も、ホストPCからスプリット応答を返されることが多い。その場合は、ホストPCのリード･データはスプリット完了として、PCI-Xボードへのターゲット・ライトとして実行される。
スプリット完了の場合は、コマンドやアドレス、アトリビュートがスプリット完了専用になる。このように、PCIで機能わけされたモジュール（ターゲット、マスタ）はたすきがけで使用される。
下にPCI-Xモジュールのブロック図を示す。こんな感じになっている。PCI-Xモジュールの外部へはクロックが異なるので、非同期FIFOを使用する。


結構、PCI-Xも大変なものだ。スプリット応答したテーブルを参照しなくちゃいけないし。。。

PCI-Xモジュールのその後

このところ日記が続いてしまったが、それだけでもなんなので仕事の話を。。。
今のところ、以前やっていたPCI-Xテストモジュールを下敷きにPCI-Xモジュールを書いている。
いざ書き始めると、いろいろな疑問や仕様策定上の迷いが生じる。主なものは下のような疑問だ。

・未解決のスプリット転送用バッファのエントリをいくつにしようか？
・PCI-Xのターゲット・リードに対して、どのデバイスの応答をスプリット転送にするのか？
・PCI-Xのターゲット・ライトのときに、アトリビュート･フェーズでターゲットに通知される転送数分の空きバッファが無いときにはどうするか？（結局これは128byte単位のアドレス（Allowable Disconnect Boundary)でバッファの空きに応じてディスコネクトすることにした。）
・前のADBでディスコネクトする場合、ターゲットはADBの前で4クロック以上STOP#をアサートする必要があるが、4クロック以上ならば何クロックでも良いのか？

これらを解決しながら、書き進めている。
でも、他の仕事もあるので、なかなか進まない。気力も充実してきたので、がんばって書き進めようと思っている。
書き進めているVHDLコードには、このブログの”アサーション事始め”で練習したような簡単なアサーションを組み込んでみたりしている。
さらに、VHDLなので”Doxygenを使ってVHDLソースコードをドキュメント化してみました”を例にDoxygenでソースコードをドキュメント化しながら書きすすめている。Visioで書いたブロック図などもPNGに変換してドキュメントに加えることができるし、リファレンスとして重宝している。

皆さんも、ソースをVHDLで書いているならば、DoxygenでVHDLソースをドキュメント化してはいかがだろうか？　少し面倒だが、素敵なドキュメントが一緒に出来上がると思う。

PCI-Ｘスプリット完了（その後）

PCI-Ｘスプリット完了のバグが解決した。
1つ目の”ホストPCがNMIを受信してしまい、You probably have a hardware problem with your RAM chipsと表示が出る”というのは、パリティが間違っていて、パリティエラーが起こると、この表示が出るようだ。パリティのHDLコードを見直したところ、バグがあったので修正したら、このメッセージは出なくなった。
2つ目の”ダンプデータが0番地（ボードのアクセス番地は4）は0、4番地（ボードのアクセス番地は0）は6、8番地は0、C番地は8。１つおきにデータが取れていない”というのは、スプリット完了の際にアドレスフェーズのAD[6:0]でスプリット応答したときのLow Addressを返していたのだが、よくよく仕様書を読んでみるとDWORD読み出しのときのアドレスフェーズのAD[6:0]は0にしろと書いてあった。それで0のときしかだめだったのか？AD[2]は何か他の事に使っているようだ？0に修正したところ、全部データが読めるようになった。
下の図は、ちゃんと読みだせたときの波形。


XカーソルがホストPCからのDWORDリードのアドレス、D8000004だけど、Oカーソルの位置のスプリット完了のアドレスフェーズでは0にした。ちなみにOカーソルのところのデータのうち、Fはタグ番号。

＃　1つ目のバグ（パリティ)は、昨日、お風呂に入っているときに思いついた。何気なくしているときやお風呂掃除などをしているときに、ふと解決法について思いつくことがあるのだ。

PCI-Ｘスプリット完了

ホストPCからPCI-Xターゲット・アクセスをしてきたときに、内部レジスタ以外はスプリット応答で返すことにした。その際に、PCIマスタ・モジュールを用いて、スプリット完了を64ビットアクセスで返したところ、ホストPCがNMIを受信してしまい、You probably have a hardware problem with your RAM chipsと表示が出てしまった。
ダンプデータも0番地（ボードのアクセス番地は4）は0、4番地（ボードのアクセス番地は0）は6、8番地は0、C番地は8。１つおきにデータが取れていない。
これがChipscopeで撮った波形。


最初のアクセスがTRDY#='0', DEVSEL#='1', STOP#='1'で応答しているのでスプリット応答、その次のアクセスのC/BE＃が"C"で始まっているのでスプリット完了である。
最初のアクセスのリクエスタ・ファンクション番号は0、リクエスタ・デバイス番号は0、リクエスタ・バス番号は0。タグ番号は14。
ボードのファンクション番号は0、デバイス番号は2、バス番号は4。

スプリット完了時のアドレスフェーズのC/BE#はC。Split CompletionなのでOK。タグ番号は14、リクエスタの３つの番号は、0,0,0、ローアドレスも4でOK。(14000004)
アトリビュートフェーズのC/BE#は0。ファンクション番号は0、デバイス番号は2、バス番号は4。ビット29,30,31も0でOK。(00041004)
その後、データフェーズでC/BE#が0になっていて、オール1に保持されていないのは問題だ。（修正予定)

やはり、データフェーズでC/BE#をオール１にしても、ホストPCがNMIを受信してしまい、You probably have a hardware problem with your RAM chipsと表示が出るのは変わらない。



どうやら、Memory read DWORDに64ビットアクセスでスプリット完了を返すのは問題があるのかもしれない。そうではないようだ。32ビットアクセスでやってみたが同様にだめ。
1つバグがあった、下の図で、pcix_req_b_cがピンクの矢印で、いったんリクエストが解除されている。これは、PCI-Xマスタ転送メイン・ステートマシンがバグでバス・パーキングの状態になってしまったためである。このバグのためにスプリット完了トランザクションがなくなってしまっていた。
バグは解消できたが、まだNMIがかかってしまう。

2007年度の技術報告書（PCIバス・インターフェース回路）

昨日、2007年度の技術報告書が一応書きあがった。今年は、私の自作したPCIバスのインターフェース回路について書いた。64bit, 66MHzのPCIモジュールだ。
ターゲット機能としてはシングル転送だけをサポートしている。ホストPCからのコマンドを受け取るだけといったところだ。バースト要求が来てもディスコネクトする。つまりバースト転送するときは、ホストPCのDMAコントローラは使用しないということだ。
マスタ機能は、バースト転送が出来るようになっている。FPGA内部バス（64ビット幅）からのデータを64ビット、66MHzでホストPCのメモリにバースト転送する。（当然逆もできる）FIFOにデータをためてから、FIFOに入っている分だけ、PCIマスタで転送するようになっていて、最大のバースト長は256ロングワード（64ビット幅)だ。DMAチャンネルは2チャンネル。ブロック図はここ。（ブロック図が間違っているところがあるが、ご愛嬌）
PCIマスタ機能は、PCIの仕様によると、相手が32ビット幅のトランザクションにしか対応していないときは、32ビット・アクセスに切り替えなければならないが、私のPCIモジュールはそんなことはしない。そうだと、どうせ性能が出ないので、ホストPCの方を64ビット、66MHｚ対応に変更する。
PCIマスタはリードとライト機能が同時に使えて、（つまりFPGA内部バスから同時に対応FIFOに読み書きが出来る。FPGA内の内部バスは2本ある。）PCIモジュールでアービトレーションを行い、出来るほうから処理を行う。実はもう1本PCIモジュールを使うパスがあるので、合計3つのFPGA内部デバイスから同時に使うことが出来る。
いまさらPCIということだが、PCI-Xはまだ出来かけなのでしょうがない。
問題は、同じようなことをやっている人がいないので、発表は技術報告書の内容で発表しても、誰もわからないということだ。したがって、もっと一般的な内容にしようと思っている。
パソコンのBIOSがどうやってPCIボードを認識して立ち上がるか？どうやって、プラグ＆プレイしているか？といったような一般的な内容にしようと思っている。一部推測が入ってしまうが。。。
なかなか、ほかの分野の人も聞いて、わかったような気になってもらう内容にするのが難しい。

DDR2-SDRAMの方は、Spartan3E Starter Kit用のDDR-SDRAMコントローラをVirtex4に載せ換えて、性能を見ているが、今のところクリティカルパスが6ns程度になっている。ということは166MHz動作なので、DDR332しか動作しないということだ。チューニングをしながら、DDR2の勉強をしてDDR2用に変えていこうと思っている。
2007/12/07 追記：クリティカルパスはPicoBlazeの部分でした。DDR-SDRAMコントローラ本体は問題ありませんでした。
なにかDDR2-SDRAMコントローラが出来たときに、つなげるIPはないかな？PowerPCがEDKなしでつかると良いんだけど。どうやればよいか調べてみよう。

PCI-Xのスプリット完了（１Kbyte)

昨日は、ホストパソコンのメモリ1Kbyteをバースト・リード (マスタ･アクセスでPCI-X Memory Read Block) してみた。今まで同様に、スプリット応答(TAG番号0）が返ってくる。スプリット完了トランザクションでデータが帰ってくる前、または途中で、次の1Kbyteのバースト・リードコマンドを発行して、スプリット応答(TAG番号1）で返された場合、512byteごとに分割されて転送されてしまった。
TAG番号0のリードデータが、最初のスプリット完了トランザクションでターゲット・ライトされるが、512byte転送したところで、次のTAG番号1のリードデータのスプリット完了トランザクションが始まってしまう。TAG番号1のリードデータのスプリット完了トランザクションが512byte分終了したところで、次に、TAG番号0のリードデータの残りの512byteが転送された。


上図のXカーソルのトランザクションはTAG番号1だが、その後ろのOカーソルのトランザクションはTAG番号0。
このチップセットでは、512byteごとに、順番が入れ替わってしまう可能性があるため、512byteごとにリードしないとだめなようだ。
PCI-Xの仕様書を見ると、複数スプリット応答していると、帰す順番は任意だと書いてある。順番を守る必要があるならば、一度スプリット完了のトランザクションが終わってから、リードを発行しろ、と書いてある。

覚書
BIOSがPCI-Xコマンド・レジスタに書き込んでいるか？ No.
BIOSがPCI-Xコマンド・レジスタを読み出しているか？ No.　(PCI-X Capability ID(0x07)とNext Capability(0x00, 終了）のみリード)
BIOSがPCI-Xステータス・レジスタを読み出しているか？ Yes.

チップセットのPCI-Xスプリット完了トランザクション

PCI-Xマスタ・アクセスで、512byteをバースト読み出ししてみた。そうすると、例によってスプリット応答が返ってきた。
チップセットからのスプリット完了トランザクションはADB(Allowable Disconnect Boundary, 128byte) ごとにイニシエータが中断した。
この辺が疑問だったのだ。512byte分を全部、チップセットにバッファリングしてから一気に出すのか？　それともイニシエータ中断しながら、出すのかが疑問だった。スループットを捨てて、レイテンシを取っているようだ。レイテンシは約1usec。当然、以前の32byteの時の750nsに比べて伸びている。128byteのデータをキャッシュして出しているか、それとも送れる見込みができてからスプリット完了トランザクションを出しているからなのだろう。何しろPCI-XはPCIと違って、128byteごとにしかトランザクションを中断できない。
最初のスプリット完了トランザクションはアトリビュート･フェーズで、512byte分のバイト･カウントを通知している。中断した後の2つ目以降のスプリット完了トランザクションは、当然バイト・カウントを適合させている。（次は512(0x200) - 128(0x80) = 384(0x180)ということ）

注：PCIでは、例えばホストパソコンのメモリをリードするときに、規定時間以内でリード・データが用意できないとリトライをしていた。リード・データが用意できない間は、何度でもリトライを繰り返してしまうために、パスの使用効率が落ちてしまった。PCI-Xはそれを避けるために、なるべくリトライを使わずに、リードを要求するトランザクションにちょっと待ってて後で返事するよ（スプリット応答）と言って、後でデータを要求元にライトする（スプリット完了トランザクション)ようにした。

次は、Maximum Outstanding Split Transactionsがいくつかを探る。