<PC>の必要性

従来例を再掲します。作成しようとするパイプラインロジックは大略、前の図540.1のとおりです。ただし図540.1では<PC>が明示されていません。

次の命令ストリームの起点であるPCは、基本的に

1. 分岐が無ければ(有っても投機的に数命令は実行)、現PC+4
2. PC相対分岐が有ればPC+オフセット
3. 絶対分岐の場合はその値

を次のPCにセットします。この他にも割り込み、例外処理等で新PCを演算し、次のPCにセットします。これを<PC>を意識した図に書き直すと、図541.1のように判りやすい図となります。図540.1のように、PC演算器やレジスタが窮屈に<IF>の中に折れ曲がることは無く、ストレートフォワードに描かれています。<PC>の入力が<PC>であることも図541.1を見れば明らかです。

図541.1では分岐の場合は<EX>の結果レジスタがPCであることから元の<EX>と分岐先<PC>が重なり、その次のステージが分岐先<IF>となることが良くわかります。クロックベースが原則のパイプラインを記号で書けば、

　　　<PC><IF><ID><EX><WB>
　　　　　　　　　　<PC><IF><ID><EX><WB>

となります。分岐先のPC計算を分岐元のEXで代行している様子が良く分かります。

一方、図540.1では<EX>の後にPCレジスタが入り、その次に<IF>ステージとなるので、記号で書くと、

　　　<IF><ID><EX><WB>
　　　　　　　　　　<IF><ID><EX><WB>

となり、<IF>が湧き出す意味が不明です。<IF>の入力レジスタがPCで、分岐命令の<EX>でそれを生成しているのだからという説明になると思いますが、であればPCを明示したほうが分かりやすいのは言うまでもありません。

逆にPCの生成も含めたパイプラインを理解してしまえば頭の中でできるため、取り立てて<PC>の必要性は感じなくなるので、不思議とも思わないようになりますが、教育的とは言えません。そもそも最も重要なPCの更新ステージはどこなのかが図示されていません。これでは分岐命令の高速化、例えばBTB等による<PC>の物量増加も、どのステージの話なのか理解しづらくなります。

<PC>の制御法

<PC>の必要性が理解できたところで、過去記事でパイプライン制御論理を示しました。<PC>の上流が<PC>だからといって上流に出力するwait信号を自分自身に入れると永久にストールするので、自分自身に入れてはいけません。

また、図示されていませんが、PCレジスタ自体も同じパイプライン制御論理によりパイプラインを流します。その理由は、例外の際には分岐が発生しますが、戻りアドレスをスタックに格納します。その戻りアドレスを上記PCパイプラインから適宜取得するためです。

前のブログ 次のブログ

PCステージ

PCステージ(<PC>)を設計します。と言うとなじみがありませんね。一般には存在しないステージなので。以降ではステージ記号を次のように定義します。例：PCステージ:=<PC>

一般にはパイプライン図は<IF>から始まっています。例えば図540.1のように。PCレジスタは<IF>の入力レジスタとして描かれています。良く見ると、本来の<PC>の演算器や結果レジスタは折り曲げられて、窮屈な恰好をしています。

図540.2の黄色のステージ記号及び点線は弊社で追加しました。FDレジスタとは<IF>と<ID>の間のステージなので、<IF>の結果レジスタです。つまりFDレジスタの左側は全て<IF>です。この図でもPCレジスタは窮屈に折り曲げられています。

この図のように<IF>の中にPCレジスタが書かれています。これが変であることに気づかれたでしょうか。パイプラインプロセッサは、パイプラインレジスタにより、組み合わせ回路の結果を次々に受けていくバケツリレー式であり、本来ステージの内部は組み合わせ回路で構成され、レジスタは無いはずです。

それでは<IF>の入力である命令アドレスはどこのステージで生成されるのでしょうか？それが<PC>です。つまり一般の図ではPCは<IF>の入力レジスタのように描かれていますが、実は他のステージと同様、<PC>の結果レジスタです。こう考えるとパイプラインの各ステージが統一的に理解できます。

例えば分岐命令では分岐先アドレス計算をする必要があり、それは必ず<ID>の後になります。図540.2にもPC calculationとありますが、それがパイプライン中の2個目の<PC>です。そして分岐条件が確定した後に<IF>が実行されるので、<PC>は明示したほうが判りやすいです。

一般的に<PC>が無視される理由としては、有名な教科書がIF, ID, EX, MEM, WBの5段で書かれている、からなのかもしれませんが、本来は

<PC><IF><ID><EX><MA><WB>

の6段パイプです。このことは過去記事でも指摘しています。

次の質問です。<PC>の前のステージは何でしょうか？答えは<PC>です。分岐しない限り<PC>は次の<PC>を生成し、1サイクル毎に次々にストリームを生み出します。

一方、例えば分岐命令等のようにパイプラインの途中に<PC>が出現することがあり、複数現れる場合でも命令ストリームの開始PCの計算ですから、いきなり別の命令ストリームの<IF>が現れるよりは判りやすいと思います。無から有は湧いてきません。

割り込みや例外を考える時には一層重要です。割り込みレベルやマスクや例外の種類等の情報を総合して、まずPCがどうなるかを決定します。PCさえ確定すれば、後は<IF>以降のパイプラインを普通に流せば良いだけです。つまり常に<PC>が命令ストリームの起点となります。

本稿で述べたことはエンジニアとしては意識しなくても、設計できるし、見方を変えて設計が変わるわけではないので、哲学に属する話かもしれません。

しかし、設計思想として大事な話なので強調しています。この思想のメリットもあり、例えば<PC>においてPCアドレスを命令アドレスとして命令メモリに流し、<PC>と<IF>の間のクロックで命令アドレスをラッチし、<IF>として命令メモリからデータを流し、プロセッサは<IF>と<ID>の間のクロックで命令データをラッチする、というフローが一般的ですが、<PC>を<IF>の中に混ぜると<IF>が複雑になります。一方この考え方であれば、ラッチベースの動作がすっきりします。

前のブログ 次のブログ

On October 22, 2022, a paper by Atsushi Sakurai, CEO of FS Micro Corporation (Head Office: Nagoya, Japan), a leading provider of functional safety (Note 1) consulting services, was formally accepted by RAMS (Note 2) 2023, an international conference on reliability organized by IEEE (Note 3). This is the fourth consecutive year that the author's paper has been accepted to RAMS. The author also received the Best Paper Award at the 14th ISPCE 2017 (Note 4), an international conference hosted by IEEE in 2017.

RAMS 2023 is scheduled for January 23-26, 2023, at the Florida Hotel and Conference Center in Orlando, Florida, USA.

In 2018, the second edition of ISO 26262 (Note 5), the international standard for functional safety in automotive electronics, was published, and the PMHF (Note 6) equation was also revised. At RAMS 2020, the author clarified the mathematical background of the PMHF formula and proposed a new PMHF formula with which optimal values can be calculated.

This paper re-proves the author's PMHF formula by using the newly proposed stochastic constituents. Specifically, the PMHF formula in ISO 26262 Edition 1 is decomposed into stochastic constituents by considering the combined elements of the intended function and the safety mechanism, and the PMHF formula is proved to be the PMHF formula in the case where the intended function and the safety mechanism are repairable. This makes it possible to prevent overestimation of the PMHF, which has been seen in the past. As a result, it is expected to reduce design man-hours and time-to-market for fault-tolerant systems (Note 7), as represented by self-driving systems.

Company name: FS Micro Corporation
Representative: Atsushi Sakurai
Date of establishment August 21, 2013
Capital: 32 million yen
Business description Consulting and seminars on functional safety of ISO 26262 automotive electronic devices
Address of Head Office 460-0011 4-1-57 Osu, Naka-ku, Nagoya, Aichi, Japan
Phone: +81-52-263-3099
E-mail address info@fs-micro.com
URL http://fs-micro.com/

Notes
Note 1: Functional safety is the concept of enhancing safety at the system level by taking various safety measures.
Note 2: IEEE stands for the Institute of Electrical and Electronics Engineers. It is the world's largest conference on electrical and electronic engineering technology in terms of number of participants and participating countries. http://ieee.org/
Note 3: RAMS stands for The 69th Annual Reliability & Maintainability Symposium, an international conference on reliability engineering organized annually by the IEEE Reliability Society. http://rams.org/
Note 4: ISPCE stands for IEEE Symposium on Product Compliance Engineering, an international conference on product safety organized annually by the IEEE Product Safety Society. http://2017.psessymposium.org/
Note 5: ISO 26262 is a functional safety standard for in-vehicle electrical and electronic systems, an international standard that aims to reduce the possibility of dangerous events to an acceptable level occurring during vehicle operation due to malfunctions of in-vehicle electrical and electronic systems.
Note 6: PMHF stands for Probabilistic Metric for Random Hardware Failures. It is one of the design target values for hardware in ISO 26262, which is a time average of the probability of system failure during the vehicle lifetime.
Note 7: Fault-tolerant systems are safety-enhancing systems that can substitute the original function without immediately losing the function in the event of a failure.

前のブログ 次のブログ

機能安全(注1)コンサルティングを提供するFSマイクロ株式会社(本社：名古屋市)代表取締役社長 桜井 厚の論文が、2022年10月22日、IEEE(注2)主催の信頼性に関する国際学会であるRAMS 2023(注3)に正式採択されました。同著者の論文がRAMSに採択されるのは4年連続となります。また同著者は、2017年にIEEE主催の国際学会である第14回ISPCE 2017(注4)において、最優秀論文賞を受賞しています。

RAMS 2023は、2023年1月23日から26日まで米国フロリダ州オーランドのフロリダホテルアンドカンファレンスセンターにて開催される予定です。

2018年に車載電子機器における機能安全の国際規格であるISO 26262(注5)第2版が発行され、併せてPMHF(注6)式も改訂されました。同著者はRAMS 2020において、このPMHF式の数学的な背景を明らかにし、最適値が算出可能な新しいPMHF式を提案しました。

本論文は、新提案の確率的構成要素を用いることで、同著者の提唱するPMHF式を再度証明したものです。具体的には主機能と安全機構の合体エレメントを考えることで、ISO26262第1版におけるPMHF式を確率的構成要素に分解し、主機能と安全機構が修復可能な場合におけるPMHF式となることを証明しました。そのため、従来見られたPMHFの過剰見積りを防止することが可能となります。これにより、自動運転システムに代表される耐故障システム(注7)の設計工数の削減と市場投入期間の短縮が期待されます。

【お問い合わせ先】
商号　　　　　 FSマイクロ株式会社
代表者　　　　 桜井 厚
設立年月日　　 2013年8月21日
資本金　　　　 3,200万円
事業内容　　　 ISO 26262車載電子機器の機能安全のコンサルティング及びセミナー
本店所在地　　 〒460-0011
　　　　　　　 愛知県名古屋市中区大須4-1-57
電話　　　　　 052-263-3099
メールアドレス info@fs-micro.com
URL　　　　　 http://fs-micro.com/

【注釈】
注1：機能安全は、様々な安全方策を講じることにより、システムレベルでの安全性を高める考え方
注2：IEEE(アイトリプルイー)はInstitute of Electrical and Electronics Engineersの略称。電気工学・電子工学技術に関する、参加人数、参加国とも世界最大規模の学会 http://ieee.org/
注3：RAMS(ラムズ)2023はThe 69th Annual Reliability & Maintainability Symposiumの略称。IEEE信頼性部会が主催する、信頼性工学に関する国際学会 http://rams.org/
注4：ISPCE(アイスパイス)はIEEE Symposium on Product Compliance Engineeringの略称。IEEE製品安全部会が主催する、製品安全に関する国際学会 http://2017.psessymposium.org/
注5：ISO 26262とは車載電気・電子システムに関する機能安全規格であり、自動車の運行中に車載電気・電子システムの故障により危険な事象が起きる可能性を、許容できる範囲にまで減少させることを目的とした国際規格
注6：PMHF(ピーエムエイチエフ)はProbabilistic Metric for Random Hardware Failuresの略称。車載電気・電子システムにおいて、車両寿命間にシステムが不稼働となる確率を時間平均した、ISO 26262のハードウェアに関する設計目標値のひとつ
注7：耐故障システムとは、故障した場合に直ちに機能を失うことなく、本来の機能を代替可能な安全性向上のためのシステム

前のブログ 次のブログ

10/22に最終論文を提出するようにRAMS委員会から返答がありました。10/25に最終論文及びプレゼン資料を登録し、これで正式採択となります。

RAMS 2023は2023年1月にフロリダ州オーランドで開催予定ですが、CDCによる入国制限が今だ継続しており、米国入国が可能かどうかは現段階では不透明です。なお、入国できない場合は録画等で発表予定です。

前のブログ 次のブログ

デコーダのソースの一部を示します。

genRules(
   switch(in_instr,
      when(pat(n(7'b0000000), v, v, n(3'b000), v, n(7'b0110011)), fadd),
      when(pat(n(7'b0100000), v, v, n(3'b000), v, n(7'b0110011)), fsub),
      when(pat(               v, v, n(3'b000), v, n(7'b0010011)), faddi),
      when(pat(n(7'b0000000), v, v, n(3'b111), v, n(7'b0110011)), fand),
      when(pat(n(7'b0000000), v, v, n(3'b110), v, n(7'b0110011)), ffor),
      when(pat(n(7'b0000000), v, v, n(3'b100), v, n(7'b0110011)), fxor),
      when(pat(               v, v, n(3'b111), v, n(7'b0010011)), fandi),
      when(pat(               v, v, n(3'b110), v, n(7'b0010011)), fori),
      when(pat(               v, v, n(3'b100), v, n(7'b0010011)), fxori),
      when(pat(               v, v, n(3'b010), v, n(7'b0000011)), flw),
      when(pat(            v, v, v, n(3'b010), v, n(7'b0100011)), fsw),
      when(pat(n(7'b0000000), v, v, n(3'b001), v, n(7'b0110011)), fsll),
      when(pat(n(7'b0000000), v, v, n(3'b101), v, n(7'b0110011)), fsrl),
      when(pat(n(7'b0100000), v, v, n(3'b101), v, n(7'b0110011)), fsra),
      when(pat(n(7'b0000000), v, v, n(3'b001), v, n(7'b0010011)), fslli),
      when(pat(n(7'b0000000), v, v, n(3'b101), v, n(7'b0010011)), fsrli),
      when(pat(n(7'b0100000), v, v, n(3'b101), v, n(7'b0010011)), fsrai),
      when(pat(n(7'b0000000), v, v, n(3'b010), v, n(7'b0110011)), fslt),
      when(pat(n(7'b0000000), v, v, n(3'b011), v, n(7'b0110011)), fsltu),
      when(pat(               v, v, n(3'b010), v, n(7'b0010011)), fslti),
      when(pat(               v, v, n(3'b011), v, n(7'b0010011)), fsltiu),
      when(pat(v, v, v, v, n(3'b000), v, v, n(7'b1100011)), fbeq),
      when(pat(v, v, v, v, n(3'b001), v, v, n(7'b1100011)), fbne),
      when(pat(v, v, v, v, n(3'b100), v, v, n(7'b1100011)), fblt),
      when(pat(v, v, v, v, n(3'b101), v, v, n(7'b1100011)), fbge),
      when(pat(v, v, v, v, n(3'b110), v, v, n(7'b1100011)), fbltu),
      when(pat(v, v, v, v, n(3'b111), v, v, n(7'b1100011)), fbgeu),
      when(pat(v, v, v, v, v, n(7'b1101111)), fjal),
      when(pat(               v, v, n(3'b000), v, n(7'b1100111)), fjalr),
      when(pat(               v, v, n(7'b0110111)), flui),
      when(pat(               v, v, n(7'b0010111)), fauipc),
      when(pat(               v, v, n(3'b001), v, n(7'b1110011)), fcsrrw),
      when(pat(               v, v, n(3'b101), v, n(7'b1110011)), fcsrrwi),
      when(pat(               v, v, n(3'b010), v, n(7'b1110011)), fcsrrs),
      when(pat(               v, v, n(3'b110), v, n(7'b1110011)), fcsrrsi),
      when(pat(               v, v, n(3'b011), v, n(7'b1110011)), fcsrrc),
      when(pat(               v, v, n(3'b111), v, n(7'b1110011)), fcsrrci),
      when(pat(n(25'b0), n(7'b1110011)), fecall)
   ) // switch
);

これは1ステップ目のデコーダステップであり、ここでビットパターン、例えばaddi命令とのマッチが取れれば、2ステップ目として個別の関数、例えばfaddiが呼び出されます。一例であるfaddiを示せば、

function Action faddi(Bit#(12) imm, Bit#(5) rs1, Bit#(5) rd) = 
   action
      Int#(32) immSext = signExtend(unpack(imm));
      if (immSext == 0)
         $display("time %4t -   mv\t%s,%s", $time, regname(rd), regname(rs1));
      else if (rs1 == 0)
         $display("time %4t -   li\t%s,%0d", $time, regname(rd), immSext);
      else
         $display("time %4t -   addi\t%s,%s,%0d", $time, regname(rd), regname(rs1), immSext);
   endaction;

RISC-Vにおいてaddi命令はイミディエイトがゼロの場合はmv命令として使用され、逆にソースレジスタにゼロレジスタを指定すれば、イミディエイトロード(li)命令として働きます。これらはプロセッサの設計的には不要な処理ですが、逆アセンブラのシンタックスシュガーとして実装しました。

2ステップ目の処理として、各種関数を命令数だけ並べる必要があります。

前のブログ 次のブログ

BSV実行結果(ハードウェアからの出力)と逆アセンブルリストをサイドバイサイドに並べた図を535.1に示します。分岐関係を除いて一致していることが分かります。BSV実行出力にアドレスやデータを表示することは簡単ですが、逆アセンブラを作成しているわけではないので、それらの表示機能は実装していません。

この後も「はじめてのCPU自作」にあるようにECALLやCSR操作命令等を実装し、ひととおりriscv-testが通るデコーダまで作成が完了しました。ところで論理合成ツールには論理圧縮機能が含まれるため、出力されたデコーダ論理を合成前に圧縮する必要はありません。

前のブログ 次のブログ

コンパイルしたオブジェクトファイルの逆アセンブルリストは以下のとおりです。

これを「ハードウェアインタプリター」にかけたら以下のような実行結果となりました。

addi命令のイミディエイトをゼロにすることでmv命令としたり、逆にレジスタをゼロレジスタとすることでli命令としたり、「インタプリター」の出力を細工し、逆アセンブルリストと合わせています。ただし、PCを実装していないので、PC相対命令のラベルは一致していません。このようにPC相対を除き、逆アセンブル結果とほぼ合わせることができました。

前のブログ 次のブログ

「ハードウェアインタプリター」に食わせる機械語列が必要です。そこで、この記事を参考に、Fibonacciプログラムをコンパイルし機械語化しました。試みにFibonacciが通るための「インタプリター」を書いていきます。前述のとおりこの「インタプリター」は実行ステージが逆アセンブル相当の表示をするだけのものです。

入力するFibonacciのソースは以下のように短いプログラムです。

fibo.c:

int fib(int n) {
  if(n <= 1) return 1;
  return fib(n-1) + fib(n-2);
}
int main() {
  fib(10);
  for(;;) {}
  return 0;
}

これをクロスコンパイルし、BSVの入力とします。シーケンサの自動生成を利用して1サイクル毎に、命令デコーダに命令を供給します。

Stmt main = seq
    instr <= 32'h074000ef;
    instr <= 32'hfe010113;
    instr <= 32'h00112e23;
    instr <= 32'h00812c23;
    instr <= 32'h00912a23;
    instr <= 32'h02010413;
    instr <= 32'hfea42623;
    instr <= 32'hfec42703;
    instr <= 32'h00100793;
    instr <= 32'h00e7c663;
    instr <= 32'h00100793;
    instr <= 32'h0300006f;
    instr <= 32'hfec42783;
    instr <= 32'hfff78793;
    instr <= 32'h00078513;
    instr <= 32'hfc9ff0ef;
    instr <= 32'h00050493;
    instr <= 32'hfec42783;
    instr <= 32'hffe78793;
    instr <= 32'h00078513;
    instr <= 32'hfb5ff0ef;
    instr <= 32'h00050793;
    instr <= 32'h00f487b3;
    instr <= 32'h00078513;
    instr <= 32'h01c12083;
    instr <= 32'h01812403;
    instr <= 32'h01412483;
    instr <= 32'h02010113;
    instr <= 32'h00008067;
    instr <= 32'hff010113;
    instr <= 32'h00112623;
    instr <= 32'h00812423;
    instr <= 32'h01010413;
    instr <= 32'h00a00513;
    instr <= 32'hf7dff0ef;
    instr <= 32'h0000006f;
endseq;

今回はまだデコーダのテストだけなので、PCは実装していません。

前のブログ 次のブログ

図532.1にBSV版のBitpatのREADMEに掲載されていた使用例を示します。

挙げられた例はちょうどRISC-Vの命令パターンに一致しており、add命令とaddi命令のデコード部分を示したものです。この要領で、次々に他の命令を実装していくことができます。

本ライブラリの動作は以下の2ステップとなっています。

1. whenの中のパターンマッチでは可変部をvで表し、固定部をnとビットパターンで記述します。vの幅を指定しないで良いのは使いやすそうです。whenの最後に識別した機能を解釈するための関数名を記述します。
2. マッチした後に呼ばれる関数では、可変部のみを変数で受け(固定部は捨てる)、処理を実行します。結局vの幅は意識しなければなりません。

このように最初に固定部、次に可変部という考え方に慣れる必要があります。最初は使いにくいと感じましたが、慣れれば気にならないのかもしれません。

プロセッサ設計と言ってもパイプラインでなければ、見方を変えれば、RISC-V機械語のインタプリターをHDLで作成するだけなので、それほど難しいことではありません。ひとつずつデコードし、対応する処理を実装していくだけです。この「ハードウェアインタプリター」の1段目はデコードステップで、2段目は実行ステップになります。

前のブログ 次のブログ