本日、MITOUJTAG BASIC 3.4をリリースしました。
また、MITOUJTAGの使い方を簡単に説明するスライドを作成しました。
http://www.tokudenkairo.co.jp/jtag/mjbas_usage.pdf
MITOUJTAGを使うと、オシロやロジアナでは見れないBGAの裏側の信号を見たり操作したりすることができます。
あるのとないのとでは、FPGAの開発の効率が全然変わってきます。
MITOUJTAG BASIC 3.4では、
などに対応しました。
詳しい更新点はこちらのページをご覧ください。
UltraScale+でJTAGを挿しているとLinux起動中にハングアップする問題があると聞いて、実験してみました。
まず、@ikwzmさんのZynqMP-FPGA-Linux (https://github.com/ikwzm/ZynqMP-FPGA-Linux) で試してみました。
Vivado HLSのコマンドプロンプトで、xsdbと入力すると、デバッガ「XSDK」が起動します。
ここでconnectと打つと、
という画面になります。
xsdb% cInfo: Cortex-A53 #1 (target 10) Stopped at 0x0 (Cannot resume. APB AP transaction error, DAP status 30000021) Info: Cortex-A53 #1 (target 10) Running xsdb% Info: Cortex-A53 #2 (target 11) Stopped at 0x0 (Cannot resume. APB AP transaction error, DAP status 30000021) Info: Cortex-A53 #2 (target 11) Running xsdb% tInfo: Cortex-A53 #1 (target 10) Stopped at 0x0 (Cannot resume. APB AP transaction error, DAP status 30000021) xsdb% Info: Cortex-A53 #1 (target 10) Running
上のようなメッセージが延々と表示されます。
targetコマンドで見てみると、たまに、
いくつかのプロセッサが停止しているようなメッセージを出しています。
このとき、LinuxのUARTに出てくるコンソールには、SDカードのトラブルやBlueToothが初期化失敗だの、いろいろなエラーメッセージが出て不安定になっています。
おそらくLinuxの起動が最後まで行かずに途中でハングすることと思われます。
解決策は、@ikwzmさんや、@marsee101のおっしゃるようにuEnv.txtのbootargsのところにcpuidle.off =1を付ければいい https://twitter.com/nahitafu/status/1057237499980918784 ようです。
これは、Linuxのカーネルコンパイル時に
CONFIG_CPU_IDLE=y
という設定になっていると、CPUがアイドル状態になることがあり、アイドル状態のときにJTAGアクセスするからおかしくなるようです。
@hidemi_ishihara さんによるとAnswer Recordの69143にあるとのこと。
https://japan.xilinx.com/support/answers/69143.html
を見てみると、確かに、そのようなことが書いてあります。
XSDBはコアのパワーダウンをチェックしているけれども、チェック後に不意にIDLEになるからDAPがエラーを起こすようです。
これなら、CPU_IDLEをOFFにする以外に解決策はなさそうです。
cpuidle.off=1を設定すれば、xsdbのtargetコマンドでも4つのCPUが落ち着いて常にRunning状態で見えます。
特電の製品でHyperFADCというものがあります。
1Gsps 16bit 2chの高速ADCチップを搭載し、QSFP光ファイバで送信するというものです。
右下にある放熱BOXがHyperFADCで、フロントパネルは
リアパネルは
こうなっています。
発熱がとにかくすごい。扇風機をあてていないと触れないほど熱くなります。
Agilentの波形発生器と高速オシロをつないで、
.
まずは、測りたい信号がちゃんと出ているかどうかを確認。
そして、HyperFADCでサンプリングしてみます。
ちゃんと動いていそうですね。
周波数特性を測ってみたら、20MHzと300MHz付近にリンギングがあるのですが、ケーブルの問題かもしれません。
納期が遅れてしまい、お客様には申し訳ございませんでしたが、無事に出荷できました。
MITOUJTAGでUltraScale+の温度や電圧が表示されるようにしました。
毎秒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+のJTAGの扱いが完璧にできるようになりました。
まず、リセット後にDummy TAP/DAPが接続される問題は自動で状況を認識して回復するようにしました。
EXTEST時にPSのバウンダリスキャンセルが入れ替わる問題も、ピン名からPSのピンなのかPLのピンなのかを自動的に判別して解決するようにしました。
こういった様々なバグに対してJTAGライブラリの根幹部分を、UltraScale+のためのパッチを書くことで対応したのですが、一つのFPGAファミリのバグ対策のためにここまでMITOUJTAGの深部に手を加えることになるとは思いませんでした。
これで、UltraScale+の自動認識とバウンダリスキャンの問題にはすべて対応できたと思います。
MITOUJTAGからネイティブでUltraScale+のPLに書き込めるようになりました。
書き込みのシーケンスは驚くほど簡単です。
これで、PLが書き変わります。
PLが書き変わってもLinux自体は動作し続けられますが、PLにあるすべてのレジスタはリセットされてしまうので、画面を使うならもう一度再起動しなければならなくなるでしょう。
書き込んで→I/Oを確認→書き込んで→I/Oを確認・・という開発＆デバッグのプロセスが楽にできるようになりました。
Ultra96ボードへの書き込みだと約10秒でできます。
PLの書き換えだけならば再起動を伴わないので、楽ですよ。
UltraScale+のバウンダリスキャンにおいて、コントロールセルがおかしい問題は、Answerに書かれていました。
https://japan.xilinx.com/support/answers/62985.html
実はSpartan-6のときにも同様の問題があったのです。
6シリーズのときは出力ピンとして誤認識されてしまうのに対して、UltraScaleでは入力ピンとして誤認識されます。
7シリーズでは全く問題なかったので、6シリーズとUltraScaleを設計したのは同じグループなのかもしれない。偶数シリーズと奇数誤で設計担当グループが交互に変わるとか、そういう事情があるのかもしれない。
さて、上記のAnswerによると、バウンダリスキャンで方向セルを正しく読めるようにするには、OBUFの代わりにT=0にしたOBUFTを使えとのことでした。
出力ピンにOBUFTを使うようにしたら、PLの入出力セルの方向が正しく読めるようになりました。
この波形を作るために書いたコードはこんな感じです。
カウンタがある一定値以上になると入力になり、一定値未満ならばバイナリでカウントアップする値を出力するというものです。
これまでにわかっているUltraScale+のJTAGの仕様(バグ?)をまとめると、
ということなのですが、PSとPLとDDR4でバウンダリスキャンの作りが違って、みんなどこかしら問題を抱えているわけなのです。
どうなっているんでしょう！？
Ultra96ボードで実験していて、ついにPLへJTAGで直接書き込むことに成功しました。
まず、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のままで、入力として判断されてしまいます。
ZYNQ UltraScale+ MPSoC（以下、ZU）の仕組みを完全に理解しました。
ZUの中にあるJTAGの構造をかみ砕いて描くと、こうなります。
ZUの内部には、PS TAP、PL TAP、ARM DAPという3つのJTAGコンポーネントが入っています。
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も認識されるようになり、正常にバウンダリスキャンができるようになります。
まとめると
となります。
発売日になるまで黙っていましたが、トランジスタ技術11月号の特集「私の人工知能チップ製作」の第1章から第3章に、記事が掲載されました。
今回の特集記事では、トラ技の本来の趣旨である「プロのビギナーのための記事」に徹し、人工知能(AI)の基礎とFPGA化のやり方を中心に執筆いたしました。
最初に考えた記事のプランでは、NNとCNNを両方作って比較したり、リアルタイム性にこだわってカメラ画像→DDRメモリ転送→即座にAIで推論、とかいうのをやろうと考えていたのですが、それだと初心者を置き去りにしてしまうのではないかと思われました。
現在のFPGAによるAI実装の最先端は、すでにビギナーの方には追い付けないほど先に進んでしまっています。
「FPGAが如何にすごいか」「こんなすごいものを作ったぞ」というスタイルで記事を書くと、すでにわかっている方にしか理解できない記事となってしまいます。トラ技の目指すところを念頭において初心者向けに何度か書き直しました。
はじめてFPGAやAIに接する人でもわかりやすくなるよう、自分がAIの勉強を始めたときの気持ちを思い出しながら、用語解説やAIの基本的な部分を中心に執筆いたしました。バリバリのプロの方には物足りないかもしれませんが、ご容赦くださいませ。
幸いなことに第4章にマーシーさんが書いてくれたCNNの記事があるので、全体として見れば第一線のプロの方でも満足いただけるような構成になっているかと思います。
●記事で使用したFPGAボードについて
本特集3章の内容は、CMOSカメラで撮った猫画像をFPGAで認識させるというものです。
使用したFPGAボードはRasppberry Pi型のFPGAボード「Zynqberry(ジンクベリー)」です。ZynqberryにUbuntu LinuxとSDSoCをいれて猫画像を認識させています。
写真1 Raspberry Pi型のFPGAボード「Zynqberry(ジンクベリー)」
Zynqberryのようなユニークなボードにも焦点が当たればよいなと感じています。
●記事で使用したCMOSイメージセンサについて
本記事では、Raspberry Piカメラを使用して画像をキャプチャしています。Raspberry Piカメラの入手は大変容易です。
写真2 どこでも手に入るRaspberry Piカメラ
Raspiカメラは、Amazonや秋月、千石などで互換品も含めて簡単に入手できます。なお、本記事で試したのはRaspiカメラのV1.3です。2.1では試していません。
下の写真は、猫画像を認識させているときのようすです。
カメラで撮った画像を1280×720→32×32に縮小しているわけですが、画面いっぱいの画像を32×32に縮小してからNNに入れるので、なかなか距離感が難しいです。
写真3 「Zynqberry」にCIFAR-10を入れて猫画像認識
現時点では全く実用的なAIではありませんが、SDSoCのソースは公開しているし、超絶技巧は使っていないので、わかりやすいと思います。
ぜひいろいろ試してみてください。
この記事が、これからFPGA×AIをしようという人の一助になれば幸いです。
Ultra96ボードを使ってZYNQ UltraScale+ MPSoC(以下、ZUと略)のJTAGの仕組みを解明しています。
まず、ZUは本体のPLのJTAGのほか、ARMのDAPや、ダミーのDAPが付いたりして、JTAGチェーンの構成が変わります。JTAGチェーンの構成はおそらくFSBLの中からCSUレジスタを操作することで行われますが、デフォルトのFSBLでは以下のようになります。
ここで厄介なことが3つあります。JTAGチェーンの構成が変わるたびに、JTAGのTMSを1にして何回かのTCKを与えてTAPをRESETしないといけないことと、JTAGチェーンの構成はソフトで変わることです。そのため、ハードウェアリセットが行われて、PMU→CSU→FSBLと起動のステップが進んだあたりでJTAGをリセットしなければなりません。
また、ZUのARM TAPはJTAGの規格に反してTAP RESET後にDRにIDCODEが現れません。そのため、自動で認識することができないことです。
JTAGを使う汎用的なツールに「MITOUJTAG(みとうジェイタグ)」というのがあります。MITOUJTAGを使うとバウンダリスキャンで端子の状態が見えます。
Ultra96ボードでは以下のように見えます。
Ultra96ボードでチカチカ光っているLEDのあたりのピンを見てみます。
AB4、AA4、Y5、AA3、AB5番ピンにこれらの端子があります。
ZUでは、普通にバウンダリスキャンでSAMPLEしても、これらの端子の状態は正しく見ることができません。
前の記事で書いたとおり、SAMPLEするときには入力セルから値を読むのが普通なのですが、
ZUではなぜか出力セルから入力値が読み込まれるからです。
これは、はっきり言って、ZUのバグだと思います。
しかも、この入力ピンの値が出力セルから読み出される現象は、SAMPLE時のみ発生し、EXTEST時には発生しません。したがって、BSDLファイルの変更では対処できません。
そこで、MITOUJTAGでは、「ZYNQUltraScale+ MPSoCならば、SAMPLE状態のときに、入力セルと出力セルの読み出した値を入れ替える」という方法でこの問題に対処することにしました。
このようにすることで、端子から出力している値と、端子から入力している値を正しく読み出すことに成功しました。
以上の問題を解決し、Ultra96ボードでLinuxが起動する時の波形を見ることに成功しました。
まずは下の波形をご覧ください。
UART0_TXに間欠的に動く波形が出ています。これはコンソールへの文字出力です。
起動してから5秒と8秒付近で、それぞれLinuxの起動と、BlueToothとWLANの起動が起こります。このときにMIOのピンの出力状態が変わるのが見てとれます。
起動後8秒後くらいというのは、コンソールにこのような文字列が出力されているあたりです。
LED0(緑のLED)がチカチカを開始するのが見えています。
あと、見て面白いのは起動後8秒付近でUSB1が起動することと、SD1に一瞬だけアクセスすることかなと思います。
UltraScale+のJTAGの仕組みがだいたい解明できました。
ポイントは、
MITOUJTAGでは、このような問題に対処するためのUltraScale+用のパッチを提供する用意があります。
自分でUltra96ボードをブートさせようと思った場合、まずUltra96ボードのVivadoのプロジェクトを探してくる必要があります。
Vivadoプロジェクトは、
http://zedboard.org/support/design/24166/156
にあるようです。
この中のTutorial 01-04 Solutionsをダウンロードします。
この中にあるUltra96_Basic_SystemというフォルダがVivadoのプロジェクトで、Ultra96_Basic_System\Ultra96_Basic_System.sdk\design_1_wrapper.hdfがHDFファイル(ハードウェア定義ファイル)です。
このファイルはVivado 2018.2用なので、私のVivado 2018.1では開けませんでしたが、HDFがあれば、XILINX SDKでプロジェクトが作成できます。
XSDKで新規プロジェクト作成、とやって、Newを押します。
次のダイアログでHDFファイルを指定すれば新しいハードウェアプラットフォームとして登録されます。
これで、プロセッサのタイプをPMUにしてPMUファームウェアを作り、FSBL、Periferal Testなどのアプリを作ります。
注意しなければならないことは、デフォルトではUART0に標準出力が出力されてしまうことです。Ultra96ボードのUART0はBluetoothなので、普通にFSBLやPMUを作ってもコンソールに何も出てきません。
Ultra96ボードのUARTを3ピンのピンヘッダ(J15)につないでいる場合、UART1に出してやらなければなりませんが、その変更はPMU_BSPや、FSBL_BSP、TEST_BSPなど、_BSPと付いたプロジェクトの中のxparameters.hにあります。xparameters.hのSTDIN_BASEADDRESSとSTDOUT_BASEADDRESSがデフォルトでは0xFF000000になっているので、これを0xFF010000に変更します。
#define STDIN_BASEADDRESS 0xFF010000 #define STDOUT_BASEADDRESS 0xFF010000
ビルドが走ってしまうと数十分かかってしまうようですね・・
XSDKが作ったデフォルトのFSBLやPMUはデバッグメッセージを出さないので、デバッグメッセージを出すように修正します。
まず、PMUのプロジェクトではxpfw_config.hを開いて
#define XPFW_DEBUG_ERROR_VAL (1U) #define XPFW_DEBUG_DETAILED_VAL (1U)
を有効にします。
FSBLのプロジェクトではxfsbl_config.hを開いて、
#define FSBL_PRINT_VAL (1U) #define FSBL_DEBUG_VAL (1U) #define FSBL_DEBUG_INFO_VAL (1U) #define FSBL_DEBUG_DETAILED_VAL (1U)
を有効にします。
bootimage.bifは以下のようにします。
//arch = zynqmp; split = false; format = BIN
the_ROM_image:
{
[fsbl_config]a53_x64
[pmufw_image]D:\ultrascale\PMU\Debug\PMU.elf
[bootloader, destination_cpu=a53-0]D:\ultrascale\FSBL\Debug\FSBL.elf
[destination_device = pl]design_1_wrapper.bit
[destination_cpu = a53-0]D:\ultrascale\TEST\Debug\TEST.elf
}
bootimage.bifの書き方でいろいろ実験してみてわかったことは、
ということでした。
なお、bootimage.bifからboot.binを作るのは
D:\Xilinx\SDK\2018.1\bin\bootgen -image bootimage.bif -arch zynqmp -o D:\ultrascale\mkboot\BOOT.bin -w on
とコマンドを打ちます。
ためしにどこまで削っていってブートするかを試してみたら、最小限のbootimage.bifとして
the_ROM_image:
{
[bootloader, destination_cpu=a53-0]D:\ultrascale\FSBL\Debug\FSBL.elf
}
だけで起動できました。
Xilinx Zynq MP First Stage Boot Loader Release 2018.1 Oct 9 2018 - 01:03:55 Reset Mode : System Reset Platform: Silicon (4.0), Cluster ID 0x80000000 Running on A53-0 (64-bit) Processor, Device Name: XCZU3EG Processor Initialization Done ================= In Stage 2 ============ SD0 Boot Mode SD: rc= 0 File name is BOOT.BIN Multiboot Reg : 0x0 Image Header Table Offset 0x8C0 XFSBL_ERROR_NO_OF_PARTITIONS Image Header Table Validation failed Boot Device Initialization failed 0xD ================= In Stage Err ============ Fsbl Error Status: 0x0
PMUも複数のプロセッサも出てこない。これならZYNQ 7000と同じですね。
さて、本筋に戻りましょう。
FSBL、PMU、BitStream、テストアプリ(Periferal Test)を結合させてBoot.binを作り、ブートさせてみた結果が次の画面です。
起動時の全メッセージを載せます。FSBLがデバッグメッセージをUART1に出力するので、中で何をやっているかがわかると思います。
Xilinx Zynq MP First Stage Boot Loader Release 2018.1 Oct 9 2018 - 01:03:55 Reset Mode : System Reset Platform: Silicon (4.0), Cluster ID 0x80000000 Running on A53-0 (64-bit) Processor, Device Name: XCZU3EG Processor Initialization Done ================= In Stage 2 ============ SD0 Boot Mode SD: rc= 0 File name is BOOT.BIN Multiboot Reg : 0x0 Image Header Table Offset 0x8C0 *****Image Header Table Details******** Boot Gen Ver: 0x1020000 No of Partitions: 0x3 Partition Header Address: 0x440 Partition Present Device: 0x0 Initialization Success ======= In Stage 3, Partition No:1 ======= UnEncrypted data Length: 0x153E27 Data word offset: 0x153E27 Total Data word length: 0x153E27 Destination Load Address: 0xFFFFFFFF Execution Address: 0x0 Data word offset: 0xED80 Partition Attributes: 0x26 Destination Device is PL, changing LoadAddress XPFW: Calling ROM PWRUP Handler..Done XPFW: Calling ROM Isolation Handler..Done Non authenticated Bitstream download to start now DMA transfer done PL Configuration done successfully PPFW: Calling ROM PWRUP Handler..Done artition 1 Load Success ======= In Stage 3, Partition No:2 ======= UnEncrypted data Length: 0x6412 Data word offset: 0x6412 Total Data word length: 0x6412 Destination Load Address: 0x0 Execution Address: 0x0 Data word offset: 0x162BB0 Partition Attributes: 0x116 Partition 2 Load Success All Partitions Loaded ================= In Stage 4 ============ PM Init Success Protection configuration applied Running Cpu Handoff address: 0x0, Exec State: 0 Exit from FSBL ---Entering main--- Running ScuGicSelfTestExample() for psu_acpu_gic... ScuGicSelfTestExample PASSED ScuGic Interrupt Setup PASSED Running XZDma_SelfTestExample() for psu_adma_1... XZDma_SelfTestExample PASSED Running Interrupt Test for psu_adma_1... ZDMA Simple Example PASSED Running XZDma_SelfTestExample() for psu_adma_2... XZDma_SelfTestExample PASSED Running Interrupt Test for psu_adma_2... ZDMA Simple Example PASSED Running XZDma_SelfTestExample() for psu_adma_3... XZDma_SelfTestExample PASSED Running Interrupt Test for psu_adma_3... ZDMA Simple Example PASSED Running XZDma_SelfTestExample() for psu_adma_4... XZDma_SelfTestExample PASSED Running Interrupt Test for psu_adma_4... ZDMA Simple Example PASSED Running XZDma_SelfTestExample() for psu_adma_5... XZDma_SelfTestExample PASSED Running Interrupt Test for psu_adma_5... ZDMA Simple Example PASSED Running XZDma_SelfTestExample() for psu_adma_6... XZDma_SelfTestExample PASSED Running Interrupt Test for psu_adma_6... ZDMA Simple Example PASSED Running XZDma_SelfTestExample() for psu_adma_7... XZDma_SelfTestExample PASSED Running Interrupt Test for psu_adma_7... ZDMA Simple Example PASSED Running SysMonPsuPolledPrintfExample() for psu_ams... Entering the SysMon Polled Example. The Current Temperature is 46.561 Centigrades. The Maximum Temperature is 47.082 Centigrades. The Minimum Temperature is 46.102 Centigrades. The Current VCCINT is 0.853 Volts. The Maximum VCCINT is 0.855 Volts. The Minimum VCCINT is 0.852 Volts. The Current VCCAUX is 1.817 Volts. The Maximum VCCAUX is 1.818 Volts. The Minimum VCCAUX is 1.815 Volts. Exiting the SysMon Polled Example. SysMonPsuPolledPrintfExample PASSED Running SysMonPsuIntrExample() for psu_ams... Entering the SysMonPsu Interrupt Example. The Current Temperature is 46.514 Centigrade. The Current VCCINT is 0.854 Volts. The Current VCCAUX is 1.816 Volts. Temperature Alarm(0) HIGH Threshold is 36.512 Centigrade. Temperature Alarm(0) LOW Threshold is 26.510 Centigrade. VCCINT Alarm(1) HIGH Threshold is 0.654 Volts. VCCINT Alarm(1) LOW Threshold is 1.054 Volts. VCCAUX Alarm(3) HIGH Threshold is 1.615 Volts. VCCAUX Alarm(3) LOW Threshold is 2.016 Volts. Alarm 0 - Temperature alarm has occured The Current Temperature is 46.607 Centigrade. The Maximum Temperature is 47.346 Centigrade. The Minimum Temperature is 45.955 Centigrade. The Current VCCINT is 0.853 Volts. The Maximum VCCINT is 0.855 Volts. The Minimum VCCINT is 0.851 Volts. The Current VCCAUX is 1.817 Volts. The Maximum VCCAUX is 1.818 Volts. The Minimum VCCAUX is 1.815 Volts. Exiting the SysMon Interrupt Example. SysMonPsu IntrExample PASSED Running XCsuDma_SelfTestExample() for psu_csudma... XCsuDma_SelfTestExample PASSED Running Interrupt Test for psu_csudma... CSUDMA Interrupt Example PASSED Running XZDma_SelfTestExample() for psu_gdma_0... XZDma_SelfTestExample PASSED Running Interrupt Test for psu_gdma_0... ZDMA Simple Example PASSED Running XZDma_SelfTestExample() for psu_gdma_1... XZDma_SelfTestExample PASSED Running Interrupt Test for psu_gdma_1... ZDMA Simple Example PASSED Running XZDma_SelfTestExample() for psu_gdma_2... XZDma_SelfTestExample PASSED Running Interrupt Test for psu_gdma_2... ZDMA Simple Example PASSED Running XZDma_SelfTestExample() for psu_gdma_3... XZDma_SelfTestExample PASSED Running Interrupt Test for psu_gdma_3... ZDMA Simple Example PASSED Running XZDma_SelfTestExample() for psu_gdma_4... XZDma_SelfTestExample PASSED Running Interrupt Test for psu_gdma_4... ZDMA Simple Example PASSED Running XZDma_SelfTestExample() for psu_gdma_5... XZDma_SelfTestExample PASSED Running Interrupt Test for psu_gdma_5... ZDMA Simple Example PASSED Running XZDma_SelfTestExample() for psu_gdma_6... XZDma_SelfTestExample PASSED Running Interrupt Test for psu_gdma_6... ZDMA Simple Example PASSED Running XZDma_SelfTestExample() for psu_gdma_7... XZDma_SelfTestExample PASSED Running Interrupt Test for psu_gdma_7... ZDMA Simple Example PASSED Running IicPsSelfTestExample() for psu_i2c_1... IicPsSelfTestExample PASSED Running XZDma_SelfTestExample() for psu_adma_0... XZDma_SelfTestExample PASSED Running Interrupt Test for psu_adma_0... ZDMA Simple Example PASSED Running SpiPsSelfTestExample() for psu_spi_0... SpiPsSelfTestExample PASSED Running SpiPsSelfTestExample() for psu_spi_1... SpiPsSelfTestExample PASSED Running Interrupt Test for psu_ttc_0... TtcIntrExample PASSED Running Interrupt Test for psu_ttc_1... TtcIntrExample PASSED Running Interrupt Test for psu_ttc_2... TtcIntrExample PASSED Running Interrupt Test for psu_ttc_3... TtcIntrExUartPsPoUartPsIntrExample PASSED Running WdtPsSelfTestExample() for psu_wdt_0... WdtPsSelfTestExample PASSED Running WdtPsSelfTestExample() for psu_wdt_1... WdtPsSelfTestExample PASSED ---Exiting main---
そして豪華なペリフェラルテストを行っています。
あれ？PMUが出てこない。
どうしてでしょう。
ぼちぼちUltra96ボードを触り始めまています。
まず、1000ページ以上にもなるZYNQ UltraScale+ MPSoCのユーザガイド(特にUG1085)を印刷して、ひたすら読みました。A4の紙に4ページで縮小印刷し、両面印刷するので、1枚あたり8ページです。それでも数百枚の紙を使ったと思います。
読んでわかったことは、
ということです。
つまり、起動するにはPMU、CSUを起動してFSBLをロードしてあげなければならないようです。
お客様から注文をいただいていたCosmo-Zアルミケース入り(80MHz 12bit 8ch)を出荷しました。
FANが付いていて、温度が37度までしか上がらないというスグレモノです。
フロントパネルに24個の使われていない穴が開いていますが、これはCosmo-Z 32chにした場合には全部埋まります。
背面は凹んでいます。このアルミの設計は結構大変だった。
Cosmo-Zは、もともと地中深くで宇宙線を検出するという目的のために作られたので、基板の幅が89mmで細長いというサイズになっています。
地上で使う一般的な用途では、そのようなサイズに合ったケースはありません。タカチのケースをカスタムで使うことになりますが、既存の基板を既存のケースに合わせるのはなかなか苦労しています。
Cosmo-Z アルミケース入りの中身はこんな感じ。
床板や天板は鉄なのでかなり丈夫です。側面は3mmくらいある凸凹したアルミです。
これで、お客様から注文をいただいていて、注文残になっていたCosmo-Zはすべて出荷できたと思います。
あと、Cosmo-Z Miniと、HyperFADCと、Spartan-6基板20個か。ふう。
Cosmo-Zの16ch版を出荷しました。
また予定以上に納期がかかってしました。
Cosmo-Zは1台1台、お客様ごとにカスタマイズしたり、仕様が異なるのが難しい理由なのかもしれません。
お客様からご依頼を受けて、時間が経ってしまった案件であるCosmo-Zのロックインアンプがようやく作成しました。
見てのとおりVivadoで作られていて、ADC Blockから出てきたデータをlockinというモジュールに入れることで、ロックイン計測ができるというものです。
動作させているときの画面の様子です。
CH1の入力をリファレンスとして、周期を推定して、同期した正弦波をFPGAの中で作り出しています。
その作り出した正弦波と観測したい波形を乗算して何周期か積分することで、特定の周波数における振幅の大きさを測るというものです。
要するに1つの周波数だけのフーリエ変換のようなものです。
FPGAで動くフルディジタルなロックインアンプですが、1.5MHz程度なら余裕でロックできます。
このような感じで、いまは積み残してきた案件を１つずつ解決していきたいと思います。
最近のコメント