なひたふJTAG日記

Spartan-6のIDELAY2の遅延が何psかということは、データシートにも記載されていません。何度も読むうちに、だいたい1タップが80psくらいではないかと思えてきたのですが、よくわかりません。
そこで、過去に行ったVirtex-5のIDELAYの実験のような方法で1タップの遅延を測ることにしました。

そのやり方は次のような感じです。固定パターンをISERDESに入れ、ディレイを1タップずつ動かしていってデータが変化する点を2箇所選びます。固定パターンの周期はわかっているので、
　周期÷変化するまでのタップカウント = 1タップの遅延時間
という方法で測れるというものです。

OSERDESから00000001というパターンを1Gbpsの速度で出してISERDESで受け取ります。ISERDESの出力は80Hというパターンになっています。そして、遅延をずらしていくと32タップあたりでパターンが乱れて、40Hか01Hになるかと期待したのですが、また80Hになってしまいました。

そして、36タップごとに同じようなことを繰り返します。1000nsを36タップで繰り返しているならば、1タップ=27psということになります。うーん。

なんだか正しいような正しくないような、よくわからない結果でした。Spartan-6のIDELAYは、Virtex-4/5のものとは違い、遅延時間が1ビットの遷移時間を超えてはいけないのですが、それが原因かもしれません。

（これがうまくいけば、80psくらいの分解能のロジアナがつくれるかも、しめしめ・・というわけなのですが、そううまくはいきませんでした。）

今回の実験に使ったVHDLのソースファイルと、前回の通信実験に使ったソースファイルは、こちらにアップロードしました。ISERDESやOSERDESを試してみたいという方は、ぜひご覧下さい。

---

追記

某所で高速なオシロをお借りして、OSERDESの波形を見てきました。特電Spartan-6ボードのピンヘッダからの出力部を差動プローブで見たところ、ちゃんとアイが開いて綺麗な波形でした。

前回の実験の続きです。

前回、Spartan-6のOSERDESから1Gbpsの信号を出すことができました。オシロの帯域の問題で正確な波形は見ることができませんでしたが、その信号をISERDESに入れることによって、通信可能なものかどうかを確かめようとしています。しかし、配線を指で触っただけで不安定になるなど、問題も多いのです。

そこで、I/Oピンに内蔵された遅延コンポーネント「IODELAY」を使ってみることにしました。

まず、遅延調整しない場合の入力信号（para_in）を見てみましょう。出力信号(para_out)からは、0x65という固定値を出力しています。

送信しているパターンは0x65という固定値なので、固定の値が受信できるはずなのですが、bit1とbit3が変化しています。きっと、サンプリングするタイミングが合っていないのでしょう。

そこで、キャリブレーションシーケンスを実行します。すると、振動がぴたっと止ります。

IDELAYに内蔵されたキャリブレーション機能はアイの中央でサンプリングするように遅延を調整してくれるそうですが、ビット同期しかできません。シンボル同期は自分でロジックを組まなければなりません。
ビット同期とシンボル同期にかかる時間は合計200nsくらいでした。これなら気軽に行なえそうですね。

同期が合った後、バイナリカウンタを送信したらちゃんと受け取れていました。

詳しく見ると、送信したデータが受け取れるまでは約4シンボル(32ns)でした。

指で触ろうが、オシロのプローブをあてようが、そのくらいのことではびくともしません。

なお、特電Spartan-6ボードは、1Gbpsを通すためのそういう基板設計をしていないので、本気で工業製品に応用しようとしたりはしないでください。あくまでも趣味の範囲で楽しむようにしてください。

ビットエラー率とかはまだ測っていませんが、それは今後の楽しみに取っておきましょう。

手のひらに乗るFPGAボードで、ギガの信号を自由に出し入れできるのです。なんだかとても嬉しく思えます。そこにあるTP線で長距離を引き回してみたくなりました・・

Spartan-6には、ISERDES/OSERDESが内蔵されています。

ISERDES/OSERDESというのは、汎用I/Oに内蔵されたシリアライザ/デシリアライザで、すべての汎用I/Oに内蔵されています。つまり、スペック上は、LXTに内蔵されたGTPを使わなくても普通のSpartan-6LXで、ギガに迫る信号を入出力できるというのです。

本当かどうか、特電Spartan-6評価ボードを使って、実際に試してみました。

まず、Spartan-6に内蔵されたISERDES/OSERDESは、Virtex-4/5のものとだいぶん違うので、戸惑いました。
やりたいことは、OSERDESから信号を出して、ISERDESで受けてデコードすること。

試行錯誤の結果、Spartan-6に内蔵されたPLLを使って、50MHzの水晶クロックから1GHzと125MHzを作り、OSERDESで速度を8倍にして1Gpbを作りました。

上の写真の右上にある、ひょろっとした銅線にギガの信号が流れています。
まぁ、このようにインピーダンスも何も考慮していないのですが、今回は、本当にギガの信号が出るかどうかを試すのが目的なので、これで良しとしましょう。

そして、オシロ（500MHz帯域）で測った結果は次のようなものでした。

おおっ、なんか出ているではないですか！
ちなみに、10101100というパターンを繰り返しで出しています。
11のところと00のところで振幅が大きく振れ、1010のところで小刻みに振れます。
スルーレートと帯域が足りないとこういう波形になるので、数G帯域のオシロを使えば、きっと綺麗に見えるでしょう。

さて、この波形は本当にGbpsクラスの信号として受け取れるのかを確認するにはどうすればよいでしょうか。
そうです、ISERDESにこの信号を受信させてみればいいのです。

というわけで、上の写真のひょろっとした銅線で出力ピンと入力ピンをつなぎます。そして、入力のところにISERDESをインプリメントします。

そして、8ビットのパターンをOSERDESから出力し、それをISERDESで受け取ってLEDに表示させるというテストを行いましたが、結果は芳しくなかったです。

それなりに正しいパターンを受け取っているのですが、銅線を指でつまむとビット間の干渉とかが起こったりします。基板のパターンやつないだ銅線が、高速差動信号を意識したものになっていないというのも理由のひとつなのですが、このような粗末な配線でも、距離が短いので1Gbps程度ならいけるような気がしています。

もう少し頑張ってみたいと思います。
おそらく、ISERDESが信号をサンプリングするタイミングが良くないんじゃないかと思います。だから、ISERDESの前にIDELAYを入れて、75psくらいの単位で遅延を調整すれば、確実に受信できるようなポイントがあるような気もしていますが、やってみないとわかりません。

---

手のひらに乗ったFPGAボードが（少なくともFPGA内部では）GHzクラスで動いているというのは、なんだかとても嬉しくなりました。XC6SLX16-2のPLLは1.2GHzまで生成可能だそうです。XC6SLX16-2におけるデータシート上ではOSERDESの最高速度は950Mb/sだそうです。

ISERDES/OSERDESで試行錯誤中のソースコードはこちらに置いておきます。ご興味おありの方は参考にしてください。

Spartan-6評価ボードのUSBインタフェースチップに組み込んだ、USB-JTAGのファームウェアを更新したところ、ものすごく速くなりました。
いままで遅くてごめんなさい！

どのくらい速くなったかというと、FPGAの書き込みは10倍、バウンダリスキャンは4～5倍です。

今までのUSB-JTAGと更新後のを比較したところ、以下のような結果となりました。
（参考までにPocket JTAG Cableでの速度も比較します。Pocket JTAG CableはCPLDでJTAG信号をハードウェア的に生成しているので、一番速いです。）

FPGAの書き込み時間が、従来は33秒かかっていたのが、3秒に短縮されたのは大きいです。びゅーっと瞬間的に書き込めます。いままでもっさりしていて、本当にごめんなさい！

DDR2メモリのテストとは、バウンダリスキャンを使ってFPGAの端子を動かして、DDR2メモリに下の図のような波形を送り出して、テストパターンを読み書きするテストです。一連の読み書きを行うのに要した時間を比較しています。

DOS版のSpartan-6用USB-JTAG書き込みツール（SP6JTAG）も更新しました。

ファームウェアの更新はとても簡単にできます。こちらのURLからファームウェア更新ツールをダウンロードし、DOSプロンプトを開いて、firmwr -pと入力するだけです。

DOS版ツール（SP6JTAG）は、こちらからダウンロードできます。

ファームウェア更新ツールはこちらからダウンロードできます。

MITOUJTAGで使うには、DLLを更新する必要があります。MITOUJTAG2.0用(Light,Pro,BASIC共通)のDLLはこちらです。

すべては、特電Spartan-6ボードのページにリンクが張られています。
高速なUSB-JTAGで、快適なFPGA開発をご堪能ください！

MITOUJTAG BASIC 特別版というのを作ってみました。

これは、特定のボードでのみご利用いただけるMITOUJTAG BASICの基板限定バージョンです。
基本的に無償で提供しています。
この特別版というのは、Spartan-6ボードでのみ動作し、MITOUJTAG BASICの機能がそのまま使えます。もちろんBLOGANAも動作します。

Spartan-6ボードには、USB-JTAGの機能がオンボードで搭載されていて、電源はUSBから供給できますので、Sp6ボードとこのツールがあれば、即座にバウンダリスキャンや書き込みできてしまう、というわけです。
電車の中でも布団の中でも、どこであっても、ノートPCがひとつあればSpartan-6の開発ができてしまいます。

起動すると、Spartan-6ボードに内蔵されたUSB-JTAGが自動的につながり、XC6S16LXが自動的にチェーンに追加されます。あとは、サンプリングしたり、操作したり、書き込んだり、自由自在です。

このツールは、先日のEDS Fairにお越しいただいた方で、Spartan-6ボードをご注文いただいた方に無償でお配りいたします。詳しくはEDS Fairで配布したチラシの裏面をご覧ください。有効期限がございますので、お早めにお申し込みください。
EDS Fairには来たけれど、チラシをなくしてしまったという方はご連絡ください。何とかします。

今日、最初の出荷を行ないました。

このツールが皆様のFPGA開発のお役に立ちますように！

特電Spartan-6ボードで動作するSPI ROMプログラマの最初のリリースを行いました。

USB-SPI書き込みアプリケーションで、DOSプロンプトから
spiwr.exe -w ファイル名
で書き込めるというものです。

Spartan-6用のBitStreamを書くのに要する時間は10秒程度でした。

SPI ROMへの書き込みのほか、ベリファイ、リード、チップ消去、メモリダンプ、IDCODE読み出し、ステータスレジスタ読み出し、セキュリティコード読み出しなどの機能をつけました。

読み出しやベリファイは1秒程度です。やはり書き込みは、消去を伴っているので時間がかかります。

このツールを使ってbitファイルをSPIメモリに直接書き込めば、FPGAが起動します。
MCSに変換しなくてもよいので、i●PACTを使って書き込むよりも、はるかに手軽です。

また、上で述べたセキュリティコードというのは、SPIメモリに格納された128バイトのワンタイムROM領域で、後半の64バイトは、ベンダーによってあらかじめ重複しない何かが書き込まれています。前半の64バイトはユーザが1回だけ自由に書き込めます。（上の画面のキャプチャーを参照）
何かに使えそうですね。

ただし、今回作った回路は、SPI読み出し部分が完璧ではないようで、かなりの確率でビットが化けます。どうやら書き込みには問題なく、読み出しの場合のみのエラーのようなので、ベリファイエラーとなった場合は複数回ベリファイを行ってみてください。
この問題は、SPIのMISOをFPGA内に取り込む際のタイミングの問題ではないかなと思うので、近いうちに精査します。

FPGAに書き込むBitファイルと、アプリケーションプログラムとソースコード一式を入れて、こちらにアップロードしました。
ご興味のある方はどうぞお試しください。

SPIメモリにアクセスするためのHDLを書いています。

とりあえず、USBからSPIメモリにコマンドを送って、返されたデータをUSB経由で受け取るというところまでいきました。1回のコマンドとデータは、クロックドメインの変換のため、Spartan-6内のBlockRAMに一旦蓄えられます。このバッファのサイズは1024バイトなので、SPIメモリの想定するあらゆるコマンドに対応できるでしょう。

IDCODE読み出しを行ったときの波形はこんな感じです。

9F 00 00 00 00 というコマンドを送って、xx 1F 26 00 00（AT45DB161DのID）が読み出されているのがわかります。あとはWindows上のソフトを作れば、読み書きベリファイをはじめ、各種のマイナーなセキュリティ機能も試せるでしょう。
ソフトは、今夜には出来る見込みです。

参考までに、HDLのソースはこちらにアップロードしました。

たいしたことではありませんが、設計のポイントは送出バイト間の切れ目がないことです。送出バイト間に待ち時間がないので、クロック速度でアクセスができます。

本当はもっと早く作りたかったのですが、USBインタフェースの動作をロバストにすることに時間をとられていました。

現在、CypressのUSB 2.0インタフェースチップEZ-USB FX2LPは「CY7C68013A」という型番ですが、QFN56ピンにはLFXCとLTXCという2つのサフィックスのものがあります。
型番で言うと、CY7C68013A-56LFXCとCY7C68013A-56LTXCです。

CY7C68013A-56LFXCはもう手に入らなくなっていて、今後はCY7C68013A-56LTXCに移行するとのことです。果たして置き換えはできるのでしょうか？

まず、従来のLFXCの写真です。

そして、これが新しいLTXCの写真です。

で、このデバイスは何が違うかというと、
まず、パッケージが違います。
・パッケージの形状が違う（LFXCは角が丸い、LTXCは角が四角い）
・パッケージの厚さが違う（LTXCは0.1mm薄いらしい）
・LFXCは上からピンが見える。LTXCは見えない。

あと、製造国も違う（LFXCはKOR、LTXCはCHI）ようです。

並べてみると、パッケージの違いはよくわかります。

（LTXCのほうは、実装後に外したので、少し傷がついています）

裏面は、LTXCのほうは触った感じではガラスのようにつるつる、LFXCはざらざらです。GNDパッドの形状も同じです。

ピン配置や、パッドのサイズは同じ（データシート上は誤差の書き方が違う程度）なので、単純に置き換えはできそうな感じがします。同じように実装すれば、問題なく実装できそうな感じです。

電気的特性についてはどうなのかというと、データシートを読んでもはっきりしません。
いろんな仮説を立てて徹底的に検証していたところ、データシートの範囲を超えるところの特性、というか個体差かロット差か、工場の差といえるような部分に、微妙な差があるような気がしてきました。

普通の意味では、電気的特性やUSBマイコンとしての機能・性能に差は無いと思われます。だから、ほとんどのアプリケーションでは、LFXCからLTXCへの置き換えは可能でしょう。

この「微妙な差」については現在も調査中ですが、おそらく判明してもブログでは書けないので、詳しいことは「JTAGひろば」のほうに書きたいと思います。

# 追記
結論を言うと単純に置き換え可能のようです。パッケージの差以外に、顕著な影響はないように思われます。
データシートの範囲外となる真のAC特性は、LTXCのほうが若干勝っているようですが、ロットの誤差範囲である可能性もあります。

この組み込み風味あふれるチョコレートの名前は
「基板チョコレート （２枚組み）」に決まりました。
組み込み業界とバレンタインという、相容れない世界の融合を目指してみました。

木曜日までに送り先のご住所のご連絡をいただいた19名の方には、金曜日の夕方に発送しました。早ければ土日に届くと思います。

PCI Expressボードと、Spartan-6のJTAGバウンダリスキャンを描いたチョコレートの2枚組みです。
どうぞ会社やご家族の皆さんでご賞味ください。

来週もどんどん発送します。お楽しみに！

お菓子屋さんに頼んでいた特電オリジナルチョコレートが今日届きました！

大きなダンボールに入って、たくさん届きました。
110個あるはずです。

こんな感じで、ホワイトチョコレートに食用インクで描かれています。

「Spartan-6を食べつくせ」というメッセージが謎ですが、気にしないでください。

試食してみたところ、普通においしいチョコレートでした。

さて、前にアナウンスしたとおり、2月上旬までに「JTAGひろば」にご参加いただいた方にこのチョコレートを送らせていただこうと思います。現在、61名の方からの登録がございます。
JTAGひろばへの新規登録はこちらからできます。

溶けるといけないので、できるだけ皆様のお手元にお届けしたいと思います。
それでは、お楽しみに。

Virtex-4やVirtex-5には、IDELAYというプリミティブがあります。

I/Oに内蔵された入力用の遅延コンポーネントで、すべてのI/Oピンに内蔵されています。遅延時間は可変で、1タップは、おそらく75～78psくらいで、64タップあります。つまり、ピンごとに75～4800psくらいまでの遅延を作ることができます。

これはこれで便利なのですが、周期が3ns程度（つまり330MHz程度）の信号を受信する場合には厄介な問題が生じます。

なぜなら、入力ディレイは、入力信号が遷移する中間のタイミングでサンプリングできるようにあわせるのがベストなのですが、最大でも4.8nsのディレイしか作れないので、信号が遷移する中間のベストな点を簡単には探すことができないからです。

入力遅延の最適値を探すには、入力信号に定型的なビットパターンをいれて、IDELAYの遅延量を0から順に増やしていって、そのパターンが変化する場所（信号が遷移点：つまり、一番サンプリングにふさわしくないタイミング）を探します。

最適な点を見つけるときのイメージは下の図のような感じです。

例えば、IDELAYの遅延量を0から順に増やしていって、13タップ目（つまり1nsあたり）で最初の遷移点が見つかったとしましょう。そして、次の遷移点が53タップ目（つまり4nsあたり）とします。すると、最適な遅延量は(13+53)/2=23タップあたりということになります。このような場合、IDELAYを23タップに合わせておけば、ベストなタイミングでサンプリングできるでしょう。

しかし、IDELAYの遅延量を0から順に増やしていって探そうとして、最初の遷移点が33タップ目（つまり2.5nsあたり）だったらどうすればよいでしょうか？IDELAYは64タップしかないので、2回の遷移点を探して中間を取るということができません。設計者が周期3nsだと知っていれば、13タップあるいは53タップにセットするということもできるでしょう。

さて、IDELAYを使うには、IDELAYCTRLというプリミティブが必要ですが、実は、IDELAYの遅延時間は、IDELAYCTRLというプリミティブが測っているようです。
だから、IDELAYCTRLのREFCLKを変えると、タップの遅延量も比例して変わります。

本来、Virtex-4やVirtex-5のIDELAYCTRLには正確に200MHzのREFCLKを与えなければなりませんが、これを100MHzにしてみたところ、IDELAYのタップの遅延量は2倍の約150psになりました。

すると、最大遅延量も比例して延び、約330MHzの信号に対しても遅延を2週させて遷移の中間点でサンプリングできるようにあわせることができるようになりました。
もちろん、規格外の使い方になるので、保障はありません。
一応、動作はしているみたいですが、いつ動かなくなるか心配です。
Virtex-4ではこのやり方で動いてしまったことがあるので、Virtex-5でもできるかなと思ってやってみたら、できました。FPGAってのは不思議なものです。

なお、Spartan-6のIDELAYは、それとは別の原理で動いているようです。
Spartan-6のIODELAYは、入力信号が遷移すると、入力ピンに内蔵されたリングオシレータが超高速に振動して50psくらいの周期のクロックを出し、そのクロックをカウントすることで、入力信号の遷移から既定の時間を遅らせて出力信号を遷移させるというような驚愕の原理で動いているようです。これも近いうちに実験してみます。