DFT March Algorithm? Checkerboard 2

5. Memory 구조 관점에서 March가 직관적으로 보이는 이유

5.1 Access 방식

SRAM 한 bank를 떠올려보면:

• Address bus로 특정 row(wordline)를 선택
• 그 row에 연결된 bitline을 통해 cell의 값을 읽거나 쓴다
• 한 번에 “한 address”만 확실하게 control 가능

그래서 test의 기본 단위는 자연스럽게 이렇게 된다.

“주소 하나 선택 → read/write 시퀀스 수행 → 다음 주소로 이동”

이 흐름 자체가 March element 정의와 거의 1:1로 겹친다.

5.2 Address decoder fault를 어떻게 잡는가?

예를 들어, 어떤 address에서:

• Decoder fault로 인해 두 개의 row가 동시에 켜진다고 하자.
• 이 address에 w1을 하면, 의도한 cell뿐 아니라 이웃 row의 cell도 같이 1이 될 수 있다.

이제 다른 address에서:

• 그 이웃 cell을 r0한다고 기대했는데 1이 읽힌다.

March C-처럼 up/down으로 여러 번 왕복하면서 r0, r1을 반복하면
“의도하지 않은 cell이 함께 켜져서 덮어쓴 값”을 어느 시점엔 반드시 읽어보게 된다.

이게 March C-가 Address decoder fault를 검출하는 메커니즘이다.

5.3 Coupling fault를 어떻게 잡는가?

Coupling fault는 다음과 같은 상황이다.

aggressor cell에 특정 연산(write, toggle)을 했을 때
neighbor cell(victim)의 값이 바뀌거나 유지되지 않는 fault

March C-는:

• 어떤 cell에 w1을 한 직후
• 그 이웃 cell을 r0 또는 r1로 확인하는 패턴을
• up/down 방향을 바꾸어가며 여러 번 반복한다.

이 과정에서:

• “이웃 cell의 패턴이 특정 상태일 때만 드러나는 fault”를 찾기 위해
• 다양한 relative ordering을 강제로 만들어 놓는 셈이다.

단순히 Checkerboard pattern 한 번만 write/read 하는 것보다
시간은 조금 더 쓰지만 훨씬 높은 fault coverage를 얻는다.

6. Checkerboard Background와 March Algorithm

이제 실무에서 자주 듣는 Checkerboard를 끼워서 보자.

6.1 Checkerboard pattern이란?

한 줄 정의부터 하자.

Checkerboard pattern = memory cell들이
01010101… / 10101010…처럼
서로 이웃한 cell끼리 값이 항상 반대가 되도록 만든 data background.

비트 기준으로 보면:

• 패턴 A: 0x55... (…0101 0101)
• 패턴 B: 0xAA... (…1010 1010)

주소 기준으로는 보통:

• 짝수 address → 0x5555_5555
• 홀수 address → 0xAAAA_AAAA

혹은 그 반대로 설정해서,
가로(비트 방향) / 세로(주소 방향) 모두에서 0과 1이 체스판처럼 번갈아 나오게 만든다.

이와 반대되는 패턴을 Inverse-checkerboard라고 부른다.

6.2 왜 굳이 Checkerboard를 쓰는가? (All-0/All-1이면 안 되나?)

All-0, All-1 패턴도 당연히 중요하다.

• w0 → r0, w1 → r1만 해도 Stuck-at fault는 잘 잡힌다.
• Transition fault도 어느 정도 커버된다.

문제는 이웃 cell 간 상호작용이다.

• bitline/wordline 간 short/bridge
• Coupling fault
• Neighborhood pattern sensitive fault (NPSF)

이런 fault는 아래와 같은 상황에서만 드러나는 경우가 많다.

• 두 cell이 서로 다른 값(0/1)을 가지고 있을 때
• 주변이 특정 pattern (예: 010/101)일 때

예를 들어, 두 cell이 약하게 short 되어 있다면:

• 둘 다 0이면 short가 있어도 0이어서 티가 안 날 수 있고
• 하나는 0, 다른 하나는 1일 때만 전류가 흐르면서 값이 뒤틀릴 수 있다.

그래서 test 입장에서는:

“이웃한 cell들이 항상 서로 반대 값”인 상황을 만들어서
bitline / cell / wordline 사이의 간섭을 최대한 자극하고 싶다.

그걸 가장 간단하게 만들어주는 것이 Checkerboard pattern이다.

6.3 Checkerboard와 March의 관계

여기서 헷갈리기 쉬운 포인트가 있다.

• March algorithm =
  ↑, ↓ + (r0, w1, r1, w0 …) 같은 연산 시퀀스
• Checkerboard =
  그 연산 시퀀스를 실행할 때의 data background

즉, 구조를 이렇게 보면 편하다.

1. Data background를 solid 0 / solid 1 / checkerboard / inverse-checkerboard 중 하나로 세팅
2. 그 상태에서 March algorithm sequence 실행

예를 들어:

• Step 1: memory 전체를 Checkerboard로 채운다.
• Step 2: 그 상태에서 March C-의 ↑(rX, wY) element를 수행한다.
• 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
  • 필요시 짧은 checkerboard sequence 추가
• Automotive / 서버급 SoC:
  • March C- @ solid 0/1
  • March C- @ checkerboard / inverse-checkerboard
  • 추가로 March SS, NPSF-oriented algorithm까지 얹어 진단 커버리지 목표를 맞춘다.

7. MBIST 관점에서 March / Checkerboard는 언제, 어떻게 결정되는가?

이제 마지막으로,
“이 Test vector/algorithm은 설계 플로우에서 언제 정해지냐?”를 정리해보자.
여기서 March algorithm과 ATPG vector를 헷갈리지 않는 게 중요하다.

7.1 Algorithm 선택 기준

현업에서 알고리즘을 고르는 과정은 보통 이렇게 요약할 수 있다.

Test requirement + Memory 특성 + Test time(ATE 비용) + Tool/Library 기본값

1. 제품 성격
   • Consumer electronics SoC → “적당한 품질 + 짧은 test time”
   • Automotive / Safety-critical → “매우 높은 신뢰성 + 더 긴 test time 감수”
2. 목표 DPPM/PPM, 표준 요구사항
   • ISO 26262 진단 커버리지
   • Foundry / 고객 coverage guideline
3. Memory 특성
   • Single-port / Dual-port / Multi-port SRAM
   • Register 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 macro는 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 엔지니어가 기억해두면 좋은 포인트

정리해보면, DFT/ATPG 엔지니어 입장에서 아래 정도만 머리에 들어 있으면 쓸모가 많다.

1. Logic test와 Memory test는 철학부터 다르다.
   • Logic: scan + ATPG, gate-level fault 중심
   • Memory: address 단위 sequential access, cell/neighbor/decoder fault 중심
2. March algorithm은 “address를 행진시키며 read/write 시퀀스를 반복하는 test”다.
   • 방향(↑/↓) + 연산(r0/r1/w0/w1) 조합이 핵심
3. 기본 개념은 March X로 잡고, 실제 실무는 March C-를 기준으로 본다.
4. Checkerboard는 Algorithm이 아니라 Background다.
   • March C- @ solid 0/1로 cell 자체를,
   • March C- @ checkerboard/inverse-checkerboard로 neighbor-interaction까지 보는 구조라고 이해하면 된다.
5. Algorithm 선택은 MBIST 삽입 단계에서 툴 옵션으로 결정된다.
   • 논문 읽고 예쁜 March 골라서 나중에 vector 만들 때 얹는 게 아니라,
   • DFT architecture / MBIST insertion 시점에 test requirement, memory 특성, test time을 보고 정해진다.

이 정도를 알고 있으면,
칩 설계 회의에서 DFT 팀을 어떻게 컨트롤해야 할 지 감이오고, MBIST spec이나 foundry guideline을 읽을 때도 훨씬 편해진다.

그리고 나중에 자기만의 custom March + background를 설계해야 할 순간이 오더라도,
지금 정리한 이 프레임이 좋은 출발점이 될 거다.