パイプライン制御の無効化論理

図468.1 CV32E40Pパイプライン図(再掲)

一方、後段にバブルを流すinvalidate信号は、EXWBレジスタのC(lear)信号ですが、やや冗長になっています。EXWB.C信号に(467.1)を代入し、ドモルガンの定理を用いて整理すれば、 $$ \require{cancel} \begin{eqnarray} \text{EXWB.C}&=&\text{wb_ready }\cap\text{!ex_valid}\\ &=&\text{wb_ready }\cap\text{(!granted }\cup\text{!wb_ready)}\\ &=&\text{(wb_ready }\cap\text{!granted) }\cup\bcancel{\text{(wb_ready }\cap\text{!wb_ready)}}\\ &=&\text{wb_ready }\cap\text{!granted} \end{eqnarray} \tag{468.1} $$ 使用ゲートは同じで、配線を繋ぎ変えるだけで1段論理になるので、2段通すのは若干無駄な論理のように見えます。論理合成を用いれば上記のように最適化されるでしょうけど。

図468.2に修正後の回路を示します。

図468.2 論理修正後パイプライン制御論理

前稿等で検討したように、パイプラインバブルは後段へ流すものですから、当該ステージ、この場合は<EX>にウエイト要因があり($=\text{!granted}$)、かつ後段である<WB>からウエイトが来ていない($=\text{wb_ready}$)ときに限り、後段を無効化する論理となり、(468.1)は正しいです。そして、この無効化信号は、パイプラインストリームのキャンセルにも用いられます。

パイプライン制御の有効論理

EXWB.Cの反転論理である<EX>有効信号を新たに$ex\_valid$とすれば、 $$ \require{cancel} \begin{eqnarray} ex\_valid&=&\text{!wb_ready }\cup\text{granted }\\ &=&wb\_wait\text{ }\cup\text{ }!exs\_wait \end{eqnarray} \tag{468.2} $$ となります。

---

前のブログ 次のブログ

既存RISC-Vの研究

このページでパイプライン制御の図を見つけたので、以下に示します。これは4ステージのインオーダーパイプラインプロセッサです。

図467.1 CV32E40Pパイプライン図

パイプライン制御の論理を追ってみます。EXWBは<EX>と<WB>を分離するレジスタです。通常は<EX>の結果を保持するのでEXパイプラインレジスタと呼びますが、もちろん<WB>の入力でもあるため、この設計ではそれをわかりやすいようにEXWBとしているようです。

パイプライン制御のイネーブル論理

まずイネーブル論理を見てみると、 $$ \begin{eqnarray} \text{EXWB.E}&=&\text{ex_valid}\\ &=&\text{ex_ready}\\ &=&\text{granted }\cap\text{wb_ready} \end{eqnarray} \tag{467.1} $$ これは

• <EX>が正当であるという、後段に対する有効論理、かつ
• <EX>以降のステージが受け入れ可能という、上段に対するイネーブル(ウエイトの否定)

を同時に意味します。

上段に対するウエイト信号を新たに$ex\_wait(=\text{!ex_ready})$とし、<EX>の許可信号である$\text{granted}$の逆論理を、<EX>のステージウエイトとして新たに$exs\_wait(=\text{!granted})$と名付ければ、

$$ \begin{eqnarray} ex\_wait&=&\text{!ex_ready}\\ &=&\text{!(granted }\cap\text{wb_ready)}\\ &=&\text{!granted }\cup\text{!wb_ready}\\ &=&exs\_wait \cup wb\_wait \end{eqnarray} \tag{467.2} $$ ただし、$wb\_wait=!\text{wb_ready}$

前述のように、ウエイトは、当該段のウエイトに下段のウェイト信号のORを取りながら、上段へパイプラインとは逆向きに同一サイクル中に送るので、これは正しいです。

---

前のブログ 次のブログ

EIT処理

EIT処理は

• <MA>においてEITの優先度判定し、最弱のEITを識別
• EITスタックにEITの分岐先(EITハンドラ先頭アドレス)をストア
• EIT原因を無効化

以上を繰り返し、最後のひとつに対してはスタックに格納せずにEIT種別による分岐先をPCに格納します。

これはメモリアドレス計算やメモリアクセスを伴うので<ID>のFSMにより実行します。後続の命令はキャンセルされます。以下に具体例を示します。

• 1の命令の<MA>でそのパイプラインストリームで集められたEIT要因を判定します。前後のストリームは見ません。
• 後続命令ストリームをキャンセルします。具体的には2, 3, 4, 5までがパイプラインに入っているので全てキャンセルします。
• <MA>から<ID1>に乗り換えることから、<ID>より前の<IF>と<PC>を持つ、後続の4, 5の命令はキャンセルされるだけでなく、ウエイトされます。
• <ID1>のFSMが起動され、弱いEIT先行してEIT分岐先をスタックに格納します。この場合はE1が最弱でありスタックに格納すると同時にEIT要因を無効化します。同時にSPを+4します。
• 次に<ID2>のFSMが起動され、同様にEIT分岐先をスタックに格納します。SPは前パイプライン<EX>からバイパスします。同時にEIT要因を無効化し、SPを+4します。
• 最後に<ID3>のFSMが起動され、残った最強のEIT分岐先を<EX>で計算します。
• そのサイクルは分岐先の<PC>と同一であり、6のEITハンドラが起動されます。

図466.1 パイプラインハザード

図466.2 パイプラインハザード

---

前のブログ 次のブログ

EIT処理

通常の命令処理以外の処理、例外(Exception)、割り込み(Interrupt)、トラップ(割り出し、Trap)を総称してEIT処理と称します。 パイプラインの各ステージで検出されるEITを以下に示します。

• <PC>: 奇数命令アドレスジャンプ例外
• <IF>: 命令フェッチアドレス例外、デバッグトラップ
• <ID>: 無効命令例外、ゼロ除算例外(命令が除算かつdivisorソースレジスタの内容がゼロ)
• <EX>: 無し
• <MA>: メモリアクセスアドレス例外、デバッグトラップ
• <WB>: 無し

割り込みはいずれのパイプラインステージで検出されるか、保留します。 さて、各ステージでEITが検出されると、前後の命令最大4命令でEITが検出されることになり、後続命令のEITが時間的に先に検出されることになります。これを処理すると命令の前後関係が逆転するために、EITを検出するパイプラインステージを揃えることを考えます。

この中で最も時間的に遅いのが、<MA>であるため、割り込みもここで検出することにします。パイプラインストリーム中に検出されたEITは全てパイプラインレジスタで<MA>まで保留し、ここで優先度を判定し、弱い順にEIT要因をスタックに格納します。従って、EITハンドラは優先度の高い順から実行し、弱い順にハンドラ実行することになります。

例外とトラップ、割り込みの違い

EITはいずれも命令ストリームの途中で起きる例外事象ですが、以下のような違いがあります。

• E(xception): 当該命令は取り消される。具体的には<MA>で起こる場合はメモリに対する書き込みを無効化する。その他の場合は<WB>において書き込みを無効化(パイプラインキャンセル)する。
• I(nterrupt): 当該命令の後に割り込みハンドラに分岐するので、当該命令は実行する。
• T(rap): 当該命令の後にトラップハンドラに分岐するので、当該命令は実行する。

---

前のブログ 次のブログ

分岐命令

一般的な5段パイプラインを解説してきましたが、具体的なプロセッサを対象にして検討します。対象は何でも良いので、ここではRISC-Vとします。その理由は命令セットがオープンであり、誰でも自由に使用することができるためです。

さて、前述の分岐命令は一般的にフラグを見て分岐判定を先行して行うRISCプロセッサでした。前の命令の<EX>で演算後にフラグを立て、その結果で次の分岐命令のデコードである<ID>終了時には分岐命令であり、かつ分岐条件が成立しているため、バブルは1$\tau$となります。

しかしながら、RISC-VのISAからの引用の図464.1を見ると、RISC-Vの条件分岐命令はレジスタをテストして、その結果で分岐するため、バブルは2$\tau$となります。そのため、前稿のフラグベースのアーキテクチャよりもこのアーキテクチャのほうが分岐レイテンシが長くなり、性能が悪いことになります。

図464.1 beq命令

図464.2 パイプライン図

それにもかかわらず、RISC-Vにおいて条件フラグを廃したのは、スーパスカラ化を考えると条件フラグの資源競合が起きやすくなるためだと思われます。

---

前のブログ 次のブログ

キャンセル

パイプラインウエイトと並んで重要な制御がパイプラインキャンセルです。パイプライン中に例外的な事象が起き、そのパイプラインストリームを無効化します。これは前稿で述べたバブルと同様に、あるステージを無効化(Valid信号=false)することで実現します。パイプライン中をinvalidが流れ、最後に<WB>においてレジスタに書き込まないことで実現します。<MA>においてはinvalidである場合にはメモリアクセスFSMは起動しません。

分岐キャンセル

分岐の場合の具体例を示します。分岐先及び非分岐先(+4)を投機的に計算しておくことで、相対分岐の高速化を図ります。これは分岐命令をデコードした時点で既に前の命令で演算フラグが確定しているものとしています。

図463.1 パイプライン図

1の命令が相対分岐であったとき、<ID>において命令をデコードと並行して相対分岐だと思って分岐先を計算します。タイミングとしては3の命令の<PC>と同一です。その命令の最後に相対分岐かどうかが確定し、かつ条件分岐の成立が確定するので、PC選択のマルチプレクサにおいて、分岐先を選択します。同時に後続命令である2のパイプラインストリームにinvalidを流し、パイプラインキャンセルを実行します。

図463.2 パイプライン図

---

前のブログ 次のブログ

マルチサイクル演算ウエイト

続いてマルチサイクル演算ウエイトです。例えば<EX>が4サイクル必要となる乗算等の命令となります。

これはパイプラインストリームの増殖が無いので、通常のウエイト同様、<EX>でウエイトが発生すると、同一サイクル中に後続の命令ステージを全て停止し、かつ下段のパイプラインを無効化します。

図462.1 パイプライン図

図462.2は図462.1をパイプラインステージ順に並び替えたもので、パイプラインウエイトとそれに対応するバブルを見ることができます。

図462.2 パイプライン図

具体的には<EX>で起動するFSMを実装します。

---

前のブログ 次のブログ

マルチサイクル命令ウエイト

前稿ではマルチサイクル命令ウエイトをご紹介しましたが、パイプライン図を示します。これは例えばRead Modify Write等のように、1命令が1サイクルで終わらない複数ストリームを使用する命令で、いわばCISC命令です。ロード命令、演算命令、ストア命令のRISC命令を並べて実行しないのは、RISC命令だとその間に割り込みが入り、アトミック性が保たれないためです。

図461.1 パイプライン図

黄色は内部的に増殖したサイクルです。

図461.2は図461.1をステージで並び替えたもので、通常のウエイトではパイプライン下段にバブルが発生しますが、マルチサイクル命令ウエイトは例外的に、内部的に命令を発生(増殖)させパイプラインを埋めるので、バブルは発生しません。

図461.2 パイプライン図 黄色は内部的に増殖したサイクルです。具体的には<ID>で起動するFSMにより実装します。これはRISC-Vにはないかもしれませんが、EIT処理やMMUミスによるテーブルウォークは、これを用いて実装する可能性があります。

---

前のブログ 次のブログ

レジスタ干渉ハザード

レジスタ干渉によるハザードは2種類あります。前稿でも触れたWARハザードとロードユースハザードです。

• WARハザード: 前の演算命令のデスティネーションレジスタが後続の命令のソースレジスタと同じ場合にレジスタ干渉ハザードが起きます。しかしながら、レジスタ番号マッチ機構によりバイパスさせ、実質ノーウエイト＝ゼロペナルティでパイプライン実行可能です。バイパスパスは<EX>出力⇒<EX>入力です。

図460.1 パイプライン図

図460.1 パイプライン図

ロードユーズハザード

• ロードユーズハザード: 前のロード命令のデスティネーションレジスタが後続の命令のソースレジスタと同じ場合にロードユーズハザードが起きます。この場合待ち合わせのために1ウェイトが必要であり、かつレジスタ番号マッチ機構によりバイパスさせます。バイパスパスは<MA>出力⇒<EX>入力です。

図460.1 パイプライン図

図460.1 パイプライン図

---

前のブログ 次のブログ

パイプラインウエイトの種別

前稿ではパイプラインウエイトの原因を2種類説明しました。ここでステージ毎のパイプラインウエイトの原因をまとめます。

• <PC>: PCの計算にウエイトがかかることは、下段からのウエイトを除きありません。
• <IF>: 命令をメモリからフェッチする際にメモリレイテンシ-1のウエイトが加算されます。これを命令フェッチウエイトと分類します。
• <ID>: 命令デコードにウエイトがかかることはありません。ただしマルチサイクル命令という例外があるので、次項で述べます。
• <EX>: 演算にウエイトがかかる場合はマルチサイクル命令です。上記マルチサイクル命令とはパイプライン制御法が異なるので、併せて次項で述べます。
• <MA>: オペランドメモリのリードライトの際にメモリレイテンシ-1のウエイトが加算されます。これをメモリアクセスウエイトと分類します。
• <WB>: レジスタライトに対してウエイトがかかることはありません。

マルチサイクル命令

前記のように<ID>と<EX>ではマルチサイクル命令ウエイトが発生する可能性があります。

• <ID>: マルチサイクル命令ウエイトと分類します。命令デコードでのマルチサイクル命令は、上段へのウエイト伝搬はパイプラインウエイトと同様、即時に伝えます。一方、下段への無効化を流す操作は行いません。これはあたかも<ID>において命令が内部的に命令ストリームが増殖し、パイプラインを埋めるためです。具体的にはメモリに対するリードモディファイライトがあります。このためには<ID>で動作するステートマシンを起動する必要があります。アーキテクチャにより、無い場合もあります。その理由はCISCっぽい命令となるためです。
• <EX>: マルチサイクル演算ウエイトと分類します。演算にウエイトがかかる場合はマルチサイクル命令ですが、マルチサイクル命令ウエイトと異なり、内部的にパイプラインが増殖することはないため、通常のウエイト制御と同じパイプライン制御を行います。例えば乗算命令に関して32bit×32bitの乗算器を用意すると面積が大きくなるので、32bit×8bitの乗算器を4サイクル回す場合等です。

---

前のブログ 次のブログ