ZYNQのLinux上でSDSoCアプリを実行する方法をわかりやすく解説したチュートリアルにまとめました。
http://www.trenz.jp/tutorial/zbsdsoc-linux.html
Zynqberryが「FPGAで任意の関数をアクセラレートして高速に実行できるRaspberry Pi互換機」に近づきました。
下の図は、xの逆数を求めるFPGAのハードウェアをSDSoCで実装し、Linuxのアプリから動かしたものです。
機械学習や人工知能などFPGAならではのアプリを、ぜひともZynqberryで試してみてください。
ZYNQのLinux上でSDSoCアプリを動かせる条件がわかってきました。
まとめると、
xlnk {
compatible = "xlnx,xlnk-1.0";
};
を書いておきます。そして、
insmod /usr/bin/xlnk-eng.ko insmod /usr/bin/xlnk-dma.ko insmod /usr/bin/xlnk-apf.ko
でドライバをインストールします。この3つのドライバはこの順序でインストールします。
SDSoCのプロジェクトをビルドすると、sd_cardというフォルダに_sds/_p0_.binとelfが出来上がります。
この_sds/_p0_.binをsambaのファイル共有でZYNQシステム上にコピーして、
cat _sds/_p0_.bin > /dev/xdevcfg
でFPGAのPLに書き込んで、elfを実行すれば、SDSoCアプリが起動します。
パーシャル・リコンフィギュレーションは使用しませんが、XC7Z010では上のcatコマンドは一瞬で終了するので、パーシャルでなくても時間的には気になりません。
ただ、PLの全レジスタがクリアされてしまうので、HDMI出力機能とかに弊害は出てきます。
SDSoCのアプリが起動するとxlnk_engドライバが動いてハードウェア関数が実装されているのを探しますが、SDSoCのハードウェアが全く入っていないFPGAだとハングするようです。
また、ハードウェア関数が変わるとbitファイルも変わりますが、異なるデザイン用に作ったbitファイルを書き込んでしまっても、運がよければプログラムは実行できると思います。正しい結果にはならないでしょうが。
ついに、できました！！
ZynqberryでSDSoCのアプリが動くようになりました。
Zynqberryというのは、Raspberry Pi形状のFPGAボードでZYNQが乗っています。
ここにあるスタータキットを使うと、Ubuntuが動いて、apt-getで便利なコマンドがいろいろインストールできるようになってRasPiみたいになります。
http://www.trenz.jp/product/TE0726-STARTER-KIT/
私は、FPGAでアクセラレートできるRasPiを作りたいので、Zynqberryのアプリ(HW/SW)をSDSoCで開発する方法を確立しようとしています。
プロジェクトやらファイルをいじっていたら、SD_CARDフォルダに起動用のboot.binが作られるようになりました。
いずれはオリジナル・プラットフォームでSDSoCを使う手順を確立して手順書を作りたいと思いますが、まずはできあがったBoot.binを使って実際に動かしてみます。
動かしている回路は、XILINXのサンプルプログラムに入っている並列加算器のデモらしく、1024個の加算をするという、いかにもなものでした。高位合成をしたらこのような回路が出来上がっていました。
まずはハードウェアで実行したときのCPUのクロック数(?)を表示しています。
次はソフトウェアで実行したときのCPUのクロック数(?)です。
確かに違いが出ていますね。
Estimate PerformanceをONにすると、プログラム全体と、ハードウェア化した関数の詳細なプロファイルを取ってくれるそうです。
が、結果を見てもよくわかりません。
あまり高速になっていないような気もします。
データはBRAMに入れているようなので、1024個の加算を同時にやっているわけではないのでしょう。
SDSoCはデータ転送に相当なクロックサイクルを使うし、CPUがそもそも666MHzで動いているので、PLを100MHzかそこらで動かしても加速はたかが知れたものです。
SDSoCを試すなら、並列加算なんていうぬるいものではなく、もっとパワーが必要な演算回路を入れてやらねば真価を発揮しないということだと思います。
重い演算、どんとこい！
秋葉原にて、第4回目となるZynqberryセミナーを開催しました。
今回の参加者は6名でした。遠方から来ていただいた方もいらっしゃいました。
4回目にもなるとだいぶん慣れてきているはずなのですが、一昨日くらいに舌を噛んでしまった影響で、口内炎が痛くて活舌が悪くなっていたのが心残りです。
いままでで一番、丁寧に深く細かく説明できたセミナーではなかったかと思います。デバイスツリーのあたりで時間がなくなってしまったので、後半のデバイスツリーや、UIOの説明は駆け足で説明しました。セミナー資料のWebページはそのまま残してあるので、ご参加された方はどうぞダウンロードしてゆっくりお試しください。
前回(5月)のセミナーでは、U-BootやLinuxカーネルのバージョンを指定していなかったので、GithubにあるU-bootが更新されていて会場でビルドに失敗するという大混乱を引き起こしましたが、今回はU-Bootは最新版でビルドできるようセミナー資料を更新したので、そういうことはなかったはずなのですが、実際には・・
Linuxに関してはバージョンを指定したため、そういうことはなかったと思いたいです。
SDSoCのチュートリアルや使用例のほとんどは、DDRメモリの中のデータとハードウェアアクセラレータの間でやりとりをしています。人工知能とか機械学習とか、画像処理とか、そういうメモリに籠ったアプリではそれがいいのでしょう。
そういう例では、メモリ上のデータをやりとりするだけなので、I/Oポートの設定はさほど気にならないのでしょう。SDSoCでI/Oピンを設定する方法が書かれたものは皆無です。XILINXのフォーラムにちょっとだけ質問が書かれていましたが、具体的な回答は書かれていません。
みんな、ZYBOとか使ってやっていて、自分でボード作る人はいないんでしょうか？？？
私がやりたいことは、カメラや高速ADCですから、SDSoC8でピン配置を設定する方法を本気で探さなければなりません。
そこで、ZynqberryにHDMI出力やPWMなど、リッチな環境を入れて、さらにピン配置も指定した状態のSDSoC用のプラットフォームを作ってみました。
まず、Trenz社提供のサンプル回路をベースにSDSoCプラットフォームを作りました。
しかし、このサンプル回路が曲者で、Vivado2017.3以降では論理合成が通らないのです。
苦労してデバッグして、ようやくその原因もわかって、対策もしましたが、Vivado2018.1では最終的にタイミングエラーが出てしまいます。
VivadoのプロジェクトをSDSoCに持っていって、いざ合成しようとしてみると、AXI RegsなどXILINXの標準IPのdriverがないと言われたり、ハードウェアのカスタムIPがないといわれるなどしましたが、SDSoCのプロジェクトの一時ディレクトリに無理やりコピーして何とか合成させました。
ただ、Vivadoでも出ていたタイミングエラーが原因となって、最終的にSDSoCもエラーで終わってしまいました。
Raspberry Pi型のZYNQボード「Zynqberry」(ジンクベリー)をSDSoCに対応させる方策を考えています。
とりあえず、SDSoCのチュートリアルUG1236をひととおり理解したつもりなので、Zynqberryのプラットフォームの元を作ります。
ZynqBerryではFCLK0が160MHzなので、clkwizも160MHzを入力して、100MHz,125MHz,250MHzなどを出力するようにしておきます。
このデザインからDSAを作り、SDSoCで読み込むと・・
見事にプラットフォームとして認識してくれました。
SDSoCで行列計算か何かの適当なサンプルデザインを組み込んで合成してみると、こんな回路が出来上がりました。
しかし、残念なことにZynqberryには入りきらなかったようで、SDSoCの最後の最後でエラーが出てしまいました。
レポートによると、XC7Z010にはDSP80個しかないのに、260個使うようなデザインが出来てしまったようです。
大きなFPGAの需要がある理由がわかってきましたぞ。
SDSoCを使った合成方法がわかったので、次は自分でプラットフォームを作る方法を調べました。
SDSoCのプラットフォームはxpfmという名前のファイルですが、これはVivadoで作るdsaというファイルと、SDKで作るboot.binやfsbl.elfなどから生成します。
詳しいやりかたはUG1236に載っているので、このチュートリアルをやりました。
UG1236によると、まず、普通にVivadoのプロジェクトを作り、processing_system7や、proc_sys_reset、clk_wizなどを置いて普通にZYNQを使った空(?)のプロジェクトを作ります。
そして、VivadoのTCLコンソールに以下のようなコマンドを入力して、processing_system7などにPFMというpropertyをセットします。
set_property PFM_NAME "xilinx.com:zynq7_board:zynq7_board:1.0"\
[get_files [get_property FILE_NAME [get_bd_designs]]]
set_property PFM.CLOCK { \
clk_out1 {id "2" is_default "true" proc_sys_reset
"proc_sys_reset_0" } \
clk_out2 {id "1" is_default "false" proc_sys_reset
"proc_sys_reset_1" } \
clk_out3 {id "0" is_default "false" proc_sys_reset
"proc_sys_reset_2" } \
clk_out4 {id "3" is_default "false" proc_sys_reset
"proc_sys_reset_3" } \
} [get_bd_cells /clk_wiz_0]
set_property PFM.AXI_PORT { \
M_AXI_GP0 {memport "M_AXI_GP"} \
M_AXI_GP1 {memport "M_AXI_GP"} \
S_AXI_ACP {memport "S_AXI_ACP" sptag "ACP" memory
"processing_system7_0 ACP_DDR_LOWOCM"} \
S_AXI_HP0 {memport "S_AXI_HP" sptag "HP0" memory
"processing_system7_0 HP0_DDR_LOWOCM"} \
S_AXI_HP1 {memport "S_AXI_HP" sptag "HP1" memory
"processing_system7_0 HP1_DDR_LOWOCM"} \
S_AXI_HP2 {memport "S_AXI_HP" sptag "HP2" memory
"processing_system7_0 HP2_DDR_LOWOCM"} \
S_AXI_HP3 {memport "S_AXI_HP" sptag "HP3" memory
"processing_system7_0 HP3_DDR_LOWOCM"} \
} [get_bd_cells /processing_system7_0]
set intVar []
for {set i 0} {$i < 16} {incr i} {
lappend intVar In$i {}
}
set_property PFM.IRQ $intVar [get_bd_cells /xlconcat_0]
この作業を行うと、PFMというプロパティが追加されるのがわかります。
VivadoをTCLで操作する方法は正直よくわからないので、勉強しないといけないですね・・
そうしたら、Generate Output Productsを行うのですが、
このときにGlobalを選ぶようです。実はこのチュートリアルは2回やっていて、1回目はうまくいかなかったのですが、per IPを選んでいたからかもしれません。Globalを選ぶのが重要なのかもしれません。
そして、Create HDL Wrapperをしたら、Export Hardwareをして、その後で以下のコマンドをTCLコンソールに打ってDSAを出力するとのことです。
write_dsa –force <path_to_project>/zynq7_board.dsa
ただし、この<path_to_project>はデフォルトでC:/Users/ユーザ名/AppData/Roaming/Xilinx/Vivado/あたりに設定されているので、少々使い勝手が悪いです。<path_to_project>の変更方法もよくわかりません。
そこで、以下のように直接ディレクトリを指定して出力したほうがいいと思います。
write_dsa –force d:/sdsoc/UG1236/zynq7_board.dsa
これでDSAファイルが出来上がります。DSAというのはZIPファイルで中身はこんな感じでした。
prjというディレクトリには、Vivadoのプロジェクトの部品がそのまま入っている感じでした。
ipcacheのほうは、ipcache\ip\2018.1ディレクトリが作られているだけで、中身は空のようでした。
こうしてdsaファイルをエクスポートしたら、XSDKでfsbl.elfとboot.binとbifファイルを生成します。それから空のプロジェクトを作って、ヒープを768MBにしたリンカスクリプトを作ります。
standalone動作で最大のメモリを使うという意図のようです。
BOOT.binと、fsbl.elf、lscript.ld、standalone.bifの4つのファイルをbootというディレクトリに入れます。
bootディレクトリの中身はこんな感じになっていますです。
SDxを起動して、[New]->[SDx Project]を行い、Platform projectを選択します。
先ほど生成したdsaファイルを選択し、Finishを押します。
Platform projectが生成されます。
①Define System Configurationを、②Add Processor Group/Domain、③Generate Platform、④Add Custom Repositoriesを行えばSDxの新規プロジェクト作成の際にこのプラットフォームが選択できるようになります。
ここまで長かった・・
さて、UG1236のチュートリアルによれば、SDxのテンプレートから選ぶとのことなのですが、テンプレートに何もありません。
SDｘ Examplesを押して、downloadボタンを押しても接続でエラーになってしまいます。
こういうときは、https://github.com/Xilinx/SDSoC_Examplesからダウンロードして、その中にあるcppフォルダのgetting_startedフォルダをC:\Users\<ユーザ名>\.Xilinx\SDx\2018.1フォルダにコピーしてあげると、サンプルが見えるようになります。
これでうまくいくかと思ったのですが、まだダメでした。
テンプレートにあるプロジェクトをコンパイルしようとすると、
#include "sds_utils.h"
というのが見つからずにエラーになります。
解決方法としては、Githubからダウンロードしてきた、SDSoC_Examples-master\libs\sds_utilsフォルダをSDxのプロジェクト(Workspace)のディレクトリに入れればOKなようです。
これでincludeファイルが見つかって、ビルドできるようになります。
出来上がったVivadoのプロジェクトは
D:\sdsoc\UG1236\platforms\empty_application\Debug\_sds\p0\_vpl\ipi\syn
にありました。開いてみるとVivadoのBlock Designが出来上がっていました。
HLSのモジュールがあり、DataMoverがDMA転送をするという典型的なデザインのようです。左側に、チュートリアルで作ったひな型のBlock Designが含まれています。
これをImplementしたプロジェクトは
D:\sdsoc\UG1236\platforms\empty_application\Debug\_sds\p0\_vpl\ipi\imp
にあります。実体はdcpファイルなので、中は見れません。
dcpファイルの拡張子をzipに変えて解凍してみても、巨大なEDIFとXDCといくつかの設定がファイルが入っているだけのようなので、この時点でネットリスト化されているようです。
SDx上ではelfファイルも出来上がり、最終的なBOOT.BINも出来ていました。
これを書き込めばSDSoCのアプリが動くのだとは思いますが、ZC702がないので試せません。
次はZynqberryでやってみることにします。
ところで、ピン配置の定義ってどこでやるんだろう・・？最初にボードファイルを読み込んだところかな？
最新の開発方法に追いつかなければならないと思い、私もSDSoCの勉強をはじめました。
ダウンロードしたのはSDx 2018.1。
まずは、UG1028を参考にしながら、Matrix Multiplication and Additionのチュートリアルを行いました。
Matrix Multiplication and Additionというのは、32×32の行列の掛け算と足し算を、ハードウェアで行うサンプルです。
チュートリアルを見ていると、SDSoCの合成結果のパフォーマンスを、クロック数やデータポートの選択の表で説明されています。
こんな感じの表です。
チュートリアルでは、この表を指してpragmaが効いている旨を説明していますが、正直よくわかりません。
実際にどんな回路が出来上がるのか、回路を見てみないと安心できないので、どこかにVivadoのプロジェクトが出来てないか探してみました。
そうしたら、VivadoのIPインテグレータのブロックデザインのプロジェクトが下記のディレクトリにありました。
\Debug\_sds\p0\_vpl\ipi\syn
これをVivadoで開きます。
デフォルトのMatrix Multiplication and Additionサンプルプロジェクトを合成した回路が、以下のものです。
この中に、Vivado HLSのモジュールが2つほどあるのが見えます。
HLSモジュールの隣にあるdm_というのがデータムーバ。データムーバとは簡単に言えばDMA転送のマスタです。
pragmaの構文やmalloc()かsds_alloc()の選択によって、シンプルDMAになるか、スキャッタギャザーDMAになるかが変わるそうです。
このデータムーバから出ているAXIバスはAXI Interconnectによって束ねられて、PSのACPポートにつながっています。
これを見てSDSoCが何をしているかが、わかりました。
CPUのメモリ空間(DDRメモリ)からDMAによってデータを取り出して、それをハードウェアのモジュール(HLS)にコピーし、演算した結果を、再びDMAによってCPUのメモリ空間(DDRメモリ)にコピーするというわけですね。
次の図は、mmultをソフトウェアに切り替えた場合です。
maddの回路のみ残って、mmultの回路はIPインテグレータから消えました。
次はvoid mmultの関数宣言の前に
#pragma SDS data sys_port(A:ACP, B:AFI)
を付けて、AFI(AXI HP0)を使うようにしてみた結果です。確かに、AXI HPポートを使うようになっています。
SDSoCがどのような回路を生成するのか、何となく理解できてきました。
特殊電子回路は、ドイツ TrenzElectronic社の正規代理店を行っていますが、このたび、Webサイトのリニューアルが完了しました。
最初の画面は、ぱっと明るい、ドイツの風景。
Trenz社の商品のうち、TE0807やTE0745、TE0782、TE0841シリーズのようなZYNQ UltraScale+やZYNQ UltraScale+製品など、取扱商品を大幅に増やしました。
ベースボードも取り扱いを開始しました。
特電で在庫している商品は「当社在庫」の数が出るようにし、
当社で在庫がない商品についてはメーカーの在庫数が表示されるようにしました。
メーカー在庫となっているものは、すぐに取り寄せますので、お気軽にお問合せください。
今、おすすめなのは、UltraScale+です。
特にZYNQ UltraScale+のハイエンドなものは、FPGA単体を日本で買うと37万円くらい(Digikey価格)するのに、Trenzのボードは約27万円と、FPGAの価格よりも安い値段となっています。
デバイスの価格より、ボードのほうが安いという逆転現象が起きています。
といってもUltraScale+のものは品切れが多いのですが、特電ではTE0820のモジュールは在庫を持っています。
例えば、
は、XCZU3CG-1SFVC784EのFPGA単体の価格が43,000円(Digikey調べ)ですが、ボードにしても47,000円なので、いかにお得かがわかります。
UltraScale+をパソコンの形にしたモジュールなんていうのもあります。
これはベースボードや電源、USB-JTAGがセットになったものなので、コンセントに挿すだけでUltraScale+のLinuxが楽しめます。
それから、最もおすすめなのが、TE0808スタータキット
一番ハイエンドなXCZU9EG-2FFVC900Iを搭載し、パソコンの形にしたものです。DigikeyやAvnetで40万円以上するFPGAなのに、スタータキットのほうが安い。これも不思議な現象です。
中に入っているTE0808-04-09EGモジュールは、今年の2月くらいから製造がうまく進んでいないようなので、半年くらいメーカーにも在庫0の状態が続いています。世界的に供給不足のようです。
特電にあるこの在庫1個が、今後しばらくの間入手可能な唯一の在庫なのではないかと思われます。
この夏、Trenz製品で、UltraScale+デビューしませんか？
特殊電子回路の決済方法は、いままで、銀行振込先払いか、代引きか、クレジットカードでした。
銀行振込後払いは、大学や公的機関のお客様に限らせていただいておりましたが、掛け売りを希望される一般の企業の方も多かったのが事実です。
一般の企業の方で掛け売りで購入したいという方は、クレジットカードを使ったり、商社を挟んでいただくことで対応されていたようです。
この中で問題になるのは、クレジットカード。
一般に知られていることかどうかわかりませんが、クレジットカードの手数料は、全額ショップ負担で7%くらいなのです。代行会社を使えば少し安くなりますが、直接的な手数料のほかに、振り込み時の手数料とか振込手数料とか早期入金サービス料とか固定費とか、何だかんだ引かれて、最終的には１割くらい減ってしまう感覚です。
（それに比べて運送会社の代引きはクレジット決済よりも手数料が安く、商品の金額が変わってもそれほど手数料が高くはならないのでありがたいです。）
クレジットカード手数料をお店が上乗せすることは契約により禁止されています。代引きの手数料を上乗せするのはOKなのに、なぜでしょうね。
Zynqberryのように利益率が少ない商品でクレジットカードで決済されると、赤字となります。
これは何とかしなければなりません。
XILINX FPGAは汎用のSPI ROMをコンフィギュレーションROMとして使用できますが、昨今のメモリ業界は入れ替わりが早く、古いSPI ROMはディスコンとなり、新しいROMはiMPACTからもVivadoからも書き込みができないなど、対応しているROMを探すのが難しくなってしまいました。
MITOUJTAGも同じで、W25Q32だの、JVSIGやSVSIG・・など型番が少し変わったROMに対応させていくのが大変だと感じていました。
すると、SPI ROMデバイスのIDCODEと、そのROMのサイズやアルゴリズムなどをテキストファイルで書いておいて、ツールが動的にそれを読み込めばいいのではないかという発想になります。
MITOUJTAGを改良し、ファイルからSPI ROMのパラメータを読み込めるようにしました。
検証に使ったボードは特電のSpartan-6ボード。このボードのSPI ROMをMacronix社のMX25R3235Fに乗せ換えます。
ROMはブランクなので、当然ながらFPGAは起動前の状態で、I/Oは全ピン入力状態としえて見えます。
MITOUJTAGはこのSPI ROMのIDCODEを知らないので、最初は書き込みができません。不明と出てしまいます。
そこで、下記のようなファイルを作成し、MITOUJTAGのsysフォルダにspiromid.txtというファイル名で置いておきます。
#idcode , pagesize , maxpages , page_addr_shift , algorithm , devicename # # Choose an algorithm from below. # ATMEL ST NUMONIX INTEL SST MICRON WINBOND SPANSION CYPRESS ISSI ONSEMI MACRONIX # 0xc22816 , 256 , 16384 , 8 , macronix , MX25R3235F 0xc22015 , 256 , 8192 , 8 , macronix , MX25L1606E 0xbf2641 , 256 , 8192 , 8 , sst , SST26VF016B
最初の列はIDCODE、次の列はページサイズです。ページサイズは普通は256です。その次の列はページ数なのですが、ページサイズが普通は256なので、32Mbit品ならここは16384となります。
次は製造元を表す列ですが、 ATMEL ST NUMONIX INTEL SST MICRON WINBOND SPANSION CYPRESS ISSI ONSEMI MACRONIXの中から選びます。これでアルゴリズムが選択されます。
最後はデバイス名です。デバイス名は画面に表示されるだけなので、違っていても動作に影響はありません。
このファイルを記述すると、未知のSPI ROMでも認識できるようになります。
もちろん書き込みも成功し、
ちゃんと起動しました。
SPI ROMの書き込みアルゴリズムは、ST/Micron/Winbond/Intelなどの標準的なアルゴリズムのほか、ATMEL、SSTなどの変則的なものにも一部対応しています。
今回の改良により、ユーザの手元で書き込みパラメータを編集できるようになりました。これで今後どんなSPI ROMが出てきても怖くありませんね。
この修正パッチは次回のMITOUJTAGの更新で提供しますが、ご必要な方にはすぐに提供しますので、ご連絡ください。
会社案内のパンフレットに載せる写真を撮ろうと思い、自宅近くにある写真スタジオに行きました。
写真屋さんは本当にいい写真を撮ってくれます。自分で取るよりも100倍良く撮れます。
撮った写真を（目隠しを入れて）ここに載せておきます。
まず、「どんな目的に使う写真ですか？ホームページですか？」ということで「会社案内のパンフレットです。」と答えたら、「どんな会社ですか？」という質問で、「電気の部品とかを作ってます」というと、「それなら真面目な堅いほうがいいですね」ということで、
「少し半身になってください。右か左かどちらか楽な方があるはずです」とのことで、確かに右肩を後ろにしたほうがしっくりきます。
それから、1cmレベルの精度で肩の位置を調整して、顔の角度、目を見開く大きさなどを調整して、ベストな見栄えで撮ってくれました。
おそらくフラッシュや一眼レフなどの設備だけあっても良い写真は撮れません。角度や表情を調整してベストな写真を撮る技術がプロの技なのでしょう。
私も電気のプロとして、そうありたいですね。
今更ではありますが、MITOUJTAGでVivadoのXDCファイルが読み込めるようにしました。
いままでのMITOUJTAGはXDCに対して機能不足で
という問題がありました。
XDCファイルが表示されないというのは、下の図のような状況です。
XILINX用のピン定義ファイルを表示しようとしても、XDCが出てきません。ファイル名のところに*.xdcと入れなければなりませんでした。
また、-dict記述に対応していないというのは、XDCでのピン定義はset_property PACKAGE_PINという記述で行いますが、このやり方には2種類あって、
set_property PACKAGE_PIN F17 [get_ports {netic20_f17}]; #IO_L6N_T0_VREF_35
set_property PACKAGE_PIN G18 [get_ports {netic20_g18}]; #IO_L16N_T2_35
set_property PACKAGE_PIN T9 [get_ports {netic20_t9}]; #IO_L12P_T1_MRCC_13
set_property PACKAGE_PIN U9 [get_ports {netic20_u9} ] ; #IO_L17P_T2_13
という書き方と、
set_property -dict {PACKAGE_PIN Y18 IOSTANDARD LVCMOS33} [get_ports {PWM_H_OUT[0]}]
set_property -dict {PACKAGE_PIN Y19 IOSTANDARD LVCMOS33} [get_ports {PWM_L_OUT[0]}]
set_property -dict {PACKAGE_PIN Y16 IOSTANDARD LVCMOS33} [get_ports {DRV_FLT[0]}]
set_property -dict {PACKAGE_PIN Y17 IOSTANDARD LVCMOS33} [get_ports {DRV_EN[0]}]
という書き方の2種類があります。
前者の書き方は、ピンに対してIO規格とピン番号を別の行で指定する方法です。
後者の書き方は-dict {} という記述方法で1行にまとめてしまう方法です。
今までのMITOUJTAGでは前者の方法にしか対応していませんでした。
これらの問題を解決したパッチを作成しました。
今回、動作テストに使ったボードは、Arty-Z7です。デバイスを自動認識させたら、右クリックして、「ピン定義ファイルの読み込み」を行います。
一覧にちゃんとXDCファイルが表示されるようになりました。
そして、Arty-Z7のXDCファイルを読み込んでロジアナモードを開くと、
このようにピンの定義が読み込まれていることがわかります。
この機能は次回のMITOUJTAGの更新の際に取り込んでリリースしますが、パッチだけすぐに欲しいという方はご連絡ください。
最近のコメント