1. 株式会社PALTEK
  2. TECHブログ
  3. 技術情報
  4. RDC – リセットドメイン・クロッシングと呼ばれる新たな設計上の注意点とその検証(Design and Verification LANDSCAPE 2023-Vol1)

TECHブログ

RDC – リセットドメイン・クロッシングと呼ばれる新たな設計上の注意点とその検証(Design and Verification LANDSCAPE 2023-Vol1)

RDC – リセットドメイン・クロッシングと呼ばれる新たな設計上の注意点とその検証(Design and Verification LANDSCAPE 2023-Vol1)

目次

はじめに

RDCはReset Domain Crossingを略したものである。1つのリセットドメインから他のリセットドメインへ渡るという意味があり、CDCが1つのクロックドメインから他のクロックドメインへ渡るのに類似する。RDCにはCDCと同じように、メタスタビリティの問題を引き起こす可能性のある設計上のリスクがある。RDCでは異なる非同期リセットドメイン間で発生する問題を扱い、いかに問題を回避し、設計の正しい機能を保証するかに関する設計上の対策、そしてその対策の有効性を検証するメソドロジを扱う。

非同期リセットドメイン・クロッシングの基本的な回路構成図。rst1とrst2の異なるリセットドメインを持つDFFが接続されている様子を示す

図1. 非同期リセットドメイン・クロッシング

基本的には図1.において赤い線で示されたrst1 → dff1.q → dff2.dから構成されるRDCパスが問題を引き起こさないかについて確認する必要がある。このパスが引き起こす可能性のある問題は、実は過去から存在している。最近の設計トレンドを見るならば、チップ内にはプロセッサコアやDSPコア、AIアクセラレータなどに加え、実に多くのIPがオンチップバスに直接接続され、またバスブリッジを介して接続される傾向にあり、検証項目として重要視されるようになった。異なるリセットスキームを持つ複数のコアやIPが同じチップ内で使われるようになり、すべてのRDCパスを目視確認することが困難になっている。そしてRDCはCDCと同じように非同期関係にある複数のリセットによりメタスタビリティを発生させ予測不可能な動作を引き起こしたり、信号のリコンバージェンスの問題を引き起こしたりする可能性がある。そしてCDCと同じように、通常のシミュレーションでは検証することができない。

RDCメタスタビリティ発生のメカニズム

非同期リセットドメイン・クロッシングにおいて、どのような仕組みでメタスタビリティ状態に陥るのか、非同期リセットそのものは問題ではなく、あくまでも複数の非同期リセットを含むデザインにおいて、異なる非同期リセットドメインにおける信号の変化により、メタスタビリティ発生のシナリオとなる。図1.および図2.を使って説明する。

図1.において、dff1レジスタとdff2レジスタは同一のクロックドメイン内にあるが、リセットはrst1とrst2という異なる非同期のリセットドメインにある。rst1とrst2は非同期リセットであり、独立してアサートされる。

非同期リセットドメインにおけるメタスタビリティ発生のタイミングチャート。rst1のアサートによりdff1.qが変化し、dff2でメタスタビリティが発生するシーケンスを示す

図2. 非同期リセットドメインにおけるメタスタビリティ発生シナリオ

図2.においてrst2がアサートされていない状態でrst1がアサートされると、dff1レジスタはリセットされ、dff1.qが非同期イベントを生成し、これが組合せロジックを通過する遅延後にdff2レジスタにサンプリングされる。その際にclkとdff2.dの間でタイミング違反が発生するとメタスタビリティ状態となり、予測不可能な状態が後段へと伝搬することになる。このようにRDCにおけるメタスタビリティは、同じクロックドメイン内にあるレジスタ間であっても発生する可能性があり、非同期リセットによって引き起こされる。

今日のSoCでは、複数のサプライヤから提供される多数のIPで構成されている。複数のIPブロックをSoCへと統合する際には、それぞれが異なるクロッキングとリセットのスキームを持つ設計に対応する必要がある。SoCが多機能化すればするほど、独立したリセットのスキームが数多く存在することになる。またASICにおいて低消費電力で稼働し、高いエネルギー効率が求められる設計では、非同期リセットを多用し、また設計の一部をパワードメインとして動的にアップ/ダウンする設計においては、UPFから生成される隠れたリセットネットワークも存在する。リセットネットワークを積極的に最適化することによってRDCのリスクが高まることは明白で、その対策を講じる事、さらにはその対策が有効であることを検証することが喫緊の課題となっている。

RDCメタスタビリティの発生を抑止する対策

RDCにおいてメタスタビリティの発生を抑止する対策には、いくつかの種類がある。

ここでは上記3つのテクニックについて、順番に解説する。

1. リセットの順序付け

設計の仕様においてはリセットをかける順番を指定することができる。これはリセットオーダリングとも呼ばれる。図3.は図1.と同じ回路構成であり、赤い線で示されるパスはRDCパスである。

RDCパスとリセットオーダリングの回路図。rst2が先にアサートされることでメタスタビリティを防ぐ構成を示す

図3. RDCパスとリセットオーダーリング

この図において、rst1リセットがかかる際には、それよりも先にrst2が常にアサートされていれば、赤い線で示したRDCパスは安全である。dff1レジスタが非同期にリセットされると、dff2に向かって非同期転送の状態となるが、すでにdff2がリセット状態であれば、非同期データをサンプリングすることはない。つまりメタスタビリティの抑止につながる。

2. クロックアイソレーションの制御

一般的に使用されるRDC対策の1つはクロックのアイソレーションを制御する構造である。図4.ではクロックを隔離してしまう構造について示す。

クロックアイソレーション制御によるRDC対策の回路図。isolation_enable信号によりクロックゲーティングを制御する様子を示す

図4. RDC回路とクロックアイソレーション対策

この構造では、rst1によって引き起こされるRDCパス上の非同期イベントが、dff2レジスタによってサンプリングされる前に、isolation_enableを制御してdff2へのクロック供給を止めることで、メタスタビリティ発生を抑止することができる。

3. データアイソレーションの制御

上記「2.クロックアイソレーションの制御」に類似したもう1つの方法がデータアイソレーションの制御である。図5.に示すとおり、データ側、つまりRDCパスそのものを隔離してしまう構造である。

データアイソレーション制御によるRDC対策の回路図。isolation_enable信号によりデータパスを遮断する様子を示す

図5. RDC回路とデータアイソレーション対策

この構造では、dff2が非同期イベントをサンプリングするのを防ぐために、つまりrst1がアサートされるのと同じタイミングがそれ以前にisolation_ebableを制御することでデータパスを隔離し、無効化する。通常はリセットコントローラを配置し、rst1をアサートするタイミングで、それに対応するisolation_enable信号を制御する。

CDC同期化回路を兼ねたRDC対策

これまでの対策は、RDCの非同期イベントをレジスタがサンプリングする際にメタスタビリティが発生することを抑制することが目的である。これに対してCDCでは本質的に非同期のデータ転送が行われるため、メタスタビリティ発生そのものを抑制することはできないが、受信側に同期化回路を挿入し、かつ送信側が転送プロトコルを守ることで、メタスタビリティが発生しても所望の動作が得られることを保証する。

CDCパスは、同時にRDCパスである場合も少なくない。図6.は非同期クロックドメイン転送であり、かつ異なる非同期リセットドメインにあるレジスタ間転送の構造である。赤い線はRDCパスを示す。

CDCとRDCの両方の特性を持つ回路の構成図。非同期クロックドメインと非同期リセットドメインの両方を跨ぐ信号経路を示す

図6. CDCかつRDCの構造を持つ回路

このような構造に対して、動作時においてはCDC転送によるメタスタビリティが発生する可能性があるものの、2段FFの同期化回路によって正しく転送されることが保証される。リセット時においてはrst1とrst2のオーダリングによりメタスタビリティが発生しないことが保証されるが、仮にメタスタビリティが発生したとしても、CDCを目的に挿入された同期化回路によって次のサイクルでは正しくリセット値が伝搬される。

RDC検証

RDC検証を行うためには、まずRDCパスを特定することが必要である。従来は目視確認に頼らざるを得なかったが、複雑なリセット構造や異なるリセットスキームを持つ数多くのIPを統合する設計では、目視確認に限界があることは明白である。RDCパスを自動的に特定するための静的解析が必須となる。

そしてRDC検証はCDC検証と同じく、シミュレーションによって検証することができない。また論理合成後のゲートレベルシミュレーションなど、プロジェクトの後段になってRDCの問題が特定されても、納期遅延や検証のコスト増につながってしまう。このような観点から、RTL設計においてRDCを専用に扱う検証ツールが必要であり、実際に完全に自動化されているツールも出現している。

検証では静的なリセット解析により、構造的、機能的チェックを行う。これにより対象設計で使用されている同期リセットと非同期リセットを把握し、リセットツリーの正当性が検証される。そして設計中のレジスタをリセットするために使用されるリセットドメインの特定、異なるリセットドメインを渡るデータパスの特定、データパスに非同期リセットからのパスが含まれているか、RDCパス上におけるメタスタビリティが抑制できるか、などが検証される。また図3.に示すリセットオーダリングについてはフォーマル解析を活用し、図4.や図5.に示すアイソレーションではゲーティングにグリッチが発生しない事の検証も含まれる。さらにRDC検証はCDC検証との親和性も重要である。図6.に示すようにRDCパスがCDCパスでもあるような場合、CDC解析で同期回路が含まれていることが特定できた場合には、その部分をRDC解析の対象除外とするような連携も求められる。さらにRDC検証の特徴として、異なるリセットスキームを持つ多くのIP間におけるリセットドメインを扱うという背景から、階層型データモデル等を用いた大規模設計への対応は欠かすことができない。

まとめ

今日の設計には数多くの機能ドメイン、数多くのインタフェースが存在し、そこには異なるリセットスキームが実装され、多くの異なるリセットドメインが構成されている。異なるリセットドメインを渡るデータパス上、つまりRDCパス上には、メタスタビリティ発生のリスクがあり、これを抑制するための対策、そしてその対策の有効性を確認する検証が欠かせない。そしてメタスタビリティを扱うような検証はシミュレーションでは実現することができず、従来は目視確認していた項目を自動的に検証する専用の検証ツールの採用が必要である。

参考文献

[1] Why Reset Domain Crossing Verification is an Emerging Requirement to Accelerate Design-to-revenue, Siemens EDA

[2] Design and Verification LANDSCAPE 2020 Vol2

[3] Design and Verification LANDSCAPE 2020 Vol3

「Design and Verification Landscape」技術情報メールニュース

PALTEKでは本ブログ「Design and Verification Landscape」シリーズの技術情報をメールで年に3-4回発信しています。
ご登録いただいた方には、最新の情報をメールニュースとしてお届けします。
ご希望の方はこちらのフォームよりご登録ください。

※競合製品取り扱い企業様の申込については、お断りする場合がありますので予めご了承ください。

 

このブログのシリーズ一覧は下記になります。是非あわせてお読みください。