msyksphinz.hatenablog.com
Open in
urlscan Pro
13.230.115.161
Public Scan
Submitted URL: http://msyksphinz.hatenablog.com/
Effective URL: https://msyksphinz.hatenablog.com/
Submission: On May 17 via api from JP — Scanned from JP
Effective URL: https://msyksphinz.hatenablog.com/
Submission: On May 17 via api from JP — Scanned from JP
Form analysis 1 forms found in the DOM
GET https://msyksphinz.hatenablog.com/search
<form class="search-form" role="search" action="https://msyksphinz.hatenablog.com/search" method="get">
<input type="text" name="q" class="search-module-input" value="" placeholder="記事を検索" required="">
<input type="submit" value="検索" class="search-module-button">
</form>Text Content
読者になる
FPGA開発日記
カテゴリ別記事インデックス HTTPS://MSYKSPHINZ.GITHUB.IO/GITHUB_PAGES , ENGLISH VERSION
HTTPS://FPGADEVDIARY.HATENADIARY.COM/
2022-05-17
MACOS (APPLE SILICON)でのCHIPYARD動作試行
相変わらずApple Silicon上での作業に四苦八苦しているのだが、Chipyardの環境が構築できるのか思考している。
github.com
このリポジトリを使うためには最初にツールチェインをビルドする必要がある。これまではサボってビルド済みバイナリをダウンロードする方式にしていたのだが、Apple
Siliconだとそうは行かない。一からビルドできるか試行してみる。
./scripts/build-toolchains.sh --ignore-qemu
./scripts/build-toolchains.sh: line 18: greadlink: command not found
Installing toolchain to /Users/kimura/work/riscv/chipyard/chipyard/riscv-tools-install
build-toolchains.sh: obsolete make version; need GNU make 4.x or later
zsh: exit 255 ./scripts/build-toolchains.sh --ignore-qemu
なんか色々だめなので、別にMakeをインストールしてやってみる。 あとはgreadlinkというのが必要らしい。
brew install coreutils
MAKE=/opt/homebrew/opt/make/libexec/gnubin/make ./scripts/build-toolchains.sh --ignore-qemu
エラーが起きているようには見えないのだが、、なんかスクリプト自体は失敗しているなあ。
make[5]: Leaving directory '/Users/kimura/work/riscv/chipyard/chipyard/toolchains/riscv-tools/riscv-gnu-toolchain/build/build-binutils-newlib/binutils'
make[4]: Leaving directory '/Users/kimura/work/riscv/chipyard/chipyard/toolchains/riscv-tools/riscv-gnu-toolchain/build/build-binutils-newlib/binutils'
make[3]: Leaving directory '/Users/kimura/work/riscv/chipyard/chipyard/toolchains/riscv-tools/riscv-gnu-toolchain/build/build-binutils-newlib/binutils'
make[2]: Leaving directory '/Users/kimura/work/riscv/chipyard/chipyard/toolchains/riscv-tools/riscv-gnu-toolchain/build/build-binutils-newlib'
make[1]: Leaving directory '/Users/kimura/work/riscv/chipyard/chipyard/toolchains/riscv-tools/riscv-gnu-toolchain/build/build-binutils-newlib'
mkdir -p stamps/ && touch stamps/build-binutils-newlib
zsh: exit 2 MAKE=/opt/homebrew/opt/make/libexec/gnubin/make ./scripts/build-toolchains.sh
うーん、なんか既知の問題な気もしてくる。
checking for memory.h... checking for inttypes.h... rm -f bind.o
checking for strtoul... /Users/kimura/work/riscv/chipyard/chipyard/toolchains/riscv-tools/riscv-gnu-toolchain/build/../riscv-gdb/readline/rltty.c:83:7: error: implicit declaration of function 'ioctl' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
if (ioctl (tty, TIOCGWINSZ, &w) == 0)
^
checking for strtoll... /Users/kimura/work/riscv/chipyard/chipyard/toolchains/riscv-tools/riscv-gnu-toolchain/build/../riscv-gdb/readline/rltty.c:720:3: error: implicit declaration of function 'ioctl' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
ioctl (fildes, TIOCSTART, 0);
^
/Users/kimura/work/riscv/chipyard/chipyard/toolchains/riscv-tools/riscv-gnu-toolchain/build/../riscv-gdb/readline/rltty.c:759:3: error: implicit declaration of function 'ioctl' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
ioctl (fildes, TIOCSTOP, 0);
^
3 errors generated.
make[3]: *** [Makefile:96: rltty.o] Error 1
make[3]: *** Waiting for unfinished jobs....
msyksphinz 15時間前
広告を非表示にする
* もっと読む
コメントを書く
2022-05-16
ALPHA 21264に関する論文を読む (6. バスインタフェースユニット)
Alpha
21264は非常に有名なプロセッサで、コンピュータアーキテクチャ系を生業とする者ならば必ず読んでおかなければならないものの一つに入る論文だと聞いている。が、私はまじめに読んだことが無いのでこの際きちんと理解しようと思う。
ieeexplore.ieee.org
--------------------------------------------------------------------------------
バスインタフェースユニット
21264のバスインタフェースユニット(Bus Interface Unit:
BIU)は、内部メモリシステムと外部(チップ外)のL2キャッシュ及び他のシステムを相互に接続するためのものである。
* 内部システムメモリからMAF(これはどういう意味？)を受け取ると、L2キャッシュヒットした場合はL2キャッシュから、それ以外の場合はシステムからデータを取得する。
* データキャッシュからL2へEvictionデータを転送する。L2からシステムでEvictionデータを転送する。
* システムからキャッシュのプロービングを受信し、必要なキャッシュコヒーレスの動作を実行して応答する。
21264はWrite-Invalidateの共有メモリマルチプロセッシングのキャッシュコヒーレスをサポートしている(注: Write
Invalidateは、あるコアがキャッシュラインに書き込みを行った場合、それ以外のコアが保持している同等のキャッシュラインを無効化すること)。
図9は21264の外部インタフェースを示している。L2のインタフェースとシステムインタフェースは分離されている。
図は本論文中より引用
L2キャッシュは、プライマリのキャッシュの高速バックアップストアをサポートしている。
* ダイレクトマップ方式
* 命令とデータで共用
* 1~16MByteのサイズでコンフィギャラブル
* 転送速度はピークで1.5CPUサイクルで16倍と
* 最小レイテンシ6サイクルのSRAMを使用するができる。
21264のシステムバスにおいて、Address OutとAddress
Inが分離されていることにより、システムからの要求とコアからの要求を分離することができる。BIUは、保留中のシステムプローブをプローブキューに格納し、順番にプローブの対応を行う。
また、21264は多くのコヒーレンス動作をサポートしており、ディレクトリベースのシステムにも拡張できる。標準的なMOESI (Modified, Owned,
Exclusive, Shared, Invalid)のキャッシュ状態をサポートしている。
BIU
は、幅広いシステムデータバススピードをサポートしています。システムデータインターフェースのピーク帯域幅は、1.5CPUサイクルあたり8バイトのデータで、400MHzの転送速度では3.2Gバイト/秒となる。ロードレイテンシ（ロードの発行からコンシューマの発行まで）は、DRAMアクセス時間60nsで160nsと低い値を実現しています。8つのインフライトMAFと8つのインフライトビクティムにより、多くの並列メモリオペレーションが可能となり、SRAMとDRAMの高い効率性を実現するスケジュールを組むことができます。これは、キャッシュミスがあったとしても、高いメモリシステム性能につながります。例えば、21264
は Stream ベンチマークで 1.3Gbytes/sec (ユーザー可視) を超えるメモリバンド幅を維持しました7。
動的な実行例
この節では、2つの例で21264の動的適用性を説明する。
ストア/ロード メモリオーダリング
21264のメモリシステムは、アウトオブオーダ実行をサポートしつつ、インオーダアーキテクチャと同様のメモリモデルをサポートしている。レジスタのリネーム論理と異なり、Read
After Writeのメモリ依存性を静的に検出ることができないため、メモリシステムは命令が発行されたあと、問題となるケースを動的に検出することができる。
ここでは、21264がロード命令の投機的実行に失敗した際のコストを回避するための方法示している。ここでは、最初の投機的実行失敗を記録し、それ以降の実行ではロードの実行を遅らせる。
図10では、21264がRead After
Writeのハザードを解決する方法示している。左側の命令リストでは、ストア命令(STQ)に対してロード命令(LDQ)が実行される。ロード命令ができるだけ早く発行され、ストア命令よりも前に発行される。これにより間違ったデータを受け取ってしまう。これを検出したあと、以降の実行では、フェッチ時にロードに対応するストアテーブルのビットが設定され、ストア・ロードの順序違反を検出し、ロード命令が投機的に実行されることを防ぐ。
図は本論文中より引用
つまり、マークされたロード命令はストア命令が実行されるまで待ち、マークされていないロード命令は可能な限り早く発行しようとする。
ロードヒット・ミス予測
21264の陶器実行ロード命令では、整数ロードヒットレイテンシを3サイクルで達成するために、整数ロードによるデータを使用する命令(データ使用命令)を投機的に発行する必要がある。これによりデータ使用命令は可能な限り早くロード命令からのデータをバイパスすることができる。データキャッシュのステージは命令発行ステージの3サイクル後である。ロード命令のデータキャッシュにおけるヒット・ミスを識別するために、さらにもう1サイクル必要となる。
このような状況下で、整数ロードデータのキャッシュミスが発生し後続のデータ命令の実行を中止するために、命令パイプライン全体を再起動する必要があるが、コストが掛かりすぎるので、ミニスタート機構で実現する。
ロードミスが発生した命令の3サイクル後にデータ処理命令が投機的に命令を発行すると、ミスが発生した時点で後で再発行されるように発行キューに引き戻される。ロードがヒットすれば、図11に示したようなスケジュールで命令が実行される。しかし、ロードのミスが発生した場合に、5サイクル目と6サイクル目に無関係な命令L5とL6が実行される。
この2サイクルのウィンドウは、プロセッサのパイプラインを完全に再起動するよりはコストは小さい。21264はロード命令がいつミスするかを予測し、その場合はデータ消費命令を投機的に発行しないように予測している。
図11の下半分は、予測を行った場合の命令スケジュール例である。ミス予測が行われたロード命令のデータ使用命令は、レイテンシは3サイクルではなく5サイクルとなる。
図は本論文中より引用
msyksphinz 1日前
広告を非表示にする
* もっと読む
コメントを書く
2022-05-15
自作RISC-Vコア向け環境のLIBELFを置き換える試行
ひょんな理由でM1 Macを使う必要が生じたのだが、MacOSにはlibelfが無いということが分かった。
いろいろ考えて、x86のLinuxを仮想マシンでシミュレートするか、それともそもそもMac環境で開発することを諦めるか考えたのだが、よく考えてみるとriscv-isa-sim(spike)はちゃんと動作している。どうしているんだろうと思ったら、libelfによるelfのローディングを使用せず、自前でelfを取り込む環境を用意していた。
github.com
elf.hは自前で定義しており、必要最低限の実装を用意しているようだ。memifにELFのデータを書いているようなので、これを現在使用しているELFローダの実装で置き換える。
github.com
このへんの実装だな。
#define LOAD_ELF(ehdr_t, phdr_t, shdr_t, sym_t, bswap) \
do { \
ehdr_t* eh = (ehdr_t*)buf; \
phdr_t* ph = (phdr_t*)(buf + bswap(eh->e_phoff)); \
*entry = bswap(eh->e_entry); \
assert(size >= bswap(eh->e_phoff) + bswap(eh->e_phnum) * sizeof(*ph)); \
for (unsigned i = 0; i < bswap(eh->e_phnum); i++) { \
if (bswap(ph[i].p_type) == PT_LOAD && bswap(ph[i].p_memsz)) { \
if (bswap(ph[i].p_filesz)) { \
assert(size >= bswap(ph[i].p_offset) + bswap(ph[i].p_filesz)); \
memif->write(bswap(ph[i].p_paddr), bswap(ph[i].p_filesz), \
(uint8_t*)buf + bswap(ph[i].p_offset)); \
} \
if (size_t pad = bswap(ph[i].p_memsz) - bswap(ph[i].p_filesz)) { \
zeros.resize(pad); \
memif->write(bswap(ph[i].p_paddr) + bswap(ph[i].p_filesz), pad, \
zeros.data()); \
} \
} \
} \
無理やり書き換える。下記のg_memoryに挿入したデータが、そのまま外部RAMに書き込まれてフェッチ・データアクセスに使用される。
#define LOAD_ELF(ehdr_t, phdr_t, shdr_t, sym_t, bswap) do { \
ehdr_t* eh = (ehdr_t*)buf; \
phdr_t* ph = (phdr_t*)(buf + bswap(eh->e_phoff)); \
/* *entry = bswap(eh->e_entry); */ \
assert(size >= bswap(eh->e_phoff) + bswap(eh->e_phnum)*sizeof(*ph)); \
for (unsigned i = 0; i < bswap(eh->e_phnum); i++) { \
if(bswap(ph[i].p_type) == PT_LOAD && bswap(ph[i].p_memsz)) { \
if (bswap(ph[i].p_filesz)) { \
assert(size >= bswap(ph[i].p_offset) + bswap(ph[i].p_filesz)); \
for (int b_idx = 0; b_idx < ph[i].p_filesz; b_idx++) { \
g_memory->StoreMemory<Byte_t> (ph[i].p_paddr + b_idx, (Byte_t *)(buf + bswap(ph[i].p_offset) + b_idx)); \
} \
} \
zeros.resize(bswap(ph[i].p_memsz) - bswap(ph[i].p_filesz)); \
} \
} \
一応ここまでで、シミュレーション環境を構築できるようになった。
msyksphinz 2日前
広告を非表示にする
* もっと読む
コメントを書く
2022-05-14
MACOSでのRISC-Vツールチェインの動作確認
ひょんな理由でM1 Macを使う必要が生じたので、M1 Mac上で自分のRISC-Vコアをシミュレーションする方法について模索している。
M1
MacはベースがArmなのでいろんな環境がLinuxと異なっているのだが、そのへんをどのように調整すればいいのか四苦八苦することが多い(そもそも自分はMacOSを使うのが人生で初めて)。
* MacOS用のRISC-Vツールチェインのインストール
MacOS用にプレビルドされたツールセットをインストールできるらしい。
github.com
$ /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
$ brew tap riscv-software-src/riscv
$ brew install riscv-tools
それぞれのコマンドの意味はよくわからない。
これで一応、riscv-gnu-toolchainと命令セットシミュレータくらいは使えるようになる。
$ which riscv64-unknown-elf-gcc
/opt/homebrew/bin/riscv64-unknown-elf-gcc$ riscv64-unknown-elf-gcc --version
riscv64-unknown-elf-gcc (g5964b5cd727-dirty) 11.1.0
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ which spike
/opt/homebrew/bin/spike
ちなみに、必要に迫られてriscv-isa-simの自前でのビルドを試行したが、一応うまくいくようだ。
$ git clone https://github.com/riscv-software-src/riscv-isa-sim.git
$ cd riscv-isa-sim
$ ./configure
$ make -j10
msyksphinz 3日前
広告を非表示にする
* もっと読む
コメントを書く
2022-05-13
ALPHA 21264に関する論文を読む (5. メモリアクセスユニット)
Alpha
21264は非常に有名なプロセッサで、コンピュータアーキテクチャ系を生業とする者ならば必ず読んでおかなければならないものの一つに入る論文だと聞いている。が、私はまじめに読んだことが無いのでこの際きちんと理解しようと思う。
ieeexplore.ieee.org
--------------------------------------------------------------------------------
アドレスと制御構造
メモリシステムの内部には、32エントリのLoad Queue(LDQ)と32エントリのStore Queue
(STQ)が実装されており、インフライトなメモリアクセスを管理している。それぞれのエントリはフェッチの順番に割り当てられるが、発行する際はアウトオブオーダに発行される。ロード命令の場合は、ロード命令がリタイアして、ロードデータが書き込まれた後にフェッチの順番(インオーダ)でLDQから解放される。ストア命令は、データがキャッシュに書き込まれた後、フェッチの順番(インオーダ)でSTQから解放される。
命令が発行されると、古い命令に対してそのアドレスとAgeをチェックする。アドレスCAMにより、アウトオブオーダメモリアクセスに対してRAR, RAW, WAR,
WAWのハザードを完全に解決する。
* Read After Write : 欲しいデータを書き込む前にそのレジスタを読んでしまうこと
* ストア命令実行時に、LDQのエントリをチェックし、若いロード命令がすでにデータを取得している場合にはそのロード命令を破棄しなければならない。
* STQのCAMにより、投機的ストアデータバッファを制御し、古いストア命令の後に若いロード命令が発行された場合、ロードに投機的なストアデータをバイパスする。
図 8
は、両方のデータバス、データキャッシュ・タグ、およびデータキャッシュ・アレイ自体への両方のポートを含む、メモリシステムのスケジューリング例を示しています。9つのロードイシュー、L1-L9、9つのストアの一部、S1-S9、および3つのフィルの一部（それぞれ必要な64バイトを得るために4データバスサイクルを要する）、F1-F3が含まれています。ロードは、パイプラインステージ6でデータキャッシュのタグとアレイの両方を参照し、ロード結果はその1サイクル後のステージ7でデータバスを使用します。たとえば、図
8 では、ロード L6 と L7 は、13 サイクルでステージ 6（図 2）、14 サイクルでステージ 7 になっています。
図8は、メモリシステムのスケジューリングの例を示している。
* L1からL9までのロード命令発行
* S1からS9までのストア命令発行
* F1からF3までのデータフィル
パイプラインステージ6において、データキャッシュを参照し、ロード結果はステージ7でデータバスに流される。図8においては、ロード命令6はステージ6にサイクル13で到達、サイクル14でステージ7に到達している。
図は本論文中より引用
ストア命令は、リタイアするまでキャッシュアレイを参照しない。S5はサイクル1でタグを参照するが、サイクル16までデータキャッシュに書き込まない。
フィルパターンは、サイクル0で到達し、サイクル1でストールした後サイクル2で書き込まれる。
この図におけるサイクル7,
サイクル10、サイクル16は、それぞれ2つのストア命令が1つのストアデータにマージされる様子を示している。図のサイクル7ではS1とS2の書き込みが発生されているが、サイクル1～6はこの書き込みはストールされている。これは、サイクル1～6まではすべてフィルもしくはロード命令によりビジー状態になっているからである。
サイクル5でのロードL4とL5のキャッシュタグの使い方は特殊である。キャッシュのタグの参照をデータアレイおよびデータバスから切り離しているため、フィルが行われている間あいているキャッシュタグを活用する。これにより、ロード命令発行スロットのキャッシュアレイの参照とデータバス転送を分離することができ、不必要なキャッシュアクセスを排除することにより帯域幅を向上できる。
内部メモリシステムには、8エントリのMiss Address
File(MAF)が実装されており、各エントリは64バイト単位でキャッシュブロックのミスを管理している。同じキャッシュブロックに対するロードストアのミスは、1つのMAFによりマージされる。かくMAFエントリは、L2キャッシュまたはシステムフィルが行われる。
AlphaはWeakly Memory Orderingであり、プラグラマがメモリバリア命令を挿入するときだけ、メモリアドレスへの順序付けが行われる。
キャッシュのプリフェッチと管理
メモリシステムには、キャッシュプリフェッチ命令が実装されている。ソフトウェアがメモリ参照を制御したい場合、関連する64バイトのキャッシュブロックをプリフェッチすることができる。
msyksphinz 4日前
広告を非表示にする
* もっと読む
コメントを書く
2022-05-12
MIPSがRISC-Vに化けた。P8700とI8500コア
前々から噂されていた、MIPSがRISC-Vを作っている話、正式発表があったようだ。
PシリーズとかIシリーズとかMIPSの時代からあった名前なので、それがそのまま踏襲されてしまっている。ただし中身はRISC-V。
riscv.org
EVOCORE P8700
これはかつてのMIPS Pシリーズの継承でしょうね。
* アウトオブオーダ実行パイプライン
* マルチスレッド対応
* シングルスレッド性能はこれまでのどのRISC-Vコアよりも高い
* 最大64クラスタ、512コアまで対応
こちらの記事ではもうちょっと詳しいことが書いてある。
www.cnx-software.com
* Multi-issue superscalar Out of Order (OOO) with Multi-threading
* 16-stage pipeline for higher clock frequency
* 8-wide instruction fetch
* 8-execution pipes: 2xALU, MDU, 2xFPU, 2xMemory
* Enhanced Coherence Manager with L2 cache
* HW pre-fetch, widened busses, reduced latency
* 48-bit physical addressing
* 256 Interrupt support, APLIC/CLINT
* System interface
* ACE or AXI: 256-bit system bus
* Optional: Coherent Bus (up to 8 ports)
* Optional: Non-coherent periphery bus (up to 4 ports)
図を見る限りはRV64GHC、つまり、ハイパーバイザー対応ということになる。
EVOCORE I8500
これはかつてのMIPS Iシリーズの継承でしょうね。
* インオーダパイプライン
* マルチスレッド対応
* 3命令発行パイプライン
* In-Order with Simultaneous Multi-threading (SMT)
* 9-stage pipeline for efficient execution
* Wide instruction fetch
* 7-execution pipes: ALU, MDU, 2xFPU, 2xMemory
* Enhanced Coherence Manager with L2 cache
* HW pre-fetch, widened busses, reduced latency
* 48-bit physical addressing
* 256 Interrupt support, APLIC/CLINT
* System interface
* ACE or AXI: 256-bit system bus
* Optional: Coherent Bus (up to 8 ports)
* Optional: Non-coherent periphery bus (up to 4 ports)
こちらも図を見る限りはRV64GHC、ハイパーバイザー拡張だ。
msyksphinz 5日前
広告を非表示にする
* もっと読む
コメントを書く
2022-05-11
ALPHA 21264に関する論文を読む (4. 実行ユニット / メモリアクセスユニット)
Alpha
21264は非常に有名なプロセッサで、コンピュータアーキテクチャ系を生業とする者ならば必ず読んでおかなければならないものの一つに入る論文だと聞いている。が、私はまじめに読んだことが無いのでこの際きちんと理解しようと思う。
ieeexplore.ieee.org
--------------------------------------------------------------------------------
実行エンジン
図6は、6つの実行パイプラインを示したものである。各パイプラインは、対応するレジスタファイルの上下に配置されている。
* 浮動小数点
* 浮動小数点乗算
* 浮動所数点加算/浮動小数点除算/浮動小数点SQRT
* 整数
* クラスタ0
* 整数乗算/シフト/分岐/加算/論理演算
* 加算/論理演算/ロード/ストア
* クラスタ1
* MVI/PLZ/シフト/分岐/加算/論理演算
* 加算/論理演算/ロード/ストア
2つのレジスタファイルが用意されているのは、クラスタ0とクラスタ1でレジスタの読み書きを分離し、合計で4ウェイ整数命令実行をサポートしている。クラスタリングとアービトレーションの簡素化により、性能コストは数パーセントダウンするが受け入れ可能である。
図6には浮動小数点実行パイプラインの構成も示している。1つのクラスタに2つの浮動小数点実行パイプラインがあり、72エントリの物理レジスタファイルを備えている。
図は本論文中より引用
21264には、21164には搭載されていなかった新規命令が搭載されている。
内部メモリシステム
内部メモリシステムにおいて、整数実行パイプから最大で2つのメモリアクセスを実行することができる。この2つのメモリアクセス命令はアウトオブオーダで実行される。
* 最大32個のインフライトメモリロード
* 最大32個のインフライトメモリストア
* 8つのインフライトキャッシュミス
を管理することができる。
64kBの2-wayセットアソシアティブデータキャッシュを搭載している。
データパス
21264は、1サイクル当たり2つのロード・ストア命令の任意の組み合わせをサポートしている。データキャッシュは、2ポートアクセスを許可するためにダブルポンプされている。これは、データキャッシュは毎サイクル2回参照され、クロックフェース上で2回アクセスが実行されている。
図7は、メモリシステムの内部データ経路を示したものである。
* 64ビットデータバス(x2) :
非常に重要なもので、各ロード命令、データキャッシュ、ストアデータバッファ、L2フィルなどのデータはこのデータバスを通じて授受される。
* ストア命令
* データバスを介して投機的ストアバッファにデータを転送する。
* ストア命令がリタイアすると、投機的ストアバッファに残されたデータをキャッシュに書き込む。
* 2つのストア命令を1つに統合するため、各ストアデータエントリは128ビットをキャッシュに書き込むことができる。この書き込みもダブルバンプデータキャッシュである。
* 投機的ストアバッファ内部に存在しているとき、後続のロード命令にそのデータを転送することができる。
* ストールしているロード命令は、自分のAgeとアドレスをこれらのストールしているストア命令を比較し、一致した場合はストア命令からエントリにフォワードされる。
図7は、内部メモリシステムとデータの出入り口についても示している。フィルされたデータはデータバスを経由して渡される。また、データフィルと同時にそのキャッシュの内容が読みだされ、バスインタフェースユニットを通じてそのEvictionデータを外部に書き戻す。
図は本論文中より引用
msyksphinz 6日前
広告を非表示にする
* もっと読む
コメントを書く
次のページ
プロフィール
msyksphinz
読者です 読者をやめる 読者になる 読者になる
402
このブログについて
検索
リンク
* はてなブログ
* ブログをはじめる
* 週刊はてなブログ
* はてなブログPro
最新記事
* MacOS (Apple Silicon)でのChipyard動作試行
* Alpha 21264に関する論文を読む (6. バスインタフェースユニット)
* 自作RISC-Vコア向け環境のlibelfを置き換える試行
* MacOSでのRISC-Vツールチェインの動作確認
* Alpha 21264に関する論文を読む (5. メモリアクセスユニット)
月別アーカイブ
* ▼ ▶
2022 (119)
* 2022 / 5 (17)
* 2022 / 4 (30)
* 2022 / 3 (26)
* 2022 / 2 (19)
* 2022 / 1 (27)
* ▼ ▶
2021 (302)
* 2021 / 12 (13)
* 2021 / 11 (15)
* 2021 / 10 (22)
* 2021 / 9 (25)
* 2021 / 8 (26)
* 2021 / 7 (29)
* 2021 / 6 (28)
* 2021 / 5 (32)
* 2021 / 4 (30)
* 2021 / 3 (30)
* 2021 / 2 (28)
* 2021 / 1 (24)
* ▼ ▶
2020 (360)
* 2020 / 12 (30)
* 2020 / 11 (27)
* 2020 / 10 (31)
* 2020 / 9 (30)
* 2020 / 8 (31)
* 2020 / 7 (31)
* 2020 / 6 (30)
* 2020 / 5 (31)
* 2020 / 4 (28)
* 2020 / 3 (31)
* 2020 / 2 (29)
* 2020 / 1 (31)
* ▼ ▶
2019 (358)
* 2019 / 12 (32)
* 2019 / 11 (29)
* 2019 / 10 (31)
* 2019 / 9 (30)
* 2019 / 8 (31)
* 2019 / 7 (31)
* 2019 / 6 (29)
* 2019 / 5 (29)
* 2019 / 4 (31)
* 2019 / 3 (28)
* 2019 / 2 (28)
* 2019 / 1 (29)
* ▼ ▶
2018 (348)
* 2018 / 12 (29)
* 2018 / 11 (28)
* 2018 / 10 (30)
* 2018 / 9 (27)
* 2018 / 8 (26)
* 2018 / 7 (27)
* 2018 / 6 (31)
* 2018 / 5 (30)
* 2018 / 4 (29)
* 2018 / 3 (29)
* 2018 / 2 (29)
* 2018 / 1 (33)
* ▼ ▶
2017 (349)
* 2017 / 12 (32)
* 2017 / 11 (33)
* 2017 / 10 (31)
* 2017 / 9 (29)
* 2017 / 8 (29)
* 2017 / 7 (30)
* 2017 / 6 (30)
* 2017 / 5 (33)
* 2017 / 4 (24)
* 2017 / 3 (30)
* 2017 / 2 (21)
* 2017 / 1 (27)
* ▼ ▶
2016 (308)
* 2016 / 12 (26)
* 2016 / 11 (29)
* 2016 / 10 (30)
* 2016 / 9 (23)
* 2016 / 8 (19)
* 2016 / 7 (23)
* 2016 / 6 (20)
* 2016 / 5 (25)
* 2016 / 4 (28)
* 2016 / 3 (22)
* 2016 / 2 (31)
* 2016 / 1 (32)
* ▼ ▶
2015 (329)
* 2015 / 12 (27)
* 2015 / 11 (34)
* 2015 / 10 (31)
* 2015 / 9 (44)
* 2015 / 8 (31)
* 2015 / 7 (35)
* 2015 / 6 (29)
* 2015 / 5 (28)
* 2015 / 4 (6)
* 2015 / 3 (17)
* 2015 / 2 (27)
* 2015 / 1 (20)
* ▼ ▶
2009 (18)
* 2009 / 10 (8)
* 2009 / 9 (5)
* 2009 / 3 (5)
FPGA開発日記
Powered by Hatena Blog | ブログを報告する
引用をストックしました
ストック一覧を見る 閉じる
引用するにはまずログインしてください
ログイン 閉じる
引用をストックできませんでした。再度お試しください
閉じる
限定公開記事のため引用できません。
読者です 読者をやめる 読者になる 読者になる
402