2017年5月
MIG設定ガイド
2017.5.22
Kintex-7搭載FPGAボード『Cosmo-K』用に、DDR3メモリコントローラ「MIG」の設定ガイドを書きました。XILINXのメモリコントローラのすべてを余すところなく記載しました。
http://www.tokudenkairo.co.jp/cosmok/cosmok-mig-guide.pdf
自社のベンダIDでXDMAに成功
2017.05.20
Kintex-7のFPGAボード『Cosmo-K』にXILINXのPCI Express DMAコアを入れて、さらに自社ベンダIDに変更して動作させることができるようになりました。
まず、VivadoでXDMAのコアをIPカタログから持ってきて、置きます。
これだけでも動作しそうなのですが、PCI Expressのクロックは差動クロックでGTXに入ってくるので、IBUF_GTE2というプリミティブで普通のクロックに直してやらねばならないなど、いろいろあるので、RTLのモジュールを作ってそのなかに細かいロジックを入れます。
また、DMAを行うには、M_AXIのポートに何かのAXIスレーブがつながっていなければなりません。
そこで、AXI Block RAMをつなぐことにしました。私のVivadoではなぜかAXI Block RAMを直接置くことができなかったので、AXI BRAM Controllerを介して普通のBlock RAMを置きました。
ここまでBRAMのサイズを指定する箇所がなかったのですが、Vivadoのアドレスエディタというツールで「0番地から1MByteに配置する」と書いてValidate Designを行うと、自動的にBRAMのサイズが1M Bytes(256個使用)と推論されるようです。
また、XDMAのコアでは、ベンダIDとデバイスID、それからクラスを変更しました。1BC8というのは特殊電子回路㈱のベンダIDで、110000というクラスは汎用のデジタル入出力装置を意味します。
できあがったBit Streamの書き込みはMITOUJTAGを使うと便利です。Cosmo-KにはUSB-JTAGが搭載されているので、MITOUJTAGをつなぐとすぐに認識されます。また、MITOUJTAGにはBit Streamが更新されたら書き込みを行うという機能があるので、論理合成が終了したら自動的に書き込まれます。
ベンダIDを変えたので今まで見たことのないデバイスとして認識されますが、XILINXのxdma.infの中を書き換えて、デジタル署名を施しただけのドライバでうまく認識されました。
xdma_info.exeツールを使えば内部のレジスタなどが見えるし、
もちろん、DMA転送のテストプログラムも動きました。
8MByteを0.004952秒で転送しているので、1.6GByte/sec出ている計算になります。
あと、割り込みも動きました。
しかし問題はDMA以外に何かやりたいと思って、AXI LiteやAXI Bytessの、いわば予備の通信チャネルを有効にすると、途端にドライバがうまく動かなくなります。
下の図は、XDMAの設定画面ですが、BARsというところでAXI LiteやAXI Bytessを有効にできます。
AXI Liteを使えば、パソコンから1ワード単位でFPGA内に小さなトランザクションを発生させられるのでしょう。AXI Bypassを使えばFull AXIなトランザクションを発生させられるのでしょう。
しかし、これらを有効にすると、
このように、xdma_関係のツールは調子が悪くなります。
XILINXのXDMAは、デフォルトの状態ではBAR0にDMA用のコントロールレジスタが並んでいますが、Liteを有効にするとBAR1に移動してしまうからでしょうか。
というわけで、自社ベンダIDのPCI Expressデザインで、XILINXのXDMAを使うことには成功しました。
1Gs/s 16bit ADCからのデータ受信
2016.5.11
ついに1Gs/s 16bit 2CHの高速ADC(TI社 ADS54J60)からのデータの受信ができるようになりました。
使っているボードは、Cosmo-K+というKintex-7のPCI Expressボード。いまはPCI Expressには挿さずにスタンドアローンで動かしています。
ADCからのデータは、JESD204Bという規格で、10Gbps×4本で送られてきます。
トータルで40Gbpsの信号です。
この中にJESD204Bのデータが入っています。
何度かやってみると、毎回、4つあるGTXのフレームの先頭がずれるようですます。
次の図ではGTX1だけ1ワード遅れています。また、先頭にある11Cというコード(/R/)が2回見えています。
GTXの中でチャネルボンディングとかしてうまく合わせられるはずなのですが、まだうまく行っていません。
とりあえず、このFPGA内蔵ロジアナで取り込んだデータをExcelにエクスポートしました。
これから解析ですよ。
16進に直して、Kコードを置換したり色を付けて見やすくします。
/A//R//Q/で始まるILASフェーズが見えてきましたね。
トラ技によればILASフェースは14バイトとのことなのですが、上の解析データでは17バイトあります。これはSYSREFの周期の違いだそうで、後ろに無駄なデータが詰まっているだけなので問題はないようです。
データを見てみると、GTX1とGTX3は00とFFばかりです。つまり、AD変換結果の上位16bitなのでしょう。
Excelで各セルに
=MOD(HEX2DEC(K271)+HEX2DEC(P271)*255+32768,65536)-32768
みたいな式を書いて2つの16進数値を結合し、10進に直して、さらに時系列に並べます。
すると、生の波形が見えてきました。
これは入力に何もつながないときの波形です。ノイズのヒストグラムを取ってみます。
おお、釣り鐘型のヒストグラムが見えてきました。4つおきに大きな頻度になっているのはDNLが極端に悪いか、何かを間違っているためでしょう。
とりあえず、まだ波形は綺麗ではないのですが、何か正しそうなデータが受信できるようになりました。
あとは、弾性バッファを入れたり、チャネルボンディングとかをできるようにして、4つのGTXのフレームの先頭がぴったり合うようにしたいですね。
FPGAからARPをひたすら投げる
2016.5.10
インターンで来ている学生さんが、Kintex-7のGTXにGigabitEtherを実装してARPをひたすら投げる回路を作ってくれました。FPGAから全力でARPを投げると帯域の50%を使うそうです。「これをやるとネットワークがめっちゃ遅くなる」そうです。
ARP自体のパケットのサイズ、プリアンプル、フレーム間ギャップなどを考えると、これで妥当な速度だそうです。
それから、他人のARPに勝手に反応するFPGAを作ればネットワークを使用不可能にさせてしまうものも作れるそうです。
↓のモジュールはSFP+からケーブルのイーサネットを引き出すためのものだそうです。
JESD204Bの安定受信
2016.5.9
学生さんがついにJESD204Bの10Gbps×4の信号を安定してKintex-7で受信できるようにしてくれました。今日、私はこれを解析しようと規格やADコンバータの使い方を調べています。
高速ADCのSYSREFという信号にノウハウがあるそうです。
Cosmo-Kのマニュアルを作った
2017.5.8
久しぶりに製品のマニュアルを執筆しました。
Cosmo-Kのトップページ
http://www.tokudenkairo.co.jp/cosmok/
のリンクから誰でもダウンロードできます。
やっぱり、紙のマニュアルがあるっていいですね。
Cosmo-KのIBERT試験
2017.05.04
Cosmo-KのIBERT試験を行いました。
IBERT試験というのは、高速シリアルトランシーバがエラーを起こすマージンを解析するものです。つまり、どのくらい電圧や時間がぶれても大丈夫かを調べることができます。
なんでこんな検査を行ったかというと、今まで6層だとP板のウルトラクイックとかでも10日くらいかかっていたのですが、さすがに納期が長い。
だが、日本の基板会社なら2~4日で製造できる。でも、本当に2日や4日で作った基板で品質は大丈夫だろうか・・・そんな心配があったから比べてみました。
10Gbpsの通信に差はでるでしょうか。
使っているFPGAはXC7K160T-2FFG676Cです。
まずは、新基板(日本)でのIBERT検査の結果です。
10Gbpsで測って、だいたい50%程度のマージンが出ています。10Gbpsでも余裕で通します。
P板(韓国か台湾)で作ったものはどうでしょうか。
いずれのチャネルも10Gbpsで十分に通信ができ、なんと60%を超えているところもあります。
ただ、新基板は2台作っていて、もう1台のもので測ってみると、
1台目のものよりも良い性能が得られました。P版で作ったものも、過去に測ったときには60%が出たことはなく50%か43.8%でした。このあたりは偶然なのでしょう。
結論を言うと、基板メーカーによる差はなく、おそらくFPGAの個体差なのだと思います。10Gbpsが出ているのだから良しとしましょう。