特殊電子回路のドメイン「tokudenkairo.co.jp」を取得しました！
"tokuden"のうしろに"kairo"がつきます。
まだ何もサーバにアップしていないので、tokudenkairo.co.jpに行っても何もありません。
今後、１年くらいかけて、nahitechから徐々にtokudenkairoに移行していこうと思います。
今までのnahitech.comのメールアドレスやWebサイトは、
しばらくの間は、そのままでもアクセスできるように残しておく予定です。
某社に注文していたプリント基板が届きました。
やはり日本国内で製造されたプリント基板は質が良いです。
金フラッシュ仕上げにしたので、金ぴかです。
部品の実装は実装屋さんにお願いしたいところですが、
急ぎなので、手作業でつけています。
１枚につき、FPGAが4個。1005サイズのパスコンが200個。1005×4個の集合抵抗が100個くらい。
金メッキはスズめっきより半田ののりがわるいような気がします。
やはり、同種金属のほうが相性がいいのでしょうか。
それともGNDの放熱が良すぎて半田鏝の熱が奪われているだめでしょうか。
今日は、皇居東御苑に行ってきました。
皇居東御苑というのは、江戸城の本丸や天守台があった場所です。
皇居外苑や北の丸公園などとともに公園として一般公開されています。
東京のど真ん中なのにとても静かで、かつ、パワー溢れるスポットです。
地下鉄の竹橋駅から歩いて５分くらいのところにある北桔橋門から入りますと、旧江戸城の天守台跡が大迫力です。
さて、カンザクラが綺麗に咲いていました。
今日は風が強くて寒かったのですが、本丸跡の芝生の上に座ると、なぜだか不思議と暖かいのです。
そういえば、２月の始めに来たときにも、何本かカンザクラが咲いていました。
今日はPCI Express IPコアとは別に、DDR2 SDRAMのコントローラを作っています。
使っているSDRAMは、エルピーダのEDE5116ABSEというものです。
Virtex4用にDDR2 SDRAMの制御回路をざっくり書いて、実機にFITして動かしてみたのですが、論理合成するたびにDQSの信号をハイインピーダンスにするタイミングなどが若干変わってしまったり、FPGAの出力DDRプリミティブからデータを出力するときに、望んだタイミングに出てこなかったり、という具合でした。
どうやらFPGA内部のロジックセルや配線による遅延による影響が無視できない回路になっていて、ハイインピーダンスにするタイミングなどに問題が生じていました。
これでは、クロック速度に依存してしまう設計になって、よくありません。
というわけで、今夜は家に持ち帰って、詳細なタイミングを書き出して検討しています。
DDR2 SDRAMはだいたい125～400MHzくらいのクロックで動作します。FPGAの内部も同じく125～400MHzくらいで動かすことになります。データ転送レートはその2倍になります。一般的には、データレートは300MHz～666MHzくらいで動かすことになるでしょう。
ですが、DDR2 SDRAMといっても、中身はただのDRAMです。
バンクをアクティブにして読み出してプリチャージして再びアクティブにする、というサイクルの時間は大昔のDRAMのころからあまり変化していないのです。
そのかわり、ただのDRAMとは違ってバースト転送やバンク切り替えができるので、これらをうまく使えば高速にアクセスできるわけです。
ところが、DDR2 SDRAMではバースト長が8までしか対応できません。1つのコマンドでバンクの中身を全部吐き出すということができないのです。
このことを考慮して、533MHzでの動作タイミングチャートを書いてみました。
４つのバンクを順にプリチャージ付きで、バースト書き込みする場合のタイミング図です。
DDR2 SDRAMを533MHzで動かすということは、クロックは266MHzなので1クロックは3.75nsです。
バンクをアクティブにしてからWRコマンドを入力するまでの時間、つまりtRCDは15ns以上なので、4クロック後にしなければなりません。しかし、DDR2 SDRAMでは、Additive Latencyという機能が追加されたので、3クロック目に入れることができます。そうすると、3クロック目に入れられたWRコマンドは実際には4クロック目に解読されて、6クロック目から9クロック目までデータを入力することになります。
書き込み完了からプリチャージまでは15nsあけなければならないので、プリチャージは最短で14クロック目のところになります。プリチャージから次のアクティブコマンドまでは15nsあけなければならないので、同一バンクを再度アクティブにするには18クロックかかることになります。
つまり、533MHz動作ならライトプリチャージでどんどんデータを書き込んでいった場合、18サイクルかかってしまいます。バンクは4つしかないですから、2サイクルのアイドル状態がでてしまいます。
これでは、実効レートが16/18=88%に下がってしまいます。
ただのSDR SDRAMの場合は、バンクを切り替えバーストさせながら切れ目なく読み出せていたので、ちょっと困惑です。DDR2 SDRAMというのはこういう感じなのでしょうか。
実効レートが下がるのを回避するには、どうしたらいいんでしょう。
例えば、バンクをオートプリチャージせずに連続してコマンドを与えていくとか・・。
考えてみれば、tWRとtRPがそれぞれ15nsかかるのが厳しい原因のようです。
これは仕方ないですね。
この制限のもと、「毎回ライト・プリチャージ」というしばりを加えて、タイミングチャートとにらめっこしながらパズルを解いてみると、400MHz動作ならばOKという結論になりました。
FPGAの中から外に出ると、およそ1～2nsくらいの遅延が生じるので、そのことを考慮にいれます。
上の図は400MHz動作ですが、見事なまでに綺麗なタイミングでアクセスできることがわかりました。
すべてのパラメータがぴったりと一致します。
ですが、バンクが頻繁に活性化したりプリチャージするので、消費電力が大きそうですね。
なんだか、オートプリチャージなしのバーストコマンドを与えるのがよいような気がしてきました。
最後に、DDR2 SDRAMは、DDR SDRAMと同様にDQSという信号があります。
DQSはクロックとほぼ同じ位相で出力すればよいのですが、FPGAから出力したデータ(DQ)をDDR2 SDRAMがサンプリングする点は、DQSのエッジであるため、DQSとDQは僅かにタイミングをずらさなければなりません。
とはいっても、DQSもDQSも、266MHzクロックをDDRして作る信号です。1.875nsごとに変化します。
DQが確定してからDQSのエッジまでの時間は、937.5psがベストです。
こういった信号を作るには、FPGAの内部で90度位相のずれたクロックを使う必要があります。
つまり、
0度・・DQSを変化(下げる)
90度・・DQを変化(データの表)
180度・・DQSを変化(上げる)
270度・・DQを変化(データの裏)
これを繰り返すわけです。90度というのは、266MHz(533)動作なら937.5psに相当します。
さて、これを単純にFPGAの中で
process(CLK90) begin
if(CLK90'event and CLK90='1') then
とか、プリミティブのODDRのクロックにCLK90を入れると、まず間違いなくタイミングエラーを起こします。
なぜなら、0度のクロックで作った信号を90度のFFでサンプリングするということは、4倍の速度で動けといっているようなものだからです。FPGAのクロックが266MHzならば、普通の信号を90度のクロックでサンプリングしなおすのは1066MHzで動くのと同じです。
これはさすがのVirtex4でも無理でしょう。
そこで、CLK0で作った信号を、CLK270を入れたD-FFでサンプリングし、CLK180を入れたD-FFでサンプリングし、CLK90を入れたD-FFでサンプリングする、というように3段のD-FFを入れる、というテクニックを使います。こうすれば、各D-FF間は270度分の位相のずれしか生じないので、何とかタイミングレポートが通るようになります。
ようやく、PCI Expressの初期化の手順が見えてきました。
というわけで、開発中のPCI Express IPコアに、コンフィギュレーションレジスタを徐々に実装しはじめています。
下の図は、初期化時におけるFPGA内の各種信号を、JTAGロジックアナライザでキャプチャしたものです。
まず、電源を入れると、アドインカードとマザーボード上のチップセットで通信をし、PCI Expressの物理層、データリンク層を初期化します。
最初に送られてくるパケットはロック解除のパケットで、その次は０番のコンフィギュレーションレジスタの読み出しです。
０番を読むのは、VID PIDを確認して、PCI Expressスロットにカードがささっているかどうかを確かめるためでしょう。
このように、送られてきたパケットをJTAGロジアナで解析して、時系列に並べると
-----------------
1 Message
2 ConfigRd 0x0000 (BE=1111) ベンダIDの読み出し
3 ConfigRd 0x0000 (BE=1111) ベンダIDの読み出し
4 ConfigRd 0x0008 (BE=1100) クラスコードの読み出し
5 ConfigRd 0x0008 (BE=1100) クラスコードの読み出し
6 ConfigRd 0x0034 (BE=0001) Capability Register Pointerの読み出し
IPコアは上記の読み出し要求に0x60を返す。
7 ConfigRd 0x0060 (BE=0011) MSI Cap.
8 ConfigRd 0x0070 (BE=0011) Power Management Cap.
9 ConfigRd 0x0080 (BE=0011) PCI Express Cap.を読み出し
10 ConfigRd 0x0090 (BE=1000) Link Statusレジスタを読み出し
11 ConfigRd 0x0090 (BE=0001) Link Controレジスタを読み出し
12 ConfigRd 0x0090 (BE=0001) Link Controレジスタへ書き込み
13 ConfigRd 0x0000 (BE=0011) ？？
・・続く・・
-----------------
こんな感じでした。
この手順を簡単に説明します。
まず最初に、マザーボード上のBIOSは、アドインカードのベンダIDを２回読み出します。
その次は、アドレス８番にある、クラスコード等を読み出しに来ます。
クラスコードというのは、アドインカードの種類を知らせる番号です。
もしPCI ExpressのスロットにささっているのがVGA互換のビデオカードならば、マザーボードに内蔵のビデオチップを無効にしてPCI Expressのビデオ出力を使うようにするため、BIOSの中でそういう処理をしているのでしょう。
次に、0x34番にある「Capability Register Pointer」というレジスタを読み出しています。
このポインタは、PCIで後から拡張された機能に関するコンフィギュレーションレジスタの位置を指し示すポインタです。
これはPCIではオプションだったようで、PCIではこのレジスタが存在するかどうかはステータスレジスタを読まなければならなかったのですが、PCI Expressでは必ず実装することになっています。したがって、BIOSはステータスレジスタを調べもせず、いきなり「Capability Register Pointer」を読みに来ます。
このレジスタには、まず、PCI Expressの割り込みの仕組みである「MSI」のためのコンフィギュレーションレジスタのポインタを指し示しておきます。今回開発しているIPコアでは、0x60番に配置しておきました。
すると、BIOSは今度は0x60番のコンフィギュレーションレジスタを読みに来ます。
0x60番には「Power Management Capability Structure」へのポインタを書いておきます。
「Power Management・・」は、今回開発しているIPコアでは、0x70番に配置しておきました。
で、0x70番には次の「PCI Express Capability Structure」へのポインタを書いておきます。
「PCI Express Capability Structure」には、アドインカードのリンク速度やらレーン数などの情報が格納されたレジスタなどが詰まっています。
BIOSは、このレジスタ群をみつけるまで、芋づる式にポインタをたどっていくようです。
そして、「PCI Express Capability Structure」を見つけると、BIOSの中のプログラムは、その中にあるリンク・ステータスレジスタを読んで、リンク・コントロールレジスタの中のCommon Clockとかビット(マザーボードとアドインカードのREFCLKが同じクロックで動いていることを示すビット)をセットします。
その後、BIOSはPCI Expressへのアクセスを停止し、しばらくしてからまた最初のようにベンダIDを読みに来ます。
ただし、アドインカードに割り当てられたPCI ExpressのBus番号が、１回目とは異なっているので、Enumerationに何か秘密があるのでしょう。
続きはまた後ほど解析して、紹介します。
今回の初期化時の波形をもっと詳しくごらんになりたい方は、「pciecap.jla」をダウンロードしてください。波形のデータファイルがダウンロードできます。
この波形は、無償の波形ビューワ「http://www.nahitech.com/support.html」か、またはMITOUJTAGの新機能Advanced JTAG Logic Analyzerで見ることができます。
引き続きPCI Expressの開発の続きを行っています。
前回は、最初のコンフィギュレーション・リード・リクエストパケットが見えたところまでいっていて、このリクエストに応答するパケットを送信することができれば、次の段階に進めるだろう、という予測で終わっていました。
というわけで、任意のパケットを送受信できるよう、さらにIPコアの開発を進めました。
言葉で書くのは簡単ですが、やってみると意外と大変です。
まず、PCI Expressは、すべてのTLPパケットが32bit CRCでがっちりガードされています。自作の回路で作ったパケットが、パソコンのチップセットで認識されるためには、このCRCを作る回路がどうしても必要になります。そして、Ack/Nackプロトコルを実装しなければなりません。Nackが帰ってくると再送処理をしなければならないので、まじめに実装するとなるとFPGA内のブロックRAMを消費してしまいます。フロー制御もそれなりにだましだまし実装することが必要です。
こういったデータリンク層回路の上に、トランザクション層のパケットの組み立てと分解の回路を作ります。
回路を作るというのは、具体的にはステートマシンを作ることになります。
このあたりを作りこんでいくと、「PCI Expressは、16ステート程度のステートマシンが数十個あって、それらが密に連携しながら動いているシステムである」ということがだんだんわかってきます。
そういった回路を作り上げることで、ようやくパケットを送受信する基盤ができあがります。
パケットを送受信する回路が出来上がったら、受信したパケットがコンフィギュレーションレジスタへの読み出しであることを判定する回路や、読み出し要求に対して答えを返す回路を作ってやらねばなりません。また、ステートマシンです。
こういったものは、第4層になります。
第4層になると、コンフィギュレーションレジスタがどうのこうのといった議論になるので、ようやくPCIっぽい話が登場します。このあたりからCPUが動いて、起動時になにやらPCIバスを叩いているのが見えてきます。
逆にいえば、PCI Expressって、コンフィギュレーション空間とかそういう概念はPCIを継承しているけれども、通信方式はまったくPCIと関係がないんです。DEVSELとかIRDYとかそういう信号は一切出てきません。
久しぶりにMITOUJTAGのWebサイトを更新しました。
今回更新したところは、JTAGロジックアナライザの使い方に関する説明ページと
http://www.nahitech.com/jtag/usage_jtag_logana.html
下記の機能紹介ページです。
http://www.nahitech.com/jtag/visbscan.html
http://www.nahitech.com/jtag/extest.html
http://www.nahitech.com/jtag/jtaglogana.html
JTAGロジックアナライザは、昨年の10月にアップデートしたのですが、新機能に関する説明のアップデートが遅れておりました。ご不便をおかけしたことを心よりお詫び申し上げます。
是非とも、FPGAの開発に、新しくなったAdvanced JTAGロジックアナライザをご活用ください。
多忙のため、PCI ExpressのIPコア開発を約１ヶ月ほど中断していましたが、先週の土日あたりから再開しました。
前回は、PCI Expressの物理層を初期化した後、第２層パケットや第３層パケットを作る段階になって、CRC生成が面倒だというところで中断していました。CRCを作るのが大変だったので、パソコン側から送られてきたパケットをそのまま何も処理せずにパソコン側へループバックすることで、PCI Expressのバスとしての挙動を調べていました。
今回、CRCを生成する回路を作り、第２層パケットを自由に投げられるようにしました。
PCI Expressの第２層のパケットには、Ack/Nack、フローコントール、パワーマネージメントなどがあります。今回はAck/Nackの実験をしてみることにします。
前回解析した結果では、PCI Expressの物理層の初期化が完了してリンクアップすると、次に第２層のフローコントロールの初期化シーケンスが動くということがわかりました。このフローコントロールが完了すると、パソコン側から第３層のパケット(TLPという)が投げられてきます。最初のパケットはメッセージパケットで、特に面白いものではありませんでした。
PCI Expressは、TLPを受信した場合、AckかNackで応答する決まりになっています。TLPの中にはCRCがあって、そのCRCが間違っていたり、シーケンス番号に異常があった場合には、受信側はNackで応答することになっています。
試しに、パソコン側から送られてきたTLPに、すべてNACKで応答するような回路を作ってみました。
・・嫌な回路ですね。
それをJTAGロジアナを使って、波形を観察します。
すると、
PCI Expressは、TLPを３回再送してそれでもNACKが返って来たら通信路にエラーが発生していると考えてリカバリーという処理を開始する、と解説書に書かれています。パソコンのチップセットは確かにそのように処理しているようです。
これでは先に進めないので、何でもかんでもACKを返すようにしてみました。CRCのチェックは、しなくてもいいでしょう。
最初のメッセージパケットをACKで応答すると、ついに
コンフィギュレーション・リード・リクエスト
のパケットが送られてきました。
苦節数ヶ月、ようやくPCIっぽいパケットが見えてきました。
解読すると、
(STP),(SEQ)=0001,(Hdr)=04000001,0000140F,05000000,(CRC)=10A89935,(END)
ヘッダ部の04000001の04は、「Config Type 0 Read Request」を表します。末尾の001は長さを示しています。
次の0000140Fの0000はRequesterIDを、14はTagという識別番号。0Fは32bitでアクセスすることを示しています。
その次の05000000の、05はPCIのBus番号、00はDevice番号とFunction番号、3バイト目の00は拡張レジスタ番号、そして4バイト目の00はレジスタ番号です。
どうやらコンフィグレーション空間の０番地を32bit幅で読み出す要求のコマンドのようです。
今はこのパケットに対してまだ何も応答していないので、パソコンは電源投入直後の真っ黒い画面のまま、ファンを全力で回してハングアップしてしまっています。CTRL+ALT+DELでも再起動できないほど深く固まっているようです。
パソコンは、起動した直後にPCI Expressの拡張ボードに対して、コンフィギュレーション空間の０番地を問い合わせるようです。これに応答しないとそこで固まってしまいます。ですが、固まってはいるものの、下の図のようなフローコントロール・アップデートパケットが周期的に送られてくるようです。
次に進むには、きっと、この読み出し要求に対して「コンプリーションパケット」を返せばいいのでしょう。
いよいよ面白くなってきました。
最近のコメント