半導体のTape-out後、最も苦痛なバグの一つはこのような形である。
Function simulationも完璧、Silicon Bring-upでもほとんど正常、しかし"たまに"異常動作をする教授の前で再現しようとすると、またうまく動作する ....再現性が低く、デバッグログも薄暗い。
- "どこかでタイミングが崩れた。"
- その"どこか"がClock/Resetのようなglobal controlであることが多い。
- 特にClockをMUXに変更するポイントで非常に薄いパルス(Glitch)が飛び出す
Clock pathでのGlitchはdata glitchとはレベルが違います。データパスのグリッチは、通常、コンビネーションロジック内で消費されます。
一方、クロックグリッチは、フリップフロップに"追加のクロックエッジ"として認識され、その瞬間から、1回の異常エッジがシステム状態全体を歪めることができます。そこで登場するのが、Glitch-Free Clock MUX(GFCM)です。
1) 一般的なMultiplexer（MUX）でGlitchが発生する理由
最も単純な2：1 MUXの論理式は簡単です。
out = (~S & A) | (S & B)RTL では、sel が 0→1 になると、すぐに A から B に変わるように見えます。
- (~S & A)経路と(S & B)経路は互いに異なる cell delay / wire delay を持ちます.
- Sのsignal propagationが2つの経路に同時に到着しません.
- その短い隙間にOR入力の組み合わせが一瞬変化し、しばらくの間信号のswitchingが発生します。(static hazard / dynamic hazard)
Clock MUXでは、A, Bは通常asynchronous clocksである。AとBの位相関係が固定されていないため、sel遷移が「悪い瞬間」にかかる確率は想像以上に高く、結果として「時々」失敗するシリコンバグになります。
2) Clock Glitchが必要な理由
- Pulse widthが短くてもFFがクロックとして認識できる
クロックツリーのslew/threshold、ライブラリFFの内部パルスフィルタリングにより、"不要なエッジ"が有効に入ることがあります。 - Setup/Holdを同時に壊しやすい
正常なエッジの直前にGlitchが入るとHoldが壊れ、直後に入るとSetupが壊れます。どちらにしても結果はランダムです。 - DVFS/Fail-over/Power domain時代には、Clock switchingは日常です
- 。
3) Glitch-Free의 핵심 정의:"Glitch 0"ではなく"遷移条件を封印"
Glitch-Free Clock MUXの核心は簡単です。
blockquote>出力クロックを変更している間は、クロックエッジを通過させない
選択信号(Enable)は、クロックの安定した区間でのみ変更されます
GFCMは「シームレスに接続する回路」ではなく、多くの場合、一時停止(pause)を利用する回路です
つまり、グリッチフリーと引き換えに1～2サイクルが失われる可能性があります。 "シームレス"なスイッチングが目標であれば、MUXだけを変えてはいけないし、PLL/clocking architectureレベルでアプローチする必要があります。
4) 가장 널리 쓰이는 구조(정석):"Mutual-Exclusion + Safe-Window Update"
Glitchが前のclockと完全に近い場合、Timing violationが起こります。
なので、このようなGlitchが出ないように、しばらくclock toggleをしばらくしないロジックが必要です。
앞부분과 뒷부분을 보면 MUX랑 같은 구조인데,
- 내부에 2단 Synchronizer 있고,
- SELECT signal 바뀔 때 반대쪽 clock에 동기화시키는 feedback loop가 있습니다.
最終的に以下のような機能をします。
この"停止"がまさにGlitch-Freeのコストと安定性です
ElectronicspediaチャンネルにGlitchの非常に良い例があり、添付しました。height="113" src="https://www.youtube.com/embed/KBeumQxSyZA?feature=oembed" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture；web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen="" title="グリッチフリークロックマックス｜クロックマックス｜VLSI｜グリッチフリーマックスとは｜GFCM｜回路">
5) 波形で見る "Glitch vs Glitch-Free" (コアのみ)5) 波形で見る "Glitch vs Glitch-Free"
(1) naive MUX (Glitch発生可能)
図に説明されているように、
Selが0の時はCLK1を出力し、
Selが1の時はCLK2を出力します。
CLK Outの点線のように飛び出している、Designerが望まなかったclock toggleをglitchと呼びます.
6) SDCとCDCの解析では?
Clock MUX出力は「CLK1でもCLK2でもある」。そのため、output pinに対してgenerated clockを2つ重ねて定義するパターンが一般的です。 そして、2つのgenerated clockが同時にアクティブになることができないことをexclusiveで知らせます。
- GFCM内部のsync FFはCDCの性質です。 そのため、CDC tool(SpyGlass-CDCなど)で機能的な安全性を別に確認します。
7) CTS/PnR 인사이트:GFCMは"論理ブロック"ではなく"Clock Rootデバイス"
GFCMは配置一つで品質が変わります。
- Clock source(PLL/OSC)の近くに配置する: MUX前後のクロックネットが長くなると、SI/EM/IR-dropの影響が大きくなり、スキュー管理が難しくなります。
- Select/controlはdataではなくcontrol: fanoutが大きくなると、グリッチフリー構造は「遷移遅延」を増加させます。このようなパスにset_case_analysisを与えた後、Gate level simulationで非常に大きなViolationが見つかる場合があります。
- CTS との役割分離: GFCM の出力以降が本当の clock tree です。
- Duty cycle / pulse integrity: 単純な AND/OR gating は duty distortion を作ることができます。RTL で GFCM を作成するよりも、Foundry-qualified cell を使用することをお勧めします。
要約すると、
GFCM はクロックアーキテクチャの一部として扱われ、PnR の「保護対象」です。
8) DFx(Scan/ATPG/Bring-up) 관점:GFCMは"テストの扉"
スキャンでは、通常、シフトクロックとキャプチャクロックの要求が異なり、at-speedテストはより厳しいです。ここでGFCMが間違って設計されると、DFxがこのように壊れます。
- test modeでclock switchingが許可されず、scanが止まる
- capture区間でpauseが発生し、patternが崩れる
- reset/test_en切り替え時にglitchが発生し、誤動作する
なので、実務のパターンはだいたいこのような感じです。
- test_enでtest_clkを直接bypass (上記のRTLのように)
- または、scan専用のclock muxを別に置いて、function clock muxと分離
- このようなGlitch Free Clock Muxだけを作る専門家もいます！
- Glitch-Free Clock MUXを「グリッチフリークロックMUX」とだけ説明すると薄っぺらい。
現代のSoCでは、GFCMはDVFS/Fail-over/Power domain/DFxを貫通するclocking infrastructureです。 - この小さなブロックが設計の成熟度を表します。
- 学生の設計は「RTLが正しいかどうか」、
- ジュニアの設計は「STAが通るかどうか」、
- シニアの設計は「量産可能かどうか」です
- 。
