Posts Tagged with "BSV"

既に発行済みのブログであっても適宜修正・追加することがあります。
We may make changes and additions to blogs already published.
posted by sakurai on January 18, 2024 #736

サウンドミキサーの検証

bsvでモジュールを開発するに際して、正解値を出力するverilogモジュールを作成しました。それぞれのモジュールを駆動するテストベンチはbsvのステートマシン合成で簡単に作成できます。verilogの世界で統合するために、テストベンチの上位にverilogの最上位階層を設けます。なぜならbsvの最上位であるテストベンチ階層にはクロックもリセットも存在しないため、verilogの最上位階層を設けてクロックとリセットをテストベンチに供給してやる必要があるためです。

ここまでは通常のBSV⇒verilogシミュレーション手法ですが、最上位階層を統合して一つにすれば、その中に2つのbsvから生成されたverilogのステートマシンとそれに接続されるverilogモジュールが配置されることになります。

表736.1 verilogとbsvの階層構造
Verilog
ファイル名 自モジュール名 子モジュール名
topVeri.v mkTop mkTbVeri
mkTbVeri.v
(自モジュール名と一致させる)
mkTbVeri mixer
mixer.v
(自モジュール名と一致させる)
mixer -
BSV⇒Verilog
bsvファイル名 生成verilog
ファイル名
自モジュール名 子モジュール名
--- top.v mkTop mkTb
TbMixer.bsv mkTb.v
(自モジュール名と一致するファイル名が生成)
mkTb mkMixer
Mixer.bsv mkMixer.v
(自モジュール名と一致するファイル名が生成)
mkMixer -

top階層からverilogモードによるC-c C-aで自動結合するには、自モジュール名とファイル名が一致する必要があります。

ここで最上位階層top.vを統合して一つにし、テストベンチを2つ配置します。これで正解値と比較してデバッグし以下のミキサーが完成しました。以下にコードを示します。

typedef Int#(8) Esound_t;
typedef Int#(16) Lsound_t;

interface Mixer_ifc;
   (* prefix="" *)
   method Lsound_t mout(
      Esound_t ch0,
      Esound_t ch1,
      Esound_t ch2,
      Esound_t ch3
      ); // output
   (* prefix="" *)
   method Bool soundon(
      Bool son0,
      Bool son1,
      Bool son2,
      Bool son3
      ); // output
endinterface

(* synthesize, always_enabled = "mout, soundon", no_default_clock, no_default_reset *)
module mkMixer(Mixer_ifc);
   function Bit#(9) repeatBit(Bit#(1) b);
      Bit#(9) result = 0;
        for (Integer i = 0; i < 9; i = i + 1) begin
           result = result << 1;
           result[0] = b;
        end
      return result;
   endfunction

   method Lsound_t mout(
      Esound_t ch0,
      Esound_t ch1,
      Esound_t ch2,
      Esound_t ch3
      ); // output
      let tmp0 = pack(ch0);
      let tmp1 = pack(ch1);
      let tmp2 = pack(ch2);
      let tmp3 = pack(ch3);
      Int#(16) itmp0 = unpack({repeatBit(~tmp0[7]),tmp0[6:0]});
      Int#(16) itmp1 = unpack({repeatBit(~tmp1[7]),tmp1[6:0]});
      Int#(16) itmp2 = unpack({repeatBit(~tmp2[7]),tmp2[6:0]});
      Int#(16) itmp3 = unpack({repeatBit(~tmp3[7]),tmp3[6:0]});
      Int#(16) tmp4 = itmp0 + itmp1 + itmp2 + itmp3;
      let tmp5 = tmp4 << 6;
      return tmp5;
   endmethod
  method Bool soundon(
      Bool son0,
      Bool son1,
      Bool son2,
      Bool son3
      ); // output
      let sdon = son0 || son1 || son2 || son3;
      return sdon;
   endmethod
endmodule   

まずげた履き符号から2の補数表現に変換するために、MSBの反転を行います。次にそれを符号拡張し16ビット整数とします。それらを加え合わせてスケーリングを行います。

シミュレーションの結果、4つのチャネルにどんな値が入力されてもオーバーフローやアンダーフローが起きないことを検証しています。


左矢前のブログ 次のブログ右矢

posted by sakurai on January 17, 2024 #735

サウンドミキサーの仕様

8bit符号無し$\dagger$のwave形式のサウンドを4多重して16bit符号付きに変換するサウンドミキサーを作成します。

  • 入力: 4チャンネルch0~3のwave(PCM, 11.025KHz、8bit、Mono、メタデータ無し)
  • 出力: 1チャンネルwave(PCM, 11.025KHz、16bit、Mono、メタデータ無し)

まず8bit符号無し数を加算操作を行うために8bitの2の補数表現に変換します。それにはゲタ8'h80を引き算する必要があります。しかしながら、引き算はコストが高いため、MSBの反転を行います。以下にそれで良いことをChatGPTに証明してもらいました。

8bitゲタ履き数を8bitの2の補数表現に変換するにはゲタを引き算するのが常道ですが、MSBの反転でも良いことを数学的に証明してください。

ChatGPT:

8ビットの「ゲタ履き数」(8'h80がゼロとされる特殊な表現)を8ビットの2の補数表現に変換する際に、MSBのみを反転する方法が等価であることを証明します。

特殊な表現

この表現では、8'h80がゼロとされます。したがって、この表現における任意の値 $V$は、標準的な2の補数表現における値 $V'$ に$128$(あるいは2進数で$1000\,0000_2 $)を加えたものとして表現されます。

つまり、$V = V' + 128$ または$ V = V' + 1000\,0000_2$。

2の補数表現への変換

通常の2の補数表現へ変換するには、特殊な表現から128($1000\,0000_2$)を引きます。

$V' = V - 128$または$V' = V - 1000\,0000_2$

MSBの反転

MSBを反転するということは、数値から$1000\,0000_2$(128)を引くか、加えることと等価です。なぜなら、MSBが1の場合は1を0に反転(-128する)、MSBが0の場合は0を1に反転(+128する)からです。

したがって、MSBの反転は以下の操作に等しいです:

  • MSBが1の場合(つまり $V$が128以上の場合)、$ V' = V - 1000\,0000_2 $。
  • MSBが0の場合(つまり $V$が127以下の場合)、$ V' = V + 1000\,0000_2$。

証明

MSBの反転が128の加算または減算と等価であることを考えると、この操作は常に特殊な表現を標準的な2の補数表現に変換します。

  • $V $が128以上の場合、MSBは1です。したがって、MSBを反転すると$ V - 128 $になります。これは2の補数表現における負の値に相当します。
  • $V $が127以下の場合、MSBは0です。したがって、MSBを反転すると $V + 128$になります。しかし、$ V $が127以下であるため、この加算はオーバーフローを引き起こし、結果として128を引くことになります。これは2の補数表現における正の値に相当します。

したがって、MSBのみを反転する操作は、特殊な8ビットの「ゲタ履き数」を標準的な8ビットの2の補数表現に変換するための有効な方法であることが証明されます。


$\dagger$:符号無しの定義は0以上の正の整数のみを扱うデータ型であるため、正しくはゲタ(8'h80)履き数


左矢前のブログ 次のブログ右矢

posted by sakurai on January 11, 2024 #731

CmodA7toPMODボード

基本的には過去記事に対してボードをCmodA7ボードに変更したものです。 DigilentからCmodA7ボードを購入しました。このボードは(弊社開発の)PMOD変換ボードは必要となりますが、総額では安くSpace Invadersを動かすことができます。

図%%.1
図731.1 Cmod A7ボード

周辺インタフェースボード等

Space Invadersを動作させるには、CmodA7ボードの他に必要なものは以下のとおりです。

CmodA7-35ボードへの移植

Arty-35とFPGAアーキテクチャが同じであり、何も変更せずにそのままで動作しました。


左矢前のブログ 次のブログ右矢

posted by sakurai on January 4, 2024 #728

BSVに簡単に変換できるからC/C++が優位とは論理が反対です。それはC/C++の優位性が無いことを示すものです。また合成できない機能についてはBSVに関係のないC/C++の欠点です。

逆です。それらはC/C++の優位性が無いことを表すものです。もともとポインタや動的メモリ管理等は合成できないのがC/C++の欠点です。なのでC/C++の優位性はそれらを除く逐次処理です。ところがその部分は自動ステートマシン合成を用いて容易にBSVに移植できるので、結論としてC/C++の優位性はほぼなく、BSVの優位性だけが示されるのではないですか?

ChatGPT
ご指摘の通り、C/C++のハードウェア合成における逐次処理の部分がBSVに容易に移植できる場合、C/C++の特有の優位性は大きく減少する可能性があります。特に、以下の点を考慮すると、BSVの優位性がより顕著になります:

  1. ハードウェア特有の機能:
    BSVはハードウェア設計のために特化された言語であり、ハードウェアの並行処理、同期、タイミング制御などの機能を直接的に表現できます。

  2. 自動ステートマシンの合成:
    BSVはC/C++の逐次的なコードをステートマシンに変換する能力があり、これにより、C/C++の逐次処理の優位性が相対的に低下します。

  3. 高レベルの抽象化:
    BSVはハードウェアの動作をより高い抽象化レベルで記述でき、複雑なハードウェアロジックの実装を容易にします。

C/C++によるハードウェア合成の主な利点の一つである既存のコードベースの再利用は、ポインタや動的メモリ割り当てなどの合成不可能な特性を除けば、BSVによってカバーできる範囲が広がります。結果として、特に逐次処理に関しては、BSVによる合成がより効率的かつ適切な選択肢となる可能性が高まります。

これにより、ハードウェア設計におけるBSVの優位性が強調され、C/C++の利用が必要とされるケースは限定的なものになるかもしれません。


所感:
ChatGPTはこのように平気で誤った論理的結論を導出することがあることに注意が必要です。一方、考え方の幅を広げて貰うには最適なことからそのような目的で使うべきであり、結論を導いて貰うべきではありません。

BSVとC/C++の比較の結論としては、技術的にはBSVのほうが圧倒的に有利であり、一方非技術的には、例えば学習コスト、ユーザベース、ツールチェイン等の面でC/C++が有利と理解しました。


左矢前のブログ 次のブログ右矢

posted by sakurai on December 29, 2023 #727

C/C++の優位性について議論しようとしたら、むしろ欠点に話が向いてしまいました。

それらはむしろC/C++の欠点なのではないですか?ポインタや動的メモリ管理などはそもそも合成できません。従ってBSVの問題ではありません。私が指摘したのは、C/C++が有利だという点についても簡単にBSVに変換可能という点です。

ChatGPT
おっしゃる通りです。提案された方法によって、C/C++コードをBSVなどのハードウェア記述言語に比較的容易に変換することが可能であるという点は、C/C++の優位性を示しています。特に、以下の点でその優位性が強調されます:

  1. 簡単な変換:
    C/C++の制御構造(例えばfor、while、if-else文)は、比較的簡単にBSVの制御構造に変換できます。これにより、既存のソフトウェアロジックをハードウェア設計に適応させる際の手間が減ります。

  2. プログラミングのアクセシビリティ:
    既にC/C++で開発されたロジックを、ハードウェアの記述に活用できるため、ソフトウェア開発者にとってはハードウェア設計のアクセシビリティが向上します。

  3. プロトタイピングの迅速化:
    C/C++のコードをBSVに変換することで、ハードウェアプロトタイピングプロセスを迅速化できる場合があります。特に、既存のアルゴリズムをハードウェアに迅速に実装したい場合に有効です。

ただし、ポインタ操作や動的メモリ割り当て(mallocなど)のようなC/C++の特定の特性は、直接的なハードウェア合成には適しておらず、これらを使用するコードの部分は、ハードウェア記述に変換する際に適切な代替手段を考慮する必要があります。従って、C/C++からBSVへの変換は、ハードウェア設計におけるC/C++の特性や限界を理解した上で行う必要があります。

結論として、C/C++のコードをBSVなどのハードウェア記述言語に変換することは、特定の条件下では有効なアプローチであり、C/C++の利用に関連する一定の優位性を提供します。ただし、このプロセスはハードウェア設計の特性を十分に理解し、C/C++の特定の制約を考慮することが重要です。


左矢前のブログ 次のブログ右矢

posted by sakurai on December 28, 2023 #726

過去記事の続きです。BSVの優位性は言うまでもないので、C/C++の優位性について話を絞ります。やはり既存のコードベース再利用が主のようです。

C/C++の優位性は既存のCコードの再利用が主ですが、それも先に述べた方法で容易に自動ステートマシンを合成可能です。この観点からはどうでしょうか?

ChatGPT
C/C++コードをBSVなどのハードウェア記述言語に移植する際のプロセスを指摘していただいた通り、特定の構文変更によって自動的にステートマシンに合成することは可能です。しかし、このアプローチにはいくつかの留意点があります:

C/C++からBSVへの移植の課題

  1. 直接変換の限界:
    単純な構文変更による自動変換は、基本的な制御フローにおいては有効かもしれませんが、C/C++の高度な機能や特定のアルゴリズムの実装では適用が難しい場合があります。特に、ポインタ操作、動的メモリ管理、複雑なデータ構造などの特性はハードウェア記述に直接対応しないため、これらの要素を含むコードは追加の手作業や再設計が必要になる可能性があります。

  2. ハードウェア特有の最適化の必要性:
    ハードウェア設計においては、リソースの利用効率、タイミングの最適化、並行処理の管理など、ハードウェア特有の考慮事項が重要になります。これらの要素はC/C++のコードには通常含まれておらず、ハードウェア合成において適切に扱う必要があります。

  3. ハードウェアとソフトウェアのパラダイムの違い:
    ソフトウェアプログラミングとハードウェア記述は根本的に異なるパラダイムです。C/C++のコードをBSVに移植する際には、このパラダイムの違いを理解し、ハードウェアの性能と機能に適した形にコードを再構築することが重要です。

結論

既存のC/C++コードの再利用は、一定の範囲内で有効なアプローチですが、ハードウェア設計における全てのニーズに対応するわけではありません。特に、ハードウェア特有の要件や最適化を考慮した再設計や調整が必要な場合があります。C/C++からBSVへの移植は、ハードウェア設計の基本的な概念と特性を理解した上で行う必要があり、プロセス全体が単純な構文変更以上のものであることを認識することが重要です。


左矢前のブログ 次のブログ右矢

posted by sakurai on December 22, 2023 #722

やはり既存のコードベースの再利用が主体のようです。

C/C++は逐次処理で書きます。たとえばfor, while if else など。ところがBSVでもこれらは使用でき、容易にFSMに合成できます。とするとC/C++の優位性はあまりないのでは?

ChatGPT
C/C++によるハードウェア合成とBSV(Bluespec SystemVerilog)による合成の間には、確かにいくつかの重要な違いがありますが、C/C++の利用には依然として特定の状況での優位性が存在します。これらは主に、開発のアクセシビリティ、既存のソフトウェアリソースの活用、および特定の種類のハードウェアプロトタイピングに関連しています。

C/C++によるハードウェア合成の優位性

  1. 既存のソフトウェアリソースの再利用:
    C/C++を使用する主な利点の一つは、既存の豊富なソフトウェアコードベースとアルゴリズムをハードウェア設計に再利用できる点です。特に、ソフトウェアで実装されている複雑なアルゴリズムをハードウェアに迅速に移植したい場合に有効です。

  2. ソフトウェア開発者のアクセシビリティ:
    C/C++は多くのソフトウェアエンジニアにとって馴染み深く、ハードウェア設計の専門知識が限られた開発者でもアクセスしやすいです。このため、ソフトウェア開発チームがハードウェアのプロトタイピングや概念実証に関わる場合に便利です。

  3. 迅速なプロトタイピング:
    C/C++ベースの合成ツールを使用することで、ソフトウェア定義のアルゴリズムを迅速にハードウェアに変換し、プロトタイピングとテストを素早く行うことができます。

BSVによる合成の特性

BSVは並行処理とハードウェアの特性を直接的にモデル化するための強力な機能を提供します。これにより、複雑なハードウェアロジックや高度なハードウェア設計をより効果的に扱えます。

BSVは、ハードウェアのタイミング制御、状態管理、並行処理などを直接的に記述することが可能で、特に複雑なハードウェアシステムの設計に適しています。

結論

BSVが提供するハードウェア記述の能力は、複雑なハードウェア設計において強力な利点を提供しますが、C/C++による合成は特定のシナリオ、特に既存のソフトウェアリソースの活用や迅速なプロトタイピングが求められる場合に依然として有用です。しかし、C/C++による合成はハードウェア設計の精密な制御や最適化においては限界があるため、ハードウェアの複雑さが増すにつれてBSVのような専用のハードウェア記述言語の優位性が顕著になります。


左矢前のブログ 次のブログ右矢

posted by sakurai on December 21, 2023 #721

BSVが優位なのは良くわかったので、逆にC/C++に向いた回路を聞いてみます。

今までの話だとC/C++に向いた回路は無いように思いますが、BSVよりもC/C++のほうが向いた回路はありますか?

ChatGPT
C/C++によるハードウェア合成が特に適している場面は確かにあります。これらは主に、C/C++のコードベースから直接ハードウェアを生成する必要がある場合や、ソフトウェア定義のロジックを素早くハードウェアプラットフォームにデプロイする場合に見られます。

C/C++による合成が適しているケース

  1. 既存のC/C++コードベースの活用:
    既存のC/C++のアルゴリズムやロジックをハードウェアに移植したい場合、C/C++に基づいた合成は有効です。これは、既存のソフトウェアリソースを再利用して、開発時間を短縮したい場合に特に有用です。

  2. ソフトウェア開発者にとってのアクセシビリティ:
    C/C++はソフトウェアエンジニアにとって非常に馴染み深い言語です。ハードウェアの専門知識が限られているソフトウェア開発者が、ハードウェア設計に関わる場合、C/C++による合成は入門しやすい選択肢となります。

  3. プロトタイピングと迅速なイテレーション:
    C/C++ベースの合成ツールを使用すると、ソフトウェアアルゴリズムを迅速にハードウェアプロトタイプに変換し、テストとイテレーションを素早く行うことが可能です。

  4. 特定のドメイン固有のアプリケーション:
    一部のドメイン固有のアプリケーション(例えば、デジタル信号処理や画像処理など)では、高レベルの合成ツールがC/C++アルゴリズムを効率的にハードウェアにマッピングすることができます。

決定における考慮事項

  1. プロジェクトの要件:
    プロジェクトの具体的な要件と目標に基づいて、最適なアプローチを選択します。

  2. 開発チームのスキルセット:
    チームの既存の知識と経験を考慮して、C/C++またはBSVのどちらがより効果的かを決定します。

  3. 開発時間とリソース:
    開発のスピードと利用可能なリソースに基づき、最も適切な技術を選択します。

C/C++による合成は、特定のシナリオや要件において依然として有効な選択肢です。ただし、複雑なハードウェア設計や高度な並行処理が必要な場合には、BSVのようなハードウェア記述言語がより適している場合が多いです。


左矢前のブログ 次のブログ右矢

posted by sakurai on December 20, 2023 #720

他にはどうでしょうか?newral networkを用いた機械学習用途では?

ChatGPT
ニューラルネットワークを用いた機械学習アプリケーションのハードウェア実装においては、C/C++による合成とBSV(Bluespec SystemVerilog)による合成はそれぞれ異なる強みと限界を持ちます。ニューラルネットワークは大量の並行計算、複雑なデータフロー、および高度な数学的演算を必要とするため、これらの要件を効果的に満たす方法を選択することが重要です。

C/C++による合成での困難点

  1. 高度な数学的演算:
    ニューラルネットワークは、多くの場合、複雑な数学的演算(例えば、行列演算)を含みます。C/C++ではこれらの演算を直接的にハードウェアレベルで表現するのが困難です。

  2. 並行処理とデータフロー:
    大規模なニューラルネットワークでは、多数のニューロンが並行して動作します。C/C++でこれらの並行処理とデータフローを効率的に扱うことは難しい場合があります。

  3. 合成ツールの制約:
    C/C++からハードウェア記述に変換する合成ツールは、ニューラルネットワーク特有の最適化を自動的には行えないことがあります。

BSVによる合成でのアプローチ

  1. 並行処理の効率的な表現:
    BSVはハードウェアの並行処理を効率的に表現するための高レベルの抽象化を提供します。これにより、ニューラルネットワークの並行計算をより自然にモデル化できます。

  2. カスタマイズ可能なデータフロー:
    BSVを使用すると、ニューラルネットワークの複雑なデータフローを直接的に記述し、最適化することが可能です。

  3. ハードウェアリソースの効率的な利用:
    ニューラルネットワークに求められる計算リソースをBSVを用いて効率的に割り当てることができます。

結論

ニューラルネットワークのハードウェア実装においては、BSVのようなハードウェア記述言語が、並行処理、複雑なデータフロー、および数学的演算の表現において優位性を持ちます。特に、複雑なニューラルネットワークモデルや大規模な計算が必要な場合、BSVの提供する高レベルの抽象化とハードウェアリソースの効率的な利用が重要になります。ただし、C/C++による合成ツールも進化しており、特定のアプリケーションには適した選択肢になる可能性があります。


左矢前のブログ 次のブログ右矢

posted by sakurai on December 19, 2023 #719

他にはどうでしょうか?インベーダーゲームやPong等のTVゲームは?

ChatGPT
インベーダーゲームやPongのようなクラシックなTVゲームのハードウェア設計において、C/C++による合成とBSV(Bluespec SystemVerilog)による合成は異なるアプローチを提供します。これらのゲームは比較的単純なロジックとグラフィックスを持っていますが、リアルタイムのインタラクションと視覚的フィードバックが必要です。それぞれの方法の適用における考慮点は以下の通りです。

C/C++による合成での困難点

  1. リアルタイム処理: C/C++ではリアルタイム処理の要件を満たすことが可能ですが、ハードウェアのタイミングと同期に関連する細かな制御が必要になります。

  2. グラフィックス処理: ゲームのグラフィックス処理には特定の描画ロジックが必要ですが、C/C++でこれを直接的に表現するのは非効率的な場合があります。

  3. ユーザーインターフェースの制御: プレイヤーの入力とゲームの状態の間のインタラクションを管理するには、C/C++での明確なロジックが必要です。

BSVによる合成でのアプローチ

  1. 並行処理と同期: BSVは、複数の入力と出力をリアルタイムで処理するのに適しており、ゲームロジックの同時並行性を扱うのに有効です。

  2. ハードウェアの直接制御: ゲームの描画ロジックやプレイヤーのインタラクションに関連するハードウェアの直接的な制御に適しています。

  3. 効率的なリソース利用: ゲームの性能要求を満たすための効率的なリソース利用が可能です。

結論

インベーダーゲームやPongのようなTVゲームを設計する際には、BSVのようなハードウェア記述言語の方がC/C++よりも適している可能性があります。これは、リアルタイム処理、並行処理、およびハードウェアの直接的な制御に関する要件がBSVの提供する抽象化と機能により効果的に対処できるためです。ただし、具体的な設計要件やチームの既存のスキルセットにも依存します。


左矢前のブログ 次のブログ右矢


ページ: