秋葉原で展示会

今日は、秋葉原のUDXで、「高速インタフェース＆インターコネクト・デザイン・ワークショップ」がありました。
特電の事務所から近くて、ロケーションは最高ですね。

今後、UDXやダイビルで行われる組み込み関係の展示会が増えていけば、嬉しいです。

PCI Express。間に合った。

2ヶ月ほど前から超特急で進めていたPCI Expresｓの仕事ですが、連日の徹夜の成果により、何とか期日に間に合うことができました。

何の期日かというと、明日9月29日、
秋葉原UDXにて、「高速インタフェース＆インターコネクト・デザイン・ワークショップ」というのが開かれます。

ベンダセッション(入場無料)の某社ブースにて展示されるあるスゴイ装置に、うちの設計が組み込まれています。
（って、これだけじゃ何かわかりませんね）

とにかく、ええと。是非お越しください。

MITOUJTAGがVirtex4に対応！

一昨日、Virtex4を搭載した基板が実装から上がってきました。

Virtex4のXC4VLX25SF363は、メタル製のBGAパッケージに入っています。
パッケージは綺麗です。結構熱くなります。

このFPGAをいろいろとデバッグするため、まずMITOUJTAGをVirtex4に対応させました。

MITOUJTAGサポートページから、「サービスパック４」と「パッケージファイル」をダウンロードして、インストールすると、MITOUJTAGでVirtex4の書き込みができるようになります。サービスパック４を適用しなくても、バウンダリスキャンはできます。

これは新規に作成した基板ですが、はじめて使うデバイスや使ったことのない機能が満載なので、FPGAの端子から本当に信号が出力されているか、隣の基板からちゃんと信号が届いてきているか、など非常に不安になる箇所がいっぱいありました。

「この信号、本当に基板上で正しくつながってるのかな」などと思ったとき、FPGAのその端子から波形を出すようなテストデザインを作ってオシロで確かめてみる、というのも手ですが、Virtex4のような大きなFPGAだと、ISEで１回コンパイルするのにかなりの時間がかかりますので、気軽にはできません。

そんなとき、MITOUJTAGのバウンダリスキャン機能をつかえば、望みの端子をクリックするだけで、FPGAのどのI/O端子からでも自由にHとLを出力することができます。

好きな端子からHやLが出せますし信号の状態もモニタできます。オシロやロジアナをあてなくても、隣のICが信号を出してきているかどうか、すぐにわかります。

つまり、「FPGAの設計をしなくても、FPGAが動く」ということです。

BGAだらけのこの基板のデバッグでは、私自身かなりMITOUJTAGに助けられました。
だいたい、作業を始めてから約12時間くらいで、PCI ExpressのIPコアが動くところまで達成できました。MITOUJTAGを使わなければ、不安な心持のまま１０日くらいはかかったでしょう。

これはPCI Expressの基板なのですが、この基板にパソコンをつなぎ、パソコンの電源を入れると、ごらんのとおりいろいろな信号が動き出すのが見えます。

ここまでくれば一安心です。

USB2.0の転送速度に関する一考察

8月ごろ、EZ-USB FX2LPのSlaveFIFOとXILINX FPGAを、デバイス限界の最高速度でインタフェースするためのコア（FPGAの回路設計）を作りました。そのときのコアを使ってUSB2.0HighSpeed対応の高速カメラを作ったところ、USBの速度について面白い現象に遭遇しました。

まず、EZ-USB FX2LPは、IN方向(USB→PC方向)の転送では最高でおよそ328Mbps（毎秒40MBytes）の速度が出せます。そこでFPGAとEZ-USB FX2の間を最高速度でデータをやりとりするためのFPGA用のコアを作りました。
このコアは、どんな回路でも簡単にインタフェースできるようにと思って作った汎用性が高いものです。先日、このコアを利用して高速なUSBカメラを作ったのですが、撮った画像が明るいと、若干、速度が落ちるのです。

調べていると、どうやらカメラが明るい映像を撮った場合、各ピクセルのデータが0xFFに飽和してしまいます。すると、転送速度が遅くなるように思われました。

詳しく説明すると、USBはNRZIという通信方式を採用しています。
NRZIとは、データ’０’を送る場合には信号の値を反転させ、データ’１’を送る場合には信号の値を反転させない、というものです。例えば、次の図のような感じになります。

NRZIの通信方式では、上の図のように適度に０と１が混ざったデータを送るならばいいのですが、’１’が連続すると同じ値を送信しつづけてしまいます。
もし、0xFFFFFFFFなんていうデータをNRZIで送ると、３２ビット分の長さの間同じ値を送りつづけることになります。USBのような高速シリアル通信では、データの変化するタイミングでクロックを抽出しているので、あまり長い間信号が変化しないと、通信ができなくなってしまいます。

USBでは、適度に信号の値が変化してくれることが必要です。そこで、USBでは’１’が６個連続すると強制的に’０’を挿入するようになっています。これがビット・スタッフィングというものです。

例えば、１１１００１１００１１１１１１１００というデータを送りたい場合、

前　１１１００１１００１１１１１１１００
後　１１１００１１００１１１１１１０１００
という具合に、強制的に０が挿入されます。
この’０’は、受信回路で自動的に除去されるのですが、余分なビットが送られるので正味の転送レートは下がります。

ということで、USBで"FFFFFFFFFF・・・"というようなデータを送信した場合、おそらくビットスタッフィングが効いて来てしまって速度が16％ほど低下するのではないかと考えました。
実際に、画面が白く飽和したような画像を映すと、転送速度が落ちます。

波形で見てみましょう。
USB2.0の480Mbpsの波形は、私の手持ちのオシロでは見えないので、EZ-USB FX2の制御信号を見ることにします。

次の図は「FPGAからEZ-USB FX2LPのSlaveFIFOにデータを送信していることを示す信号」をオシロでキャプチャしたものです。この波形が’０’の時、FIFOに向かって書き込んでいます。

0xFF(つまり明るくて飽和してしまった白)が多く含まれるデータを送信した場合は、このように、125μ秒のマイクロフレームの間に、信号が９回立ち下がっています。つまり、512バイト×9/125マイクロ秒=36.9Mバイト/秒程度の速度しか出ていません。

一方、通常の画像、つまり0xFFなどが含まれていない普通に見られる画像を送った場合は、

このように、125μ秒の間に信号が１０回立ち下がっていて、512×10/125マイクロ秒＝40Mバイト/秒の速さでデータを送れていることがわかります。

このように実験してみましたが、つまり、USBに向かって'1'が6個連続するようなデータを送ると、転送速度が下がるのではないかという予想ができます。したがって、USBとの間でデータをやりとりする場合には、0xFFや0x7F、0x3F、0xFCなんていうデータは送らないほうがよさそうです。

もしどうしても0xFFをいっぱい送らなければならないような場合には、データにスクランブルをかけて'1'が連続しないようにしてやるとか・・そこまでするかというような感じですが。

ここで書いた結果は、ちょっとした思いつきで実験したことなので、全く間違っている可能性もあります。ですからあまり鵜呑みにせずに参考程度にとどめて置いてください。
また今度、詳しい追実験をやってみることにします。

→ つづきはこちらに書きました★

JTAGロジックアナライザの大幅な機能強化

JTAGロジックアナライザの機能を大幅にアップさせようとしています。

しかし、今のJTAGロジックアナライザのソースコードは非常に汚いのが4000行もあるで、これ以上の拡張が全くできない状態になっていました。

そこで、全てのコードを１から綺麗に書き直すことにしました。

私は、C言語でクラスを実現するプログラミングスタイルを覚えてからは、C++は使わずに、Cで構造体を駆使してクラスを作るようになりました。オブジェクト指向プログラミングをするなら、C++よりもこっちのほうがラクです。 要はC++が自動でやってくれることを自分で書くわけですが、C++よりも緊張しながら考えながら書かないとうまく作れないので、必然的にプログラムが綺麗になります。 暇ができれば、いつかこの「Cでクラス」を書くプログラミング技法も紹介したいところです。

さて、今回の改良のポイントは、表示とデータ構造を完全に分離して、ロジアナ機能の拡張を容易にするところにあります。

今までのJTAGロジックアナライザの問題点としては、何百本もある信号の1本1本を波形で表示できるものの、いくつかの信号をバスとしてまとめて表示させることはできなかったところにあります。
そこで、今回は主にバス化対応の改良を行っています。

次のJTAGロジックアナライザのイメージは、こんな感じになります。

（この画面は開発中のものです。）

このように、いくつかの信号を纏めて、バスとして表示させる機能をつけました。
バスの表示は、10進、16進、2進、ASCII文字、8B10Bデコード、アナログ波形など、いろいろな形式に対応しています。
※PCI Expressの実験のために、8B/10Bでデコードした結果を画面上で見たかったというのが、この開発の最大の動機です。

よくみると、8B10Bデコードしたような値が見えていますが、元のデータはただの乱数なので、K7.4とかいうありえない値が出ています。

さて、波形上をマウスでクリックするとカーソルが表示されますが、左クリックと右クリックで２つのカーソルが使えるようになりました。カーソル間の時間差がステータスバーに表示されるので、これが意外と波形の解析に使えて便利そうです。

見たくない信号を表示されないようにしたり、区切り行を挿入したりと、操作性も向上しています。
今週か来週中にはリリースできるかと思います。

ご期待ください。

MITOUJTAGパンフレット・機能・対応デバイス一覧

いままで展示会などで、MITOUJTAGのパンフレットとしてA4の紙一枚のものをお配りしておりましたが、これがとてもわかりにくいというご指摘を受けておりました。
また、MITOUJTAGにはどんな機能があって、どのようなデバイスで使えるのか、という問い合わせをよくいただいておりました。

そこで、諸々の案件やET2006に向けて、MITOUJTAGのパンフレットを全面的に書き直すことにしました。

MITOUJTAGパンフレット

・・・実に４ページになってしまいました。
このパンフレットは、A3のつるつる紙に両面フルカラー印刷して2つ折りにするつもりです。
したがって、A4サイズ４ページ分のご案内資料となります。

また、MITOUJTAGの機能や対応デバイスは刻一刻とバージョンアップしているので、追加資料として別刷りにしました。上記のパンフレットの間にはさみこむ形となる予定です。

MITOUJTAG機能一覧表

対応デバイス一覧表

機能一覧表と対応デバイス一覧表は、毎月１回くらいのペースで更新していきたいと思います。
MITOUJTAGをよろしくお願いします。

PCI Expressの波形が見えた！

昨日の続きの実験をしています。

昨日の日記では『シンボルを解読するとK23.4 K30.7 K30.7 D26.5 D00.2 D00.0 D22.5 D22.5 D22.5 D22.5 D22.5 D22.5 D22.5 D22.5 D22.5 D22.5』と書きましたが、解読方法が間違っていました。
正しくは、下の図のように、8bitの2進数のデータを上位3bitと下位5bitに分けて、入れ替えて読みます。

私が昨日K23.4と書いたのは、1BChというデータを1 10111 100と読んだのですが、正しくは1 101 11100と区切ってK28.5と読むのが正解でした。K28.5はCOMシンボルと言って、ある種のシーケンスの開始を表す符号です。

さて、PhillipsのPX1011Aは250MHzの速度でデータを出してくるので、それをSpartan3 FPGAでそのまま処理するのはちょっと難しいです。Virtex4ならば余裕でしょうが、Spartan3ではちょっと厳しいでしょう。
そこで、次の図のようにDDRみたいなことをやって、入力した信号を125MHzで2倍のビット幅の信号に変換してやります。つまり、8bit250MHｚで受信したデータは、FPGAの中で16bit125MHzに変換されて処理されるわけです。

125MHzの信号ならば、Spartan3でも処理できる速度です。

こうして、速度を変換した信号をBLOGANAで観てみると、次の図のようになりました。

白い線（トリガポイント）の後で、繰り返し同じ波形が見えています。
これを解読すると、次の図のようになりました。

パソコンのチップセットが送ってくる「トレーニングシーケンス」のパターンが、しっかりと読めるようになりました。

このシーケンスに呼応するような信号を返してやれば、きっとリンクが確立するのでしょう。
その楽しみは明日にとっておくことにします。

今日のハマリどころは、PCI Expressは普通、PHYチップが出力するRXCLKで動作するのですが、PX1011Aはリセットをかけてから物理層のリンクが確立するまでの間はRXCLKが100MHzが出力されるところでした。リンクが確立すると、このRXCLKは250MHzに変わります。FPGAの中でDCMを使っている場合は適当なところでDCMにリセットをかけてやらなければなりません。

それにしてもPCI Expressは、JTAGを使ってデバッグしないと、とても開発をやってられません。

PCI Expressの実験開始

PCI Expressのコアを自分で作ることにします。

PCI Expressは、PCIとは違い、物理層からアプリケーション層まですべて完成していないと、マザーボードは全く認識してくれません。認識してくれなければ、パソコン上のプログラムからいくらI/Oポートや物理メモリを叩いても、その指令がブリッジを超えることができないのです。
したがって、PCIの時によくやったように、I/Oポート叩きやメモリライトなどを行ってロジアナで信号観察・・というわけにはいきません。

PCI Expressの仕様は複雑なので、一気に全部を作ることはできません。したがって、一番下の層から、確実に動作する層を順々に作っていくことにします。

ボードは、XILINXのPCI Express評価キットを使います。
このボードは、PhilippsのPX1101AというPCI Express用のPHYチップと、Spartan3のXC3S1000がのっています。
ほかには、DDR SDRAMやビデオ出力なども乗っていて、豪華なボードです。

このボードを、PCI Expressに対応したマザーボードに挿入します。

上の写真のように、PCI Expressのボードも、マザーボード剥き出しの状態です。
この実験に使った剥き出しのパソコン（マザーボードや、ハードディスク、電源、メモリなど）は、3万円台で作ることができました。

さて、PHYチップのPX1101AはFPGAと接続しますが、インタフェースの速度は250MHzです。FPGAとPHYチップの間を8bit/250MHzでつなぐのですが、常識的に考えても周波数が高すぎます。LVTTLやLVCMOSの信号ではまずうまくいかないでしょう。そこで、この評価ボードではSSTL_2という信号形式を使うようになっています。
SSTL_2というのは、終端抵抗を使ってなんとか高速信号をやりとりするやり方です。
周波数が高いと大変ですね。

FPGAには、ほとんど何もしない回路を書いておきます。
今回作った回路は、タイマーで周期的にリセットをかけてPHYチップを初期化してやるだけの単純なものです。
これをマザーボードに挿せば、マザーボード上のチップセットがきっとPCI Expressのボードを探しに来てくれるでしょう。

MITOUJTAGのロジックアナライザで波形を見ると、何かを受信しているのが見えました。

ボードとチップセットの間でリンクが確立すると、PX1011AはRXVALIDという信号をHにします。このRXVALIDがLの場合は、RXDATAとRXDATAKは無効な値です。
見ると、RXVALIDが数十ミリ秒で周期的にアクティブになって、何かを送ってきています。ですが、こちらのFPGAは、たとえリンク確立のパケットを受け取っても、無視して何も返しません。
チップセットはリンク確立をしようと延々と頑張っているのでしょうか。

MITOUJTAGの通常モードのロジアナは１クロックごとに信号を捉えることができないので、BLOGANA機能を使います。BLOGANAならば１クロックごとの信号が見えます。

さて、BLOGANAで、受信したデータを見てみます。

何か見えていますね。

あるタイミングで受信したシンボルを解読してみると、K23.4 K30.7 K30.7 D26.5 D00.2 D00.0 D22.5 D22.5 D22.5 D22.5 D22.5 D22.5 D22.5 D22.5 D22.5 D22.5 というデータが16ワード周期で来ています。
16周期ということは、おそらく、「Link Initialization & Training」というシーケンスを実行したいのだとは思いますが、このK23.4というのは有効な開始コマンドではありません。

おそらく、今の回路では、データが正しく受信できていません。
正しいデータが受信できるように、これからタイミングを調整していきましょう。

今日、何となくわかったことは、PCI Expressのマザーボードは最初に「Training Sequense」を送ってくるっぽいということです。

SH-4AのJTAGバウンダリスキャン

MITOUJTAGが、SH-4Aのバウンダリスキャンに対応しました。

SH-4Aは、ルネサステクノロジのRISCプロセッサ「SuperH」ファミリの最上位製品です。速度も速く、キャッシュやSuperHywayや浮動小数点やPCIやDDR SDRAM、とにかくすごいCPUです。何がすごいかは一言では言い表せませんが、とにかくSHの最上位機種です。

このCPUはSH2とはちがい、内部にROMやRAMを持っていない、いわゆる普通のCPUです。したがって、プログラムを走らせるには、外付けのROMやRAM上にあらかじめ書き込んでおかなければなりません。

ですが、「・・・ROMに書き込むには、あらかじめROMにブートコードを書いておいて、シリアルで・・」これでは、卵が先か、鶏が先かという問題になってしまいます。

そんなとき、JTAGが便利です。

ところで、一口にJTAGといっても、マイコンに対して２つの使い方があります。
一つは、ICEといって、CPUのレジスタやコアに対するアクセス方法。
もう一つは、バウンダリスキャンといって、CPUのI/O端子だけを操作する方法です。

市販のJTAGデバッガの99.9％はICEといわれているもので、CPUのコアを直接刺激してプログラムのダウンロードやメモリの操作を行います。確かにこの方法は強力な方法なのですが、CPUの品種によってコアにアクセスするためのシーケンスが全く異なるため、異なる品種のCPUに対しては100％使えません。いわゆる特定のCPU専用のソフトウェアになります。

一方、MITOUJTAG BASICがサポートしているのは、バウンダリスキャンという方法です。バウンダリスキャンは、どのような品種のICに対しても同じシーケンスでアクセスすることができるため、たとえCPUの品種が変わっても同じソフトウェアで対応することができます。

さて、実際にMITOUJTAGでバウンダリスキャンをおこなってみます。

MITOUJTAGで、SH-4AのSH7780のバウンダリスキャンを行うには、MITOUJTAGサポートページから、「サービスパック３」と「パッケージファイル」をダウンロードして、インストールしておいてください。SH7780のバウンダリスキャンは少々特殊な部分があるので、「サービスパック３」を適用しないと正しくバウンダリスキャンが出来ません。

サービスパックをインストールしたら、ルネサステクノロジのWebサイトへ行き、登録を済ませてSH7780のBSDLファイルをダウンロードします。

普通ならBSDLファイルはダウンロードするだけでMITOUJTAGから使えるようになるのですが、私の手元にあるSH7780は、ちょっと型番が古いためか「IDCODE相違」と、エラーが出てしまいます。

そこで、BSDLファイルの929行目
"1000000000001010"&
を
"10000000000X1010"&
と書き換えます。

これをMITOUJTAGで読み込ませてもエラーが出なくなります。SH7780は、MITOUJTAGで自動認識することができます。自動認識したら、「デバイスの変更」と「パッケージの変更」の２つの操作を行います。SH7780のパッケージは449ピンBGAという特殊な形状なので、手動で指定しなければなりません。SH7780用に「sh7780.pkg」というファイルを用意しています。

この操作をおこなうと、下の図のようにバウンダリスキャンを行うことができるようになります。

MITOUJTAGでバウンダリスキャンを行うと、SH7780が入出力する信号が、パソコンの画面上に「赤：H」「青：L」で表示されます。上の図の画面では、ICの上側の方がデータバスとアドレスバスです。CPUが動くと、これらの端子の色がピカピカと変わります。

表示されたSH-4Aの絵の右下にある灰色の部分は、DDR SDRAM用の接続ピンです。DDR SDRAMの接続ピンはバウンダリスキャンできないので、灰色になっています。

バウンダリスキャンは非常に強力なデバッグ方法です。MITOUJTAGのバウンダリスキャンは、CPUのコアを介さず、CPUの端子だけを操作するので、CPUが動作していなくても使うことができます。つまり、一般的な話ですが、CPUのモード設定が間違っていたり、リセットがかかりっぱなしだったり、CPUにクロックが入っていなくても、バウンダリスキャンはできてしまいます。バウンダリスキャンは単純なので、とても安定しています。CPUがどんな状態でもバウンダリスキャンは安心して使えます。

それに対してJTAG ICEはとても複雑なシーケンスで制御しているため、これほど安定はしていません。CPUの動作がとまっていたり、クロックが入っていなかったり、モード設定が間違っていたりすると使えないことがありますし、不用意にリセットをかけると同期が外れて反応が返ってこなくなることも多いでしょう。JTAG ICEは極めて微妙なバランスの上で動いていますので、あまり変な操作はしないほうがいいでしょう。

さて、最後に、バウンダリスキャンでCPUのピンを操作して、CPUにつながったフラッシュROMを書き換えてみます。MITOUJTAGのフラッシュライタを起動し、SH7780とフラッシュROMの接続方法を入力します。すると、簡単なGUI操作でフラッシュROMの内容が読めるようになります。

上の図は、フラッシュROMのCFIコードというものをよみ、セクタ構成を図示したものです。

ここで、適当なデータを書き込んでみましょう。

SH7780は、リセット後、0xA0000000番地から起動します。この領域はROMの0000番地につながっていることが多いでしょう。したがって、ROMの0番地に適当なコードを書き込めばSHはそれを実行してくれるはずです。

適当なバイナリエディタで、次のような内容のファイルを作ります
>　0009 0009 0009 0009 0009 0009 0009 0009
>　0009 0009 0009 0009 0009 0009 0009 0009
>　0009 0009 AFF8 0009 0009 0009 FFFF FFFF
>　FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF

0009 は、SHにとってのNOPコードです。AFF8は遅延分岐で、少し前のアドレスに戻ります。
このコードを実行すればCPUは無限ループしてくれるはずです。

実際に、MITOUJTAGのフラッシュROMライタを使って書き込んでみると、アドレス端子のA1～A5は激しく動くものの、A6以上のアドレス端子はLのままで止まっています。つまり、CPUは+00～+3E番地の間で動いているといえるでしょう。

SH4はキャッシュを積んでいるので、アドレスバスが実行している番地を指しているとは限りませんが、どうやら0x40番地以降は読みに言っていないことは、少なくとも推測できます。

JTAGロジックアナライザで波形をみてみても、A1～A5が動いていてA6以上は動いていないことがわかります。これは想定した動作です。つまり、CPUは全く動いていないということはなく、少なくとも何らかのプログラムを実行していることが推測されます。

---

まとめ

・MITOUJTAGのJTAGバウンダリスキャンを使うと、SH4の入出力端子を見たり操作することができます。

・バウンダリスキャンを使えば、プログラムを組むことなしに、CPUが動くのを確認できます。

・MITOUJTAGのバウンダリスキャンは、非常に強力で汎用性の高いデバッグ方法です。

今回はバウンダリスキャンを使って「CPUが動いていること」を確認しました。次はSH4A用のJTAG ICEを作ってみることにします。お楽しみに。