ラベル FPGA の投稿を表示しています。 すべての投稿を表示
ラベル FPGA の投稿を表示しています。 すべての投稿を表示

PetaLinuxで手軽にZynq(MicroZed)用カスタムLinuxを作る

2017年1月25日水曜日

PetaLinuxとは何なのか

私の現時点でのPetaLinux認識は次のとおりです。
Xilinxが提供しているカスタムLinux構成管理ツール兼カーネル・rootfsビルダー。標準のYocto Linux向けビルドツールチェーンに手を加えてXilinx SoC向けの各種コンフィグを追加したり、bitbakeコマンド体系をラップして扱ってくれたり、Yocto向けの適切なレシピ管理あたりまでやってくれるもの。Vivadoが生成するハードウェア定義を利用し、当該ハードウェア向けLinux一式の構築から各種媒体への一次デプロイメントまである程度カバーする。

PetaLinuxの基本をざっと把握する

Xilinxのドキュメントをひたすら読んでいくのが良いです。
私はUG980→1156→1157→1144という順でざっと読んでいきました。順序はドキュメント一覧(https://www.xilinx.com/support/documentation-navigation/design-hubs/dh0016-petalinux-tools-hub.html)を眺めてクイックスタートガイド→ワークフローのチュートリアル→コマンドリファレンス→リファレンスガイドと適当に決めましたが、結果的に割と良い順だったと思うのでおすすめです。
本エントリの最後におまけとして、私が読んでいった中でのメモを簡単に残しています。

PetaLinuxのビルド環境を作る

ホスト(コンパイル)環境にはUbuntu 16.04を利用します。古いバージョンのPetaLinux SDKは古いバージョンのUbuntu上で利用したほうが良さそうですが、基本的に最新版を使っていきたいのでこのようにしました。

必要なパッケージの導入

今回ビルドに使った環境は元々Yocto Linuxのビルド環境を構築していたので、その際に導入したパッケージを下敷きにしています。Yocto Project を使用して組み込み用のカスタム Linux ディストリビューションを作成するの「リスト 3. Ubuntu で必要なパッケージのインストール」を最初に導入しました。ものによっては不要なはずです。その後はUG1144の表1-3に従って不足分を補うのが良いかと思います。
PetaLinuxのSDKインストール時点で最低限のパッケージが不足していればハネられるのですが、アーカイブ(5GB超、バージョンによっては7GB)のチェックサム検証→展開→...の後に依存関係チェックがおこなわれるので、失敗すると最初からやり直しで時間がかかって厳しいです。
後述する事情によりPetaLinux 2016.2を使う必要が生じたので、
AR# 67503 / 2016.2 PetaLinux - PetaLinux インストールで 32 ビット互換ライブラリのインストールが求められる
2016.1 および 2016.2 バージョンの Petalinux インストールに対しては、32 ビット依存ライブラリが必要となります。
ということで、通常インストール状態のUbuntu 16.04でそのままビルドを通すのは無理です。このページも参考にしつついくつかパッケージを導入しました。なお、Ubuntu 16.04ではここに書かれているlib32bz2-1.0自体存在しないようで、ビルド上も問題は無かったので多分不要です。
また、
sudo apt-get install bc lib32ncurses5 lib32tinfo5
として追加いくつかインストールしておきました。
さもないと次のようなエラーで苦しむことになります。
[INFO ] build zynq_fsbl
[ERROR] make[3]: *** [xqspips.o] Error 1
[ERROR] make[2]: *** [ps7_cortexa9_0/libsrc/qspips_v3_3/src/make.libs] Error 2
[ERROR] make[1]: *** [build] Error 255

dash村からの脱出

PetaLinuxは/bin/shがbashであることを期待するので、dashをbashに戻す作業が必要です。手元ではsudo dpkg-reconfigure dashを使いました。

ロケールをゴリッと変更する

日本語ロケールで無邪気にPetaLinuxビルドを進めると次のようなエラーで終了します。
[INFO ] install linux/kernel
[ERROR] ERROR: Invalid ELF file '/home/muo/mz_7010_2016_2/images/linux/vmlinux'
[ERROR] make[1]: *** [package-subsystem-FIT] Error 255
https://forums.xilinx.com/t5/Embedded-Linux/Petalinux-2015-2-Invalid-ELF-file-vmlinux/td-p/659064
petalinux-build parses the output of readelf to check generated kernel format.
うわぁぁ…。ひどい。
特に必要のない日本語ロケールを、macOSからSSHでログインした場合にUTF8系ロケールが求められる警告メッセージがうるさいという理由でlocale-genやっていた結果がこれなので報われない。例によってMacからSSHだとアレしてソレみたいな問題があるので、http://yano3.hatenablog.jp/entry/2012/11/25/234244の結果を丸ごと~/.bashrcに書きました(もちろん~/.bash_profileでも良いでしょう)。あとはSSH入り直してok。

PetaLinux SDKを導入する

PetaLinux SDKはhttps://www.xilinx.com/support/download/index.html/content/xilinx/en/downloadNav/embedded-design-tools/2016-4.htmlこのあたりから入手しますが、Xilinx SDKとは違ってWebインストーラがありません。
つまり、v2016.4の場合は8.34GBをごっそりダウンロードしてインストールするほかありません。
後述しますが、MicroZedをターゲットボードとする場合にはv2016.4をインストールしてはいけません。2016.2を選択する必要があります。2016.2はたった5.5GBで済みます、よかったですね(なお私は両方ダウンロードしました)。
PetaLinuxで諸々のLinuxイメージを生成する範囲ではXilinx SDK不要だと思いますが、必要そうならインストールしましょう。

PetaLinuxでMicroZed向けのLinux一式を構築する

事前に読んでおいたドキュメントに従ってBSPからプロジェクトを生成します。
MicroZedのBSPはhttp://zedboard.org/support/design/1519/10でひっそりと配布されているので入手します(Avnetの会員登録が必要)。MicroZed 7010/7020ともに最新版は2016.2用、と書かれています。

PetaLinuxプロジェクトを生成する

$ petalinux-create -t project -s mz_7010_2016_2.bsp
これだけですね。mz_7010_2016_2というディレクトリにプロジェクトが生成されます。この名前は変更して構わないのかな…。

PetaLinuxをひとまずビルドす・・・る?

まずはビルドしてみましょう。
$ petalinux-build
WARNING: Your PetaLinux project was last modified by PetaLinux SDK version "2016.2",
WARNING: however, you are using PetaLinux SDK version "2016.3".
Please input "y" to continue. Otherwise it will exit![n]
おう2016.3なんてSDKしらねーけど大丈夫か?と聞かれます*1。力強くyと返します。
y
INFO: Checking component...
ERROR: Cannot find XLNX__4___4 of linux-kernel
INFO: Generating make files and build linux
INFO: Generating make files for the subcomponents of linux
ERROR: Cannot find XLNX__4___4 of linux-kernel
ERROR: Failed to get subcomponents for linux
ERROR: Failed to build linux! Failed to get makefiles for subcomponents of linux!
全然大丈夫じゃありませんでした。
これはどうあがいてもPetaLinux SDK 2016.3以上でビルドを通すのは無理なので、PetaLinux SDK 2016.2をインストールしました。PetaLinux SDKは相当巨大でダウンロードから面倒なのにやり直しなの大変苦しいです。
ZedboardはPetaLinux SDKの各バージョンローンチに合わせてhttps://www.xilinx.com/support/download/index.html/content/xilinx/en/downloadNav/embedded-design-tools/2016-4.htmlでBSPを配布してもらえるのにMicroZedには無い…。仕方ない、売れてない?のが悪いんや。大人はみんなそうや… 正論いやいいと思ってやがる…
ということで、実はhttps://forums.xilinx.com/t5/Embedded-Development-Tools/Error-when-creating-first-SDK-project-after-installation-of/td-p/643937に、なんやビルドが失敗して辛いという話がありまして、このあたりを参考にして適宜パッケージを導入しましょう。
[*1] ちなみに最新版の2016.4を使わず2016.3を使っていたのは、SDSoCの最新が2016.3でそれにあわせたためです

PetaLinux SDK 2016.2でMicroZed用Linuxをビルドする

気を取り直してもう一度。念のためさきのプロジェクトディレクトリは削除してBSPから生成し直し、ビルドコマンドを実行します。
$ petalinux-build
今度は通りました。最後にTFTP用(ネットワークブート用かな)のファイル書き出しに失敗した旨のエラーが出るので、指定ディレクトリをsudo mkdirで掘っておくと次回から安心ですね。なお、あっさり通った風に書いていますが、実際は本エントリの序盤にまとめた依存パッケージやらロケールやらの問題でずいぶん遠回りをしました。
$ petalinux-boot --qemu ...
でQEMU上での実行を確認した感じ、ざっくりいけてそうです。rootで入ってhaltまで確認しました。
halt後にQEMUは自動終了してくれない(内部管理コマンドがあった気がしますが覚えていません)ので、tmuxで専用シェルを立ち上げて実行し、終わったら画面1枚丸ごと閉じる運用をしています。

ビルドするLinuxに含めるパッケージをカスタマイズする

カスタムしてこそYocto Linux、簡単にカスタムできてこそPetaLinuxです。
petalinux-configコマンドを実行して表示されるメニューは階層化されていますが、サブメニュー内の詳細設定、たとえばrootfsに含めるパッケージの選択はpetalinux-config -c rootfsは-c rootfsで明示しないと入れません。
全体コンフィグを抜けると後処理諸々(FSBL用のBSP生成とか)が走るので時間かかります。なお、-c rootfsで実行した画面を抜けると無言で時間かかるのでkill -KILLしそうになりますが、1分程度待っていればちゃんと抜けるので我慢しましょう。
さて、手元ではQtのベースパッケージとexamples、fontあたりを含めてビルドしてみました。
Qt込みにするとrootfs.cpioが順当に膨らみます。
-rw-rw-r--  1 muo  staff  11540480  1 14 22:57 rootfs.cpio
-rw-rw-r--  1 muo  staff  73434112  1 15 07:10 rootfs.cpio
導入するパッケージ量にともなって肥大化するrootfsをどこに置くかは悩ましい問題です。SDカード上の別パーティションへ書き出す筋がスタンドアロン動作面で良いのですが、開発中は何かと面倒です。MicroZedが安定してネットワークにつながる状態ではNFSもよさそうですが、メモリを1GB積んでいるのがこのボードの良いところでもあるので、ひとまず100MBぐらいまではinitramfsでいくつもりです。

PetaLinuxに関する所感

よさそうです。Yoctoのbitbakeを直接触るよりもエラー出力が少なめな分、トラブルシュートをやりづらいと感じますが、間口を広くしたりプロジェクト内での部分オーバーラップしつつの分業体制をうまく回していくのに向いている設計だと感じました。
MicroZedのBSPが2016.2までしか提供されていない点については、差し当たり大きな問題がないこと、そろそろMPSoC時代の安価な評価ボードも出てくるであろうことから、そんなもんかなと思っています。2013年発売のボードですし、あと1年ぐらい色々と使い倒して乗り換えるぐらいのノリでいればいいと思います。

各種の関連FAQ

PetaLinuxをさらさらと使っていく上で読んだFAQエントリを簡単にまとめておきます。何かの役に立つかもしれません。

ツールチェーンの差し替え

AR# 59553 / PetaLinux 2013.10 - Can I Use A Cross-Compiler Other Than the Built-In CodeSourcery Toolsを読むと
I would like to use a cross-compiler other than the default toolchain included with PetaLinux.  Is this possible?
に対して、環境変数指定で内部のツールチェーンを部分的に差し替えられると書いています*2
[*2] そういえばhttp://www.wiki.xilinx.com/Install+Xilinx+ToolsでZynq 7000用に紹介されているツールチェーン、Code Sourcery版とlinaro版などの差が分かっていないので、そのうち調べようと思います。単純にsoftfpuとhardfpu利用の差だけなのかな

Linuxを指定Gitリポジトリからビルドする方法

Xilinxのlinux-xlnxリポジトリから派生させて手を加えたGitリポジトリのコードを使いたい場合、などの話だと思います。
AR# 60406を読むと
PetaLinux 2013.10 and later support the ability to retrieve source code for the Linux kernel or UBOOT from a Git repository.  How do I use this feature in my design workflow?
に対してpetalinux-configで実行するメニュー内での操作方法が書かれています。

PetaLinuxの生成するデバイスツリーファイル(DTS/DTSI)にイーサネットのPHYやMDIOの情報が含まれない

AR# 61117 / PetaLinux - My System Device Tree DTS Does Not Include Ethernet PHY Information
質問はタイトルどおりなので省略し、これに対する答えが
Ethernet PHY information is board level and board-specific information that PetaLinux does not have access to without user input.
ということなんだけど、イマイチ腑に落ちてない…。system-top.dtsもPetaLinuxが生成していけない理由がないように思う(PetaLinuxのプロジェクト生成時点でBSPを読み込んでいるので、ターゲットボードもそのハードウェア構成も分かっているはず)し、petalinux-configの設定画面中にもPHY設定あったような?見間違いかもしれないので、そのうちこのあたりに触れる段になったらもう一度確認してみます。

PetaLinux関連のUGめぐり読みメモ

よく分かっていない状態から段々と全容が掴めていくまでが見て取れるメモです。

UG980(Board Bringup Guide)

  • 諸々ビルドして、bitstream生成も込みでボード上で起動するまでが書いてある
  • おまけとしてシステム構成のコンフィグ方法も書いてあるっぽいのが良い
  • prerequisites部分にシリアルコンソール用のUARTは必須とあるけど本当かなこれ
  • Vivadoからexport hardwareでhardware description fileができる
  • PetaLinux toolsから.dtsやu-bootイメージを生成できる
  • petalinux-createでtemplateにできるのは、ドキュメント上zynqとmicroblazeだけだった
    • 今ならMPSoCとか増えてるんだろうけど、ドキュメントがちょい古い
  • petalinux-createは-t projectでプロジェクト作れるけど、-t appsならアプリ作れる
    • 想定よりも広範囲かな、と思ったけれど ビットストリーム生成まではみ出してはいかないので想定のうち
  • --get-hw-descriptionという不思議オプションがある
    • これ毎回mz7010指定するやつ?
  • petalinux-configからシステム構成設定へと進める
    • 用途とても広い: "If you want to do advanced PetaLinux project configurations such as enabling some kernel options, modifying
the default flash partition table settings and so on, or you just want to view the current configuration, you can run petalinux-config to do so."* petalinux-config -c kernelでカーネルのみの設定を開けるらしい** 同-c rootfsでrootfsをいじれる** ここに追加パッケージ入れるとかやれそうな気がするけど、そこらは直接Yoctoのレイヤを触る感じなのかな* その後にpetalinux-buildを走らせるとLinux本体(つまりカーネル)とrootfsをビルドしてくれるとある* Zynqの場合、petalinux-package --boot ...を使って.binフォーマットにまとめると** 先日触ったXilinx向けYoctoの構成でも、このへんまでbitbake petalnux-buildでやってくれてる気がする。用途の切り分けがよくわからない*** 気持ちの話をすると、Yoctoのbitbake系とPetaLinux SDKでのpetalinux-*コマンド群はiterativeに混ぜて使えてほしい* autoconfigに期待するやつ** "If a component is selected to enable autoconfig, when petailnux-config is run, its config files will be auto updated based on the top system level settings. ... device tree autoconfig is enabled, when petalinux-config runs, the kernel config file <project-root>/subsystems/linux/configs/kernel/config will be auto updated with the top system level settings."とあって期待を持てる*** autoconfigどれぐらい選択肢あるんだろう。頑張ってほしい

UG1156(Workflow Tutorial)

  • "1-1: Design Flow Overview"部分がとてもきれいに役割分担と共にまとまっていて良い。そのまま抜粋
    • Design Flow Step Tool / Workflow
    • Hardware Platform Creation Vivado
    • Create PetaLinux Project
      • petalinux-create -t project
    • Initialize PetaLinux Project
      • petalinux-config --get-hw-description
    • Configure System-Level Options
      • petalinux-config
    • Create User Components
      • petalinux-create -t COMPONENT
    • Configure the Linux Kernel
      • petalinux-config -c kernel
    • Configure the Root Filesystem
      • petalinux-config -c rootfs
    • Build the System
      • petalinux-build
    • Deploy the System
      • petalinux-package
    • Test the System
      • petalinux-boot
  • 気持ち伝わってきたので、あとは全力で飛ばし読み
    • 配布されてるボード用BSPもpetalinux-buildでビルドしてみるところからスタートするのが良さそう
      • Makefileあるけど、直接makeじゃなかったんや…
  • "This step will generate a device tree DTB file, a first stage bootloader (if selected), U-Boot, the Linux kernel, and a root filesystem image. Finally, it will generate the necessary boot images."
    • 大事
    • これでimages/.../image.ubが出て来る。これはFITイメージ?というものらしい
  • リビルドしたらQEMUで試そうな、という優しさ
  • そしてこういう丁寧版も書いてある
    • 1. Change to your project directory and boot the prebuilt linux kernel image: $ petalinux-boot --qemu --prebuilt 3
    • The --qemu option tells petalinux-boot to boot QEMU, instead of real hardware via JTAG, and the --prebuilt 3 boots the linux kernel.
  • デフォルトのログイン情報はID: root、PW: root
    • 意外とハマるやつだ
  • petalinux-bootだけはWindows環境から叩けるようにしておかないと困らない??と思うんだけど、ひょっとすると無いのかこれ
    • JTAGアクセス部分だけLinuxからやるとか微妙に不毛な気がするな...?
  • QEMUの章
    • The --kernel option is used to boot the project’s most recently built Linux image. For Microblaze, it is "<plnx-proj-root>/images/linux/image.elf". For Zynq, it is "<plnx-proj-root>/images/ linux/zImage".
      • なるほど。微妙にわかりづらい挙動やな
  • p.29にちょっと面白いのがあった: "Anatomy of a PetaLinux Project"
  • 続いてp.30。Yoctoだ!!!! となった
  • CAUTION! "<plnx-proj-root>/build/" is automatically generated. Do not manually edit it. Contents in this directory will get updated when you run petalinux-config or petalinux-build. "<plnx-proj-root>/images/" is automatically generated and managed. Files in this directory will get updated when you run petalinux-build.
    • あっ、そういうことなの
    • 若干きな臭い? 個別のパッケージ管理などはあくまでもbuild/conf/以下のファイルで制御しろということか、それすらも触るなということなのか
      • petalinux-configでインストールするrpmパッケージを選べるようになってたら特に文句はないんだけど、どこまで細かくいじれるんだろう(注: その後、petalinux-createで割となんとかなりそうな気がしてきた)
  • p.31-32にも各構成ファイルの役割が書かれていて、そのうち戻ってくるとお得な感じがする

UG1157(PetaLinux Command Line / Reference)

  • 単純にコマンドのリファレンスだと思う
    • 全体の流れが分かってきているので、流し読みぐらいで良いはず
  • petalinux-config -c rootfsからパッケージ選択いける気がしてきた
    • https://www.beyond-circuits.com/wordpress/tutorial/tutorial25/ このへんのスクショ見る感じ、パッケージ選択がある
  • あと問題は、手元の~/build/環境に放り込んであるrecipesをpetalinux-config系にどうやって取り込むか
    • 環境変数設定(setupsdk?)だけでいい感じにそっちを見に行ってくれるのならとても嬉しい
  • bitbake petalinux-imageとかpetalinux-*とついてるレシピ?が何をやってるのか気になるので読もう
    • リポジトリはそこらに生えてるはずなので読みに行けるはず
    • 逆に、petalinux-*の無印コマンドを呼んだ際にbitbakeを内部で呼んでるオチだったらシャンシャンとなる
  • petalinux-create -t COMPONENTというのが出てきた
    • なんだろうこれ
  • "The petalinux-create -t COMPONENT command allows you to create various components within the specified PetaLinux project. These components can then be selectively included or excluded from the final system by toggling them using the petalinux-config -c rootfs workflow. There are no component-specific options for the petalinux-create -t modules workflows."
    • つまり例の.bbファイル相当のもの+そのカタログ管理用ラッパーなのかな
  • 例示
    • Create an application component that is enabled in the root filesystem.
    • $ petalinux-create -t apps -n <NAME> --enable
    • Create a new install-only application component. In this flow, nothing is compiled.
    • $ petalinux-create -t apps -n <NAME> --template install
  • ふーむ
  • ATFはARM Trusted Firmwareということで例のsecure-bootやらTrustZoneやらの系統かー
  • Yoctoへの言及
    • "Introduction: PetaLinux is a development and build environment which automates many of the tasks required to boot embedded Linux on Xilinx AP SoC’s and FPGA’s. It uses Yocto Project underneath for configuring and building various components."
      • のっけにあった
    • petalinux-buildにもあった
      • This tool uses the Yocto Project underneath. Whenever petalinux-build is invoked, it internally calls bitbake. While the tool provides a single workflow, the specifics of its operation can be dictated via the petalinux-build -c and petalinux-build -x options.
      • "-x, --execute"の意
        • Execute specified build step. All yocto tasks can be passed through this option. To get all tasks of a component use “listtasks”. This is optional.
      • なるほど、ようやっと全容見えてきた
      • となると、PetaLinuxのrepoで認識できる形でYoctoの一式を維持しようとすると、PetaLinux側でソースのフェッチから何からやらなきゃいかんのかな? それともsetupsdkでつないでくれる(build/で全部やる)のか
    • まずはpetalinux-configからのワークフローを試して慣れていくのが近道な気がする

UG1144(Reference Guide)

  • Yoctoとの絡みもちょいちょい書いてあるリファレンス
  • 最終的にこれを片手にやっていく感じなのかな
  • bitbakeもちょいちょい露出してるけど、bblayersが出てこないので微妙にこれだけだと不足しそう
  • p.50あたりにprebuilt modulesの追加方法があった
    • 要は*.bbのレシピ追加と組み込みの話なので、これが大事
    • $ petalinux-create -t apps --template install --name mymodule --enable
    • これでいい感じにしてくれるのか、なるほど
    • --template installを与えずにこれやるとCで新規アプリを書いて組み込むテンプレートが生成される
      • こんなんわかるかー!となる
      • autoconfのテンプレートもあって、まあ一貫してはいる..
  • "CAUTION! You can delete the app directory if it is no longer required. Apart from deleting the app directory, you have to remove the line: IMAGE_INSTALL_append= “myapp” from <plnx-proj-root>/project-spec/meta-plnx-generated/recipes-core/images/petalinux-image.bbappend. Deleting the directory by keeping the mentioned line will throw an error."
    • これでbblayersを使ってなくても問題ない理由が明らかになった
  • -t app、-t moduleとあって、それぞれテンプレートがちょいちょいあるので、使い分けは実際やるときに読み直す
  • 原則、-t app --template installのものはビルド済みのやつ(*.ko)を単純に取り込むだけっぽい
    • もちろん他のことに使えんではないだろうけど、役割分けてる
  • p.20からのHardware Import部分もとても大事
    • ハードウェアプラットフォームと.hdfを使うとある
    • これ、BSPとの絡みはどうするんだろう
  • SDSoCからPetaLinuxへ必要なものを渡してビルド、とはならないはずなので注意する
    • SDSoCはあくまでも最終地点
    • カーネルとrootfsの両方を作り上げてSDカードへ書き込める状態にして、それをSDSoC側で設定して使う
    • なんならBSPはSDSoC側で頑張るイメージもあるんだけど、どうだろう
    • 結局bitstream差し替えの都合上、BOOT.binはSDSoCが書き換えるあるいは作り直す認識でいいのかな
    • カーネルとrootfsだけがPetaLinuxからの成果物として、その先は別フロー
    • これまでプラットフォームをエクスポートしてせっせとPetaLinux環境で頑張っていたのが順序逆転して、下回りで必要なものやアプリを組み込んだカーネル・rootfsを先にPetaLinuxで作り、メインアプリをせっせとその上にSDSoCで構築して動作確認までサクサクやる流れ、と捉えると良さそう
    • BSPの出番は更に前で、PetaLinuxのプロジェクトを作るタイミングで必要か、なるほど

RTLを語る会(12)でChisel 3/FIRRTL+自作HDL試作のLTをしてきた

2016年9月28日水曜日

9/25(日)に秋葉原界隈でおこなわれた「RTLを語る会(12)」に参加し、ついでにLTをしてきたので補足などをまとめます。

RTLを語る会。

RTLを語る会(12) 〜Vivado HLS GO〜です。参加するのは2度めで、前回「どえらく濃い場に来てしまったぞ・・・」と感じた記憶があります。
今回もVivado HLS(Xilinxの高位合成系)を使い倒して得られた諸々の話が展開されていて「貴重な場だ・・・」という感想でした(KONMAI感)。資料が公開されている分についてはイベント資料一覧で確認できます。一部の資料は公開されていません(これも大変得るものが多いセッションで、現地参加して本当によかったと思いました)。

LTをしてきた

LTとしては長めの15分枠にて、RTLコードを生成するための(alt-)HDLであるChisel HDLの簡単な紹介とその新バージョン(Chisel 3)に関する話をしました。色々と端折りましたが、実際には18分ぐらい喋っていた気がします。

Chiselに関してはこのblogでも既に(告知) C90 3日目西a-05abでScala+Chisel入門記事の載った技術書が出ますChiselで開発を始める小冊子(MFT2016配布物)の小改訂版を100円で販売しますで紹介しているのでここでは触れません。Chisel 3とそのバックエンドであるFIRRTLについてこれまであまり言及していないので書きます。

Chisel 3のアーキテクチャ

Chisel 3はChisel 2とほぼ互換性を保った記法を採用していますが、中身の実装が大きく異なります。代表的な違いは、構造のフロントエンドとバックエンドが切り分けられた点です(図1)。
図1 Chisel 3の実行時アーキテクチャ
Chisel 2は実行時に回路情報に基づいた.v/.cppファイルを自前生成し、.cppの場合はそれをコンパイルして開発環境用のネイティブバイナリを生成します。そして生成されたバイナリをDUTとしてChisel側に用意したテストコードと接続してシミュレーション検証をおこないます。
これに対してChisel 3では、バックエンドがFIRRTLというプロジェクトへ切り出されました。Chisel本体が担うのはFIRRTLの生成と、FIRRTLの先で生成されたバイナリとの通信によるシミュレーション検証作業のみへと軽減されます。
Chisel 2でマルチクロック利用などの込み入ったコードを書くと、回避の面倒なバグを踏むことが多くあります(代表的なのが#696です)。また、Chisel 2から生成した.cppコードがそもそもコンパイルを通らないケースもあります(マルチクロック利用時にcpp側のスコープ切りがおかしいパターンほか)。
Chisel 3+FIRRTLでは.cppコードの生成がChisel内部からFIRRTL側へ移っただけでなく、生成にVerilator*1を利用するようになりました*2
[*1] Verilatorは高速なHDLシミュレータ兼、HDL→C++コードの生成ユーティリティです。10年以上に渡り粛々と開発が進んでいて脱帽する系です
[*2] このためVerilatorのバージョンへの依存が激しい状態にもなっていますが、そのうち落ち着くはずです

LTのネタパート

割と真面目にChisel 2/3とFIRRTLの話をしたところで本題です。
Chisel 3世代では、バギーでメンテしづらいC++コード生成系を切り離せたことで今後のChiselプロジェクトの見通しがよくなることを期待できる一方、Chiselと同列にあたるFIRRTLのフロントエンドを比較的簡単に作れるようになりました。

Chisel 3の基盤を使ってHDL生成用DSLを自作する話

実は最近、Kindleへ突っ込んでおいたFIRRTLの言語仕様書を空いた時間でせっせと読んでいました。
そして、今回は運良く会場へのまとまった移動時間がありました。そこで「FIRRTLのフロントエンドとなる自前DSLを作ってみよう。C#ターゲットで」と思い立ち、作ってみました。
ここでC#を選択したのは自分が使い慣れているのに加えて、IDEが充実しており「プログラマ負荷の低いHDLを構築できる下地がある」可能性があるためです。なおFIRRTLのフロントエンドとしては、FIRRTL言語仕様に従ったコードを生成する機能があれば最低限の要件を満たせます(これに加えてDUTとの通信・テスト機能などを適宜作り込むことになります)。

FIRRTL#

そして作ったのがFIRRTL#という処理系です。.NET向けのクラスとして書いており、「回路内の単一モジュール定義と、モジュールの入出力ポートでAND/XOR処理をできる」ものです。
つまり、次のコードを書くと・・・
using FirrtlSharp;

namespace FirrtlSharpHalfAdder
{
    class HalfAdder : Module
    {
        public HalfAdder()
        {
            var io = new
            {
                a = new UInt(isOut: false),
                b = new UInt(isOut: false),
                s = new UInt(isOut: true),
                c = new UInt(isOut: true)
            };
            this.io = io;

            io.s.Assign(io.a + io.b);
            io.c.Assign(io.a ^ io.b);
        }
    }

    public class AdderGenerator
    {
        public static void Main()
        {
            FirrtlSharp.Generator.GenerateHDL(new HalfAdder());
        }
    }
}
FIRRTL経由で次のようなVerilog HDLコードを生成できます。
...
`ifdef RANDOMIZE_MEM_INIT
`define RANDOMIZE
`endif

module HalfAdder(
  input   clk,
  input   reset,
  input   io_a,
  input   io_b,
  output  io_s,
  output  io_c
);
  assign io_s = io_a & io_b;
  assign io_c = io_a ^ io_b;
endmodule
module TopHalfAdder(
  input   clk,
  input   reset
);
  wire  halfadder_clk;
  wire  halfadder_reset;
  wire  halfadder_io_a;
...

FIRRTL#、おいしいの?

おいしくありません。
今回はC# 6時点の構文でどの程度直感的かつ柔軟なHDL記法を実現できるか、という検討を重視しました。パッと見で厳しそうだな、と思ったところは案の定厳しいものです。
I/OポートのIDEでのコード補完ぐらいは効きます。I/O内の信号宣言時に個別の型指定をおこなうことで、型検証の道を残しつつ簡便な記法を維持することもできました。
これを育てていけば形になりそうにも見えますが、実際は次のように大きな問題が複数あります。
まず致命的なのが、C#を利用している限り<=を信号の受け渡し用演算子として自然な記法で成立させられないことです。これは演算子のオーバーロードでは解決できない問題で、C#が1;のような記述を許さないためです。
無理やり
  if (io.s <= io.a ^ io.b);
のようなif+空ステートメントの組み合わせでコードを記述できますが、この構文を許容するぐらいなら圧倒的にScalaを学んだほうが生産的です。ちなみに=をオーバーライドすることもできないので、io.s = io.a ^ io.b;という微妙に嫌な構文で妥協することも許されません。delegateをうまく利用すればio.s => io.a ^ io.b;といった記法は可能かもしれませんが、許容しがたい記法なので深く検討していません。
また、C#は構文上の制約としてシンボルに指定できる文字種が少ないため、たとえば<==といったメソッドを作るのも無理筋です(さらに、中置記法もないので自然な形には収められません)。
このあたりを満たす言語を作って、そこからC#コードを生成するという手はなくもないのですがFIRRTLの性質を考えると本末転倒です。

FIRRTL#実装の裏側

名前は.NET向け各種バインディングの慣習に従ってFIRRTL#と付けましたが、大したことはやっていません。
firrtl-sharpにてコードを公開しておきます。C# 6時点の構文でどの程度直感的かつ柔軟な記法を実現できるか、という検討に時間を多く使った結果、FIRRTLコード生成部分は見るも無残な感じになりました。これを拡張してもどこにもたどり着きはしないと思います。他言語でFIRRTL対応DSLを組むために最低限必要な要素が何かを知りたい場合には多少参考になるかもしれません。
今回はC# embedded languageとしてのHDL生成系がコンセプトとしてアリか否かを検討し、可能な範囲で試作してみるというのがメイン目的だったので、目的は満たせました。
当然テストハーネスなどは作っていないので、生成されたHDLの自動テストができるわけでもありません。

まとめ

FIRRTLによってHDL生成系を分離できたのはChiselの将来にとって良さそうで、この先割と良いバランスの立ち位置に落ち着きそう。

クラウドでASICを利用する時代の必読論文が出ていたので紹介する(Bitcoin、Litecoin、H.265動画変換、ディープラーニング用のASIC試作/検討からのあふれる知見:ISCA2016)

2016年8月24日水曜日

どのような論文か

クラウドを構築するデータセンターでのASIC(特定用途向け集積回路)利用が伸びるというのを大前提として(実際、お金に直結するBitcoinではASICマイニングが主流だから当然だよね!と)、業界の流れ分析に始まり各種ワークロードの特性分析から総所有コスト最適化、排熱シミュレーションまでを幅広く扱った論文です。超オススメです。
次のURLから入手できます。
最初にこの論文を読んだ時は、12ページ(参照込みで13ページ)とコンパクトながら怒涛の情報量であったため、大変衝撃を受けました。「特に読むべきポイントは?」と聞かれたら「全部!」と答えたいところですが、せっかくなので本エントリではいくつかポイントを絞って紹介してみます。
ちなみに発表資料内で「今回の研究のために8種類のBitCoinマイナー*1を購入してリバース・エンジニアリングしたよ。サンディエゴへ見においでよ」とスナックに書いていたりします(図1)。本気度がやばいです。
図1 ASIC Clouds Exist Today(ISCA2016での発表資料PDFのp.16より)
[*1] マイニング用のチップ/ボード/クラスタを指している

前提

発表資料のp.4で、今回の話の前提を紹介しています。
コンピューティングがモバイルのSoCとクラウド(データセンター)へ二極化し、デナード則の終焉とダークシリコン問題を意識した設計が必要な時代

クラウドで使われつつあるASIC

データセンターでFPGAを使っている例としてはMicrosoftのProject Catapultや各種HFT(High Frequency Trading)がよく知られています。
いっぽう、ASICの利用(ASIC Cloud)例として論文内ではBitcoinのマイニング専用マシンを主要なものとして紹介しています。プロセス世代としては、当初130/110nmという旧世代プロセスで始まったものの、65nm→55nm→28nm→Intel 22nm/TSMC 16nmプロセスのものへと爆発的に進化していったと紹介されています。
本blogエントリを書いている2016年8月下旬の時点では、クラウドでのASIC利用といえばAlphaGoの李・セドル氏対局でも使われたGoogleのTPU(Tensor Processing Unit)*2が有名です。おそらくこの論文が投稿されたタイミングではTPUが発表されていなかったため、論文内ではカバーされていません。

TCO(総所有コスト)が最低になるポイントを探る

ASIC化にあたってはどれだけの電力と資金を投下してどれだけのパフォーマンスを得るか、という選択をおこないます。ここでは設計上のいくつかのパラメータ設定が重要です。
チップのコア電圧を下げると消費電力を劇的に下げられる反面、稼働可能な最大クロック数も低下します。このため、1チップあたりの処理性能が落ちます。
ある程度コア電圧を下げて1チップあたりの消費電力を削り、その一方でサーバスペースへ大量のチップを実装して適切な通信系を整備することでボード全体の性能を高めることになります。
しかしチップ数を増やすことでインターコネクトが複雑化したり、実装面積が不足してデータセンター内の領域を圧迫してしまっては元も子もありません。
この論文では、なんとこの面の分析をきっちりおこなっています。まず、パフォーマンスあたりのコストと処理あたりのエネルギーという2軸のパレート最適を分析しています(例:図2)。そして、これらの状態群に対して、各パラメータへの適切な重み付けをおこなうことでTCO(総所有コスト)の最適化検討までおこないます。
図2 Bitcoinマイニング用ASICのパレートカーブ(投稿論文PDFのp.19より)
外部メモリへのアクセス性能が重要な場合は、1つの処理チップあたりいくつのDRAMチップを接続するか、などでも性能が変わります。このため動画変換(H.265)のケースでは重要要素として検討されています。
データセンターでのASIC利用の前提は「チップの設計や製造にかかるコストよりも消費電力とファシリティ維持コストのほうが支配的になる」ことですが、その中でも具体的なコスト最適化プランの枠組みが提示されていることの意味は大きいと感じました。

ボードへのチップ配置方法に関する検討

チップの安定稼働にとって熱は敵なので、うまい排熱方法を確立しておく必要があります。
データセンター内では通常、サーバラック手前から冷たい空気を吸気し、ラック内のサーバモジュールを冷やし、背面へ排気するという構造をとります*3。このため、背面に近いチップほど前面に近いチップからの排熱を受けた熱い空気を使って排熱することになり、効率が悪くなります。
この論文ではサーバモジュール(ボード)上の各要素が発する熱を勘案して排熱効率を数値流体力学によってシミュレーションしています。
図3 ASIC Server Thermal Optimization(ISCA2016での発表資料PDFのp.33より)
そして、チップをどのように配置すると排熱効率を高められるかという検討もおこなっています。
図4 ASIC Placement: Duct Wins(ISCA2016での発表資料PDFのp.34より)
普通に並べたもの<チップを入れ違いに並べたもの<ダクトを設置したもの、という結果が紹介されています。
[*3] 液浸によって冷却するシステムも見かけますが、コストやメンテナンス性の面から少なくとも商用データセンターにおいて現時点の主流ではありません

各ユースケースにあわせた性能ファクタ検討

ISCA 2016での発表資料のp.40に、アクセラレータの特性を決める要素が各ユースケースの評価と共に紹介されています。
図5 Accelerator Properties(ISCA2016での発表資料PDFのp.40より)
  • Bitcoinは特定プリフィックスを持つハッシュのゴリ押し検索という計算特性から、ロジックをいかに詰め込んでひたすらに回せるかが重要(On-chip Logic Intensityに偏ったケース)
  • LitecoinはScryptという、計算に一定のメモリ領域が必要でランダムアクセスの必要もあるという計算特性から、チップ上に搭載するメモリとの兼ね合いが重要(On-chip RAM Intensityに偏ったケース)
  • 動画変換(H.265)は対象データ量が多くDRAMアクセスのスループットが必要なことからDRAM or I/O Intensityが高い(他の根拠は論文内で示されていないものの、内部で利用される計算式の複雑さのためOn-chip Logic Intensityも高めの評価と解釈)
  • 畳み込みニューラルネット(DaDianNaoベース)は大量のDRAMアクセスが発生するのに加えてチップ間の通信にHyperTransport(HT)を利用するため、Latency Sensitivityを強く評価

おわりに

本エントリではこの論文の良さの5%も伝えられていない気がします。ここで紹介しなかった要素が多いのに加えて、ここで紹介した内容だけに関しても、それぞれもっと具体的なことが論文に書かれているので、ぜひ読んでみてください。

FPGAマガジンNo.13の誤記/誤植一覧

2016年4月27日水曜日

特集 プロローグ

  • p.5
    • Arduinoシールド試す → Arduinoシールドで試す (※章タイトルはこうなっているため)

特集 第1章 MAX 10+BLEモジュールでスマホ制御ラジコンを作る!

  • p.7
    • 表1 MAX 10 10MH08SAU → MAX 10 10M08SAU*1
  • p.8
    • Nexsus7 → Nexus7 (※またはNexus 7)
  • p.11
    • GAT_xxxx.bin → GATT_xxxx.bin
  • p.15
    • パーソナリティ・データ(GAT_xxxx.dat) → パーソナリティ・データ(GATT_xxxx.bin)
[*1] あまり関係ありませんが、マクニカのパーツリスト内でBCM20736SとBCM20737Sという型番が使い分けられている理由はhttp://ja.broadcom.com/collateral/hs/2073X-HS100-R.pdfを読んで納得しました。

特集 Appendix 1 20ピン&40ピンDIPサイズMAX 10ボード2品種紹介

なし!

特集 第2章 MAX 10+カメラ・モジュールで動き成分をディスプレイ表示

  • p.31
    • 図8 PIO は1 ビットでBidirect → PIO は1 ビットでBidir (※もちろん意味としては何の問題もないけれど、本文中・UI上・表5でもBidirと統一されているので)

特集 第3章 トランジスタ技術増刊号付属MAX 10基板でHDMI&オーディオ出力!

  • p.46
    • Pin Prannner → Pin Planner
  • p.51
    • Genarate → Generate

特集 Appendix 2 DE0拡張ボードを使ってMAX 10をEthernetに接続する!

  • p.58
    • 表B PIO(SWITH) → PIO(SWITCH)
  • p.59
    • Intarval Timer → Interval Timer
  • p.60
    • Pallael I/O → Parallel I/O
    • 表D Data Witdh → Data Width
    • 表D Initalization reflesh cycles → Initialization refresh cycles
    • 表D Delay after powerup,before initalization → Delay after powerup,before initialization
    • 表D ACTUVE to READ or WRITE delay(t_rcd) → ACTIVE to READ or WRITE delay(t_rcd)
  • p.61
    • 10/100Mb Small Mac → 10/100Mb Small MAC
    • 45(100/45=2.5MHz) → 40(100/40=2.5MHz) (※2.5MHzにしたいなら40へ改め、45のままでいくなら2.222MHzへと改める必要あるのでは。図J内では20になっているので判断つかず)

特集 第4章 純正MAX 10評価キット+Arduinoシールドで試す初めてのMAX 10

なし!

特集 第5章 MAX 10の特徴と使用する開発ツール

  • p.82
    • Enprion → Enpirion
  • p.83
    • Quaruts → Quartus
  • p.84
    • Quarus → Quartus

Vivado HLxの各エディションとHLS(High Level Synthesis)の特徴

  • p.90
    • Airtx-7 → Artix-7
    • Vivado シュミレータ → Vivado シミュレータ
  • p.91
    • IP Integator → IP Integrator

Cyclone V SoCとZynqのAXIバスの共通点と相違点,その性能を比較する

  • p.100
    • シテム → システム
    • キャラクタは2体 → キャラクタ2体
  • p.101
    • r_backets → r_buckets (※Verilog HDLのコードでは正しくこう書かれているため)
  • p.102
    • r_backets → r_buckets (2箇所) (※Verilog HDLのコードでは正しくこう書かれているため)
    • リスト3 サイクス数カウンタ → サイクル数カウンタ

Cyclone V SoC&Zynq共通システムで割り込み制御を試す!

  • p.108
    • 表3 Ethernet1 Waku-Up → Ethernet1 Wake-Up
  • p.110
    • リスト2 fd = open(/dev/uio0); → fd = open("/dev/uio0");
  • p.112
    • gpio-alitera → gpio-altera
    • 自体に陥ります → 事態に陥ります
    • taskler → Tasklet

入門評価ボードZYBOでHDMI(DVI)画像入出力を学ぶ

  • p.115
    • VESA(Video Electoronics Standard Association) → VESA(Video Electronics Standards Association)
  • p.118
    • VAG端子 → VGA端子
  • p.121
    • bitsip → bitslip
  • p.122
    • hmdi_in_sp → hdmi_in_sp
  • p.123
    • 表3 Degilent社 → Digilent社

USBコミュニケーション・デバイス・クラス対応のUSBターゲット機器の製作

  • p.131
    • usbCdcTarge → usbCdcTarget

FPGA で高速シリアル通信 ~ SERDES を使ってみる~

  • p.136
    • SERDES:Serializer/Desilializer → SERDES:Serializer/Deserializer
  • p.137
    • 表3 Aitix-7 → Artix-7
  • p.138
    • パターンでで定め → パターンで定め
  • p.139
    • 図6 (b)Line Rate,Refclk Selection タブの設定 → (b)Line Rate,RefClk Selection タブの設定
    • 図6 (c)Encodeng and Clocking タブの設定 → (c)Encoding and Clocking タブの設定
  • p.141
    • 見出し Line Rate,Refclk Selection タブの設定 → Line Rate,RefClk Selection タブの設定
    • Line Rate,refclk Selectionタブ → Line Rate,RefClk Selectionタブ
    • 見出し Encodeng and Clocking タブの設定 → Encoding and Clocking タブの設定
    • Encodeng and Clocking タブ → Encoding and Clocking タブ

気持ち

いつもながら尖った記事が満載で読み応えがありました。
読みながら見つけたtypo/誤植系は合計49件でした。記事を読みながら手を動かす際に気付かないと詰む系のものはほとんどありませんでした。割り込み制御章のサンプルコードぐらいだと思います。トラ技増刊MAX 10との並行作業という離れ業を考えると、「やり遂げたよ、最後まで。」という感じが圧倒的に強いですね。
Quartusのタイプミスは過去号からの伝統感があり、そういう意味では覚えやすくてタイプもしやすいVivado最高だな!という気持ちが芽生えました(冗談です)。
内容としては、見事に積みデバイスと化しているBeMicro MAX 10を活かそうな、という気持ちが大きくなると共に次号でのVivado HLS記事が楽しみになった号でした。あと、Cyclone V SoCとZynqでの性能検証の章がとてもかっこよくて参考になりました(「メモリのクロック差じゃないっすかねー?」で終わらせない分析力、身に付けたい)。
p.105のコラムに書かれていた次号予告のPmod接続HDMI(DVI)ネタ、今号のZYBO+HDMI(DVI)ネタとぴったりかぶってしまっているのでは...?という気持ちと共に締めます。

FPGAマガジンNo.12の誤記/誤植一覧

2016年3月31日木曜日

FPGAマガジンは毎号技術的にエッジーな記事が多く勉強になる、本当にありがたい存在です。しかし誤植が割とコンスタントに多いです。技術専門誌としての本分は「他で得難い情報」にあるので、限られた執筆・編集時間をそちらへ割くのは当然なのですが、利用者の裾野を広げる意味ではちょっと悲しいです。
No.12もけっこう誤植多いな…と思いつつ読んでいたのですが、毎回「誤植多いぽよ~~」と言っているだけでも改善しない気がします。著者の方々に誤植一覧が届けば次以降の原稿で気をつけるヒントになるかもしれない、という期待も持ちつつ精読して洗い出しました。66箇所ありました。
多くは細かな表記上のミスや写植上のミスです。脳内で補正しながら読めば良いので大した問題ではなく、放っておいても良いようにも感じられます。自分の慣れているエリアの文章は脳内での読み替えが効きます。しかし当然スピードが落ちます。バイナリトランスレーション大変でしょ。とりわけ私の場合、記事の序盤で複数のミスを見つけると不安になってじっくり読むフェーズに入り、1/5ぐらいのスピードでしか読めなくなってしまいます。
また私は、初心者向けの技術記事では写経可能性もかなり大事だと思っています。ここでは特に間違いを減らしたいものです。写経で経典が間違ってるとかそもそもやばいし、当該環境に慣れていないと自力で誤りを見つけて乗り越えるのが難しいから。近年は雑誌でキーワードを拾い、その後にネットで調べて深めるフローも多用されます。キーワードが間違っていたら先を調べていくのも一苦労します(Googleのキーワード補正に期待することもできますが、著者側がこれをいうと開き直りにしかなりません)。
そういうわけで、この一覧が誰かの学習の役に立てば幸いです。

特集 第1章 Cyclone V SoCとZynqの比較とFPGA開発フロー

p.10
  • 右段なかほど All Programable → All Programmable
  • 右段下 PowePC → PowerPC
p.12
  • 表3 Contoller → Controller
p.15
  • 左段下見出し Quatrus → Quartus
  • 右段下箇条書き Impliment → Implement
p.17
  • 表6 Programing → Programming
  • 表6 PomGen → PromGen
計7箇所

特集 第2章 VGA表示回路を例にしたMy回路のIPコア開発とライブラリ化

p.20
  • 図3右 Cyclone V Soc → Cyclone V SoC
p.22
  • リスト2冒頭 `define XILIXN → `define XILINX
p.24
  • 右段上 Memoris & → Memories &
計3箇所

特集 第3章 ビルディング・ブロック開発によるMy回路IPコアのFPGAへの実装

p.35
  • 図5 QSys → Qsys
  • 図5 モージュル → モジュール
p.43
  • 左段上 Ummapped → Unmapped (2箇所)
計4箇所

特集 第4章 共通カスタムLinuxディストリビューションの開発

p.46
  • 左段上 Suppor → Support
p.47
  • 図1右上 Yocoto → Yocto
p.49
  • 左段 Ubutnu → Ubuntu (2箇所)
  • 右段下見出し bblayes.conf → bblayers.conf
p.53
  • 左段中 SPLのコンパイルgmakeを → SPLのコンパイルはgmakeを
  • 左段中 ubuntu → Ubuntu
p.54
  • 左段中 Cyclne → Cyclone
  • DTB(Device Tree Bomb) → DTB(Device Tree Binary)*
  • DTS(Device Tree Script) → DTS(Device Tree Source)
DTBが何の略かについては、Linuxのドキュメント(https://www.kernel.org/doc/Documentation/devicetree/usage-model.txt)とDevice Treeのドキュメント(http://www.devicetree.org/Device_Tree_Compiler)で確認しました。
計10箇所

特集 第5章 ついに起動!デュアル・ブートSDカードの作り方

p.61
  • 表4 DTB(Device Tree Bomb) → DTB(Device Tree Binary) (2箇所)
計2箇所

特集 第6章 Linuxデバドラ&アプリケーションの作成と性能評価

p.66
  • 左段上(5行目) ./memwrite 40010000 1 → ./memdump 40010000 1
計1箇所

特集関連(1) Atlas-SoCでアルテラSoC環境を手軽に楽しもう

p.74
  • 左段 SysFs → Sysfs
    • p.80のリスト3キャプション部分表記に揃え。この場合、p.81の4箇所も変更
    • あるいは逆でp.80のリスト3キャプションをSysFsへ揃え
      • 一般的表記はSysfsあるいはsysfsだと思うけれど、一貫性を重視する意味ではp.80のリスト3側を変えるほうが手っ取り早い
  • 右段中 Cyclon → Cyclone
p.76
  • 右段見出し Cyclon-SoC → Cyclone-SoC
p.77
  • Liteweight → Lightweight (11箇所、うちリスト1のコメント中に2箇所)
  • 右段中 LiteWeight → Lightweight
  • リスト1キャプション Liteweigth → Lightweight
p.80
  • 右段中 Liteweight → Lightweight
p.81
  • Liteweight → Lightweight(4箇所、うち本文に2箇所、図5中に2箇所)
p.84
  • リスト7コメント Liteweight → Lightweight
計22箇所

特集関連(2) 使いやすいXillinux&XillybusをTerasic社SoCKit上に導入する

p.85
  • Ubuntsu → Ubuntu(2箇所)
  • 図1絵解き Xilliux → Xillinux
  • 図2 Row Binary File → Raw Binary File
  • 図2 Xilinux → Xillinux
p.86
  • 右段中 Xilliux → Xillinux
p.91
  • 写真4 キャプション Xilliux → Xillinux
計7箇所

USBコミュニケーション・デバイス・クラス対応のUSBターゲット機器の実装

p.94
  • 表1 最上段 「転送速度 フルスピード」がヘッダとして網掛けになっているのはおかしい
    • 仕様表記なので最上段はヘッダ無しでも成立する。網掛けのみが不要
    • あるいは「名称 仕様」などが無難
p.98
  • 右段上 usbCdcDeice → usbCdcDevice
  • 図9 EPOCdc → EP0Cdc
p.99
  • 右段下見出し ディスクリプタの要求動作例 → デスクリプタ~
    • 章内でずっと"デスクリプタ"表記なので、表記ゆれ
p.105
  • 左段中 監視するたけでも → 監視するだけでも
計5箇所

プログラミング言語PythonではじめるFPGA開発入門

p.108
  • 表1 Flase → False
計1箇所

SDKを使ったMicroBlazeのソフトウェア開発手順詳細

p.119
  • 図2(b) Local Project → Local to Project
  • 図3(b) Local Project → Local to Project
p.120
  • 図5(a) "File → New-Application Project" → "File → New → Application Project"
    • 本文での表記にあわせる
p.125
  • 図10(a) 右部分の丸囲みが1段上についている
    • PDF版のみかもしれない
計4箇所

Cyclone V SoCで試す無償版純正PCI Expressコアの使いこなし

なし!

微妙なもの

  • P.15 iSimとISimあたりの表記が揺れている
    • そもそもVivadoではISim使わない? Vivado Simulatorへ変わったような気もする
  • p.53 右段の日本語ぐちゃぐちゃ
  • p.74 右段 Helio → Sodiaかなぁ
    • 本号の執筆段階でHelioを終売してSodiaへ向かうという流れはそれなりに明確だったので
  • p.85 図2 XillyBus IP → Xillybus IP
    • これはどちらの表記でも良いのかもしれない。判断つかず
  • p.101 リスト2(usbCdcROMの定義部分) usbCcdROM.v → usbCdcROM.vではないか。同usbCcdDevice_define.v → usbCdcDevice_define.vではないか
    • この記事は解説とコード抜粋紹介のみで実コードのダウンロード先を記載していないので正しいところは分からない
  • p.127 EPROMの接続例です → EEPROMの接続例です
    • EEPROMもEPROMのうちなので"EPROM表記でも"間違ってはいなさそう。しかし図14キャプションの表記を見ると、ここもEEPROMと記載するのが適切そう
  • p.129 Basysボードに → Basys3ボードに
    • ここまで一貫してBasys3と表記しているので、ここも揃えるべき。しかしBasysシリーズには違いないので、まあ良いのかも
なお、今回のまとめにおいて
OpenEmbedded Projectとは,組み込み機器用の Linux ディストリビューションを作るためのソフトウェア・フレームワークを提供しています(図 3). - p.50
こういう、日本語として(???)な記述はすべて無視しました。技術用語が間違っていたり、明らかに意味が通らないものだけを書きました。

ソフトウェア開発者のFPGA入門 補足ノート1

2015年8月1日土曜日


の資料を補足するシリーズです。
途中でやったことや、参考情報を書いていきます。割と個人的メモです。

作りたいものがあるのは大事

まず、心構え的なアレですが、すぐに具体的なものが浮かばないにしても、「こういうジャンルのものを作りたい」ぐらいはあったほうが情報収集についても何にしても良さそうです。
私の場合はWebサービスやゲーム系のサーバサイドでFPGAを利用して何かできないかなーという興味が軸です。

FPGAを勉強し始める前段階


ハードウェアとソフトウェアの真ん中あたりへ攻めていくにあたり、ソフトウェア方面から来た人間には明らかにハードウェア方面の常識が不足しています。まずはこれを補っておいたほうが後がきっと楽です。
そういう場面で読むべき本として、「CPUの創りかた」は完全なる名著です。発刊から12年近くが経った現在でも売れ続けていることから分かるように、とても良い本です。私の場合は、元々ハードウェア系にとても弱いので、この本を何度か読んでからFPGAの領域へ来ました。

第0歩の直前: XilinxかAlteraか

そこそこの評価ボードを入手しやすく、開発キットをしっかり提供しているベンダーはXilinxとAlteraの2強です。FPGA自体の実装アーキテクチャは異なりますが、VerilogやVHDLで記述した定義をFPGAへ落として実行し、デバッグなどもできるという面ではあまり変わりません。
私の場合は、うっかりと両方のボードが手元にあります(当初購入したAlteraのチップを搭載したDE0というボード、そしてARMコアとFPGAのハイブリッド構成という楽しさに釣られて購入したXilinx系のMicroZed)。
評価ボードがない状態でもひとまず開発ソフトをダウンロードして試すことはできるので、ひとまず両方触ってみましょう。といいたいところですが、FPGAの開発用IDEはとにかくメニュー構造もワークフローもソフトウェア系と違ってなかなかに複雑です。しかも、XilinxのIDEは割と最近(といっても2-3年前ですが)にフルリニューアルし、過去版(ISE)に基づいたblogの入門記事類がごっそりとdeprecatedになっています。「どうせEclipseベースだから、触ればなんとかなるだろ」と思ってむやみに触り始めると心折れます。私は折れました。
まあ、AMD派?Intel派?という感じのふわっとした感じで適当に決めれば良いと思います。個人的印象では、Xilinxのほうがオンラインドキュメントが膨大にあってIntel風味なので好みです*1。x86 CPUベンダーと違って、「どちらのほうが比較的安い」みたいなのは無い気がします。
AlteraとXilinxどちらにするか決めたら、まずは安めのボードを物色します。雑誌付録にFPGAがついていたこともありましたが、最近は見かけないので えいやっと買ってしまうのが手っ取り早いです。
面白そうなボードや、入門の道を誰かが切り拓いてくれているボードがあれば、それに乗っかるのも良いと思います。今なら、$30で始めるFPGA(竹村さんの資料)に従って進める想定でBeMicro Max10 FPGA EvaKitあたりを買うのが楽なのではないでしょうか。ちなみに、これを買うとAltera閥へ入ることになります。おめでとうございます。
[*1] あっ、Intelが最近Alteraを買収したので、AlteraのほうがIntelっぽいというかIntelですね(紛らわしい表現)。

第0歩: 型を学ぶ


「ARM Cortex-A9×2! ZynqでワンチップLinux on FPGA」という本で学んでいったという話です。
これは、XilinxのZynqというアーキテクチャのZedBoardという評価ボードの利用を前提にした本です。
出た当初はこの本高いなぁ、Web上にある情報でなんとかならないかなぁ、と思っていました。
しかし、途中でIDEの扱い方に心が折れ、諦めて買いました。
本の範囲としては、旧世代のIDEの利用が多いのですが、一応新世代のIDEをカバーした章もあり、グラフィックス出力から自前のコア構築、チューニング可能なポイントの洗い出しから実際にチューニングしてみるまでの本当に多彩なトピックをカバーしています。
とても良い本です。ただ、誤植がものすごく多いのが難点です。見つけた誤植は「ARM Cortex-A9×2! ZynqでワンチップLinux on FPGA」の誤植一覧(150箇所)にまとめました。
ここでの学び: ツール群の扱い方がざっくりと身につかないと、他のことが頭に入ってこない。まずはこういう本に従ってひと通りを体験するの大事(しかしISEベース...!)
この本、ひとつひとつしっかりやっていくと各小項目で1冊ずつ本が書けそうな幅広さです。
特に、さわりが載っていたことが個人的に嬉しかった項目を挙げておきます。
  • ISEとVivadoの両方を使っての話展開
    • ちょっと古い記事やチュートリアルを眺めると、結構ISEベースの話がある。こういう時に怖がらず読めるようになった
      • まあ、PlanAheadとかXPS?とかいくつかのツールが、どういうふうに再編してVivadoになってるかという雰囲気が掴めるのが大きい
  • Linuxのデバイスツリーに関する話と実際に自分で書く話
  • PSとPLの間のデータ転送
    • AXI系
      • AXI4-Lite
      • AXI4
      • AXI4-Stream
結果、この本はだいぶ読み込みました。軽く遠出するときに電車の中で読んだり、家でも何度か読んだり。
2-3ヶ月FPGA方面から離れて、頭のなかから色んなものが抜けた状態で再度スタートしようというときに、頭をFPGAへ引き戻すためにも有効でした。
惜しいのは前述の通り、誤植が多いことです。やはり、頭が乗ってきて読み進めている時に、技術用語が誤った領域を踏むと脳が例外を吐いて止まってしまうので悲しいところです。売れに売れて重版で誤植が直ったら、多分もう一冊買うと思います。

Zynqの雰囲気

本やオンラインのドキュメントを読んでいて感じた、ARM+FPGAというZynqアーキテクチャにまつわる雰囲気を書いてみます。

"7"シリーズは断絶の壁

前述のように、XilinxはISEシリーズから新しいIDE(Vivado)へと移行しました。この移行期にぴったりぶつかったのが、いわゆる"7"シリーズです。ZedBoard/MicroZed/ZYBOに使われているZynq-7000シリーズもこのひとつです。
ISEにはZynq-7000シリーズの開発用定義ファイルがありません。古いチュートリアル(書籍も!)は割とISE前提で書かれています。

「ARM無しのFPGA単体で使いたいんですけど?」→「Artixでも使えば^^」

  • Zynqなシステムの利用にあたっては、Linuxを使うか否かは別として、チュートリアル的にARMは普通使うぽい
    • なので、Zynqのチュートリアルを探していくと、「単純な論理回路をまずは組んで動かしてみよう!」という感じの伝統的なFPGAチュートリアルっぽいのがあまり出てこない
  • Xilinxの人の、Zynqをシステム要素として使う際の設計スタンス http://news.mynavi.jp/articles/2012/02/22/zynq-7020/002.html
    • ARM側の電力削りたければ100MHzでも10MHzでも好きにクロック落とせ
    • RTOSが必要なら、ARM側をSMPではなくAMP構成にして1コアを低クロック動作させて使え
    • Cortex-R系はひとまずやる気ない
      • ※そう言いつつ、3年後にはMPSoCという新世代のアーキテクチャはCortex-A53ベースとCortex-R5ベースの2ラインに割れたので大変趣深い

MicroZed/ZedBoardの起動手段は使い分けたほうが便利

  • JTAGは初期の開発へ利用
    • デバッガをアタッチしたい場合などに大変便利
  • FPGA部分が固まってソフト開発へと段階が移ってきたらSDカードに書き込んで起動
    • いくつかのバージョンを別カードへ保持して差し替えやすい
    • 数十MB〜数GBのファイルも置ける
  • ファームがしっかり固まってきたらQSPIへ焼く
    • 起動がSDカードより速い
    • 16MBまでしかアクセスできないので、起動用ファイル以外のデータ群はどのみちSDカードになるはず

ソフトウェア開発者もやっぱり気になるFPGA( #CodeLunch フォローアップ)

2015年4月28日火曜日

先日、CodeLunchというpodcastの収録へ行ってきました。

本職はスマフォアプリをC++で書いてる(書けるとは言っていない)とかそのへんなのですが、ハードの話をしようということでFPGAの話をしてきました。

Beatroboの竹井さんに随所で助けてもらいつつ、どうにかこうにか喋れた気がしますが、元々専門ではないエリアなので間違ってること喋ってるかも、という不安もありつつでした。

そういうわけで収録後に周辺情報を補足する資料を書こうと思って書いたのがこれです。

podcastはこちらです→ http://codelunch.fm/11/

なんでFPGAが注目されてるの?という話

Field Programmable Gate Array

どういうところで注目されてる?

1: 金融取引

http://www.hpcwire.com/2011/07/13/jp_morgan_buys_into_fpga_supercomputing/な話

金融取引でスピードは大事という話

  • podcastでは実際の想定利用シーンとしてアービトラージ(裁定取引)の話をしてる
  • 価格情報が届いた瞬間に発注してしまう
    • 補足: FPGAでの完全自動トレードは比較的新しい領域
  • 補足: メモリアクセスが頻繁に発生するとやはり遅いので、いかにこれを避けられる用途に絞るかというところにはなるはず

CPUに届く前にやろう

  • 補足: どちらかというとCPUに対して予め処理しやすい形式へと速やかに変換して値を渡すような部分がメイン(前出)ということで、話したのは少々飛ばしすぎたかもしれない

早さ大事という話

価格情報配信ってどれぐらい安定してる?

  • 補足: 改めて調べると、これは証券会社によって差が生じたことに対するペナルティだった
    • 純粋な価格情報遅延によるペナルティを受けたことはないぽい?調べきれなかった

金融関係のアルゴリズムってそんなに複雑じゃない?という疑問

補足: フラッシュトレード絡みだとフラッシュ・クラッシュ

Flash Crashについては別途ちゃんと読もう

2. FPGAで機械学習

MSのBing(補足: 2014年末時点では本番環境へ投入されていなかったけれど、そろそろ?)

ページランクみたいなやつに使い始めた

  • http://qiita.com/kazunori279/items/6f517648e8a408254a50
    • 例によってかずのりさん
    • 安定のかずのりさん
      • 補足: しっかりまとまってたので読み返そう
  • ランク付けをFPGAで
    • サーバ台数を半分ぐらいに減らせたよ
    • ランキングアルゴリズムは普遍的だから?→スパム対策などでよく更新されるということなのでは
      • 完全にハード化すると数ヶ月ごとにハードを捨てないといけなくなって辛い
      • だからFPGAなんじゃないかな(推測)

ほかの用途

  • 画像処理。最近は展示会などでも車載用が押されてる
  • カメラの中の画像処理にFPGAを使うとかもあった
  • 画像のフィルタリングに使われる
  • FPGAだと作り付けの回路よりも書き換えの手間が発生する
  • カメラの中身に、とか

FPGAってどうやって焼く?の

  • コンフィグROMから読み出すよ
  • 起動時にコンフィグ
    • 補足: なおZynqとかだと起動後に別途コンフィグもできる

FPGA 基礎の基礎

論理の表現

  • 図とかなしにどう説明しようかなと思い
  • すごく雑に仕組みを説明すると、カンペ+メモ帳
  • AND回路とかOR回路とかふんわり分かればFPGAの仕組みは分かります
    • ANDは、全部の入力が1の場合のみ1を出す、それ以外は0
    • ORはどれか1つでも1だったら1を出す
    • NOTは入力が1なら0を、0なら1を出す
  • これをFPGAはカンペで実現する
  • まずはとても単純な、1値の入力で1値の出力をおこなうものから考える
    • NOTをあらわすカンペには1→0 0→1と書いておく
  • 2値以上でも基本は同じ
    • 2値のANDなら0・0→0、0・1→0、1・0→0、1・1→1というカンペを書いておく
    • 6値の入力から1bitの出力を作る、と考えると64パターン。結構複雑な回路が作れる

フリップフロップ

  • (フリップフロップ、一度手組でもしないと自分の中のイメージきちんと固まらないのでは)
  • 要はメモリです。次のクロックが来たタイミングで、つながってる先へと値を渡す役割を持ちます

配置配線

  • ゲート数がいっぱいあればいい感じに動く?動かない
  • 配線が大事になる
    • FPGAのクロックはナノ秒単位
    • あるユニットから他のユニットへどれぐらいの時間で信号が届くかが大事になる
    • 配線が異常に長い部分ができると、その信号が到達するのを他の部分で待つ必要が生じる
      • クロックを落とせばいいけれど、そうするとシステムの動作速度が下がってしまう
  • どこのゲートにつなぐか(配置配線)はFPGAベンダーのツールでやる
  • 書き方によって生成される配線も変わる
    • ここは職人芸(経験とカン)

FPGA上にあるロジックセル

  • 数は200万とかある
  • Flip-Flopでも消費されたりする(SRAMとして使ったり)。小規模なものならいくつか入れられたりする
  • 全部をプリミティブに組むのはあまり効率が悪い
  • 加算処理をする専用の回路とかが予め含まれるようになってきている
    • キャリーフラグなども流せる

Alteraがここしばらく(数年)力を入れてきたFPGA上の最適化

  • ロジックセルは8値の入力から2値の出力というのが基本セット
  • これを4値入力1値出力 2セットというふうにも使えるようになっている
    • 補足: 限られたロジックセルを有効に使って柔軟に回路構築をできるというウリ
  • 考えてみると、ここの最適化を人力でやるのは非常につらい
    • 他のベンダーがいきなり入ってきてちゃんとしたツールセットを提供するのもむずい

論理合成・配置配線

  • 最適化問題。むずい
  • 肌感覚、割と単純な回路でもMacBook Proで4-5分とか合成/配置配線にかかる
  • 複雑なのを作りたければ高いの買え的な?
    • 同じアーキテクチャ世代でも回路規模によって値段が全然違う
  • 回路規模が大きくなると合成も時間がかかりすぎて個人では無理なのでは?
    • ツールのお高い版には分散処理をする仕組みが含まれていたりするらしい
  • ツールはFPGAボードごとに別? → XilinxとAlteraでそれぞれ1種類ずつ持っている

プログラムを書いて合成していく

  • VHDLとかVerilogとかで書く
    • アセンブリ言語なイメージ
  • コードが上から順に実行されるわけではない
  • あるブロックをまとめて実行する
  • この性質を使って、パラレルにできる部分はパラレルにする
    • 例えば16個の入力それぞれに4ずつ値を足すような処理は、それだけ分の回路を割り当てれば同時に処理できる
    • FPGAで高速化できるパターンの半分ぐらいはこれだと思う(主観)
    • 行列計算とかいい感じにできる
    • ハードウェアとソフトウェアのいいとこ取りができるエリア

FPGAつらい話

  • VHDLやVerilogでいきなりBingのランキング処理書け!とか言われてもつらい
  • Xilinxのツール、生成した回路の中でネックっぽい場所は見つけてくれる
  • VHDLやVerilogはアセンブリ言語みたいな立ち位置、これで大規模なアプリを作るのは辛い

FPGAのざっくり開発工数

  • より高級な言語で書けばいいのでは?という感じもする→後で出てくる
  • Xilinxの人による2012年の講演資料: FPGA 2032 Roadmap: A Personal Perspective
    • CPUだと1時間で書けるような処理にFPGAだと1週間ぐらいかかる。その段階で1時間かけて作ったコードの4倍ぐらい速い。いっぽうCPU側も1週間ほど続けると更に4倍速いあたりになる
    • FPGAを採用してうまみのある部分は数ヶ月間かけてチューニングしていくようなもの
    • 最初の立ち上げはCPUで書いて、後から時間をかけて最適化していくのにFPGAを使うなどがモデルとして良さそうという話
      • 「相当なコストをかけても、それだけのリターンがあれば使いたい」という領域にしか当初は使いにくい→最たるものが金融
  • 細かく辛いところ: コンパイルに時間かかる
    • 多少コード書き換えてコンパイルし直しに5分とかかかると辛い

OpenCores

  • 開発効率がなかなか上がらない点は、再利用可能な部品がいっぱいあると効率よくなるかも
  • OpenCoresというプロジェクトではIPを公開している

GPUを使う話

  • GPGPUとかGPU Computingというエリア
  • さきの資料、1週間ぐらいかけてできるFPGA実装よりも4倍ぐらい速い状態(CPU実装の1週間分あたり)が、GPUだと2日程度でできるよという話
    • 最終的にスケールする度合いもFPGAと結構近いとされている
  • FPGAほど辛いことやらなくても良いかも
  • GPUでいいんじゃない?ってなる

高位合成

  • FPGA向けのハードウェア設計をもっと書きやすい言語で書けるようにする
  • CとかからFPGAのデザインを作るのを高位合成と呼ぶ
    • ここがホットなエリア
  • ものによってはCで書かれたコードをなるべく並列化して最初のデザインを仕上げるというもの
    • Cだけではない。Haskellからの高位合成もある
      • 型がしっかりしているし、もともと並列処理に向いているし
      • Lavaというのがある(Kansas大学あたり)→Xilinx版もメンテされてる
  • 竹井さん: 以前やったところだとSystemC、変換効率がさほどよくなかった
  • 竹井さん: VHDLを書いていると「こんだけ書いたのにまだこれだけしか動かない」となる
  • ボトルネック部分を手動で頑張るような感じになると良い
    • Pythonの拡張みたいな感じ
    • そういえばPythonからの高位合成を研究している
  • XilinxのツールセットでもVivado HLSというのがある
    • 25万円ぐらいのエディションでないと使えない
  • Lavaあたりで論理合成を先にやってしまって、実際のFPGAボードにあわせた配置配線だけXilinxあたりのツールでやるとかも現実的かもしれない
    • 補足: ここは、IP-XACT(IEEE 1685)あたりで書きだしたものを各種ツール側でインポートするのを想定している

開発環境

  • 今は開発しているコードの情報などをXilinxやAlteraへと共有する(これを売り渡すと表現している)代わりに無料で使える範囲が大きい
  • XilinxのSUZAKUというシリーズを使っていた。これには1年分のライセンスがくっついてきてた
    • Zynqも似た感じ

高位合成が普通になると、FPGAはGPGPUと張り合える?

  • 基本的には両方が選択肢になるのではと思っている
  • FPGAとGPU、少々特性が違う
  • GPUにもつらさがある
    • GPUで処理するためにメインメモリからデータを転送し、GPUでの処理を終えてからCPU側へ引き上げるのにレイテンシがかかる
      • このコストを上回るほどGPGPU側の処理が速ければペイする?というのを考える必要がある

GPU側も進化していっている

  • GPUも進んでいるエリアがある。CPUとGPUを統合する向きにある
    • AMDだとAPU(Accelerated Processing Unit)と呼ばれる
  • CPUメモリとGPUメモリを統合する向き
    • CPU側とGPU側のメモリをリニアに共有する形になっている
    • CPU側でデータを作り、GPUには場所だけを伝えるとGPU側から直接データを読み出して処理、結果アドレスをCPUへ返して直接利用できるようになっている
    • AppleのA7あたりでも似た話
      • Metalは描画コマンドの送り方が違うなどの他にも、CPUから書き込んだメモリをGPU側で直接読み出して処理するようなモデルが整備されている
  • GPU統合CPUというモデルがハイエンド化していくのでは
    • これまでは安いノートPC用というイメージだった
    • メインメモリの一部をGPUに割り当てていたが、従来だと垣根があった
  • GPUも進化している
  • FPGA一人勝ちという感じはしない

FPGAとCPUがミックスされたようなもの

  • 昔だとFPGAの中に小さなCPUコアを構築する形だった
  • 最近は逆、というか普通にARMのCPUが載っていて、それに加えてFPGAも載っている形のものをXilinx(補足: Zynq)もAltera(補足: FPGA & SoC)も出している
    • ARMのCPUに自分で拡張命令を実装して、それを普通にLinuxなどから呼び出せる
  • 中澤が最近やっているのはARMv8に載っている拡張命令をFPGA側に実装してARMv7でも使えるようにするというもの。なかなかパフォーマンス上がらない
    • どこから手を付けて良いかよくわからず、ツールの使い方で苦労した
    • 数十年間練られてきたツールだけに、慣れないとなかなか効率があがらない(補足: PlanAhead+Vivadoで15年ぐらい?)

竹井さん: FPGA学習の仕方 / Design Wave

  • FPGAな人向けのやつ
    • 最近のツールの使い方とか説明してた
  • 最近だとFPGA Magazine
  • Design Wave 2009年の最終号
    • (ここで主要トピックが「Cベース設計の時代がやってきた」となってたあたりがとても趣深い)
  • もう10年ぐらい前だと、5万円でめちゃくちゃショボいボードを買って触ってた
  • ucLinux(MMUの要らないもの)をMicroBlazeで動かしていた
  • 秋月で売ってた液晶を買ってきてコア拡張した部分の物理アドレスへデータを書き込んで画面表示する
  • 大学の研究室で、ディスプレイ出力とか諸々全部含めてシューティングゲームを作る的なのやってるひといた
    • 敵のスプライトを移動させるとかそういう処理も
  • 大学の演習でCPU作るところからやるのとかあるという話

クロージング: まずはここから

  • 最近話題になっていた$30のボードがあるのでそれで($30で始めるFPGAが素晴らしい資料)
    • 8000ロジックエレメントでできることを考える
    • 飯塚さんが小さなCPUを作るのを目標にする