eisuke::log()

この備忘録の概要 Zynq MPSoCの中でもハードウェア容量の大きなFPGAでは、DPU (Deep-Learning Processor Unit)の最大規模のアーキテクチャであるDPUCZDX8GのB4096を複数実装できる。今回は、DPUCZDX8G (B4096)を2コア用いて、画像認識処理を2並列で処理することを目指す。本備忘録では、事前学習済みのDenseBox(顔検出)とResNet-50(クラス分類)モデルを2並列で処理してみることにした。Vitis AI Libraryからの使い方はそれぞれ、UG1354 vitis-ai-FaceDetectとUG1354 vitis-ai-Classificationを参照すること。 動作確認済み環境 Zynq UltraScale+ MPSoC カスタムボードでの動作を確認した。詳細は以下の通りである。 Device Part: xczu19eg-ffvc1760-2-i OS: Petalinux 2022.2 CPU: Cortex-A53 Petalinux SDK: 2022.2 Vitis-AI: 3.0 DPU: DPUCZDX8G v4.1 (B4096) x 2コア カスタムボード向けへのDPU構築にはPG338 DPU-TRDのVitisフローを用いた。構築の解説は割愛するが、Vitisフローが完了すると、以下の画像のようにVivadoのブロックデザインや使用したハードウェア量を見ることができる。具体的な構築方法は、Zynq UltraScale＋ MPSoC DPU TRD V4.1 Vitis 2022.2を追っていくと良い。また、Vitisフローで登場するDPUの構成を変更できる設定ファイルdpu_conf.vhは、デフォルトのまま変更せずに構築した。 一番使用率の高いDSPでも27%の空きがあるので、B1024のようなハードウェア使用率を抑えたアーキテクチャであれば、実装可能かもしれない。 と思ったのだが、PG338 featuresには、 Software and IP core support for up to a maximum of four homogeneous DPU instances in a single AMD Xilinx® SoC....

NICのオープンソースプロジェクトCorundumを使用してAlveo U200とU50をNIC化し、Alveo間で通信ができたのでその備忘録です。 この記事のゴール 以下の画像のようにAlveo U200とAlveo U50をNIC化したもの使って通信する。 環境 基本的に前に投稿した記事Alveo U200とU50のセットアップのセットアップ環境を用いた。ただし、Vivadoは別マシンにインストールしているものを使ったためバージョンがズレている(2021.1でなく2022.1)。 Corundum: 記事執筆時点での最新コミット(c708bc4) AlveoホストマシンOS: Ubuntu 20.04 Vivado: 2022.1 FPGA: Alveo U200/U50 DACケーブル: 1m (3ft) Cisco QSFP-100G-CU1M互換 100G QSFP28パッシブダイレクトアタッチ銅製Twinaxケーブル(DAC) NIC化の手順 (U200で説明) Corundumでは、10G/25G/100GのEthernetに対応している。今回は、U200とU50を100GbEへNIC化した。以下はCorundumのドキュメントのGetting Startedを参考に進めていったときの手順である。また、以下の説明では、U200を対象とするが、同様の手順でU50もNIC化できる。 1. UltraScale+ Integrated 100G Ethernet Subsystemのライセンス取得 まず、XilinxのUltraScale+ Integrated 100G Ethernet Subsystemから100G Ethernet Subsystemのライセンスを取得する(無償)。また、ライセンスファイルが取得できたら、Vivadoのライセンスマネージャで読み込む。 読み込むと以下の画像のようにcmac_usplusという名前で追加された。 2. Corundumのダウンロード GitHubからCloneする $ git clone https://github....

2022年の5月くらいに作ってたTclスクリプトの紹介 実用的な回路を256個も含んで並列処理、というのはハードウェアリソースの面で現実的ではなさそうなのでネタっぽさはあるが、複数のIPコアを含むブロックデザインを作る際に、作成したTclスクリプトで作業効率が上がった。 「IPコア」という表記をする場合は高位合成ベースのIPコアを指す。 背景 VivadoのブロックデザインにはIPコア同士を接続できる機能Run Connection Automationがある。この機能を使って、Zynq SoC向けにVitis HLSで作成したIPコアを複数個使ってブロックデザインを作成したいが、AXI4-Liteインターフェイスを含むIPコアを64個より多く含んで自動接続することができない。その原因は、AXI Interconnectのマスタ側は最大64接続?であるが、その数を超えたIPコアがあっても新たにAXI Interconnectを追加してくれないためである。実際に128個の加算回路IPコアを追加しRun Connection Automationした際のエラーを画像に示す。65個目の加算回路IPコアの接続でエラーが出ている。 また、Zynq SoC向けにAXI4-StreamインターフェイスのIPコアをAXI DMA IPを用いてデータ入出力することがしばしば発生する。IPコアを複数個追加しAXI DMA IPと1対1に接続するとき、追加した数だけAXI DMA IPの設定(チャネルの設定)する必要があり、手間である(AXI Interconnectの件よりも、これを解決するのが本命だった)。 何をしたか UG835を参考に、Zynq SoC向けの高位合成ベースのIPコアを最大256個含むブロックデザインを自動で追加・接続のできるTclスクリプトを作成した。スクリプトは vivado-auto-bd-playgroud - GitHub にてMITライセンスで公開している。 どんなブロックデザインが生成できるか 同一のIPコアを複数個 作成したスクリプトを使うことで画像のようなブロックデザインを自動で作成することができる。以下の画像は入出力がAXI4-Liteの加算回路のIPコアを自動で256個追加・接続したときのブロックデザインである(画像では、もやは何がなんだかわからない)。 異種のIPコアを複数個 また、複数種類のIPコアを複数個、追加・接続することもできる。以下の画像は、入出力にAXI4-Streamを使うIPコアを4つ、入出力にAXI4-Liteを使うIPコアを8個追加した例である。AXI4-Streamの場合はDMA回路の設定を含めて自動で行われる。 スクリプトの使い方 後述の環境と制限をよく読み、Vitis HLSでC Synthesis、export RTL vivado_block_design.tclを必要なパラメータと一緒にvivadoのコマンドライン引数に渡す vivado -nolog -nojournal -mode batch \ -source ./vivado_block_design.tcl \ -tclargs -project_name vivado \ -device_part <デバイスパーツ> \ -ips_directory <IPコア(....

2022年最終日！今年はARMプロセッサと一体のFPGAボード(SoC FPGA)を中心に使っていたが、卒業論文や学会発表が終わり次第、Alveoカードを中心に使うことになりそうなので開発環境をセットアップした。そのときのメモを残しておく。基本的にUG1301やUG1370を参考にセットアップした。 セットアップ環境 Xilinx Alveoはデータセンター向けのFPGAで、PCI Express経由でホストマシン(x86)と通信することができる。今回はAlveoのU200とU50のセットアップをした。U200もU50も同じような手順でセットアップすることができる。セットアップアップするホストマシンの環境は以下の通りである。 ホストマシン #1 CPU: 12th Gen Intel(R) Core(TM) i5-12400 OS: 20.04.5 LTS (Focal Fossa) Vitis 2021.1 PCI Expressスロット ← Alveo U200を装着 ホストマシン #2 CPU: 12th Gen Intel(R) Core(TM) i5-12400 OS: 20.04.5 LTS (Focal Fossa) Vitis 2021.1 PCI Expressスロット ← Alveo U50を装着 Vitisのインストール Vitis 2021....

いつの間にか学部4年生になっていて、今取り組んでいる卒業研究の単位が認定されれば学士号取得です(あっという間の4年間)。今年は全然記事かけませんでしたが、たまには書こうということで、今年買ってよかったものと、学生生活に分けて振り返りました。 今年買ってよかったもの 生活の木 アロモアミニ ポータブル ウッド あまりにも睡眠の質がひどく悩まされていたので、池袋の「生活の木」でアロマディフューザーを買ってみたところ最高でした。私は、ラベンダーばかり買っています。ホットアイマスクと併用して寝ると、なお良いです。睡眠以外にも作業中に使用するとリフレッシュでき、卒業研究の助けになりました。 書籍 今年はあまり書籍は買っていませんが、2冊ほど… .amazon-widget { margin: 2rem 0; max-width: 240px; position: relative; } .amazon-widget a { position: absolute; top:0; left:0; height: 100%; width: 100%; } .amazon-widget-img { border: 1px solid #E1E8ED; border-radius: 15px 15px 0 0; text-align: center; } .amazon-widget-img img { border: none; margin: 0 auto; max-height: 150px; padding: 16px; } ....

はじめに epoll APIは有能だなあと思う今日この頃ですが、epoll_wait()してイベントを取り出す処理をべた書きするとコードが汚くなりがちです。少し前の記事ですが、epoll APIを使ったチャットサーバでは、epoll_wait()後のfor(){}が長くなり、読みにくいものになっていました。そこでイベント監視を少し一般化して裏でepollを呼ぶような仕組みを作りたくなりました。話がややこしいので結論だけ書いておくと、 epoll_data_t dataのユーザ定義のポインタに関数ポインタが混じった構造体を代入すると簡潔にアプリケーション側が書けそう インタレストリストへ追加/削除するような基本的な関数を作ってアプリケーション側から呼ぶと良さそう だねっていう話です。 後述するこれらの良くないであろう点でも書いていますが、あまりいいものではないです。 この記事内で使うコードの一式をGitHubに置いておきます。ヘッダファイルはこの記事内ですべてを載せてるわけではなので使ってみたい場合は以下のリポジトリからどうぞ。 いい感じにするための方針 方向性 いい感じにするには、struct epoll_eventのメンバであるepoll_data_t dataカギになりそうです。epoll_data_tは共用体なので実際に(同時に)使えるメンバは1つだけです。前回のチャットサーバと同様に、void *ptrを使うことを考えていきます。void *ですので任意の型で代入することができます。 typedef union epoll_data { void *ptr; // ユーザ定義のデータへのポインタ int fd; // ファイルディスクリプタ uint32_t u32; // 32ビット整数 uint64_t u64; // 64ビット整数 } epoll_data_t; 前回のチャットサーバで、for(){}が長くなっている原因はIO可能になって処理する内容を関数として作られていないからというのがありますが、何よりもそれらの処理が連結リストのポインタの操作が混じっていることが原因だと思います。そのため、ポインタ操作など面倒くさいものはできるだけ裏でやるようにすると良さそうです。 void*ptrに入れる構造体 void *ptrに代入するものを以下のstruct io_eventのようにしました。...

チャットサーバの簡単な説明 1プロセス1スレッドで動作するチャットサーバを考えていきます。 echoサーバとほぼ同じです。 複数のクライアントが接続できるサーバを考えます。 クライアントからの1回目のwrite()でユーザ名の登録をします。 ユーザ名の登録以外(2回目以降)のwrite()はサーバはそれを受け取った後に、メッセージを他の全クライアントに対して送信します。 サーバはメッセージを受け取った後に以下のフォーマットに従って編集します。 [メッセージの通し番号 発言元のユーザ名 日時] メッセージ プログラムの実行例(というか最終的に出来上がったものの実行例) ※ 今回はサーバがメインです。クライアント側はtelnetをいくつか開いて、それぞれをクライアントと想定しています。 発言元はログイン時、ログアウト時は"server"とし、それ以外の発言はユーザ名を表示しています。 epoll APIについて I/Oの多重化を扱うにはいくつかの方法があるようですが、select()やpoll()よりも扱いやすそうだったため、今回はepoll()を使用しました。 epoll APIはLinux固有の機能であるためLinux上での実行を想定しています。 int epoll_create(int size); epollインスタンスの作成 インタレストリストを空にする 引数 説明 備考 int size 監視対象のファイルディスクリプタ数 sizeは初期化処理のヒントのためであって、sizeを超えた数のファイルディスクリプタの処理も可能(だから適当な値でいいっぽい？) 戻り値の型 説明 int 成功時にファイルディスクリプタ、エラー時に-1 int epoll_ctl(int epfd, int op, int fd, struct epoll_event *ev); インタレストリストの変更(追加、編集、削除)...

とある電子機器を買おうと思って、日本の正規代理店を調べていたのですが、最終的に海外のMouser Electronicsにしました(￥2,000ほど安かった)。それよりも配送そのものが少し不安だったのでまとめておきます。Mouser Electronicsでは配送業者をいくつからか選ぶことができたと思いますが、そもそも個人輸入とをしたことがなかったので冒険をせず、デフォルトで設定されていたUPSで届けてもらうことにしました。 Mouser発注 Mouserで発注手続きをしたのが1/26の22時頃。Mouser日本を経由してMouser本社に注文が行くようなので、発注手続き直後は何も起こらず、次の日(1/27)にMouser日本から以下のメールが届きました。 そして、1/28の夜に届いた発送通知がこれです。UPSのトラッキングができるページのURLが添付されていました。 ロケーション 日付 現地時刻 説明 TOKYO, JP 2021/02/02 04:00 PM 配達済み Chuo-Ku, Japan 2021/02/01 09:00 AM お客様の荷物は弊社施設で処理されました / 荷物は配達先都市のUPS施設へ転送されました。 Tokyo, Japan 2021/01/31 10:10 PM 施設を出発 Tokyo, Japan 2021/01/31 08:29 PM 空港上屋スキャン（輸入） Tokyo, Japan 2021/01/31 06:00 PM 荷物は地元エージェントに引き渡され、配達が手配されました。 Tokyo, Japan 2021/01/30 10:51 PM この出荷に関連付けられているすべての荷物が到着するまで留め置かれます。 Tokyo, Japan 2021/01/30 10:15 PM この出荷に関連付けられているすべての荷物が到着するまで留め置かれます。 Tokyo, Japan 2021/01/30 12:58 PM ウエアハウススキャン（在庫スキャン） Tokyo, Japan 2021/01/30 12:57 PM 空港上屋スキャン（輸入） Narita, Japan 2021/01/30 11:30 AM 施設を出発 Narita, Japan 2021/01/30 11:12 AM 施設に到着 Anchorage, AK, United States 2021/01/29 09:24 AM 施設を出発 Anchorage, AK, United States 2021/01/29 07:17 AM 施設に到着 Louisville, KY, United States 2021/01/29 04:32 AM 施設を出発 Louisville, KY, United States 2021/01/28 11:54 PM 施設に到着 DFW Airport, TX, United States 2021/01/28 08:58 PM 施設を出発 DFW Airport, TX, United States 2021/01/28 07:01 PM 発地国センタースキャン United States 2021/01/28 07:24 PM 荷送人がラベルを作成しましたが、UPSはまだ荷物を受領していません。 ヤマト運輸 通関後はヤマト運輸に引き渡されたみたいです。UPSの配送状況がずっと「運送中」だったので気になり、カスタマーサポートに電話してみてようやくわかりました。ほぼ1週間かかったとはいえ、無事に届いてよかったです。

授業でPygameを触り、グループワーク時にタイピングゲームを作ったので、その時に面倒だったテキスト入力の備忘録。 Pygame 1.9.5(SDL2.0.0)以降のテキスト入力 Pygame1.9.5以降、新たなイベントが加わり、テキスト入力が比較的楽になったようです(多分)。とはいえ、Pygameの日本語のドキュメントにそれがまだ載ってない上に、公式のテキスト入力のサンプル(この記事の執筆時の最新コミット)も分かりづらかったので、改めて書くことにしました。テキスト入力系で追加されたのは、TEXTINPUTとTEXTEDITINGの2つです。TEXTINPUTは直接入力モード時に受け取るイベント、TEXTEDITINGがIMEを使っている時に受け取るイベントらしいです。また、SDLのバグの関係で、IMEの予測変換は使えないので今回はそれを扱っていません。 プログラム ライブラリ化したものを上げておきました。ご活用ください。 以下がテキストの処理をするロジック(text.py) from typing import List class Text: """ PygameのINPUT、EDITINGイベントで使うクラス カーソル操作や文字列処理に使う """ def __init__(self) -> None: self.text = ["|"] # 入力されたテキストを格納していく変数 self.editing: List[str] = [] # 全角の文字編集中(変換前)の文字を格納するための変数 self.is_editing = False # 編集中文字列の有無(全角入力時に使用) self.cursor_pos = 0 # 文字入力のカーソル(パイプ|)の位置 def __str__(self) -> str: """self.textリストを文字列にして返す""" return "".join(self.text) def edit(self, text: str, editing_cursor_pos: int) -> str: """ edit(編集中)であるときに呼ばれるメソッド 全角かつ漢字変換前の確定していないときに呼ばれる """ if text: # テキストがあるなら self....