レジスタフォワーディング

レジスタフォワーディングは単にフォワーディング、またはバイパスと呼ばれることがあります。これは前述のRAWハザードのペナルティ(無駄時間、バブル)を軽減もしくは無化するためのものです。

以下のような命令ストリームがあった時、

1: <PC><IF><ID><EX><MA><WB>
2:         <PC><IF><ID><EX><MA><WB>
3:                  <PC><IF><ID><EX><MA><WB>
4:                           <PC><IF><ID><EX><MA><WB>
5:                                   <PC><IF><ID><EX><MA><WB>

1:のデスティネーションレジスタは<WB>ステージで書き込まれますが、直後の2の命令ストリームの<ID>で読もうとすると、5の命令のタイミングまでウエイトしなければなりません。つまり2、3、4の命令実行時間の$3\tau$が無駄になります。

これを高速化するのがレジスタフォワーディングで、2の命令デコード時に先行命令のデスティネーションレジスタ番号と自分の命令のソースレジスタ番号の比較を行います。この時同じレジスタであれば、デスティネーションレジスタから読み出すのではなく、演算器の出力をレジスタの結果とみなします。1の命令の<EX>の出力確定は2の命令の<ID>のレジスタ読み出しと同一タイミングなので、レジスタフォワーディング制御としては<EX>の出力を<EX>の入力にフィードバックします。

このバイパス機構を設けることで、本来$3\tau$のバブルが発生するところをバブル無しとなり、RAWハザードを解消することができます。

機構的にはソースレジスタとデスティネーションレジスタの番号をパイプラインで流し、番号が前後の命令で一致するかを見る比較器を設け、一致した場合は命令コードが示すレジスタの内容ではなく、演算器の出力パスをマルチプレクサで選択します。

前のブログ 次のブログ

パイプラインステージ

プロセッサに話を戻して、一連の処理を複数のパイプラインステージに分解します。一般的にみられるのは、 ステージを<>で表示する約束として、

• <IF>: 命令フェッチステージ
• <ID>: 命令デコード, レジスタリードステージ
• <EX>: 演算ステージ
• <MA>: メモリアクセスステージ
• <WB>: ライトバックステージ

の5段に分割するものです。

このような5段のパイプラインの説明が一般的ですが、いきなり命令フェッチすることはできないので、実は<IF>の前段にはプログラムカウンタ演算の

• <PC>: PC演算ステージ

が必要になります。<PC>の前はといえば、それはその前の<PC>なので、パイプラインの開始はやはり<PC>からです。命令パイプラインなのでプログラムカウンタが原点です。

従って、<PC><IF><ID><EX><MA><WB>の6段ステージと考えるほうが考えやすいです。

1: <PC><IF><ID><EX><MA><WB>
2:         <PC><IF><ID><EX><MA><WB>
3:                  <PC><IF><ID><EX><MA><WB>
4:                           <PC><IF><ID><EX><MA><WB>

各命令の<PC>は通常PCの+4インクリメントを実行します。ここで1の命令が無条件相対分岐命令だった時、分岐命令とオフセットが判明するのが1の<ID>の最後です。従って、それからPC計算を実行すれば、分岐先は4の命令ストリームとなります。

マイクロアーキテクチャによっては、IFの中でPC計算を実施する場合もあります。その場合は<PC>は<IF>に隠蔽され5段パイプラインとなります。このあたりは、マイクロアーキテクチャの考え方で、32bitの加算に$1\tau$かかるのであれば、<PC>も$1\tau$かかるのが妥当ということになります。

投機的実行

従って1の分岐命令は3サイクル命令となります。つまり1の分岐命令のレイテンシは$3\tau$となってしまうので、裏技的な手法を使います。それは、1の命令を<IF>でフェッチしたら、次の<ID>のデコードと同時に投機的に分岐命令だと思って分岐先を計算します。こうすれば分岐先は3の命令から始めることができ、分岐命令のレイテンシは$2\tau$となります。この場合、ほとんどは分岐命令でないので、その場合は<PC>で実行した投機的な実行結果を捨てます。

<PC>では本来次の命令アドレスであるPC+4か、または分岐命令の場合はPC+オフセットのいずれかを計算すれば良いのですが、このように、常に両方計算することで高速化を図ります。

パイプラインプロセッサにはこのような投機的な(ある意味無駄な)実行は良く使われ、例えばレジスタリードも同様です。<ID>でリードするのですが、本来はレジスタ演算命令の場合だけリードすれば良く、レジスタをリードしない命令でレジスタをリードする必要はありません。

投機的実行の場合は<ID>と同時にレジスタリードを行い、<ID>の完了後に不要だった場合は実行結果を捨てます。このためにレジスタリードのための命令のビットフィールドは固定されています。

前のブログ 次のブログ

プロセッサパイプライン

本稿ではコンピュータの設計が主題なので、社内メール処理ではなく、プロセッサパイプラインについて解説します。プロセッサの命令にはRISC形式、CISC形式が存在しますが、ここではRISC形式を取り上げます。

RISCとCISC

このRISC/CISCの別は、実はパイプライン構造から発しており、パイプラインステージ中にメモリアクセスが1回のものをRISC、2回以上のものをCISCと呼びます。元々はメモリ上のデータを書き換えるのがプロセッサの役目なので、CISCが先に発明されたのですが、パイプライン化を考えた場合にパイプラインステージ中に複数のメモリアクセスステージが存在すると、パイプラインハザードが起こりやすくなるのが欠点でした。

これに対して演算をレジスタに限り、メモリアクセスをロードストアのみに限定したのがRISCです。パイプラインステージ中にメモリアクセスが1か所で固定されているため、メモリアクセスにはRAWハザードがありません。レジスタのRAWハザードのみを考慮すれば良いことになります。

RISCのメリット・デメリット

RISCのメリットは種々あり、

• 32bit固定長命令によるデコードの簡略化
• レジスタフィールドの固定により、デコードせずにソースレジスタの読み出しが可能
• 複雑な命令の排除による命令デコーダの高速化

等がありますが、その根本はメモリ演算の廃止によるものです。メモリアクセスはロードストアのみと割り切り、演算はレジスタを対象とすることでパイプライン制御を単純化し、上記の特徴も併せて高速化が可能となりました。

一方で命令長が32bit固定でかつ複雑な命令を単純な命令の組み合わせで実行することから、命令コード効率はあまり良くありません。ワークステーション等では問題なかったこの欠点は、16/32bit混合の導入により組み込み向けの応用では改善が行われています。

前のブログ 次のブログ

パイプラインハザード

それでは100段でも1,000段でも細かく切れば性能は100倍、1,000倍になるかというと、そう単純には行きません。それには複数の理由があります。

• パイプラインステージは同じレイテンシ$\tau$である必要がある。
• ステージ間の箱(パイプラインレジスタ)によるレイテンシ($\alpha$)が増加する
• パイプラインハザードの存在により、性能向上できない

ひとつの大きな処理の中を均等に細かい時間間隔の$\tau$で切るのは、ハードウエア構成上限界があります。また、パイプラインレジスタのレイテンシの追加は、性能低下原因となります。最後にパイプラインハザードの存在により、後続ステージの待ち合わせが発生し、パイプライン中に隙間(バブル)が生まれます。これも性能低下原因となります。

RAWハザード

パイプラインハザードのひとつにRAW(Read After Write)ハザードがあります。これは、パイプラインステージの前半、例えばAの処理において使用する封筒に、Cの処理において投函される封筒が必要だったとします。すると、処理としてはCが終了しないとAが開始できませんが、パイプラインステージ中ではAのほうが先になっているので、図453.1の左のようには2番目の処理が開始できず、図453.1の右のように、$2\tau$のバブル(＝無駄サイクル)が発生してしまいます。これをパイプラインハザードと呼びます。

前のブログ 次のブログ

機械の場合

人間であれば器用に3つの処理を一人で実行することができますが、コンピュータは機械なので一つのことしかできません。つまり、A専用、B専用、C専用の3つの機械を並べて処理することになります。

• 社内メール封筒を取りに行く ----- A専用機
• 宛名を書いて書類を入れて封をする ----- B専用機
• 社内メール投函箱に投函しに行く ----- C専用機

レイテンシは前稿の3人がかりと同じように$3\tau$で、スループットはその逆数である$\frac{1}{3\tau}$です。これを表452.1にまとめます。

パイプライン化

さて、ここでシステムのスループット(システム性能)は$\frac{1}{3\tau}$ですが、その向上を考えてみます。

性能向上のためレイテンシ短縮を考えると、$3\tau$以下にするのは困難です。ところが、AとB、BとCの間に箱を置いて、$3\tau$ではなく、$\tau$毎に処理を入力したらどうでしょうか。ちょうどバケツリレーのように$\tau$毎に処理が可能です。

スループットから見てみましょう。元々A, B, Cの機械単体でのスループットは$\frac{1}{\tau}$だったのですが、システムで組み合わせると$\frac{1}{3\tau}$のように33%に低下していました。

例えばA機械は、BとCが働いているときには遊んでいたわけです。これを間に箱を入れて切り離すようにした結果、レイテンシはほとんど変わらずに、スループットは3倍の100%に向上しました。つまり、A, B, Cそれぞれの機械の能力を100%出し切ることができたわけです。

このように、パイプライン化はあまりコストをかけることなく、性能を大幅に向上できる特長があります。一般的には、全体を$n$ステージのパイプラインで構成すれば、レイテンシはあまり変わらず$n\tau+\alpha$と若干増加するだけです。一方、スループット(性能)を$n$倍のように大幅に引き上げることができます。

前のブログ 次のブログ

パイプラインとは

ノイマン型計算機の進歩の中で命令パイプライン技術が考案されました。パイプライン制御はコンピュータの性能向上の手法の重要な技術のひとつです。詳細は命令パイプライン制御を見てください。

本稿ではパイプライン制御を解説していきます。このパイプライン制御を理解するには、まずスループットとレイテンシについて、正しく理解する必要があります。

スループットとレイテンシ

まずスループットとは、Wikipediaにもあるように、単位時間当たりの処理量です。コンピュータの処理能力は上げるほうが良いので、スループットを上げることを考えます。

次にレイテンシとは、端的に言えば入力から出力までの処理時間のことで、普通はその逆数がスループットになります。従って、処理能力を上げるにはレイテンシを小さくすることを考えます。

ところが、レイテンシを短くするのは非常に大変です。単純な仕事で見てみましょう。会社で社内メールを出すのに、

• 社内メール封筒を取りに行く ----- A処理と呼ぶ
• 宛名を書いて書類を入れて封をする ----- B処理と呼ぶ
• 社内メール投函箱に投函しに行く ----- C処理と呼ぶ

上記のA～C処理の3ステップがあるものとします。どれも同じ時間$\tau$だけかかるとすれば、レイテンシは$3\tau$です。一人の人間がフルに働いても$3\tau$に1通しか処理できません。処理能力であるスループットは、上記から$\frac{1}{3\tau}$となります。

3人でやってもレイテンシは$3\tau$と変わりません。Cを実行するにはBが完了していなければならない依存性があり、Bを実行するにはAが完了していなければならない依存性があるからです。これがレイテンシを短縮するのが困難な理由です。

前のブログ 次のブログ

だいぶ前の記事ですが、テストベンチのBSVと、モジュールのBSVからVerilogを生成し、Verilogシミュレーションを実施しました。BSVではテストベンチにおいてクロックとリセットが自動生成され、暗黙的にモジュールに供給されます。一方、Verilogでは明示的にテストベンチにクロックとリセットを供給する必要があります。前の記事では、テストベンチ内にその処理を行う記述をインクルードする方法を用いました。

ここでは、最上位からそれらの信号を供給する手法をとります。これにより、よりスマートにVerilogシミュレーションが実行できます。まず、原始最上位ファイルを用意します。最上位からはテストベンチを呼び出しています。

最上位ファイル:mkTop.v

module mkTop () ;
   /*AUTOREGINPUT*/
   mkTb Tb_inst(/*AUTOINST*/);
  initial begin
    RST_N = 1'b0;
    #30;
    RST_N = 1'b1;
  end
  initial begin
    CLK = 1'b0;
    forever begin
       #5 CLK = ~CLK;
    end
  end
endmodule // mkTop  

これに対して、Verilog-modeのオートコネクションコマンドであるC-c C-aを用いてポートの追加を行えば、

最上位ファイル:mkTop.v

module mkTop () ;
   /*AUTOREGINPUT*/
   // Beginning of automatic reg inputs (for undeclared instantiated-module inputs)                
   reg                  CLK;                    // To Tb_inst of mkTb.v                            
   reg                  RST_N;                  // To Tb_inst of mkTb.v                            
   // End of automatics                                                                            
   mkTb Tb_inst(/*AUTOINST*/
                // Inputs                                                                          
                .CLK                    (CLK),
                .RST_N                  (RST_N));
  initial begin
    RST_N = 1'b0;
    #30;
    RST_N = 1'b1;
  end
  initial begin
    CLK = 1'b0;
    forever begin
       #5 CLK = ~CLK;
    end
  end
endmodule // mkTop              

のように、テストベンチに対してクロックとリセットが接続されます。

最上位、テストベンチ、モジュールを結合した実行ファイルを生成します。エラーが出ることもなく実行ファイルが生成され、実行ファイルによりVerilogシミュレーションを実行すれば、

\$ iverilog mkTop.v mkTb.v mkFibOne.v -o mkFibOne.exev
\$ ./mkFibOne.exev
1
1
2
3
5
8
13
21
34
55
89
144
233
377
610
987
1597
2584
4181
6765
10946

このように、正しくVerilogシミュレーションが行われ、前記事と同じ結果となります。

結論としては、この記事のように自動結合を使用すれば、前記事のようにincludeを埋め込む必要はありませんでした。

前のブログ 次のブログ

BoktechからレベコンICのみ実装のV10ボードが届きました。図445.1のように、基板は5枚でわずか1.0 USD、レベコンICの実装は最低2枚からで、その費用は部品代が6.64 USD、実装費その他を加えて29.83 USDでした。今回はDHLを使用したので若干輸送費が高く34.0 USDで、合計64.83 USDでした。

他の部品を半田付けして組み立て動作させたところ、フルハードウェア(マイコン、ソフトウェアは一切使用しない)によるSpace Invadersが正常に動作しました。

図445.2のように、使用機材はAvnet製Ultra96ボードに弊社Ultra96toPMODボードの他、インタフェースのためのPMODボード類です。これでUltra96toPMODボード回路はようやくfixとなります。

V10ボードデータ一式はこの場所にあります。以下はデータのREADMEです。

Gerber data and Pick&Place data for Ultra96toPMOD mezzanine board.

https://qiita.com/mocapapa/items/a2faa710503e4affa88b

• BokTech-Bom-Ultra96toPMODV10_minimum.xlsx ---- BOM file for BockTech
• Ultra96toPMODV10.brd ---- EAGLE layout data
• Ultra96toPMODV10.sch ---- EAGLE schematic data
• Ultra96toPMODV10_2021-10-22.zip ---- Gerber data for two layer production (SeedFusion 2layer)
• Ultra96toPMODV10.mnt.zip ---- Pick & Place file for PCBA
• JLCPCB-PP-Ultra96toPMODV10_minimum.xlsx ---- Pick&Place file for JLCPCB
• JLCPCB-Bom-Ultra96toPMODV10_minimum.xlsx ---- BOM file for JLCPCB

前のブログ 次のブログ

BoktechにオーダーしていたV9基板が届いたので、組み立て火を入れたところ、JoystickスイッチONのタイミングで垂直同期にノイズが乗る現象が再発しました。

図442.1の上側黄色トレースが、X_RIGHT_SW信号(ボードへの入力、負論理)、下側青色トレースがVSYNC(ボードからの出力、負論理)です。スイッチのチャタリングが、本来無関係のはずの同期信号にクロストークしています。

実際にこのVSYNCのノイズにより、外付けモニタが誤動作しています。具体的には同期が乱れるため、それを自動的に検知し、一定期間ブランキングしています。

レベコンICのVSYNCの隣接端子であるX_RIGHT_SW信号からノイズが回り込んでおり、一つ離れたX_LEFT_SW信号からの回り込みはありません。

この現象は、開発初期のV4で起きていたため、V5からスイッチ信号と同期信号を同じレベコンICに入力しないようにしていました。その後、配線に近い場所があったため、ロジカルには大丈夫だろうと、V9で同じレベコンICに入れたのですが再発しました。論理的には問題ないはずなので、あとは以下の2つ程度が考えられます。

• チャタリング⇒レベコンICの電源・グラウンドの揺れ⇒同期信号にノイズ
• レベコンICの内部でのクロストーク

ところが、4chオシロで観測したところ、電源・グラウンドの揺れはありませんでした。従って、原因はレベコンIC内部でのクロストークと考えられます。修正がここまでかかった原因は、メーカー製ICを信用し過ぎていたことに依るものです。

以上より、信号を入れ替え、ズイッチ信号と同期信号のレベコンICを別々に変更しました。これをV10とします。V10の基板図を図442.2及び3に示します。

前のブログ 次のブログ

改版中のV9ボードの基板図を図437.1及び2に示します。

前のブログ 次のブログ