---
title: "동작 중 reset 테스트: 취소한 요청의 정답도 함께 정리해야 한다"
author: "브레이브브라우저쓰자"
published_at: "2026-10-18T12:25:03.359Z"
updated_at: "2026-10-06T01:01:25.553Z"
tags: ["동작 중 reset 테스트"]
canonical_url: "https://ariser.io/@writer_a9817d5a8de0/%EB%8F%99%EC%9E%91-%EC%A4%91-reset-%ED%85%8C%EC%8A%A4%ED%8A%B8-%EC%B7%A8%EC%86%8C%ED%95%9C-%EC%9A%94%EC%B2%AD%EC%9D%98-%EC%A0%95%EB%8B%B5%EB%8F%84-%ED%95%A8%EA%BB%98-%EC%A0%95%EB%A6%AC%ED%95%B4%EC%95%BC-%ED%95%9C%EB%8B%A4"
ai_assisted: true
---

# 동작 중 reset 테스트: 취소한 요청의 정답도 함께 정리해야 한다

이 글은 AI가 활용됐습니다.

[원문](https://ariser.io/@writer_a9817d5a8de0/%EB%8F%99%EC%9E%91-%EC%A4%91-reset-%ED%85%8C%EC%8A%A4%ED%8A%B8-%EC%B7%A8%EC%86%8C%ED%95%9C-%EC%9A%94%EC%B2%AD%EC%9D%98-%EC%A0%95%EB%8B%B5%EB%8F%84-%ED%95%A8%EA%BB%98-%EC%A0%95%EB%A6%AC%ED%95%B4%EC%95%BC-%ED%95%9C%EB%8B%A4)

초기 reset을 통과한 계산 모듈이 테스트 도중 reset을 만나자, 회로는 새 요청을 처리하는데 비교기는 이전 응답을 계속 기다린다. 반대 상황도 가능하다. 비교기를 깨끗하게 지웠더니 회로에서 잘못 살아남은 응답까지 정상처럼 받아들인다. 진행 중 reset은 레지스터의 초기값만 보는 시험으로 충분하지 않다.

동작 중 reset 테스트는 그 경계에서 어떤 일을 취소하고 어떤 상태를 유지하는지 확인한다. DUT뿐 아니라 자극과 관측, 참조 모델도 같은 계약을 따라야 한다.

## 초기화는 이미 진행 중인 일을 건드린다

가상의 요청·응답 계산 모듈을 생각하자. reset은 아직 완료하지 않은 모든 요청을 취소하며, 해제 뒤에는 취소된 요청의 응답을 내보내지 않는다고 정한다. reset 동안 새 요청은 수락하지 않고, 해제 후 지정한 준비 조건을 만족하면 다시 수락한다. 이는 예제의 계약이며 모든 버스나 장치의 공통 규칙은 아니다.

reset 전에 ID 2와 ID 7의 요청이 수락되었고 아직 응답하지 않았다고 하자. 참조 모델에는 `{2:44, 7:88}`이 남아 있다. 여기서 reset이 들어오면 회로의 작업 큐와 함께 이 두 기대 응답도 취소해야 한다. 그대로 남겨 두면 정상적으로 취소한 요청을 누락 오류로 보고한다.

| 시점 | DUT에 요구하는 동작 | 검증 환경이 기록할 일 |
|---|---|---|
| reset 전 | 2와 7을 처리 중 | 두 기대 응답 보관 |
| reset 진입 | 미완료 작업 취소 | 해당 기대 응답을 취소 기록으로 이동 |
| reset 중 | 새 수락 없음 | 입력 수락과 출력 규칙 검사 |
| 해제 후 준비 완료 | 새 요청 처리 가능 | 새 기대 응답만 등록 |

취소를 기록으로 남기면 왜 응답이 없는지 설명할 수 있다. 정답 큐를 조용히 비워 버리면 정말 reset으로 취소한 것인지, 테스트벤치가 임의로 놓친 것인지 구별하기 어렵다.

## reset이 driver를 멈추게 하는 방식도 맞아야 한다

driver가 ready를 기다리던 순간 reset이 들어오면, 대기 중인 item을 어떻게 끝낼지 정해야 한다. 취소를 sequence에 알릴지, 해제 뒤 같은 요청을 다시 보낼지, 별도 오류 완료로 처리할지는 환경과 계약에 따른다. 단순히 driver task를 죽이면 sequence가 item 완료를 영원히 기다리는 문제가 생길 수 있다.

OpenTitan의 `cip_base_vseq`는 자극과 랜덤 reset을 병렬로 실행하는 실제 코드를 제공한다. 이 구현은 설정에 따라 outstanding CSR 접근이 없는지를 확인하고, reset이 진행 중인 sequence를 중단시키는 과정의 동기화를 별도로 다룬다. 코드 주석도 요청을 구동하는 task가 죽으면 완료하지 못한 접근 때문에 상태가 어긋날 수 있음을 설명한다. [OpenTitan, run_seq_with_rand_reset_vseq](https://github.com/lowRISC/opentitan/blob/master/hw/dv/sv/cip_lib/seq_lib/cip_base_vseq.sv)

이 근거는 ‘모든 환경에서 아무 순간이나 reset해도 된다’는 뜻이 아니다. 해당 환경의 설정과 지원 범위 안에서 reset을 발행하고, 지원하는 진행 중 접근을 정리해야 한다는 사례다. 실제 DUT가 그런 reset을 허용한다면 그 상황을 시험하고, 허용하지 않는다면 제약의 이유를 명세에서 확인해야 한다.

monitor도 reset 경계를 알아야 한다. reset 진입 edge와 전송 edge가 겹치면 어느 동작이 우선하는지 계약에 따라 판정한다. reset 동안 보이는 valid를 무조건 정상 응답으로 기록하거나, 해제 직후 모든 출력을 무조건 무시하는 방식은 각각 오검출과 누락을 만들 수 있다.

## 새 요청과 이전 요청을 혼동하지 않는다

reset 해제 뒤 ID 2를 다시 사용하고 이번 정답은 99라고 하자. 올바른 결과는 새 요청의 99다. 취소된 요청의 44가 뒤늦게 나오면 오류다. 같은 ID를 사용하더라도 reset 전후의 요청은 다른 작업이다.

로그에 reset 때마다 증가하는 epoch를 붙이면 `{epoch, ID}`로 기대 기록과 취소 기록을 관리하기 쉽다. 그러나 이 epoch가 실제 응답 신호에 실리지 않는다면, 그것만으로 응답의 출처를 완벽히 알아낼 수는 없다. ID가 같고 결과까지 같은 경우 오래된 응답을 새 응답으로 착각할 수 있다.

따라서 reset 동안과 새 요청 전의 출력 규칙을 검사하고, 재사용 시험에서는 이전과 다른 데이터도 선택한다. 필요하면 외부 응답 경로를 비우는 절차나 프로토콜이 제공하는 식별 규칙을 함께 따른다. 테스트벤치의 표식은 관측 정보를 정리할 뿐, 회로에 없는 구분 정보를 만들어 내지 않는다.

## 유지되는 상태는 지우지 않는다

reset이 모든 상태를 지운다고 가정해서도 안 된다. retention 상태, 외부 메모리에 이미 반영된 쓰기, reset 대상 밖의 장치는 유지될 수 있다. 미완료 요청 취소와 완료한 작업의 효과 제거는 서로 다른 요구다. 모델을 모두 초기화하면 유지되어야 할 데이터를 잘못된 기준으로 검사한다.

반면 일부 프로토콜은 reset 전에 요청을 모두 끝내야 하거나, 취소 대신 오류 응답으로 마무리하도록 정한다. 그 경우 기대 응답을 삭제하는 앞의 정책은 맞지 않는다. 입력·출력·참조 상태 각각의 reset 의미를 문장으로 적은 뒤 구현해야 한다.

시험 위치도 초기 유휴 상태에만 머물지 않도록 한다. 요청을 제시하고 아직 수락하지 않은 때, 수락 후 응답 전, 응답이 기다리는 때는 서로 다른 상태다. reset 해제 뒤 새 작업까지 정상 완료하는지 확인하면 중단과 복구를 함께 볼 수 있다. 물리적인 reset 해제 타이밍과 도메인별 동기화는 별도 요구이며, 기능 모델만으로 그 안전성을 증명하는 것은 아니다.

동작 중 reset 테스트가 묻는 것은 ‘초기값으로 돌아왔는가’보다 넓다. 취소한 작업은 다시 나오지 않고, 유지할 효과는 남으며, 새 작업은 끝까지 진행되어야 한다. 이 경계의 계약을 DUT와 driver, monitor, 참조 모델에 똑같이 적용해야 정상 취소와 실제 응답 누락을 구별할 수 있다.