Functional Verification — 명세대로 동작하는 회로인지 확인하기

입력 순서·기대 결과·Assertion·Coverage를 연결해 재현 가능한 검증 범위를 만듭니다.

심화 · 측정과 검증 · 업데이트 2026-10-18

추천 읽기 순서 · 용어사전 · 어디까지 알아야 하나요? · 관련 직무

논리 회로의 원리 다음에는 명세를 확인합니다

기능 검증은 Design Specification(요구 동작)에 맞게 설계가 동작하는지 확인하는 과정입니다. RTL(Register Transfer Level)은 레지스터 간 데이터 이동과 논리를 표현하는 수준입니다. Simulation은 모델을 실행해 입력에 대한 반응을 관찰합니다. Testbench는 Stimulus(입력 자극)를 만들고 Expected Result(기대 결과)와 실제 반응을 비교하는 검증 환경입니다.

검사 프로그램을 실행했다는 사실보다 기대 결과를 어떤 명세에서 도출했는지가 중요합니다. 구현 코드와 같은 잘못된 가정을 복사한 비교기는 같은 오류를 놓칠 수 있습니다.

메모리 읽기·쓰기 순서의 가상 사례

교육용 장치 명세를 가정합니다. 요청을 수락한 뒤 읽기 응답 전까지는 새 쓰기를 수락하지 않는 단일 요청 모델입니다. 실제 SRAM·메모리 인터페이스 전체의 규칙이 아닙니다.

단일 읽기·단일 쓰기 테스트는 통과해도 이 순서를 놓칠 수 있습니다. 최소 재현 순서·초기 메모리·Reset·Seed·관측 시점을 남기고, 명세 위반인지 테스트 가정 오류인지 먼저 확인합니다.

Assertion과 Coverage는 서로 다른 질문입니다

Assertion은 “Busy 동안 새 요청을 수락하지 않는다”처럼 지켜야 할 성질을 점검합니다. Functional Coverage는 계획한 시나리오·상태 조합의 실행 여부, Code Coverage는 코드의 문장·분기 등 실행 범위를 봅니다. 분모·측정 정의가 다릅니다. 높은 Code Coverage가 명세 시나리오의 충분함을 보장하지 않으며, 높은 Functional Coverage도 계획에 없는 오류를 배제하지 않습니다.

Corner Case에는 경계 주소·Reset과 요청의 교차·Backpressure 등 명세에 맞는 경계 상황을 포함합니다. 버그 수정 뒤 최소 재현 Test와 유사 조건을 Regression Test에 추가하고, 수정으로 다른 시나리오가 깨지지 않는지 확인합니다. 검증 담당자는 파형·로그·Assertion 실패·Coverage의 빈 곳을 설계자와 함께 해석합니다. 실제 조직·도구는 회사별로 다릅니다.

Timing·Validation과의 경계

Functional Verification은 논리 기능, Static Timing Analysis는 지연 모델과 제약을 바탕으로 시간 조건을 분석합니다. RTL 기능 시뮬레이션 합격이 실제 속도를 보장하지 않습니다. Verification은 명세 준수, Validation은 의도한 사용 요구 충족을 확인한다는 구분이 유용하지만 조직·개발 단계마다 용례가 달라 정의를 먼저 합의합니다.

교육용 실습: 2-bit 레지스터의 읽기·쓰기 검증

기업 RTL이 아닌 자체 교육용 명세입니다. 소프트웨어 상태 모델로 명세→Test Case→Expected/Actual→재현→Regression 과정을 연습합니다. 실제 HDL 시뮬레이션·Timing 검증·CDC 검증을 대체하지 않습니다.

Specification을 먼저 고정합니다

Reset을 올리기만 하고 Clock 상승 에지가 없으면 즉시 초기화되지 않는 동기식 명세입니다. X/Z 입력·메타안정성·전원 투입 동작·Setup/Hold 위반은 이 모델에 정의하지 않았습니다. 그런 상황의 기대 결과를 임의로 00이나 Hold라고 확정하지 않습니다.

Test Sequence: 기대 결과부터 적습니다

각 행은 직전 행의 상태에서 이어집니다. 값은 2진수 두 자리입니다. 아래 Actual은 Write가 Reset보다 우선하는 결함을 일부러 넣은 가상 구현의 결과입니다.

첫 실패는 T4입니다. T5는 새 쓰기를 수락한 오류가 아니라 이전 오류 상태를 유지한 결과입니다. 최소 재현은 정상 Reset→0이 아닌 값 준비→rst=1·we=1의 상승 에지입니다. T4의 Expected를 구현 코드에서 다시 계산하면 같은 우선순위 오류를 비교기에도 복제할 수 있으므로 명세에서 독립적으로 예상값을 작성합니다.

Testbench를 작은 Python 상태 모델로 실행합니다

아래 코드를 Python 3에서 실행하면 의도한 실패 [4, 5]와 수정 후 실패 []를 출력합니다. 외부 패키지가 필요 없습니다. rising=0은 “상승 에지가 없는 관측 구간”이며 아날로그 Clock 파형을 모델링하지 않습니다.

# 순서: rising, rst, we, d, expected (d/expected는 십진수 0~3)
tests = [
    (1, 1, 0, 0, 0),
    (1, 0, 1, 1, 1),
    (1, 0, 0, 2, 1),
    (1, 0, 1, 3, 3),
    (1, 1, 1, 2, 0),
    (0, 0, 1, 3, 0),
    (1, 0, 1, 2, 2),
    (1, 0, 0, 0, 2),
    (1, 1, 0, 0, 0),
]

def dut(q, rising, rst, we, d, fixed):
    if not rising:
        return q
    if fixed:
        if rst:
            return 0
        if we:
            return d
    else:  # 의도적으로 잘못된 우선순위
        if we:
            return d
        if rst:
            return 0
    return q

def run(fixed):
    q = None  # Reset 전 기대 상태를 추정하지 않음
    failures = []
    for index, (rising, rst, we, d, expected) in enumerate(tests):
        q = dut(q, rising, rst, we, d, fixed)
        if q != expected:  # 명세에서 수기로 정한 예상값과 비교
            failures.append(index)
    return failures

assert run(False) == [4, 5]
assert run(True) == []
print("의도한 결함의 실패:", run(False))
print("수정 후 실패:", run(True))

Stimulus는 각 행의 입력·순서, Expected Result는 독립 예상값, Actual Result는 모델 출력입니다. Testbench는 입력 공급·상태 실행·비교·로그를 묶습니다. 위 두 assert는 예제가 의도한 실패와 수정 결과를 검증합니다. 실제 검증의 Assertion은 “Reset 상승 에지 후 rd=00”, “쓰기 금지 시 상태 유지”처럼 명세 성질을 자동 점검할 수 있습니다. 표의 우선순위·관측 시점을 Assertion에도 일치시켜야 합니다.

Functional Coverage와 빠진 Test Case

우리는 Reset 단독, Write, Hold, Reset+Write 충돌과 비상승 구간을 계획했습니다. 해당 다섯 종류를 실행했다고 “이 계획의 범주를 방문했다”고 말할 수 있지만 전체 RTL 검증 100%는 아닙니다. 직접 00 쓰기, 각 이전 값×다음 값의 전이, rst/we 교차, 데이터 변경·Clock 순서, Reset만 높고 상승 에지가 없는 경우 등을 추가해보세요. 명세에 없는 X/Z·Timing 동작은 먼저 요구사항을 확장해야 검증할 수 있습니다.

T4를 회귀에서 빼면 단독 쓰기·Reset만으로 우선순위 오류를 놓칠 수 있습니다. 수정 뒤 최소 재현과 기존 Test를 모두 반복하는 Regression은 이런 재발과 다른 기능의 손상을 찾는 데 필요합니다. 예상 결과·입력 순서·초기화·구현 버전·실패 시점은 함께 보존합니다.

학생 확인 질문과 해설

• 기능 검증과 Timing 검증은? → 명세의 논리 동작과 실제/모델 시간 제약은 다릅니다. 이 Python 실습에는 실제 지연이 없습니다.
• Expected와 Actual이 다르면? → 먼저 명세·초기화·관측 시점·테스트 입력을 고정하고 검증기 오류와 설계 오류를 나눕니다.
• Test Case가 많으면 끝인가? → 중복 Test 수보다 요구사항·상태·전이·순서·경계의 누락을 확인해야 합니다.
• Regression이 중요한 이유는? → 수정한 실패를 재현 가능한 Test로 남기고 기존 동작이 유지되는지 반복 확인하기 위해서입니다.

교육용 면접 연습: Functional Coverage가 높아도 계획에 없는 요구사항·상태 조합이나 잘못된 Expected가 남을 수 있습니다. Coverage의 분모와 명세 추적을 설명해보세요. 실제 출제 기록은 아닙니다.

CMOS → Logic Gate → Timing을 선수 학습으로 읽고 회로설계 로드맵에서 다음 단계를 정하세요.

학생들이 자주 하는 오해

Coverage 100%는 오류 0개의 증명이 아닙니다. 같은 코드가 실행돼도 데이터·순서·명세의 빈 곳이 남을 수 있습니다. 위 사례의 수락 규칙을 모든 실제 메모리에 적용하지 않습니다.

선수 학습과 다음 공부

CMOS Logic Gate — NAND·NOR부터 조합논리까지 · Timing 기초: Setup·Hold와 시간 여유 · SRAM Cell과 Sense Amplifier — 작은 전압 차이를 읽는 원리 · Signal Integrity와 Timing 검증 — 신호가 전달될 때 발생하는 문제

교육용 예상 면접 질문

공개 참고 자료

확인: 2026-10-18. 공개 원리와 자체 작성한 교육용 가상 상황·질문을 구분합니다. 자료별 적용 범위는 아래와 같으며 특정 회사의 업무·조건이 모두 같다는 뜻은 아닙니다.

• Siemens · Debug and Functional Coverage: 시뮬레이션·Testbench·Assertion·회귀와 디버그.
• Siemens · Coverage and Assertion: Code/Functional Coverage의 구분. 검색 색인으로 확인.