「データ転送効率」に要注目

　ICの設計がより複雑になる中、各社製品の設計には、1つのシステムを構成する多くの要素が取り込まれるようになった。データ処理機能、オンチップバス、さまざまな周辺インターフェース、汎用またはアプリケーション固有のアルゴリズムを実現する論理回路などが1つのチップに集積されるようになってきている。これらの要素のすべてを問題なく動作させるためには、ほとんどの場合、高性能のメモリーインターフェースが必要となる。

　現在、多くのSoC（system on chip）の設計においては、DRAMをどのように使用するかが、考慮するべきアーキテクチャ上の重要な課題となっている。オンチップDRAM（組み込みDRAM）を前提として設計されているのか、それとも外部のDRAMサブシステムを対象として設計されているのかにかかわらず、ほとんどの場合、SoCはオンチップのメモリーコントローラを必要とする。

　メモリーコントローラを使用したサブシステムは、例えば画像を処理するためのフレームバッファ、ネットワークルーター用のデータバッファ、携帯電話機やデジタルカメラといった民生機器における音声/画像データの保存用など、さまざまなアプリケーションで使用されている。そのため、SoCには、フラッシュメモリー、DDR（double data rate）2/3、モバイル向けDDR、グラフィックス用途向けのDDRなどに対応したメモリーコントローラが必要となる。

　しかしながら、特定のアプリケーションに最適なメモリーコントローラを選定するのは非常に困難な作業である。場合によっては、既存の選択肢では最適なメモリーコントローラを得られないこともある。以下、本稿ではDDR SDRAM（synchronous DRAM）メモリーコントローラ（以下、コントローラ）に限って解説を進める。

　コントローラをSoCに実装する方法には、2つの選択肢がある。1つは自社でコントローラを開発してそれを利用する方法である。もう1つは、サードパーティのIP（intellectual property）プロバイダからコントローラのIPコアを購入して使用するというものだ。いくつかの理由から、最近では後者の方法がより一般的になってきている。それらの中でも最も重要な理由は、コントローラの設計、検証、テスト、実装などは、こうしたサブシステムの開発経験があまりない設計者にとっては、非常に複雑でコストもかかり、リスクの大きい作業であることだ。

　また、今日のDDR規格とそれに対応するテスト手法は比較的、安定したものとなっている。そのため、自社でコントローラを開発しても、SoC化した際、それが他社と差異化を図れる要因とはならない。それに対し、IPコアの購入は長期的に見ればコストが低く抑えられ、納期の面でのリスクも低減可能な有効な方法だと言える。IPコアを利用することで、設計チームは製品の差異化につながる本質的な機能の設計/開発に専念することが可能になるため、この選択肢が重んじられているのである。

　コントローラのIPコアを購入すると決めたら、次に必要なのは、どれを選ぶべきなのかを技術的な面から考察することである。まず思い浮かぶ基準としては、コストや機能、サイズ、性能、遅延時間（レイテンシー）、消費電力などが挙げられる。

　しかし、IPコアを購入するための技術的な選択基準はこれだけでよいのだろうか。必ずと言ってよいほど見過ごされてしまうのが「データ転送効率（efficiency）」である。ここで言うデータ転送効率とは、理論上の最大帯域幅に対する実現可能な帯域幅の比率のことだ。このデータ転送効率こそが、対象とするシステムにそのコントローラが適合するかどうかを判断する上での重要な選択基準となる。

アクセス時間の違い

　データ転送効率について理解するには、まずDDR SDRAMの主要なアクセス特性についてよく知ることが重要である。もし、SDRAMへのアクセスにかかる時間が常に同じであれば、メモリーサブシステムのインターフェースにおけるデータ転送効率を測定するのは容易だ。しかし、実際のDDR SDRAMメモリーデバイス/サブシステムでは、アクセスの条件が異なれば、アクセス時間も異なる。

　DDR SDRAMのチップは、複数（通常は4か8）の独立したメモリーバンクを内蔵している。同バンクは、常にアイドル、アクティブのどちらかの状態にある。

　アイドル状態にあるメモリーバンクは、アクティブコマンドによってアクティブな状態に遷移する。そして、指示された行データをセンスアンプの配列に格納する（行を“オープン”する）。読み出し/書き込み操作の間、データはここで保持される。このプロセスには少し時間がかかるが、これは行からデータを読み出す前に必要なオーバーヘッドである。読み出し/書き込みコマンドは、アドレスを使って、行に格納された複数のデータ（2、4、8ワード）にアクセスする。

　コントローラが別の行にアクセスする場合、まず使用中のメモリーバンクのセンスアンプをアイドル状態に戻してから、次の行をセンス（感知）する。このプロセスは、プリチャージ（または行の“クローズ”）と呼ばれる。メモリーバンクが完全にアイドル状態になり、次のアクティブコマンドを受け取れるようになるまでには、少し時間が必要となる。

　アクセス時間を長いほうから順に挙げると、以下のようになる。

①すでに行がオープンされているときの、別の行へのアクセス（オープンの行をクローズし、新たに別の行をオープンする）
②クローズの行へのアクセス（その行をオープンする）
③現在オープンの行へのアクセス

　このほかにも、コントローラの実装においては、リフレッシュ、パワーダウン、初期化など、考慮しなければならないさまざまなタイミング要件があるが、本稿では省略する。ただし、考慮すべき重要な点がもう1つ存在するので、それについては指摘しておく。それは、メモリーサブシステムが読み出しから書き込みへと処理を遷移する際、インターフェースバスの反転に伴い発生する遅延である。この遅延があまりにも頻繁に起きると、メモリーへのデータ転送効率が全体的に劣化するので注意が必要だ。

データ転送効率の定義

　先述したように、データ転送効率とは、理論上の最大転送帯域幅に対し、メモリーインターフェースが提供する実際に利用可能なデータ転送帯域幅の割合のことである。例えば、DDR2 DIMM（dual inline memory module）における理論上の最大転送速度が6400メガバイト/秒で、実際の平均転送速度が3200メガバイト/秒である場合、データ転送効率は50％である。

　通常、コントローラのデータ転送効率は、25％から90％までといった具合に幅広い値をとる。非効率的なコントローラ実装を使用すると、システムの主要な特性に大きな影響が及び、全体のコストが増加することになる。

　また、メモリーアクセスの性質（トラフィックパターン）によっては、高いデータ転送効率を実現するのが難しいケースがある。前節で、オープンの行に対するアクセスは速いという事実について触れたが、メモリーに対するアクセスが、主にオープンな行に対して行われる場合には、理論上の最大帯域幅が実現される。それに対し、メモリーアクセスが分散的に行われる場合には、同じ行へのアクセスはほとんど発生せず、違う行へのアクセスが多発することによって処理時間が長くなる。これにより、平均アクセス時間が長くなり、全体のデータ転送効率が落ちてしまうのである。

　コントローラによっては、データのトラフィックパターンに応じて、より効率良く操作を組み合わせることのできるものがある。これであれば、非効率なトラフィックパターンによる影響を軽減することができる。例えば、メモリーアクセスのリクエスト（要求）が発生した順に実行するのではなく、同じ行へのアクセスをグルーピングして、読み出し/書き込み処理を最適に実行したり、優先度の高いデータへのアクセスをより速く実行したりするものである。このようなコントローラであれば、それぞれが備える機能と特徴によって、データ転送効率を大幅に改善することができる。