News and Views 2014 Summer / Vol. 10: 上流設計&組込み

オンチップバスの機能とその検証について

はじめに

SoC設計におけるオンチップバスのインターコネクトは、非常に重要なサブシステムになってきています。異なるマスタやスレーブ間のデータを転送する機能を果たしつつ、かつシステムとしての性能要件を満たさなくてはなりません。スループットを最大化するためにスイッチングを階層的に構成し、リンクさせる設計も存在します。

ヘテロジニアスなマルチコアのシステムで、複数のキャッシュが同一のデータを共有するような場合、キャッシュコヒーレントのプロトコルを持つインターコネクト設計や検証が極めて複雑化します。AMBA®4 ACE™や、AMBA5のCHI™に代表されるプロトコルがそれにあたります。

オンチップバスの進化

さて、大規模SoC設計における統合プロセスの労力は、標準的なプロトコルを使用することにより負担が軽減されます。ARM®から提供される多種のプロセッサIPやシステムレベルIPはもとより、サードパーティから提供される設計IPがAMBAをサポートしています。しかし、SoC検証作業の中で、これらすべてのIPがAMBAに対して適切に統合されていることを検証し、インターコネクトのコンフィギュレーションを最適化することに膨大な労力が割かれていることも事実です。結果として、インターコネクトの性能決定はプロジェクトの後工程で検討されてしまい、求める性能の達成を図るには「時すでに遅し」という状況に陥ってしまうケースがあまりに多く見受けられます。限られたバンド幅を複数のマスタやスレーブが競合し合う複雑なプラットフォームにおいて、システムレベル全体で性能解析が可能な手法が求められています。

図1. マスタ(M0)からスレーブ(S3)までのトランザクション(T1、T2、T3)がリンクされる図1. マスタ(M0)からスレーブ(S3)までのトランザクション(T1、T2、T3)がリンクされる

AMBAプロトコルファミリは、SoCに対するより高い性能要件に応えるために、進化を続けてきました。第一世代のプロトコルはASBやAPBでした。第二世代ではAHB™が出現し、複数のマスタ、複数のスレーブ、マルチプレクス可能なインターコネクトへと進化しました。ただしリード、ライトのデータ転送はパイプライン1段のインオーダーに限定されていました。第三世代のプロトコルはAXI™で、マスタからスレーブへのPoint-to-Pointのインタフェースが可能になり、マスタのリクエストをターゲットのスレーブにルーティングし、その応答をオリジナルのマスタに返すためのスイッチングを使用します。図1は、M0からS3へ、複数のインターコネクト階層を経たトランザクションのリンクを示しています。複数のサブチャンネルでリードとライトを分け、必要な段数のパイプラインを用いて異なるフェーズで転送し、リードアクセスへの応答のアウトオブオーダー転送も実現しています。これによりオンチップバスとしての採用が広がりました。

各設計IPのAXIやAHBへのインタフェースがプロトコル仕様に従って正しく実装されているかどうかは、検証IPを用いて検証できます。テストベンチで検証IPを用いて設計IPへのスティミュラスとし、さらにスティミュラスのカバレッジや設計IPからの応答を監視します。この時に重要になるのがテストプランです。検証IPに実装されているコードにはテスト項目が分かりやすいネーミングが使われているのが一般的ですが、最終的にはドキュメントによる仕様確認が必要となります。シミュレータが直接アクセス可能なテストプランが検証IPの一部として備わっていることで、シミュレーションのセッションを離れることなく、テストプランに照らしあわせたテストが可能になります。

キャッシュコヒーレンシの重要性

第四世代のAMBAプロコトルではACEが追加され、新たにキャッシュコヒーレンシをサポートするようになりました。最新のARMプロセッサでは、インストラクションを常時実行すべく、複数段のメモリ階層(L1、L2、L3)を持つキャッシュ構造がよく用いられます。キャッシュは、インストラクションやデータフェッチのレイテンシを短くするだけでなく、外部メモリへのアクセスを回避することでシステムが消費する電力を抑えます。

マルチプロセッサシステムでは、異なるCPUがメモリのデータ領域を共有し、プロセス間の同期やハードウェアリソースへのアクセスを可能にしています。共有されるデータは、セマフォ、コマンド、メッセージなどのテーブルです。キャッシュコヒーレンシを使って、この共有データ領域を、各プロセッサのデータキャッシュ内に常駐させることができます。これにより、例えばセマフォの状態をチェックするために、わざわざ外部メモリにアクセスする必要がありません。

マルチプロセッサのSoCにおいて、インストラクションセットにバイナリ互換がある場合、あるプロセッサから別のプロセッサへと実行をスイッチさせることができます。これにより、処理の負荷を分散させたり、より処理能力の高いプロセッサへとスイッチしたり、より低消費電力のプロセッサへとスイッチすることなどが可能になります。ARMのbig.LITTLE™はまさにこのアプローチの良い例です。実行すべきプロセスを、処理能力が大きく消費電力の小さなクラスタで実行させ、スワップすることが可能です。

キャッシュコヒーレンシは、コア間でプロセスをスイッチさせる際のオーバーヘッドを低減します。同じインストラクションのコードが複数のキャッシュ間で共有されているので、プロセス実行のコアが変わっても、そのまま実行できるメリットがあります。

キャッシュコヒーレンシを実現するハードウェアは、バスのマスタが他のマスタのキャッシュへの専用インタフェースを使ってアクセスする仕組みになります。他のマスタのキャッシュコンテンツを探り当てることから、スヌープ(snoop)と呼ばれます。ACEとはAXI Coherency Extensionsの略称で、AXIバスインタフェースに対して以下の拡張を実現しています。

図2. キャッシュコヒーレントのインターコネクトとスヌープアクセス図2. キャッシュコヒーレントのインターコネクトとスヌープアクセス

  • 既存チャネルでコヒーレントアクセスを可能にするバスフィールドを追加
  • スヌープアクセスをサポートする3つのサブチャンネルを追加

共有メモリにアクセスする際に、コヒーレントのマスタは最初に自身のコンテンツをチェックします。キャッシュミスとなった場合には、スヌープリクエストをインターコネクトに出します。インターコネクトは、システム上の他のコヒーレントマスタに対するスヌープアクセスを試み、スヌープがヒットすればそのマスタからのデータをリクエスト側マスタに送り、リクエストしたマスタのキャッシュに追加します。スヌープがフェイルした場合には、インターコネクトはメモリ階層中の次段へとアクセスを開始し、元のマスタへと結果を返し、同時に他のコヒーレントマスタにもスヌープされることになります。ACEにおけるトランザクションのリンキングを図2に示します。Master_0は共有メモリのデータをリクエストし、インターコネクトがスヌープのトランザクションを他のコヒーレントマスタに送出します。フェイルした場合にはSlave_2から外部メモリにアクセスすることになります。

ACEプロトコルでは、システム内のコヒーレントマスタに対するスヌープにより効率の良いデータ共有を図っていますが、マスタ数にも限りがあります。そこで、AMBA5 CHI(Coherent Hub Interface)プロトコルにおいては、スケーラビリティがサポートされるようになりました。これは、キャッシュディレクトリというACEとは異なるスヌープのアプローチになります。またAXIインタフェースとも異なり、プロトコルのトランスポートレイヤにハイスピードのパケット指向のアプローチが取られています。

ACEやCHIにおいてキャッシュコヒーレンシをチェックするためにスヌープチャネルが追加され、マスタとスレーブの関係が1対1ではなくなりました。このスヌープチャネルに対しては、非コヒーレント状態では各キャッシュラインにValid / Invalidを示すビットを使用します。キャッシュコントローラから、アクセスがヒットしたかミスしたかを知ることができます。コヒーレント状態になると、Invalidに加えて、Unique Clean、Unique Dirty、Shared Clean、Shared Dirtyといったステートが追加されます。この5つの要素を組み合わせたキャッシュステートを図3に示します。

図3. コヒーレントキャッシュのステート図3. コヒーレントキャッシュのステート

Invalidは、キャッシュラインに有効なデータがないことを意味します。キャッシュラインのステートがUniqueというのは、そのデータが唯一そのマスタにのみ存在し、他のマスタには存在しないことを意味します。逆にSharedは、データが少なくとも1つの他のマスタにも存在することを意味します。Cleanは最後にメインメモリからフェッチした時から変更がないことを示し、Dirtyは書込みがあったにも関わらずメインメモリ内のコンテンツが更新されていないことを意味します。各キャッシュラインにストアされているステートは、他のマスタのキャッシュラインと共に構成されるFSMの1要素になります。これに加えて、スヌープのトランザクションタイプが17種類あり、キャッシュがスヌープされているかどうか、スヌープのヒット後にキャッシュが更新されているかどうかなどにより、次の遷移が異なってきます。

機能検証に与える影響

AMBAは、常に高速のプロトコルインタフェースを提供するために進化をしている一方、機能検証における複雑さを増大させます。コヒーレントのキャッシュコントローラが、ステートの遷移、スヌープのトランザクション、応答などを組み合わせたすべての状況を作り得たかを検証することは非常に困難であることは容易に想像ができるでしょう。同時に、オンチップバスの機能検証がSoC検証にとって非常にクリティカルであることも事実です。ここで忘れてはならないのは、各プロセッサ上ではファームウェアやソフトウェアが実行されるということです。

機能検証の戦略を考える際に、以下の3つの要素に分けて検討することが必要になります。

  1. 検証IPを活用する
    オンチップバスの検証に検証IPを使うことは非常に有効ですが、テストプランに対する検証項目やカバレッジを追跡できること、キャッシュコヒーレンシを完全にサポートしていることは重要なポイントです。
  2. テストシナリオに注力できる手法を活用する
    システムレベルでのテストシナリオを容易に作成することを目的としたインテリジェントなテストシナリオの自動化手法を活用することは、今後も複雑化するオンチップバスの検証には欠かせないテクノロジです。
  3. ソフトウェアやファームウェアを用いた検証を実施する
    本来、テストシナリオには、ソフトウェアやファームウェアによるシナリオと深い連携が不可欠です。上記のインテリジェントなテストシナリオに対して、ソフトウェアやファームウェアが連携することが欠かせません。

まとめ

オンチップバスのインターコネクトは、性能や消費電力の課題に応えるべく、進化を続けています。しかし一方で、その機能検証は複雑さを増し、SoC機能検証における大きな割合を占めるようになりました。メンター・グラフィックスは、コヒーレンシ対応の検証IPであるMentor VIP、インテリジェントなテストシナリオを生成可能なQuesta inFact、さらにインテリジェントなソフトウェアドリブン検証手法を提供しています。

ソフトウェアを含むインテリジェントなテスト環境実装例はこちら

今すぐダウンロード