GTXのリンクが外れる
電源モジュールを交換したCosmo-ZでGTXの通信実験をしたのですが、なぜかリンクが外れるという事態に。
うーん、なぜなんだろう。
この千石の同軸ケーブルに6Gbpsが速すぎるのか、プロトコルをちゃんと作らなければならないか。
2020.04.27
2020.04.26
64ch版Cosmo-Zの内蔵電源モジュールを交換した
Cosmo-Z 64という製品をひそかに開発中です。
中には32ch化したCosmo-Zを2台入れて、相互に接続して64ch化を目指すというものです。
この装置は5V8A程度の電流を消費するので、中に12V→5Vの電源モジュールを入れていたのですが、その電源モジュールがあまりにもクソだったのです。
激しいノイズをまきちらして、ADCとFPGA間のLVDSの通信(1Gbpsになる)のリンクを外させたり、たまにCPUがリセットしたりします。オシロのプローブを近づけると5Vものノイズが誘起されているほど、磁界ノイズを発生させる酷い代物だったのです。
下の波形は、オシロのプローブを5Vの線にあって測ったものです。5Vの電源のはずなのに+2.5～+7.5Vを観測しています。
実はここまではひどくなくて、10cmはあるGNDのループが磁界を拾ってしまっているため+2.5～+7.5Vとして観測されています。GNDのリードの代わりに錫メッキ線で短いリードを作って測るとこんなものでした。
結合をACにして電圧軸を拡大してみています。5V±200mVくらいでしょうか。
このスパイク状のノイズは結構キツイので、スイッチング電源を通して出てきた1.8V電源にも±150mVほどのノイズを乗せてしまいます。
こんな激しいノイズをまき散らしているので、CPUには突然リセットがかかってしまいます。
計測値には周期的におかしなノイズが乗ります。
酷い時には、LVDSのリンクが外れます。おそらくADCが気絶しているかFPGAのISERDESが気絶しています。
本当に、ここまでひどい電源があったのだろうかというほど、酷いです。
まぁ、100V→5VへのDCDCなど世の中にいくらでもあるので、本当なら装置にAC100Vを供給して5Vを作るのが筋なのでしょうが、PSE法という悪法があるため1台だけ作る装置に100Vの入力はできないのです。PSE法をすぐにでも撤廃してほしいですわ。
この電源モジュールを撤去して、別のモジュールに置き換えました。
Digikeyで購入したMeanWell社のSD-50A-5という電源です。アメリカの会社なのですが製造は中国です。
最初のクソ電源との違いはトランスの数です。
5V±50mV程度で、静かです。磁界のノイズも測れないほど小さいものです。
もう一つ試したのは5V8Aという化け物級ACアダプタで、GlobTek, Inc.のTR9WA8000LCPIM(R6B)というものです。
これもノイズが少なく、SD-50A-5と同じほどでした。ボード上で生成した1.8Vの電源にも、ACアダプタ由来の電源は見当たりません。
最初のDROK DCだけが異常なほどノイズが大きかったことがわかります。
後の2つの電源のうちどっちが良いかは難しいところですが、装置本体を軽くするため、5V8AのACアダプタを採用することにしました。
これでCosmo-Zが32ch+32chの64chで動作するようになりました。
次は2台の基板の同期をどうやって作るか、です。
2020.04.24
Artix-7のPCI Expressボードを作ります
Artix-7のPCI Express基板を作ることにしました。
DDR3を乗せるかどうかとか悩む点は多いのですが、今までの自分はあれもこれも付けてコストが高くなるという傾向にあったので、今回はコストを最優先してみることにしました。
◆AM 1:25
EXPARTAN-6Tの基板データから部品を削除し、ほとんど何も乗っていないPCI Expressの基板形状を作る。
◆AM 2:31
過去にArtix-7で作ったJESD204B受信基板から、XC7A50T-CSG325のシンボルと、電源やコンフィグまわりの周辺回路をコピーしてきてざっと配置してみる。
◆AM 4:41
電源、PCI Expressの配線、少しのパスコンを配置。
4層基板で配線できるのではないかという期待。
◆AM5:23
万能基板エリアを設けてみた。意外と狭いことがわかる。
◆AM5:35
コストをかけずに付加価値を高めたいと思い、Arduinoのシールドが乗らないかどうか検討する。
Arduinoが大きいのか、LowProfileなPCI Expressが狭いのか。
◆AM5:57
FPGAを少しずらすことで、Arduinoの基板も乗ることがわかった。
PMODを3つ、40ピンのフラットケーブルを1つ乗せられる。
PMODが使えればいろんな拡張が楽しめるだろう。
今日はここまで。続きの設計は連休中に。
この基板はもちろん国内の業者に発注するし、実装も国内です。
100枚くらい売れないと赤字なんでしょうけど、在庫や仕掛品という資産として計上されるので（廃棄したりしなければ）会計上は赤字にはならないでしょう。
売れるかどうかはわからないけど、できるところから経済を回していきたいと思います。
2020.04.22
Artix-7のPCI Express基板を作りたい
Artix-7のPCI Express基板を作りたいな~と思っています。
コンセプトは下の図のような感じの、PCIe-GPIOです。
手軽なI/OだとUSBがいいのですが、USBだと1msのフレームや0.125msのサブフレームに同期してトランザクションを発行するので、読んだり書いたりするのを頻繁に行う用途ではどうしても動きが遅くなってしまいます。そのため、USB-JTAGをJTAG-ICEに使うと遅くなります。
その点、PCI Expressはレイテンシが低く、パソコンのCPUがリクエストをしてからμ秒のオーダーでトランザクションが完了します。そこにPCI Expressの活路があるのではないかと思う次第です。
ただ、PCI Expressの評価ボードは高いし、メザニンコネクタで拡張となると、手にしたユーザが基板を作らなければならなくなってしまうので、万能基板やフラットケーブルで拡張できる手軽なPCI Express基板があれば需要があるのではないかと思った次第です。
私が何か基板を作ろうとすると、あれもこれも乗せて高くなっていくので、とにかく安く、最低限の機能だけに絞っていきたいと思います。
本当はDDR3メモリも載せたいし、余ったGTPでSATAとか乗せたいし、GTPの実験ができるようにしたい・・、と夢は膨らんでいくのですが、ぐっとこらえて最低限のに絞っていきます。
中に入れる回路もシンプルそのもので、XILINXのPCI Expressコアと、クロックバッファと、AXI LiteなGPIOのみ。
これで、PCI Express GPIOが作れるはずです。
XDMAを実装するには最低限、XC7A35が必要なようです。XC7A15だと10600/10400くらいで溢れます。
なお、Artix-7でGTPを持っている品種は下記の5つがあるのですが、
どうやらXC7A12とXC7A25は他のと比べて何かが違う(MMCMが3個しかない？)らしく、XC7A25にはXDMAを実装できませんでした。7A35のデザインからPartNumber変更すると、このような画面になってIPがロックされてしまします。やはり、どうしても無理なのでしょう。
そして、XC7Aの325ピンのものをDigikeyで調べてみると、価格は5300円から9400円。
スピードグレード-1と-2でどのくらい差があるかを調べてみると、-1であってもGTPは3.75Gbpsが出せることがわかります。
PCI Express Gen2は5Gbpsなので-1では足りないことになります。Gen2をするなら-2が必要ですが、高速なDMA転送をする相手のDRAMが乗っていないので、Gen1のXC7A35-1で十分かなということになります。
結論としては、XC7A35T-1の安い版と、XC7A50T-2の高級版を作ろうかなという感じです。
FPGA自体は5400円くらいで手に入るのですが、その他の部品で約3000円くらい。
目標の売価は2万円以下なのですが基板と実装で30万円くらいかかります。その費用をどう分散させて、価格を2万円以下に抑えようかと悩ましいところです。100台くらい売らないと利益が出ない計算になります。
2020.04.21
Kintex-7のIBERT検査のやり方
Cosmo-K0というKintex-7ボードを4台作ったので、ギガビットトランシーバの動作テストをしたいと思い、IBERT試験を行うことにしました。
この試験はギガビットトランシーバから信号を出して受けてそのエラーレートを計るもなのですが、受信や送信のタイミングや電圧を少しずつずらして、どの程度アイが広がっているかを見ることができます。
もちろん、そんな複雑な回路を自分で作るわけではなく、XILINXのIPを使います。
IBERT試験の回路は以前アルバイトさんが作ってくれたのがあったのですが、どのように作ったのかがよくわからないので、自分でも作ってみることにしました。
まず、普通にVivadoでプロジェクトを作ります。
そうしたら、IP Catalogをクリックし、Searchにibertと入力し、出てきた「IBERT 7 Series GTX」をクリックします。
IBERT 7 Series GTXのIPコアは、Block Designから使えないので IP Catalogから直接呼び出す必要があります。
ダイアログが開くので、Line Rateを10Gbpsにし、DataWidthを40bitに変更します。
RefClkは基板の設計によって異なるはずですが、Cosmo-K0の場合は150MHzのクロックと125MHzのクロックがGTXREFCLKにつながっています。ラインレートとクロック速度は綺麗な比になっていなければならないので125MHzのほうを選びます。
Protocol Selectionのタブでは、Protocol SelectedをCustom 1/10Gbpsにし、RefclkSelectionをMGTREFCLK1 116にします。
これでGTX Bank116のREFCLK1が使われます。
次のClock Settingsのタブでは、システムクロックをどうするかを選択するのですが、外部ピンのを使うか、GTXの中で使っているクロックを流用するかを決めます。当然ながらGTXのクロックを使いますのでQUAL116 1を選びます。
OKを押せば、コアが生成されます。
このダイアログにはRXOUTCLKをProbeするかというチェックボックスがありますが、これをONにしても受信クロックを内部の回路で使えるわけではなく、どこかのI/Oピンに割り当てられてしまいます。
IBERTコアは、入出力ピンのすべてが外部ピンを想定して作られています。ユーザ回路に埋め込むのではなく、これ単体でラッパして動かせという意図を感じます。
出来上がったコアをどのようにユーザ回路にインプリメントすればよいかというと、サンプル回路はコアを右クリックして出てくるプルダウンで「Open IP Example Design」を実行すると生成されます。
新しいVivadoのプロジェクトが、コアをインプリメントしたVHDLファイル（あるいはVerilogファイル）と共に、生成されます。
プロジェクト作成→コア作成→サンプルプロジェクト作成という手順で、トップのラッパを作るわけです。
XDCファイルも一緒に生成されますが、
set_property RXBUF_ADDR_MODE "FAST" [get_cells u_ibert_core/inst/QUAD[0].u_q/CH[*].u_ch/u_gtxe2_channel]
set_property RXBUF_EIDLE_HI_CNT 4'b1000 [get_cells u_ibert_core/inst/QUAD[0].u_q/CH[*].u_ch/u_gtxe2_channel]
set_property RXBUF_EIDLE_LO_CNT 4'b0000 [get_cells u_ibert_core/inst/QUAD[0].u_q/CH[*].u_ch/u_gtxe2_channel]
set_property RXBUF_EN "TRUE" [get_cells u_ibert_core/inst/QUAD[0].u_q/CH[*].u_ch/u_gtxe2_channel]
set_property RX_BUFFER_CFG 6'b000000 [get_cells u_ibert_core/inst/QUAD[0].u_q/CH[*].u_ch/u_gtxe2_channel]
set_property RXBUF_RESET_ON_CB_CHANGE "TRUE" [get_cells u_ibert_core/inst/QUAD[0].u_q/CH[*].u_ch/u_gtxe2_channel]
set_property RXBUF_RESET_ON_COMMAALIGN "FALSE" [get_cells u_ibert_core/inst/QUAD[0].u_q/CH[*].u_ch/u_gtxe2_channel]
set_property RXBUF_RESET_ON_EIDLE "FALSE" [get_cells u_ibert_core/inst/QUAD[0].u_q/CH[*].u_ch/u_gtxe2_channel]
set_property RXBUF_RESET_ON_RATE_CHANGE "TRUE" [get_cells u_ibert_core/inst/QUAD[0].u_q/CH[*].u_ch/u_gtxe2_channel]
set_property RXBUFRESET_TIME 5'b00001 [get_cells u_ibert_core/inst/QUAD[0].u_q/CH[*].u_ch/u_gtxe2_channel]
set_property RXBUF_THRESH_OVFLW 61 [get_cells u_ibert_core/inst/QUAD[0].u_q/CH[*].u_ch/u_gtxe2_channel]
set_property RXBUF_THRESH_OVRD "FALSE" [get_cells u_ibert_core/inst/QUAD[0].u_q/CH[*].u_ch/u_gtxe2_channel]
set_property RXBUF_THRESH_UNDFLW 4 [get_cells u_ibert_core/inst/QUAD[0].u_q/CH[*].u_ch/u_gtxe2_channel]
set_property RXDLY_CFG 16'h001F [get_cells u_ibert_core/inst/QUAD[0].u_q/CH[*].u_ch/u_gtxe2_channel]
set_property RXDLY_LCFG 9'h030 [get_cells u_ibert_core/inst/QUAD[0].u_q/CH[*].u_ch/u_gtxe2_channel]
set_property RXDLY_TAP_CFG 16'h0000 [get_cells u_ibert_core/inst/QUAD[0].u_q/CH[*].u_ch/u_gtxe2_channel]
のような謎パラメータが延々と並んでいるので、手作業で作るのは不可能でしょう。Vivadoに模範解答を作ってもらうしかありません。
このトップのHDLファイルとXDCファイルを自分のプロジェクトにコピーしてくれば、プロジェクトは完成です。
同軸ケーブルやSATAケーブルの場合は信号が出っぱなしになるのでいいのですが、光ファイバを使う場合にはSFPというモジュールのDISABLE信号を無効にしなければならないので、TOPのHDLファイルに
sfp_dis : out std_logic_vector(2 downto 0);
・・・
sfp_dis <= "000";
という感じで定数を出すだけの回路を追加することはできると思います。
IBERTコアは、クロックやリセット、エラー状態などを一切出さない孤高のコアなので、ユーザができることはほとんどありません。
このようにしてコアができたら、Generate Bitstreamをして書き込むと、IBERTのコアが埋め込まれたことをVivadoは感知します。
HW ManagerにIBERTというのが出てくるので、右クリックしてAuto Detect Linkを行って、Create Scanを開始すると、1次元のバスタブカーブや、
2Dスキャンといって時間と電圧を振るスキャンを行ってくれます。
このようにして、GTXからSFTを通じて光ファイバまで含めたトータルのギガビットリンクの性能（耐久性）が簡単に測れるというわけです。
やり方がわかってしまえば、すごく簡単です。
2020.04.14
MAX1000とCYC1000の使い方をQiitaに投稿しました
Intel(旧ALTERA)のFPGAを搭載した小型のFPGAボードでMAX1000と、CYC1000というものがあります。
これらのFPGAボードの使い方をQiitaに投稿しました。
https://qiita.com/nahitafu/items/d7dfb8a7439eafdd4cc3
オンボードのUSB-JTAGはUSB Blaster互換ではありませんが、Quartusから認識することができました。
新しくWindows10をインストールしたまっさらなPCでも、問題なく認識できて、Quartusから書き込みができました。
間に入っているArrow USB Programmer2というプログラムがALTERA JTAG Serverを介してMPSSEをQuartusから使えるようにしてます。
安いし、Quartusから使えるし、世界中で大量に使われているボードなので実績もあります。
ALTEAR(INTEL)のFPGAを初めてみたい方に最適なボードだと思います。
https://qiita.com/nahitafu/items/d7dfb8a7439eafdd4cc3
2020.04.13
MAX1000(TEI0001-03-08-C8)を入荷しました
TrenzElectronic社のFPGAモジュール「TEI0001-03-08-C8」を入荷しました。
基板の名前はMAX1000ですが、乗っているのはIntelのMAX10とSDRAMです。
DIP形状でUSB給電もでき、とても安いのが特徴です。
このボードのUSBにはFT2232Hがつながっていて、MPSSEを通じたUSB-JTAGが実現されています。
とにかく安く、初心者向けの低価格ボードだと言い切れる値段だと思います。
中には「安いのはいいんだけどMAXにしろCYCにしろ、載ってるのがUSB-Blaster互換ではない」のでQuartusから使えないと誤解されている方もいらっしゃるようです。
オンボードのUSB-JTAGは確かにUSB Blaster互換ではないのですが、Arrow USB Programmer2というライブラリが間に入って、Quartusから操作できるようになっているようです。
Arrow USB Programmer2がどういう動作をするのか、手持ちの類似品の試してみました。
ちょっと脱線しますが、中身はMPSSEなのでMITOUJTAGからも認識することができました。つまり、MPSSEの標準的なピン配置のようです。
自動認識させてみると、Cyclong3もCyclone4もCyclone10も同じIDCODEなので、どれか選べと出てきます。
これではIDCODEの役割を果たしていませんね。
IntelはJTAGを正しく作れ！！
気を取り直してQuartusからつないでみると、
Quartusでもデバイスを選ばせます。JTAGのIDCODEが被っているためです。
YとZの違いはわかりませんが、とにかく認識できました。
このとおり、問題なく使うことができます。
Arrow USB Programmer2のインストールマニュアルはこれですが、特にレジストリの書き換えや、サービスの再起動は必要ありませんでした。
Arrowのプログラムをインストールしておけば、特別なことをやっていると気が付くこともなくQuartusから普通に使えてしまいます。
すばらしい。
MAX1000とCYC1000は、下記のページで購入できます。
- MAX1000(TEI0001)はこちら ¥3,680
- CYC1000(TEI0003-02)はこちら ¥4,900
2020.04.12
SSHポートフォワーディングを使ったテレワークによるFPGA開発のセキュリティ改善
Qiitaに投稿した「SSHポートフォワーディングを使ったテレワークによるFPGA開発」の記事に、セキュリティの指摘を受けたので、改善方法を示しました。
https://qiita.com/nahitafu/items/f308d62bfb81d7f3f663
リモートサーバの自宅側も会社側もSSHにすれば、証明書を持っていない人（あるいはパスワード認証で）外からは入れなくなるので、安全なトンネルが作れるというわけです。
速度的にもほとんど低下は見られませんでした。
遠隔操作でILAも使えるので、開発効率アップ間違いなし！？
詳しくはQiitaの記事へ。
https://qiita.com/nahitafu/items/f308d62bfb81d7f3f663
2020.04.11
SSHポートフォワーディングを使ったテレワークによるFPGA開発
テレワークでFPGAを開発したいけど、
- 会社がVPNに対応してくれない
- 外からの接続を受け付けない
- NATが超えられない
- 情報管理部門が許してくれない
- 回線が細くてリモートデスクトップするに耐えられない
- 会社のVPNがすぐ切れる
こんな悩みはありませんか？
状況としては、自宅のPCでFPGAのビルドをするけど、機械は会社や学校にあるという場合を想定します。
い。
Vivadoを使ってFPGAの書き込みやデバッグだけはしたい！ というのであれば、SSHポートフォワーディングをすると何とかなります。
SSHポートフォワーディングを使うにはグローバルIPを持ったSSHサーバが必要ですが、自宅も会社(学校)もTCPのクライアント側になるので、NATを越えられるし、ファイアーウォールも越えられるからです。つまり、インターネット上にあるSSHが動くサーバを介して、任意の2点間でトンネルを作ることができます。
Vivadoのリモート対応
VivadoのJTAGまわりのツールはもともとネットワークに対応していて、概ね次の図のようになっています。
実はローカルPCでVivadoを使っていても、内部ではhw_server というプログラムが動いて、TCPの3121で待ち受けています。そして、VivadoやXILINX SDKがFPGAに書き込むときにTCP 3121を通じていろいろなコマンドを与えています。
したがって、hw_server.exeを起動しておけばVivadoは元からリモート接続に対応しているので、遠隔操作ができるのです。
hw_server.exeは、Vivadoをインストールしたフォルダのbinの中にある hw_server.batをダブルクリックすることで起動できます。
起動するとDOSプロンプトの以下のような画面が開きます。これで待ち受けはOKです。
サーバを借りよう！
やるべきことは、グローバルIPアドレスを持ったサーバを借りることです。
AmazonのAWSで、一番安いサーバで十分でしょう。私はUbuntu Linuxの動く最小構成のサーバを借りました。そして、セキュリティグループというのを開き、通したいポートのインバウンドルールを追加します。ログインしてからufwで設定するのではなく、ファイアーウォールの設定はWebのこの画面から行えばよいようです。
VivadoのJTAG通信はTCP:3121ですが、同じ番号だと困ることになるので、3121に10000を足して13121番を開けることにしました。sshd_configの設定は特にありません。サーバ上で作業することもありません。
Amazonで借りられるサーバにログインするにはキーペアという証明書が必要で、サーバを作ったときに配布されます。それがないと絶対にログインできないので、かなり安全です。
会社と家庭、それぞれの準備
JTAGサーバ(会社)側の準備
会社の中でhw_serverを起動したPCでTeraTermを起動します。そして設定→SSH転送の設定を開きます。
SSHポート転送の設定は、リモートサーバのポートを13121にして、ポートを3121にします。
この設定をして会社のPCからSSHサーバに22番で普通に接続すると、リモートサーバの13121へのアクセスが会社サーバの3121に転送されます。
家庭側の作業
Vivadoを起動し、Open Hardware ManagerでConnected toにRemote serverを選び、リモートサーバのIPアドレスを入れます。また、TCPのポート番号は先ほどの13121とします。
これで無事にリモートサーバ経由で接続できました。
接続方法のまとめ
- リモートのSSHサーバを立てておく。
- リモートサーバではTCP:13121(任意)を開けておく
- 会社PCでhw_server.batを起動しておく
- 会社PCからリモートサーバにSSH(TCP:22)でつなぐ
- 自宅PCでVivadoを起動し、Remoteの13121につなぐ
- リモートサーバと会社PCのTeraTermの間でトンネルが作られ、会社PCのTCP:3121に転送される
- 自宅PCから会社PCのhw_serverに接続できる
というわけです。
繰り返しになりますが、会社からリモートサーバへただのSSHのセッションを張るだけなので、ファイアーウォールもNATも越えられるというわけなのです。
性能はどうか
ZYNQ UltraScale+のXCZU2CGに書き込む時間を比べてみました。
- ローカルPCでダイレクト接続・・・2秒
- 会社と自宅でVPNを張った(L2TP)場合・・3~6秒
- TCPポートフォワーディングの場合・・5秒
リモート接続してもそんなに遅くはならないという印象です。AWSがいいバックボーンを持っていると思われ、かなり安定してトンネルできます。
VIOもロジアナも使えるので、テレワークでFPGAを開発するのが少しだけ楽になるかと思います。
2020.04.08
TE0802のサンプルプロジェクトをビルドする方法
TrenzElectronic社の新しい評価ボード「TE0802」のサンプルプロジェクトをビルドする方法を書きます。
まず、リファレンスデザインをダウンロードします。
ダウンロードして解凍すると、下の図のようなフォルダが出てきます。
Trenz社のプロジェクトは、通常のVivadoの.xprのプロジェクトは入っていません。XPRを生成するためのTCLと、最小限のテキストファイルで構成されています。
Vivadoのプロジェクトを生成するには、_create_win_setup.cmdを実行します。
次の図のような画面が出てくるので c を押してENTERを押します。
次の図の画面が出るので max と打ってENTERを押します。
ファイルがいろいろと生成されて、このバッチファイルは終了です。
以下のようなファイルが出来上がります。
そうしたら、この中にある、design_basic_settings.cmdを編集します。
編集する箇所は、40~42行目の
@set XILDIR=C:/Xilinx
@REM -Attention: These scripts support only the predefined Vivado Version.
@set VIVADO_VERSION=2018.3
です。
40行目ではVivadoをインストールしたフォルダの一つ上のフォルダを、42行目ではVivadoのバージョンを指定します。
このプロジェクトは基本的にはVivado 2018.3用に生成されています。
例えば、VivadoをD:\Xilinx\Vivado\2018.3にインストールしているのであれば、
@set XILDIR=D:/Xilinx
@REM -Attention: These scripts support only the predefined Vivado Version.
@set VIVADO_VERSION=2018.3
とします。
そうしたら、バッチファイルの vivado_create_project_guimode.cmd を実行します。DOSプロンプトやVivadoのコンソールから実行するのではなく、エクスプローラでダブルクリックするのが正解です。
DOSプロンプトが開いて・・・
プロジェクトが生成されます。
これでGenerate BitStreamを実行すればビルドが行われます。
もし、Vivado 2019.2で使うのであれば、
@set XILDIR=D:/Xilinx
@REM -Attention: These scripts support only the predefined Vivado Version.
@set VIVADO_VERSION=2019.2
とした後、block_design\zusys_bd.tclを編集します。
編集する箇所は3か所あって、
25行目
set scripts_vivado_version 2018.3
を
set scripts_vivado_version 2019.2
に、
140行目
xilinx.com:ip:zynq_ultra_ps_e:3.2\
を
xilinx.com:ip:zynq_ultra_ps_e:3.3\
に
522行目
set zynq_ultra_ps_e_0 [ create_bd_cell -type ip -vlnv xilinx.com:ip:zynq_ultra_ps_e:3.2 zynq_ultra_ps_e_0 ]
を
set zynq_ultra_ps_e_0 [ create_bd_cell -type ip -vlnv xilinx.com:ip:zynq_ultra_ps_e:3.3 zynq_ultra_ps_e_0 ]
に、です。
これでVivado 2019.2でもプロジェクトを開くことができるようになり、ビルドも成功しました。
なお、Trenz社のプロジェクトはバッチファイルからVivadoを操作して何でもできるようになっています。
design_run_project_batchmode.cmd を実行すれば、コマンドラインベースのVivadoでプロジェクトのビルドが行われます。Windowsサーバ上にログインして操作できれば、GUIの画面は見ずに論理合成結果のbitファイルだけを得ることができます。
ありがたいことにLinux版も用意されているので、Linux版のVivadoを入れた高速なサーバを会社とかAWSに置いておいて、SSHでログインして、design_run_project_batchmode を実行するという使い方もできるのです。
2020.04.06
FT2232Hの出力にバッファを使う場合のMPSSE JTAG
MPSSEをMITOUJTAGから扱うためのプログラムを書いていて、USB-JTAGアダプタにTrenzElectronic社のTE0790を使った場合、ターゲットFPGAによっては不安定になることがありました。
現象としては、
「（TE0790を使う）AND（Digilent JTAGとしてではなくMPSSEとして扱う）AND（Spartan-7がターゲット）AND（クロック速度が最大）AND（MPSSEのコマンド3Bを使用）」
という条件でNGになります。
ようやくこの原因がわかりました。
TE0790は、FT2232Hの後ろにバッファとしてCPLDを置いていますが、このCPLDの遅延が5nsくらいあるので、TCKが出てターゲットデバイスからTDOが戻ってくるまでに、約10nsほどの遅延が生じてしまいます。
TE0790を使う場合だけではなく、FT2232Hの出力をレベル変換したい場合などで同じような問題に当たるはずです。
実際にオシロで見てみました。まず、Spartan-7 FPGAに与えるTCKとSpartan-7から出てきたTDOの関係です。
下の黄色いTCKが下がってから、5nsくらいでTDOが変化しています。
CPLDの前後でTDOを見てみると、CPLDの通過で約5nsずれているのがわかります。
TDOがFT2232Hに到達したときには5ns遅れますが、FPGAのTCKよりもFT2232HのTCKのほうが5ns早く出ているので、トータルで10ns遅れたように見えます。
このため、FT2232HがTCKの立ち上がりでTDOをサンプリングしては間に合わないことになります。
☀
アプリケーションノートAN108では、MPSSEでは、コマンド3Bというのを使ってTDIを出力することになっています。
コマンド3Bを使うと、TCKの立下りでTDIが変化し、TCKの立ち上がりでTDOをサンプリングします。
CPLDなどのバッファを通していると、前述のとおりTCKの立ち上がりでTDOをサンプリングするタイミングが間に合わないので、コマンド3Eを使うとうまくいくようになりましたが、これは正しい解決ではありません。
まず、コマンド3Bで0x55というデータを出力した場合。TCKの立下りでTDIが変化しています。これは正常な動作です。
次はコマンド3Eにした場合。TCKの立ち上がりでTDIが変化するので、これを受け取るターゲットデバイス(FPGA)は、2bit目のセットアップタイムが不足することになるでしょう。（一応、動いてはいますが）
つまり、コマンド3BだとTDI(FPGA)のセットアップタイムは足りるが、TDO(FT2232H)のセットアップタイムが不足する。
コマンド3EだとTDO(FT2232H)のセットアップタイムは足りるが、TDI(FPGA)のセットアップタイムが不足するという事態になります。
☀
そもそもコマンド3Bとか3Eというのはどういう意味かというと、
Bit 0 : '1'ならTDIの出力をTCKの立下りで行う
Bit 1 : '1'ならビットモード、'0'ならバイトモード
Bit 2 : '1'ならTDOのリードをTCKの立下りで行う
Bit 3 : '1'ならLSB firstにする
Bit 4 : TDIから出力する
Bit 5 : TDOから読み出し
Bit 6 : TMSを出力する
Bit 7 : 0
という意味です。つまり3BはTDOは立ち上がり＆TDIは立下りというコマンドで、3EはTDOは立ち下がり＆TDIは立ち上がりというコマンドなわけです。
それならば、3Fというコマンドにしてみたらどうなるでしょうか？コマンド3FはアプリケーションノートAN108には載っていませんが、なんと、動いてしまいました。TDOは立下りでサンプリングし、TDIも立下りでサンプリングするという理想的なモードでした。
このように裏技的なコマンドを使うことでFT2232H+バッファな構成でもJTAGが使えるようになりました。
これが正しい方法なのかどうかはわかりませんが・・
あと、どうしてDigilentのAdeptはTE0790で正常に動作しているのか。裏コマンド3Fを使っているのかどうか。それも謎です。
まとめると、「FT2232HのMPSSEで、TCKを最高速度の30MHzで動かす場合、TCKとTDOにバッファが入っている場合は「TDIは立ち上がりで変化、TDOは立下りでサンプリング」という標準コマンドだとFT2232HのTDOのセットアップタイムが不足」していまいます。
解決策としては、
- 裏コマンド3Fを使う
- TCK=15MHzで動かす
のどちらかを使うこととなります。
最近のコメント