JTAG総合情報サイト>MITOUJTAG開発日記>2014年以前のJTAG開発の記録

MITOUJTAGとは何か

導入するメリット

製品について

製品一覧表

ご購入を検討中の方へ

サポート

JTAGについて

JTAG技術サービス(有料)

JTAG技術サービス

JTAG開発日記

開発日記総合案内

JTAGを熱く語る

2014年以前のJTAG開発の記録

MITOUJTAGで電源やGNDへのショートは発見できるか？

2014年12月15日

MITOUJTAGのシンプル基板検査機能を使って、信号線が電源やGNDにショートしているかを検出できかどうか、実験してみました。

犠牲になったのは、ALTERAのFPGAが乗ったDE0というボード。

Cyclone3のEP3C16F484が乗っていて、バウンダリスキャンしてみると、こんな風にみえます。

マニュアルを見れば、GPIOの端子がFPGAのどの端子につながっているかわかります。そこで、AB16とAA16、AA13とGND、U13と3.3Vをショートさせてみようと思います。

念のため、ショートさせる前の状態で基板検査機能を実行してみると・・

このように、AA13、AA16、AB16、U13の各端子はプルアップと表示され、どこにも接続されている箇所はありません。

では、基板をショートさせてみましょう。

De0_3_3

ショートさせてから基板検査を走らせてみると・・

AA16とAB16の相互ショートと、AA13のGNDへの短絡、U13の3.3Vへの短絡が検出されました。

MITOUJTAGの簡易接続検査機能は、信号線どうしのショートだけではなく、電源やGNDへの短絡もわかるので、結構便利かもしれません！

さて、ここでお知らせです。

この接続検査機能は、MITOUJTAG Proだけの機能でしたが、

なんと、この冬、2014年12月末に発売するMITOUJTAG Light版にも搭載予定です。

ただし、MITOUJTAG Lightは、非営利目的の個人利用専用です。

本来はPro版だけに乗せるはずの機能を個人向けの廉価版に乗せるわけですから、ずーっと販売していくわけにはいきません。

今回発売するMITOUJTAG Light 2.7のみの限定機能で、しかも、期間限定かつ数量限定とさせていただきます。何卒ご了承くださいませ。MITOUJTAG Lightをご注文いただいた先着数名の方のみ、この新しい機能をお使いいただけます。数量限定ですので、どうかお見逃しのないようお願いします。

MITOUJTAG Lightの情報は当ブログで少しずつ公開していきます。

MITOUJTAGの簡易接続検査機能

2014年12月13日

MITOUJTAG Proには、簡易接続検査機能という、とーっても手軽な基板検査機能があります。

ネットリストとか細かい設定といった事前準備なしでいきなり検査しても、いろいろわかります。詳しい使い方は下記のページに書いたのですが、

http://www.tokudenkairo.co.jp/jtag/tutorial/tutorial1-12.html

とりあえず、どんなものかサワリだけ紹介します。

ここに、Spartan-6評価ボードがあります。

よく見ると、右下の39と40と書かれたピンヘッダがはんだでブリッジしています。

こんなときに「簡易検査機能」を使うと・・

このように、表示されます。

HDR_B_BP<34>という信号がHDR_B_BP<35>につながっていて、HDR_B_BP<35>がHDR_B_BP<34>につながっているのですから、ショートしているというわけです。

インターコネクトテストとは違い、FPGAが基板上に1個だけ、あるいはCPUが1個だけ、という基板でも、ショートしているのを発見できます。

目視やテスター、オシロではなかなか発見できないショートも、このツールを使えば3分以内に見つけられるのでなかなか便利ですよ。

ぜひお試しあれ！

FlashAirでWi-Fi JTAGができた！

2014年12月8日

昨日、セミナーを開催している間に、特電のスタッフが事務所でFlashAirをつかったWi-Fi JTAGの実験をしてくれました。

前回の記事では、Wi-Fi JTAGがなんとか動いているかどうかといった感じだったのですが、実際のデバイスとキャプチャしたIDCODEが違うという問題が起きていました。その原因は、使っていたボードに2つのJTAGデバイスが乗っていたためでした。

電気的な問題や、ソフト的な問題が起きていたわけではなかったようでひと安心。FlashAirのGPIOを直接JTAGデバイスにつないでもとりあえず動作はするのですが、安心のため、バッファを入れることにしました。

相変わらず遅いですね～。緑がTMS、青がTDO、橙がTCKです。1bitの操作で0.2秒くらいかかっています。自動的にデータを送った時は、大体1回のHTTP GETの送受信に220～230ms掛かっています。

そのスタッフが、このFlashAirの操作をJavaScriptを使ってサクッと自動化してくれました。とても優秀なスタッフに恵まれて私は幸せです。

このように、FlashAirのWi-Fi経由でJTAGのIDCODEを調べるスクリプトがブラウザの中で動いています。

-----------------------------------------------------------------
 JTAGを操作して、Device IDを読み込むデモです。
{"STATUS":"OK","CTRL":"0x0d","DATA":"0x12"}
{"STATUS":"OK","CTRL":"0x0d","DATA":"0x16"}
{"STATUS":"OK","CTRL":"0x0d","DATA":"0x17"}
{"STATUS":"OK","CTRL":"0x0d","DATA":"0x16"}
{"STATUS":"OK","CTRL":"0x0d","DATA":"0x17"}
{"STATUS":"OK","CTRL":"0x0d","DATA":"0x16"}
{"STATUS":"OK","CTRL":"0x0d","DATA":"0x17"}
{"STATUS":"OK","CTRL":"0x0d","DATA":"0x16"}
{"STATUS":"OK","CTRL":"0x0d","DATA":"0x17"}
{"STATUS":"OK","CTRL":"0x0d","DATA":"0x16"}
{"STATUS":"OK","CTRL":"0x0d","DATA":"0x17"}
{"STATUS":"OK","CTRL":"0x0d","DATA":"0x16"}
{"STATUS":"OK","CTRL":"0x0d","DATA":"0x12"}
{"STATUS":"OK","CTRL":"0x0d","DATA":"0x13"}
{"STATUS":"OK","CTRL":"0x0d","DATA":"0x12"}
{"STATUS":"OK","CTRL":"0x0d","DATA":"0x16"}
{"STATUS":"OK","CTRL":"0x0d","DATA":"0x17"}
{"STATUS":"OK","CTRL":"0x0d","DATA":"0x16"}
{"STATUS":"OK","CTRL":"0x0d","DATA":"0x12"}
{"STATUS":"OK","CTRL":"0x0d","DATA":"0x13"}
{"STATUS":"OK","CTRL":"0x0d","DATA":"0x12"}
{"STATUS":"OK","CTRL":"0x0d","DATA":"0x13"}
{"STATUS":"OK","CTRL":"0x0d","DATA":"0x12"}
FlashAirに書き込む平均待ち時間は :  228.91304347826087 [ms]でした。(N =  23  )
[1, 1, 0, 0, 1, 0, 0, 1, 0, 0, 0, 0, 0, 1, 1, 0, 0, 0, 1, 0, 0, 0, 0, 0, 1, 0, 1, 0, 1, 1, 1, 1]
-----------------------------------------------------------------

ちゃんと、0xF5046093と見えています。これはXILINXのコンフィグROM、XCF04SのIDCODEですね。

わずか2日でここまでできるとは・・

次回は、複数のデバイスの認識に対応させたり、特電のWebサイト中にIDCODE→デバイス名の候補を調べるAPIを作ったりして遊んでみることにします。

MITOUJTAGでインターコネクトテストができるようになった

2014年12月8日

ついに、MITOUJTAGにインターコネクトテストの機能を追加できました。

今回も検証に使っているボードはBLANCAです。

Blanca_ic

MITOUJTAGの画面では３つのICが見えています。

ネットリストを読み込みます。

基板ファンクションテストツールを起動し、インターコネクトテストのモジュールを追加します。

すると、ネットリストから接続されている信号を抽出して、検査手順が自動的に生成されます。

Extest 2 U1 XC3S1500-FG456
Check _CFG_NCS_U1 2:AA3 U1 SYS_RST_PIN 1:58 U7 CFG0_NCS 
Check _L_NBE[0] 2:AA16 U1 L_NBE<0> 3:T4 U2 L_NBE<0> 
Check _L_NBE[1] 2:V17 U1 L_NBE<1> 3:D3 U2 L_NBE<1> 
Check _L_NBE[2] 2:AA19 U1 L_NBE<2> 3:E3 U2 L_NBE<2> 
Check _L_NBE[3] 2:W17 U1 L_NBE<3> 3:L5 U2 L_NBE<3> 
Check _L_NCS[0] 2:V14 U1 L_NCS<0> 3:M3 U2 L_NCS<0> 
Check _L_NCS[1] 2:AB16 U1 L_NCS<1> 3:N3 U2 L_NCS<1> 
Check _L_NCS[2] 2:W14 U1 L_NCS<2> 3:V1 U2 L_NCS<2> 
Check _L_NCS[3] 2:U14 U1 L_NCS<3> 3:V2 U2 L_NCS<3> 
Check _L_NCS[4] 2:AA13 U1 L_NCS<4> 3:T2 U2 L_NCS<4> 
Check _L_NCS[5] 2:U11 U1 L_NCS<5> 3:T1 U2 L_NCS<5> 
Check _L_NCS[6] 2:Y13 U1 L_NCS<6> 3:N2 U2 L_NCS<6> 
Check _L_NCS[7] 2:V5 U1 L_NCS<7> 3:M2 U2 L_NCS<7> 
Check _L_NINT[0] 2:W7 U1 IOP_NINT<0> 3:V3 U2 IOP_NINT<0> 
Check _L_NINT[1] 2:V7 U1 IOP_NINT<1> 3:V5 U2 IOP_NINT<1> 
Check _L_NINT[2] 2:U7 U1 IOP_NINT<2> 3:U2 U2 IOP_NINT<2> 
Check _L_NINT[3] 2:Y10 U1 IOP_NINT<3> 3:U4 U2 IOP_NINT<3> 
Check _L_NRD 2:U13 U1 L_NRD 3:U11 U2 L_NRD 
Check _L_NWAIT 2:V13 U1 L_NWAIT 3:U7 U2 L_NWAIT 
Check _L_NWR 2:W13 U1 L_NWR 3:U10 U2 L_NWR 
Check _PCI_NDEVSEL 2:B11 U1 PCI_NDEVSEL 3:C18 U2 PCI_NDEVSEL 
Check _PCI_NFRAME 2:C12 U1 PCI_NFRAME 3:A11 U2 PCI_NFRAME 
Check _PCI_NINTA 2:B13 U1 PCI_NINTA 3:A12 U2 PCI_NINTA 
Check _PCI_NINTB 2:A13 U1 PCI_NINTB 3:A13 U2 PCI_NINTB 
Check _PCI_NINTC 2:C18 U1 PCI_NINTC 3:E12 U2 PCI_NINTC 
Check _PCI_NINTD 2:D18 U1 PCI_NINTD 3:C13 U2 PCI_NINTD
・・・
Check ROM_A[6] 1:120 U7 ROM_A<6> 2:A4 U1 ROM_A<6> 
Check ROM_A[7] 1:119 U7 ROM_A<7> 2:B4 U1 ROM_A<7> 
Check ROM_A[8] 1:118 U7 ROM_A<8> 2:A9 U1 ROM_A<8> 
Check ROM_A[9] 1:117 U7 ROM_A<9> 2:B9 U1 ROM_A<9> 
End

そして、スタートボタンを押しますと・・

接続検査ができました！

１つ１つの配線がつながっているかどうかを、この手順に従って検査してくれます。

-------2014/12/08 21:43:59 スクリプト実行開始-------
2番目のデバイス(U1:XC3S1500-FG456)から信号を出力します。
信号'_CFG_NCS_U1'の接続を検査します。
  デバイス'U1' ピン名'SYS_RST_PIN' ピン番号'2:AA3' => 初期値:プルアップ
   => U7:CFG0_NCS(1:58) への接続 STA=b 正常
信号'_L_NBE[0]'の接続を検査します。
  デバイス'U1' ピン名'L_NBE<0>' ピン番号'2:AA16' => 初期値:プルアップ
   => U2:L_NBE<0>(3:T4) への接続 STA=b 正常
信号'_L_NBE[1]'の接続を検査します。
  デバイス'U1' ピン名'L_NBE<1>' ピン番号'2:V17' => 初期値:プルアップ
   => U2:L_NBE<1>(3:D3) への接続 STA=b 正常
信号'_L_NBE[2]'の接続を検査します。
  デバイス'U1' ピン名'L_NBE<2>' ピン番号'2:AA19' => 初期値:プルアップ
   => U2:L_NBE<2>(3:E3) への接続 STA=b 正常
信号'_L_NBE[3]'の接続を検査します。
  デバイス'U1' ピン名'L_NBE<3>' ピン番号'2:W17' => 初期値:プルアップ
   => U2:L_NBE<3>(3:L5) への接続 STA=b 正常
信号'_L_NCS[0]'の接続を検査します。
  デバイス'U1' ピン名'L_NCS<0>' ピン番号'2:V14' => 初期値:プルアップ
   => U2:L_NCS<0>(3:M3) への接続 STA=b 正常
信号'_L_NCS[1]'の接続を検査します。
  デバイス'U1' ピン名'L_NCS<1>' ピン番号'2:AB16' => 初期値:プルアップ
   => U2:L_NCS<1>(3:N3) への接続 STA=b 正常
信号'_L_NCS[2]'の接続を検査します。
  デバイス'U1' ピン名'L_NCS<2>' ピン番号'2:W14' => 初期値:プルアップ
   => U2:L_NCS<2>(3:V1) への接続 STA=b 正常
信号'_L_NCS[3]'の接続を検査します。
  デバイス'U1' ピン名'L_NCS<3>' ピン番号'2:U14' => 初期値:プルアップ
   => U2:L_NCS<3>(3:V2) への接続 STA=b 正常
信号'_L_NCS[4]'の接続を検査します。
  デバイス'U1' ピン名'L_NCS<4>' ピン番号'2:AA13' => 初期値:プルアップ
   => U2:L_NCS<4>(3:T2) への接続 STA=b 正常
信号'_L_NCS[5]'の接続を検査します。
  デバイス'U1' ピン名'L_NCS<5>' ピン番号'2:U11' => 初期値:プルアップ
   => U2:L_NCS<5>(3:T1) への接続 STA=b 正常
信号'_L_NCS[6]'の接続を検査します。
  デバイス'U1' ピン名'L_NCS<6>' ピン番号'2:Y13' => 初期値:プルアップ
   => U2:L_NCS<6>(3:N2) への接続 STA=b 正常
信号'_L_NCS[7]'の接続を検査します。
  デバイス'U1' ピン名'L_NCS<7>' ピン番号'2:V5' => 初期値:プルアップ
   => U2:L_NCS<7>(3:M2) への接続 STA=b 正常
信号'_L_NINT[0]'の接続を検査します。
  デバイス'U1' ピン名'IOP_NINT<0>' ピン番号'2:W7' => 初期値:プルアップ
   => U2:IOP_NINT<0>(3:V3) への接続 STA=b 正常
信号'_L_NINT[1]'の接続を検査します。
  デバイス'U1' ピン名'IOP_NINT<1>' ピン番号'2:V7' => 初期値:プルアップ
   => U2:IOP_NINT<1>(3:V5) への接続 STA=b 正常
信号'_L_NINT[2]'の接続を検査します。
  デバイス'U1' ピン名'IOP_NINT<2>' ピン番号'2:U7' => 初期値:プルアップ
   => U2:IOP_NINT<2>(3:U2) への接続 STA=b 正常
信号'_L_NINT[3]'の接続を検査します。
・・・
・・・
  デバイス'U7' ピン名'ROM_A<8>' ピン番号'1:118' => 初期値:プルアップ
   => U1:ROM_A<8>(2:A9) への接続 STA=b 正常
信号'ROM_A[9]'の接続を検査します。
  デバイス'U7' ピン名'ROM_A<9>' ピン番号'1:117' => 初期値:プルアップ
   => U1:ROM_A<9>(2:B9) への接続 STA=b 正常
385個の配線を検査し、0個の異常を発見しました
-------2014/12/08 21:44:06 スクリプト終了-------

この検査では、あるソース信号をH→Z→L→Zと変化させ、目的の端子がどのように変化するかを見ています。そして、

目的の端子に正しく接続されているか？
オープンか、ショートか、もしくは抵抗でプルアップか、プルダウンされているか？

を検査対象のすべての端子に対して検査していきます。

現時点ではこの検査手順も、検査結果の表示もテキストですが、ゆくゆくはGUI化していきたいと思います。

Vivadoの制約ファイルxdcを読み込めるようになった

平成26年12月5日

XILINXの論理合成ツールVidadoでは、ピン定義などの制約がUCFではなく、xdcというファイルに変わりました。今までのMITOUJTAGでは制約ファイルのUCFや、成果物ファイルのPADは読み込めたのですが、Vivadoの制約「XDC」には対応していませんでした。

そんなある日、（昨日ですが・・）、Vidadoで使っていらっしゃるお客様がVivadoのピン定義が読み込めないという問合せがあったので、本日、すぐに対応しました。

検証用にVivadoのツールの中に入っているサンプルデザインを使いました。

このサンプルデザインは、FPGAの型番はxc7k70tfbg676のようでした。MITOUJTAGを起動して、デバイスを追加します。

壮観な風景ですね。

そして、このKintexの上にマウスを合わせ右クリックし、「ピン定義ファイルの登録」を実行します。

そして、Vivadoの論理合成で指定したxdcファイルを選択します。

XDCファイルはこんな感じのファイルで、

どうやら、

set_property PACKAGE_PIN ピン番号 [get_ports 信号名]

という書式でピンの定義が並んでいるようです。

ちゃんと読み込めたかどうかは、ロジアナモードにして確認します。

このとおり、XDCの中にあるピン定義が読み込まれています。

MIOUJTAGはVivadoの制約ファイルを読み込めるようになりました。

こちらのURLからダウンロードしていただけます。

https://www.tokudenkairo.co.jp/login2/getfile.php?target=MJVIVADO_PATCH

今回の対応はお客様からのご要望を反映したものです。MITOUJTAGについてご意見ご要望などあればぜひぜひお寄せください。

MITOUJTAGに基板接続検査機能を開発中

2014年12月4日(木)

MITOUJTAGに基板接続検査機能を開発しています。

開発用に、BLANCAという評価ボードを便利に使っています。

このボードは、3つのCPLDとFPGAがバスでがっちり結ばれているので、接続検査のテストには最適なのです。

まず、MITOUJTAGで認識すると・・

このように3つのICが見えます。

そして、ネットリストを読み込みます。

そしたら、基板検査ツールを立ち上げ、デバイスの割り当てという作業を行います。

この作業は、U1のXC3S1500がJTAGの2番目、U2のXC3S400がJTAGの3番目、U7のCPLDがJTAGの1番目のデバイスであることをツールに知らせるものです。

そして、検査モジュールの「インターコネクトテスト」を読み込むと・・

検査すべき手順を自動的に生成してくれました。

これは、ネットリストを読んで、JTAGデバイス同士がつながっているところを探して列挙したものです。JTAGデバイス同士であっても、入力専用ピンからは出力しないようになっていますし、GNDにつながっているような端子は動かさないようにしています。

そして、実行ボタンを押すと・・

この手順に沿ってバウンダリスキャンを実行してくれるというわけです。

今日のところはまだ実際のバウンダリスキャンを実行するところまではできていませんが、あと１日くらいでできるでしょう。

①　デバイスを自動認識する
②　ネットリストを読み込む
③　ネットリスト上のICと、JTAGチェーン上のデバイスを結びつける
④　インターコネクト・アルゴリズムを選ぶ
⑤　実行ボタンを押す

という簡単な手順で接続検査ができるようになるまで、あと少しです！

FlashAirのGPIOモードでJTAGを操作する

平成26年12月3日(水)

最近、FlashAirというWiFi対応SDカードから、GPIOが出せるとかなんとかいうことで、人気のようです。そこで、特電は特電らしく、FlashAirをWiFi-JTAG化できないかと思い、試してみることにしました。

つまり、FlashAirを単体で、無線LAN経由のJTAGアダプタにしてしまおうというわけです。

FlashAirのチュートリアルはこちらにあります。

https://flashair-developers.com/ja/documents/tutorials/arduino/1/

知りたい点は2つです。

JTAG化したときに、どのくらいの速さが出るのか？
1bitごとに1パケット送るのか？バルク転送みたいなものが存在しないか？

早速、FlashAirを入手し、ピッチ変換基板と万能機版で治具を作りますした。そして、適当な評価ボード（ここではXILINXのSpartan-3A評価ボード）のJTAG端子に、FlashAirのGPIOとなった各端子を接続します。

GPIO機能を使うためには、IFMODE=1かつ「ホスト側からの初期化がない」場合だそうです。その時、CMDとD1～4がGPIOになるようです。よって、端子の割り当ては、

SDカード端子名  ビット  JTAG機能割当てピン
CMD/SDI         0x01    TCK
D0/SDO          0x02    TDO
D1              0x04    TMS
D2              0x08    -
D3/CS           0x10    TDI

としました。

IFMODEに関しては、/SD_WLAN/CONFIGというファイルに書き込んで設定します。

FlashAirのCONFIGファイルはこんな感じです。

[Vendor]

CIPATH=/DCIM/100__TSB/FA000001.JPG
APPMODE=6
APPNETWORKKEY=********
VERSION=F19BAW3AW2.00.03
CID=●●●●●●●●●●●●●●●●●
PRODUCT=FlashAir
VENDOR=TOSHIBA
BRGSSID=●●●●●●●●●●●
BRGNETWORKKEY=******************
IFMODE=1
MASTERCODE=●●●●●●●●●●
LOCK=1
APPSSID=flashair_●●●●●●●●●●
FORMATSETMODE=1

固有情報やSSIDなどは●で隠していますのでご了承ください。

転送速度ですが、

「Maker Faire Tokyo 2014：メイカーは「リレカチ」がお好き (2/2) - MONOist（モノイスト）」http://monoist.atmarkit.co.jp/mn/articles/1412/01/news068_2.html
を見ると、約1.8bpsと書いてある。遅いですね…

FlashAirのファームウェアの更新に期待します。簡単なプログラムが使えるようになるか、バルク転送のようなものができるといいのですが・・

FlashAirのGPIOにアクセスするには、HTTPのGETやPOSTでデータを送るようです。つまり、

http://flashair/command.cgi?op=190&CTRL=0x1f&DATA=0x05

のようにしてアクセスすると、0x05に対応した値にGPIOが変化するというわけです。

気が遠くなりそうな話ですね・・

ちょっと気になった点は、FlashAirのI/Oの出力駆動能力があまり高くないかもしれないということです。

実際にSDカードの端子5つに100Ωを介して赤色LED(Vf≒2V)を接続したところ、GPIO出力が3.28V→2.8Vまで電圧降下した。8mA程度までしか流せないのかもしれません。

さて、いよいよJTAGの信号を出してみることにします。

まずはターゲットICのIDCODEを調べましょう。

JTAGのIDCODEを調べるためには、

TMS='1'にしたあとTCKを5cycle、のちTMS='0'
TMS='0'でTCKを1cycle
TMS='1'にしたあと、TCKを1cycle
TMS='0'にしたあと、TCKを2cycle
以後、TMS='0'のままTCKをたくさん与える
TCKの立ち下がりで、TDOに1bitずつ、LSBからIDCODEから出力される。

実際に、URLを全部手打ちでGPIOを操作し、受信してみました。

command.cgiに、?op=190&CTRL=0x1f&DATA=0x05 のように引数を付けるとGPIOからその値が出力され、ブラウザの画面にGPIOを読んだ値が表示されます。

いわゆるJSON形式なのでしょう、

　{"STATUS":"OK","CTRL":"0x1f","DATA":"0x1f"}

のように表示されます。

FlashAirに対し、ベタに何度も何度もアクセスします。

URLに投げたGETリクエストは、以下のようなもの
http://flashair/command.cgi?op=190&CTRL=0x1f&DATA=0x00	// clear

http://flashair/command.cgi?op=190&CTRL=0x1f&DATA=0x04	// TMS up

// TMS = 1, 5cycle
http://flashair/command.cgi?op=190&CTRL=0x1f&DATA=0x05	// TCK raise
http://flashair/command.cgi?op=190&CTRL=0x1f&DATA=0x04	// TCK fall
http://flashair/command.cgi?op=190&CTRL=0x1f&DATA=0x05
http://flashair/command.cgi?op=190&CTRL=0x1f&DATA=0x04
http://flashair/command.cgi?op=190&CTRL=0x1f&DATA=0x05
http://flashair/command.cgi?op=190&CTRL=0x1f&DATA=0x04
http://flashair/command.cgi?op=190&CTRL=0x1f&DATA=0x05
http://flashair/command.cgi?op=190&CTRL=0x1f&DATA=0x04
http://flashair/command.cgi?op=190&CTRL=0x1f&DATA=0x05
http://flashair/command.cgi?op=190&CTRL=0x1f&DATA=0x04	

http://flashair/command.cgi?op=190&CTRL=0x1f&DATA=0x00	// clear

// TMS = 0, 1cycle
http://flashair/command.cgi?op=190&CTRL=0x1f&DATA=0x01	// TCK raise 
http://flashair/command.cgi?op=190&CTRL=0x1f&DATA=0x00	// TCK fall

// TMS = 1, 1cycle
http://flashair/command.cgi?op=190&CTRL=0x1f&DATA=0x04	// TMS up
http://flashair/command.cgi?op=190&CTRL=0x1f&DATA=0x05	// TCK raise
http://flashair/command.cgi?op=190&CTRL=0x1f&DATA=0x04	// TCK fall
http://flashair/command.cgi?op=190&CTRL=0x1f&DATA=0x00	// clear

// TMS = 0, 1cycle
http://flashair/command.cgi?op=190&CTRL=0x1f&DATA=0x01	// TCK raise 
http://flashair/command.cgi?op=190&CTRL=0x1f&DATA=0x00	// TCK fall

// TMS = 0, 1cycle
http://flashair/command.cgi?op=190&CTRL=0x1f&DATA=0x01	// TCK raise 
http://flashair/command.cgi?op=190&CTRL=0x1f&DATA=0x00	// TCK fall

// now we can read TDI @ 32cycles...
http://flashair/command.cgi?op=190&CTRL=0x0D&DATA=0x01	// TCK raise 
http://flashair/command.cgi?op=190&CTRL=0x0D&DATA=0x00	// TCK fall
// read TDI

http://flashair/command.cgi?op=190&CTRL=0x0D&DATA=0x01	// TCK raise 
http://flashair/command.cgi?op=190&CTRL=0x0D&DATA=0x00	// TCK fall
// read TDI
※以下、上の0x01、0x00を繰り返し、[7..0]中の[1](TDI)を読み出す。

すると、

LSB(最初に受信した方)		MSB
1100100100000110001000001010111110010
3   9   0   6   8   0   5   F   B   0

正解のIDは22628093ですから、

MSB							 LSB
00100010011000101000000010010011
2   2   6   2   8   0   9   3

こうなるはずです。近いような値だけど、微妙に違っているので、やはりFlashAirの出すJTAG信号はFPGAが正常に認識できていないようです。その原因としてTCKの波形の鈍りが疑わしいので、次回はバッファを入れて試してみることにします。

MITOUJTAGでインターコネクトテストに成功

平成26年10月1日

MITOUJTAGの新・基板検査機能として、インターコネクトテスト機能を開発しています。

インターコネクトテストというのは、JTAGバウンダリスキャン対応のデバイス同士の配線の接続検査です。一方のICからテストパターンを出して、もう一方のICで正しく受け取れるかどうかを見ます。

したがって、FPGAやCPUやCPLDが2個以上、太いバスでつながっている基板を使って検証するのですが、そういう基板はなかなかありません。最近では大きなFPGA1個に入れてしまうので・・なかなかそういったものは・・

・・

いや、あるじゃないですか！

それは、BLANCAです。

BLANCAは、確か、2つのFPGAがローカルバスとPCIバスでつながっていて、しかも、SDRAMやNORフラッシュもついているはず。

想像ですが、こんな感じだったような・・

BLANCAでは、2個のFPGAの間を、ローカルバスとPCIバスでつないでいて、中央のFPGAはSDRAM(32bitデータ幅)とCPLDがつながっていて、CPLDにはNOR型フラッシュROMがつながっています。

FPGA間のローカルバスは、アドレス29bit、データ32bitという超太い配線です。他にも割り込み信号があったと思います。

まさにインターコネクトテストのために生まれてきたようなボードではないでしょうか！？？

手元にネットリストのファイルがないので、自分で作るしかありません。とりあえず回路図をみながらネットリストのようなものを打ち込んでいきます。

$PACKAGES
FG456! XC3S1500-FG456; U1
FG456! XC3S400-FG456; U2
TSOP! MT48LC4M32B2TG; U4
TQ144! XC95288XL-TQ144; U7
$NETS
SD_CLK;  U1.N3 U4.68
SD_CKE;  U1.M3 U4.67
SD_nCS;  U1.W1 U4.20
SD_nRAS;  U1.M2 U4.19
SD_nCAS;  U1.Y2 U4.18
SD_nWE;  U1.N1 U4.17
SD_DQM<0>;  U1.N2 U4.16
SD_DQM<1>;  U1.P4 U4.71
SD_DQM<2>;  U1.H1 U4.28
SD_DQM<3>;  U1.H2 U4.59
SD_MBA<0>;  U1.L2 U4.22
SD_MBA<1>;  U1.K2 U4.23
・・・

こんな感じで書いていきます。全部を書くと大変なので、SDRAMと最低限の接続だけ書いてみました。

接続検査のための配線接続を抽出すると、次のようになります。

Name     PCI_AD
FromAddr IOB
ToAddr   AVP
From     2:B19 A12 F17 E13 B14 A14 B15 A15 F12 F13 E14 F16 B16 A16 B17 B18 D19 E18 G18 F18 C22 D21 F19 E21 E20 E19 D20 G22 E22 F21 D22 G21
To       3:F13 D13 E14 D14 B13 A14 B14 B19 E15 D15 F16 E16 B18 C17 B17 B15 G17 D19 D20 E19 K22 K21 G22 G21 E20 E18 F20 G18 F21 E22 E21 D21

Name     PCI_AD
FromAddr AVP
ToAddr   IOB
From     3:F13 D13 E14 D14 B13 A14 B14 B19 E15 D15 F16 E16 B18 C17 B17 B15 G17 D19 D20 E19 K22 K21 G22 G21 E20 E18 F20 G18 F21 E22 E21 D21
To       2:B19 A12 F17 E13 B14 A14 B15 A15 F12 F13 E14 F16 B16 A16 B17 B18 D19 E18 G18 F18 C22 D21 F19 E21 E20 E19 D20 G22 E22 F21 D22 G21
 
Name     PCI_CTRL
FromAddr IOB
ToAddr   AVP
From     2:D18 C18 A13 B13 K17 K18 H22 C19 D17 C17 B11 C12 E17 A18 C21 C20
To       3:C13 E12 A13 A12 E13 A19 G19 F17 D17 B11 C18 A11 E17 A15 F18 C22
 
Name     PCI_CTRL
FromAddr AVP
ToAddr   IOB
From     3:C13 E12 A13 A12 E13 A19 G19 F17 D17 B11 C18 A11 E17 A15 F18 C22
To       2:D18 C18 A13 B13 K17 K18 H22 C19 D17 C17 B11 C12 E17 A18 C21 C20

上のデータは、PCIのADバスと制御信号の接続検査をするためのものです。出力側と入力側を入れ替えて、このパラメータでインターコネクトテストを行ってみました。

まず、PCI_ADバスが1ビットずつ動いていきます。

それが終わったら、こんどは制御線が1ビットずつ動いていきます。

コンソールの画面にはこのように表示されます。

以上で示したように、指定されたバスに対してWalking '0'とWalking '1'を行って、接続が正しく行われているかを調べるというわけです。

今は配線接続を抽出が完全には自動化できていないのですが、もう少し進めば、マウスでポチポチとやるだけで、基板全体を網羅するような接続検査ができるようになると思います。

また、BLANCAのネットリストからSDRAMの配線を自動的に推定することもできました。以下が、SDRAMを制御するためのFPGAの端子です。

CAS 2:Y2
CKE 2:M3
CLK 2:N3
CS 2:W1
RAS 2:M2
WEN 2:N1
DQ 2:G4 2:G3 2:G1 2:F2 2:F3 2:E2 2:F4 2:E3 2:C2 2:D3 2:D1 2:D2 2:C3 2:C4 2:E1 2:C1 2:Y1 2:W2 2:V2 2:M1 2:N4 2:T3 2:T4 2:R4 2:P1 2:P2 2:R1 2:R2 2:T1 2:T2 2:U3 2:V1 
ADDR 2:Y3 2:K1 2:G2 2:L3 2:L4 2:K3 2:K4 2:J4 2:H4 2:J1 2:L1 2:J2 
BA 2:K2 2:L2 
DM 2:H2 2:H1 2:P4 2:N2

例えば、RASを動かしたいならば、2番目のJTAGデバイスのM2番ピン動かすということです。

こうしてSDRAM検査アルゴリズムを実行したらちゃんと読み書き検査ができました。

検査時はバウンダリスキャンを使って、FPGAからこんな波形を送り込んでいます。

このように、ほぼマウスクリックだけで様々な検査ができるようなツールをめざして、日々改良を続けています。

バウンダリスキャンでDDR2 SDRAMをテスト

平成26年9月12日

MITOUJTAGに基板検査機能を追加しています。

DDR2メモリの検査プログラムを手直しして、パラメタライズできるようにしました。

まずは、Spartan-6ボードのDDR2 SDRAM。これはCAS ADDRが10bit、BANK ADDRが2bit、RAS ADDRが14bitのものです。計26本のアドレス線があってデータバスは8bitなので、64MBytesの容量があります。

このSDRAMのデータ線と、アドレス線を1本ずつHにして、メモリに読み書きをします。

このようにして、データ線やアドレス線の切れている箇所を発見しようというわけです。

次はEXPARTAN-6Tに搭載されているDDR2 SDRAM。これはCAS ADDRが10bit、BANK ADDRが3bit、RAS ADDRが13bitのものです。計26本のアドレス線があってデータバスは16bitなので、128MBytesの容量があります。

こういう波形を、C言語で手順を書いてパソコンからJTAGを使ってFPGAを遠隔操作して実行します。

VHDLとかでFPGAのソースコードを書いて論理合成して実行するのではないので、非常に手軽にできます。

これらの検査が同じソースから行えるようになって、また、ネットリストから自動的にFPGAの端子の機能を推測できるようになったというわけです。

MITOUJTAGの基板検査機能の開発

平成26年9月9日

MITOUJTAGに基板検査機能を実装中です。

この数か月の成果がようやく結びついてきました。

今日、テスト用に用いたのが特電製の究極のRX62Nボード 。RXマイコンボードで、JTAG端子が出ていて、バウンダリスキャンができます。

MITOUJTAGで認識させるとこうなります。

さて、ここまでは今までのMITOUJTAGと同じです。

新しいMITOUJTAG 2.7では、ネットリストの読み込み機能があります。プロジェクトツリーの中にある「ネットリスト」で読み込めば、ネットリストを解釈してどの部品が何とつながっているかを把握してくれます。

ネットリストというのは、その基板を設計した者なら持っているはずのファイルです。回路の信号の結線情報と部品情報が載っています。いろいろな形式があるのですが、たとえば、なひたふが好んで使っているTELESISというネットリストの形式ではこんな感じです。

まず部品のリストがあって、

R5F562N8BDBG! RX62N_R5F562N8BDBG_1; U1
MT48LC4M32B2B5! MT48LC4M32B2B5; U2
LAN8720Ai! LAN8720AI; U3
UPD78F0731! UPD78F0731; U4
・・・

その後に接続情報があります。

78K_USBP;  CN7.3 R36.2 R46.2
78K_VUSBREGC;  C53.2 Tr2.2 U4.12
78K_X1;  U4.8 X4.3
78K_X2;  U4.7 X4.1
AGND;  C3.1 C4.1 C56.2 C57.2 ,
     L4.2 U1.A1 U1.B3
ALL_RESET;  C49.2 J5.2 R30.1 SW2.1 ,
     TP3.1 U4.5
AV3REF;  C3.2 C57.1 L3.2 U1.B2
AV33;  C4.2 C56.1 L2.2 U1.A2
AV33PLL;  C2.2 C55.2 C58.1 L5.2 ,
     U1.P2
BCLK;  RP6.1 U1.R10
CNVSS;  R8.2 U1.E2
・・・

そして、ツールメニューの中から「基板ファンクションテスト」を選びます。

すると、こんな画面が現れます。

最初の状態ではInfraというテストしかありません。ここで、「デバイスの割り当て」というボタンを押します。

すると、ダイアログが開いて、回路図上の「U*」という部品番号とJTAGチェーン上のデバイスとの対応付けを行います。今回はU1がJTAGチェーン上の唯一のデバイスです。

そうしたら、元の画面に戻って、「検査項目の追加」というボタンを押します。プルダウンメニューが開くので、SDR SDRAMを選択します。

SDR SDRAMという項目が増えました。

そうしたら、SDR SDRAMのところをダブルクリックするか、「デバイス・ピン」の割り当て、ボタンを押します。そして、「どのデバイスを検査しますか？」となっているところをU2: MT48LC4M32B25を選択します。

すると、上の図のように、ネットリスト中にある信号名から「アドレスっぽい」「データっぽい」という曖昧な検索によって自動的に機能を推測してくれます。

つまり、SDRAM_CAS#はCAS信号だろう、SDRAM_A10はアドレスの10番だろう・・というのを正規表現を使って推測して割り当てています。

で、FPGAのどの端子を動かせば、SDRAMのRASやCAS、DM等をうごかせるかというリストを作ってくれます。

CAS 1:A14
CKE 1:D15
CLK 1:B15
CS 1:A13
DM0 1:E14
DM1 1:E15
DM2 1:F14
DM3 1:G15
RAS 1:B12
WEN 1:B13
DQ 1:H12 1:G14 1:F15 1:F12 1:F13 1:E12 1:D10 1:A11 1:B9 1:B8 1:D8 1:C8 1:D7 1:C7 1:B6 1:A6 1:D14 1:C15 1:C14 1:D13 1:C13 1:B14 1:A15 1:C12 1:A12 1:B10 1:C10 1:A10 1:A9 1:A8 1:B7 1:A7 
ADDR 1:N15 1:L13 1:L14 1:M15 1:K12 1:K15 1:J14 1:J15 1:J13 1:H14 1:H15 1:H13   
BA 1:P15 1:M14

そして、Startボタンを押すと、自動推定されたピンを、あらかじめ決められたアルゴリズムで動かして、SDRAM等のファンクション・テストを行います。

SDRAMのテストは、データ線と、アドレス線がちゃんとつながっているかどうかを1本1本調べていくことができます。

このような形で、MITOUJTAGの基板検査機能が動きました。

ネットリスト中の信号名から、正規表現で機能を推定して、その端子につながるFPGA端子をバウンダリスキャンで動かして、SDRAMの書き込み信号や読み出し信号を作り出し、アドレス線、データ線、制御線にオープン/ショートがないかどうかを判断することができました。

ポイントは、ネットリストを読み込んだり、実行したいアルゴリズムを選んだだけで、一切キーボードから入力していないということです。

ついに、マウス操作だけで基板検査ができるようになったというわけです。

MITOUJTAGのネットリスト読み込み機能の開発

平成26年9月1日

MITOUJTAGのネットリスト読み込み機能を開発しています。目標は、ネットリストを読み込ませることで、各種の基板検査を自動的に行えるようにすること、です。

次のような感じになりました。

まず、例として特電Artix-7ボードのネットリストを読み込ませてみることにします。

Artix-7ボードのネットリストを読み込むと、その中に書かれているU?の部品番号の一覧が得られました。

Mj_netlist_load1_2

このU3、MT41J256M8という部品をダブルクリックすると、デバイスの種類を選択するダイアログが出ます。

Mj_netlist_load2

ここでクラスタデバイスを選びます。すると、どんな種類のデバイスかを選択するリストが出ます。

ここでDDR3 SDRAMを選びます。

すると、ソフトウェアはネットリスト中にある信号の名前をDDR3のものとして解釈します。

ピン DDR3_DQ0 は "データバス"。DQ(0) です
ピン DDR3_DM は "データマスク"。DMです。
ピン DDR3_DQ2 は "データバス"。DQ(2) です
ピン DDR3_DQSP は "データストローブP側"。DQSPです。
ピン DDR3_DQ1 は "データバス"。DQ(1) です
ピン DDR3_DQ3 は "データバス"。DQ(3) です
ピン DDR3_DQ6 は "データバス"。DQ(6) です
ピン DDR3_DQSN は "データストローブP側"。DQSPです。
ピン DDR3_DQ4 は "データバス"。DQ(4) です
ピン DDR3_DQ7 は "データバス"。DQ(7) です
ピン DDR3_DQ5 は "データバス"。DQ(5) です
ピン DDR3_RAS は "行アドレスイネーブル"。RASです。
ピン DDR3_CAS は "列アドレスイネーブル"。CASです。
ピン DDR3_CKE は "クロックイネーブル"。CKEです。
ピン DDR3_CS は "チップセレクト"。CSです。
ピン DDR3_WEN は "書き込みイネーブル"。WENです。
ピン DDR3_ADDR10 は "アドレスバス"。ADDR(10) です
ピン DDR3_BA0 は "バンクアドレス"。BA(0) です
ピン DDR3_BA2 は "バンクアドレス"。BA(2) です
ピン DDR3_ADDR3 は "アドレスバス"。ADDR(3) です
ピン DDR3_ADDR0 は "アドレスバス"。ADDR(0) です
ピン DDR3_ADDR12 は "アドレスバス"。ADDR(12) です
ピン DDR3_BA1 は "バンクアドレス"。BA(1) です
ピン DDR3_ADDR5 は "アドレスバス"。ADDR(5) です
ピン DDR3_ADDR2 は "アドレスバス"。ADDR(2) です
ピン DDR3_ADDR1 は "アドレスバス"。ADDR(1) です
ピン DDR3_ADDR4 は "アドレスバス"。ADDR(4) です
ピン DDR3_ADDR7 は "アドレスバス"。ADDR(7) です
ピン DDR3_ADDR9 は "アドレスバス"。ADDR(9) です
ピン DDR3_ADDR11 は "アドレスバス"。ADDR(11) です
ピン DDR3_ADDR6 は "アドレスバス"。ADDR(6) です
ピン DDR3_ADDR13 は "アドレスバス"。ADDR(13) です
ピン DDR3_ADDR14 は "アドレスバス"。ADDR(14) です
ピン DDR3_ADDR8 は "アドレスバス"。ADDR(8) です

回路図やネットリストは人間が作成しているものなので、データバスをDQという名前で付ける人もいれば、DATA[]という名前にする人もいます。括弧があったりなかったり、いろいろです。

そこで、この解釈の定義ファイルは正規表現を使って柔軟に記述できるようにしました。正規表現による信号名の定義はiniファイルに書かれていて、

[DDR3]
descr=DDR3 SDRAM
[DDR3.bus]
DQ=データバス
ADDR=アドレスバス
BA=バンクアドレス
[DDR3.pin]
RAS=行アドレスイネーブル
CAS=列アドレスイネーブル
WEN=書き込みイネーブル
CS=チップセレクト
CKE=クロックイネーブル
DM=データマスク
DQSP=データストローブP側
DQSN=データストローブN側
CKP=クロックP側
CKN=クロックN側
ODT=オンチップ終端
[DDR3.regex]
D[ATQ]?_?[\(\[]?([0-9]+)[\)\]]?=DQ
A[DR]+?_?[\(\[]?([0-9]+)[\)\]]?=ADDR
B[ANK]?A[DR]?_?[\(\[]?([0-9]+)[\)\]]?=BA
RAS=RAS
CAS=CAS
WE[_]?[N]?=WEN
CS=CS
CKE=CKE
(DM)|(DQM)=DM
DQS[P+]?=DQSP
DQS[MN-]=DQSN
=CK[P+]?=CKP
CK[MN-]=CKN
ODT=ODT

となっています。

これならどんな回路であっても柔軟に対応できるのではないかと思います。