テンシリカは急速に成長している企業です。同社の主な製品は、プロフェッショナルアプリケーション向けのマイクロプロセッサであり、今日の大容量組み込みシステムに最適なソリューションを提供します。同社は1997年7月に設立されました。同社の投資家には、Oak Investment Partners、Worldview Technology Partners、Foundation Capitalの3つの有名なベンチャーキャピタル企業と、ハイテクエレクトロニクス業界の5つの有名な企業Cisco Systems、Inc、松下電器産業株式会社、アルテラ株式会社、NEC株式会社およびコネクサントシステムズ。テンシリカの創設者は、初代CEOでもあるクリスローウェンです。彼は、インテル、スタンフォード、MIPS、SGI、シノプシスで働いていました。また、再構成可能な処理のアイデアの提案者であり、実践者でもあります。テンシリカの作成の目的は、対応するソフトウェア開発ツールを備えた、再構成可能なASICベースの専用マイクロプロセッサソリューションを提供することです。
HIFIシリーズ製品の主な用途は次のとおりです。
構成可能なプロセッサコアとして、Xtensaプロセッサは命令拡張をサポートします。ユーザーは共通ロジックを回路にカプセル化し、呼び出す新しい命令を追加できます。次に例を示します。
fは関数を表し、FFTまたはCRCなどの任意のアルゴリズムのいずれかです。
1.高水準プログラミング言語の効率的なコンパイルをより適切にサポートするために、最近のプロセッサには通常16個または32個の汎用レジスタがあります。非常に多くのレジスタが、より複雑なアプリケーションで深みを実現できます。プログラムを正しく実行するには、レジスタをスタックに頻繁に出し入れする必要があります。このような頻繁なスタックメモリアクセスは、アプリケーションのパフォーマンスを大幅に低下させます。この問題を効果的に解決するために、tensilicaのXtensaアーキテクチャWindowsローテーションのレジスタ管理メカニズムモードは、論理レジスタと物理レジスタを分離するように設計されています。関数が呼び出されると、論理レジスタは、レジスタのカバレッジを回避するためにスライディングウィンドウによって切り替えられます。スタックとスタックを減らすために、設計に抽象化が追加されます。スタック操作により、パフォーマンスが向上します。より大きな範囲で。次の図は、64個の物理レジスタに実装されたレジスタウィンドウを示しています。ISAでは16個のARレジスタしか定義されていませんが、実際のマイクロアーキテクチャの設計は物理レジスタの数に限定されません。もちろん、マイクロアーキテクチャレジスタの数に応じてコストが増加します。増加しました。
より具体的なマッピングの例：
レジスタウィンドウの動作メカニズムに関して、WindowBaseは命令のsrcフィールドとdstフィールドと連携して、次の図で表すことができる最終的な物理レジスタアドレス指定の動作原理を実現します。接続のスラッシュの横の数字は次の図に示すように、データビット幅。これは、64個の32ビット物理レジスタのマイクロアーキテクチャによって実装されたアドレス指定スキームを表しています。
物理レジスタの数には限りがあります。コール4/8/12が複数のレイヤーにネストされている場合、元のレジスタウィンドウが上書きされます。上書きが発生すると、Xtensaはレジスタウィンドウの例外を通じてこの状況を処理します。レジスタウィンドウメカニズムでは、a0-a3への参照はレジスタウィンドウ例外を生成しません。どの環境でも、現在の論理ウィンドウのレジスタに上書きがないか、またははすでに存在します呼び出し/エントリ命令はスタックにプッシュされます。a4-a15の高レジスタ参照は、低レジスタのカバレッジ検出をトリガーします。低レジスタが表示されていない場合でも、トリガーシーケンスは最初にoverflow4、次にoverflow8からoverflow12になります。
エントリ命令の実行擬似コード：
2.ESP32とHIFI3 / 4/5の違い
HIFI3 / 4/5のISAは同じですが、リソースの数と実行ユニットの実装に違いがある可能性があります。
総括する：
- Xtensaコアに基づいて、HIFIシリーズはさまざまなDSP操作を高速化するためのVLIWコンピューティングユニットの統合など、DSP拡張機能を統合します。ESP32コアにはこれらの拡張機能がありません。
- ESP32シリーズとHIFIシリーズの基本ISA部分は同じである必要があります。これは、RISCV ISA RV32I / 64I拡張機能の設計にいくらか似ています。ただし、同じBase ISAは、プロセッサの特性がまったく同じであることを意味するわけではありません。特に、Xtensaは再構成可能なプロセッサ設計アーキテクチャをサポートしているため、新しい命令を簡単に拡張できるため、HIFIシリーズはxtensaのDSPとして実装されます。コア。高速DSP操作DSP命令をサポートするために追加する必要があります。ESP32はDSPではなく、これらを備えていません。
- ESP32には、シングルサイクル乗算および累積命令などの32ビットmac単一命令がいくつかあります。一部のDSP操作にも使用できますが、HIFIコアアプローチとは完全に異なります。HIFIコアはハードウェアベクトルに基づいて実装されます。およびVLIW。、DSP処理を対象としており、パフォーマンスは間違いなく同じレベルではありません。
- 実際、DSPのような操作にESP32を使用するアルゴリズムライブラリを実装するプロジェクトがgithubにあります。esp-dspプロジェクト。
- HIFI5 DSPは、LXシリーズプロセッサの構成オプションであり、LXシリーズプロセッサコアに追加してDSPコアを形成できます。もちろん、追加しないとDSPではありません。DSPの拡張構成を使用する場合、コンパイラは、命令にHIFI5DSPを自動的に使用します。高速でコンパイルします。
- HIFI5 DSPは、Xtensa RISCアーキテクチャのベースラインに基づいて構築されています。その最も強力な機能は、ベースラインISAではなく、DSP命令セットとオーディオ命令セット拡張機能にあります。ベースラインISAを確認する場合は、esp32またはesp8266を使用して体験できます。それ。
- HIFIシリーズプロセッサは、同時に最大5つの命令を送信でき（構造、データ関連なし）、これらの5つの命令を128ビットの超長命令にパックし、5セットのVILWマシンスロット実行ユニットに配布して実行します。 。VLIWにまとめることができない構造関連の命令があります。たとえば、slot0のみがストア操作をサポートしているため、2つ以上のメモリストア操作を同時に実行するようにパッケージ化することはできません。スロット機能に依存する他の命令は次のとおりです。また、各スロットに応じて制限されます。サポート情報。
- xtensaは、独自のコンパイラxccのレジスタスケジューリング機能に非常に自信を持っているようです。そのため、ユーザーがHIFI5でDSPアセンブリをこすることはお勧めしません。
- HIFI4およびHIFI5と比較して、VLIWマシンスロットの数（HIFI4の場合は4、HIFI5の場合は5）などのパフォーマンスが向上し、HIFIはMACなどのより強力なコンピューティングリソースとロード/ストア帯域幅を備えています。 、HIFI5それも強化されました。ただし、ソフトウェア開発の観点からは、HIFI4 / 5はすべてXtensaLXプロセッサに基づいており、XEA2例外モデルをサポートしています。
- ESP32には、ISAに16ビットの乗算/加算命令を追加するMAC16がありますが、HiFi拡張機能はありません。これは、VLIWマシンスロットがないことを意味していると思いますが、よくわかりません... 興味があれば、ここにいくつかの例があり ます。リンクされたコードはESP32用にコンパイルされて実行されます。
- ウィンドウABIには、すべてのコードを同じGB領域に配置する必要があるという制限があります。例：0 ----- 0x3FFFFFFFまたは0x40000000 --- 0x7FFFFFFF、call4 / call8 / call12の有効範囲（524284〜524288バイト）。ただし、別のロングコールバージョンがあります。callx4/ callx8 / callx12は、コンパイラオプション-mlongcallsで有効にできます。Complierは、必要に応じてそれらを自動的に使用します。1GBリージョンでの通話を許可できます。
- Xtensa ISS（xt-runで呼び出される ）は、ユーザーがコマンドラインオプションを介して指定する、サイクルアキュレートと高速機能の2つの主要なシミュレーションモードをサポートします。デフォルトのサイクル精度モードでは、ISSはパイプラインの複数の命令をサイクルごとに直接シミュレートし、非常に高い精度を維持しながら、Xtensaプロセッサのほとんどのマイクロアーキテクチャ機能をモデル化します。このモードでは、ISSを詳細なハードウェアシミュレーションの参照モデルとして使用できます。
高速機能（または TurboXim）で）モードの場合、ISSはマイクロアーキテクチャの詳細をモデル化しませんが、すべてのXtensa命令と例外のアーキテクチャ的に正しいシミュレーションを実行します。長時間実行されるプログラムの場合、高速機能シミュレーションはサイクル精度シミュレーションよりも40〜80倍高速であるため、アプリケーションソフトウェアの高レベルの検証に最適です。
私たちのISSはiDMAとメモリをモデル化していますが、現在QEMUをサポートしていません。これにより他のシステムIPの拡張が可能になります。ただし、SystemCまたはSystemC / Verilog環境でのXtensaコアのトランザクションレベルのモデリングとピンレベルのモデリングの両方をサポートする別のツール（XTSC）があります。また、現在、QEMU上の他のIPと一緒にXTSCを共同シミュレーションしているお客様がいます。
Xtensa LXプロセッサにはFLIX（可変長命令拡張）と呼ばれる機能があり、プロセッサが既存の16ビットと24ビットのXtensa命令を混合して、カスタマイズされたワイド命令、VLIWダイアグラム、スロットが実行ユニット、各機能を生成できるようにします。異なる、あなたは命令が構造的に関連することができないことに注意を払う必要があります。
3. Googleのxtensaに関する情報によると、VLIWのアプリケーションシナリオと使用法に関する情報が抽出されます。これには、合計10の命令パッケージ形式が含まれます。各形式は、使用されるリソース、アプリケーションシナリオ、および命令の長さが異なります。
4：経験によると、通常の状況では、プロセッサISAの例外エントリを定義してソフトウェアに公開する方法は2つあります。1つ
目はISA固定例外のエントリアドレスです。たとえば、前のarm9には2つの0x00000000 / 0xffff0000。選択肢として、mipsの開始ベクトルは0xbfc00000などです。
2番目のタイプ：ISAは例外ベースアドレスレジスタを提供し、ソフトウェアは例外エントリアドレスを書き込むことができるため、例外エントリはriscv / cortex-aシリーズなどのアドレス空間のどこにでも配置できます。
しかし、xtensaの仕様では、エントリアドレスの定義がわかりませんでした。また、特定のレジスタに例外エントリを設定するコードも見つかりませんでした（ソフトウェアの逆コンパイル後、シンボルテーブルを探しましたが、見つかりませんでした）。特定のレジスタに設定されている例外シンボルを見つけます。（ロジック）
つまり、例外が発生すると例外処理関数が呼び出されることはわかっていますが、実行フローがどこから来るのかわかりません。
したがって、上記の2つのオプションが「いいえ」の場合、3番目の例外処理方法は何ですか？HWデジタル設計時にエントリアドレスが決定され、構成ファイル（ここではリンクスクリプトxmm）が生成され、ソフトウェアがこの構成ファイルに従って異常なコードを正しい場所に配置する可能性があります。それを理解することができます。
確認後、xtensaはこのように処理します。つまり、例外ベクトルテーブルのアドレスを再マッピングできます。これは、再構成可能なプロセッサであると主張する側面でもあります。 esp32 / exp8266SDK、ソフトコア再構成によって生成されたxmmファイルがリンクスクリプトを生成します。ソフトウェアは生成されたリンクスクリプトに従ってコードとデータをレイアウトします。したがって、ハードウェアのアドレスと異常なエントリロジックがバインドされます。チップTO、xmmファイルを再度変更すると異常が発生します。入力コードが実際のハードウェアと一致しない場合、CPUが間違った入力処理プログラムを入力すると問題が発生します。
ただし、ソフトウェアは、問題を解決するにはレイヤーを追加することで解決できるとよく言います。このステートメントはハードウェアにも当てはまります。結局のところ、これらはすべて言語です。デジタル設計の場合、一部のレジスタは周辺に構成できます。これらのレジスタはそうではありません。 xtensa ISAの一部。これらのレジスタによって設定されたロジックを介して、例外エントリを柔軟に設定し、riscv mtvec / stvecまたはcortex-CP15vbarと同様のアドレス効果を実現できます。
再構成可能なプロセッサはより柔軟性があり、さまざまな構成に従ってHDLコードを生成できます。プロセッサの機能を変更するには、生成されたコードを再構成するだけです。これは、ソフトウェア開発の構成ヘッダーファイルに少し似ています。それ？
5：ESP32 xtensaアーキテクチャのfreeRTOS起動プロセス。wsr.vecbase命令を呼び出してウィンドウオーバーフロー例外エントリを設定する操作に注意してください。
WindowOverFlowの設定については、ESP32の「cpu_hal_set_vecbase」でベースアドレスを設定しています。
6：ESP32例外処理アーキテクチャ：
7：Xtensa ISA Windowsチェックのタイミング。入力コマンドもウィンドウオーバーフロー例外をトリガーすることに注意してください。
8：Xtensa ABI：
もちろん、ウィンドウABIとCall0 ABIを混在させることはできません。ただし、call0を含む安全な手でこするアセンブリを除きます。
9：Xtensaのレジスタウィンドウメカニズムの詳細な分析
githubのcadenceによって管理されているfreeRTOS開発ウェアハウスからxtensaLXシリーズプロセッサーをサポートするコードをダウンロードします。このウェアハウスはcadenceによって提供され、オープンソースです。
git clone https://github.com/foss-xtensa/amazon-freertos.gitウィンドウABIはXtensaアーキテクチャの主要な機能であり、理解するのも最も困難です。call4/ call8 / call12の呼び出しは、呼び出し先関数によって使用されるレジスタに影響します。子関数と親関数の間で、同じレジスタ名は対応しますARM、X86、MIPS、RISCVなどのアーキテクチャでは、さまざまな物理レジスタを想像するのは困難です。これも、Xtensaアーキテクチャの理解に大きな障害をもたらします。
Xtensaのドキュメントを詳細に分析した結果、レジスタウィンドウの概念の学習曲線は非常に急であるものの、主にドキュメントの理解が不十分で多くの詳細が欠落していることが原因であることがわかりました。実際、レジスタウィンドウのコアロジックは変換とウィンドウの発生時プロセッサがカバレッジ中に実行する必要のあるWindowOverflowException処理は、ISAアーキテクチャドキュメントで紹介されていますが、英語の読み方はかなりぎくしゃくしています。関連する章を数回読んだ後、少しずつ感じます。
要約すると、実際、そのレジスタウィンドウはシステムソフトウェアに対して強い仮定を持っています。この仮定は必須です。つまり、すべてのスレッドの呼び出しスタックの最上位です。call4を使用して最初の関数の呼び出しを開始するか、または手作業でコンパイルします。call8例外ハンドラーまたはcall12例外ハンドラーに準拠する呼び出しを手動で作成して、WindowExceptionによってトリガーされるトップレベルロジックに適合させます。このロジックでは、WindowOverflow8 / 12には、図に示すように、スタックポインターを取得するための初期ベース保存領域が必要です。下の図では：
_WindowOverflow8 / _WindowOverflow12は、例外の開始時にスタックからSPを取得する必要があることがわかります。このSPのソースは、call4によって生成された_WindowOverflow4を介して初期化されるか、ウィンドウレジスタメカニズムを確保するためにスタックレイアウトを手動で作成されます。効果的に動作することができます。
分析後、3レベルの関数呼び出しスタックレイアウトは次のとおりです。
同じ理由で、FreeRTOSスレッドが初期スタック充填を作成するとき、スレッドエントリ関数の上位層にコールチェーンがないため、レジスタウィンドウが正常に機能することを保証するために、call4を偽造する必要があります。以下のスクリーンショットに示すように、方法は次のとおりです。
コードは、freertos / kernel / FreeRTOS / portal / XCC / Xtensa / port.cpxPortInitialiseStack関数の実装にあります。
ウィンドウレジスタ（WOE）を開き、PS_UM（ユーザー例外）とcall4のcallincに対応する最も重要なCALLINC（1）を設定することにより、EXCMを1に設定する目的は、rfeが異常に戻ることを保証することです。
スレッドエントリ関数がエントリ命令を実行するとき、ここで設定されたcallincが使用されます。
10：初期化スタックを初期化する必要があるかどうか、およびロジックを初期化する方法について：
初期化する必要がある場合は、以下の手順に従う必要があります。
どのような状況で初期化する必要はありません：
初期化する必要がある場合：
12：call8 / call12スタックによって作成されたロジックを手動で初期化し、次の点に注意してください。
1.青い部分は、立ち上げ初期化プロセスによって手作業でこすられた現在のスタックです。これは、立ち上げアセンブリによって使用されるスタックを表します。これは通常、_startフラグが設定されたプロセスです。
2.このスタックにはローカルオブジェクトがなく、下の茶色の部分の追加の保存領域と紫色の部分の基本の保存領域だけがあります。これはよく理解されています。組み立て段階で製造されたスタックは、スタック自体に格納する必要はありません。
3.実行プロセスでは、firstfunctionによって開始されたコールチェーンが関数呼び出しのレジスタのこのレイヤーをカバーしている場合、ウィンドウはcall8で表されるレジスタウィンドウビューに回転し、WindowOverflow8例外処理を実行します。このプロセスでは、最初にGet the sp-12のアドレスに格納されている最後のスタックフレームのsp（a1）。実際には、このスタックフレームが作成されます。前のスタックフレームがある場合、ここで上位レベルのspを取得する目的は、spのみを渡すことです。さらに、16バイトの安価なスキップおよびベース保存領域（青い部分）を追加して、追加の保存領域の黄色の部分に対処することができます。）
4. WindowOverflow8で、最初の関数のスタックアドレスであるa9を渡し続け、起動スタックのa0〜a3の値を最初の関数のベース保存領域に保存します。
5. call8 / 12のスタックを作成する目的は、windowoverflow4例外がすでに発生している上位層でのcall4呼び出しの存在をシミュレートし、call8のベース保存領域に独自のspを保存することです。 call8レイヤーの場合、保存されたspの値を介して、このレイヤーの追加の保存領域へのアドレスにすることができます。
call8自体のa0-a3は、呼び出し先の基本保存領域に保存されます。
call12の初期化スタックはcall8の初期化スタックと似ており、詳細が異なります。Call12は、パラメーター転送とローカル変数のスペースを考慮します。パラメーター転送の場合、16バイトのスペースがa8-a11用に予約されていることを考慮します。追加の保存領域で、16バイトの整数倍であるLocバイトがスタックローカル変数用のスペースとして予約されます。
このスタックの作成後、スレッドのソースでの最初のc関数呼び出しはcall4なしで実装できます。
Xtensaのスタックレイアウトは破滅的すぎると言わざるを得ません。Xtensaを読んだ後、ARMとRVを振り返ります。ARMとRVの方がはるかにかわいいと感じています。
13：ウィンドウレジスタABIの理解を強化するために、ソフトウェアABIに最も密接に関連する関数であるsetjmpの分析を続けます。
Xtensaの構造体jmp_bufは次のように定義されています。
14：特殊レジスターに対する特殊命令の影響
15：WindowCheckのロジック
16：xt-xccコンパイラはcコードをコンパイルするときにcall8命令しか生成できないようで、call4 / call12はユーザーの手でこするアセンブリによってのみ実現できます。次の実行可能ファイルでcall4 / 8/12の使用頻度を参照してください。ファイル。
call0は独立したABIであり、システムがWindowABIではなくCALL0ABIを選択しない限り、手動でのみこすることができます。
アロカスタック割り当てメモリ命令は「movsp」命令を生成しますが、これは多すぎないようです。
たとえば、次の図のmovsp命令は、allocaがalloc_in_stackで呼び出されるために生成されます。
総括する：
1. Call8は、追加の保管域に16バイト、基本保管域に16バイトを必要とするため、入口のエントリーは少なくとも32バイトです。
2. Call12は、追加の保管域に32バイト、基本保管域に16バイトを必要とするため、入口のエントリーは少なくとも48バイトです。
3. Cコードのコンパイルではデフォルトでcall8命令のみが使用されるため、リーフ以外の関数の場合、エントリはエントリ16であってはなりません。リーフ関数の場合、cコンパイラもエントリ32から始まるようです。スペースを節約するために、Hand-rubアセンブリはエントリ16から始まり、call4で内部的に呼び出すか、関数呼び出しを行わない可能性があります。
4.レジスタウィンドウの動作原理によれば、子関数が呼び出されるとレジスタウィンドウが新しいレジスタビューに回転するため、親関数と子関数、つまり有用なレジスタ間でレジスタの競合が発生しません。親関数のは子関数によって踏まれないので、親関数を保存する必要はありません。同様に、子関数は親関数の実行サイトを踏んで破壊することを恐れる必要はありません。子関数は、コールチェーン内のさらに離れたコールサイトのみを破棄し、WOF例外をトリガーします。
movsp命令のハードウェア実行ロジックは、途中でアロカ例外をトリガーして、現在のスタックのベース保存領域[sp-16、sp]を[as-16、as]の新しい範囲に移動します。これは方法です。怠惰な復元の。
例外処理フロー：
17：xtensaのネイティブxt-xccは、「__ builtin_apply_args」「__ builtin_apply」「__ builtin_return」のいくつかのGNUGCC組み込み拡張機能をサポートしていないようです。ESP32のxtensagccサポートがどれほど優れているかわかりません。
18：ill / ill.n命令は、ソフトウェアでのデバッグに使用される不正な命令例外を無条件にトリガーするために使用されるriscvのunimp命令に似ています。
19：xtensaの割り込みロジックについて：
1.割り込みのLEVEL番号が大きいほど、割り込みの優先度が高くなるため、レベル1、レベル2、レベル3、...の優先度が徐々に高くなります。
2. EXCMLEVELは、デフォルトで比較的大きな数値を設定します。これは、ほとんどの割り込みをマスクできることを意味します。例外が発生した場合、PS.EXCMは1です。次の図に示す式では、プロセッサの例外レベルCINTLEVELは、 PS.EXCMの製品。したがって、ほとんどの割り込みは、例外が発生したときにシールドされます。例外で割り込みをシールドするこの方法は、
MPS、ARM、およびRISCVはすべて同様の実装を持っていますが、これは驚くべきことではありません。
3. PS.UMのさまざまな構成に応じて、例外はKernelExceptionVectorまたはUserExceptionVectorに送られ、UserExceptionは処理前にスタックを切り替えることができ、KernelExceptionはカーネルスタックを直接使用します。
4.割り込み優先度は、NMIが最も高く、DEBUGが2番目です。レベルが小さいほど、優先度は低くなります。DEBUGレベルは、優先度がNMIに次ぐ割り込みです。
5.割り込みレジスタ機能は、汎用プロセッサの割り込み保留レジスタに似ており、現在アクティブで保留中の割り込み要求をマークします。
6.割り込み処理プロセス：
7. Xplorer ISSシミュレーターを使用してFreeRTOSテストケースプロジェクトを実行すると、コンパイルされますが、リンクは常に最後のステップではありません。理由は、FreeRTOSネイティブコードxtensa_vector.Sでの例外処理がcall0を使用するためです。命令、ただしxtensa命令によるコード化されたオフセットフィールドは18ビットのみで、単位はWORDであり、変換のみがサポートされています。
オフセットは1Mバイトで、リンカはcall0の背後にある関数を、リンク時に1M以上離れたアドレスにリンクするため、リンクできません。同様の問題がMIPSにも存在します。
この問題を解決するには、xt-xccのマニュアルに従って、コンパイル時にコンパイルオプションを追加する必要があります。
もともと、xplorerのビルド構成ページから-mlongcallsコンパイルオプションを追加したかったのですが、何度も試しても失敗しました。このツールセットに慣れていないことが原因である可能性があります。後で、次のアセンブリコードを次のように変更しました。下の図に示すように、左側が変更です。後で、call0命令をload命令とcallx命令に変更しました。異なるアーキテクチャでは、ジャンプの後にサフィックス-xを追加して、レジスタを示していることがわかります。ジャンプこれは同じです。たとえば、arm bx、mips jalx、riscvにも、接尾辞xTransfer命令が付いたジャンプがあります。
即値データのビット幅に応じて、コンパイラはmovi命令をl32r命令にコンパイルするかどうかを判断します。
