DFTマーチアルゴリズム？チェッカーボード2

5.Memory構造の観点からMarchが直感的に見える理由

5.1 Access方式

SRAM 1バンクを思い浮かべてみると:

figure class="kg-card kg-image-card">

• Address busで特定のrow(wordline)を選択
• そのrowに連結されたbitlineを通じてcellの値を読み書きする
• 一度に"一つのaddress"だけ確実にcontrol可能
  • だからtestの基本単位は自然にこのようになります。
  • この流れ自体がMarch elementの定義とほぼ1:1で重なります。
  • 例えば、あるアドレスで:
    • Decoder faultにより二つの rowが同時に点灯するとします。
    • このアドレスにw1をすると、意図したcellだけでなく、隣のrowのcellも一緒に1になることがあります。
  • 今度は別のアドレスで:
    • その隣のcellをr0と期待したのに1が読み込まれます。
  • March C-のようにup/downを何度も往復しながらr0, r0, r1 を繰り返すと
    "意図していないcellが一緒に点灯して上書きされた値"をある時点で必ず読むことになります。3 Coupling faultをどう捉えるか
  • Coupling faultは次のような状況です。
  • March C-は：
    • あるcellにw1をした直後
    • その隣のcellをr0またはr1で確認するパターンを
    • up/down方向を変えながら何度も繰り返します。
  • この過程で:
    • "隣のcellのパターンが特定の状態である時だけ現れるfault"を探すために
    • 様々なrelative orderingを強制的に作っておくわけです。
  • 単にCheckerboard pattern一度だけwrite/readするより
    時間は少しかかりますが、はるかに高いfault coverageを得ることができます。
  • hr>
  • では、実務でよく聞くCheckerboardを挟んでみましょう。
  • 一行定義から始めましょう。
  • ビットベースで見ると:
    • パターンA: 0x55... (...0101 0101)
    • パターンB: 0xAA... (...1010 1010)
  • アドレス基準では通常:
    • 偶数 address → 0x5555_5555
    • 奇数 address → 0xAAAA_AAAA
  • 또는 그 반대로 설정해서,
    가로(bit direction) / 세로(address direction) 모두에서 0과 1이 체스판처럼 번갈아 나오게 만든다.
  • これと反対のパターンをInverse-checkerboardと呼びます。
  • All-0, All-1パターンも当然重要です。
    • w0 → r0, w1 → r1 だけで、Stuck-at faultはよくキャッチされます。
    • Transition faultもある程度カバーされます。
  • 問題は隣のセル間の相互作用です。
    • bitline/wordline 間 short/bridge
    • Coupling fault
    • Neighborhood pattern sensitive fault (NPSF)
  • このようなfaultは以下のような状況でのみ現れることが多い。
    • 二つのセルが異なる値(0/1)を持っている時
    • 周辺が特定のパターン(例えば、010/101)の時
      • 例えば、二つのセルが弱くshortされている場合:
        • 両方が0であればshortがあっても0なので目立たないことがあり、
        • 一つは0、もう一つは1の時だけ電流が流れて値が歪むことがあります。
      • だから、testの立場では:

6.2 なぜわざわざCheckerboardを使うのか？ (All-0/All-1ではダメなのか？)

Checkerboard pattern = memory cellsが
0101010101... / 10101010... のように
隣り合うcell同士が常に値が反対になるように作った data background.

6.1 Checkerboard patternとは

6. Checkerboard BackgroundとMarch Algorithm

aggressor cellに特定の演算(write, toggle)をした時、
neighbor cell(victim)の値が変わったり、維持されないfault

5.2 Address decoder faultをどのように捉えるか？

"アドレス一つ選択→read/writeシーケンス実行→次のアドレスへ移動"

"隣り合うcellsが常に互いに反対の値"である状況を作って
bitline / cell / wordline間の干渉を最大限刺激したい。3 CheckerboardとMarchの関係

ここで混乱しやすいポイントがあります。March algorithm =
↑, ↓ + (r0, w1, r1, r1, w0 ...) のような 연산 sequenceCheckerboard =
その演算シーケンスを実行するときの data background

つまり、このような構造で考えるとわかりやすい。Data backgroundをsolid 0 / solid 1 / checkerboard / inverse-checkerboardのいずれかに設定しますその状態でMarch algorithm sequenceを実行します

例えば:Step 1: memory全体をCheckerboardで埋めます。Step 2: その状態で March C- の ↑(rX, wY) 要素を実行します。Step 3: Inverse-checkerboard に切り替えて再び March を実行します。

MBISTツールスクリプトでよく見かける構成はこのような感じです。Algorithm: March C-
Background: solid 0/1, checkerboard, inverse-checkerboard

このようにAlgorithm>とBackground>をorthogonalに定義しておき、
組み合わせでfault coverageを引き上げる
実際の製品仕様では、おおよそこのような図になります。

Consumer SoC:March C- @ solid 0/1必要に応じて短いチェッカーボードシーケンスを追加>Automotive / サーバー級SoC：March C- @ solid 0/1March C- @ checkerboard / inverse-checkerboardMarch SS, NPSF-oriented algorithmまで加えて、診断カバレッジの目標を合わせる。7.MBISTの観点からMarch/Checkerboardはいつ、どのように決定されるのか

さて、最後に、
"このTest vector/algorithmは設計フローでいつ決まるのか？"を整理してみましょう。7.1 Algorithm選択基準



現場でアルゴリズムを選択するプロセスは、通常このように要約することができます。Test requirement + Memory characteristic + Test time(ATE cost) + Tool/Library default valueProduct natureConsumer electronics SoC → "moderate quality + short test time"Automotive / Safety-critical → "very high reliability + longer test time 감수"목표 DPPM/PPM、標準要件ISO 26262診断カバレッジFoundry / Customer coverage guidelineMemory 特性Single-port / Dual-port / Multi-port SRAMRegister file, CAM, ROM, eDRAM, eFlashなどbitcell構造, redundancy, ECCの有無はい：eFlash/eFuse/NVMはprogram/erase/retention testを含むMulti-port SRAMはport interaction faultのためにport間read/writeの組み合わせを入れたMarch変種を使用

実務ではMemory compiler / IP vendorが推奨March setを一緒に与える場合が多い。"このSRAMマクロはMarch C- + Checkerboard基準でfault coverage XX%達成"



DFTエンジニアはこれを基に会社の標準/顧客の要求に合うかどうか確認不足する場合はMarch elementをもう一つ載せたり、backgroundを追加するようにカスタマイズします。さらに、多くの会社では、BU/会社レベルで標準MBISTアルゴリズムセットを運営しています。例)March C- + March LA + Checkerboard新しいプロジェクトのDFTエンジニアはこれをデフォルトで使用し、
特殊なmemory(eFlash、特殊SRAMなど)だけを別々にチューニングします。実際には個々のエンジニアがMarch algorithmを完全にゼロから設計するケースは多くなく、
標準テンプレート+若干のカスタマイズが現実に近いです。まとめると、DFT/ATPGエンジニアの立場で、以下のようなことを頭に入れておけば役に立ちます。Logic testとMemory testは哲学から違うLogic: scan + ATPG, gate-level fault中心Memory: address unit sequential access, cell/neighbor/decoder fault中心March algorithmは"addressを行進させながらread/writeシーケンスを繰り返す test"である。方向(↑/↓)+演算(r0/r1/w0/w1)の組み合わせが核心strong>基本概念はMarch Xで、実際の実務はMarch C-を基準CheckerboardはAlgorithmではなくBackgroundです。March C- @ solid 0/1でcell自体を、March C- @ checkerboard/inverse-checkerboardでneighbor-interactionまで見る構造と理解すればいいAlgorithm選択はMBIST挿入段階でツールオプションで決定されます。論文を読んできれいなMarchを選んで後でvectorを作る時に載せるのではなく、DFT architecture / MBIST insertionの時点でtest requirement, memory characteristic, test timeを見て決まる。この程度を知っていれば、
チップ設計会議でDFTチームをどのようにコントロールすべきか感触が来て、MBIST specやfoundry guidelineを読む時もずっと楽になります.そして、後で自分だけのcustom March + backgroundを設計しなければならない瞬間が来ても、
今まとめたこのフレームが良い出発点になるでしょう.。

요약:DFT/ATPGエンジニアが覚えておくと良いポイント