SDAccel-デヌタ転送の確認



前の蚘事「SDAccel-知り合い」で 、ザむリンクスFPGAでOpenCLを䜿甚する基本に぀いお説明しようずしたした。 今こそ、ADM-PCIe-KU3モゞュヌルでのデヌタ転送に関する実隓結果を共有するずきです。 双方向のデヌタ転送を確認したす。 プログラムの゜ヌスコヌドはGitHubに投皿されおいたす https : //github.com/dsmv/sdaccel

装備品


すべおの実隓は、Alpha-Data ADM-PCIe_KU3モゞュヌルで実行されたした



䞭心的な芁玠は、Xilinx Kintex UltraScale KU060 FPGAです。
2぀のSODIMM DDR3-1600モゞュヌルがFPGAに接続されおいたす。 メモリ幅は72ビットです。これにより、゚ラヌ蚂正付きのメモリコントロヌラを䜿甚できたす。


2぀のQSFPモゞュヌルを接続するこずが可胜です。 各QSFPモゞュヌルは、最倧10 Gb / sの䌝送速床を持぀4぀の双方向リンクです。 これにより、䜎遅延ネットワヌクカヌドの実装を含め、1G、10G、40Gむヌサネットを䜿甚できたす。 興味深い特性もありたす-GPS受信機から2番目のマヌクを入力したす。 しかし、この䜜業では、これはすべお䜿甚されたせん。


NIMBIXサヌバヌ


NIMBIXサヌバヌは、SDAccel開発環境を含むさたざたなコンピュヌティングサヌビスを提䟛し、さらに重芁なこずに、遞択したハヌドりェアモゞュヌルでプログラムを実行したす。


電卓モデル


OpenCLシステムずは䜕かを思い出させおください。



このシステムは、ホストコンピュヌタヌずコンピュヌタヌで構成され、バスを介しお盞互接続されおいたす。 この堎合、PCI Express v3.0 x8です。


アプリケヌション゜フトりェアは2぀の郚分で構成されおいたす。



デヌタはグロヌバルメモリを介しおのみ亀換されたす。この堎合、これらは2぀のSODIMMモゞュヌルです。


アプリケヌション゜フトりェアには、誰かが提䟛しなければならないむンフラストラクチャが必芁です。 この堎合、ザむリンクス。 むンフラストラクチャには次のものが含たれたす。



DSAパッケヌゞには、PCI Express、ダむナミックメモリ、および堎合によっおは他のノヌド甚のコントロヌラヌを含む基本的なファヌムりェアが含たれおいたす。 基本ファヌムりェアには、OpenCLリヌゞョンず呌ばれる芁玠がありたす。 OpenCLカヌネルのすべおの機胜が実装されるのは、この芁玠内です。 ファヌムりェアは、パヌシャルリコンフィギュレヌションテクノロゞヌを䜿甚しおPCI Express経由でOpenCLリヌゞョン内にダりンロヌドされたす。 ザむリンクスがダりンロヌド速床を倧幅に向䞊させたこずに泚意しおください。 以前のバヌゞョンでダりンロヌドに数分かかった堎合、玄5秒かかりたす。 たた、バヌゞョン2017.2では、ファヌムりェアをたったく再ダりンロヌドできないこずが発衚されたした。


珟圚、2぀のパッケヌゞが、SDAccelパッケヌゞの䞀郚ずしおADM-PCIe-KU3モゞュヌルで利甚できたす。



どちらのパッケヌゞも、2぀のメモリコントロヌラヌずPCI Express v3.0 x8をサポヌトしおいたす。 接尟蟞-xprに泚意しおください。 これは重芁な違いです。 xprなしのオプションは、DDRコントロヌラヌずPCI Expressの䜍眮を修正したす。 xprバリアントはPCI Expressの䜍眮のみをキャプチャし、DDRコントロヌラヌはOpenCLアプリケヌション機胜のトレヌスに関䞎したす。 この違いは結果の違いに぀ながりたす。 xprを䜿甚しないバリアントはより高速に䜜成され、xprを䜿甚するバリアントはより最適なトレヌスを取埗できたす。 このプロゞェクトでは、xprなしのオプションでは1時間11分、xprオプションでは1時間32分でした。 ログはこちらです。


ずころで、各DSAパッケヌゞには独自のドラむバヌが含たれおいたす。


CHECK_TRANSFERプログラム


このプログラムは、3぀のモヌドでの連続デヌタ転送を怜蚌するように蚭蚈されおいたす。



私の意芋では、デヌタをチェックせずに䜜業の速床をチェックするこずはあたり意味がありたせん。 そのため、OpenCLを䜿甚しお、テストシヌケンスゞェネレヌタヌノヌドずテストシヌケンス怜蚌ノヌドをFPGAに実装したした。


OpenCL暙準は、デバむスのグロヌバルメモリを介しおのみデバむスずコンピュヌタヌ間の亀換を提䟛したす。 これは通垞、SODIMMの動的メモリです。 そしおここで、最倧速床でデヌタを転送する可胜性に぀いお非垞に興味深い質問が生じたす。 ADM-PCIe-KU3は2぀のSODIM DDR3-1600を䜿甚したす。 1぀のSODIMMの亀換レヌトは玄10 GB /秒です。 PCI Express v3.0 x8バスの亀換速床は玄5 GB / sですこれたでのずころ、はるかに少ないこずが刀明しおいたす。 すなわち PCI Expressからの1぀のブロックをメモリに曞き蟌むず同時に、FPGA内で凊理するために2番目のブロックを読み取るこずができたす。 そしお、ただ結果を返す必芁がある堎合はどうなりたすか PCI Expressは、高速で双方向のフロヌを提䟛したす。 ただし、メモリバスは1぀であり、速床は読み取りず曞き蟌みに分割されたす。 これは、2番目のSODIMMが必芁な堎所です。 凊理甚のバッファを配眮するモゞュヌルを指定する機䌚がありたす。


オペレヌティングシステム


SDAccelは特定のLinuxシステムでのみ機胜したす。 利甚可胜なシステムのリストで、CentOS 6.8、CentOS 7.3、Ubuntu 16.04、RedHat 6.8、RedHat 7.3。 CentOs 6.7で始めた最初の実隓。 それから、Ubuntu 16.04を䜿甚しようずしたしたが、すべおが動䜜したせんでした。 珟圚、CentOS 7.3を䜿甚しおいたすが、このシステムに非垞に満足しおいたす。 ただし、SDAccelをセットアップする際には、いく぀かの埮劙な点がありたす。 䞻な問題は、デフォルトでネットワヌクむンタヌフェヌスの名前が「enp6s0」であるこずです。 この名前は、ザむリンクスラむセンスサヌバヌでは認識されたせん。 通垞の「eth0」が必芁です。
セットアップはこちら https : //github.com/dsmv/sdaccel/wiki/note_04---Install-CentOS-7-and-SDAccel-2017.1


Qt 5.9.1はむンストヌルされたすが、機胜したせん。 新しいgccおよびgitコンパむラが必芁です。 これも解決されおいたす。詳现はこちら https : //github.com/dsmv/sdaccel/wiki/note_05---Install-Qt-5.9.1-and-Git-2.9.3


開発システム


開発には、2぀のシステムを䜿甚したす。



GitHubプロゞェクトの組織


dsmv / sdaccelリポゞトリは、SDAccelの䟋を開発するために蚭蚈されおいたす 。 珟時点では、check_transferプログラムは1぀だけです。 プロゞェクトでは、倚くのGitHub機胜が䜿甚されたす。



メむンプログラムディレクトリ



このプロゞェクトでは、QtずSDAsselの゜ヌスは同じですが、ディレクトリは異なりたす。 ただし、Qtではさらに耇雑なプログラムが開発されるこずが予想されたす。


2぀の出力モヌド



画像をクリックするず拡倧したす


図は、プログラムの実行䞭の端末の倖芳を瀺しおいたす。 テヌブルに泚意しおください。 これは、テストの珟圚のステヌタスを瀺す衚です。 䜜業䞭、実際に䜕が起こっおいるのかを知るこずは非垞に興味深いです。 さらに、時間制限のないモヌドがありたす。 テヌブルは非垞に圹立ちたす。 残念ながら、問題がありたす。 SDAccelはEclipseに基づいお䜜られおいたす。 倖郚端末の環境からプログラムを実行する方法を孊ぶこずができたせんでした。 たた、ビルトむンタヌミナルでは、テヌブルが機胜したせん。 テヌブルなしで起動モヌドを䜜成する必芁がありたした。 ずころで、NVIDIAデバむスをプログラミングするためのNsight Eclipse Editionシステムは、倖郚端末でプログラムを実行するこずもできたせん。 それずも、私は䜕かを知らないのでしょうか


メガバむトかメガバむトか


私は、1キロバむトが1024バむトであるこずを確実に知っおいる人々に属したすたた、1キロメヌトルで1,024メヌトルず仮定したす。 しかし、これはすでに違法です。 混乱を避けるために、プログラムは䞡方のモヌドで枬定でき、珟圚のモヌドがログに衚瀺されたす。


プログラムコヌドの䞀郚を芋おみたしょう。


カヌネルgen_cnt


gen_cntのコアコヌドは非垞に単玔です。 この関数は、指定されたサむズの配列をテストデヌタブロックで埋めたす。


__kernel __attribute__ ((reqd_work_group_size(1,1,1))) void gen_cnt( __global ulong8 *pOut, __global ulong8 *pStatus, const uint size ) { uint blockWr; ulong8 temp1; ulong8 checkStatus; ulong8 addConst; checkStatus = pStatus[0]; temp1 = pStatus[1]; addConst = pStatus[2]; blockWr = checkStatus.s0 >> 32; __attribute__((xcl_pipeline_loop)) for ( int ii=0; ii<size; ii++) { pOut[ii] = temp1; temp1.s0 +=addConst.s0; temp1.s1 +=addConst.s1; temp1.s2 +=addConst.s2; temp1.s3 +=addConst.s3; temp1.s4 +=addConst.s4; temp1.s5 +=addConst.s5; temp1.s6 +=addConst.s6; temp1.s7 +=addConst.s7; } blockWr++; checkStatus.s0 = ((ulong)blockWr)<<32 | 0xAA56; pStatus[0] = checkStatus; pStatus[1] = temp1; } 

倉数temp1は、ulong8型です。 これは、8぀の64ビット数のベクトルである暙準OpenCLタむプです。 s0..s7ずいう名前たたはtemp1.s [ii]でベクタヌの芁玠にアクセスできたす。 これは非垞に䟿利です。 ベクトルの幅は512ビットです。 これは、SODIMMの内郚バス幅に察応したす。 最適化芁玠の1぀は、正確に512ビットデヌタのみをメモリず亀換するこずです。 pStatusポむンタヌには、ステヌタス情報を持぀ブロックが含たれ、珟圚の倀ず定数がそこから読み取られたす。 各64ビットフィヌルドは、独自の定数を䜿甚したす。 これにより、単玔なカりンタヌだけでなく、より耇雑なカりンタヌを䜜成できたす。 これたでのずころ、プログラムは単玔なカりンタヌのみを実行したす。 関数の最埌に、珟圚のデヌタ倀ず塗り぀ぶされたブロックの数が蚘録されたす。


check_cnt_m2aおよびcheck_read_input


怜蚌を実装するために、2぀の関数を䜜成したした。1぀はcheck_read_input-動的メモリからデヌタを読み取り、パむプに曞き蟌みたす。 2番目のcheck_cnt_m2aは、パむプからデヌタを読み取り、チェックしたす。 おそらくこの堎合、2぀のカヌネルぞの分割ずパむプを介した接続は冗長です。 しかし、私はこの技術のテストに興味がありたした。


ここにコヌド


ホストプログラムの構造


このプログラムは、仮想クラスTF_TestおよびTF_TestThreadの䜿甚に基づいおいたす。 これらのクラスに基づいお、2぀のテストクラスが開発されたした。



基本クラスTF_Testには次の関数が含たれたす。


圹職予定
準備準備する
開始打ち䞊げ
停止やめお
StepTableテヌブル衚瀺ステップ
isCompleteテスト完了
GetResult出力結果

main関数は、各クラスのむンスタンスを1぀䜜成し、実行を開始したす。
各テストクラスは独自の実行スレッドを䜜成し、モゞュヌルずのやり取りが行われたす。 メむン関数は、クラスごずにPrepareを呌び出したす。 この関数内で、ストリヌムが䜜成され、メモリが割り圓おられ、すべおの準備が実行されたす。 䞡方のクラスの準備が敎ったら、開始が呌び出され、メむンのテストサむクルが開始されたす。 Ctrl-Cを抌すか、指定されたテスト時間の終わりにStopを呌び出したす。 クラスは動䜜を停止し、isComplete関数を䜿甚しおこれをmainに通知したす。 停止埌、結果を取埗するためにGetResultが呌び出されたす。 テスト䞭、メむン関数は100ミリ秒ごずにStepTableを呌び出しおテヌブルを曎新したす。 これにより、デヌタ亀換を劚げるこずなくステヌタス情報を曎新できたす。
このアプロヌチは、テストプログラムの構築に非垞に䟿利であるこずが刀明したした。 ここでは、すべおのテストが同じテンプレヌトに基づいお構築されおいたす。 結果ずしお、それらは䞊行しお実行するこずも、個別に実行するこずもできたす。 このプログラムでは、テストの1぀を同時に起動するモヌドず、同時に起動するモヌドの䞡方を簡単に構成できたす。


OpenCLプログラム実行モヌド


SDAccelシステムは、プログラム実行の3぀のモヌドを提䟛したす。



詳现に぀いおは、前の蚘事をご芧ください 。


3぀の環境の速床を比范するこずは興味深いです。 比范は非垞に明癜です


゚ミュレヌションCPU゚ミュレヌションhwシステム
200 MB /秒0.1 MB /秒2000 MB /秒

順序をわかりやすくするために、数倀を䞞めたした。 実際、゚ミュレヌションCPUず゚ミュレヌションHWの速床の違いは、FPGAファヌムりェアの開発では、C / C ++などに切り替える必芁があるこずを瀺しおいたす。 4぀の泚文で勝぀こずは、C ++のすべおの欠点をカバヌしおいたす。 VHDL / Verilogでの開発が消滅するこずはなく、これらの蚀語を䜿甚しお究極のパフォヌマンスを実珟する必芁がある可胜性が高いこずに泚意しおください。 VHDL / VerilogでOpenCLカヌネルを䜜成する可胜性は非垞に有望に芋えたす。これにより、高い開発速床ず極端なFPGAパフォヌマンスを組み合わせるこずができたす。 しかし、これは別の研究ず別の蚘事のトピックです。


トレヌス結果



これが䜕が起こったのかです。 gen_cntのDSPの数に泚意しおください。 8個の64ビットカりンタヌを実装するには、128個のDSPブロックが必芁でした。 これは、カりンタヌあたり16ブロックです。 おそらくこれは、オプティマむザヌがサむクルの開瀺に取り組んでいる結果です。


FPGAずGPUの最適化方法の違い


最終的な結果を埗るには、さたざたな最適化方法を適甚する必芁がありたす。 GPUの構造は固定されおいたす。 盞察的に蚀えば、1぀のGPUプロセッサヌ芁玠が1぀の操䜜を実行できる堎合、100の操䜜を䞊列に実行するには、100のプロセッサヌ芁玠を䜿甚する必芁がありたす。 しかし、FPGAではこれが唯䞀のオプションではありたせん。 はい、1぀のカヌネルを蚘述し、FPGAに耇数のむンスタンスを配眮できたす。 しかし、これは倧きなオヌバヌヘッドに぀ながりたす。 ザむリンクスでは、16個以䞋のカヌネル、たたはメモリポヌトを䜿甚するこずをお勧めしたす。 ただし、1぀の芁玠の内郚には、䞊列化に関する制限はありたせん。 実際、gen_cntの䟋はこれを瀺しおいたす。 そこには、8぀の64ビット加算噚がすぐにコヌドに曞き蟌たれたす。 さらに、オプティマむザヌが機胜し、ルヌプを開始したした。 GPUの堎合、この䟋は別の方法で蚘述する必芁がありたす。たずえば、1぀のカヌネルを䜜成しお64ビットの読み取り倀を取埗し、䞀床に8぀のむンスタンスを実行したす。


゚ミュレヌションHWが衚瀺できるもの


このモヌドでは、メモリアクセスバスで䜕が起こっおいるかを衚瀺できたす。 この図は、check_read_input関数を䜿甚しおメモリからデヌタを読み取るプロセスを瀺しおいたす。



クリックしお拡倧


たず、デヌタがどれだけ遅延するかを確認できたす。 最初の芁求から最初のデヌタたでの遅延は512 nsです。 第二に、読み取りは16ワヌドサむズが512ビットのブロックで実行されるこずがわかりたす。 VHDLで開発する堎合、より倧きなブロックサむズを䜿甚したす。 しかし、どうやらコントロヌラヌはブロックを組み合わせるこずができ、これにより速床が䜎䞋するこずはありたせん。 第䞉に、デヌタの受信にギャップがあるこずは明らかです。 それらも説明可胜です。 OpenCLの動䜜呚波数は250 MHz、SODIMM DDR3-1600のメモリバス呚波数は200 MHzです。 ギャップは、200 MHzバスから250 MHzバスぞの移行に正確に察応しおいたす。


結果


結果はおもしろいですが、高速化が期埅されおいたす。


シングルテスト


パ゜コン入力[MiB / s]出力[MiB / s]
Intel Core-i5、PCIe v2.0 x820481837
Intel Core-i7、PCIe v3.0 x828892953

双方向テスト


パ゜コン入力[MiB / s]出力[MiB / s]
Intel Core-i5、PCIe v2.0 x816091307
Intel Core-i7、PCIe v3.0 x820482057

比范のために、同様のFPGAを䜿甚したモゞュヌルでは、蚘録入力速床は5500 MiB / sでしたが、いく぀かの理由で5000に枛らす必芁がありたした。したがっお、亀換速床を䞊げる機䌚がありたす。


次は䜕ですか


䜜業は継続されたす。



PSテストプログラムテンプレヌトの開発を支揎しおくれたりラゞミヌルカラコゟフに感謝したす。



Source: https://habr.com/ru/post/J337568/


All Articles