Posts Issued in September, 2023

posted by sakurai on September 29, 2023 #671

パイプライン動作において、そのサイクルが有効か無効かは重要な情報です。無効サイクルはパイプラインバブルとも呼ばれます。

そこで、本来PCパイプラインには不要ですが、制御信号パイプラインに必要な、Maybe型を用いてパイプラインを記述します。Maybe型は以下に示すようにtagged unionで定義され、validの場合には値を持ちinvalidの場合には値を持たない型です。

typedef union tagged {
    void Invalid;
    data_t Valid;
} Maybe #(type data_t) deriving (Eq, Bits);

以下に修正箇所を示します。

Processor.bsv

int型のFIFOを設けていたところをMaybe型のFIFOに修正します。int型のペイロードに対して1bitのvalid/invalidを表すtagを付加します。

FIFO#(Maybe#(int)) ifs    <- mkFIFO;
FIFO#(Maybe#(int)) ids    <- mkFIFO;
FIFO#(Maybe#(int)) exs    <- mkFIFO;
FIFO#(Maybe#(int)) mas    <- mkFIFO;
FIFO#(Maybe#(int)) wbs    <- mkFIFO;

次に<IF>においてwaitが来たら上位のdeqと下位のenqを停止していましたが、制御信号の場合はwaitの時、下流にinvalidを流すように変更します。このinvalidはパイプラインバブルです。

 // <IF>
 rule if_stage;
    let pc_if = ifs.first;
    if (!if_wait) begin
       ifs.deq;                             // !waitの場合はデキュー
       $display (" pc_if = %04h", pc_if);
       ids.enq (pc_if);                 // !waitの場合はその値を下流にエンキュー
    end else begin
       ids.enq (tagged Invalid); // waitの場合下流にinvalidを流す
    end
 endrule

コンパイルと起動コマンドは以下のとおりです。

$ bsc -u -sim Tb.bsv; bsc -sim -e mkTb -o mkTb.exe;
$ ./mkTb.exe -V;
$ gtkwave -A dump.vcd

以下はbsimシミュレーション波形です。Maybe型は33bitのデータでありMSBがvalid bitとなっています。 標準ではGtkwaveはMaybeのinvalidを認識せず赤色にならないため、手で赤色に修正しました。

図%%.1
図671.1 wait入りPCパイプラインの波形

以下はverilogシミュレーション波形です。verilogでも同様です。

図%%.2
図671.2 wait入りPCパイプラインの波形

bsimとverilogで全く同じ動作となっています。まとめとして、ステージ中にwaitが入る場合の処理は、

  • 上位へはdeqをサイクル中で停止、するとFIFOがfullでとまる。ただしFIFOは1段。
  • 下流へはデータパイプラインの場合はvalid bitは不要であり、値を保持
  • 下流へは制御パイプラインの場合はinvalid(パイプラインバブル)を流す

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

RAMS査読8回目

posted by sakurai on September 28, 2023 #670

指摘事項

最終(?)の査読結果が届きました。指摘は1点あり、

  • systematic faultは筆者の推定ではないか?その場合は規格にバグがあるとは言えない
  • 問題を見つけて修正したとあるが、修正の具体的な方法が書かれていない

というもので、いまだにsystematic faultであると決めつけていると疑念を持たれているようです。論拠は全て示しているのですが、systematic faultが特殊なフォールトであるという認識のためか、論証が弱いと思われています。

本来systematic faultは偶然に発現するランダムフォールトとは異なり、必ず発現する類のバグです。ところが、どうしてもその点に納得されないため、systematic faultを弱めてpotential faultと修正しました。

タイトル

タイトルもそれに合わせてpotential faultとします。 Identifying and Rectifying the Potential Faults in the Probabilistic Metric (PMHF) Formula in ISO 26262

また、修正法が書かれていないという指摘はそのとおりであるため、過去論文[4]を引用してそこに導出がある旨を追加しました。

対応状況

  • systematic faultを弱めてpotential faultと修正しました。
  • 修正法が書かれていないという点は、過去論文[4]を引用してそこに導出がある旨を追加しました。

修正は限定的なためAJEによる英文修正は省略し、RAMSに提出済です。

表670.1 RAMS 2024へのマイルストーン
期限 マイルストーン 状態
2023/4/30 アブストラクト投稿締め切り(システム入力) 投稿済
2023/6/10⇒2023/5/25 アブストラクト採択結果 採択済
2023/8/1 論文、プレゼン投稿締め切り(名前、所属無し版) 投稿済
2023/9/1 第1回論文、プレゼン資料査読コメント受領 投稿済
2023/10/10⇒2023/9/17 改訂版論文、プレゼン投稿締め切り(名前、所属有り版) 投稿済
2023/10/22⇒2023/9/21 最終査読コメント受領 受領済
2023/10/10 学会出席登録締め切り
2023/10/10 最終論文、プレゼン投稿締め切り(名前、所属有り版)


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

posted by sakurai on September 27, 2023 #669

次にパイプラインウェイトをテストします。具体的にはテストベンチにのwait信号を設け、途中でアサートします。

Tb.bsv

Tbにはその記述を追加します。

import StmtFSM::*;
import Processor::*;

(* synthesize *)
module mkTb();
    Empty proc <- mkProcessor();
    Stmt main = seq
         proc.if_wait_load(False);
         delay(10);
         proc.if_wait_load(True);
         delay(1);        // ここでif_waitを2サイクルアサート
         proc.if_wait_load(False);
         delay(10);
         $finish;
    endseq;
    mkAutoFSM(main);
endmodule

if_wait信号を1サイクルアサートをさせようとしてdelay(1);を挟みましたが、その前のload(True);により1サイクルアサートされるようです。そのため、1サイクルアサートさせるには以下の表のように、何も挟まないかdelay(0);と記述するようです。

表669.1 BSV構文とwaitアサート期間
BSV構文 waitアサート期間
proc.if_wait_load(True);
proc.if_wait_load(False);
1サイクル
proc.if_wait_load(True);
delay(0);
proc.if_wait_load(False);
1サイクル
proc.if_wait_load(True);
repeat(0) noAction;
proc.if_wait_load(False);
1サイクル
proc.if_wait_load(True);
noAction;
proc.if_wait_load(False);
2サイクル
proc.if_wait_load(True);
delay(1);
proc.if_wait_load(False);
2サイクル
proc.if_wait_load(True);
repeat(1) noAction;
proc.if_wait_load(False);
2サイクル

Processor.bsv

PCパイプラインにインタフェースを設け、そこにif_wait入力を設けます。

Import FIFO::*;

interface Processor_ifc;
    (* prefix="" *)
    method Action if_wait_load(Bool in_if_wait);
endinterface

(* synthesize, always_ready *)
module mkProcessor(Processor_ifc);

if_waitはレジスタで宣言します。

Reg#(Bool) if_wait <- mkReg(False);

<IF>において、waitが来たら上位のdeqと下位のenqを停止します。

 // <IF>
 rule if_stage;
     let pc_if = ifs.first;
     if (!if_wait) begin
         ifs.deq;
         $display (" pc_if = %04h", pc_if);
         ids.enq (pc_if);
     end
 endrule

コンパイルと起動コマンドは以下のとおりです。gtkwaveはここ

$ bsc -u -sim Tb.bsv; bsc -sim -e mkTb -o mkTb.exe;
$ ./mkTb.exe -V;
$ gtkwave -A dump.vcd

以下はbsimシミュレーション波形です。if_waitを1サイクルアサートしようとして、delay(1);とすると2サイクルアサートされるので、1サイクルアサートするにはdelay(0);とするようです。

if_waitにより一旦はinvalidになりますが、そのデータを転送するとvalidになってしまうようです。

図%%.1
図669.1 wait入りPCパイプラインの波形(bsim)

以下はverilogシミュレーション波形です。if_waitによりinvalidになることはありません。

図%%.2
図669.2 wait入りPCパイプラインの波形(verilog)

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

posted by sakurai on September 26, 2023 #668

過去記事で設計したPCパイプラインをモジュールに変更し、その上にテストベンチをかぶせます。以下にテストベンチTb.bsv及びPCパイプラインProcessor.bsvのソースを示します。

Tb.bsv

import StmtFSM::*;
import Processor::*;

(* synthesize *)
module mkTb();
    Empty proc <- mkProcessor();
    Stmt main = seq
        delay(30);
        $finish;
    endseq;
    mkAutoFSM(main);
endmodule

Processor.bsv

import FIFO::*;

(* synthesize, always_ready *)
module mkProcessor(Empty);

    Reg#(int)  pc     <- mkReg(0);
    FIFO#(int) ifs    <- mkFIFO;
    FIFO#(int) ids    <- mkFIFO;
    FIFO#(int) exs    <- mkFIFO;
    FIFO#(int) mas    <- mkFIFO;
    FIFO#(int) wbs    <- mkFIFO;

     // <PC>
     rule pc_stage;
        if (pc > 100) $finish(0);
        $display("------");
        ifs.enq(pc);
        pc <= pc + 4;
     endrule

     // <IF>
     rule if_stage;
        let pc_if = ifs.first;
        ifs.deq;
        $display (" pc_if = %04h", pc_if);
        ids.enq (pc_if);
     endrule

     // <ID>
     rule id_stage;
        let pc_id = ids.first;
        ids.deq;
        $display (" pc_id = %04h", pc_id);
        exs.enq (pc_id);
     endrule

     // <EX>
     rule ex_stage;
        let pc_ex = exs.first;
        exs.deq;
        $display (" pc_ex = %04h", pc_ex);
        mas.enq (pc_ex);
     endrule

     // <MA>
     rule ma_stage;
        let pc_ma = mas.first;
        mas.deq;
        $display (" pc_ma = %04h", pc_ma);
        wbs.enq (pc_ma);
     endrule

     // <WB>
     rule wb_stage;
        let pc_wb = wbs.first;
        wbs.deq;
        $display (" pc_wb = %04h", pc_wb);
     endrule

endmodule: mkProcesso

コンパイルと起動コマンドは以下のとおりです。gtkwaveはここ

$ bsc -u -sim Tb.bsv; bsc -sim -e mkTb -o mkTb.exe;
$ ./mkTb.exe -V;
$ gtkwave -A dump.vcd

図%%.1
図668.1 PCパイプラインの波形

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

RAMS査読6,7回目

posted by sakurai on September 22, 2023 #667

指摘事項

最終(?)の査読結果が届きました。指摘は1点あり、

Systematic Faultは筆者の推定ではないか?その場合は規格にバグがあるとは言えず、「全て修正した場合にAF2となることを証明した」とは言えないのでその文言を削除すべき。

とのことです。なかなかSystematic Faultが理解してもらえないため、図667.1の規格での定義を抜き出して送付したら、その定義により論理のチェインを繋げるべきというコメントをもらいました。

図%%.1
図667.1 Systematic Faultの定義(規格より)
日本語訳を以下に追記します。

3.165 系統的障害
プロセスまたは設計の対策を適用することによってのみ防ぐことができる、決定論的な方法で故障が顕在化する障害

ただし、この表現は抽象的でわかりにくいです。一般的に系統的障害とはバグ論理ミスと言われているものです。

対応状況

AEJによる英文修正後にRAMSに提出予定です。

表667.1 RAMS 2024へのマイルストーン
期限 マイルストーン 状態
2023/4/30 アブストラクト投稿締め切り(システム入力) 投稿済
2023/6/10⇒2023/5/25 アブストラクト採択結果 採択済
2023/8/1 論文、プレゼン投稿締め切り(名前、所属無し版) 投稿済
2023/9/1 第1回論文、プレゼン資料査読コメント受領 投稿済
2023/10/10⇒2023/9/17 改訂版論文、プレゼン投稿締め切り(名前、所属有り版) 投稿済
2023/10/22⇒2023/9/21 最終査読コメント受領 受領済
2023/10/10 学会出席登録締め切り
2023/10/10 最終論文、プレゼン投稿締め切り(名前、所属有り版)


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

RAMS査読5回目

posted by sakurai on September 21, 2023 #666

最終(?)の査読結果が届きました。指摘は2点あり、

  • Systematic Faultは意味がわからないからSUMMARY&CONCLUSIONに説明を入れたほうが良い
  • 以前の論文で効果が20~40倍あるとのことだが、今回の論文で書かれていない。

とのことです。前回の査読の指摘「Systematic Faultは意味がわからない」に基づきSystematic Faultはの説明をイントロダクションに追加していたのですが、それでは足りず、SUMMARY&CONCLUSIONに追加せよとのことです。早速対応し、さらに効果については過去論文で論証していたため、今回の論文では削除しました。英文校正を経て投稿済みです。

表666.1 RAMS 2024へのマイルストーン
期限 マイルストーン 状態
2023/4/30 アブストラクト投稿締め切り(システム入力) 投稿済
2023/6/10⇒2023/5/25 アブストラクト採択結果 採択済
2023/8/1 論文、プレゼン投稿締め切り(名前、所属無し版) 投稿済
2023/9/1 第1回論文、プレゼン資料査読コメント受領 投稿済
2023/10/10⇒2023/9/17 改訂版論文、プレゼン投稿締め切り(名前、所属有り版) 投稿済
2023/10/22⇒2023/9/21 最終査読コメント受領 受領済
2023/10/10 学会出席登録締め切り
2023/10/10 最終論文、プレゼン投稿締め切り(名前、所属有り版)

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

AI Writer (5)

posted by sakurai on September 19, 2023 #665

ほとんど満足できる結果が生成されました。ただ、不稼働度を下げるには故障率の低減だけでなく検出率や修理率の向上も必要なため、その旨を伝えます。さらに、PMHFと不稼働度の関連も加えてもらいます。

大変良いです。ただ、不稼働度の節において、不稼働度を低減する=信頼性を高めるには故障率を下げるだけでなく、故障検出率を上げる、修理率を上げることが影響します。それを加えて修正してください。さらに、PMHFは不稼働度を用いて定義されることを追記してください。

ChatGPT:

ご指摘いただきありがとうございます。不稼働度とPMHFの節を以下のように修正します。

不稼働度とは

不稼働度は、車載ECUが期待される動作時間に対する不動作時間の割合を示す重要な評価指標です。逆に言えば、不稼働度が低いほど車載ECUの信頼性と安全性が高いということになります。不稼働度を正確に評価し、最小限に抑えるためには、システムの故障率を下げるだけでなく、故障検出率や修理率を高めることも重要です。これらの要素を考慮に入れ、信頼性の高いハードウェアとソフトウェアを設計、開発することが求められます。

PMHF(Probabilistic Metric for Random Hardware Failures)とは

PMHFは、車載ECUに搭載された電子部品や回路がランダムに故障する確率を評価するための指標です。PMHFはISO26262規格に基づいて定義されており、これに従ってハードウェア故障の発生確率を算出することで、車載ECUの機能安全を評価し向上させることが可能となります。この指標は不稼働度を用いて計算され、機能安全の確保に重要な役割を果たします。


論文の導入部分等のISO 26262やPMHFの説明等は、独自性が出るべき箇所ではなく、誰が書いても同じ内容になるので、AIに書かせることはむしろ推奨されるべきかもしれません。しかしながら内容の妥当性の確認は当然人間が行うべきです。


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

AI Writer (4)

posted by sakurai on September 18, 2023 #664

だいぶさっぱりしてしまったので、もう少し中身を充実させます。

もう少し長くしてください。

ChatGPT:

すみませんが、それぞれのセクションをもう少し詳細に説明します。

機能安全とは?車載ECUの不稼働度を評価するPMHFとISO26262との関係

機能安全とは

機能安全は、自動車の中枢部である車載ECUの正常な動作を保証し、意図しない故障や異常動作を防止する重要な要素です。この目的を達成するための詳細な要件と評価方法はISO26262規格によって定められており、これらの規格を順守することにより自動車の信頼性が向上します。

不稼働度とは

不稼働度は、車載ECUが期待される動作時間に対する不動作時間の割合を示す重要な評価指標です。これは逆に言えば、不稼働度が低いほど車載ECUの信頼性と安全性が高いということになります。不稼働度を正確に評価するためにはシステムの故障率や故障の影響度を考慮する必要があり、これらの要素を基に信頼性の高いハードウェアとソフトウェアを設計、開発することで不稼働度を最小限に抑えることが求められます。

PMHF(Probabilistic Metric for Random Hardware Failures)とは

PMHFは、車載ECUに搭載された電子部品や回路がランダムに故障する確率を評価するための指標です。PMHFはISO26262規格に基づいて定義されており、これに従ってハードウェア故障の発生確率を算出することで、車載ECUの機能安全を評価し向上させることが可能となります。

車載ECUにおけるPMHFの利用

車載ECUでは、PMHFを使用してランダムなハードウェア故障の確率を評価し、信頼性を向上させることが可能です。また、PMHFを使用することで故障の予測や調査が容易になり、その結果として自動車の安全性を向上させる戦略や対策を立てることができます。これらの利点は、自動車の安全性向上や事故や故障のリスク軽減に大いに貢献します。


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

AI Writer (3)

posted by sakurai on September 14, 2023 #663

同じ内容が繰り返されているようなので、ChatGPT-4に改善してもらいます。

以下の文章は冗長で長いため、冗長性を削除して短くしてください。特に不稼働度の項目は逆になっています。つまり不稼働度は高信頼性を意味すると書かれているが、逆であり、不稼働度は故障の確率を表すものです。この節だけ論旨を反対にしてください。

機能安全とは?車載ECUの不稼働度を評価するPMHFとISO26262との関係

機能安全とは

機能安全とは、車載ECUにおける機能安全の重要性について説明するものです。車載ECUは自動車の中枢を担い、安全性が最も重要な要素となっています。ISO26262規格は、この機能安全の要件を定め、その適用範囲や評価方法などを規定しています。

車載ECUの機能安全は、万が一の故障や異常動作を防止し、適切な制御が行われることを保証することを目的としています。ISO26262では、ハードウェアの設計やソフトウェアの開発、評価方法など、様々な要件が述べられています。機能安全の確保は、自動車の信頼性を高めるために欠かせない要素であり、自動車メーカーなどにとっては非常に重要な課題となっています。

不稼働度とは

不稼働度とは、車載ECUにおいて非常に重要な概念です。不稼働度とは、システムが正常に動作することが期待される時間に対して、システムが実際に正常に動作している時間の割合を示します。つまり、車載ECUの不稼働度が高いほど、システムの信頼性や安全性が高いと言えるのです。不稼働度を評価するためには、システムの故障率や故障の影響度などの情報が必要です。不稼働度の評価には、統計的な手法やシミュレーションなどが用いられます。不稼働度の高い車載ECUは、車両の安全性を確保する上で非常に重要であり、ISO26262規格などの機能安全の要件を満たす必要があります。車載ECUの不稼働度を向上させるためには、信頼性の高いハードウェアやソフトウェアの設計と開発が不可欠です。

PMHF(Probabilistic Metric for Random Hardware Failures)とは

PMHF(Probabilistic Metric for Random Hardware Failures)は、機能安全において重要な評価指標の一つです。PMHFは、車載ECUにおけるランダムなハードウェア故障の確率を算出するためのメトリックです。車載ECUには多くの電子部品や回路が搭載されており、これらのハードウェアの故障は機能安全に影響を与える可能性があります。PMHFは、このようなランダムなハードウェア故障の発生確率を示す指標として利用されます。PMHFの算出方法や評価指標はISO26262規格に基づいており、これに従って導入されることが推奨されています。PMHFを活用することで、車載ECUの機能安全を向上させることができます。

車載ECUにおけるPMHFの利用

車載ECUにおけるPMHFの利用は、機能安全の向上において非常に重要です。PMHFは、Probabilistic Metric for Random Hardware Failuresの略であり、ランダムなハードウェア障害の確率を評価する指標です。車載ECUでは、信頼性の向上や不稼働度の評価にPMHFを利用することができます。また、PMHFを活用することで車載ECUの故障の予測や調査が可能となり、車載システムの安全性を確保するための戦略や対策を立てることができます。これにより、自動車の安全性向上や事故や故障のリスクを軽減することができます。特に、ISO26262という機能安全の国際規格に基づいた車載システム開発では、PMHFの利用が求められています。車載ECUにおけるPMHFの利用により、より高い機能安全性を確保することができるため、自動車業界において重要な技術と言えます。

ChatGPT:

以下に短縮した文章を提供します。

機能安全とは?車載ECUの不稼働度を評価するPMHFとISO26262との関係

機能安全について

機能安全は、車載ECUが正常に動作し、故障や異常を防止することを目指します。この確保はISO26262規格で規定され、自動車の信頼性を高めるために重要です。

不稼働度について

不稼働度は、車載ECUが正常に動作していない時間の割合を表し、低いほど信頼性や安全性が高まります。不稼働度の評価には故障率や影響度が必要で、その向上には信頼性の高い設計と開発が必要です。

PMHFについて

PMHFは、車載ECUのランダムなハードウェア故障の確率を示す指標で、ISO26262規格に基づいています。PMHFの活用は、車載ECUの機能安全向上に有用です。

PMHFの利用

車載ECUでは、PMHFを活用し、信頼性の向上や故障の予測が可能になります。これにより、安全性の向上や事故や故障のリスク軽減に寄与し、高い機能安全性を確保します。


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

AI Writer (2)

posted by sakurai on September 13, 2023 #662

このタイトルやキーワードに沿って、記事の章立てを考えてくれます。適宜編集することが可能です。5番目の展望については不要なので、削除しました。

図%%.1
図662.1 記事の概要

この章立てで記事を書かせると、やや冗長な記事を書いてくれました。長いので、以下に部分のみを示します。

図%%.2
図662.2 記事の概要

不稼働度について、不稼働度が高まると信頼度が上がると逆のことが書かれています。これを修正させましょう。


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


ページ: