はてなブックマーク

はじめに 以前、FPGAを始めるときの壁 というのを書かせて頂きました。 また最近、CPU や GPU についても幾つか個人的意見を書かせて頂きました。 今日は、今のところ私が最も熱を入れている FPGA について私見を書いてみたいと思います。 FPGAの原理と構成 オーム社Amazon FPGA に対する誤解 今、特に GPU などで AI に取り組んでいる方々が「FPGAというデバイスがあるらしい」と興味を持ってこの分野の門をたたいてくださる機会が増えているように思います。 一方で、高価なFPGAボードを買ってきて、ものすごく苦労してベンダーの出しているツール(AI開発ツール含む)を覚え、慣れない難しいプログラムのデバッグに翻弄され、GPU の 10倍も100倍も苦労して作った挙句、GPU の 1/10 も性能が出ず、性能も電力もコストもリアルタイム性すらGPUに負け、いいとこなしで「

はじめに 最近 FPGA をやっているとよく GPU と比べられるという事が起こります。 本来の FPGA の得意分野(通信処理とか画像信号処理とか)を考えると、不思議な感じもするのですが、逆に FPGA が汎用計算機と比較されてしまうぐらい守備範囲を広げているとも考えられますので、喜ばしいことです。 FPGA との比較は後に回して、まずは どうしてCPUに対してGPUは高性能になれたのか？ について考えてみたいと思います。 HPC は一旦おいていて、コンシューマでも手の届くレンジで最新のものとして GeForce RTX 50 series を眺めていたのですが、TSMC 4N での製造でダイサイズが 16.9 ～ 750mm2 までラインナップがあり、CUDAコア数が 2,560 ～ 21,760、TensorCore も含めた演算性能だと 13.2 ～ 104.8 TFLOPS(FP

はじめに 例によって当事者でもない人間が感想を書く素人考察ポエムです。 先日 こんな 記事を書き、その中で 「 このあたりで１命令で出来ること自体を複雑にするかシンプルにするかでCISC/RISC論争とかがあった気もしますが、今となってはあまり本質ではないのでおいておきます」と、バッサリと話をスキップしたので少しだけ回収しておきたいと思います。 なぜ本質ではないと言ったかというと、先日の記事の趣旨は「演算器の並列稼働率」にフォーカスしたものであり、CISC/RISC という「命令デコーダの効率」に関わる問題はそこで取り上げるべきではないと考えたからです。 事実、RISC の成功例だったはずの ARM は Thumb2 命令以降も複雑化を続けて十分 CISC っぽさを持っていますし、CISC の代表格の x86 もいつの間にやらRISC風の 内部 μ-OPs に変換して実行するようになってい

はじめに 我々プログラマは CPU/GPU/NPU/FPGA なんかを特性に合わせて選択しながらプログラミングすることになっているわけですが、AI以降、CPU以外のプロセッサの台頭が著しいですので、今更ながら基本となる CPU をもう一度眺めてみようという書きながら考えているポエムです。 当然ながら私はCPUユーザーではあれど、CPU設計者ではありませんので、ユーザー視点から好き勝手レビューするという話なので、素人考察になるわけですが、マサカリ投げずにお付き合いください(笑) CPU の進化の歴史を覗いてみる 4004 からのCPU の歴史を眺めてものすごく大雑把な感想を述べると １命令の実行時間を縮めるのに腐心していた時代(CPI縮小＆周波数向上) 一度に実行できる命令を増やすのに腐心してきた時代(IPC拡大＆コア数増加) の２つの時代に分けられる気がします。 ここで CPI(Clock

はじめに 今回はコールセンターのたらい回しの話に絡めた、ポエムと言うか駄文回です。 私はテクノロジーというものは人と人とのコミュニケーションを円滑にし、お互いを幸せにすべきものであろうと思っています。 昨今、ChatGPT はじめ、高度なAIの出現で、人と人のコミュニケーションの間に AI を介在させてはどうか、というようなアイデアは多々聞くようになり、しばし技術者同士の雑談の中で星新一の「肩の上の秘書」の話が飛び出したりもしています。 私もかなり昔、ボッコちゃんというの短編集の中の１話としてで読んだ記憶があります。 ボッコちゃん (新潮文庫) 作者:新一, 星新潮社Amazon たしか、セールスマンと客の間でAI的ポジションの肩の上のインコが本音と建て前を変換＆通訳(というか取り次ぎ)してくれるというお話だったかと思います。 まさに今のAIを思わせるお話で、星新一さんの先見の明はすごいな

FPGAをはじめてみたい 「FPGAという何やら面白いものがあるらしくて、使うとすごい計算やいろいろなデバイス制御ができるらしい。」 と、興味を持って頂ける方はそれなりにいらっしゃるのではないでしょうか？ 早速なんらかのHDLなる言語を勉強し、例えば SystemVerilog を少し勉強すれば下記のようなプログラムを書くことが出来ます。 入力ポート a,b から入ってくるデータをクロックサイクル毎に加算してc に出力するロジックのソースです。 module add ( input logic reset, input logic clk, input logic [31:0] a, input logic [31:0] b, output logic [31:0] c ); always_ff @( posedge clk ) begin if ( reset ) begin c <=

はじめに 先般 MN-Ccore Challenge なるものが開催され、私もスキマ時間に気分転換的にちょこちょこ挑戦していたのですが(本業関係者への言い訳)、とても面白いアーキテクチャだなと思いました(順位はまあその力及ばず微妙な感じでしたが)。 普段 FPGAプログラミングが多い私ですが、いろいろ新しい観点で脳に刺激を頂きました。 今更私なんかが考察する余地もない気はしますが、折角なのでプログラミングではなく、プロセッサアーキの方を少しだけ感想程度に記録しておければと思います。 いろいろ資料も公式に公開されていますし、コンテストも終わったようなので(実は終了日を勘違いしていました)、安心してあれこれと自分用の勉強の教材にして楽しませて頂きたいなと思います。 なお、ほんとに素人考察なので、あんまりマサカリは投げないでおいてあげてください(言い訳)。 どんな構成なのか 最初に「ソフトウェア

GDDR について もともとGPGPUはGPUであり、GPUはグラフィックスボードであります。 グラフィックスボードは、DVIとかHDMIとかDisplayPort を備え、60fps などで毎フレーム画像を生成＆出力するものですが、そうするとゲームなどではその fps に対して、例えば 60fps であれば 16.6ms の時間で読みだせる分量だけのテクスチャなどを絵作りに使えることになります。昨今ではマルチパスレンダリングも当たり前に行われていますので、１枚の絵を作るためにメモリ上での描画作業は何度も繰り返されます。 つまり１枚の絵を、より高精細で複雑にしようとするととにもかくにも大量のバス帯域が無いとはじまりません。 逆に、1フレーム時間で読みだせない容量があっても、それは別のシーンの描画の為の準備的なデータを置いておくことにしか使えませんので、やはり容量より帯域が優先されがちです。

発表資料 本日TOPPERS開発者会議2021にてLTで参加させて頂きました。 RTOSの具体的なお試しは殆ど進んでなかったので、かなり「こうできたらいいなぁ」レベルのお話になってしまいましたが、楽しく参加させていただきました。 資料を下記に公開しておきます。 Rust で RTOS を考える from ryuz88 www.slideshare.net Rust関連の書籍の著者さん方も参加されており、私なんかが発表してよかったのかはわかりませんが、組み込みでは今後伸びてくる言語と思われますのでますますの発展を期待したいです。 ひとまず、ZynqMP で Rust 使う仲間が増えると嬉しいなと思います。 github 今回の関連コードは下記にて開発中です。 https://github.com/ryuz/pudding-rtos Slack 便利ですね あと今回も含めて Slack 便利だ

はじめに 今更ながら@ikwzm氏の「一体いつから FPGA はハードウェアだと錯覚していた？」に感化されて、私なりにFPGA上で行うソフトウェア開発がどういうものかというのを再考してみたいと思います。 前置きですが、あくまですべて私見ですので、こういう風に考えてる人もいますよ、という駄文です。 ハードウェアとソフトウェア どこのどなたが言っていたのか忘れましたが「ハンマーで壊せるものがハードウェアで、そうでないものがソフトウェアだ」という考え方に基づけば、FPGAにダウンロードする0と1の並びの「情報」を開発しているわけでして、FPGA開発は疑いようもなくソフトウェア開発だと思っています。 チップという物理的なものを開発するのではなく、チップという物理的なものはXilinxなりIntelなりの製品が既にそこにある前提での開発スタートになるからです。 一方で、先の記事で述べられているように