会社案内 (近況 2008/05)

2008/05/28 東京都南部にいってきます (川井)

25日には「だいたい動く」状態になったが、なかなか「完全に動く」状態に達しない。 PIO write を大量に発行するとホストがハングする。

すげーあちこち調べたが、結局 2 つの TLP が間髪入れずに届いたとき、TLP を解析するステートマシンが 2 個目の解析に間に合わないのが原因だった。 x1 のときは平気だったが、x4 になって CRC 計算の latency が増えたために 間に合わなくなってしまったのだ。

そこの回路を pipeline 化すれば良さそうだということまでは分かったが、所 用 (休暇ともいう) で本日 09:00 のおがさわら丸に搭乗せねばならず、現在 時刻は 05:00。朝の通勤ラッシュが始まる前に竹芝に着いておかないとエラい ことになるのでこれ以上のデバッグは諦めた。徹夜イクナイ。それでは皆さん、 来月 10 日までごきげんよう。

2008/05/19 PCIe IP コア開発 (川井)

コア開発もいよいよ大詰め、x8 に着手。データパスに関連する回路モジュー ルだけいじれば良いので大した手間ではない気もするが、実際のところはどうか?

PHY 層の Deframer/Framer では少しややこしい処理が必要:

x8 Deframer:

• DLLP が 1clk に 3 個届く可能性がある。
  • SDP は 1 symbol time につき 1 個しか送出してはならないと PCIe Base Spec. で規定されているが、コアは 1 clk に 2 symbol time ぶんのデー タを受けるので、SDP が 2 個届くこともあり得る。
  • 1 個目の DLLP の後半、2 個目全体、3 個目の前半、という組み合わせ で、最大 3 個の DLLP (の一部分) が 1clk に同時に届くことがあり得る。
• 複数の TLP, DLLP を密着して送る場合は STP, SDP は lane 4N に置く。 1 個目の TLP, DLLP は必ず lane 0 から始まるが、2 個目以降の TLP, DLLP は lane 0 から始まるとは限らない。

つまり SDP, STP は 0L, 4L, 0H, 4H のどの lane に来る可能性もある。END, EDB は 3L, 7L, 3H, 7H のどの lane に来る可能性もある。いずれの組み合わ せで届いた場合でも正しく受信できねばならない。

x8 Framer:

• END が最後の lane 以外にあり、なおかつ次の STP や SDP が密着して いない場合、END から最後の lane までを PAD で埋める。

2008/05/17 PCIe IP コア開発 (川井)

コアのバックエンドに GRAPE-7 用の G5PIPE を実装したら、ふつーに重力計 算できた。すげぇ。

ここらで転送速度もみておこう。

DMAW 性能
   1kB   100MB/s
   4kB   270MB/s
  16kB   540MB/s

ある DMAW の終了から次の DMAW の開始までの idle time : 約 900clk。
ひとつの DMAW burst の内訳 :
   payload 256B               : 32clk
   latency                    : 15-20clk
   効率                       : 32/(32+19) = 63%
転送量 4kB の DMAW 全体の効率 : 32*(4096/256) / ((32+20)*(4096/256)+900) = 33%

idle time 900 clk を減らせないか?

DMA 終了判定のための polling の頻度が低いため、750clk くらい余分な待ち が入ってしまっている。PIO read で local register を見にゆくのをやめて、 main memory を polling すれば、つまり main memory 上の DMAW buffer の 最後の値が書き換わったら DMA 終了ということにすれば、もっと速くなるか もしれない。

劇的に速くなった。
     1kB   350MB/s
     4kB   530MB/s
    16kB   630MB/s
idle time : 約 180clk。

さらに効率をあげるには、max payload size を増やすのが手っ取り早い。 max payload を最大値 (4kB) にすれば転送量 4kB でも 720MB/s 出るはず。 あとは 15-20clk の latency は妥当な値なのかどうかも要検討。

ついでに PIOW 性能
     1kB   705MB/s
     4kB   690MB/s
    16kB   693MB/s

なぜこんなに速い? 要調査。

2008/05/16 PCIe IP コア開発 (川井)

これまで GRAPE-7 で使っていたインタフェース回路の新コア版を作った。 local register の mapping と、PIO write を write-combining モードで正 しく動作させるのに必要な double buffer の実装が主な作業内容。

PIO write と DMA write が出来たので loopback テストを行えるようになっ た。コアのバックエンドにメモリを置いて、ホストから PIO write を使って そこに適当なデータを書き、それを DMA write で送り返す、というテストを 行った。いくつか細かいバグを直したらちゃんと動くようになった。

2008/05/14 PCIe IP コア開発 (川井)

それなりに苦労したが、ここ 1 週間で DMA write が動くようになった。PCI や PCI-X のコアなら多分 DMA engine の設計が最難関なのだろうが、PCI Express だと難関だらけで DMA engine が特別に難しいという気はしなかった。 慣れとはおそろしいものだ。

2008/05/07 PCIe IP コア開発 (川井)

PIO write で転送しているデータが正しいかどうかチェックするには、コアが 受け取ったデータをホストへ送り返し (loopback)、ホスト上で送信したデー タと受信したデータを比較するのがよいだろう。そのためにはコアからホスト へのデータ転送機構が必要。

PIO read (Target Memory Read) なら実装ずみだが、これは速度が遅いのでこ れまでの回路ではレジスタのステータス読み出しにしか使用してこなかった。 データの転送には DMA write を使っていたので、今回もやはり DMA write を 実装すべきだろう。

2008/05/06 PCIe IP コア開発 (川井)

x4 での PIO write が発狂する問題を解決した。上流から受け取った TLP に 対する受領通知 (Ack) を返すのが遅れると、上流は送信に失敗したと判断し てその TLP を再送してしまう。再送されてきた TLP をコアの Data Link 層 が受け取って、そのまま Transaction 層に渡してしまうと、同じデータが 2 回届いたことになってしまう。また credit のカウントもおかしくなってしま う。

• 再送されてきた TLP は破棄する。
• TLP を受け取ったら CRC チェックせずにさっさと Ack を返す。

ようにしたらちゃんと動くようになった。CRC チェックは PCI Express の仕 様上は必須だが、実用上は不要。CRC を 1 回目だけ間違って、再送された 2 回目では合うような、そんな不安定なハードウェアは設計しないのが王道。

2008/05/04 PCIe IP コア開発 (川井)

Altera の出してる CRC 生成用の IP コアをちと調べてみたら、これの throughput は Stratix II で 15Gbps だった。x8 を実現するには ArriaGX で 16Gbps 必要なので、この IP では無理。やはり Walma の algorithm を使 うしかないか? ロジック消費を抑える改良が必要だなぁ。

2008/05/02 PCIe IP コア開発 (川井)

x4 での PIO write もだいたい動くようになったが、大量に write すると発 狂して、以降 Configuration Register の値もおかしくなる。