2018年のJTAG開発日記

VivadoがUltraScake+を検出するときのJTAGのシーケンスは次のようになっています。

STATE RESET;
SDR 32 TDI (000000FF) TDO (28E20126);
STATE RESET;
SDR 1056 TDI (000000FF000000FF000000FF000000FF000000FF000000FF000000FF000000FF000000FF000000FF000000FF000000FF000000FF000000FF000000FF000000FF000000FF000000FF000000FF000000FF000000FF000000FF000000FF000000FF000000FF000000FF000000FF000000FF000000FF000000FF000000FF000000FF000000FF) TDO (000001FE000001FE000001FE000001FE000001FE000001FE000001FE000001FE000001FE000001FE000001FE000001FE000001FE000001FE000001FE000001FE000001FE000001FE000001FE000001FE000001FE000001FE000001FE000001FE000001FE000001FE000001FE000001FE000001FE000001FE000001FE000001FE28E20126);
SIR 192 TDI (FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFE) TDO (FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFE0751);
STATE RESET;

問題は2回目のSTATE RESETにありました。

最終送受信データの表示
tms: ff
11111111 01000000 00000000 00000000・・
tdi:
00000000 00001111 11110000 00000000・・
tdo:
11111111 11110110 01001000 00000100・・

開発中の新しいバージョンのMITOUJTAGを使って、VivadoからUltraScale+へのJTAGアクセスを解析できたのはいいのですが、それを目で追っていると大変なので、SVFフォーマットで出力できるようにしました。

それを見ると、かなりプライベート命令を使っているな・・という感想です。

アクセスの最初の部分を見ると、

SIR 16 TDI (902F) TDO (0411); // USER1
SDR 33 TDI (000000000) TDO (000000000);
STATE RESET;
SIR 16 TDI (7E4F) TDO (0411); // ???
SDR 33 TDI (000000000) TDO (060018202);
STATE RESET;
SIR 16 TDI (902F) TDO (0411); // USER1
SDR 18 TDI (1E000) TDO (38000);
SDR 77 TDI (00000000000000000152) TDO (00000000000000000548);
STATE RESET;
SIR 16 TDI (922F) TDO (0411); // USER3
SDR 18 TDI (1E000) TDO (38000);
SDR 77 TDI (00000000000000000152) TDO (00000000000000000548);
SIR 16 TDI (FFFF) TDO (0411);
SIR 16 TDI (903F) TDO (0411); // USER2
SDR 33 TDI (000000000) TDO (000000000);
SIR 16 TDI (FFFF) TDO (0411);
SIR 16 TDI (903F) TDO (0411); // USER2
SDR 43 TDI (000000000D2) TDO (00000000348);
SIR 16 TDI (FFFF) TDO (0411);
SIR 16 TDI (903F) TDO (0411); // USER2
SDR 7 TDI (18) TDO (60);
SDR 43 TDI (000000000D2) TDO (00000000348);
SIR 16 TDI (A32F) TDO (0411); // ????
SDR 97 TDI (0000000000000000000000000) TDO (0000000000000000000000000);
SIR 16 TDI (FFFF) TDO (0411);
SIR 16 TDI (0E4F) TDO (0411); // ????
SDR 33 TDI (000000000) TDO (000000000);
SIR 16 TDI (FFFF) TDO (0411);
・・・
SIR 16 TDI (824F) TDO (0751);
SDR 33 TDI (000000006) TDO (000000000);
・・・

となっています。USER1,2,3はILAなどの内蔵ロジアナを見るためのものだと思いますが、0x7E4F 0xA32F 0x0E4Fという秘密のプライベート命令なので何をやっているかわかりません。

ユーザガイドug1085にもug570にも記述はありません。また、BSDLファイルを解読しても、該当する命令はありません。自力で解析するしかなさそうです。

UltraScale+のJTAGコマンドは上位12bitがPS-PL系へのアクセスで、下位4bitがARM DAPへのコマンドなのですが、上記の解析結果からわかることは、

 

• 0x7E4は何かの32bitのステータスレジスタ読み出しで、VivadoがJTAGでアクセスをするとそのステータスは変わる。
• 0xA32は96bitのレジスタがつながる
• 0x0E4は32bitのレジスタがつながる
• 0ｘ824は32bitのレジスタがつながる

 

ということです。

UltraScale+のリセット後にDummy DAPからARM DAPに切り替えるJTAG_CTRL命令は見つかりませんでしたが、PS TAPとPL TAPを分離して考えると、上記のプライベート命令というのは既知の命令の組み合わせの表現なのかもしれません。

そう考えると、0x7E4というのは011111 & 100100なので、JTAG_STATUSコマンドとPLに対する24というコマンドの組み合わせです。JTAG_STATUSコマンドでPS TAP Controllerのステータスレジスタが見えるはずです。下位6bit(PL)に対する0x24のコマンドは公開されていませんが、データレジスタ長を0にする命令かもしれません。

0x7E4の後で32bitのDRをスキャンして0x060018202という結果を得ていますが、

と照らし合わせて、ビンゴじゃないかなと思います。

0xA32は101000 & 110010なのですが、これに該当する命令はありません。ですが、下位6bitの110010はFUSE_DNAコマンドの下位6bitと一致するので、FUSE_DNAを読み出しているのだろうと推測されます。一回しか試せなさそうですが、FUSE_DNAを書き込んで試してみたいところです。上位6bit(PS)に対する0x28もレジスタ長を0にするものかもしれません。

0x0E4は、000011 & 100100と読めるので、PSに対するPMU_MDM命令と解釈できそうです。

0x824は、100000 & 100100と読めるので、PSに対するJTAG_CTRLコマンドで、直後のSDRに6を与えているので、PS TAPとPL TAPとARM DAPを接続するようです。

まとめると

• 0x7E4はPSのステータス読み出し
• 0xA32はDNAの読み出し
• 0x0E4はPMUのMicroblaze Debug Moduleへのアクセス
• 0x824と続く0x00000006はJTAGチェーンの正常化

なのかと推測されます。

それ以外の902や903、922はUSER1,2,3コマンドで、ILAやVIOの有無を調べているのだと思われるので、重要ではなさそうです。

その他にもプライベート命令はFUSE関係でたくさん出てきましたが、すべて解読できました。

さて、Vivadoが起動した後は、ARMのDAPに対するコマンドが発行されるのが確認できました。

STATE RESET;
SIR 16 TDI (FFF8) TDO (0751);
SDR 36 TDI (000000008) TDO (000000000);
SIR 16 TDI (FFFA) TDO (0751);
SDR 36 TDI (08000019A) TDO (000000002);
SIR 16 TDI (FFFA) TDO (0751);
SDR 36 TDI (000000003) TDO (18000000A);
SDR 36 TDI (000000007) TDO (18000000A);
SIR 16 TDI (FFFA) TDO (0751);
SDR 36 TDI (000000784) TDO (000000002);
SIR 16 TDI (FFFB) TDO (0751);
SDR 36 TDI (000000007) TDO (000000782);
SDR 36 TDI (000000003) TDO (1A3B80022);
SIR 16 TDI (FFFA) TDO (0751);
SDR 36 TDI (008000784) TDO (000000012);
SIR 16 TDI (FFFB) TDO (0751);
SDR 36 TDI (000000007) TDO (008000782);
SIR 16 TDI (FFFA) TDO (0751);
SDR 36 TDI (010000784) TDO (223B80012);
SIR 16 TDI (FFFB) TDO (0751);
SDR 36 TDI (000000007) TDO (010000782);
SIR 16 TDI (FFFA) TDO (0751);
SDR 36 TDI (000000003) TDO (123B00082);
SDR 36 TDI (000000007) TDO (18000000A);
SIR 16 TDI (FFFA) TDO (0751);
SDR 36 TDI (008000004) TDO (000000002);
SIR 16 TDI (FFFB) TDO (0751);
SDR 36 TDI (400000010) TDO (008000002);
SIR 16 TDI (FFFA) TDO (0751);
SDR 36 TDI (000000004) TDO (123B00082);
SIR 16 TDI (FFFB) TDO (0751);
SDR 36 TDI (000000001) TDO (000000002);
SIR 16 TDI (FFFA) TDO (0751);
SDR 36 TDI (008000004) TDO (184030212);
SIR 16 TDI (FFFB) TDO (0751);
SDR 36 TDI (000000001) TDO (008000002);

というものですが、SIRの行にあるFFF8、FFFA、FFFBというのがコマンド、続く36bitのがデータです。

この解釈はARM Debug Interface Architecture Specification（https://static.docs.arm.com/ihi0031/c/IHI0031C_debug_interface_as.pdf）ににあります。

ARMのデバッグシステムは以下のような構造になっていて、

FFF8が発行されるとABORT、FFFAはDPACC、FFFBはAPACCへの読み書きが行われます。

これが何を意味しているかの解読は別の機会にするとしましょう。

http://www.tokudenkairo.co.jp/jtag/mjbas_usage.pdf

 

MITOUJTAGを使うと、オシロやロジアナでは見れないBGAの裏側の信号を見たり操作したりすることができます。

あるのとないのとでは、FPGAの開発の効率が全然変わってきます。

MITOUJTAG BASIC 3.4では、

 

• UltraScale+への書き込み、バウンダリスキャン対応
• XILINX 7シリーズの温度・電圧測定

 

などに対応しました。

詳しい更新点はこちらのページをご覧ください。

http://www.tokudenkairo.co.jp/jtag/3xto34.html

 

毎秒2回更新します。

JTAGで温度を見る方法はユーザガイドUG580 (v1.9)に書かれているDRPという仕組みを利用します。

簡単に言うと、SYSMON_DRPという命令を使って、読み出したいステータスレジスタのアドレスをセットし、読み出します。

どのようなステータスレジスタがあるかというと、

このような感じになっています。

まず、IRにSYSMON_DRPという命令を発行し、次にDRに32bitの値をセットします。

シフトイン値は26bit目を1にし、[25:16]に読み出したいアドレスをセットします。

val = (1 << 26) | (addr << 16) | data;

 

DRPレジスタに書き込むのでなければdataは0でよいでしょう。

こうして、2回スキャンすると、2回目で目的のレジスタの値が読み出されます。

 温度を測る場合は、

rdvalue / 65536. * 509.3140064 - 280.23087870;

で[℃]に変換します。

 電圧を測る場合は、

rdvalue / 65536. * 3;

で[V]に変換します。

 

同じ要領でレジスタ0x10～0x1Fを読み出せば、XADCの値が読み出せると思います。

電源ピン電圧の監視では、HR I/Oでは上記の*3が*6になる場合もあるそうです。

なお、JTAG DRPは、バウンダリスキャンとは排他的です。JTAGのデータレジスタにDRPが接続されているときは、バウンダリスキャンレジスタは切り離されています。

そのため、MITOUJTAGでは、I/Oの状態を表示している時には温度は出ないようにしました。

 

 

UltraScale+のバウンダリスキャンにおいて、コントロールセルがおかしい問題は、Answerに書かれていました。

https://japan.xilinx.com/support/answers/62985.html

実はSpartan-6のときにも同様の問題があったのです。

 

• http://nahitafu.cocolog-nifty.com/nahitafu/2009/09/spartan-6-11d0.html
• http://nahitafu.cocolog-nifty.com/nahitafu/2009/11/spartan-6-0b37.html
• http://nahitafu.cocolog-nifty.com/nahitafu/2010/12/spartan-6mitouj.html

 

6シリーズのときは出力ピンとして誤認識されてしまうのに対して、UltraScaleでは入力ピンとして誤認識されます。

7シリーズでは全く問題なかったので、6シリーズとUltraScaleを設計したのは同じグループなのかもしれない。偶数シリーズと奇数誤で設計担当グループが交互に変わるとか、そういう事情があるのかもしれない。

さて、上記のAnswerによると、バウンダリスキャンで方向セルを正しく読めるようにするには、OBUFの代わりにT=0にしたOBUFTを使えとのことでした。

出力ピンにOBUFTを使うようにしたら、PLの入出力セルの方向が正しく読めるようになりました。

この波形を作るために書いたコードはこんな感じです。

カウンタがある一定値以上になると入力になり、一定値未満ならばバイナリでカウントアップする値を出力するというものです。

これまでにわかっているUltraScale+のJTAGの仕様(バグ?)をまとめると、

 

• PLはコントロールセルから正しくない値が読み出される。PSは問題ない。
• PSはSAMPLE時に入出力セルが逆になる。PLは逆にならなない。
• EXTEST時はPSでも入出力セルは逆にならない。
• DDR4 SDRAMとのやりとりは見えない。

 

ということなのですが、PSとPLとDDR4でバウンダリスキャンの作りが違って、みんなどこかしら問題を抱えているわけなのです。

どうなっているんでしょう！？ 

まず、PLのデザインのBitファイルを作らなければならないので、

http://zedboard.org/support/design/24166/156

からリファレンスデザインをダウンロードしてきます。

この中のUltra96_Basic_SystemをVivado 2018.2で開きます。

Ultra96のサンプルは、PLは使わずに、PSのみで動いているようです。

これだと書き込んでも何も起きないので、簡単なカウンタ回路を作ります

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;

entity counter is
	Port (	clk  : in  std_logic;
			test_o : out std_logic_vector(7 downto 0)
	);
end counter;

architecture Behavioral of counter is
	signal counter : std_logic_vector(24 downto 0); 
begin
	process(clk) begin
		if(clk'event and clk='1') then
			counter <= counter + 1;
		end if;
		if(counter(23) = '1') then
			test_o <= (others => 'Z');
		else
			test_o <= counter(23 downto 16);
		end if;
	end process;

end Behavioral;

カウントアップしながら、一定期間test_oを

そして、VivadoにRTLモジュールとして登録します。

これでGenerate Bitstreamすると、Bitstreamができるわけですが、これをSVF形式に変換します。

SVFに変換するには、VivadoのTclコンソールで次のように入力します。

open_hw
create_hw_target my_svf_target
open_hw_target
set device0 [create_hw_device -part xczu3eg]
set_property PROGRAM.FILE {D:/Ultra96_Basic_System/Ultra96_Basic_System.runs/impl_1/design_1_wrapper.bit} [get_hw_devices xczu3_0]
program_hw_devices -disable_eos_check [get_hw_devices xczu3_0]
write_hw_svf -force D:/Ultra96_Basic_System/counter.svf
close_hw_target
close_hw

SVFを生成すると、Hardware Managerが開いて、以下のような画面になります。

そうしたら、MITOUJTAGで以下のSVFファイルを実行し、PL TAPとARM DAPを有効化します。

STATE RESET;
TDR 0;
HDR 1 TDO (1); // ARMのDAPを無視するため
SIR 16  TDI (83FF) ; // JTAG_CTRL
SDR 32 TDI (00000003) PRINT; // ARM DAPとPL TAPを有効化
RUNTEST RESET 16 TCK;

そして、Vivadoで生成したSVFファイルをMITOUJTAGのSVFプレイヤーで再生します。

書き込みには結構な時間がかかります。

書き込んだ後、JTAGロジックアナライザで見てみると、

ちゃんとカウントアップして、休む波形が見えました。

ただ、様子がおかしいですね。バウンダリスキャンセルの方向ピンが正しく読み取れていないようです。

本来は、このDIRと書かれた方向制御ピンは出力時には0になり、入力時には1になるはずです。

しかし、常に1のままで、入力として判断されてしまいます。

ZUの内部には、PS TAP、PL TAP、ARM DAPという3つのJTAGコンポーネントが入っています。

 

• PS TAPはPSの制御に使われるもので、JTAGステータスを見たりPMU(実体はMicroblaze)のデバッグポート(MDM)に接続されています。
• PL TAPはPLのバウンダリスキャンやFPGA部分のコンフィグに使われます。
• ARM DAPはCortex CPUのデバッグに使われます。

 

PL TAPとARM DAPは、デフォルトではDummyのほうを選択されていて、本体は無効になっています。また、PMU MDMとPL TAPとARM DAPにはセキュリティゲートというのがあって、勝手にデバッグをさせないようになっています。

セキュリティゲートは電源ON時やセキュアブートの時、eFUSEが切られているときには有効になっていて、JTAGが突破できません。

しかし、非セキュアブート(つまり普通のブート)するときには、CSUのROMのコードにってセキュリティゲートは無効になり、JTAGアクセスできるようになります。したがって、普通に起動した場合にはJTAGは使えるので、セキュリティゲートを気にする必要はありません。

ZYNQ UltraScale+ MPSoCのJTAG命令レジスタの構造は次の図のようになっています。

ただし、PSとPLのIRは合わせて12bitという扱いなので、個別にコマンドを与えることはありません。PLのDRの長さは0bitになることもあります。

あまりPSとPL TAPを分離して考える必要はありませんが、ZUのJTAGのコマンドを解読していくときに、6bitごとに切って考えると理解しやすいところがあります。

ただし、PL TAPも一人前にIDCODEを持っていて、XCZU3EGのPSのIDCODEが0x14710093なのに対して、PLのIDCODEは0x14A42093でした。

このPL IDCODEは特別な命令IDCODE_PL(0x925)やIDCODE_PSPL(0x265)を発行すると読めます。

JTAGのTDIから入ってきた信号はPS TAPを通った後、PL TAPかDummy TAPを通ります。その後、ARM DAPかDummy DAPを通ります。どちらを通るかというのは、PS TAPに対して発行するJTAG_CTRLコマンドで指定します。

具体的には、JTAG_CTRLコマンド(0x83F)をPS-PLに発行して、そのあと、0x00000003をDRに書き込みます。

SVF形式で書くなら、

STATE RESET;
TDR 0;
HDR 1 TDO (1); // ARMのDAPを無視するため
SIR 16  TDI (83FF) ; // JTAG_CTRL
SDR 32 TDI (00000003) ; // ARM DAPとPL TAPを有効化
RUNTEST RESET 16 TCK; // 切り替えた後は、Test-Logic-Resetステートで5回以上 TCKをトグルする

となります。

こうすることで、PL TAPとARM DAPが有効になって、MITOUJTAGの自動認識でも2個のデバイスが見つかるようになりました。

そして、ARMのDAPも認識されるようになり、正常にバウンダリスキャンができるようになります。

 

まとめると

• ZYNQ UltraScale+ MPSoCのIRの長さは常に16bit
• 非セキュアブートではセキュリティゲートは無効になっていて、突破できる
• リセット後は、PL TAPとARM DAPはDummyが選択されているので、バウンダリスキャンやコンフィギュレーションをするなら、JTAG_CTRLコマンドで有効にしなければならない
• PMUがJTAGでデバッグできそうだ

となります。

Ultra96ボードを使ってZYNQ UltraScale+ MPSoC(以下、ZUと略)のJTAGの仕組みを解明しています。

本日、JTAGチャレンジ基板を使った初めてのセミナーを開催しました。

ボードから12Vの電源と、JTAGの配線を引き出してテスト開始です。

MITOUJTAGで認識させてみると、XCZU3しか見つかりません。実際にはXCZU3のほかにARMのDAPというのがつながっているので2個のデバイスが見つかるはずなのですが・・

そこで、SVFプレイヤーを用いて

STATE RESET;
STATE IDLE;
SDR 128 TDI (00000000000000000000000000000000) TDO (00000000000000000000000000000000);

というコマンドを実行して、JTAGの低レベルなデバッグをしてみると、XCZU3のIDCODEが1bitずれたものが読み出されました。

ARM DAPのDRが1bitになっていて(ZYNQ7000では32bitあった)、JTAG IDCODEが存在していないことがわかります。これは、ちょっと問題です。ARM DAPのIRは4bit長なので規格どおりですが。

この点は、ARM DAPのBSDLを作成して手動で追加すれば何とかなりました。

MITOUJTAGのバウンダリスキャンで、端子のI/Oが見えているように見えます。

また、端子のAA3、AA4あたりをEXTESTで動かすとLEDがチカチカするので、MITOUJTAGから操作もできていることがわかりました。

しかし、問題はここからです。基板上のSW4を押してもそれに相当する端子の状態が変化しないのです。

 

これはUltraScale+の持つJTAGのバグではないかと思います。

本来、JTAGバウンダリスキャンでは、I/Oパッドから入力した値は入力セルから読み出されます。

しかし、コンフィギュレーションされたUltraScale+では、なぜか出力セルから読み出されます。

これが仕様なのか設計ミスなのかわかりませんが、JTAGの動作としては間違っているように思われます。

なお、バウンダリスキャンセルを手動で書き換えて、出力セルの値を見るようにすると、一見正しい動作をするのですが、FPGAが出力する値を読めなくなってしまうので、これも正しくありません。

BSDLファイルが間違っているというわけではなく、チップレベルで間違っているようです。

それから、DDR4メモリの端子が全く動いていないことも気になります。Ultra96ボードのデフォルトのSDカードでは、DDRメモリは使用していないのでしょうか。 

AVNETのUltra96ボードを買いました。

私がやるべきことは、UltraScale+のJTAGコンフィギュレーションの仕組みを解析することだと思います。

参考にしたのは、Vivado Design Suiteユーザガイド(ug908)と、UltraScale アーキテクチャ コンフィギュレーション ユーザー ガイド (UG570)です。UG570にはJTAGコンフィギュレーションの仕組みは書いてありますが、実際にどういうシーケンスで動作させるかの実例がないと、不安要素はぬぐえません。

そこで、VivadoにSVFファイルを生成させてみることにします。SVFファイルの生成方法は、UG908の77ページあたりに書かれています。

とりあえずVivadoでZU2CGの適当なデザインを作り、Tclコンソールから下記のように入力します。

open_hw
create_hw_target my_svf_target
open_hw_target

このコマンドを打つと、Hardware Managerがファイル生成モードで開き、VivadoにSVF Operationsという欄が出来ます。

このcreate_hw_targetというのが、SVF生成プログラムを起動するTclコマンドのようです。

次に、

set device0 [create_hw_device -part xczu2cg]

とコマンドを打つと、JTAGチェーンにxczu2とarm_dapの2つのデバイスが追加されます。

（紫の部分は実際に使用するデバイスに合わせて変えます）

以下のコマンドで書き込みたいビットストリームファイルを指定して、書き込み操作を指示します。

set_property PROGRAM.FILE {D:/naitou/uscale/uscale.runs/impl_1/main.bit} [get_hw_devices xczu2_0]
program_hw_devices -disable_eos_check [get_hw_devices xczu2_0]
write_hw_svf -force D:/naitou/uscale/uscale.runs/impl_1/my_svf_target.svf

ただし、SVFモードなので、実際にはデバイスに書き込まれず、SVFファイルが生成されます。

最後に

close_hw_target
close_hw

とやって、Hardware Managerを閉じます。

出来上がったSVFファイルは10Mバイト以上あるのですが、

TRST OFF;
ENDIR IDLE;
ENDDR IDLE;
STATE RESET;
STATE IDLE;
FREQUENCY 1.00E+07 HZ;
HIR 4 TDI (0f) SMASK (0f) ;
TIR 0 ;
HDR 1 TDI (00) SMASK (01) ;
TDR 0 ;
// config/idcode
SIR 12 TDI (0249) ;
SDR 32 TDI (00000000) TDO (04711093) MASK (0fffffff) ;
// config/jprog
STATE RESET;
STATE IDLE;
SIR 12 TDI (090b) ;
SIR 12 TDI (0914) ;
// Modify the below delay for config_init operation (0.100000 sec typical, 0.100000 sec maximum)
RUNTEST 0.100000 SEC;
// config/jprog/poll
RUNTEST 10000 TCK;
SIR 12 TDI (0914) TDO (0011) MASK (0031) ;
// config/slr
SIR 12 TDI (0905) ;
SDR 44549344 TDI (00000004000000040000000400000004000000040000000400000004000000040000000400000004000000040000000400000004000000040000000400000004000000040000000400000004000000040000000400000004000000040000000400000004000000040000000400000004000000040000
・・・
・・・
ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff) ;
// config/start
SIR 12 TDI (0249) TDO (0031) MASK (0011) ;
// config/status
STATE RESET;
RUNTEST 5 TCK;
SIR 12 TDI (0905) ;
SDR 160 TDI (0000000400000004800700140000000466aa9955) ;
SIR 12 TDI (0904) ;
SDR 32 TDI (00000000) TDO (3f5e0d40) MASK (08000000) ;
STATE RESET;
RUNTEST 5 TCK;

となっています。

この動作を解説すると、まずHIRとHDRでARM_DAPをBYPASSする設定を与え、次にIDCODEをチェックしています。

090bはJPROGRAMコマンドで、PROG_Bピンと同等の働きをします。その後、0914のISC_NOOP命令(動作なし)に切り替えて、0.1秒待ちます。

再びISC_NOOP命令(914)を行い、IRの下位6bitが01XXX1であることをチェックしています。このbit5はDONEピンの状態を表していて、bit4は内部INITピンの状態を表しています。

つまり、DONE=0で現在のコンフィギュレーションが消えていること、INITで初期化状態であることを確認しています。

次の0905はCFG_INコマンドで、このコマンドを与えた後でJTAGのTDIからBitStreamを流し込めば、コンフィギュレーションが行われます。

次に0249(IDCODE)命令を行っていますが、特にIDCODE命令である必要はないようです。そのときのIRの状態を見て、DONE=0、INIT=1であることを確認しています。

そのあとで、CFG_INとCFG_OUTを実行して、0000000400000004800700140000000466aa9955を送って、3f5e0d40であるかどうかを確認しています。

それでは、0000000400000004800700140000000466aa9955という呪文のようなワードは何かというと、以下のように読みます。

 

• 66aa9955・・同期ワード
• 00000004・・NOOP
• 80070014・・レジスタ7（ステータスレジスタ）を1ワード読む
• 00000004・・NOOP
• 00000004・・NOOP

 

つまり、FPGAのコンフィギュレーションレジスタのステータスレジスタを読んでいるようです。ステータスレジスタの値としてチェックしている3f5e0d40というのは逆から読むので、0x02b07afcとなりますが、DONEピンや、GHIGH、GWEなどのビットを確認しているようです。

ただし、08000000でマスクしているので、実際にチェックするのはEND_OF_STARTUP_(EOS)_STATUSだけのようです。

ところで、-disable_eos_checkを付けても付けなくても結果は変わらないので、このオプションは効いていないようです。

ただ、これではJSTARTが実行されていないので、FPGAは起動しないような気がするのですが、良いのでしょうか？

おそらく、Vivadoのバグではないかと思います。本来は、

// config/start
SIR 12 TDI (0249) TDO (0031) MASK (0011) ;

ではなく、

// config/start
SIR 12 TDI (090C) ;

ではないかと思います。

disable_eos_checkのオプションが効かない点と、JSTARTが含まれていないので、Vivadoも完璧ではないのかもしれません。

明日にでもVivadoの出力したSVFでコンフィギュレーションできるかどうか、検証してみたいと思います。

 

 

 

 

今年はフィジカルレイヤーという物理層レベルのセキュリティのトラックが新設され、その講師に任命されたので、私の専門であるJTAG(ジェイタグ)について講義と実習を行ってきました。

添付の写真のような基板を受講者に渡して、JTAGのビット列を解読したり、解読したビット列をもとにEXTESTを使ったLEDをチカチカさせたりといった演習となりました。

 

当日朝まで徹夜でパワポをまとめたり、ソフトをデバッグしたりで大変でしたが、4時間の講義が終わったときのやり遂げたという解放感はひとしおでした。

XILINXとALTERAのデバイスが同一のJTAGチェーンにつながっている場合に、MITOUJTAGから書き込む方法を紹介します。

まず、Qualtus PrimeでMAX10のデザインを作ります。

QualtusのToolsからProgrammerを起動します。

QualtusのProgrammerが起動したら、いちど、まっさらな状態にします。

Add Fileを押して、MAX10の出力したファイルを選択します。

MAX10の内蔵ROMに書き込みたいならPOFを選び、揮発性のコンフィギュレーションをしたいならSOFを選びます。

下の図はPOFを選んだ場合の状態です。

次に、同一チェーン上にあるXILINXデバイスを追加したいのですが、当然ながらALTERAのツールはXILINXデバイスを認識しません。

そこで、Add Deviceボタンを押します。

どのデバイスを追加するかを聞かれるので、Importボタンを押します。

 

 

ファイル名を入力するダイアログが出るので．．．ボタンを押します。

D:\Xilinx\Vivado18.1\data\parts\xilinx\spartan7\public\bsdlディレクトリを指定し、中にあるxc7s25_csga225.bsdを指定します。

XC7S25が使用できるようになりました。

下の図のように、XILINXとALTERAがJTAGチェーンでつながります。

もし、順番が逆になっている場合にはUpボタンを押します。

次にMITOUJTAGから書き込むために、SVFというファイルを作ります。SVFを作るにはProgrammerのFileからCreate JAM JBC、SVF or ISC Fileを行います。

デフォルトでは、下の図のようにjamファイルになっているので、

これを選択して、

SVFファイルに変更します。また、TCKを1MHzに変更します。（これを行わないと遅くなる）

OKを押します。

これでSVFファイルができました。SVFファイルというのはこのような感じのテキストファイルです。

この中に、Spartan-6とMAX10がチェーンになった場合のMAX10書き込みシーケンスが入っていて、そのまま実行すれば書き込まれるようになっています。

そうしたら、MITOUJTAGを起動して、[ツール]→[SVFプレイヤー]を起動します。

先ほど生成したSVFファイルの中身を貼り付けます。

ここで開始ボタンを押すと、SVFが実行されて、MAX10に書き込まれます。

無事に書き込みが行われ、MAX10が起動しました。

下の図は、MAX10につないだシリアルADCを操作して、半固定抵抗の値やマイクで拾った音声を、JTAGロジアナで波形として表示しているようすです。

 

特にWindowsのソフトウェアを組むことなく、FPGAのピンからバイナリの値を出せば、MITOUJTAGのロジアナでそれを拾って、アナログ波形として表示できます。

このやり方は、FPGAやWindowsのソフトを作らなくてもよいので楽ですよ。

とりあえずは、JTAGケーブルを接続してSpartan-7とMAX10が認識されました。

この画面が出れば電源とJTAGは正常であることが保証されるので安心できますね。

よく見るとエラーになっていますが、MAX10は書き込み前だとINSTRUCTION_CAPTUREレジスタの値が変わるという変な仕様のためです。

最初は動かなくてかなり焦りました。まさか、こんな罠があるとは・・

これから動かないことを確認します！

 

ようやくDigilent USB-JTAGの使い方を理解して、MITOUJTAGから使えるようにできました！

まずは、ZYBOとパソコンをつなぎます。ZYBO上のUSB-JTAGで通信するので、USBケーブル1本だけです。

これでDigilent製のボードはUSBをつなぐだけでI/Oピンや波形が見れるようになったわけなのですが、ZYBOが起動するときの波形をバウンダリスキャンのロジアナで見てみたら、毎秒4000サンプリングほど出ていました。つまり250usくらいのサンプリング周期のようです。

JTAGロジアナで見てみると、DDR3メモリの動きなどが見えます。

実は今までのMITOUJTAGにもDigilent USB-JTAGを接続する機能はあったのですが、XILINX ISEがサポートするDigilent Cable Pluginを間接的に使っていたので、ISE(Labtool)が入っていないと使えませんでした。

LabToolはISEのでなければだめで、Vivadoには対応していませんでした。

その意味でも、今回の改良でISEに依存せずにDigilentケーブルが使えるようになったのは大きいといえます。

 

その他、ISSI製SPI ROMへの書き込み対応など細かいアップデートや、波形のエクスポート、ファイルの保存ボタンが押せないバグの修正などが行われています。