会社案内 (近況 2008/03)
先月 翌月Rx にいろいろなタイプのパケットを与えたとき、すべて正しく解析して Transaction 層の上部へ出力できるか、シミュレータで確認した。急がば回れ な大人的仕事。
リンクアップして (つまり L0 に入って) しばらくすると、上流が勝手にリン クを切ってしまう。現状では DL_Active になったあと、Tx に特に送出すべき データが無いときには Logical Idle を送り、そこに定期的に SKP ordered set をはさんでいる。が、PCIe の仕様では SKP だけでなく UpdateFC も時々 送るように規定されていた。UpdateFC 送出機能を実装したらリンク切れは無 くなった。
Ack/Nak DLLP 送出を TLP 1 個ごとに行うのではなく、ある程度 TLP を 貯めてから行うようにした (無駄な通信を減らすため)。
host を reboot したら、ホストの Root Port から今まで見たことのない TLP が届いた:
STP 00 01 04 00 00 01 00 c0 00 0f 02 00 00 00 af 4f 14 fc END
パケットの内容は Configuration Read Request だった:
STP 00 01 Seq#=0001 04 00 00 01 header (3DW w/o payload, CfgRd0, TC=00, length=1). 00 c0 00 0f header (requesterID=00c0, tag=00, last/1stBE=0f). 02 00 00 00 header (bus=02, device=0, function=0) af 4f 14 fc LCRC END
この request に対して completion を返すには以下の機能が必要。
Transaction 層のさらに上に Application 層 (一般ユーザ向けのユルい層) を用意して、Transaction 層への target read/write 線は全部ここに出すこ とにしよう。Configuration Register は Transaction 層ではなくこっちに実 装するほうが良いかも。
Data Link 層から上は、いきなり多レーンを実装するのは難しそう。まずは x1 で software layer まで動かすことを目標にしよう。
TLP の deframing (LCRC をチェックして Ack/Nak DLLP を送出。パケット本 体を Transaction 層へ渡す) を実装した。Ack を返すまでは上流から同じ TLP が数回 (3 回?) 再送されてきていたが、Ack を返すようにしたら再送が 無くなった。これはつまり、上流が Ack を受け取ってくれたということだろ う。
しゃちょーにお願いして PCI-SIG のメンバになってもらった。Vendor ID 1B1Ah をもらった。 仕様書 (PCI Express Base Specification) ダウンロードし放題。わーい。
Data Link 層に実装すべき機能を整理した。いずれも TLP が届かないと動作 しない機能なので、Transcation 層の実装と並行して行うこと。
上流から DLL パケットが送られてこない問題を解決した。えれーハマった。
scrambler の初期化タイミングがおかしいのが原因だった。PHY 層のリンクト レーニング終盤で Tx の scramble を開始するときに、COM を送って相手の scrambler のタネと自身のそれとを同期する必要がある。そうしないと Logical Idle (00h) を送っているつもりでも相手がそれを正しく descramble できない。
DL_Active ステートに入ったら上流から Transaction Layer packet (TLP) が送られてきた:
STP 00 00 74 00 00 01 00 c0 00 50 00 00 00 00 00 00 00 00 00 00 00 00 75 76 56 23 END
パケットの内容は Slot Power Limit という種類のメッセージだった (message code 50h):
STP 00 00 Seq#=0000 74 00 00 01 header (4DW w payload, MsgD local. TC=00, length=1). 00 c0 00 50 header (requesterID=00c0, tag=00, MsgCode=50). 00 00 00 00 header (not used). 00 00 00 00 header (not used). 00 00 00 00 payload (not used). 75 76 56 23 LCRC END
依然として DLL パケットが送られてこない。SKP ordered set の送出機能、 lane-to-lane deskew 機能も実装したが、関係ないみたい。
Data Link 層初期化シーケンサと、ついでに framer/deframer も作った。し かし LTSSM が L0 に入っても上流の Rootport から DLL パケットが送られて こない。
ようやく Data Link 層に着手。まずは初期化シーケンサを作るところから。
先日の問題は Signal Tap II で観測する線が多すぎると発症するらしいとい うことが分かった。なぜそうなるのかは不明だが、PHY PCS, PHY PMA まで x4, x8 で動くようになったので、とりあえずこれで良いことにする。
Data Link 層にゆく前に PHY 層を多レーン化することにした。 そうしないと DLL-PHY 間のやりとりをどう実装すべきかよく分からない。
上位層には PLDA のコアを使い、自作 PCS, PMA sublayer 部分を 多レーン化したら動かなくなった。なんで?
ようやく L0 ステートに到達するようになった。 L0 ステートというのは要す るに、トレーニングがうまくいったので使っていいよ状態。結局 1 週間かかっ た。
Tips: Signal Tap II で観測したいのに optimize out されてしまう信号線が ある場合には attribute keep を使う。同様に、register の optimize out 防 止には attribute preserve を使う。
例)
attribute keep : boolean;
attribute keep of trigger : signal is true;
とりあえず x1 のリンク確立に必要な最低限のトレーニングシーケンスを書き 出してみた。な、なげぇ。きょ、今日はこれくらいのところで勘弁してやろう。
LTSSM (Link Training Sequence State Machine) を作り始めた。こいつは電 源投入時やリセット時に PHY 層レベルのリンクを確立するためのステートマ シンである。コアが上流の Rootport とお互いの情報をやりとりして、通信に 使うリンク幅や転送速度などを決定する。この過程をリンクのトレーニングと 呼ぶ。たぶん LTSSM 作成が PCIe コア開発の最初の山場だろう。
トレーニングについては社長が持っていたPCI Express System Architectureにそこそこ詳しく書いてあった。これに従っ て実装すれば動くかも。
ところで今のところ参考にしている文献は上記の他には PCI Express 入門講座だけなんだが、たったこんだけの資料でコア作るってどうよ。
scrambler/descrambler を作った。CRC 回路のときと同様、いきなりやらずに、 C でエミュレータ書いてから VHDL を書いた。オレ偉い。
PHY 層の下のほう (PCS, PMA sublayer) を、PLDA コアについてくるものから 自作のものに置き換えた。Gbit トランシーバの wrapper (alt2gxb) は Mega Wizard で生成できる。あとはそれの power on reset 線を PLL のロック状態 とかをみて制御する。トランシーバの仕様書読むのが面倒だが、それは先月別 件で済ませてあったので、さほど手間取らなかった。
どうやら動いてるぽい。リセットのタイミングなんてちょっとくらい間違って いても動いてしまうだろうから、回路が厳密に正しいかどうかは分からないが。
社で購入して使っている PLDA のコアがあるので、こいつの挙動を Signal Tap II で観測してみようと思い立った。購入したのはソースコードは読めな いライセンスなので (というかソースをいじれるライセンスなんて、見積りと るのもおそろしいような値段だろう) コア内部は観測できないが、PIPE イン タフェース部分は見えるはず。
で、観測してみた。DLLP パケットらしいものが上流の Rootport から届いて いるが、scramble されているので意味がわからん。(de)scrambler を作って 出直しだ。