FPGA開発日記

カテゴリ別記事インデックス https://msyksphinz.github.io/github_pages , English Version https://fpgadevdiary.hatenadiary.com/

RISC-Vベクトル拡張仕様書 v1.0 を読み直す (5. その他のCSRレジスタ)

RISC-Vベクトル拡張仕様書の読み直し。その他のベクトルCSRレジスタについて。

github.com

github.com


3.7. ベクトル固定小数点丸めモードレジスタ vxrm

ベクトル固定小数点丸めモード・レジスタは、2ビットの読み書き可能な丸め込みモード・フィールドを保持します。 ベクトル固定小数点丸め込みモードは、独立してアクセスできるように、 別のCSRアドレスが与えられていますが、 vcsr のフィールドとしても反映されています。

固定小数点丸めのアルゴリズムは以下のように規定されています。 丸め前の結果を v とし、その結果の d ビットを丸めるとします。 このとき、丸められた結果は (v >> d) + r となり、 r は次の表にあるように丸めモードに依存します。

以下の命令の説明では、丸め関数を表すために以下の操作が使用されています。

roundoff_unsigned(v, d) = (unsigned(v) >> d) + r
roundoff_signed(v, d) = (signed(v) >> d) + r

vxrm[XLEN-1:2] はゼロが書き込まれるべきです。

Note: csrwi 1命令を使って、元の丸め込みモードを保存しながら、 新しい丸め込みモードを設定することができます。

3.8. ベクトル固定小数点飽和フラグ vxsat

vxsat CSRは読み書き可能な1ビットを保持しており、 固定小数点命令が出力値を出力先のフォーマットに収めるために飽和させる必要があったかどうかを示します。

vxsat ビットは vcsr のミラーです。

3.9. Vector 制御・ステータスレジスタ vcsr

vxrm と vxsat CSRは、ベクトル制御・ステータスCSRであるvcsrのフィールドを介してアクセスすることもできます。

3.10. リセット時のベクトル拡張の状態

ベクトル拡張は、リセット時に一貫した状態を持っている必要があります。 特に、vtype と vl は、1つの vsetvl 命令で読み取ってから復元できる値を持っていなければなりません。

Note: リセット時には、vtype.vill が設定され、vtype の残りのビットはゼロになり、vl はゼロになることが推奨されます。 vstart, vxrm, vxsat CSR は、リセット時に任意の値を持つことができます。

Note: ベクトルユニットを使用する場合は、初期化のための vset{i}vl{i} が必要で、 これにより vstart がリセットされます。 vxrm と vxsat フィールドは、使用前にソフトウェアで明示的にリセットする必要があります。 ベクトルレジスタはリセット時に任意の値を持つことができます。

RISC-Vベクトル拡張仕様書 v1.0 を読み直す (4. vstartレジスタ)

RISC-Vベクトル拡張仕様書の読み直し、次はvstartについて。

これは単純。要するにベクトル要素のどこから演算を開始させるか、という話。

github.com

github.com


3.6. ベクトルスタートインデックスCSR vstart

読み書き可能なCSRである vstart は、 Prestart, Active, Inactive, Body, and Tail Element Definitions 項で説明したように、 ベクトル命令で実行される最初の要素のインデックスを指定します。

通常、vstart はベクトル命令の例外発生時にハードウェアによってのみ書き込まれ、 vstart の値は例外発生した要素 (同期例外または非同期割り込み) を表し、 再開可能な例外が処理された後に実行が再開されるべき要素を表します。

すべてのベクトル命令は、 vstart CSR で指定された要素インデックスから実行を開始し、 書き込みベクトル内の以前の要素には影響を与えず、実行終了時には vstart CSR をゼロにリセットするように定義されています。

Note: vset{i}vl{i} を含むすべてのベクトル命令は、vstart CSR をゼロにリセットします。 vstart は、不正命令例外を発生させるベクトル命令によって変更されません。

vstart CSR は、最大の要素インデックスを保持するのに十分な書き込み可能なビットのみを持つように定義されます (最大 VLMAX より 1 つ少ない)。

Note: 最大のベクトル長は、最大のLMUL設定(8)と最小のSEW設定(8)で得られるため、VLMAX_max = 8*VLEN/8 = VLENとなります。 例えば、VLEN=256の場合、vstart は、0から255までのインデックスを表す8ビットを持つことになります。 現在のSEW設定の最大要素インデックスよりも大きい vstart 値の使用は予約されています。

Note: vstart が範囲外の場合には、実装で例外を発生させることが推奨されています。 上位の vstart ビットの将来的な使用法として、 不正確な例外情報を保存することが考えられるため、 例外を発生させることは必須ではありません。 vstart CSR は非特権コードによって書き込み可能ですが、 非ゼロの vstart 値はいくつかの実装でベクトル命令の実行速度を大幅に低下させる可能性があるため、 vstart はアプリケーション・プログラマーが使用すべきではありません。 いくつかのベクトル命令は、非ゼロの vstart 値では実行できず、 以下に定義するような不正な命令例外を発生させます。

Note: vstart を非特権コードから見えるようにすることは、 ユーザレベルのスレッディングライブラリをサポートします。 実装は、同じ vtype 設定で同じ命令を実行した場合でも、 実装が決して生成できない vstart の値を持つベクトル命令を実行しようとした場合、 不正命令例外を発生させることが許可されています。

Note: 例えば、ある実装では、ベクトル演算命令の実行中には決して割り込みを受け取らず、 命令が完了するまで待って割り込みを受け取ります。 そのような実装では、 vstart が0でないときにベクトル演算命令を実行しようとすると、 不正な命令例外を発生させることができます。

Note: マイクロアーキテクチャの異なる 2 つの hart 間でソフトウェア・スレッドを移行する場合、 vstart 値は新しい hart のマイクロアーキテクチャーではサポートされていない可能性があります。 その場合、受信側の hart のランタイムは、サポートされている vstart 要素の位置への命令実行をエミュレートしなければならないかもしれません。 あるいは、移行イベントは、相互にサポートされる vstart 位置でのみ発生するように制約することもできます。

SonicBOOMに関する調査 (8. Load-useに関する調査2)

SonicBOOMのロードユースについて調査したい。キャッシュヒットした場合、ロード命令からその次の依存命令まで何サイクル掛かるのか。

CoremarkのPointer Chase部分についてサイクル数を確認している。当該部分はここになる。

               11996 3 0x000000008000122a c.ld    a5, 8(a0) x15 0x0000000080003ad4
               11996 3 0x000000008000122c lh      a5, 2(a5) x15 0x0000000000007fff
               12000 3 0x0000000080001230 bne     a5, a4, pc - 10
               12001 3 0x0000000080001226 c.ld    a0, 0(a0) x10 0x00000000800038e0
               12002 3 0x0000000080001228 c.beqz  a0, pc + 38
               12002 3 0x000000008000122a c.ld    a5, 8(a0) x15 0x0000000080003ad0
               12003 3 0x000000008000122c lh      a5, 2(a5) x15 0x0000000000000000
               12007 3 0x0000000080001230 bne     a5, a4, pc - 10
               12008 3 0x0000000080001226 c.ld    a0, 0(a0) x10 0x0000000080003960
               12009 3 0x0000000080001228 c.beqz  a0, pc + 38
               12010 3 0x000000008000122a c.ld    a5, 8(a0) x15 0x0000000080003af0
               12010 3 0x000000008000122c lh      a5, 2(a5) x15 0x0000000000000716
               12012 3 0x0000000080001230 bne     a5, a4, pc - 10
               12013 3 0x0000000080001226 c.ld    a0, 0(a0) x10 0x00000000800039e0
               12014 3 0x0000000080001228 c.beqz  a0, pc + 38
               12014 3 0x000000008000122a c.ld    a5, 8(a0) x15 0x0000000080003b10
               12015 3 0x000000008000122c lh      a5, 2(a5) x15 0x000000000000070e
               12017 3 0x0000000080001230 bne     a5, a4, pc - 10
               12018 3 0x0000000080001226 c.ld    a0, 0(a0) x10 0x0000000080003a60
               12019 3 0x0000000080001228 c.beqz  a0, pc + 38
               12020 3 0x000000008000122a c.ld    a5, 8(a0) x15 0x0000000080003b30
               12020 3 0x000000008000122c lh      a5, 2(a5) x15 0x0000000000000706
               12022 3 0x0000000080001230 bne     a5, a4, pc - 10

ここのLSUの波形を確認した。リクエストの依存関係は以下のようになっている。

f:id:msyksphinz:20210619233358p:plain

ここから分かることは、それぞれのループにおいて分岐予測を使用して可能な限りロード命令を先出ししているということ。

そして、ロード命令はパイプライン発行後の2サイクルでWakeup信号を他スケジューラに送出する(おそらくL1Dミス/TLBミスすると1サイクル後にld_missがWakeupする)し、 それを受け取った他スケジューラは即時パイプラインへ投入される。

f:id:msyksphinz:20210620002238p:plain

RISC-Vベクトル拡張仕様書 v1.0 を読み直す (3. vta/vmaフィールド)

RISC-Vベクトル拡張仕様書の読み直し、次はvta / vmaについて。

これも理解するのは少し厄介。要するに無効な要素の扱いをどのようにするかということだが、 リネームするマシンとそうでないマシンで、効率よく実装するために色々と考え込まれている。


3.3.3. Tail Agnostic とVector Mask Agnostic vta と vma

これらの2つのビットは、ベクトル命令の実行中に、書き込みレジスタのTail要素および 書き込みレジスタの非アクティブなマスクオフされた要素の動作をそれぞれ変更します。 Tailセットと非アクティブセットには、Prestart, Active, Inactive, Body, and Tail Element Definitions 項で定義されているように、 ベクトル演算中に新しい結果を受け取らない要素の位置を含んでいます。

すべてのシステムは、4つのオプションすべてをサポートしなければなりません。

vta vma Tail要素 非アクティブ要素
0 0 undisturbed undisturbed
0 1 undisturbed agnostic
1 0 agnostic undisturbed
1 1 agnostic agnostic

セットがundisturbedに設定されている場合、ベクトルレジスタグループ内の対応するセットの書き込み要素は、 以前に保持していた値を保持します。 マスクの書き込み値は、vta の設定にかかわらず、 常にTail Agnosticとして扱われます。

セットがAgnosticとしてマークされている場合、任意のベクトル書き込みオペランドの書き込み要素の対応するセットは、 以前保持していた値を保持するか、1で上書きされるかのいずれかになります。 1つのベクトル命令の中で、各書き込み要素は、任意の組み合わせで、1を残したり、1で上書きしたりすることができ、 同じ入力で命令を実行したときに、1を残したり、1で上書きしたりするパターンは、常に決定している必要はありません。 また、マスクロード命令を除き、マスク結果の末尾にある任意の要素には、 マスク生成演算が vl=VLMAX で計算したであろう値を書き込むこともできます。

Note: Agnosticポリシーは、ベクトルレジスタをリネームするマシンや、 深い一時的なベクトルレジスタを持つマシンに対応するために追加されました。 Agnosticなポリシーでは、新しい物理書き込みベクトルレジスタにコピーするために、 すべての要素を古い物理書き込みベクトルレジスタから読み込まなければなりません。 これは、これらの非アクティブまたはTail値が後続の計算に必要でない場合、効率が悪くなります。

Note: マスクテールは、ビット単位で記述可能なマスクデータの管理の複雑さを軽減するために、常にAgnosticに扱われます。 マスクレジスタ値のTail Undisturbedをサポートするソフトウェアの必要性はほとんどないと思われます。 マスクを生成する命令が命令の結果を書き戻すことを許可すると、Tailをマスクアウトするロジックの必要性がなくなります。 ただし、マスクロードは、ソフトウェアの意図を超えてメモリにアクセスすることになるため、 宛先のマスクテールにメモリ値を書き込むことはできません。

Note: 上書き値として、All-0ではなくAll-1を選択したのは、 ソフトウェア開発者が書き込まれた値に依存しないようにするためです。

Note: シンプルなインオーダー実装であれば、この設定を無視して、単純にundisturbedポリシーですべてのベクター命令を実行することができます。 互換性とスレッドの移行をサポートするために、vta と vma のステートビットは vtype で提供されなければなりません。

Note: アウトオブオーダーの実装では、実装の複雑さを軽減するために、 tail-agnostic + mask-agnostic を tail-agnostic + mask-undisturbed を使って実装することを選択できます。

Note: agnosticポリシーの定義は、小さなインオーダコア上のhart(おそらくagnostic領域は邪魔されずに残る)と、 レジスタリネーミングのある大きなアウトオブオーダコア上のhart(おそらくagnostic要素を1で上書きする)の間でアプリケーションスレッドを移行することに対応するため、 緩く残されています。 途中で再起動する必要があるかもしれないので、1つのベクトル命令の中で、Agnosticなポリシーを任意に混在させることができます。 このようなポリシーの混在を許容することで、 例えば、アクティブに操作されている要素内ではundisturbedを使用し、テールの要素ではすべて1にリネームするなど、 ベクターレジスタの異なる要素に対してポリシーを変更するような実装も可能になります。

アセンブリ構文では、 vsetvli 命令に2つのフラグが追加されています。

 ta   # Tail agnostic
 tu   # Tail undisturbed
 ma   # Mask agnostic
 mu   # Mask undisturbed

 vsetvli t0, a0, e32, m4, ta, ma   # Tail agnostic, mask agnostic
 vsetvli t0, a0, e32, m4, tu, ma   # Tail undisturbed, mask agnostic
 vsetvli t0, a0, e32, m4, ta, mu   # Tail agnostic, mask undisturbed
 vsetvli t0, a0, e32, m4, tu, mu   # Tail undisturbed, mask undisturbed

Note: 短期的には後方互換性を維持し、0.9 への移行時にはソフトウェアの変更を減らすために、これらのフラグが vsetvli に指定されていない場合は、 デフォルトで mask-undisturbed/tail-undisturbed とすべきです。 しかし、これらのフラグを持たない vsetvli の使用は非推奨とし、 フラグ設定の指定が必須となるようにします。 どちらかというと、デフォルトはtail-agnostic/mask-agnosticにすべきなので、 ソフトウェアは非アクティブ要素を気にするタイミングを指定する必要がありますが、 これらのフラグが導入される前の命令の歴史的な意味を考えると、 将来のアセンブリコードでは常にフラグを要求するのが最も安全です。

CARRV 2021の発表論文概観 (2)

ISCA 2021と併設されているCARRV 2021の論文が公開されている。25本近くの論文が公開されているのですべてを読むことは出来ないので、とりあえずカテゴリ別にAbstractだけ読んで日本語にしてみることにした。 今回は後半。

carrv.github.io


シミュレーションと検証セッション

  • RISC-Vのフルシステムシミュレーションをgem5でサポート

RISC-V ISAとそのエコシステムは、産業界と学術界の両方でますます人気が高まっています。gem5は、コンピュータ・アーキテクチャ研究のための強力なシミュレーション・プラットフォームとして広く使用されています。これまでの研究では、シングルコアおよびマルチコアのRISC-Vサポートをgem5に追加してきましたが、システムコールのエミュレーションにとどまっていました。一方、gem5のフルシステム・シミュレーションは、gem5でモデリングされたハードウェア・プラットフォーム上に実際のシステム・ソフトウェアをロードして実行することで、システムの正確な解析を可能にします。 しかし、RISC-V ISAに対するgem5のフルシステム・シミュレーションのサポートは現在のところありません。

この論文では、RISC-Vのフルシステム・シミュレーションをgem5でサポートするための最近の研究成果を紹介します。拡張可能なターゲット・システムをサポートするための実装の詳細と、主要な課題を克服するためのデバッグ手法について説明した後、フルシステム・シミュレーションの実験結果を紹介します。

古システムエミュレーションというのはSoCレベルでのデバイスを含めた全シミュレーションということだろうか?

RISC-Vシステムへの関心が高まり、カスタマイズされたハードウェア・アーキテクチャーを作成する無限の可能性がある中、再構成可能なIoT(Internet of Things)ローエンド機器向けの初のオープンソース・アグノスティック・ハードウェア・オペレーティング・システム(OS)フレームワークであるChamelIoTの最初の概念実証(PoC)の実装を紹介します。現段階では、ChamelIoTは、Rocket Custom Co-Processor Interface(RoCC)を活用して、3種類のOSのスレッド管理とスケジューリングをハードウェアアクセラレーションでサポートしています。RIOT、Zephyr、そしてFreeRTOSです。本論文では、ChamelIoTアーキテクチャ全体の概要と、現在のPoC展開における実装の詳細について説明します。我々の最初の実験はXilinx Arty-35T FPGA Evaluation kitで行われましたが、その予備的な結果は非常に有望で、望ましい不可知論と柔軟性が、決定性と性能上の利点を伴って、ハードウェア資源の妥当なコストで達成できることを示しています。

RoCCを使ったIoT向けのオープンソースOSを設計するということ?

  • RISC-Vコア開発のための柔軟なアンコア・インフラストラクチャ

RISC-Vのオープン性、柔軟性、モジュール性は、コンピュータ・アーキテクチャ研究における新たな開発の扉を開きます。また、同じ特性を持つRISC-Vは、特にFPGAベースのラピッドプロトタイピングと組み合わせることで、学生が独自のコアデザインを実装する際の参入障壁を下げることができるため、教育やコンピュータ・アーキテクチャ教育にとっても非常に魅力的です。しかし、キャッシュ、メモリ一貫性モデル、デバッグプロトコル、制御プロトコルなどの周辺環境の開発が複雑で、コア自体の設計能力を損なうことが多いという大きな課題が残っています。

この課題を解決するために、私たちはFPGAをターゲットとした柔軟なアンコア・インフラストラクチャを提案します。このインフラストラクチャは、可能な限りのRISC-Vコア設計を実装、テスト、使用するために使用できます。このアンコア・インフラストラクチャは、RISC-Vのメモリ・セマンティクスに適合したマルチコア・サポートのための設定可能なキャッシュとメモリ階層を含んでおり、性能指標やデバッグ情報の収集を簡素化するための容易に適応可能な通信プロトコルを備えています。このアプローチにより、性能重視のコアとキャッシュコヒーレントなマルチコアシステムの両方を、対象となるFPGAに最小限のリソースしか必要とせずに開発できることを示しています。また、コア設計者は設計の本質的な部分に集中することができ、研究者や学生にとっても魅力的なフレームワークとなっています。私たちはこのフレームワークを1年生の学士課程で使用し、成果を上げています。

周辺システムを含めた学生向けのUncoreインフラストラクチャの構築。

  • rtlv: ハードウェア上のソフトウェアのプッシュボタン検証

この論文では、ハードウェア上で何サイクルも実行されるソフトウェアの特性を、プッシュボタンで形式的に検証するアプローチであるrtlvを紹介します。例えば、rtlvは、ブートコードを実行するとプロセッサのマイクロアーキテクチャの状態が既知の決定論的な値にリセットされることを証明するために使用することができます。

rtlvは、2つの重要なアイデアにより、多くのサイクルの回路実行に関する推論を扱うことができます。第一に、rtlvはハイブリッドシンボリック実行を用いて、シンボリック値を持つ回路の推論を行い、シンボリック表現の複雑さを最小限に抑えています。第二に、rtlvは、パフォーマンス・ヒント・インターフェースを備えた再利用可能な回路に依存しないプロパティ・チェッカーの開発を可能にし、開発者は、証明が正しいという信頼性を維持しながら、検証パフォーマンスを最適化することができます。

rtlvを使って、小型(1,300フリップフロップ)のRISC-V SoCの状態消去特性を正式に検証すると、わずか1.3秒で終了します。一方、オープンソースの人気検証ツールであるSymbiYosysは12時間以内に終了することができませんでした。別のケーススタディでは、rtlvは4,300個のフリップフロップを持つ大規模なRISC-V SoCに拡張され、この状態クリア特性を検証するためには、ハードウェア上で実行されるソフトウェアの2万サイクル以上をモデル化する必要があります。rtlvを用いた形式検証では、ベースラインのハードウェアにおけるこの特性の違反を発見して修正することができ、rtlvがバグの発見に有効であることが実証されました。

ふーむ、検証環境の話なんだろうが、良く分からない。ちゃんと論文読んでみよ。

設計セッション2

  • 高度な再構成可能SIMD命令を探求するためのRISC-V ISAの拡張

本論文では、ソフトコアにおけるカスタムSIMD命令を検討するための、新しい非標準的なベクトル命令タイプのセットを紹介します。この新しいタイプは、比較的多くのオペランドへの同時アクセスを可能にし、必要に応じて命令数を減らすことができます。さらに、オープンソースの高性能なRISC-V(RV32 IM)ソフトコアを導入し、カスタムSIMD命令の検討やストリーミング性能の向上に最適化しました。HDL/Verilogによる命令開発のための命令テンプレートを提供することで、効率的なFPGAベースの命令を少数の低レベルコードで開発することができます。カスタムSIMD命令の性能を向上させるために、ソフトコアのキャッシュ階層は、最終レベルのキャッシュに非常に広いブロックを使用するなどして、帯域幅を最適化しています。このアプローチは、FPGA上のメモリ集約型アプリケーションの例で実証されています。今回の研究はソフトコアをベースにしていますが、その目的は、再構成可能な領域を備えた将来のCPUにカスタム命令として搭載可能な高度なSIMD命令を実験する手段を提供することにあります。最後に、このような将来のマイクロアーキテクチャーの課題と有効性について、いくつかの洞察を示します。

ふーむP拡張ではダメだったということなんだろうか?

科学的計算の急速な発展に伴い、ますます多くの研究者や開発者が、様々なデバイス上で様々なワークロード/操作を実装することに尽力しています。これらのデバイスの中で、NVIDIA GPUは、その包括的なドキュメントと優れた開発ツールのため、最も人気のある選択肢となっています。その結果、高性能なCUDAコードを手書きするためのリソースが豊富にあります。しかし、CUDAは主に商用製品のみでサポートされており、オープンソースのH/Wプラットフォームへのサポートはありませんでした。RISC-Vは、その洗練されたデザインとオープンソースライセンスにより、ハードウェアISAとして最も人気のある選択肢です。本プロジェクトでは、これらの既存のCUDAコードをRISC-Vデバイスで利用することを目指しています。具体的には、RISC-V GPUアーキテクチャ上でCUDAソースコードを実行できるパイプラインを設計・実装します。その結果、マルチスレッドやアトミック命令など、いくつかの重要な機能を持つCUDAカーネルRISC-V GPUアーキテクチャ上で実行することに成功しました。

まず、RISC-V GPUアーキテクチャを実装し、これの上にCUDAを動かした。すごいな。

本論文では、RISC-V v0.9ベクトルISA拡張のサブセットを実装した、コンフィギュラブルなハードウェアアクセラレータアーキテクチャであるArrowを紹介します。実験の結果、Arrowコプロセッサは、Xilinx XC7A200T-1SBG484C FPGAに実装した場合、機械学習推論の基本となる一連のベクトルおよび行列ベンチマークを、スカラRISCプロセッサよりも2~78倍高速に実行でき、消費電力は20~99%削減できることがわかった。

ベクトル命令のゴリゴリな実装。実装の詳細はあまり語られず。

近年、RISC-V Open ISAの登場により、オープンソースハードウェアの重要性が高まっています。それに伴い、コンパイラツールから本格的なOSまで、オープンソースのソフトウェアスタックをサポートする動きも加速しています。OpenCLなどのアプリケーション・プログラミング・インターフェースを用いた並列コンピューティングは、コモディティ・マルチコア・プロセッサープログラマブルな並列アクセラレータの並列性を有効に活用できることがわかっています。しかし、我々の知る限り、コモディティRISC-Vプロセッサを対象としたOpenCLの実装は、現在のところ、オープンソース・コミュニティからアクセス可能なものはありません。OpenCLは、RISC-Vを科学的な並列アプリケーションに開放するだけでなく、コンピュータ・アーキテクチャの研究に役立つユニークなジャンルのベンチマークへのアクセスを提供します。本研究では、オープンソースで実装されているOpenCLRISC-V CPU向けに拡張しました。本研究では、マルチコアのRISC-Vプロセッサだけでなく、原子命令やマルチスレッドをサポートしていないロープロファイルの組み込みRISC-V CPUも対象としています。

OpenCLRISC-V向けに拡張した話。RISC-Vへの移植の話かな?

セキュリティセッション2

SpectreやMeltdownのようなセキュリティ関連のサイドチャネル攻撃は、マイクロアーキテクチャの実行におけるエッジケースを利用しています。この種の攻撃は、多くのマイクロプロセッサに共通する最新のパフォーマンス機能によって可能になっています。設計段階で潜在的脆弱性を特定するためには、セキュリティホールが存在する可能性のあるハードウェアの状態をすべて探索できる機能検証が必要です。今日の多くのアプリケーションの要件を考慮すると、商業市場では、これらのサイドチャネルの問題を解決することが求められています。設計プロセスにおいてフォーマル検証ツールを活用するには、多大なエンジニアリング・リソースの投資が必要であり、マイクロアーキテクチャ設計の機能が導入され、複雑さが増すにつれて、これらのコストは増加すると考えられます。

本稿では、複雑なRISC-Vマイクロアーキテクチャのマイクロアーキテクチャ設計プロセスにおいて、セキュリティ指向の検証を可能にするための我々の初期の取り組みを紹介する。我々はこの目標を達成するために、サイクルベースの性能評価のために設計された最先端のシミュレーション・フレームワークである Akita と、境界型マイクロアーキテクチャ検証を統合しました。このアプローチにより、コンピュータ・アーキテクトは、新規および既存の性能機能を評価し、トレードオフを行うことができるようになり、また、セキュリティへの影響を単一のフレームワークで評価することができるようになります。本論文では、この統合を可能にする、形式的検証と秋田のイベントベースモデリングとの間の論理的な橋渡しを行う方法を紹介します。秋田モデルを基本コンポーネントに分解し、形式検証用の公理的モデルとして再構築する方法を示す。

  • RISC-Vセキュアコンピュート環境におけるデザインスペース探索の実現

TEE(Trusted Execution Environments)のサイクルレベルのアーキテクチャ・シミュレーションは、これらのセキュア・アーキテクチャのデザイン・スペースを広範囲に渡って探索することを可能にします。TEEをサポートする既存のアーキテクチャ・シミュレータは、ハードウェアレベルの実装に基づくものと、抽象的な解析モデルに基づくものがあります。本論文では、RISCVベースのオープンソースTEEであるKeystoneの実行と評価に必要なgem5モデルの実装について説明し、このシミュレーション環境が、これらの信頼できる環境を設計・研究するための新たな道を開くことを議論します。gem5上でのKeystoneのシミュレーションは、以前に行われたKeystoneのハードウェア評価と同様の性能を示すことを示します。また、3つの簡単な使用例(信頼された実行の速度低下の理由の理解、メモリ暗号化の性能、信頼された実行の性能に対するマイクロアーキテクチャの影響)を説明し、TEEをシミュレーションする能力が、既存の形や強化された設計でのTEEの動作に関する有用な情報を提供できることを示します。

  • ERTOS: Enclaves in Real-Time Operating Systems

エッジコンピューティングやIoT(Internet of Things)デバイスの普及に伴い、組み込みデバイス上で安全に計算を行う必要性が高まっています。一般的に、組み込み機器は異種環境であり、クラウド上のホストと比較して一般的なセキュリティ保護機能を備えていません。組込み機器上で実行されるサードパーティ製のライブラリやアプリケーションが増えてくると、機器のRTOSカーネルでさえ保護できないシステム侵害のリスクに直面します。組込み機器上に信頼性の高い実行環境(TEE)を構築することが求められていますが、現在のTEEの多くは高価なハードウェアを必要とします。私たちは、カスタマイズ可能なTEEを作成するためのフレームワークであるKeystoneをRISC-Vアーキテクチャ上で使用することを提案します。KeystoneでTEEを作成するためのハードウェア要件は、標準的なRISC-Vデバイスで一般的に利用可能です。RISC-Vは、Keystoneのアイソレーションの基礎となるPMPレジスタをすでに提供しているからです。我々は、KeystoneとFreeRTOSを使用して、組み込み機器上で効率的かつ動的なTEEを作成するためのモジュールをFreeRTOSに実装することを提案します。FreeRTOSの新しいモジュールであるERTOSを紹介します。ERTOSは、Keystoneのセキュリティモニタを使用して、他のタスクから強力に隔離された認証可能な安全なタスクを作成することができます。ERTOSは、開発者がエンクレーブで保護されたタスクを作成、実行できるように、使いやすいAPIを公開しています。ERTOSは、エンクレイブ内の計算量の多いタスクに対して無視できる程度のパフォーマンス・オーバーヘッドを追加し、タスク間通信をより効率的に行うための最適化を導入しています。

CARRV 2021の発表論文概観 (1)

ISCA 2021と併設されているCARRV 2021の論文が公開されている。25本近くの論文が公開されているのですべてを読むことは出来ないので、とりあえずカテゴリ別にAbstractだけ読んで日本語にしてみることにした。

これも量としてはかなりあるので、DeepLにお世話になりながらさっくりと日本語を読んで概要をつかんでみることにした。 面白そうなものだけピックアップして読むことにしてみよう。まずは前半。後半は明日。

carrv.github.io


設計セッション1

完成すれば最大の電波望遠鏡となるスクウェア・キロメター・アレイは、エクサスケール時代とその先にあるコンピューティングの模範例の一つです。演算性能とエネルギー効率は、現在のトップレベルのスーパーコンピュータよりも少なくとも2、3桁優れていることが求められます。これらの要求を満たすために、GPUFPGAアクセラレータが何度も検討されてきましたが、ソリューションのアルゴリズムアーキテクチャの特性に根ざした制限のために、約束された可能性を満たすには至っていません。

SKAのデータ処理を有意義な時間とリソースの範囲内で行うためには、クリーンスレートのアプローチが有効であると考えています。このポジションペーパーでは、SKAのデータ処理ニーズに特化して設計されたオープンソースドメインスペシフィック・システムオンチップである「RISKA」を提案します。現在の提案の範囲は、SKAのサイエンス・データ・プロセッサ・スーパーコンピュータ(SKA-SDP)の要件に対応することであり、将来的には他のシステムに拡張することを意図している。RISKAは、オープンソースRISC-V CPUコアと、SKA-SDPに特化したカスタムデザインのアクセラレータおよびオンチップメモリを組み合わせたもので、SKA-SDPの性能およびエネルギー効率のボトルネックを解消するための予備的なデザインについて説明します。最後に、RISKAの開発は、オープンソースのコラボレーションモデルに基づいて行われるべきであると提案します。

電波望遠鏡のデータ処理のために設計されたSoCであるRISKAの発表。なんか電波望遠鏡については昔にも論文を読んだことがあるような気がする。

  • NeuralScale: クラウドでのAI推論を促進するRISC-Vベースのニューラルプロセッサ

ここ数年、クラウドコンピューティング用のAIチップが非常に増えてきました。特化したAIチップのほとんどは、特定のアプリケーションを最適化するために設計されており、プログラマビリティや柔軟性に欠けています。本論文では、クラウドにおけるAI推論のためのRISC-Vベースのニューラル・プロセッサ・コア・アーキテクチャであるNeuralScaleを紹介します。NeuralScaleは、競争力のある性能と効率性を維持しながら、RISC-Vベクトル拡張によりプログラマビリティを大幅に促進します。当社の工業製品であるP920は、32個のNeuralScaleコアを搭載し、TSMC 12nm FinFETプロセス技術を用いて、1.0GHzのクロック周波数で256TOPS(INT8)および128TFLOPS(FP16)のピーク性能を達成しています。典型的な推論ワークロードでの評価結果は、本プロセッサが最先端のスループットと電力効率性能を実現していることを示しています。

RISC-Vのベクトルサポートのクラウドコンピューティング用のAIチップの紹介。

  • RISC-V Dataflow Extension

データフローアーキテクチャは、フォン・ノイマン(コントロールフロー)アーキテクチャに代わるもので、性能の向上とエネルギー消費の低減が可能です。既存のデータフローアーキテクチャには、明示的なものとハイブリッドなものがあります。明示的なデータフロー・アーキテクチャは、不規則なワークロードに対して高いパフォーマンスを提供しますが、コントロールフロー・アーキテクチャは、効果的な制御投機と正確な割り込み/例外処理を提供します。ハイブリッド・データフロー/ボン・ノイマンアーキテクチャーは、データフロー・アーキテクチャー・モデルとコントロール・フロー・アーキテクチャーの両方を組み合わせたものである。

既存のハイブリッドアーキテクチャの多くは、データフローの要素をフォン・ノイマン計算機モデルに統合したものである。本研究では、RISC-Vアーキテクチャのために、明示的なデータフロー命令を実行可能なISA(Instruction Set Architecture)拡張を設計しました。また、データフロー/フォン・ノイマン型のヘテロジニアスなCPUモデルをGem5シミュレータに実装しました。いくつかのマイクロベンチマークを実行した結果、最大で7.5%の性能向上が見られ、データフローISA拡張とデータフロー/フォン・ノイマンヘテロジニアスなアーキテクチャの可能性が示されました。

RISC-VのISAをデータフロー向けに拡張したということ?

エッジコンピューティングの台頭や暗号・誤り訂正符号の高度化に伴い、携帯機器用プロセッサには、ガロア体演算をベースとした多様なアルゴリズムの処理が求められています。これらの演算がプロセッサの命令セットに含まれている場合、汎用プロセッサの実行時間を効率を低下させることなく最適化するためには、速度と消費電力のトレードオフが必要です。本研究では、ガロア体演算の乗算用RISC-V命令セットを実装し、Nexys A7 FPGA上でSweRV-EL2 1.3を用いて検証しました。AESやReed-Solomonコードのようないくつかのアルゴリズムでは、論理使用率がわずかに増加するものの、性能が向上しています。

"ガロア体演算の乗算用RISC-V命令セット"なんじゃそりゃ!?

解析セッション

  • 機能指向プログラミングによるRocket Chipの性能カウンター設計バリエーション

パフォーマンスカウンタは、開発者にとって、自分のアプリケーションが特定のプラットフォーム上でどの程度動作するかという重要な情報を提供します。現在、Rocket Chipジェネレーターには、パフォーマンスカウンタシステムが搭載されていますが、そのバリエーションは、カウントレジスタの数のみとなっています。RISC-Vが幅広いアプリケーションで魅力的であるためには、他のバリエーションも可能であるべきです。例えば、マイクロアーキテクチャのイベントにしか興味がない開発者がいるとします。例えば、マイクロアーキテクチャのイベントだけに興味がある場合、特定の機能の中だけでカウントした方がより多くの情報が得られる可能性があります。

そこで、パフォーマンスカウンタのサブシステムを、Rocket Chipに適用可能な個別の直交する機能ユニットに再構成し、その機能を単独または組み合わせて適用するツールを開発しました。Scalaの抽象構文木を操作して機能を適用し、機能の依存関係を自動的に判断するツールを開発しました。また、このような機能を構築するためのシンプルなドメイン固有言語を設計しました。

パフォーマンスカウンタの実装を機能に特化させることで、Rocket Chipの開発者には、より多くの実装の可能性を提供しています。開発者は、RISC-Vイベントの任意のサブセットを選択して監視することができます。モニタリング対象のプロセッサに新しいイベントを簡単に導入できます。必要に応じて、プログラムカウンタの特定の範囲内でのみイベントをカウントすることができます。

我々の機能や他の興味深い設計上のポイントを用いて、現在のパフォーマンスカウンタを再構築しました。これらの構成に必要なリソースを示す結果を示します。

Rocket-Chipのためのパフォーマンスカウンタを新たに設計してRocket-Chipに組み込んだということ。

  • Linux用性能解析ツール(Perf)によるRISC-Vパフォーマンスカウンターのサポート

クラウド、データセンター、オートモーティブ、ネットワーキングなどの分野でRISC-Vへの注目が高まっており、RISC-Vをハイパフォーマンス・コンピューティングのシナリオに組み込む動きが活発化しています。しかし、強力なパフォーマンス・モニタリング・ツールがないと、アプリケーションが十分に最適化されず、結果的にコンピューティング・パフォーマンスが制限されてしまいます。RISC-V ISAはすでにハードウェア・パフォーマンス・モニター(HPM)を定義していますが、現在のソフトウェアでは、パフォーマンスをモニターするためのサポートが限られています。本論文では、RISC-V性能監視仕様の完全なサポートを実現するために、Linux用の性能解析ツール(perf/perf_events)、Linuxカーネル、およびOpenSBIの拡張および修正を紹介します。予備的なテストと評価を、FPGAブートのCVA6 CPU(旧称Ariane)上で動作するLinux 5.7で実施したところ、モニタリングのオーバーヘッドは0.283%でした。

こちらはソフトウェアの修正。LinuxのPerfを使用するためにperf, Linuxカーネル、OpenSBIに修正を追加したということ。

マイクロプロセッサの設計、デバッグ、検証の研究開発は、さまざまな抽象度のモデリングとシミュレーションに基づいて行われるようになってきています。マイクロアーキテクチャレベルのシミュレータは、抽象度の低いレベルに比べてシミュレーションのスループットが高いため、性能評価に最もよく使われるツールとなっていますが、その代償としてハードウェアの精度が損なわれることがほとんどです。その結果、研究者やマイクロプロセッサの設計者にとって、マイクロアーキテクトのシミュレータの実装、速度、精度はますます重要になってきています。マイクロアーキテクチャーシミュレータの最も重要な点の一つは、マイクロアーキテクチャーの様々な側面が設計の改良に伴って変化する中で、設計基準を正確に表現する能力です。一方、最近のマイクロプロセッサのモデルは、専用のハードウェア実装に依存しているため、設計空間の探索には時間がかかり、高レベルモデルからハードウェア・プロトタイピングまで、さまざまな方法を用いて行われます。そのため,シミュレーションの速度と精度の間のトレードオフが大きく変化し,アプリケーションの性能測定が不確実になることがあります。

本論文では,RISC-Vアウトオブオーダー・スーパースカラ・マイクロプロセッサ・コアの性能を可能な限り正確にモデリングするための,マイクロアーキテクチャレベルのシミュレーション・モデリング研究を紹介します。広く使用されているgem5シミュレータの重要なマイクロアーキテクチャ・パラメータを調整することにより,マイクロアーキテクチャレベルのシミュレーションで正確な性能モデリングを行うことが,ターゲットデザインのRTLシミュレーションの精度や低いシミュレーション・スループットと比較してどのような課題があるかを調査しました。さらに,マイクロアーキテクチャレベルのモデリングの高精度化を妨げる主なエラーの原因を明らかにしました。

Gem5を使用したサイクル精度RISC-Vアーキテクチャシミュレータの話。

  • SwiftからMightyへ。アプリケーションの性能、消費電力、面積に関するIbexとCV32E40Pのコスト・ベネフィット分析

lowRISCやOpenHW Groupのような非営利の共同エンジニアリング組織の台頭により、オープンソースは、産業界で実行可能なコンピューティングハードウェア開発のパラダイムとして普及し続けています。これらの組織は、RI5CYから派生したIbexおよびCV32E40Pプロセッサの開発を続けています。RI5CYは、初期の、そして最もよく知られた学術的なオープンソースRISC-V設計の一つです[1, 2]。当初、この2つのコアは、それぞれ低コストの制御タスクとエネルギー効率の高い信号処理をターゲットとして、明確に差別化されていました。しかし、Ibexでは、業界水準の検証と規格準拠を確立したことに加え、いくつかの性能重視の機能が追加されたため、コアや構成の選択が明確ではなくなりました。

本研究では、アプリケーション性能、シリコン面積、消費電力の観点から、2つのコアを徹底的に比較しました。Ibexの新機能は、IPC(インストラクション・パー・サイクル)性能を最大で34%向上させる一方で、最大動作周波数に悪影響を与えます。ライトバックステージとシングルサイクル乗算器を組み合わせることで、最高の周波数で最高の性能が得られます。この構成は、性能面ではCV32E40Pと同等ですが、面積は40%少なくて済みます。CV32E40Pは、カスタム命令セットの拡張機能と最適化されたパイプラインを利用することで、制御が少なく計算量の多い信号処理に適しています。

2つのコアIbexとCV32E40Pのコアを比較している。

セキュリティセッション1

  • Keystoneにおけるデマンド・ページングのための高速かつ安全な決定論的Stash Free Write Only Oblivious RAMの導入

Keystoneは、RISC-Vアーキテクチャをベースにした信頼性の高い実行環境です。メモリを安全なKeystoneプライベート・メモリと安全でない非Keystoneメモリに分割し、Keystoneプライベート・メモリ内にあるコードを安全に実行できるようにしています。Keystoneの単純なデマンドページングでは、Keystoneアプリケーションの機密性の高いアクセスパターンが、悪意のあるオペレーティングシステム(OS)に漏れてしまいます。これは、Keystoneが安全でない非Keystoneメモリにアクセスするためには、OSのサポートが必要だからです。これを緩和するために、KeystoneはOblivious RAM(ORAM)技術を使用してページアクセスパターンを難読化しながら、oblivious demand pagingを実装する必要があります。そのため、アプリケーションの実行速度が大幅に低下してしまいます。

本論文では、Detinistic, stash free, Write only ORAM (DetWoORAM)をoblivious demand pagingに使用することで、Keystoneにおける非セキュアなデマンド・ページングとセキュアなデマンド・ページングのアプリケーション実行時間の間のパフォーマンス・ギャップを解消します。また、Write only ORAMであるDetWoORAMがなぜ oblivious demand pagingに十分なのかを示します。DetWoORAMは、メモリを論理的に主領域と保持領域に分割します。実際のページは主領域に格納されます。我々は、アプリケーションの実行速度の低下を改善するために、DetWoORAMに対する2つの拡張機能を提案します。1つ目は、Eager DetWoORAMと呼ばれるもので、DetWoORAMの決定論的なアクセスパターンを利用したページのプリロードを行い、ORAMのレイテンシーを隠そうとするものです。2つ目の改良点は、Parallel DetWoORAMと呼ばれるもので、複数のスレッドを生成し、各スレッドがDetWoORAMのメモリアクセスアルゴリズムの一部を実行します。DetWoORAMが[1.4x, 2x, 3.24x]の速度低下を示したのに対し、Eager DetWoORAMとParallel DetWoORAMは、k=3, 7, 15の場合、それぞれ[1.2x, 1.8x, 3.2x]と[1.1x, 1.1x, 1.4x]の速度低下を示しました。

  • RISC-VおよびCHERI-RISC-Vに対する過渡応答攻撃のテスト・スイートの開発

本論文では,RISC-Vにおける主要な過渡現象発生攻撃の再現を含む,柔軟で拡張可能なベアメタル・テスト・スイートを紹介します.このテスト・スイートは,オープンソースのアウトオブオーダー・スーパースカラRISC-VプロセッサであるRiscyOOで実証されています.これらの攻撃は、FPGAハードウェアとシミュレーションの両方で特性評価を行っていますが、そのシンプルさは、特にプロセッサ開発時のシミュレーションによる検証に適しています。例として、RiscyOOにCHERIセキュリティ拡張を施したバージョンを評価します。CHERIは、インストラクションセットアーキテクチャ(ISA)のセキュリティ拡張機能で、きめ細かなメモリ保護とコンパートメント化を実現します。これは、メモリの安全性を侵害して特権を得たり、秘密を漏らしたりする過渡実行攻撃の興味深いターゲットとなります。今回の結果は、洗練されたRISC-Vの実装が、主流のアーキテクチャと同様の過渡実行攻撃に対して脆弱であることを明確に示していますが、オープンソースの実装とオープンソースの検証ツールが、開発中の脆弱性の発見と排除に役立つことを期待しています。さらに、CHERI-RISC-Vの命令セットは、過渡的実行攻撃に対する防御を意味するものではありませんが、慎重な実装と積極的なポインタ・バウンディングによって、いくつかの形態の攻撃を緩和できることを示します。我々の拡張可能なテスト・スイートは、RISC-Vシステムにおける過渡実行攻撃とその緩和に関する今後の研究のための共通の基盤となり、オープンソースの高性能で安全なRISC-Vプロセッサの成功への道を開くものと期待されます。

  • RISC-Vオープンハードウェア設計による安全な投機的実行

近年、さまざまなSpectre攻撃をはじめ、最新のプロセッサではマイクロアーキテクチャ脆弱性が悪用されるケースが急増しています。現在のソフトウェアによる緩和策は、重要な性能オーバーヘッドがあり、多くの場合、ソースコードの修正を必要とします。また、アーキテクチャの拡張は、ほとんどがシミュレータで検証されており、実際にハードウェアを実装して評価することはありません。

本プロジェクトでは、安全な投機的実行(SSE-RV)のための効率的なaint-trackingソリューションを提案し、最も有名な投機的実行攻撃から保護します。本プロジェクトでは,RISC-Vのオープンハードウェアエコシステムを活用したセキュアバイデザインアプローチを採用し,最新のバークレーのOut-of-Order Machine(SonicBOOM)にテイントトラッキングカニズムを実装しました.また,Linuxが動作するFPGA上でSSE-RVプロセッサのプロトタイプを作成した.その結果、Spectre-v1, v2, v5からの保護が可能であると同時に、単一の小型BOOMコアの性能として0.66 CoreMark/MHzを達成しました。また,実装コストを評価するために,130nm BiCMOS技術をターゲットとしたプロセッサコアを合成しました。その結果,保護されていないコアと比較して,ゲート数が0.42%増加し,コア全体の消費電力が1.7%増加するだけでした。今回開発した防御方式は一般的なものであり,他の過渡的実行攻撃に対する防御にも拡張可能である.

  • RISC-V GPGPUによる暗号技術の高速化

AESとSHAファミリーは、それぞれ対称暗号とハッシュ化を行う代表的な暗号アルゴリズムです。AESとSHAの呼び出しには高度な並列処理が必要となるため、GPGPUでのハードウェア高速化が望まれています。そこで、既存のGPGPUに暗号実行ユニットを追加し、これらのアルゴリズムの重要な要素を高速化しました。RISC-V暗号拡張ドラフト仕様のサブセットをVortex GPGPUに実装したところ、Vortex上の純粋なソフトウェア実装に比べ、SHA-256で1.6倍、AES-256で6.6倍の高速化を実現しました。

RISC-Vベクトル拡張仕様書 v1.0 を読み直す (2. vtypeレジスタ)

RISC-Vベクトル拡張仕様書の読み直し、次はvtypeについて。 ここがRISC-Vベクトル拡張の一番難しいところ。vlmulに応じてベクトルの長さとグルーピングが変わる。やっかいなところ。

結構昔に翻訳したバージョンだと、LMULは整数しか取れないようになっていたが、最新版では小数も取れるようになっている。これはベクトルレジスタをより短く扱おうというもの。


github.com

3.3. ベクトル型レジスタ vtype

読み取り専用のXLEN幅を持つ ベクトル 型 CSR (vtype)は、 ベクトルレジスタファイルの内容を解釈するために使用されるデフォルトの型を提供し、 vset{i}vl{i} 命令によってのみ更新することができます。 ベクトル型は、各ベクトルレジスタの要素の構成や、複数のベクトルレジスタをどのようにグループ化するかを決定します。

vtype レジスタには、 vill 、 vma 、 vta 、 vsew[2:0] 、 vlmul[2:0] の5つのフィールドがあります。

3.3.1. ベクトル選択要素幅 vsew[2:0]

vsew の値は、動的な 選択要素幅 (SEW)を設定します。 デフォルトでは、ベクトルレジスターは、 VLEN/SEW要素に分割されているとみなされます。

3.3.2. ベクトルレジスタのグループ化(vlmul[2:0])

複数のベクトルレジスタをグループ化することで、1つのベクトル命令で複数のベクトルレジスタを操作することができます。 本仕様書では、ベクトル命令の単一オペランドとして使用される1つまたは複数のベクトルレジスタを指すために ベクトルレジスタグループ という用語を使用しています。 ベクトルレジスタグループは、2倍以上の幅の要素を、選択された幅の要素と同じベクトル長で操作することを可能にします。 また、ベクトルレジスタグループは、長いアプリケーションベクターの実行効率を高めます。

ベクトル長 の倍数 LMUL が1より大きい場合は、ベクトルレジスタグループ形成するために 結合されるベクトルレジスタのデフォルト数を表します。 実装では、LMULは整数値1,2,4,8をサポートする必要があります。

LMUL は、ベクトルレジスタで使用されるビット数を減らすために、小数値を取ることもできます。 LMUL は、1/2、1/4、1/8 の分数値を持つことができます。 小数点以下のLMULは、幅の広いベクトルが複数のベクトルレジスタを使用する必要がないため、 幅の異なる値を操作する際に使用可能なアーキテクチャレジスタの数を増やすために使用されます。 その代わり、幅の広い値は1つのベクトルレジスタを占有し、 幅の狭い値はベクトルレジスタの端数を占有することができます。

実装では、LMUL ≥ SEW{LMUL1MIN}/SEW{LMUL1MAX} の小数の LMUL 設定をサポートする必要があります。 SEW{LMUL1MIN} はLMUL=1でサポートされる最も狭いSEW値で、 SEW{LMUL1MAX} はLMUL=1でサポートされる最も広いSEW値です。 サポートされていないSEWとLMULの設定を行おうとすると、vtypevillビットが設定されます。

サポートされている小数のLMUL設定に対して、 実装はSEW{LMUL1MIN} とLMUL * SEW{LMUL1MAX} の間のSEW設定をサポートしなければなりません。

LMUL=2の場合、ベクトレジスタグループには、ベクトレジスタv nとベクトレジスタv n+1が含まれ、 ビット単位で2倍のベクト長になります。 LMUL=2のベクトレジスターグループで、奇数番号のベクトレジスターを指定する命令は予約されています。

LMUL=4 の場合、ベクトレジスターグループには 4 個のベクトレジスターが含まれ、 4 の倍数ではないベクトレジスター番号を使用して LMUL=4 のベクトレジスターグループを指定する命令は予約されます。

LMUL=8 の場合、ベクトレジスターグループには 8 個のベクトレジスターが含まれ、 8 の倍数ではないレジスター番号を使用して LMUL=8 ベクトレジスターグループを指定する命令は予約されています。

マスクレジスタは、LMULにかかわらず、常に1つのベクトレジスタとして取り扱われます。