CNNのバックプロパゲーションについて聞いてみます。

CNN（Convolutional Neural Network）における重みの更新は、一般的に「バックプロパゲーション」というプロセスを通じて行われます。これは、ネットワークの出力層（下流）から入力層（上流）に向かって逆方向に誤差を伝播させながら、各層の重みを更新する方法です。バックプロパゲーションは、以下のステップで構成されます。

1. フォワードパス

• ネットワークの入力から出力へとデータを順方向に伝播させます。
• 各層での活性化関数を通じて、次の層への入力を計算します。
• 最終的に、ネットワークの出力層で予測結果を得ます。

2. 損失関数の計算

• 出力層での予測結果と、実際のラベル（正解データ）との間の誤差を計算します。
• この誤差は損失関数（例えば、クロスエントロピー損失）を用いて表され、ネットワークの性能の良し悪しを評価する指標となります。

3. バックプロパゲーション

• 損失関数から得られた誤差を、出力層から入力層に向かって逆方向に伝播させます。
• 各層における重みの勾配（損失関数の重みに対する偏微分）を計算します。これは、重みをどの方向にどれだけ調整すれば損失を減少させることができるかを示します。

4. 重みの更新

• 計算された勾配を用いて、各層の重みを更新します。この際、学習率というパラメータが重みの更新量を決定します。
• 通常、勾配降下法（またはその変種、例えば、モーメンタムやAdam）が重みの更新に使用されます。

5. 反復学習

• これらのステップをデータセット上で複数回繰り返し実行し（エポック）、ネットワークの性能を徐々に改善していきます。

バックプロパゲーションによる重みの更新は、CNNを含む多くのディープラーニングモデルで採用されている基本的な学習アルゴリズムです。このプロセスにより、ネットワークは与えられたタスク（例えば、画像分類）に対して最適な予測を行うための重みを学習します。

前のブログ 次のブログ

(前記事の続き)

ハードウェア最適化のためのアプローチ

リソース共有

• 複数の畳み込み層や活性化関数が同様の計算を行う場合、これらの計算資源を共有することで、全体のリソース消費を削減できます。例えば、複数の畳み込み層が同時に動作しない場合、一つのハードウェア畳み込みエンジンをタイムシェアリングすることが可能です。

精度とリソースのトレードオフ

• データの精度（ビット幅）を調整することで、計算リソースの使用量とパワー消費を削減できます。例えば、32ビット浮動小数点数から16ビット固定小数点数への変換は、精度のわずかな低下と引き換えに、計算速度とエネルギー効率の向上をもたらすことがあります。

動的なリコンフィギュレーション

• FPGAのようなプログラマブルなハードウェアを使用する場合、動的にハードウェアの構成を変更することで、異なるタスクに最適な計算資源を割り当てることができます。これにより、一つの物理デバイス上で複数のモデルやアルゴリズムを効率的に実行することが可能になります。

カスタムデータパス

• タスクの特定の要件に合わせて、カスタムのデータパスや計算ユニットを設計することで、標準的なCPUやGPUよりもはるかに高速な処理が可能になります。このアプローチは、特にデータフローが予測可能で、特定の計算パターンが頻繁に発生するタスクに適しています。

デバッグと検証

• ハードウェア実装では、シミュレーションを通じて設計を検証することが重要です。特に、BSVのような高レベル合成言語を使用する場合、論理的なエラーや性能のボトルネックを初期段階で特定し、修正することができます。
• 実際のハードウェア上でのプロトタイピングとテストを行うことで、シミュレーションでは捉えられない問題（例えば、タイミングの問題やハードウェアの不具合）を発見し、解決することができます。

ハードウェアでのCNN実装は、ソフトウェアベースの実装と比較して複雑な作業ですが、リアルタイム性やエネルギー効率の面で顕著な利点を提供します。設計の各段階での慎重な検討と最適化を行うことで、高性能なハードウェアアクセラレータを実現することが可能です。

前のブログ 次のブログ

トラブルシュート

当初、以下のbsvからverilogをコンパイルするというふつうの依存関係が動作せずに苦労しました。

# Verilogファイルの生成
mk%.v: %.bsv
        time bsc -verilog -u -steps-warn-interval 1000000 -steps 8000000 -suppress-warnings T0054 $<

そこで以下のコマンドによりデバッグ情報を出力したところ、原因がわかりました。

$ make -rd

原因は、makeがtop-original.vという原始ファイルの元となるtop-original.bsvを探しに行ったためでした。探しに行って無ければ無視すれば問題ないのですが、動作としてはこのルール全体を却下する動作をするため、このルールが無効になっていたものです。ChatGPTと相談して.SECONDARYキーワードでなんとか無視させることができました。

パターンマッチ

さらにC/C++等だと拡張子のみが変化するのですが、bsvではUart.bsvをコンパイルするとmkUart.vとなるなど変則的な変化をするため、それがなかなか表現できませんでしたが、

mk%.v: %.bsv

このように変化しないところを%で記述することで対処できました。

原始ファイルからのファイル名生成法

汎用的に使用できるように、原始ファイル名から中間ファイル名を生成するようにしました。例えば、

$(addprefix mk, $(addsuffix .v, $(basename $(wildcard *.bsv))))

これにより原始ファイルのbsvファイル名からverilogファイル名を自動生成します。このようにすればMakefileに具体的なファイル名を書く必要がありません。誤ってwildcard *.v等としてしまうと、make cleanを行った後には何もないためmake処理が正しく行えないので、全部を集めるリンクのような場合は必ず存在するファイルに基づき必要なファイル名を生成します。一方、一対一の場合は%.v: %.bsvのような記法で十分です。

top.vの役割

忘れがちですが、top.vは直下の端子とemacsのマクロにより自動結線するため、テストベンチのverilogであるmkTb.vが必要です。そのため、Makefileにはその依存関係も加えました。

そもそもtop.vはverilog.vcdを出力するためのものです。

$ bsc -verilog -e mkTb -o mkTb.exv

一方、このようにbsimシミュレーションと同様、フラグを-verilogに変えるだけでiverilogを使わずとも*.vファイルをリンクし、実行ファイルまで生成されます。ではなぜtop.vを使ったかというと、verilog.vcdをダンプするためで、mkTb.exvを実行するだけではvcdが出力されなかったからです。

ところが、

$ ./mkTb.exv +bscvcd=verilog.vcd

このフラグ設定によりvcdが出力できることがわかりました。これによってtop.v等は不要となります。従ってemacsで結線する手段やiverilogが不要となるため、Makefileもだいぶ簡潔になります。

前のブログ 次のブログ

Makefile

ChatGPTの助けを借りながらbsvのMakefileを作成しました。bsvソースはBSVの問題点?を作成したときのファイルです。完成したMakefileを示します。

# ファイル名の生成
BSRCS = $(wildcard *.bsv) # BSVソースファイル
BASRCS = $(addprefix mk, $(addsuffix .ba, $(basename $(BSRCS)))) # BA中間ファイル
VSRCS = $(addprefix mk, $(addsuffix .v, $(basename $(BSRCS)))) # Verilogファイル

# .PHONY ターゲットの定義
.PHONY: all bsv_view verilog_view clean

# 全体のターゲット定義
all: bsv_view verilog_view

# BSV波形ビューアの起動
bsv_view: bsim.vcd
    gtkwave -A bsim.vcd

# BSV波形ファイルの生成
bsim.vcd: mkTb.exe
    ./mkTb.exe -V bsim.vcd

# BSV実行ファイルの生成
mkTb.exe: $(BASRCS)
    bsc -sim -e mkTb -parallel-sim-link 4 -o mkTb.exe

# BSVファイルのコンパイル
mk%.ba: %.bsv
    time bsc -sim -u -steps-warn-interval 1000000 -steps 8000000 -suppress-warnings T0054 $<

# Verilog波形ビューアの起動
verilog_view: verilog.vcd
    gtkwave -A verilog.vcd

# Verilog波形ファイルの生成
verilog.vcd: mkTb.exv
    ./mkTb.exv -V verilog.vcd

# Verilog実行ファイルの生成
mkTb.exv: top.v $(VSRCS)
    iverilog -y /usr/local/lib/Verilog/ top.v $(VSRCS) -o mkTb.exv

# top.vの生成と更新
top.v: top-original.v mkTb.v
    cp top-original.v top.v
    chmod 644 top.v
    emacs --batch top.v -f verilog-batch-auto

# BSVファイルからVerilogファイルを生成
mk%.v: %.bsv
    time bsc -verilog -u -steps-warn-interval 1000000 -steps 8000000 -suppress-warnings T0054 $<

# クリーンアップ
clean:
    @rm -f mk*.v top.v
    @rm -f *.bi *.bo *.ba a.out \#*
    @rm -f *.cxx *.h *.o *.so *.bexe
    @rm -f *.exe *.exv
    @rm -f *.vcd *~ *.fsdb *.log

# 中間ファイルを保持するための設定
.SECONDARY: top-original.v

依存関係グラフ

ここで、’Makefile'の依存関係の可視化の記事のプログラムをそのまま用いて、

$ LANG=C make -np | python3 make_p_to_json.py > graph.json; python json_to_dot.py workflow.png; xv workflow.png

このコマンドにより作成した依存関係図を図814.1に示します。

前のブログ 次のブログ

bscのコンパイルとインストールをChatGPTの助けを借りながら実行しました。OSはFedora 40の場合です。

$ sudo dnf -y install ghc stack libX11-devel libXft-devel gperf bison flex itk-devel tk-devel itcl-devel tcl-devel g++ iverilog autoconf
$ git clone --recursive https://github.com/B-Lang-org/bsc.git bsc
$ cd bsc

bsc.cabalとstack.yamlを作成します。

$ echo "name:                bsc
version:             0.1.0.0
synopsis:            Brief description
description:         Longer description
license:             BSD3
author:              Author name
maintainer:          example@example.com
category:            Category
build-type:          Simple
cabal-version:       >=1.10
executable bsc
 main-is:             Main.hs
 build-depends:       base >=4.7 && <5
 hs-source-dirs:      src
 default-language:    Haskell2010" > bsc.cabal

$ echo "resolver: lts-18.0
    packages:
    - .
    extra-deps:
    - regex-compat-0.95.2.1
    - syb-0.7.2.4
    - old-time-1.1.0.4
    - split-0.2.5" > stack.yaml

Haskellのパッケージのバージョンを調べるためには、StackageやHackageを利用します。ChatGPTに依頼しても調べて貰えます。

次にsrc/Main.hsが無いため作成します。

$ echo 'module Main where
    main :: IO ()
    main = putStrLn "Hello, BSC!"' > src/Main.hs

stackを用いて必要なライブラリをインストールします。

$ stack install regex-compat syb old-time split; stack update; stack build --only-dependencies; stack build
$ stack exec -- make install-src

これでコンパイルが始まるので、しばらく待ちます。終わったら以下のコマンドでインストールします。

$ sudo cp -r ./inst/bin/* /usr/local/bin/; sudo cp -r ./inst/lib/* /usr/local/lib/

何か不明な点があったらリファレンスマニュアルやbsv例を調べてからフォーラムで質問します。

前のブログ 次のブログ

(続き)以下に、ハードウェアでCNNを実装する際の追加的な考慮点を示します。

パラメータとウェイトの管理

• ウェイトの格納: CNNの性能は、学習されたウェイトに大きく依存します。これらのウェイトは、ハードウェア内のメモリに効率的に格納され、アクセスされる必要があります。FPGAの場合、オンチップのブロックRAM（BRAM）や、より大きなデータセットの場合は外部メモリとのインターフェースが必要になる場合があります。
• ウェイトの更新: 学習プロセス中にウェイトを更新する場合、これを効率的に行うメカニズムを設計する必要があります。多くの実装では、ウェイトは事前に学習され、ハードウェアに固定されるため、更新は行われません。しかし、オンライン学習やアダプティブなシステムを設計する場合は、この点を考慮する必要があります。

データフローの最適化

• パイプライン処理: データを連続的に処理する畳み込み層やプーリング層では、パイプライン処理を用いることで、各ステージの遅延を重ね合わせ、全体のスループットを向上させることができます。
• 並列処理: CNNの各層で複数の演算を同時に行うことができるため、並列処理を活用して計算の高速化を図ります。特に、Depthwise Separable Convolutionでは、Depthwise畳み込みとPointwise畳み込みの両方で並列化の機会があります。

リソースの制約と最適化

• リソースの利用: FPGAのリソースは有限です。使用するロジックブロックの数、メモリの使用量、I/Oの利用などを最適化することが必要です。
• 性能と精度のトレードオフ: ハードウェアの制約の下で、性能（例えば、推論の速度）と精度（例えば、分類性能）のバランスを取る設計決定を行う必要があります。例えば、ウェイトの量子化を行うことでメモリ使用量を減らすことができますが、これが精度に影響を与える可能性があります。

ハードウェア実装におけるデバッグと検証

• シミュレーションとテスト: 設計したモジュールの正確性を検証するために、BSVのシミュレーション環境を利用して広範なテストを行います。これには、単体テストから統合テストまで、さまざまなレベルのテストが含まれます。

ハードウェアでのCNN実装は、特にリアルタイム処理やパワー効率が重要なアプリケーションにおいて、大きな利点をもたらすことができます。しかし、その設計と実装は複雑であり、ハードウェアの特性や制約を十分に理解する必要があります。上記の考慮点を踏まえて設計を進めることで、効率的かつ効果的なハードウェアベースのCNNを実現することが可能になります。

前のブログ 次のブログ

アルゴリズムは大方カバーしたので、MobileNetをBSVでどのように実装したら良いかを聞いてみます。

Bluespec SystemVerilog（BSV）を使用してMobileNetなどの畳み込みニューラルネットワーク（CNN）のコンポーネントをハードウェアで実装する際には、畳み込み層、活性化関数、プーリング層などの基本的な要素を個別に設計し、それらを組み合わせて全体のネットワークを構築します。ここでは、これらのコンポーネントのハードウェア設計に関する概念的な説明を行いますが、BSVに特有のコードを提供することはできませんのでご了承ください。

畳み込み層

• 概要: 畳み込み層は、入力画像にフィルタ（カーネル）を適用し、特定の特徴を抽出するための層です。MobileNetでは、効率化のためにDepthwise Separable Convolutionが使用されます。
• ハードウェア設計のポイント: 各フィルタの畳み込み計算を行うための乗算と加算の演算器を実装します。Depthwise Separable Convolutionの場合、Depthwise畳み込みとPointwise畳み込みの2ステップに分けて実装する必要があります。演算の並列化やパイプライン化を行うことで、高速な処理が可能になります。

活性化関数

• 概要: 活性化関数は、畳み込み層や全結合層の出力に非線形性を導入するために使用されます。MobileNetでは、ReLU（Rectified Linear Unit）が一般的に使用されます。
• ハードウェア設計のポイント: ReLUは、入力が正であればその値を、負であれば0を出力するシンプルな関数です。この関数は、条件分岐を用いて簡単に実装できます。ハードウェアでの実装では、比較演算と条件に基づく値の選択を行うロジックが必要になります。

プーリング層

• 概要: プーリング層（特にMax Pooling層）は、入力特徴マップのサブサンプリングを行い、特徴の位置変化に対するロバスト性を高めるために使用されます。
• ハードウェア設計のポイント: Max Poolingは、定義されたウィンドウ内で最大の値を選択します。この処理は、ウィンドウ内の値を比較し、最大値を選出することにより実装できます。効率的なデータアクセスと演算のために、適切なバッファリング戦略が重要になります。

実装に向けて

• モジュール化: 各コンポーネントをモジュールとして設計し、それらを組み合わせて全体のネットワークを構築します。モジュール化により、再利用性が向上し、デバッグやメンテナンスが容易になります。
• テストベンチの作成: 各コンポーネントおよび全体のネットワークに対して、シミュレーション環境を用いて広範囲のテストを行います。これにより、設計の正確性を検証し、期待通りの動作をすることを確認します。

ハードウェアでCNNを実装することは、ソフトウェアベースの実装と比較して高い効率と性能を実現することができますが、複雑な設計と詳細なテストが必要になります。また、BSVのようなハードウェア記述言語を用いた実装では、ハードウェアの特性を十分に理解し、それに適した設計を行う必要があります。

前のブログ 次のブログ

BSVではどのように設計したら良いかを聞いてみます。

Bluespec SystemVerilog (BSV) を使用して MobileNet のような CNN (Convolutional Neural Network) アーキテクチャを設計する場合、具体的なコードを書く前に、いくつかの重要な設計段階を検討する必要があります。BSVで直接ディープラーニングモデルを実装するのは非標準的なアプローチですが、ハードウェアアクセラレーションの観点から特徴量抽出などの計算処理を効率化するために用いることができます。

設計の概要

1. 入力データ: 256x256x1 のグレースケール画像が CNN の入力として与えられます。この入力データは、Pong ゲームの各フレームに相当します。

2. MobileNet のアーキテクチャ: MobileNet は、軽量でありながら高い精度を実現する CNN アーキテクチャです。Depthwise Separable Convolution を中心とした構造を採用しており、計算コストとモデルサイズの削減を実現しています。

3. 特徴量抽出: CNNの主な目的は、入力画像から有効な特徴量を抽出することです。これらの特徴量は、後続の強化学習アルゴリズムでゲームの状態表現として使用されます。

BSVによる実装ステップ

実際のBSVでのコーディングに進む前に、以下のようなステップを踏む必要があります。

1. ハードウェアアーキテクチャの設計: MobileNetをハードウェアで実装するためには、畳み込み層、活性化関数、プーリング層など、各種コンポーネントのハードウェアモデルを設計する必要があります。

2. リソース管理: FPGA上でのリソース（メモリ、演算ユニットなど）の利用効率を最適化するための設計を行います。特に、Depthwise Separable Convolutionは、通常の畳み込みに比べてリソース使用量を大幅に削減できるため、その効率的な実装が重要です。

3. パイプライン処理: 高速な処理を実現するために、データ処理をパイプライン化します。これにより、異なる処理ステップを同時に実行し、全体のスループットを向上させます。

4. テストベンチの作成: 設計したハードウェアモデルの動作を検証するために、テストベンチを用いたシミュレーションを行います。これには、実際のゲーム画面データを入力として使用し、期待される出力（特徴量）が得られるかを確認します。

注意点

• BSVでのCNN実装は、一般的なディープラーニングフレームワークを使用する場合と比べて、かなり高度なハードウェア設計スキルを要求されます。
• ハードウェア上での効率的な演算を実現するためには、演算の並列化や最適化が重要になります。

残念ながら、BSVによる具体的なコーディング例を提供することはできませんが、上記の概要とステップが、BSVを用いたCNNの設計と実装の出発点となることを願っています。ハードウェアアクセラレーションを活用することで、リアルタイム性が要求されるアプリケーションにおいて顕著な性能向上が期待できます。

前のブログ 次のブログ

アプローチが3種提案されましたが、Pongに対して最適なアプローチを聞いてみます。

Pongゲームのような環境では、行動の選択肢が比較的限定されており、状況がシンプルであるため、行動価値関数$Q(s, a)$を直接学習するアプローチが特に効果的です。このアプローチでは、各状態での各行動の期待される報酬を評価し、それに基づいて最適な行動を選択します。Pongゲームに適したアルゴリズムの選択肢をいくつか紹介します。

DQN（Deep Q-Network）

• 適用性: DQNは、ディープラーニングを利用して行動価値関数$Q$を近似する方法です。これにより、高次元の状態空間を扱うことができるため、画像のピクセルデータなどを直接入力として使用することが可能です。
• 利点: DQNは経験リプレイと固定Qターゲットの技術を使用して学習の安定性と効率を向上させます。Pongのようなシンプルなゲームであれば、比較的短時間で効果的なポリシーを学習できます。
• 実装例: DQNはAtariゲームで高い性能を発揮したことが示されており、Pongもその中の一つです。

Policy Gradient Methods

• 適用性: ポリシーグラディエント法は、ポリシーを直接パラメータ化し、報酬の期待値を最大化する方向にパラメータを更新します。これにより、確率的ポリシーを学習することができ、特に行動選択の確率性を重要視する場合に適しています。
• 利点: このアプローチは、特にポリシーが確率的である場合に自然な方法であり、学習したポリシーが柔軟であることが期待できます。また、行動価値関数を介さずに直接ポリシーを最適化するため、特定の問題設定では高速に収束する可能性があります。

どのアプローチが良いか

Pongゲームにおいては、DQNが特に初心者にとって取り組みやすく、実証済みの効果があります。画像から直接行動を決定できる能力は、ゲームの状態を効率的に処理するのに役立ちます。一方で、ポリシーグラディエント法も興味深い選択肢であり、特に探索のバリエーションを重要視する場合や、より洗練されたポリシーを求める場合に有効です。

最終的な選択は、具体的な目的、環境の複雑さ、利用可能な計算リソース、そして実装の容易さなど、プロジェクトの要件に依存します。Pongのような比較的単純なゲームでは、DQNから始めることをお勧めしますが、学習の進展と共に他の方法も検討する価値があります。

前のブログ 次のブログ

ポリシーのパラメータ更新について聞いてみます。

ポリシー関数の形が学習の繰り返しによって変化していくプロセスは、基本的には強化学習アルゴリズムにおけるパラメータの更新によって行われます。このパラメータ更新には、エージェントが収集した経験（状態、行動、報酬、次の状態）を基にして行われ、ポリシーを徐々に最適なものへと改善していきます。以下に、ポリシー関数の形式を変化させる主な方法を紹介します。

1. パラメータ更新によるポリシーの改善

• パラメータ化されたポリシー: ディープラーニングを使用した強化学習では、ポリシーはニューラルネットワークによってパラメータ化されます。このネットワークの重みがパラメータとして機能し、これらの重みを更新することでポリシー関数の形式が変化します。
• 勾配上昇法: 確率的ポリシーの場合、ポリシーのパラメータを更新する一般的な方法は勾配上昇法です。この方法では、ポリシーのパフォーマンスを改善する方向にパラメータを調整し、報酬の期待値を最大化します。

2. 行動価値関数を介した間接的なポリシーの改善

• $Q$-学習やDQN: これらのアルゴリズムでは、行動価値関数$Q$を直接学習し、その$Q$値に基づいて最適な行動を選択するポリシーを導出します。ポリシーは間接的に改善され、$Q$関数の更新がポリシーの変化を引き起こします。

3. アクタークリティックアプローチ

• アクタークリティックアルゴリズム: アクター（ポリシー）とクリティック（価値関数）の両方を学習します。クリティックが価値関数を評価し、その評価に基づいてアクターがポリシーを改善します。このプロセスでは、クリティックのフィードバックをもとにアクターのポリシーが更新されます。

パラメータの更新方法

パラメータの更新には様々な手法が存在しますが、一般には以下の要素が関与します。

• 報酬信号: エージェントが取った行動の結果として得られる報酬を、ポリシー改善の指標とします。
• 学習率: パラメータ更新の際のステップサイズを決定します。高すぎると学習が不安定になり、低すぎると収束が遅くなる可能性があります。
• 勾配: パラメータに関するポリシーの性能（報酬の期待値）の勾配を計算し、この勾配方向にパラメータを更新します。

結論として、ポリシー関数の形式を変化させるためには、ニューラルネットワークなどのパラメータ化されたポリシーの重みを、収集した経験データを基に更新していく必要があります。この更新プロセスは、エージェントのパフォーマンスを向上させ、より良い行動選択を可能にするためのものです。

前のブログ 次のブログ