PCI Expressが動き出した！

ようやく、PCI Expressの自作IPコアが動き出しました。
開発における重要なマイルストーンを、何とか今年のうちに間に合わせることができました。

今回の実験では、XILINXのSpartan3 PCI Express評価ボードを使っています。
このボードはPhilippsのPX1101AというインタフェースチップをSpartan3から制御することでPCI Expressの機能を実現するというものです。

PCI Expressはよく、3層の構造で描かれます。
---------------------
| 　 トランザクション層
---------------------
| 　 データリンク層
---------------------
| 　 物理層
| 　 　FPGAの中
| 　 　PIPEインタフェース
| 　 　インタフェースチップ
---------------------

物理層を実現する「インタフェースチップ」は、主に8b10bの変換、シリアルパラレル変換などを行います。

この種のPCI Expressチップは、今回使用しているPX1101A以外にも、Texas InstrumentsのXIO1100など各社から似たようなチップが販売されています。こういったチップとFPGAとの間はPIPEと呼ばれるインタフェース規格を採用していますので、1つのチップで動くようになれば、他のチップにも同じように適用することができます。

これらPCI Expressのインタフェースチップは、要するにシリパラ変換ICにすぎないので、リンクを確立させるための初期化パケットなどは全部FPGAが作ってやらねばなりません。

下の図は、その初期化手順を実行している間の、FPGAの内部信号をMITOUJTAGを使って観測したものです。

なんだかいろいろな信号が飛び交っています。
これらはリンク初期化のためのいろいろなパケットを交換するための信号です。

PCI Expressは、リセットをしてから通常の動作モードに入るまでに、いろいろな初期化ステートを通ります。FPGAの中にそれらのステートを操るステートマシンを作らなければ、全く手も足もでません。

PCI Expressのステートについて簡単に説明すると、
・PCI Expressは、まずシステムをリセットしたら、まず12ms待って受信側チップが存在するか否かを調べます。これがDetectステートです。
・その次に、TS1というパケットを1024個送信し、逆に相手側からTS1が8個以上のTS1が受信できるか否かを調べます。このTS1にはCOMシンボル(K28.5)が含まれているので、ビット同期とシンボル同期が行われます。そういうわけで、1024個ものTS1パケットを送るわけです。その次に、TS2を送って互いの速度を確かめ合い、シリアルの線(TX+,TX-あるいはRX+,RX-)がひっくり返っていないかどうかを調べます。これがPollingステート。
・そしたら今度はTS1パケットの中のリンク番号とレーン番号をセットして、上流から下流に向かってパケットを流してそれを送り返します。一周したらTS2パケットに切り替え、TS2パケットも一周したら論理IDLEを流す。これがConfigステート。
・Configステートが送受信の両方で完了したら、晴れて通常の通信モード(L0)へ遷移します。

L0に移ったら、パソコン側(Intelのチップセット)はデータリンク層パケット(DLP)を送信してきました。

ようやく最初のDLPを見ることができました。
(上の図では、"K28.2 D0.2 D1.0 D0.0 D16.0 D27.7 D25.5 K29.7")

ユーザデータをやりとりできるようになるまでには、まだまだ先は長いですね。

いま思えば、この回路を開発するにあたって、ほとんどすべてのデバッグ作業をMITOUJTAGを使って行ってきました。開発の最初の段階で、クロックが正しい周波数で発振しているかどうかを確認すること以外、オシロスコープは全く使わなかったですね。

PCI Expressはバスのようですが、実は通信です。
拡張ボードを作って何かのデータを転送しようとした場合、パソコンと拡張ボードの間でまず最初にリンク確立の通信をいろいろ行ってデータを交換し、互いの存在を認識させなければなりません。
リンクが確立されなければ、2本のシリアル線にいかなるデータを流そうとも、すべて無視されてしまいます。

このため、バスが動いているかどうかを確認するための最初の敷居がとても高くなります。
逆に、リンクが確立できれば、基本的な部分はできたといえるでしょう。

TB-4V-LX25-DDR2-Eボードを購入

DDR2メモリを使った高速メモリインタフェースが特徴のFPGAボード「TB-4V-LX25-DDR2-E」(東京エレクトロンデバイス製)を購入しました。

この基板は、来年早々のお仕事で使います。
やっぱり新しい装置はワクワクしますね。

基板上にElpida製のDDR2メモリが2個載っているほか、DDR2のDIMMを2枚挿す事ができます。
電源電圧は2.5Vや3.3Vといったものだけではなく、1.2Vやら0.9Vといった低電圧を必要としています。自分で作るのは嫌なので、出来合いのボードがあればそれを使うのが吉です。

さっそく電源とJTAGコネクタをつなぎ、MITOUJTAGでバウンダリスキャン。

デモアプリケーションが書き込まれていて、早速、何かしら動いているのが見えます。
これからDDR2のしくみやらいろいろなことを調べていかなければなりません。

雨漏り対策②

不動産やさんや管理人さんが動いてくれたのか、今日は朝から大勢の人が来ていました。
大家さん、鑑定の人、建物の保険の人、中の保険の人、工事屋さん・・
名刺をいただくと、一級建築士の方でした。

いろいろ調べていただいて、防水金具を取り付けて、あとは次の雨が降るまで様子見です。

雨漏り対策①

昨夜の雨で雨漏りが酷いということを、朝一で不動産屋さんと工事業者に告げました。
早速、不動産屋さんと管理人さんに現場を見てもらいました。それから昨日、ビデオで雨漏りの現場を撮っておいたのでこれも見てもらいました。
これは酷いね、ということになりました。
キュービクル(ビルの変電設備)にある排熱用の穴が怪しいとのことでしたので、私も屋上にあがらせてもらって見せてもらいました。
明日工事の人が来て、水が吹き込まないようにふさぐ板を取り付ける工事するということです。

いっそ水を流してみたらという考えもあるのですが、もし原因が違っていたら余計に大きな問題になるということで、水をばら撒いて調査するようなことはできないようです。
その後しらべてもらったところ、漏電の心配はない、とのことで一安心です。

事務所の納会

今日は事務所の納会を行いました。
東京は便利ですね。ケータリングを注文できる店がたくさんあります。
近くにあったほか弁のオードブルと、寿司を５人前注文しました。
ケータリングは前日予約が基本なのですが、ほか弁は当日予約可なので人数が確定してからゆっくりと決められます。

さて、納会がお開きになって帰ろうとすると、外は雨。
季節はずれの台風がやってきています。

なんと事務所の雨漏りがまだ続いていることが判明。
んー、いままで何とも無かった箇所からも漏れ初めているような・・

天井のシーリング蛍光灯の傘の中には水が溜まっていました。
というよりは、電気が通って光っている蛍光灯が丸々水に浸かっているわけで。
これは非常に危険。

傘をはずしてブレーカーを落として帰ります。

PCI Expressの開発再開

PCI Expressの開発を再開することにしました。

Spartan3 でPCI Expressの機器を開発する場合、Spartan3はPCI Expressの信号を直接出力することができませんので、高速シリアル変換のインタフェースチップを使うことになります。
このFPGAとPCI Expressチップとの間のインタフェースはPIPEと呼ばれています。

PIPEを8ビット幅にしておくと、250MHzの速度にもなります。単純にFPGAのロジックから信号を出力したのでは、うまくインタフェースすることができません。

この速度のレベルになると、FPGAは、外から入力したクロックをDCMをつかって位相シフトさせ、なおかつFPGAが出力したデータの遷移するタイミングをクロックから何ns後にするといった制約をUCFに書き、タイミング検証を行うといったテクニックが必要になります。

前回実験していたときには、FPGAが出力したデータが、PCI Expressボード上のチップに正しく伝わり、2.5Gbpsのシリアルに変換されパソコンに伝わり、パソコン側のチップセットで受信できているか、を検証するすべがなかったので、そこで行き詰まってしまいました。

そこで今回、下の写真のような治具を作りました。

この治具基板は、LVDSで100MHzのクロック信号を作りPCI Express基板に供給する役割と、PCI Expressの送信と受信の信号をループバックさせるということを行っています。

つまり、PCI Expressボード上のチップが出力したデータをループバックさせて再び取り込み、FPGAの中に仕込んだロジアナを使うことで、「FPGAが出力したデータがインタフェースチップに正しく伝わり、それが正しく受信できている」ことを確認するためのものです。

今日はこの基板を使って実験を行いました。

最初、全部ゼロを送ったり、同じデータの繰り返しならば正しく通信できたのですが、ちょっとでも複雑なパターンを送るとPCI Expressチップの受信回路がすぐにエラーを起こしてしまうという現象が観察されました。これはノイズなどでビットやシンボルのロックが外れたりしたときに起きる現象です。

どうやら、LVDSの振幅が僅かに強すぎたようです。REFCLKの信号に抵抗を挟んで若干弱めてやると、全くエラーは発生しなくなりました。PCI Expressチップが要求するリファレンスクロックは非常に微妙で難しい信号なようです。

エラーが出なくなったのを確認したら、FPGAで乱数を発生させつつ、5μ秒に一回「COM SKP SKP SKP」という制御コードを送ります。治具でループバックさせ、FPGA内のロジアナIPコアで取り込んでみたところ、ちゃんと正しく受信できていることがわかりました。

思ったようにPCI Expressの信号をFPGAから送信することができるようになりました。これでようやく、パソコンとつないでリンク確立シーケンスの実験ができるようになりました。

鹿島神宮へお参り

天長節の今日、今年１年間のご守護のお礼にと鹿島神宮へお参りに行きました。

今まで、いろいろな祈祷をお願いしてきたのですが、年の暮れということもあって今日は「神恩感謝」でお願いしました。
祝詞はどれも美しい日本語なのですが、神恩感謝の祝詞は格別に美しかったです。

鹿島神宮には鹿がいます。
私は初めて鹿の鳴き声を聞きました。
言葉にするのは難しいのですが、小さな声でキーキーと鳴くんですね。

火鍋を食す

今日は大学時代の仲間と集まって、火鍋を食べにいきました。

場所は新橋の重慶府。知る人ぞ知る四川料理の名店です。

大学院にいたころ、向かいにある日本原子力学会に論文の予稿を出しに行ったのがきっかけで、それ以来ずっと毎年食べにきています。
昼はランチの７番（とても辛い麺）をよく食べました。

この火鍋は鍋の真ん中に仕切りがあって、片方が赤、片方が白になっています。

赤いほうの汁は、唐辛子・山椒の麻辣の味と、たくさんの野菜や肉や正体不明の珍味から染み出した風味が溶け合ってできた、絶妙の味です。一言で言ってしまえば、ラー油です。猛烈な辛さです。
お店の人に頼むと両方赤という逃げ場のない火鍋を食べることもできますが、今回は片方が白の普通の火鍋にしました。

ところで、火鍋をGoogleで検索してみると、赤いほうのスープは辛いので飲まないと書いてあるページもありますが、それは大変勿体ないことです。
赤いほうのスープも飲まなければ火鍋の楽しみはどこにあるのでしょう。

火鍋を食べながら白酒と紹興酒をのみ、一年間のことや昔の出来事を語り合うとあっという間に時が過ぎてしまいます。

唐辛子の辛さ（カプサイシン）を定量的に測る単位に「スコヴィル値」というのがあります。
辛い液体を砂糖水で薄めていって何倍に薄めたら辛さを感じなくなるか、ということで辛さを定量化したそうです。

一説によれば、スコヴィルさんは筋肉痛に効くクリームを作りたかったと聞きますが、本当は辛い物好きだったのではないでしょうか。

調べによると、
タバスコはせいぜい2140スコヴィル。
カイエンペッパーは30000スコビル。（このへんならスーパーにも売ってます。）
ハバネロは10万～35万スコヴィル。(唐辛子としてのハバネロ。暴君ではない)
純粋なカプサイシンはなんと1千600万スコヴィルだそうです。

火鍋の赤いスープは、いったい何スコヴィルになるのでしょう。

MSP430用のJTAGツールを作ろうかな

いまさらですが、トラ技1月号を読みました。
今回の付録はMSP430です。このCPUはJTAGを使うことができるようですね。

私はこのCPUを使ったことは今までなく、MSP430には興味もなかったのですが、JTAG対応ということに惹かれてツールを作ろうかなという気になってきました。

普通、JTAG関連の端子はTCK、TMS、TDI、TDOの4つですが、MSP430ではTCLKやTEST、RSTという端子があるようです。
資料に目を通したところ、付録基板のMSP430の場合では、TESTとRSTは使用しなくてもよさそうだし、TCLKはTDIと共用です。リセットは、必要なら手作業でボタンを押してあげればいいでしょう。

そうなると、XILINXやALTERAのパラレルケーブルを使って、MSP430のフラッシュに書き込んだり、JTAG-ICEが使えたりできそうです。もちろん、TIが用意している標準のソフトではXILINXやALTERAのケーブルを使うようにはできていないので、ソフトは自作することになりますが。

資料を読んでみると、ARMのJTAG-ICEの仕組みによく似ているなという印象を受けました。

また、MSP430はJTAGの標準的な規格に完全に準拠しているわけではないようです。
TEST端子の存在は許せるとして、TCLKなんていう得体の知れない信号があります。
TDIとTCLKは共用ですから、TCKをとめてTDIをカチカチやるわけです。
なんて非準拠な。

しかも、フラッシュの書き込みの際にはこのTDIに入れるクロックの周波数が定められているそうです。
クロックをとめてもいいわけではないので、USBでやるなら、ちょっと面倒ですね。

また、DRのスキャンではMSBファーストで送らなければならないとか、いろいろJTAGの規格に非準拠な部分があります。

ですが、公開された資料をもとに、CPUの内部構造を推測していったりするなどの方法によって、なんだかJTAGエミュレータを作れそうな気がしてきました。

XILINXやALTERAのパラレルケーブルで、MSP430のICEやフラッシュ書き込みができるツールが作れたらいいな、と期待しながら、具体的な方式を考え中です。

もし、作って公開するとしたら、来年のお正月のころになるでしょう。
気長にお待ちください。

青年技術士懇談会で貴重な出会い

今日は青年技術士懇談会の中間報告会＆忘年会に行ってきました。
私としては委員補佐になってから、オフィシャルな会へは初めての出席になります。

その会で、青年会OBの技術士の方とお会いしたのですが、なんと、CQ出版の雑誌や書籍を執筆されている方でした。最近は無線方面の記事を執筆されているようでした。

その後の忘年会でいろいろお話を伺ってみると、私の十数年先を進んでいるような方でした。
いや～、いろんなところに貴重な出会いがあるものです。

やっと雨漏りの補修工事か？

特殊電子回路が入居しているビルは築30年の建物で、何があっても不思議ではありません。
10月6日に事務所の雨漏りが発覚して以来、管理人さん(自治会さん？)や不動産屋さんに調査とたびたび補修工事を申しいれてきたのですが、「屋上防水工事は最近やったばかりだから問題ないはず」、「調査にもお金がかかる」、「（やるかどうか大屋さんと）話してみる」、などのらりくらりとした対応をされてきました。
先日、漏れている時に現場を見せたのが効果があったのでしょうか。ようやく業者さんを呼んでくれました。「屋上のタンクのところに隙間があって、風と雨が両方来るとそこから吹き込んでくる可能性がある」みたいな感じのことを業者さんは言っていました。

そして今日、ついにエレベータの中に「屋上防水工事のお知らせ」なる紙が張られていました。

自治会さんはようやく動いてくれたのでしょうか。
これで事務所の雨漏りが治ることを切に願います。

JTAGで汎用フラッシュROMに書き込む

組み込みシステム開発評価キット（通称、BLANCA）を使って、フラッシュROMに高速に書き込む方法の研究を行っています。

BLANCAは、FPGAのコンフィギュレーション用のデータを、汎用のフラッシュROM（Am29DL640G）に格納されています。電源をONすると、CPLD（XC95288XL)は、フラッシュROMのデータを読み出してFPGAをコンフィギュレーションする、という仕組みになっています。

このフラッシュROMにはFPGAのコンフィギュレーションデータだけでなく、FPGAの中に仕込まれたCPU（MicroBlazeなど）のソフトウェアも格納されることになっています。

そこで、このフラッシュROMを書き換えたいのですが、JTAGを使って書き換える方法を考えてみると、まずは、バウンダリスキャンによる方法があります。

バウンダリスキャンを使えば、動作中のCPLDやFPGAの端子の状態を、パソコンから自由に書き換えてコントロールすることができます。つまり、CPLDやFPGAがどのような動作をしていようとも、パソコンから指令を出すことによってフラッシュROMにつながったCPLDの端子の状態を自由に制御することができるわけです。

MITOUJTAG BLANCA版のフラッシュROMライタ機能を使って、CPLDの端子を操作してフラッシュROMを書き換えてみると、毎秒72バイト程度という結果が得られました。

遅いですね。

なぜこれだけしか速度が出ないかというと、XC95288XLのバウンダリスキャンレジスタは864ビットの長さがあります。つまり、XC95288XLをバウンダリスキャンして端子を操作するには１回あたり864ビットのデータを送受信しなければならないのです。
フラッシュROMとCPLDとの接続が8ビットあるいは16ビットで、アドレス線は22本、制御信号はせいぜい４つですから、42ビットくらいの信号を操作したいのに864バイトものデータを送っていることになります。
送っている95％くらいのデータは無駄なのです。

そのうえ、パラレルポートを操作してJTAGの信号を１ビット入出力するには、約4μ秒くらいの時間がかかります。実際には870ビットくらいは操作しなければならないので、
4μ秒×870=3480μ秒。
そして、AMD/Spansion系フラッシュROMの書き込みのためには、アドレス線を操作したり、WE信号をL→Hと操作したりで１ワードあたり６回の操作が必要になります。

つまり、８ビット幅でアクセスした場合、
4μ秒×870bit×6回≒21ミリ秒。
1バイトの書き込みに、理論上は21ミリ秒もかかってしまうのです。
（実測値は毎秒72バイト程度だったので、計算よりもちょっと速くなっていますが、遅いのには変わりありません）

一方、XC3S1500をバウンダリスキャンで操作した場合、このデバイスは1559bitの長さがあるので、
4μ秒×1565bit×6回≒38ミリ秒。
と、CPLDよりも遅くなってしまいます。
FPGAからCPLDを通じてフラッシュROMへつながる経路は16ビット幅のデータバスでつながっているので、１回の操作で16ビットをまとめて書き込むことにすれば、毎秒52バイトくらいは書き込める計算になります。
実測値は同じく毎秒72バイト程度でした。
それでも、遅いといえるでしょう。

バウンダリスキャンを使った書き込み方法は、CPLDでも、FPGAでも、CPUでも、そのデバイスの動作をパソコンから完全にコントロールして行います。CPLDが未書き込みの状態でも使うことができます。
このように汎用性がある反面、速度が犠牲になります。

書き込み速度を上げるには、JTAGのクロック速度を上げたり、バウンダリスキャンレジスタ長の短いデバイスを操作して書き込むということになるのですが、決定的な高速化はできません。USB接続のJTAGケーブルを使ってもウン十倍に速くなるということはありません。

調べてみるとBLANCAでは、FPGAが起動した後は、CPLDはFPGAとROMの間の通信を素通しさせるだけの動作になります。
そこで、FPGAにフラッシュROM書き換え回路を内蔵させてしまって、JTAGを使ってFPGAの内部ロジックと通信して正味のデータだけ渡し、WE端子やOE端子の操作はFPGAのロジックで発行させるようにしたらどうなるか、と考え、実際にやってみました。

今回作った回路は実験用に適当に作ったものなのであまり効率が良いものではありませんが、パラレルポートを使用している場合で、約5200バイト/秒という結果が得られました。バウンダリスキャンを使った場合の100倍です。
AMD系フラッシュROMでは、高速なアルゴリズムでも1ワード書き込むには「一度A0を書いた後、本来のデータを書き込む」という２度の手順を踏まなければなりません。こういった手順もFPGAに自動で発行させるようにしたりすれば容易に2倍以上速くできるでしょう。

うまく動作を最適化していけば毎秒20kバイト程度まではいけそうです。
こうなるとJTAGのクロック速度がボトルネックになってきます。
パラレルポート経由では毎秒200～300kbit/sまでしかJTAGのクロック速度を上げられないので、そのあたりが限界になってくるでしょう。

FPGAは通常は平常どおりの動作をしているけれども、フラッシュROM書き換えを行いたくなったら、まずJTAG経由でFPGAの中に「フラッシュ書き換えロジック」をダウンロードし、その後JTAGを通信用に使ってフラッシュに高速にダウンロードし、その後はFPGAをリセットして新しいロジックで再起動する、という感じになります。
したがって、ユーザロジックの中にこの書き換え回路を埋め込む必要はありません。

今後は、まずBLANCAを使ってこの方式を研究した後、汎用性を高めてフラッシュROMを高速に書き換えるツールをリリースしていきたいと思います。