Path: news.ccsf.jp!norn-news!news.heimat.gr.jp!news.snarked.org!aioe.org!eternal-september.org!feeder.eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail From: YAMAGUTIseisei Newsgroups: tw.bbs.edu.computer-science,japan.test Subject: =?ISO-2022-JP?B?GyRCRUU7UkYsRz5AXzdXP14zNU1XGyhCIDAxODA4MTAyMDAg?= =?ISO-2022-JP?B?GyRCSEcbKEI=?= Followup-To: tw.bbs.comp.sources Date: Sat, 11 Aug 2018 17:03:02 +0000 Organization: X-PlsDntToRmsMatzYktJlgTtiRbistAnd: http://j.mp/2K8Eo4k?#__Sponsor_-_CellBE Lines: 887 Message-ID: <5B6F16C6.9020808@hello.to> References: <54C4B4E9.4080503@hello.to> <54D7DCBA.9080004@hello.to> <54E0B1C1.4000206@hello.to> <54E0B96A.2090205@hello.to> <54E9FF02.8090302@hello.to> <54F326E9.3010908@hello.to> <54FC6769.6090605@hello.to> <550DC230.7030303@hello.to> <5516EBEE.8040901@hello.to> <551A2704.4020109@hello.to> <5529692E.4060609@hello.to> <552D3439.3090107@hello.to> <5534B697.2000800@hello.to> <5545F912.9020803@hello.to> <5550CDAB.8040405@hello.to> <5558C89B.4050103@hello.to> <5561E704.9000208@hello.to> <55645EAA.9040304@hello.to> <55745BE2.5000100@hello.to> <55ACFE56.7040602@hello.to> <55E2830C.9070303@hello.to> <55EBB467.40803@hello.to> <55F4C0BC.5050308@hello.to> <560130D5.4030103@hello.to> <560131AA.9080804@hello.to> <57CC1878.8040106@hello.to> <59B5507B.2050905@hello.to> <5AE59DD3.70407@hello.to> <5AEF6019.9040802@hello.to> <5B549B9B.1090408@hello.to> <5B6E4792.4060600@hello.to> Reply-To: saitou@motoaki Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Injection-Info: reader02.eternal-september.org; posting-host="5bf5ec1369feb549feb97e17ac1d507f"; logging-data="6740"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/7IOzKqplxHtMPznlfgvup" User-Agent: Mozilla/5.0 (BeOS; U; BeOS BePC; en-US; rv:1.8.1.17) Gecko/20080930 Thunderbird/2.0.0.17 ThunderBrowse/3.82 Mnenhy/0.7.6.0 Cancel-Lock: sha1:8dCrpW4retTyNwtNarL9PbC6Nbc= In-Reply-To: <5B6E4792.4060600@hello.to> Xref: news.ccsf.jp japan.test:3347 YAMAGUTIseisei wrote: > PR : シンギュラリティ系有料メールマガジン発行を構想致しております > 無料メールマガジン版 ( 別途有料版開始時打切 ) > http://mailux.com/mm_dsp.php?mm_id=MM53D8AF3589BC7 > > > > Google 翻訳 > > arXiv:1803.06617v1 [cs.AR] 2018年3月18日 http://arxiv.org/abs/1803.06617 > Microsoft Researchテクニカルレポート > 2014年1月に作成。 2018年3月リリース > > 面積の効率的な高ILP EDGEソフトプロセッサの実装に向けて > > ジャングレイ > グレイリサーチLLC > jsgrayATacm.org > > アーロン・スミス > マイクロソフトリサーチ > aaron.smithATmicrosoft。 > >  抽象- In-OrderスカラーRISCアーキテクチャは、20年にわたってFPGAソフトプロセッサ設計の支配的パラダイムとなっています。 > ? ry 順序外スーパスカラ ry 。 > 従来のアウトオブオーダスーパスカラ実装は、競合領域または絶対性能を示さなかった。 > 本稿では、EDGE(Explicit Data Graph Execution)命令セットアーキテクチャを利用して、高速かつエリア効率の優れた順序外のスーパースカラソフトプロセッサを構築する新しい方法について説明します。 > EDGEマイクロアーキテクチャ、特にそのデータフロー命令スケジューラを慎重にマッピングすることにより、アウトオブオーダFPGAアーキテクチャの実現可能性を実証します。 > 2つのスケジューラ設計の選択肢が比較されます。 >  索引用語 - 明示的データグラフ実行(EDGE); ハイブリッドフォンノイマンデータフロー; FPGAソフトプロセッサ > > 1. 前書き > >  設計の生産性は、リコンフィギュラブルコンピューティングの課題として残っています。 > ? ワークロードをゲートに移植し、 ry 。 > 処理内容をゲートに移し、10^2〜10^4秒のビットストリーム再設計の設計反復に耐えるのは高価です。 > ソフトプロセッサアレイオーバーレイは、これらのコストを軽減するのに役立ちます。 > ? 高価な初期ポートは、ソフトプロセッサーを対象 ry 。 > コストがかかる最初の移植は、ソフトプロセッサを対象とした単純なクロスコンパイルとなります。ほとんどのデザインターンは、迅速な再コンパイルです。 > ? ry 、または相互接続 として公開されているカスタムハードウェア ry 。 > アプリケーションのボトルネックは、新しい命令、機能ユニット、自律アクセラレータ、メモリ、または相互接続の公開済機能を持つカスタムハードウェアにオフロードできます。 > ?  異種のFPGA ry 相補的な有用性 ry 。 >  ヘテロジニアス FPGA とハードARMコアの出現は、ソフトコアの相補的有用性を低下させません。 > FPGAの容量が倍増するにつれて、FPGAあたりの潜在的なソフトプロセッサも倍増します。 > ? いくつかのハード・プロセッサーが一致しないスループット ry 。 > 中規模のFPGAは現在、何百ものソフトプロセッサとそのメモリ相互接続ネットワークをホストしています。そのような超並列プロセッサとアクセラレータアレイ(MPPAA)は、サイクルごとに数百のメモリアクセスとブランチ -- 一部のハードプロセッサを越えるスループットを維持できます。 > ?   ry 20年後にはほとんど変わりません。 >  汎用ソフトプロセッサーのマイクロアーキテクチャーは20年間余り変わっていません。 > ? ry インラインパイプライン型スカラーRISC ry 。 > Philip Freidinの16ビットRISC4005(1991)は、j32、xr16、NIOS、MicroBlaze [1] -- [4]のように、インオーダパイプライン型スカラ RISC であり、最新バージョンと同様です。 > 何年もの間、ソフトプロセッサは命令レベルの並列性を高めるためにキャッシュ、分岐予測器、その他の構造を得ていますが、基本的なスカラーRISCマイクロアーキテクチャが依然として支配的です。 > ? ry と1つのライト/サイクルLUT RAM ry 。 > これは、この単純なマイクロアーキテクチャと、それを実装するために必要なFPGAプリミティブ要素、特にLUTとライトパーサイクル LUT RAM との間の良好な適合を反映しています。 > 残念なことに、このようなアーキテクチャでキャッシュミスが発生すると、実行は停止します。 > > ?   ry ソフトプロセッサの代わりにVLIW [5]、[6]またはベクトル[7]、[8]コア。 >  より高い命令レベル並列(ILP)マイクロアーキテクチャをターゲットとする設計研究は、典型的には、アウトオブオーダー(OoO)[9] -- [11]ソフトプロセッサコアの代替としてのVLIW [5]、[6]またはベクトル[7]、[8] アーキテクチャを挙げれます。 > スーパースカラOoOマイクロアーキテクチャの問題は、レジスタの名前を変更し、命令をデータフロー順にスケジューリングし、誤特定した後にクリーンアップし、正確な例外のために結果を順序通りにリタイアさせるために必要な機械の複雑さです。 > ? これは、 ry 多数ポートCAM、 ry 、これらのすべてがFPGAで面積が集中する。 > これにより、深い多ポートレジスタファイル、データフロー命令スケジューリングウェイクアップのための多ポートCAM、および多くのワイドバスマルチプレクサおよびバイパスネットワークなどの高価な回路を必要とし、これらのすべてがFPGAの面積消費を加速する。 > ? ry 、マルチリード、マルチライトRAMは、レプリケーション、 ry 。 > 例えば、マルチリード、マルチライトRAMは、転送形態の混在、マルチサイクル動作、クロックダブリング、バンクインターリーブ、ライブバリューテーブル、その他の高価な技術を必要とします。 > ?  現在の作業は、 >  この度の取組は、複雑さとオーバーヘッドのほとんどを伴わずに、高いILP OoOスーパースカラソフトプロセッサを構築するための新しいアプローチです。 > 我々の洞察は、面積とエネルギー効率の高い高ILP実行のために設計された明示的データグラフ実行(EDGE)[12]、[13]命令セットアーキテクチャを実装することである。 > > 1 > > > ? ry 、順不同のプロセッサーをインライン・スカラーRISCより ry 。 > EDGEアーキテクチャーとそのコンパイラーは、レジスタの名前変更、CAM、複雑さを払拭し、アウトオブオーダプロセッサーをインオーダスカラ RISC よりも数百LUTだけ有効にします。 > ?   ry が、今日のFPGA上で一般的なインオーダRISCとどのように似ているかを解説します。 >  本稿では、EDGE ISAとFPGAに最適化されたEDGEマイクロアーキテクチャと、今日のFPGA上で一般的なインオーダRISCとの共通性を解説します。 > 重要な課題と論文の主な貢献点は、FPGAに小型で高速なデータフロー命令スケジューラを構築する方法です。 > 最小面積のEDGEソフトプロセッサを開発する途中で、2つの代替FPGA実装を開発して対比しています。 > > II. EDGE の概要 > > > z = x + y; > if (z <= 5) { > > x=R0, y=R7 > ヘッダ > I[0] READ R0 T[2R] > I[1] READ R7 T[2L] > I[2] ADD T[3L] > I[3] TLEI #5 B[1P] > I[4] BRO.T B1 > I[5] BRO.F B1 > > ↓ > > x += 1; > y -= 1; > x /= y; > > ヘッダ > I[0] READ R0 T[2L] > I[1] READ R7 T[3L] > I[2] ADD #1 T[4L] > I[3] SUB #1 T[4R] > I[4] DIV W[R0] > I[5] BRO > > } > > インストラクションウィンドウ > > ? オペラ・バッファ BP 0 1 > オペランド・バッファ BP 0 1 > READ R0 > 2R > READ R7 > 2L > ADD > 3L > TLEI #5 > > BRO.T > > BRO.F > > > 図1: 擬似コードおよび対応する命令ブロック。 > > >7b 2b 2b 3b 9b 9b > OPCODE PR BID XOP TARGET1 TARGET0 > > PR= PREDICATE > BID= BROADCAST ID > XOP= EXTENDED OPCODE > > > 図2: 一般的な命令フォーマット > > >  EDGEアーキテクチャ[12]、[14] -- [16]は、アトミックにフェッチ、実行、およびコミットされる命令ブロック内で編成された命令を実行する。 > ブロック内の命令はデータフローの順番で実行されるため、高価なレジスタの名前変更の必要性がなくなり、効率的なアウトオブオーダー実行が可能になります。 > ? ry 明示的に符号化し、、マイクロアーキテクチャが実行時にこれらの依存性を再発見するのを解放する。 > コンパイラは、命令セット・アーキテクチャを通じてデータ依存性を明示的にエンコードし、これらの依存性の実行時再探索からマイクロアーキテクチャを解放する。 > ? ry 直接データ依存です。 > 述語を使用すると、ブロック内のすべてのブランチはデータフロー命令に変換され、メモリ以外のすべての依存関係は直接データ依存となる。 > このターゲット・フォーム・エンコーディングは、ブロック内の命令がオペランド・バッファを介して直接オペランドを通信することを可能にし、電力を必要とするマルチポート物理レジスタ・ファイルへのアクセス回数を減らします。 > ブロック間では、命令はメモリとレジスタを使用して通信します。 > ? ry インオーダーの電力効率と複雑さを備えたアウトオブオーダー実行のメリットを享受します。 > EDGEアーキテクチャは、ハイブリッドデータフロー実行モデルを利用することにより、命令型プログラミング言語とシーケンシャルメモリセマンティクスをサポートしますが、インオーダーのものに近い電力効率と複雑さを備えつつアウトオブオーダー実行のメリットを享受します。 >  図1は、2つのEDGE命令ブロックの例と、命令がそのターゲットを明示的にエンコードする方法を示しています。 > この例では、各ブロックは基本ブロックに対応する。 > 最初の2つのREAD命令は、ADD命令の左オペランド(T [2L])と右(T [2R])オペランドを対象としています。 > READは、グローバル・レジスタ・ファイルから読み取る唯一の命令です(しかし、どの命令もターゲットにすることができます。 例 グローバルレジスタファイルへの書き込み)。 > ADDが両方のレジスタ読み出しの結果を受け取ると、それは準備完了となり、実行されます。 >  図2に一般的な命令フォーマットを示します。 > 各EDGE命令は32ビットで、最大2つのターゲット命令のエンコードをサポートしています。 > ? ry 消費者の指示については、コンパイラは移動命令を使用して ry 高いファンアウト命令を割り当てることができます[15]。 > ターゲットフィールドより多くのコンシューマを伴う命令については、コンパイラは move 命令を使用してファンアウトツリーを構築するか、ブロードキャストに高ファンアウトな命令を割り当てることができます[15]。 > ブロードキャストは、軽量ネットワーク上のオペランドをブロック内の任意の数のコンシューマ命令に送信することをサポートします。 > ? ry 、TLEI命令(テスト無しイミディエイト命令) ry 。 > 図1では、TLEI命令(Less / Equal イミディエイトテスト命令)がADDから単一の入力オペランドを受け取ると、それは準備完了となり、実行されます。 > ? ry 生成されます。 > このテストでは、チャネル1(B [1P])からブロードキャストチャネルでリッスンするすべての命令(この例では2つの分岐予測命令(BRO.TおよびBRO.F))にブロードキャストされる述語オペランドがプロデュースされます。 > 一致する述部を受け取ったブランチは起動します。 > > ?  EDGE実装のスペクトルは、 >   EDGE スペクトル実装は、さまざまな面積と性能のトレードオフで可能です。 > ? 以前のEDGEの研究では、スカラーワークロードのパフォーマンスを向上させるために、非常に幅広い問題実装[12]、[13]、複数のコアの融合[14]〜[16] > 以前のEDGEの研究では、スカラ処理パフォーマンス向上の為に、超ワイドなイシューの実装[12]、[13]、複数のコアの融合[14]〜[16] 、を用いました。 > ? この作業では、 > この度の取組では、競争力のあるパフォーマンス/面積のコンパクトEDGEソフトプロセッサを使用したMPPAAシナリオに焦点を当てます。 > したがって、データとポインタは32ビットです。ブロックは最大32命令までです。 マイクロアーキテクチャはクロックごとに1-2命令をデコードし、1命令を発行します。 > ? 、分岐またはメモリ依存の予測を省略します。 > 本研究では、ロードストアキュー(LSQ)をシンプルで非投機的な設計に制限し、分岐又はメモリに依存する予測を省略します。 > > III. FPGAでのEDGE > > IF > INSN キャッシュデータ > nK x 32 x 2 ポート > ブロック RAM > > DC > デコーダー(S) > > IS > インストラクションウィンドウ > INSN スケジューラ > 32 ENTRIES > > T1 T0 IID > > デコードされた INSNS > 32 x n LUT-RAM(S) > > ? オペラのバッファ オペランドバッファ > 32 x 32 LUT-RAMS > > EX > EX パイプラインの REGS > > EX > TS > > OPS0 > 32x32 > > × > > LS > ロード/ストア > キュー > > データキャッシュデータ > nK x 32 > ブロック RAM > > LS PIPELINE REGS > > ×2 > > REGISTER FILE > 32 x 32 LUT-RAM > > > ? ry 2つのデコード、シングル発行の ry 。 > 図3: 2 デコード、シングルイシューのEDGEマイクロアーキテクチャ。 > > A. マイクロアーキテクチャ >  図3は、コンパクトEDGEプロセッサのマイクロアーキテクチャの例です。 > ? ry 、およびメモリ/データキャッシュアクセスを含む命令およびデータキャッシュおよび5段階パイプライン(従来のインオーダスカラーRISC) LS)。 > これは、命令フェッチ(IF)、デコード(DC)、オペランドフェッチ、実行(EX)、およびメモリ/データキャッシュアクセス ( LS ) を含む I/D キャッシュおよび5段階パイプラインを持つほぼ従来型のインオーダスカラ RISC です。 > ? ry 読み出されます。 > インオーダ・プロセッサとは異なり、命令オペランドはレジスタ・ファイルではなくオペランド・バッファから読出され、 > ? ry データフローの > 又データフローの順序で次に実行する命令は、IS(発行)パイプラインステージによって決定されます。 > これは、データフロー命令スケジューラと、デコードされた命令バッファと、オペランドバッファとを含む命令ウィンドウを使用する。 > ? 単純な ry プログラム命令 ry 。 > その際に単純なロードストアキューを使用してプログラムされた順の通りのメモリ命令群を発行します。 >  フロントエンド(IF、DC)はバックエンド(IS、EX、LS)から切り離されています。 > クロックごとに2つの命令をフェッチし、命令ウィンドウにデコードします。 > 命令ウィンドウのデータフロースケジューラは、各デコードされた命令の入力すなわち > ? その述語とオペランド。 > その述語とオペランドのレディステートを保持します。 > ? 準備完了状態になると、 ry 。 > すべての入力(ある場合)がレディ状態になると、命令は起動し、発行準備が整います。 > 最も低い番号のレディ命令IIDが各サイクルで選択され、そのデコードされた命令および入力オペランドが読み取られる。 > データマルチプレクサとファンクションユニット制御信号のほかに、この命令は最大2つのレディイベントをエンコードします。 > ? ry および/またはイベント ry 準備状態を更新する。 > スケジューラは、これらの and/or イベントを他のソース(T0およびT1に多重化)から受け取り、ウィンドウ内の他の命令のレディ状態をアップデートする。 > このようにして、データフローの実行が開始され、ブロックのレディ0入力命令、次にこれらがターゲットとする命令などが開始されます。 > > B. EDGEデータフロー命令のスケジューリング要件 > ?   ry、コアの鎹です。 >  命令ウィンドウとスケジューラは、コアのリンチピンです。 > それらの領域、クロック周期、能力、および制限によって、EDGEコアの実現性能とEDGEマルチプロセッサのスループットが大きく左右されます。 > > 2 > > >  命令スケジューラは、多様な機能と要件を備えています。 > ? ry 同時です。 > それは非常に同時並行的です。 > ? ry 、デコーダは、命令をデコードし、デコードされた ry 。 > 各サイクルにおいて、デコーダは、デコードされたレディ状態及びデコードされた命令をウィンドウに書き込む。 > ? ry バックエンドは準備完了イベント ry 。 > 各サイクルで、スケジューラは発行する次の命令を選択し、それに応答してバックエンドはレディイベント -- > 特定の命令の入力スロット(述語、オペランド#0、オペランド#1)をターゲットとするターゲットレディイベント、またはブロードキャストIDで待機しているすべての命令をターゲットとしたブロードキャストレディイベントのいずれかを送信します。 > これらは命令毎のアクティブレディ状態ビットをセットし、デコード済みレディ状態と共に命令が発行可能であることを知らせる。 > ? ry を受け付け、発行されたレディ命令の再発行を禁止する必要があることに注意してください。 > スケジューラは、まだデコードされていないターゲット命令のイベントを受付けるので、発行されたレディ命令の再発行を禁止する必要があることに注意してください。 > ?   ry 、または述語の真または偽である可能性 ry 。 >  EDGE命令は、述語ではないか、又は true か false という述語である可能性があります。 > ? ry 、別の命令の述語結果によって ry 。 > 述語化された命令は、別の命令の述語評価結果によってターゲットにされ、その結果が述語条件と一致するまで、準備ができません。 > ? ry 発行しません。 > 述語が一致しない場合、命令は決して発行されません。 > >  新しいブロックへの分岐では、すべての命令ウインドウレディ状態がフラッシュクリアされる(ブロックリセット)。 > しかし、ブロックがそれ自身に分岐すると(ブロックリフレッシュ)、アクティブレディ状態のみがクリアされ、 > デコードされたレディ状態は保存されるので、ブロックの命令を再フェッチしてデコードする必要はない。 > リフレッシュは、ループの時間とエネルギーを節約するための鍵です。 >  ソフトウェアクリティカルパスの一部は、依存する命令の1つのチェーン ( 例 > ? ry 、連続するバックツーバック命令ウェイクアップのためにパイプラインバブルを追加しないことが重要です。 > A → B → C と順にターゲット ) で構成されており、データフロースケジューラは、連続するバックツーバック命令の起動の為のパイプラインバブルを追加しない点は重要です。 > ? ry レディ・イグジット・ターゲット・レディ・パイプラインの再発行は、クロック・サイクルに深刻 ry > したがって、ISステージのレディ・イシュー・ターゲット・レディ・パイプラインの再発行は、クロック周波数に深刻な影響を与えないと仮定すると、1サイクルで完了するはずです。 >  ADDのような命令は、1サイクルの待ち時間を有する。 > ? ry 、スケジューラはターゲットステージの命令をISステージでウェイクさせることができます。 > EXステージの結果転送では、命令が完了する前であっても、スケジューラはISステージでターゲットがターゲットする命令を起動させることができます。 > 他の命令の結果は、ALUの比較を待つか、複数のサイクルを取るか、または未知の待ち時間を有する可能性がある。 > ? これらは後で目標を起こすまで待たなければなりません。 > これらの場合はターゲットを後で起動する様にウェイトせねばなりません。 > ?   ry 、予想されるEDGE実装のスペクトルにわたってスケーラブルでなければなりません。各サイクルは、少なくとも1〜4のデコードされた命令と2〜4つのターゲットレディイベントを受け入れ、1サイクルあたり1〜2の命令を発行します。 >  最後に、スケジューラ設計は、予想されるEDGEのスペクトル実装にわたってスケーラブル -- 各サイクルは、少なくとも1〜4のデコードされた命令と2〜4つのターゲットレディイベントを受入れ、1サイクルあたり1〜2の命令を発行します -- でなければなりません。 >  2つの代替的なデータフロー命令スケジューラ設計を考える: > ? ry 、各命令のレディステータスが各サイクルで再評価されます。 > FPGAのDフリップフロップ(FF)で命令のレディ状態が明示的に表現されているブルートフォース並列スケジューラでは、各命令のレディステータスが各サイクルで再評価されます。 > ? よりコンパクトなインクリメンタルスケジューラで、 ry 。 > そしてよりコンパクトなインクリメンタルスケジューラでは、LUT RAMにレディ状態を保持し、1サイクルあたり2〜4ターゲット命令のみのレディステータスを更新します。 > > C. 並列命令スケジューラ > > > BID > T1 > T0 > ENs > > 31 > ... > 3 > DBID DRT DRF DR0 DR1 > > NEXT RDYS > RDY RT RF R0 R1 INH > > 2 > 1 > 0 > > DEC.RDYS > リセット > RESETv? リフレッシュ > > 32→(5,1) > ? 優先エンコーダ 優先度エンコーダ > > IID,V > > > 図4: エントリ#2をより詳細に示す、並列データフロースケジューラのブロック図。 > >  図4は、図3の命令ウィンドウのための並列命令スケジューラを示す。 > ? アクティブ準備完了状態は、ターゲット準備完了イベントT0、T1および ry )によって設定され、 ry 。 > アクティブレディステートは、ターゲットレディイベントT0、T1及びブロードキャストID BID(存在する場合)によってセットされ、さまざまな入力タイプによって修飾されてENをイネーブルにすることに注意してください。 > ? ry 、1命令準備回路のインスタンス ry 。 > 32エントリウィンドウの場合、1命令分の回路のインスタンスが32個あります。 > どのサイクルにおいても、32個のRDY信号のうちの1つ以上がアサートされてもよい。 > ? ry 、これを発行する次の命令の5ビットIIDに縮小する。 > 32ビット優先度エンコーダは、これを次の発行される命令の5ビットIIDに縮小する。 >  各エントリに対して、復号されたレディ状態の6ビットがあり、 > ? すなわち、それらは命令デコーダによって初期化される。 > それらは、例えば次の様に命令デコーダによって初期化される : > > . DBID: 2ビットのバイナリブロードキャストID。存在しない場合は00 > ? . ry が準備完了です。 > ? . DRT, DRF: decoder:述語true(false)がレディ状態です。 > . DR0, DR1: デコーダ:オペランド#0(オペランド#1)がレディ状態 > > ? ry 符号化し、恐らくブロードキャストチャネルを介して述語および/またはいくつかのオペランドを待つか、 ry 。 > これらのビットはともに、命令がデコードされたかどうかを符号化し、述語および/またはいくつかのオペランドを恐らくブロードキャストチャネルを介して待つか、またはすぐに発行する準備ができているかどうかをエンコードする。 > これらのビットは、ブロック・リセット時にのみクリアされます。 >  アクティブ・レディ状態の6ビットもあります: > > ? . ryが準備完了です。 > . RT, RF: 述語true(false)がレディです。 > . R0, R1: オペランド#0(オペランド#1)がレディ状態 > ? . ry 命令を禁止する - 既に発行済み > . INH: 禁止指令 - 既にイシュー済 > . RDY: 命令は発行可能です > > 3 > > > ? 命令は、if(RT&RF&R0&R1&〜INH)の準備ができています。 > 命令は、(RT&RF&R0&R1& ‾INH)の場合にのみレディです。 > Any of RT, RF, R0, R1 may be set when: > ? ry 、RT、RF、R0、R1のいずれかを設定 ry 。 > 以下の場合、 RT、RF、R0、R1 をどれでも設定することができます。 > > . 対応するDRXがデコーダによって設定されるか、または > . 実行命令は、明示的に、またはブロードキャストイベント(ブロードキャストID、入力)を介して入力をターゲットにします。 > > アクティブ・レディ状態ビットは、ブロック・リセットまたはリフレッシュ時にクリアされます。 > > > デコード済みレディ状態 アクティブレディ状態 > 命令 DBID DRT DRF DR0 DR1 RT RF R0 R1 INH RDY > READ 00 1 1 1 1 1 1 1 1 1 0 > READ 00 1 1 1 1 1 1 1 1 0 1 > ADD 00 1 1 0 0 1 1 1 0 0 0 > TLEI 00 1 1 0 1 1 1 0 1 0 0 > BRO.T B1 01 0 1 1 1 0 1 1 1 0 0 > BRO.F B1 01 1 0 1 1 1 0 1 1 0 0 > デコードされていない 00 0 0 x x 0 0 x x x 0 > > ? 表I:命令インストラクション・レディ状態 > 表I:命令スケジューラのレディ状態の例 > > >  表Iは、6つの命令をデコードして最初の命令を発行した後のブロックの命令スケジューラ状態を示す。 > ? ry 特定の述語結果を待たないことを反映するDRTおよびDRFセットを有する。 > 最初の4つの非述語命令は、それらが特定の述語評価結果を待たないことを反映するDRTおよびDRFセットを有する。 > ? ry )はすぐに発行する準備ができています。 > 2つのREAD命令(予測されず、入力オペランドがゼロ)は即時イシューの準備ができています。 > ? 最初のものが発行されました - そして現在は再発行が禁止されています - R0が設定されているADDのオペランド0を対象とします。 > 最初のものがイシューされて -- そして現在は再発行が禁止されている -- ADD 命令のオペランド0が対象とされている時、その R0 が設定されます。 > 2番目のREADは、次のISパイプラインサイクルで発行されます。 > ? ry 述語結果をブロードキャストします。 > TLEI(test-lessthan-or-equal-immediate)命令は、チャネル1でその述語評価結果をブロードキャストします : > ? 2つの分岐命令、 > 2つの分岐命令に付いて、 > 述語部が夫々 true か false か > ? 、この述語の結果を待つ。 > 、この述語の結果を待って。 > ? ry デコードされていない: ry 。 > 第7のエントリはデコードされていない命令:(DRT | DRF)= 0。 > ?  ry デコードされた命令バッファに ry 。 >  データフロースケジューリングのクリティカルパスを減らすために、フロントエンドはデコードされた命令用のバッファにプリデコードされたEDGE命令を書き込む。 > 命令IIDが発行されると、そのデコードされた命令がバックエンドによって読み取られる。 > ? とりわけ、命令の0-2(IID、入力)明示的ターゲットを指定する2つのターゲットオペランド準備完了イベントフィールド_T0および_T1、ならびに入力イネーブルの4ビットベクトルを含む:ENs = {RT EN 、RF EN、R0 EN、R1 EN}である。 > とりわけ、0-2(IID、入力)で命令のターゲットを明示指定する 2 つのターゲットオペランドレディイベントフィールド_T0および_T1を含む、謂うなれば 4 ビットベクトルとしての入力は以下に示すイネーブル効果を持つ:ENs = {RT EN 、RF EN、R0 EN、R1 EN} > ? 図3を参照すると、これらの信号は、他のパイプラインステージからのレディイベントとスケジューラによって入力されたT0およびT1とに多重化される。 > 図3 に遡るが、これらの信号、他のパイプラインステージからのレディイベントは、スケジューラによって入力されたT0およびT1とに mux される。 > > D. 並列スケジューラのFPGA実装 >  スケジューラの面積とクロック周期を最小限にするには、FPGA回路設計に注意を払う必要があります。 > ? 32命令ウィンドウは、準備完了状態のために32 *(6 + 6)= 384FFを、準備完了イベントを復号して各入力の準備完了状態を更新するために32 *多くのLUTを必要とする。 > 32 個ある命令ウィンドウは、それらのレディステートの為に 32 *(6 + 6)= 384FF を、レディイベントを復号して各入力のレディステートを更新するために32 *多くのLUTを必要とする。 > ?  最新のFPGAは、 ry 。 >  現代的 FPGA は、一連のLUT(ルックアップテーブル)とDフリップフロップ(FF)をロジッククラスタにまとめています。 > ? ry 各スライスのクラスタに ry 。 > たとえば、ザイリンクス7シリーズデバイスは、4つの6-LUTと8つのFFを各 `` スライス ''クラスタにグループ化します。 > 各LUTは2つの出力を持ち、1つの6-LUT、または5つの共通入力を持つ2つの5-LUTとして使用できます。 > ? ry 登録することができます。 > 各出力はFFに登録されるかも知れません。 > フリップフロップにはオプションのCE(クロックイネーブル)とSR(セット/リセット)入力がありますが、これらの信号はクラスタ内の8つのFFすべてに共通です。 > この基本的なクラスタ・アーキテクチャは、アルテラのFPGAに似ています。 >  これから、2つの設計上の考慮事項があります。 > ?  Fracturable 6-LUTデコーダ: ry 。 >  分割可能な 6-LUTデコーダ:ターゲット命令インデックスのデコードでは、インデックスが≦5ビットである限り、2つのデコーダが1つの6-LUTに収まる可能性があります。 >  スライスFFパッキングとクラスタ制御セットの制限:領域と配線の遅延を最小限に抑えるため、デザインはクラスタごとに4〜8 FFの高密度FFをパックします。 > すべての6ビットデコード済みレディ状態エントリは一緒に書き込まれ(共通RSTおよびCE)、1つまたは2つのスライスにパックすることができます。 >  アクティブレディ状態のFFにはもっと注意が必要です。 > ? これらの32ラ6 ry 。 > これらの32*6 = 192個のFFの各々は個別に設定することができるが、スライス当たり4つのFFをパックすることにより、1つのFFがクロックイネーブルされると、全てがクロックイネーブルされる。 > 準備完了イベントによってFFが設定されると、そのスライス内の他のFFは変更されるべきではありません。 > これには、各FFの入力LUTにCE機能を実装し、その出力をその入力にフィードバックする必要があります。FF_NXT = FF |(EN&入力)。 > > > generate for (i = 0; i < N; i = i + 1) begin: R > always @* begin > // ターゲット・デコーダ > T00[i] = T0 == i; > T01[i] = T0 == (i|N); > T10[i] = T1 == i; > T11[i] = T1 == (i|N); > B[i] = BID == DBID[i]; > > // 次のアクティブレディ状態ロジック > RT_NXT[i] = RT[i] | DRT[i] > | (RT_EN & (T01[i]|T11[i]|B[i])); > RF_NXT[i] = RF[i] | DRF[i] > | (RF_EN & (T00[i]|T10[i]|B[i])); > R0_NXT[i] = R0[i] | DR0[i] > | (R0_EN & (T00[i]|T10[i]|B[i])); > R1_NXT[i] = R1[i] | DR1[i] > | (R1_EN & (T01[i]|T11[i]|B[i])); > INH_NXT[i] = INH[i] | (INH_EN & (IID == i)); > RDY_NXT[i] = RT_NXT[i] & RF_NXT[i] & R0_NXT[i] > & R1_NXT[i] & ‾INH_NXT[i]; > end > end endgenerate > > リスト1:並列スケジューラー `` next readys ''ロジック > > >  リスト1は、N-entry並列スケジューラー用の `` next readys ''を生成するVerilogです。 > 4つのレディ・イベント入力タイプ(述部真、偽、オペランド#0、オペランド#1)がありますが、 > ? ry 、真/オペランド#1ターゲットから偽/オペランド#0ターゲットを区別するのに単一のターゲットインデックスビットで十分である。 > 述部ターゲットイベントがオペランドターゲットイベントと同じサイクルで発生しないことを保証することによって、真/オペランド#1ターゲットと偽/オペランド#0ターゲットを区別する為のターゲットインデックスビットは一つで済む。 > ? N = 32エントリの命令ウィンドウの場合、T0とT1は6ビット{入力#1:0}である(すなわち、特定の{RT / RF / R0 / R1} . > ? IID:5}。 > (特定の{RT / RF / R0 / R1} EN がイネーブル化する事によってデコーディング促進が齎される ) > すなわち、 N = 32エントリの命令ウィンドウの場合、T0とT1は6ビット{入力#1: IID:5}である。 > ? ry (ターゲット0の入力0等)は、ブロードキャスト選択デコーダB ry 。 > ターゲットデコーダT00、T01、T10、T11(ターゲット0の入力0 、等)は、放送選択デコーダBと同様に、それぞれ6-LUTである。 > ? ry 、現在アクティブでデコードされたレディステートでターゲットデコーダ出力を一緒にフォールドします。 > 次のアクティブレディ状態ロジックは、現在アクティブかデコードされたレディステートでターゲットデコーダ出力を一緒に畳みます。 > これにはさらに7つのLUT(INH_NXTでは2つ)が必要で、合計32 * 12 = 384のLUTが必要です。 >  これは、32エントリスケジューラを偶数および奇数命令の2つの16エントリバンクに分割することによって改善することができる。 > ? ある銀行内では、4ビットの銀行IIDで十分である。 > 1 つのバンクに付き、4ビットのバンク IID で十分である。 > ? ry 、T5、T10、T11は2つの5,5-LUT、 ry 。 > 次に、T0、T1は5ビットに狭くなるので、T00、T01、T10、T11は2つの5,5-LUT、INH_NXTは1つの6-LUT、または2 * 16 *(3 + 6)= 288のLUTに収まります。 > > 4 > > > ?  シェービングLUTに加えて、 ry 。 >  シェービング ( サイズを削落とす ) LUTに加えて、2バンクスケジューラは2組のT0、T1ポートを提供し、各サイクルで2組の2つのイベントをシンクすることができます。 > ? ry より広い発行率を維持するために不可欠である。 > これは、1サイクルにつき2命令(サイクル当たり4つのオペランドを対象とする)のより幅広なイシューレートを維持するために不可欠である。 > ? さらに広い問題点とそれ以上 ry メリットがあります。 > さらに幅広なイシューとそれ以上の命令ウィンドウでは、4バンク設計のメリットが活きます。 >   ready-issue-target-ready スケジューリングの繰り返しは、ISステージのクリティカルパスです。 > 32→5プライオリティエンコーダは、RDYベクトルをIIDに縮小し、デコードされた命令を選択する。 > ? ry 多重化される。 > デコードされた命令のフィールド{T0、T1、BID、EN}は、RDYを含むターゲット命令のレディ状態を更新する{T0、T1、BID、ENs}に mux される。 > ?   ry :LUTまたはキャリーロジックまたはツリー、キャリーロジックゼロスキャン、および ry ワンショット変換を含む、多くの32ビットエンコーダデザインが評価されました。 >  優先順位エンコーダ:LUTまたはキャリーロジックの OR ツリー、キャリーロジックのゼロスキャン、およびF7MAP / F8MAPマルチプレクサを使用したワンホット変換を含む、多くの32ビットエンコーダデザインが評価検討されました。 > ? ry 、2つのLUT遅延で完了する。 > 現在の設計では、バンク当たり2つの16→4エンコーダを使用し、2つの LUT の遅延で完了する。 > ワン・イシュー・プロセッサでは、後続の2:1マルチプレクサがこれらのエンコーダ出力の1つを選択します。 >  特に、各16ビットエンコーダ入力I [15:0]はI [15]、I [14:10]、I [9:5]、I [4:0]にチャンクされる。 > ? 各5ビットグループは32x4 LUT ROMにインデックスを付け、そのグループのエンコーダ出力を事前計算します。 > 各5ビットグループはそのグループのエンコーダ出力を事前計算してある 32x4 LUT ROM をインデックスします。 > ? 3つの5ビットゼロコンパレータ出力とともに、 ry 。 > 5ビットゼロコンパレータ出力 3 つは共に、3つのグループがすべてゼロのときに 'b1111'を出力するカスタム4ビット3:1セレクタに供給されます。 > ?   ry RPM(Relativeally配置されたマクロ) ry 。 >  技術マッピングとフロアプランニング: このデザインではRPM(関連配置マクロ)手法を使用してエリアと相互接続の遅延を改善し、モジュール構成と大規模な複製で簡単なルーティングとタイミングクロージャのための繰り返し可能なレイアウトを実現します。 > 構造RTLはモジュールをインスタンス化し、それらをスケジューラにタイルします。 > 6入力モジュール上のXST注釈(* LUT MAP = "yes" *)は、そのロジックを1つのLUTにロックします。(* RLOC = "XxYy" *)は、FPGAプリミティブをクラスタにパックし、相互に相対的にクラスタを配置します。 > > > 図5: 並列スケジューラのFPGA実装 > > ?   ry 、およびデコードされた命令バッファ ry 。 >  図5は、スケジューラ、プライオリティエンコーダ、およびデコード済命令用バッファを含む図4のザイリンクス7シリーズの実装であり、クリティカルパスが白で強調表示されています。 >  FPGAスライスの2つの水平な行はそれぞれ、命令ウィンドウの4つのエントリに対応します。 > 左から右へ: > > ? . 淡黄色:4つの6ビットデコード済み状態フリップフロップ。 > . 淡黄色:4つの6ビットデコード済レディ状態フリップフロップ。 > . 黄/緑:B、T00、T01、T10、T11ターゲット・デコーダ; > . オレンジ:アクティブレディ状態のLUT / FF RT_NXT / RTなど。 > . 紫色:INH_NXTおよびINH。 > . 赤:RDY_NXTとRDY。 > > ? 右側には、複数の32x6ビットトゥルーデュアルポートLUT RAMに実装された、合成された優先エンコーダとマルチプレクサ(青)とデコードされた命令バッファ(白) ry 。 > 右側には、合成された優先度エンコーダとマルチプレクサ(青)と、複数の 32 x 6 ビットトゥルーデュアルポート LUT RAM に実装されたデコード命令用バッファ(白)があります。 > ?   ry デコード済命令LUT RAM、 ry 。 >  パフォーマンス:Kintex-7 -1スピードグレードでは、クリティカルパスにRDYクロックトゥーアウト、プライオリティエンコーダ、マルチプレクサ、デコードされた命令LUT RAM、次のreadysロジック、RDYセットアップを含む5.0 nsが必要です。 > 相互接続遅延はクリティカルパスの85%です。残念ながら、RDYからRDYまでのすべてのパスは、比較的大きな直径のネットリストを通過する必要があります。 > ?   ry バックツーバック問題(連続サイクルで) ry 。 > スケジューラクリティカルパス(命令バッファLUT RAMの出力ポート)の途中でパイプラインレジスタを追加することにより、サイクルタイムを2.9nsに短縮することができますが、これは、単一の従属命令チェーンのバックツーバックイシュー(連続サイクルで)を達成することはできません。 > > ? ry 準備完了状態 > E. 増分データフロースケジューラレディー状態 >  並列スケジューラは簡単ですが、32x12bのレディステート(LUT RAMの数少ないLUT)を維持するために何百ものLUTとFFを消費し、命令ウィンドウのサイズが2倍になるとこの領域も2倍になります。 > ? また、発行された各命令が多くても2つの他の準備完了状態に影響を与えても(ブロードキャストにもかかわらず)、各命令の次のreadys LUTの各サイクルはすべての命令の準備を再計算します。 > 又、発行された各命令が大抵 2 つの他のレディー状態に影響を与えても(ブロードキャストにもかかわらず)、LUT での各レディーは次の各サイクルで全ての命令のレディーステートを再計算させます。 ? > ? ry 、キュー内のレディ命令のフロンティアを維持し、 ry 。 > 対照的に、インクリメンタルスケジューラは、LUT RAMでデコードされたアクティブレディ状態を保持し、キュー内のレディ命令のフロンティアを整備し、1サイクルあたりわずか2〜4ターゲット命令のレディステータスを評価します。 > > 5 > > > FFの配列と比較して、LUT RAMは高速で高密度ですが、いくつかの欠点があります。フラッシュする方法がなく、1サイクルあたり1つの書き込みしかサポートしていません。 > > DRDYSS > WA ← DC_IID > RA ← EVT_IID > I ← DC_DRDYS > O → READY LOGIC DRDYS > > ARDYSS > WA ← EVT_IID > RA ← EVT_IID > I ← READYLOGIC ARDYS_NXT > O → READYLOGIC DRDYS > > DVS ← RESET > O → READYLOGIC DV > WA ← DRDYSS WA > RA ← DRDYSS RA > > AVS ← RESET?vREFRESH > WA ← ARDYSS WA > RA ← ARDYSS RA > O → READYLOGIC AV > > READY LOGIC > READY → > DV ← DVS O > DRDYS ← DRDYSS O > AV ← AVS O > ARDYS → ARDYSS O > ARDYS_NXT → ARDYSS I > EVT_RDYS ← EVT_RDYS > > ? ry :準備状態、検証、および準備論理。 > (a)設計:レディー状態、検証、およびレディーロジック。 > > > > (b)FPGAの実装。 > > 図6: 16エントリスケジューラバンク。 > > > > ?   ry とFFの `` RAM ''の ry 。 >  代わりに、スケジューラはLUT RAMとFF `` RAM '' のハイブリッドを使用します。 > ? ry 16x4真のデュアルポートLUT RAMのいくつかのバンクに格納され、16x1フラッシュクリア可能セット - 「FC-SO-RAM」 > デコードされた(DRT、DRF、DR0、DR1)およびアクティブ(RT、RF、R0、R1)レディ状態は16x4の真のデュアルポート LUT RAM を構成する「 FC-SO-RAM 」に批准する 16 x 1 フラッシュクリア可能セットオンリー RAM であるいくつかのバンクに格納される。 > ? これには、16個 ry )すべて。 > これは、16個のFF(共通リセット付き)、16個のライトポートアドレスデコーダ(8個の5,5-LUT)、16:1のリードポートマルチプレクサ(4個の6-LUT、2個のMUXF7、1個のMUXF8)の全 3 つのスライスで構成されています。 > このハイブリッドからの各読み出しは、4b LUT RAMエントリおよびその有効ビットを読み取る。 > 各書き込みはLUT RAMを更新し、その有効ビットをセットする。 > >  複数のLUT RAM書込みポート。 > d命令/サイクルのフェッチ/デコード速度およびi命令/サイクルの発行速度を維持するためには、各サイクルでd + 2iレディ状態エントリを更新する必要がある。 > これは1つのライト/サイクルLUT RAMの課題です。 > ? ry なく、4つ(またはそれ以上)のインタリーブされたディスジョイントバンクにレディ状態を分割します。 (偶数、奇数)命令の(デコードされた、アクティブな)準備完了状態を示す。 > 増分スケジューラは、クロックダブリングまたは複製されたRAMバンクをライブ値テーブルで使用するのではなく、レディ状態を 4つ(またはそれ以上)のインタリーブされたディスジョイントバンクに分割します : (偶数、奇数)命令の(デコードされた、アクティブな)レディステートを示す。 > > その後、フロントエンドは、偶数および奇数のデコード済みレディ状態を書き込むことができ、バックエンドは、偶数および/または奇数ターゲット命令のアクティブレディ状態を更新する。 > その後、バックエンドが偶数および/または奇数ターゲット命令のアクティブレディ状態を更新する状態である限りは、フロントエンドは偶数および奇数のデコード済みレディ状態を書き込むことができる。 > > > // ? 準備完了のロジック レディーロジック > always @* begin > ARDYS_NXT = (DV ? DRDYS : 4'b0000) > | (AV ? ARDYS : 4'b0000) > | EVT_RDYS; > READY = &ADRYS_NXT; > end > > ? ry :準備完了ロジック > リスト2:レディーロジック > > >  図6は、結果として16エントリスケジューラバンクの設計と実装を示しています。 > ? 青でデコードされ ry 。 > 青のデコードされアクティブな状態のLUT RAM DRDYSSおよびARDYSSは、オレンジ/赤のFC-SO-RAM DVSおよびAVSによって検証されます。 > 各サイクルにおいて、デコーダは、命令DC IIDのデコード済みレディ状態DC DRDYSおよびその有効ビットを書き込む。 > ? また、各サイクルで銀行の目標準備完了EVT :: = {EVT_IID; EVT_RDYS}は、そのDRDYSおよびEVT_RDYSを使用してEVT_IIDのARDYSの読み取り - 変更 - 書き込みを介して処理されます。 > また、バンクのターゲットレディイベント EVT :: = {EVT_IID; EVT_RDYS}は各サイクルで、リードモディファイライトを行う EVT _ID の ARDYS を介し又その DRDYS 及び EVT_RDYS をも使用して処理されます。 > リスト2を参照してください。 > 4つのARDYSビットがすべてセットされると、命令はレディ状態になります。 > ? このロジック(シアン)はすべて1つのスライスで済みます。 最適化として、READYの縮小はキャリーロジックになります。 > このロジック(シアン)の全ては 1 つのスライスで済み、 最適化として、READY 縮小の為の and はキャリーロジックになります。 > > ?   ry ・バンクの競合が存在する可能性があります。 >  EDGEコンパイラは、命令の両方のターゲットがディスジョイント・バンクにあることを保証するわけではないため、スケジューラ・バンクの競合が発生する可能性があります。 > ADD命令は、命令10のオペランドと命令12のオペランドを対象とすることができる。 > 同じサイクルで2つの偶数バンク・ターゲットのアクティブ・レディ状態を更新することはできないため、1つのイベントが処理され、もう1つのイベントが後のサイクルでキューに入れられます。 > > F. インクリメンタルなデータフロースケジューラの設計、運用、実装 >  スケジューラのコア(図7)は次のように構成されています。 > > . INSN: 2つのターゲットイベントフィールドを持つデコードされた命令 > . EVT0, EVT1: 偶数/奇数ペンディングイベントレジスタ > . 偶数/奇数イベントマルチプレクサ、プリデコードされたセレクトによって制御される > . SCH0, SCH1: 偶数/奇数16エントリスケジューラバンク > ? . 3つの準備命令IIDキュー: > . 3つのレディ命令IIDキュー: > -- DCRDYQ: デコーダレディキュー。 > ? -- ISRDYQ: 発行( ry 。 > -- ISRDYQ: イシュー(スケジューラ)レディキュー。 > -- LSRDYQ: ロード/ストアレディキュー > . 次のIIDを選択する2つの3:1セレクタ > ? . INSNS: デコードされた命令RAM( ry ) > . INSNS: デコード済命令RAM(リードポート) > > ? ry 、デコードされた命令レジスタ ry 。 > この設計では、スケジューラの繰り返しサイクルが開始され、デコード済命令レジスタで終了することに注意してください。 >  図1の最初のEDGEコードブロックの実行を検討してください。 > ? ry 、DVS、SCH0、SCH1のAVSがクリアされます。 > スケジューラがリセットされ、 SCH0 、 SCH1 の DVS 、 AVS がクリアされます。 > ? ry 、その命令をINSNSにフェッチしてデコードします。 > フロントエンドはブロックのヘッダをフェッチし、その命令をフェッチして INSNS にデコードします。 > ? 2つのREADは発行する準備ができているため、 ry 。 > 2つのREADはイシュー待ちレディーである為、IIDがDCRDYQにエンキューされます。 > ? これはバックエンドのために ``ポンプを準備する ''。 > これはバックエンドの為の ``ポンプの準備 '' 。 > ? ry 、準備ができていないため、エンキューされません。 > 他の命令はオペランドまたは述部を待機し、レディーでない為、エンキューされません。 > > 6 > > > > 0 > INSN > T1 > T0 > > 1 > EVT1 > EVT0 > > 2 3 4 > LSRDYQ > DCRDYQ > ISRDYQ > SCH1 > READY → > EVT ← > EVT_IID → > SCH0 > READY → > EVT ← > EVT_IID → > > 5 > IID > > 6 > INSNS: > ? デコードされた指示 デコード済命令 > 32xn LUT RAM > > 6 6 > INSNS: INSNS: > DECODED INSTRUCTIONS > 32xn LUT RAM 32xn LUT RAM > > (a)デザイン。 > > > > (b)FPGAの実装。 > > ? ry 、デコードされた命令バッファ、レディキューを含む。 > 図7: 32エントリスケジューラ、デコード済命令バッファ、レディキュー。 > > > ?  ry データフロー実行は次のように実行されます。 >  バックエンドのデータフロー実行継続は次の様に承認されます。 > ? ry 、両方のREADYが否定されます。 > 最初はINSNが無効で、両方のREADYがネゲートです。 > IIDセレクタツリーは、DCRDYQから最初のREAD命令(IID = 0)を選択/デキューします。 > デコードされたREAD命令語は、INSNSからINSNに読み出される。 > >  READ対象ADDオペランド#1 > ?そのINSN.T0(バンク対象準備完了イベント) ry 、そのマルチプレクサはSCH0のEVT =(2、 'b0001)を選択する。 > そのINSN.T0(偶数バンクターゲットレディーイベント)フィールドは有効であり、そのマルチプレクサは SCH0 用に EVT =(2、 'b0001)を選択する。 > これはADDのアクティブレディ状態を更新します: 'b1100 |' b0000 | 'b0001 =' b1101、現在は左オペランド(オペランド#0)のみを待ちます。 > どちらのスケジューラ・バンクもREADY命令を検出していないので、IIDセレクタ・ツリーはDCRDYQからの2番目のREADを選択/デキューします。 > >  このREADはADDオペランド#0を対象としています ; そのINSN.T0はEVT =(2、 'b0010)である。 > SCH0はADDのレディー状態を 'b1111'に更新し、READYをアサートしてADD(IID = 2)を発行します。 >  ADDのT1はSCH1のTLEIレディ状態をターゲットにしています。 > ? TLEIは準備ができて問題になります。 > TLEIはレディーとなりイシューされます。 > ?   ry ISステージ準備完了イベントを指定しない。 >  TLEIに関しては、どちらのT0 / T1フィールドもISステージレディーイベントを指定しない。 > どうして? > ADDのような単純な1サイクルレイテンシ命令とは異なり、テスト命令のターゲットは、テストがEXステージで実行されるまでレディイベントを受け取ることができません。 > テストが完了すると、その真/偽の述語イベントが通知されます。 > これらは待ち行列および/またはマルチプレクサ(図示せず)を介してEVT0、EVT1ペンディングイベントレジスタに進み、アイドルスケジューライベントスロットを待つ。 > ?   ry 、多くのエラスティックFIFOレディキュー ry 。 >  キュー: このデザインでは、多くの弾力的 FIFO レディキューとイベントキューが採用されています。 > ? アップダウンカウンタと ry 。 > それらは小さく且つ高速でありアップダウンカウンタとザイリンクスSRL32CE 32ビット可変長シフトレジスタLUTで構成されています。 > DCRDYQに加えて、現在の設計には2つの他のレディキューがあります。 >  ISRDYQ: 命令が発行され、それが2つを目覚めさせ、偶数命令が次に発行し、奇数命令がISRDYQにキューイングされるときの「1つの問題」の設計では、 >  ISRDYQ: 「 1 イシュー」の設計に於ては、命令が発行され、それが他の 2 つを目覚めさせ、偶数命令が次に発行し、奇数命令がキューイングされるキューは ISRDYQ >  LSRDYQ: EDGEプロセッサは、ロード・ストア・キューを使用してシーケンシャル・メモリ・セマンティクスを提供します。 > ry 並べ替えます。 (ready)ロード/ストアが ry 。 > 1つのシンプルなエリア最適化LSQは、特定のアクセスを保護して並べ替えます ; (レディ/)ロード/ストアがメモリに発行可能になると、LSQはそれをLSRDYQにエンキューします。 >  ブロードキャストウェイクアップ: 各EDGE結果ブロードキャストは、ウィンドウ内の任意の数の命令をターゲットにしてウェイクさせることができる。 > ? ry 、増分スケジューラーではコストがかかります。 > これは並列スケジューラーにとっては簡単ですが、インクリメンタルスケジューラではコストがかかります。 > 結果がブロードキャストされると、スケジューラは、そのブロードキャスト入力でデコードされた各命令のレディ状態を順次更新しなければならない。 > ? ry )を維持する。 > したがって、デコーダは、所定のブロードキャスト入力を有する命令のIIDの待ち行列(BR1Q、BR2Q、BR3Q)を整備する。 > Once a broadcast result is known, the scheduler begins to dequeue the BRnQ IIDs into EVTs presented to SCH0, SCH1. > ? ry SCH0、SCH1に提示されたEVTにデキューし始める。 > ブロードキャスト結果が分かれば、スケジューラはBRnQ IIDをSCH0、SCH1へ提示されたEVTにデキューし始める。 >  パフォーマンス: 図7aのラベル0〜6は、スケジューラクリティカルパスの各ポイントへの「LUT遅延」の数を示します。図7bの白いパスです。 > ? ry を含む4.3 nsです。 > Kintex-7 -1スピードグレードでは、INSNクロックトゥーアウト、EVTマルチプレクサ、SCH1のAVSリードポートマルチプレクサ、ARDYS_NXTとREADYロジック、IIDセレクタ、INSNSリード、およびINSNセットアップを含めて 4.3 ns です。 > ? ry LUTローカルMUXF7 / MUXF8 / CARRY4ネットの使用 ry 。 > ここで、相互接続遅延は、比較的短いネットとLUTローカルなMUXF7/MUXF8/ CARRY4ネットなりの使用を反映するクリティカルパスのわずか70%です。 > The scheduler clock period may be reduced to 2.5 ns by adding pipeline registers after the LUT RAM and FC-SO-RAM reads, but as with the parallel scheduler, pipelining precludes backto-back issue of dependent instructions. > ? ry LUT RAMおよびFC-SO-RAMの読み取り後にパイプラインレジスタ ry バックトゥーバック問題が排除されます。 > スケジューラのクロック周期は、LUT RAMおよびFC-SO-RAMの読取り後のパイプラインレジスタを追加することで2.5 nsに減らすことができますが、並列スケジューラと同様に、パイプライン処理によって依存命令のバックトゥーバックイシューの余地がなくなります。 > > ? G. 並列スケジューラと増分スケジューラの比較 > G. 並列とインクリメンタルとのスケジューラの比較 >  表2は、2つのデータフロースケジューラ設計の違いをまとめたものです。 > インクリメンタルスケジューラのコアは、並列スケジューラのサイズの3分の1以下ですが、キューとマルチプレクサの追加オーバーヘッドが追加されるとサイズの利点が小さくなります。 > ? ry 、エリア*期間のメトリック ry 。 > インクリメンタルスケジューラも高速で、エリア*時間のメトリックは2.6倍優れています。 > > 7 > > > メトリック パラレル インクリメンタル ユニット > > エリア, 32エントリ 288 78 LUTs > 面積、合計、32エントリ 340 150 LUTs > 期間 5.0 4.3 ns > 期間、パイプライン 2.9 2.5 ns > 面積、合計*期間 1700 645 LUT*ns > > ブロードキャスト ? フラッシュ反復 フラッシュインタリーブ > イベントバンクの競合? 決してない sometimes > > エリア、4イベント/サイクル 288 156 LUTs > エリア、64エントリ 576 130 LUTs > > ? 表II: 並列スケジューラと増分スケジューラの比較 > 表II: 並列とインクリメンタルとのスケジューラの比較 > > > しかし、並列スケジューラはいくつかの強引な利点を保持しています。 > ? 増分スケジューラは、 ry 割合でブロードキャストキューを反復的に排除する必要があります。 > インクリメンタルスケジューラは、ブロードキャストイベントを1サイクルで処理できますが、1サイクルあたり1〜2命令の割合で反復的にブロードキャストキューから排出させる必要があります。 > ? ry で問題が発生する可能性 ry 。 > これにより、一部のワークロードでイシューがストールする可能性があります。 > インクリメンタルスケジューラはまた、偶数/奇数のターゲットバンクの衝突を受けやすく、命令ウェイクアップを遅らせる可能性がある。 > ? ry 実質的な期間の利点を覆い隠す ry 、実際の作業負荷の調査が必要です。 > これらの影響が実質的な面積*時間の利点を覆隠すかどうかを測定するには、実際のワークロードの調査が必要です。 > ?  最後に、将来のスケールアップをより広い問題とより大きな命令ウィンドウにまで考慮する。 >  最後に、より幅広のイシューとより大きな命令ウィンドウの為の将来のスケールアップを考察する。 > ? ry 細分されたときには増加せず、 ry 。 > 並列スケジューラは、サイクルごとに2倍のイベントを処理するために、より多くのバンクに細分されたときには拡大せず、インクリメンタルスケジューラコア領域は2倍になります。 > 命令ウィンドウを64エントリに拡張するために、並列スケジューラは2倍の面積を必要とし、インクリメンタルスケジューラ領域はより穏やかに増加する。 > > IV. 結論 > ?   ry 取り組みを紹介します。 >  本稿では、FPGAのための実用的なアウトオブオーダーのデータフローソフトプロセッサーアーキテクチャーに向けた取組を紹介しました。 > ASICのより単純な高ILPマイクロアーキテクチャに最適化された新しいEDGE命令セットアーキテクチャが、FPGAに適しているか、または汎用ソフトプロセッサがスカラーRISC低速レーンに停滞しているかどうかを発見することに着手しました。 >  我々は、2つの異なるデータフロー命令スケジューラ設計とその最適化されたFPGA実装を検討した。 > ? ry 、いずれかのデザインのFPGAリソースコストとクロック周期の影響は限定的であり、 ry 。 > 市販の200MHz、1,000-2,000のLUTソフトプロセッサのコンテキストでは、いずれのデザインのFPGAリソースコストとクロック周期のインパクトも限定的であり、許容可能で実用的なようです。 > ? ry 4デコード/ 2つの実装形態に適しています。 > 両方の設計選択肢は、将来の4デコード/ 2イシュー実装形態へのスケールに適しています。 > > 参考文献 > ? ry 、「FPGAでRISCをつくる」、 ry > [1] J. Gray、1996年8月、「 FPGA で 自家製 RISC をつくる」、 http://fpgacpu.org/papers/j32.ppt > [2] ----、 「FPGAにRISCシステムを構築する」 サーキットセルラーインク、no。 116 - 118、March、April、2000年5月。 > [オンライン]。 利用可能な: http://fpgacpu.org/papers/xsoc-series-drafts.pdf > [3]アルテラ・コーポレーション、 「Niosエンベデッド・プロセッサ・ソフトウェア開発リファレンス・マニュアル」、2001年3月。 > [4]ザイリンクス社の「MicroBlazeプロセッサリファレンスガイド」、 2002。 > [5] AK Jones、R. Hoare、D. Kusic、J. Fazekas、およびJ. Foster、 「カスタムハードウェア実行によるFPGAベースのVLIWプロセッサ」、 > ? ry 、2005年、107〜117頁。 > フィールドプログラマブルゲートアレイに関する第13回国際シンポジウム予稿集、2005年、pp 107〜117頁。 > [6] KOI TiliとJG Steffan、 「チルト:マルチスレッドVLIWソフトプロセッサファミリ」、 > フィールドプログラマブルロジックとアプリケーションに関する国際会議の議事録、2013年8月。 > [7] P. Yiannacouras、JG Steffan、およびJ. Rose、 「VESPA:ポータブル、スケーラブル、フレキシブルなFPGAベースのベクタ・プロセッサ」 > ? 、および組み込みシステムに関する ry 。 > コンパイラ、アーキテクチャ、および組み込みシステムの統合に関する国際会議の議事録、2008、pp。61-70。 > [8] J. Yu、G. Lemieux、およびC. Eagleston、 > ? ry 、第16回国際プログラマブルゲートアレイシンポジウム講演予稿集、 ry 。 > 「ソフトコアCPUアクセラレータとしてのベクトル処理」、第16回プログラマブルゲートアレイ国際 ACM/SIGDA シンポジウム講演予稿集、2008年、pp。222-232。 > [9] R. Carli、 柔軟なMIPSソフトプロセッサアーキテクチャ、 修士論文、マサチューセッツ工科大学、2008年5月 > [10] K. AasaraaiとA. Moshovos、 「実行可能な順序外ソフトコアへ:コピーフリー、チェックポイント付きレジスタの名前変更、 > フィールドプログラマブルロジックとアプリケーションに関する第19回国際会議の講演会、2009年8月。 > [11] BH Dwiel、NK Choudhary、およびE. Rotenberg、 「多様なスーパースカラー・プロセッサのFPGAモデリング」、 > ? ry 」、2012年、188〜199頁。 > IEEE国際シンポジウム「システムとソフトウェアの性能解析」 論文集 、2012年、 pp 188〜199頁。 > [12] D. Burger、SW Keckler、KS McKinley、M. Dahlin、LK John、C. Lin、CR Moore、 > J. Burrill、R.G. McDonald、W.Yoder、X.Chen、R.Disikan、S.Drolia、J.Gibson、MSS Govindan、 > P. Gratz、H。Hanson、C. Kim、SK Kushwaha、H. Liu、R。Nagarajan、N. Ranganathan、 > E. Reeber、K.Sankaralingam、S.Sethumadhavan、P.Sivakumar、およびA.Smith、 > 「EDGEアーキテクチャを用いてシリコンの端までスケーリングする」、IEEE Computer、vol。 37、no。 7、pp。44-55、2004年7月。 > [13] M. Gebhart、BA Maher、KE Coons、J. Diamond、P. Gratz、M. Marino、N. Ranganathan、B. Robatmili、A. Smith、J. Burrill、SW Keckler、D. Burger、およびKSマッキンリー、 > ? ry 、2009年、1〜12頁。 > 「TRIPSコンピュータシステムの評価」、 プログラミング言語とオペレーティングシステムのアーキテクチャサポートに関する第14回国際会議の講演会、2009年、 pp 1〜12頁。 > [14] C. Kim、S. Sethumadhavan、MS Govindan、N. Ranganathan、D. Gulati、D. Burger、およびSW Keckler、 > ? ry 、2007年、381〜394頁。 > 「構成可能な軽量プロセッサ」、 第40回マイクロアーキテクチャシンポジウム講演予稿集、2007年、 pp 381〜394頁。 > [15] B. Robatmili、D. Li、H. Esmaeilzadeh、S. Govindan、A. Smith、A. Putnam、D. Burger、およびSW Keckler、 > ? 「ヒューズブル ry 」 > 「フューザブルダイナミックマルチコアアーキテクチャのための効果的な予測とフォワーディングの実装方法」 > ry 、2013年、第460 - 471頁。 > 第19回高性能計算機アーキテクチャ国際シンポジウム講演予稿集、2013年、pp 第460 - 471頁。 > [16] MSS Govindan、B. Robatmili、D. Li、B. Maher、A. Smith、SW Keckler、およびD. Burger、 > 「プロセッサのコンフィギュラビリティによるパワーと性能のスケーリング」、 > IEEE Transactions on Computers、2013年3月。 > > 8 > > > > -- > フリーソフトウエア関連ボランティアの皆様に感謝申上げますと共に > 当原稿執筆の多大なるコストへの御配慮に厚く御礼申上げます > 三菱 UFJ 銀行 平針支店 ( 普 ) 0111481 ヤマグチセイセイ > 郵便局 218普2449768 ヤマグチセイセイ > Yahoo pt 1362821068616323 Rakuten pt 1100-3310-4065-1717 > http://yahoo.jp/HsDIG -- YAMAGUTIseisei ( str_h__namae = { :sei => "山口" , :mei => "青星" } ) http://hello.to/seisei/ mailto:seisei@.68..net tel:081-70-5152-1104 heiwa furiisekkusu 1t