TE0808の使い方の連載も最後になりました。最後はSDカードから起動させる方法です。
TE0808にはオンボードでQSPI ROMが載っていて起動させることはできるのですが、やはり大容量なSDカードを使いたいところです。
次の回路図のようにコネクタJ3のMIOにつなげればOKなのですが、
注意すべき点はVCCOが1.8Vであることです。SDカードは3.3Vロジックで動作するのでレベルシフタが必要になります。
おすすめのレベルシフタはTXS02612です。
この回路図ではSDCLKは直結していますが、できれば30Ω程度の抵抗を入れてください。ZYNQ7000のとき、MIOから出てくるSD_CLKの信号が強すぎて、SDカードやレベルシフタに直結すると反射してうまく動かなかった嫌な思い出があります。
ZYNQ UltraScale+では直っているのでしょうか？
また、UltraScale+のSDカードはSD2.0対応と書かれているのですが、SDXCにも対応しているのかなど、機会があれば試してみたいと思います。
TrenzElectronic社のTE0803/TE0807/TE0808はZYNQ UltraScale+を搭載したSoMです。UltraScale+にはPS GTRというギガビットトランシーバが内蔵されていて、これを使うことでUSB3.0の通信を行うことができます。
とはいっても、USB3.0は最初の接続時はUSB2.0として動作してネゴーシエーションの末にUSB3.0でリンクアップするしくみなので、USB2.0でも接続できる回路にしておかなければなりません。
まずはUSB2.0の信号を出す
ZYNQ UltraScale+のI/OはUSB2.0をそのまま出すことができないので、USB PHYを外付けします。
おすすめはUSB3320です。
USB3320の端子にはUSB_DATA0~7、USB_STP、USB_NXT、USB_DIR、USB_CLKがあります。USB_CLKはUSB3320→ZYNQ方向の信号ですが、それ以外はZYNQ→USB3320または双方向信号です。これらの信号はMIOに接続します。
ZYNQのMIOはコネクタJ3の115~128に出るので、接続してください。
また、VCCOは1.8Vなので、USB3320のVIO電圧も1.8Vにしてください。USB3320のクロック周波数はREFSELで選択できるので、入手しやすい水晶発振器を選んでください。
USB3320のRESETB端子は、MIOをGPIOとして使ってリセットがかけられるようにしておいたほうがよいでしょう。FSBLの中でリセットするのが良いと思われます。
USB3.0の信号の出し方
USB3.0の高速信号はPSのGTRから出力されます。バンクは505で、コネクタJ2の下の図の場所から出力されます。
Bank505にはTXとRXが4組ずつありますが、どこを使っても構いません。TE0808の純正ベースボードTEBF0808-04AではTX1/RX1を使用していたので上の図では同じくTX1/RX1を使用するようにしています。なお、ZCU104ではTX2/RX2を使用しているようです。
まとめ
USB3.0といっても、最初はUSB2.0として起動します。ZYNQ UltraScale+はUSB2.0を直接出せないのでPHYを使います。おすすめのPHYはUSB3320です。
USB3320によってUSB2.0の信号を作り、PS GTRのどれか1本を使ってUSB3.0の信号を作ります。
ZYNQ UltraScale+はUSBからもブートできるらしいので、ぜひ試してみたいですね。
TE0808シリーズにはTE0803、TE0807、TE0808がありますが、昨年の型番の更改によりわかりにくくなったので、解説します。
Trenz社の公式WebサイトにはTE080xの型番についての解説はありませんが、全商品の仕様を見比べてみたところ以下のような規則になっていると推測されます。
TE080xの数字はシリーズを表し、3は比較的小規模なシリーズで、GTHがないか少ないタイプです。オンボードPLLは4chです。
7と8は中規模～大規模ですが、8はすべてEGタイプ。7はCG/EG/EVタイプがあります。PLLは高機能な10chのタイプです。
ハイフンの次の数字は基板のリビジョンを表します。
その次の5桁の英数字の最初はFPGAの規模を表します。これはXCZU●の数字と一致します。ただしXCZU15はTE0808-05-Bとなります
2つ目の数字はFPGAのタイプとスピードグレードです。
傾向を分析したところ、
と、なっているようでした。
3番目の数字は温度グレードでIまたはEです。これはFPGAの温度グレードと一致しています。
4番目の数字は、おそらくDDR4メモリの容量と思われます。1ならば2GByte、2ならば4GByteです。
5番目の数字は、すべての製品で1なので、わかりません。
最後のAかLかは、Aが通常版、Lがロープロファイルの意味だと思われます。
製品の型番とバリアントの一覧を以下の表に示します。
| 製品型番 | FPGA型番 | GTH | DDR4 |
|---|---|---|---|
| TE0803-04-2AE11-A | XCZU2CG-1SFVC784E | 0 | 2GB |
| TE0803-04-2BE11-A | XCZU2EG-1SFVC784E | 0 | 2GB |
| TE0803-04-3AE11-A | XCZU3CG-1SFVC784E | 0 | 2GB |
| TE0803-04-3BE11-A | XCZU3EG-1SFVC784E | 0 | 2GB |
| TE0803-04-4AE11-A | XCZU4CG-1SFVC784E | 4 | 2GB |
| TE0803-04-4BE11-A | XCZU4EG-1SFVC784E | 4 | 2GB |
| TE0803-04-4DE11-A | XCZU4EV-1SFVC784E | 4 | 2GB |
| TE0803-04-4DE21-L | XCZU4EV-1SFVC784E | 4 | 4GB |
| TE0803-04-4GE21-L | XCZU4EG-2SFVC784E | 4 | 4GB |
| TE0803-04-5DE11-A | XCZU5EV-1SFVC784E | 4 | 2GB |
| TE0803-04-5DI21-A | XCZU5EV-1SFVC784I | 4 | 4GB |
| TE0807-03-4AI21-A | XCZU4CG-1FBVB900I | 16 | 4GB |
| TE0807-03-4BE21-A | XCZU4EG-1FBVB900E | 16 | 4GB |
| TE0807-03-7AI21-A | XCZU7CG-1FBVB900I | 16 | 4GB |
| TE0807-03-7DE21-A | XCZU7EV-1FBVB900E | 16 | 4GB |
| TE0807-03-7DI21-A | XCZU7EV-1FBVB900I | 16 | 4GB |
| TE0807-03-7NE21-A | XCZU7EV-3FBVB900E | 16 | 4GB |
| TE0808-05-6BE21-A | XCZU6EG-1FFVC900E | 16 | 4GB |
| TE0808-05-6BE21-L | XCZU6EG-1FFVC900E | 16 | 4GB |
| TE0808-05-9BE21-A | XCZU9EG-1FFVC900E | 16 | 4GB |
| TE0808-05-9BE21-L | XCZU9EG-1FFVC900E | 16 | 4GB |
| TE0808-05-9GI21-A | XCZU9EG-2FFVC900I | 16 | 4GB |
| TE0808-05-BBE21-A | XCZU15EG-1FFVC900E | 16 | 4GB |
これまで３回にわたりTrenz社のTE0808の使い方を解説してきましたが、TE0808の類似製品にはTE0803とTE0807というSoMがあります。これらの基板のサイズと形状は同じで、ピンヘッダにも互換性があります。
今回はこれらのボードの違いについて解説したいと思います。
ボードの外観
まず、3種類のボードの写真を見比べてみましょう。
ぱっと見て、TE0803はパッケージが小さく、TE0807はコアがむき出しのBGパッケージ、TE0808は上が覆われたFFパッケージであることがわかります。このため、ヒートシンクは互換性がないのでご注意ください。
FPGAの違い
FPGAの違いを簡単に説明すると、
ここでZYNQ UltraScale+のタイプを簡単に説明すると、
ということになっています。
もしEVタイプのUltraScale+が必要であれば、TE0807-03-7DE21-AやTE0803-04-5DE11-Aを選択することになります。TE0808はロジックの規模は大きいのですがすべてEGタイプなのでビデオコーデックがありません。
ピン配置の互換性
ピン配置の互換性ですが、図にすると以下のようになります。
TE0803はMGTの数が少なく、PLLが簡素化されているので、該当する部分の端子がNCになっていたり、クロックの入力が接続されていない部分があります。
TE0807の違い
TE0807とTE0808の違いを簡単に説明すると、VCU(ビデオコーデックユニット)用の電源の有無と、GT_Lの存在です。
TE0808のMGT(GTH)はGT_LとGT_Rに分かれていてB128だけが特別なGT_Rになっていました。それに対してTE0807ではGT_LとGT_Rの区別がなく、すべてGT_Lに集約されています。電源のEN_GT_Rの端子は残っていますが機能はありません。
このような軽微な違いだけなので、TE0807とTE0808は実質的に同じように使えます。
また、J3に出ているHDバンクのIOの番号が少し変わっています。
TE0803の違い
TE0803で使われているFPGAは784ピンのパッケージで少ないので、PLのMGTがないか、あっても4chしかありません。XCZU4とXCZU5のみMGTが使えて、XCZU2とXCZU3はMGTがありません。
なお、PSのMGT(DisplayPortやUSB3.0に使うもの)は4chあって、コネクタに出ているのですべて使えます。
また、TE0803に搭載されているオンボードのPLLはSi5338Aという4chタイプのものです。I2Cを使ってコントロールできるのでPLL_SDAとPLL_SCLはありますが、それ以外のPLL_FDECなどはありません。
まとめ
TE0803とTE0807とTE0808はピン配置に互換性があります。TE0808用に作ったベースボードにTE0807やTE0803を搭載することができます。
TE0803は小規模なFPGAなので、もともとPLのMGTがないか少なく、存在しないMGTの端子がNCになっています。また、TE0803のPLLは簡素化されているのでPLL_SDAとPLL_SCL以外の信号がありません。
もしMGTが1 bank (4ch)でよいならば、ユーザが作るベースボードではB228 (B224)を使うようにすれば、3種類のボードで互換性を保つことができます。
TE0808の電源の供給方法についてメモしておきたいと思います。
UltraScale+にはたくさんの種類の電源が必要なのですが、こういったFPGAボードでは外部から1種類の電源を与えるだけで、内部でいろいろな電源を作り出すようにできているはずです。
データシートを見ると、電源の供給ツリーは下の図のようになっています。これだけの数のレギュレータが載っているってすごいことだと思います。
電源入力は、DCDCIN、PL_DCIN、LP_DCDC、GT_DCDCの4つの大きな電源と、PS_BATTとPLL_3V3のオプション的な電源です。
ZYNQの電源供給は全部同時ではなく、順番に立ち上げていくことが推奨されています。TE0808ではありがたいことに、ボード上のレギュレータのPGとENを巧みに使って、各種レギュレータが順番に電源ONするようになっています。そのためユーザが電源レールの立ち上がり順序を気にする必要はありません。
DCDCINはフルパワードメインに使われ、LP_DCDCはローパワードメインに、PL_DCINはPLに、GT_DCDCはMGTに使われます。各電源の入力電圧範囲は
となっています。バッテリとPLL用電源、LP_DCDCは絶対最大定格が低いので要注意です。
PS_BATT以外はすべて3.3Vに接続すればOKです。
TE0808には電源出力端子がある
TE0808はボード上で様々な電圧を作り出しますが、PSとPL用の1.8Vがコネクタから出力されていて、いろいろなことに使えるようになっています。特にPS_1V8とPL_1V8が便利に使えます。
PSとPLで分けている理由は、個別に電源をON/OFFするためだと思われます。
PS_1V8はPSのモード設定用抵抗のプルアップなどに活用できます。PL_1V8はPLのBankのVCCIO用に活用できます。
このほかにDDR用のDDR_1V2や、PLL用のSI_PLL_1V8がありますが、有効的な利用方法はあまり思いつきません。
TEBT0808の電源供給方法
Trenz社のベースボードTEBT0808の回路図を見てみると、PL_DCIN、LP_DCDC、DCDCIN、GT_DCDCはすべて同一の3.3Vの電源にそのままつながっています。
特にこだわりがなければユーザが作るベースボード上で区別することなくそのままつなげばOKです。
PS_BATTは、1.8Vのラインからダイオード(SDMG0340LC)を通じて供給しています。ダイオードの順電圧降下を期待しているのだと思いますがZYNQのPS_BATTの消費電流がゼロならば電圧降下しないので、結局のところ1.8Vくらいが加わってしまいますが、絶対最大定格はクリアしているのでよいのでしょう。
PLL_3V3は、3.3Vのラインから1uHのコイルでフィルタして供給しています。
まとめ
以上のことをまとめると、電源供給は下の図のようにすればよいことがわかります。
TE0808への電源供給は上の図のオレンジで囲んだ部分に3.3Vを供給すれば良いようです。
VCCOは、ボード上で生成されるPL_1V8を使用して供給します。
PS_BATTは、PS_1V8をダイオードを通して供給します。
PLL_3V3は3.3Vラインからコイルを通して供給します。
3.3Vが使用可能なバンクはVCCO47とVCCO48のみですが、Trenz社ベースボードのTEBF0808でもTEBT0808のどちらも1.8Vで使用するようになっていました。今日ではあまり3.3Vというのは使わなくなってきているのかもしれません。
TE0808のJ2の端子を眺めてみると、I/OピンやMGTピン、電源ピンのほかにPG_xxxやEN_xxxといった設定ピンがたくさんあることに気が付きます。
今回はこれらの設定ピンの使い方を紹介します。
EN_xxxとPG_xxx
ZYNQ UltraScale+の電源はLowPowerドメインやFullPowerドメインなど、いくつものドメインに分かれています。これらのドメインごとに電源をON/OFFするためのピンがEnableを示すEN_xxxと、PowerGoodを示すPG_xxxです。
EN_xxxには以下のものがあります。
となっています。
EN端子は、それぞれの電源ICのENABLE端子につながっていたり、PG信号とANDをとるためのワンチップゲートにつながっていたりするのですが、すべて3.3Vのロジックで動作するようになっています。Trenz製ベースボードのTEBT0808の回路図を見ると3.3Vから5.1kΩでプルアップしてDIPスイッチで切り替えられるようになっているので、GNDか、3.3Vへプルアップするかという選択ができればよいと思われます。
MGTにはRとLがあります。MGT_RはBank228、Bank229、Bank230で、J1に出ているGTHが該当します。
MGT_LはJ2に出てきているBank128のGTHが該当します。
PSGTというのは、DisplayPortなどで使われるPSのGTです。
なお、TE0808にはSilab社(現Skyworks社)のSi5345Aというクロックドライバが搭載されています。EN_PLL_PWRはSi5345Aの電源を個別にON/OFFするためのものです。Si5345Aは最大で1200mWの電力を消費し、また極めて敏感なPLL発振器なので個別の電源を用意しているのだと思われます。
PowerGood系の信号には
があります。これらの信号はLP_DCDCやDCDCIN(通常は3.3V)などの電源入力に対して数kΩでプルアップされています。
まとめると、EN_xxxは3.3Vにプルアップすると各電源が有効になり、PG_xxxがHにプルアップされるというわけです。使わないクロックドメインは個別にシャットダウンできます。
PLL系信号
前述のようにTE0808にはクロックドライバSi5345Aが載っているのですが、このSi5345Aのコントロール信号がPLL_xxxの信号です。
いろいろな信号がありますが、最低限必要なのはPLL_SCLとPLL_SDAです。I2CのインタフェースでSi5345Aの内蔵レジスタや内蔵ROMに書き込みを行うために必要です。出荷時にはSi5345Aは書き込みが行われていないので、SkyWorks社のツールをつないで外部から書き込みができるよう、ベースボードにはPLL_SDAとPLL_SCLをコネクタ等に出しておくか、FSBL中で操作できるようにしておく必要があります。
PLL_SDAとPLL_SCLの信号は1.8Vロジックです。ベースボードを設計する際に、ベースボード上にプルアップ抵抗を付けてください。I2Cのアドレスは1101001bです。
なお、TE0808にはEEPROMが乗っていて、PLL_SDA、PLL_SCLを通じてアクセスができるようになっています。しかし、これはSi5345Aのメモリではなく、MACアドレス等を記憶しておくための汎用的なEEPROMとして使われることを想定しているようです。
JTAG系信号
TCK、TDI、TMS、TDOはJTAG信号でPSの1.8V系のロジックとなっています。
MR信号
MRという信号は電圧監視IC「TPS3106」のMR端子につながっています。MRはManual Resetの意味であるようです。LPDの電源電圧である0.85Vが0.74Vを下回るとリセット信号POR_Bを出します。また、MR端子からもマニュアルでリセットできます。
つまり、MRをLにすると、POR_BがLになってリセットがかかります。MRはTE0808でどこにも接続されずにコネクタに出ているので、リセットを使用しない場合はオープンにすればよいでしょう。
なお、MRはTPS3106内部でLP_DCDC(3.3V)レールに対してプルアップされています。HになるのはVDD×0.7Vなので、1.8Vを加えてもHの電圧になりません。リセットをかけない場合はオープンにして、リセットをかける場合にGNDに落とすようにします。
ZYNQのコンフィグ関連端子
以下の端子はZYNQのコンフィグ関係の端子がそのまま出ています。
TE0808ボード上で4.7kΩでプルアップがされている(PUDCは1kΩ)ので、ユーザボード上ではオープンにしておいて構いません。
ZYNQのモード設定端子
MODE0..MODE3は、ZYNQの起動モードを決定します。MODEの値と起動モードの対応は以下のようになります。
ZYNQ7000シリーズと異なり、SD0だけではなくSD1が使えるようになっていたり、USBやPJTAGからも起動できるようになっていて進化を感じさせます。
TE0808上ではプルアップもプルダウンもされずにコネクタに出ています。様々なモードを試すことがあると思うので、プルアップ/ダウン抵抗やDIPスイッチで設定しておくとよいでしょう。なお、ロジックレベルは1.8Vで、プルアップ先はPS用の1.8Vです。
ZYNQのエラー端子
ZYNQ UltraScale+のPSにはERR_STATUSとERR_OUTというエラー端子があります。
ERR_OUTはZYNQ内部のPMUが電源断やエラーや例外を検出するとアサートされます。ERR_STATUSはセキュアロックダウンステートであることを示します。いずれも1.8VのPS_1.8V系ロジックで、アサートされるとHになります。
TE0808のコントール端子の使い方まとめ
TE0808の端子を調べているつもりが、いつのまにか、Zynq UltraScale+の端子の使い方を調べることになっていました。
最近、TrenzElectronic社のSoMモジュール「TE0808」を応用したシステムの開発を行っています。
TE0808はUltraScale+のXCZU9EGやXCZU11EGなど大規模なFPGAを搭載したモジュールで、約1000本以上もあるBGAのパッケージを解きほぐして順番に並べてピンヘッダに出してくれるという、いわば変換基板です。
このモジュール上にUltraScale+設計の難しいところはすべて凝縮されているので、4層基板で簡単なベースボードを作るだけでZYNQ UltraScale+応用機器が作れるようになるというわけです。
ただし、TE0808モジュールには640本のピンがあり、これらをどのように接続すればよいのか、またコネクタの位置や向きはどうすればよいのかなどがわかりにくいので、当ブログで分かりやすく書いていこうと思います。
外観
まず、TE0808の外観、表面、裏面の写真を示します。TE0808は76mm×52mｍのカードサイズで、極めて実装密度が高く、ZYNQ UltraScale+のほか、DDR4メモリ、SPI ROM×2個、クロックジェネレータICなどが搭載されています。
基板の表面にはFPGAが乗っていて、裏面にはコネクタが付いています。ユーザがベースボードを作る際には裏面に勘合するように作るわけなので、裏面を裏から見た図が必要になります。
寸法とコネクタの位置
BottomViewな基板の寸法と、コネクタの位置を示します。
中央で上下左右対称になっています。コネクタの1番ピンの位置がわかりにくいので上の図で●を付けています。ネジ穴は基板の角から3.8mmの位置にあり、内側のネジ穴は8mm内側にあります。
メザニンコネクタの型番
メザニンのコネクタですが、SoMボード上に実装されているのはSAMTEC社のST5-80-1.50-LD-P-TRです。STシリーズの意味はTerminal Strip。分かりやすく言えばオスです。端が凹凹のほうが1番ピン、凸のほうが160番ピンのある方となっています。
これに勘合するコネクタ、つまりユーザが作る拡張ボード上のコネクタはSAMTEC社のSS5-80-3.50-L-D-K-TRです。SSシリーズの意味はStripです。わかりやすくいえばメスです。
端子の配置
端子の配置は以下のようになります。
メザニンコネクタの機能
まずはコネクタの機能から解説しますと、
・J1にはGTHのB228,B229,B230、一般I/OのB66がある
・J2には電源入力、JTAG、モード設定、電源設定、PSGTR、GTHのB128がある
・J3にはMIO、一般I/OのB47、B48がある
・J4には一般I/OのB64とB65がある
となっています。なお、J3とJ4はだいたい左右対称にできているのですが、一部のVREFとGNDが対象になっていません。
I/Oの電圧
一般I/OのB64、B65、B66は最大で1.8Vまでです。3.3Vでは使えないのでご注意ください。
I/Oで3.3Vを使う場合はB47とB48を使用します。
また、MIOはすべて1.8V仕様になっています。SDカードを接続する場合にはレベル変換が必要です。
新たに2種類の基板を作りました。
お客様から依頼を受けて作った基板で、一般販売はしないので、ちょいとモザイクをかけています。
上の小さな基板は、特電のArtix-7ボードにMIPI CSIカメラをつなぐためのボードですが、4レーンのものとなっています。RasPiカメラが2レーンなので、単純に考えてその2倍のデータレートが出ます。
下の大きな基板は、Trenz社のTE07xxボードを搭載してArduino形状の拡張ピンを出すためのボードです。もちろんArduino化するだけではなくいろいろな機能が付いています。
今日、ACRiのウェビナーでライトニングトークをさせていただき、その講演内容をYoutubeで公開しました。
この機会に「なひたふJTAGちゃんねる」を開設しました。
ああ、超恥ずかしい・・・(/ω＼)
https://www.youtube.com/channel/UCnBxjOIhpRNdDi_KLMmkcKw
ちなみに、動画は「ゆっくりムービーメーカー4」というソフトを使って編集しています。
音が響いて聞きづらいのですが、これは使っている会議室の音の反響が大きいからです。聞きづらさを補うために字幕を入れてみたところ10分の動画を編集するのに2時間半もかかってしまいました。
また、会議室のホワイトボードの高さが低いので、立ったままだとホワイトボードが活用できないです。
動画を撮るのって難しいですね。
今後は週1くらいのペースでJTAGの技術的解説の講演なんかをアップロードしていきたいと思います。
XILINXのMIPI CSI RX SubSystemコアはMIPI CSIの信号をデコードしてAXI Streamで出力してくれるコアですが、Embedded non-image interfaceというチェックボックスがあります。
これを使うとEmbedded Data Lineの内容が読めるようになるらしいです。
ぽちっとONにしてみましょう。
すると、emb_nonimgというAXI Streamのインタフェースが出現します。
なんと、tdataが64bit、tuserが96bitもある極太のインタフェースです。
まぁ、どんなデータが来るのか見てみましょう。
昨日のブログで書いた「先頭2ライン」のときにemb_tvalidが立ちます。一般の画像ラインのときにはemb_tvalidはLのままです。
先頭部分を拡大してみると、
16進での表示の都合上、上位32bitと下位32bitに分けて表示しているのですが、くっつけると
0x025a0055-a500aa0a 0x5a195a6e-555a7b5a
となっています。
下位から順番に読んでいけばいいのですが、4バイトごとに挿入されるDummy Byte(0x55)はそのまま残っているので、大変読みづらいですね。コアの中で削除しておいてくれればよかったのにと思います。
また、10クロックに1回くらいしかtvalidが立っていないので、こんなに広いバス幅にする意味もないと思います。もうちょっとコアが頑張ってほしかったと思います。
また、96bitあるtuserの内容にはあまり役に立つものは入っていないようでした。
MIPI CSI RX SubsystemコアではチェックボックスをONにすることでEmbedderd Data Lineを読むことができるようになります。
これが何に役立つのかというと、現在の解像度を読み取ってダイナミックにHとVのサイズを変えられるような回路にするとか、そういう応用ができるでしょうか。
XILINXのMIPI CSI RXコアで画像のデコードができるようになったので、再び生のパケットを目で見てみることにしました。
MIPIカメラの最初のパケットは次の図のように、最初に超短いパケットが来て、そのあとで2つの水平ラインがすぐに送られてきます。
FPGAに内蔵したロジアナで見てもこのようになっています。
水平ラインは周囲の明るさなどとは関係ない値が送られてくるので、初めはノイズかバグかと思っていたのですが、iMX219のデータシートを読んでみてようやくわかりました。
最初の短いパケットはFrame StartというShort Packetで、次の連続して2回送られてくるものはEmbedded Data Linesというもののようです。
iMX219データシートの図を掲載します。
どうやらMIPI CSIのパケットにはShort PacketとLong Packetというのがあるようで、Short Packetは4バイト、Long Packetは水平ライン長+6バイトの長さがあります。
どちらも最初はData IDとなっていますが、
・0x00はFrame Start
・0x01はFrame End
・0x12はEmbedded Data
・0x2AはRAW8フレーム
・0x2BはRAW10フレーム
となります。
実際のデータを見てみましょう。
まずはShort Packet。
0x00 0xF7 0x00 0x2Cと読めます。
最初の0x00はFrame Startのコードで、続く0xF7 0x00はWord Countのようです。16bitの値ですが上位8bitはいつも0になっています。最後の0x2Cはエラーチェック用のECCであるようです。
次の長いパケットはごちゃごちゃしています。
2つのレーンがありますが、レーン0→レーン1→レーン0→レーン1・・という順番で読んでいくのだと思われます。
読んでみると、
12 54 06 31 0A AA 00 A5 55 00 5A 02 5A 55 19 5A 20 55 55 07 5A 7B 5A 55 6E 5A 79 5A 55 04 A5 0D 5A 55 08 5A 16 ・・・
とにかく5とかAとかの多い高周波な波形ですね。
パケットの最初のバイトが0x12なので、Embedded Dataであると思われます。続く0x54 0x06は0x0654と呼んでラインの長さです。0x31はECCなので無視して構いません。なので、0x0Aからがパケットの正味のデータです。
読み方はデータシートに書いてあるのですが、RAW8の場合とRAW10の場合でフォーマットが違うのですが、RAW10の場合では、
となっています。
なるほど。最初の0x0Aはヘッダみたいなもので、Tagは次のDataの意味を示すようです。Tagにはいくつかあって、
・0x00 無効なタグ。データの終わりとして扱う
・0x07 データの終わり
・0xAA CCIレジスタのインデックス MSB[15:8]
・0xA5 CCIレジスタのインデックス LSB[7:0]
・0x5A 自動でインクリメントされるCCIのデータ(データがある)
・0x55 自動でインクリメントされるCCIのデータ(データが無効)
・0xFF 無効なタグ。データの終わりとして扱う
となっています。
この内容を見ると、どうやらCCIレジスタ(I2Cで読み書きできるコントロールレジスタ)の内容を最初のラインで出力しているようです。
まず4バイトごとに挿入されるDummy Bytes(0x55)を削除します。
0A AA 00 A5 00 5A 02 5A 19 5A 20 55 07 5A 7B 5A 6E 5A 79 5A 04 A5 0D 5A 08 5A 16・・・
TagとDataの組に分割します。
・AA 00・・・CCIレジスタの上位8bitは00
・A5 00・・・CCIレジスタの下位8bitは00。次はレジスタ0x0000から読み出す
・5A 02・・・レジスタ0x0000の値は0x02
・5A 19・・・レジスタ0x0001の値は0x19
・5A 20・・・レジスタ0x0002の値は0x20
・55 07・・・レジスタ0x0003は存在していない
・5A 7B・・・レジスタ0x0004の値は0x7B
・5A 6E・・・レジスタ0x0005の値は0x6E
・5A 79・・・レジスタ0x0006の値は0x79
・5A 04・・・レジスタ0x0007の値は0x04
・A5 0D・・・CCIレジスタの下位8bitは0D。次はレジスタ0x000Dから読み出す
・5A 16・・・レジスタ0x000dの値は0x16
・・・
と読めます。CCIレジスタの最初の部分はこうなっているので、
まさに、CCIレジスタの内容が最初の2でラインで送られてきていることがわかります。
次のラインからは
というパケットが送られてきていて、読むと、
という画像データと思われる内容でした。
結論を言うと、
でした。ぶっちゃけ、最初の2フレーム(ヘッダが0x12)は無視してもよさそうですね。
このパケットの構造がわかれば、MIPI CSI RX SubSystemコアを使わずにMIPI D-PHYでもCSIの画像デコードができるようになると思います。
MIPI CSI-2 Rx Subsystemの使い方が分かりました。このコアを使うとMIPIの信号をデコードしてAXI Streamにして出力してくれるので、RasPiカメラV2の信号をデコードしてみたいと思います。
MIPI CSI-2 RX Subsystemというコアは中にMIPI D-PHYと、MIPI CSI-2 RX ControllerとVideo Frame Bufferが入っています。コアの内部構造を下の図に示します。
Vivado 2019の頃は無償ではMIPI D-PHYしか使えなかったのですが、Vivado 2020からはRX ControllerやVideo Bufferまで入ったMIPI CSI-2 RX Subsystemも無償で使えるようになったというわけです。
まず、IP Integratorを使ってBlock DesignにMIPIコアを置いたら、ダブルクリックして以下のようにカスタマイズします。
一番重要なのはPixel Formatで、RAW10にします。このパラメータは必須でカメラの出力フォーマットと一致していないと出力が何も出てこなくなります。RasPiカメラV2の出力フォーマットはRAW10かRAW8で設定で買えられますが、普通はRAW10で使うと思います。とにかくカメラの出力フォーマットと合わせてください。
その右にあるSerial Data Linesは2にします。2レーンということです。
次のLine Rateは555にしましたが、効果があるのかどうかはわかりません。少なくともPLLの発振周波数とかを決めているわけではなさそうなので適当でもいいのかもしれません。
デバッグを便利にするオプションとして、CSI2 Controller Register Interfaceというチェックボックスがあります。
ONにするとAXI Liteでレジスタを操作することでコアを動かしたり止めたり、ステータスを見たりすることができるようになりますが、AXI Liteを使うのも面倒なので、好みの問題ですがOFFにしておきます。なお、デフォルトでコアは動作開始になっているのでAXI Liteのマスタには何もつながなくても動くはずです。
OFFにするとAXI Liteのコントロース・ステータスポートが消えて、個別信号が出てきます。それが、ctrl_core_enや、dl0_stopstate_intrなどのバラバラとした信号です。ロジアナで見ればよいので楽です。ctrl_core_enは適当なタイミングで1にします。
Pixels Per Clockは1のままでよいでしょう。MIPIの速度が速くAXI Streamが追い付かない場合に2や4にすると複数のピクセルを同時に出してくれるようになるのだと思います。
このようにして作ったBlock Designを下の図に示します。右上のRTLのブロックはI2Cのシーケンスを出してカメラを設定するためのもので、右下のvideo_bloganaというコアはAXISの信号をキャプチャするためのロジアナです。
MIPI CSI-2 RX Subsystemの入力側のポイントは2つです。
実際に動かしてみた波形を示します。
AXI Streamで出力されますが、XILINXのVideo AXI Streamはライン0の先頭でtuser(0)が立ちます。したがって下の波形はライン0のものです。
このAXI Streamにはtdest[9:0]というサイドバンド信号があるのですが、Product Guide PG232を読むと、tdest[9:4]はData Typeと書いてあります。
Data Typeとは何ぞやということなのですが、RAW10やRAW8といったデータのタイプのことを示す6bitの値のようです。RAW10の場合は0x2Bとなります。上の表を見るとライン番号などもtuserから出てくるようなのでtuserを広げればデバッグも楽になりそうですね。
tdataの開始部分から拡大してみてみると、tvalidとともに10bitのデータがやって来るのがわかります。
青いLEDをカメラの間近で見せると
小・大・小・大という並びになったので、IMX219のデータシートどおりライン0はGb・B・Gb・Bという並びなのかもしれません。
これがそのままAXI Streamで出ているのではないかと思われます。なお、tvalidの長さは1296でした。
この1296という長さはIMX219にI2C経由で0x016C <= 0x05、0x016D <= 0x10と設定しているので想定どおりです。
デコードしたデータが綺麗な画像になっているかどうかはDDR3メモリに展開してUSBで吸い上げてみないとわかりませんが、ここまでのところ不安定さは全くなく、制御コード等は必ず同じデータが取れていました。
いろいろ苦労しましたが、一番大事なポイントはカメラの出力フォーマットとコアのフォーマットを合わせないと全く何も動かないというところでした。
早くDDR3メモリとつないで画像をキャプチャしてみたくなります。
今度、ACRiのウェビナーでライトニングトークをすることになりました。
ACRiルームには100台を超えるArtyと、Alveoがあるらしい。
特電はACRiの創設企業なのに、いままでACRiルームを使ったことがなかったので、この機会にACRiの環境をひととおり使えるようにしてみました。
やり方をメモしておきます。
まず、登録申請のページから登録申請します。
しばらくするとパスワードがメールで送られてきますが、パスワードは2種類あります。一つはLinuxのシステムにログインしてFPGAの開発などを行うためのもの。もう一つはサーバの予約をするためのもの。
ちょっとややこしいのですが、VivadoやVitisが動いているのはLinuxのマシンなのでLinuxのアカウントが必要。サーバの予約はWebのシステムで出来ているようで、うまく統合されていないようなのでパスワードは2つあるようです。予約システムのほうはWebブラウザに登録されるので滅多に手入力することはないでしょう。
よく使うパスワードはLinuxのほうです。
パスワードが発行されたらサーバ予約のページから使いたいサーバと時間の欄をクリックします。
ag001が高級サーバ、as001～as004はAlveo用のサーバ、vs001～vs615がArty用のサーバとのことです。
この中で好きなサーバ（申請の登録時にお勧めのサーバが示される）を使います。各サーバにArtyやAlveoがぶらさがっていて、1台のサーバに最大15台のArtyがぶらさがっているというのですから、すごいですね。
こんな感じの画面が出たら予約を押します。私の推奨はvs601でした。ボタンを押したら5秒ほどでそのサーバが使えるようになります。
これらのサーバは仮想的なサーバで、予約ボタンを押すと起動するしくみになっているようです。
「使う」というのは、ゲートウェイとなるサーバ(gw.acri.c.titech.ac.jp)に対してSSHで接続し、リモートデスクトップ接続をポートフォワーディングして仮想サーバに接続して使うという意味です。
ACRiルームの使い方を図にすると、こうなります。
つまり、gw.acri.c.titech.ac.jpはSSHの中継用のサーバで、TeraTermのポートフォーワーディングの設定をします。
Windowsのリモートデスクトップ経由で仮想サーバのデスクトップに接続できるようになりますが、ここでパスワードを聞かれる(ユーザ名は聞かれない)ので、Linux用パスワードを入力します。
そうしたらデスクトップが出るので、
左上のほうにあるActivityをクリックしてスタートメニューが出たらtermを開いて、
source /tools/Xilinx/Vivado/2020.1/settings64.sh
としてVivadoの設定スクリプトを起動します。
それから、
vivado &
でGUI版のVivadoを起動します。
ACRiのファイルはどのサーバにログインしても同じファイルシステムが見えるようになっているので、as001～vs615のどれにログインしても自分専用の同じファイルシステムが見える(/home以下はどのサーバにログインしても同じ！)ようです。
気になる速度ですが、Vivadoが起動してから後はめっちゃ速いですね。
Hardware Managerが一瞬で起動します。さすがCore i9。
各仮想マシンには専用のArtyが1台ずつぶらさがっていて、VivadoのHardware Managerを開くとDigilentケーブル越しにハードウェアが見えます。Vivadoのこの画面から書き込みなどができるわけです。
私としては書き込みの部分が一番知りたかったところです。
まとめると、
ということでした。
もともとのサーバが超速いのですが、リモートデスクトップ経由で操作するとネットワークの関係で重くなってしまいます。
そこで、
といったことができるとサクサク動いてさらに便利なのではないかと思い、実際にできるようにしました。
そのような方法もライトニングトークでお話していきたいと思います。
これまで特電製品のArtix-7ボードとSpartan-6ボードについては、下の写真のような4面フルカラー印刷されたダンボール箱に、スポンジ製の仕切りを入れて、付属品のCD-ROMや印刷されたマニュアル、ケーブル類、ピンヘッダ等を入れて発送していました。
特電では7cm×5cmサイズのFPGAボードを発送するためにこの梱包を行うのは過剰ではないかとの懸念を抱いており、環境保護と省資源化の観点からこのパッケージを全面的に改めることにいたしました。
本日以降のご注文分に関しては下の写真のような8cmサイズの紙箱に入れて発送いたします。
箱の内容物は
のみとし、衝撃吸収用と仕切り用のスポンジを廃止しました。基板自体は静電気を避けるため導電袋に入れております。
マニュアルとCD-ROMは、Webサイトからダウンロードできるため今後は添付しないこととしました。
また、これはではボード1台ごとにケーブルやACアダプタを添付していましたが、不要という方も多く、今後は別売りとさせていただくことにしました。
以上のように梱包資材と梱包作業の簡素化、および付属品の別売りによるコスト削減を行ったため、各商品の販売価格を5000円(税別)引き下げることにいたしました。
もし従来の梱包での出荷をご希望というお客様がいらっしゃいましたら、資材在庫がある間は対応させていただきます。メール等でお問合せください。
Cypress EZ-USB FX3(CYUSB3014)はファームウェアを格納するためにSPI ROMを使うことができます。
このSPI ROMにはいままでAdesto(現Dialog)のAT25SF041Bなどを使っていたのですが、昨今の半導体不足のためか、それともディスコンなのか、入手が難しくなってきました。
DigikeyでもRSでもMouserでもChip1でも、幅の細いSOIC8の物が見つかりません。
DigikeyにはAT25XE041BというROMならば大量にあるのですが、これを使うことはできるでしょうか？
AT25SFとAT25XEは何となく型番が似ているので行けそうな気がする！と思い、AT25XEを使ってArtix-7ボード24台と、Kintex-7のPCIeボード2台を製造してしまいました！！！
いざ電源を入れてファームウェアを書き込んでみると・・・
起動しない。
なんてことだー。やはりAT25XEだとEZ-USB FX3は起動しないのか？？？
途方に暮れてデータシートをじっくり読みました。
どうやらAT25XEはデフォルトですべてのセクタにプロテクトがかかっているので、書き込めなかったようです。
さて、CypressのEZ-USB FX3でSPI ROMに書き込むには、CypressからCyControl.exeというのが用意されています。
CyControl.exeはROM書き込み用のファームウェアとしてCyBootProgrammer.imgという「I2C/SPI ROM書き込み用ファームウェア」をいったんRAM上にロードして書き込んでいます。ファームウェアが2段階になるわけです。
そのため、CyBootProgrammer.imgのソースを見つけてきて、AT25XEならばUnprotectの処理を行うようなコードを追加した新たなファームを作って置き換えればよいということになります。
CyBootProgrammer.imgのソースですが、おそらく、EZ-USB FX3 SDKの中にある \1.3\firmware\basic_examples\cyfxflashprog でしょう。ベンダIDとプロダクトIDが04b4:4720で同じです。
AT25XEのUnprotect Sectorのやり方には2通りあって、一つはセクタごとにUnprotectを行う方法、もう一つはGlobal Unprotectを行う方法です。セクタごとのUnprotectはコマンド39hの後にアドレス(3バイト)を送ればよいようなのですが、セクタの構成とかを調べるのが大変です。
やはり、おすすめはGlobal Unprotectです。ステータスレジスタ1に00hを書き込むだけでOK。コマンドとしては01h 00hです。これを行うためにファームウェア内に次のような関数を作ります。
void UnprotectAT25XE()
{
uint8_t buf[8];
buf[0] = 0x9f; /* Read IDCODE */
CyU3PSpiSetSsnLine (CyFalse);
CyU3PSpiTransferWords (buf, 1, 0, 0);
CyU3PSpiTransferWords (0, 0, buf, 4);
CyU3PSpiSetSsnLine (CyTrue);
buf[0] = 0x05; // Read status command
CyU3PSpiSetSsnLine (CyFalse);
CyU3PSpiTransferWords (buf, 1, 0, 0);
CyU3PSpiTransferWords (0, 0, buf, 1);
CyU3PSpiSetSsnLine (CyTrue);
if((rom_id[0] == 0x1f) && (rom_id[1] == 0x44) && (rom_id[2] == 0x02)) // AT25XE041Bならば
{
buf[0] = 0x06; // Write Enable
CyU3PSpiSetSsnLine (CyFalse);
CyU3PSpiTransferWords (buf, 1, 0, 0);
CyU3PSpiSetSsnLine (CyTrue);
buf[0] = 0x01; // Write Status Register
buf[1] = 0x00; // Global Unprotect
CyU3PSpiSetSsnLine (CyFalse);
CyU3PSpiTransferWords (buf, 2, 0, 0);
CyU3PSpiSetSsnLine (CyTrue);
buf[0] = 0x05; // Read status command
CyU3PSpiSetSsnLine (CyFalse);
CyU3PSpiTransferWords (buf, 1, 0, 0);
CyU3PSpiTransferWords (0, 0, buf, 1);
CyU3PSpiSetSsnLine (CyTrue);
}
}
この関数をcyfxflashprog.cのCyFxFlashProgSpiInit()の後で呼び出せばOKです。SPIの初期化完了後にIDCODEを調べてAT25XE041ならば即座にGlobal Unprotectを行うようになります。
Cypress Ez Suiteでビルドするとcyfxflashprog.imgという名前のファイルが出来上がっているので、これをCyBootProgrammer.imgにリネームすればCyControl.exeで自動的に読み込んでくれます。
自作のFX3書き込みアプリでロードして、自作アプリ中からFX3のROMを書き換えてみてもいいでしょう。
◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇
おまけですが、こういったSPI ROMのデバッグを行うには、ベンダリクエストを発行できたほうが便利です。
CyControl.exeではどうやってSPI ROMに書き込んでいるかというと、まずDownloadUserIMGtoSPIFLASH()を呼び出してDownloadUserIMGtoSPIFLASH()の中ではWriteToSPIFlash()を呼び出していて、WriteToSPIFlash()の中ではEp0VendorCommand()を呼びだしています。
DownloadUserIMGtoSPIFLASH() → WriteToSPIFlash() → Ep0VendorCommand()
最終的にはEP0VendorRequest()に行きつきます。ユーザプログラムからEP0VendorRequest()を呼び出せれば何でもできるのですが、CyUSB.dllの中にあるCyFX3Deviceクラスでprivateにされているため見えません。
本来はこの関数を使うとEndPoint0に自由なコマンドを発行してEZ-USB FX3のファームウェアと直接通信できるのですが・・・。こんな便利な関数をprivateにしておくのは勿体ないのでpublicにしてしまいましょう。
CyUSB.dllのソースコードを見つけてきて、CyFX3Devices.csの93行目
private bool Ep0VendorCommand(ref byte[] buf, ref uint buflen, bool IsFromDevice, byte ReqCode, uint Value)
というけしからん行を
public bool Ep0VendorCommand(ref byte[] buf, ref uint buflen, bool IsFromDevice, byte ReqCode, uint Value)
にしてビルドします。
こうして出来上がったCyUSB.dllを使うとベンダリクエストが使えるようになります。
私はSPI ROMのIDCODEやStatusの読み出しとしてコード0xc5を割り当て、チップイレースに0xc7を割り当てました。
結論を言うと、AT25XEはデフォルトで全セクタがプロテクトされているという鬼畜仕様だけど、プロテクト解除してあげれば普通のSPI ROMとして使えるようになるということです。
半導体不足の世の中でSPI ROMがなかなか入手しづらいので、EZ-USB FX3のファームウェア格納にAT25XEが使えるようになるのはよいことだと思います。
半導体メーカーさんは、独自の色を出さなくていいから、業界標準のを作ってください。どうかお願いします。
<m(__)m>
最近のコメント