目的
- 多くのデジタル処理では、複数のデータから1つのデータを作ることがほとんどです。例えば、フィルタ処理は1つのデータを作るために、フィルタ係数分のデータが必要になります。このような処理では、1つのターゲットに対し必要最小限のデータを集めてくるDestination Baseの手法が効率的です。自然に採用していることが多いかと思います。
- Destination Baseの手法は、多対一の割合でメモリのReadとWriteを行うことが多くなります。つまり、メモリのRead性能が重要になります。不規則で離散的なReadを行うこともあるため、ランダムアクセス性能が重要になります。
- 一方、大量のメモリアクセスに伴って、SDRAM制御に不可欠なバーストアクセスへの対処も必要です。ランダムアクセスとバーストアク
セスをバランスさせないと性能が出ないため、ここに多くの時間と工数を費やすことになります。しかしせっかくシステムを構築しても、アクセスパターンが変わるだけで、再設計を強いられることも珍しくありません[1]。
- キャッシュは最適解ではないのですが、万能な解として用いることができます。比較的に性能が向上し、労力とバグの発生頻度を軽減するこため、現在の早期開発の流れに沿った技術であると言えます。SDRAMとセットで使う状況では、特に効果を発揮します。
- キャッシュにはCPUに用いられるものが一般的に解説されていますが、ここではLSIやFPGAに組み込まれる、多目的用途のキャッシュをターゲットにします（狭義な意味ではCPUキャッシュと同じです）。セットアソシアティブなどキャッシュの基本部分については割愛しますが、基本的にはCPUのキャッシュの機構を模したものになります。
考え方（キャッシュの機能）
- 基本的にアドレッシングに局所性があれば、キャッシュヒットする割合が増加し、性能向上に繋がることは直感的に分かります。これに加え、各種エンジンに使われるキャッシュの要件もしくは期待すべき項目[2]を上げてみます。
- ランダムアクセス可能で、SDRAM等バーストアクセスが必要なデバイスに対するブリッジとして機能すること[3]
- スループット性能とレイテンシ性能が劣化しないこと（特にスループット）
- キャッシュ容量やWay数などが可変で、特殊なSRAM等を使用することなく実装しやすいこと
- コヒーレンスへの対処やWrite-throughなど、用途に応じて機能の実装が選択できること
- ランダムアクセスとバーストアクセスのブリッジは、キャッシュの役割そのものなので自然に達成できます。これはエンジンの設計がかなり楽になるため大変有意義です。性能と実装に関することは、キャッシュの構造にかかわるため、実装のところで言及したいと思います。
- この中でやっかいなのは、コヒーレンス（一貫性）の対処です。キャッシュが複数使われると、それぞれで同じデータをアクセスする可能性が出てきます。厳密に制御するならば、Snoop機構を実装しなければなりません。しかし、これはコストと構造[4]に多大な影響を与えます（性能も影響を受けます）。
- そこで、ソフトウェアで排他的にメモリ領域管理すると言った割り切りを加えます。具体的には、同時刻においてエンジンが排他的なメモリ領域をアクセスするように制御し、必要に応じてそれぞれのキャッシュを解放（フラッシュ）[5]します。
- 一方排他的な制御を突き詰めるとエンジンごとのキャッシュシステムとなり、キャッシュを共有に使用してエンジン間でデータ交換することができません。複数のエンジンでリレーしてデータを加工する場合（大きな単位のパイプライン）、キャッシュにヒットしていればSDRAM等のアクセスは削減できるので、キャッシュでデータ交換できないのは大変もったいないことです。この解決方法は、帯域の拡大と合わせてクロスバスの設計例で述べたいと思います。ここの結論としては、排他的なメモリ領域の管理を前提に、任意のタイミングでキャッシュの内容を解放（フラッシュ）する機構だけを搭載することにします。
考え方（インターフェイス）
- キャッシュはSDRAMの末端からエンジン間まで、様々な部分で挿入することが考えられます。従って、基本的にインターフェイス仕様の一貫性・対称性が求められます。マスターはランダムアクセス、スレーブはバーストアクセスの違い等はありますが、上位・下位の互換性は保たねばなりません。
- マスターインターフェイスは、規定のバスプロトコルを当てはめます。Requestインターフェイスはそのままで行けます。Read/Write Dataインターフェイスはそれぞれ、flush信号が不要になります（ランダムアクセスのため）。
- メモリインターフェイスは、キャッシュフィル性能を最大化させるためR/W分離方式にします（同時アクセスを想定）。基本的に、マスターインターフェイスと同じですが、rxw信号が不要です。バースト長はモジュール外部で明示もしくは暗示します。
- コヒーレンス対処に必要なキャッシュタグ操作は、マスターインターフェイスと同期して行うか、別のインターフェイスを使って非同期に行います。
- マスターインターフェイスから同期して制御する方法は、Requestに同期する別の信号を定義します。タグ操作は例えば、ValidのクリアやFlush、Write-throughからWrite-backかの選択などで、基本的にRequestで指定した単位で制御を行います。
- 別のインターフェイスを使って非同期に制御する方法は、別のRequestを設け上記同様の信号を定義します。ただし、対象となる単位は、特定のWayなどキャッシュ全体の操作になります（特定の範囲も選ぼうと思えば可能）。このことから、一旦操作が始まると処理が長期間に及び、通常のマスターのアクセスをブロックする可能性があります[6]。
問題点
- 上記のキャッシュの問題点を上げてみます。
- アドレッシングに局所性がないと、キャッシュの効果がなく単なるコスト増加になる（単純なブリッジと比較して）
- 汎用性のため受動的なアクセスの受け付けとなり、最適解とはならない（例えば、先を予測したアクセスを前もって行うなど）
- キャッシュ容量などを性能・コストと照らし合いながら定める必要があるが、トレードオフ条件が確率的にしか分からないなど曖昧さがある
- 最後のトレードオフ条件は、キャッシュ容量・Way数・R/Wのタイプ[7]の選択に影響します。アドレッシングのパターンが状況によって変化する場合（極端な例だとランダムなアドレッシング）、キャッシュ容量・Way数とヒット率の関係を、数式モデルやシミュレーションモデルを用いて調べなければなりません。
- ところで、キャッシュは最悪の使用条件下だと、キャッシュがないシステムよりも性能が悪くなることがあります。図は画像を縦方向にアクセスして横方向の画像に転送する右90度回転です。縦方向のアクセスであっても、SDRAM等を使っているならば、バーストアクセスせざるを得ません。アクセスしたデータを全て保持しておかないと再度アクセスをやり直すことになり、キャッシュの意味がなくなります[8]。最悪の使用条件下を導き出してキャッシュ容量を設定する必要があります。
回路デザイン > 設計例 [キャッシュ] > 目的・考え方 次のページ（実装にあたって） このページのTOP ▲
