𝗥𝗘𝗦𝗘𝗧 │ reset을 푸는 순간에도 timing check가 있습니다

시뮬레이션에서는 정상인데, 보드 전원을 켤 때만 상태 머신의 첫 사이클이 가끔 어긋납니다. 데이터 경로의 setup/hold는 통과했습니다. 그렇다면 asynchronous reset이 언제 해제됐는지부터 확인해 볼 만합니다.

active-low asynchronous reset인 rst_n을 예로 들겠습니다. rst_n=0이면 clock을 기다리지 않고 FF가 reset 상태로 들어갑니다. 반대로 rst_n이 1로 올라가는 순간이 FF의 clock edge에 너무 가까우면, 그 FF가 이번 edge부터 동작해야 하는지 다음 edge부터 동작해야 하는지가 불안정해질 수 있습니다. 여기서 보는 검사가 recovery와 removal입니다.

FF의 local clock pin에 rising edge가 10.0 ns에 도착한다고 가정해 보죠. 이 예시 cell의 recovery가 0.8 ns, removal이 0.4 ns라면, reset 해제 신호는 늦어도 9.2 ns, 아니면 그 edge가 지난 뒤 빨라도 10.4 ns에 도착해야 합니다. 9.5 ns에 오면 recovery가 0.3 ns 부족하고, 10.2 ns에 오면 removal이 0.2 ns 부족합니다. 숫자는 설명용이며 실제 값은 cell과 corner, clock/reset 경로에 따라 달라집니다.

이 검사는 data pin의 setup/hold와 닮았지만 endpoint가 다릅니다. reset의 해제 edge가 FF의 asynchronous clear/preset pin에 도착하는 시각을 clock pin의 active edge와 비교합니다. AMD의 timing report에서도 recovery는 setup 계열, removal은 hold 계열에 들어갑니다. 그래서 WNS/WHS 숫자만 훑지 말고 reset 경로의 check 종류와 실제 제약 적용 범위를 확인해야 합니다.

설계에서는 reset을 비동기로 걸어야 하는 요구가 있더라도, 해제는 각 clock domain에 맞춰 동기화하는 구조를 씁니다. 그리고 synchronizer를 넣었다는 이유로 검토를 끝내지 않습니다. 동기화된 reset이 실제 leaf FF의 reset pin까지 가는 경로, fanout과 해제 순서도 봐야 합니다. 같은 domain에 독립적인 reset synchronizer를 여럿 두면 블록마다 서로 다른 cycle에 reset을 벗어날 수 있다는 점도 AMD UG906이 경고합니다.

리뷰 때는 세 가지만 묻겠습니다. “이 reset은 어느 clock domain의 FF를 풀어 주나?”, “해제 경로의 recovery/removal이 보고되고 있나?”, “서로 의존하는 블록들이 같은 해제 계약을 공유하나?” Reset은 값 하나를 0으로 만드는 신호이면서, 동시에 언제 동작을 다시 시작할지 정하는 제어 경로입니다.

근거: AMD Vivado UG949/UG906 (2026.1).

https://docs.amd.com/r/en-US/ug949-vivado-design-methodology/Synchronous-Reset-vs.-Asynchronous-Reset
https://docs.amd.com/r/en-US/ug949-vivado-design-methodology/Understanding-Timing-Reports
https://docs.amd.com/r/en-US/ug906-vivado-design-analysis/Asynchronous-Reset-Synchronizer