인프런 커뮤니티 질문&답변

안녕하세요, 답변 남겨드립니다.

음 일단 제가 디버깅을 직접 못하는 상황이라서 추측되는 가능성에 대해서 설명드려볼게요.

지금 상황은 오히려 정상에 가깝습니다. 같은 sv 파일과 sdc를 써도 Quartus에서 negative slack이 반드시 재현되지는 않습니다. 강의 흐름 자체도 먼저 SDC 작성과 합성을 보고, 그 다음 단계에서 Fast/Slow corner와 slack, Fmax, false path를 따로 확인하도록 이어져 있어서, 실습 5-1에서 바로 violation이 안 보이는 경우가 충분히 나올 수 있어요. 커리큘럼상으로도 5-1은 SDC 작성과 합성, 5-2는 slack과 Fmax 확인 및 STA 심화로 분리되어 있습니다.

왜 이런 차이가 생기냐면, 실제로는 device 선택, speed grade, Quartus 버전, fitter seed, synthesis 최적화 결과, 그리고 가장 크게는 clock period 설정값 차이 때문에 경로 지연이 달라지기 때문입니다. 아주 작은 RTL에서는 툴이 논리를 잘 줄여버려서, 강의 화면에서는 겨우 임계경로였던 부분이 본인 환경에서는 1 ns 이상 여유가 남는 경우도 흔합니다. 실무에서도 slack = required time - arrival time 이고, setup 관점에서는 대략 slack_setup = Tclk - (Tcq + Tcomb + Tsetup + skew + uncertainty) 형태로 보는데, 여기서 Tclk를 조금만 빡빡하게 잡아도 바로 음수로 넘어갑니다.

학습 목적이라면 가장 안전한 방법은 RTL을 크게 망가뜨리지 말고 SDC에서 clock period를 단계적으로 줄여보는 것입니다. 예를 들어 지금 sdc에 create_clock -period 20.000 같은 식으로 되어 있다면 10.000 ns, 5.000 ns, 3.333 ns, 2.500 ns 순서로 줄여보세요. 100 MHz 조건에서는 통과하던 회로가 200 MHz, 300 MHz로 올라가면 어느 순간 setup slack이 0 ns 아래로 내려갑니다. 이 방식이 좋은 이유는 기능은 그대로 두고 timing만 의도적으로 빡빡하게 만들어서, 나중에 timing closure를 연습하기에 가장 깔끔하기 때문입니다.

실제로는 Fmax를 먼저 보는 게 감이 잘 옵니다. 예를 들어 현재 설계의 Fmax가 185 MHz 정도라면, clock period를 5.4 ns보다 작게 주는 순간 setup violation이 생길 가능성이 높습니다. 계산으로 쓰면 Ttarget < Tcritical 일 때 negative slack이 나는 구조라서, report에서 Fmax를 본 뒤 period = 1000 / Fmax(MHz) 보다 10~20% 더 공격적으로 주면 재현 확률이 높아져요. 예를 들어 Fmax가 160 MHz면 임계 주기는 약 6.25 ns이고, 여기에 5.5 ns나 5.0 ns를 걸면 slack이 음수로 나올 가능성이 커집니다.

한 번 더 짚고 가면, false path나 multicycle path가 들어가 있으면 원래 느린 경로가 timing 체크 대상에서 빠져서 negative slack이 안 보일 수 있습니다. 실습 단계에서는 false path를 최소화한 상태에서 먼저 pure setup violation을 보는 편이 훨씬 공부가 잘 됩니다. 이 부분도 커리큘럼에서 SDC 작성 실무와 false path 설정, 그리고 이후 slack/Fmax 확인으로 이어지게 배치된 이유가 여기에 있어요.

정말로 “해결하는 과정”까지 연습하고 싶다면, 일부러 violation을 만든 뒤 해결은 두 갈래로 접근하시면 됩니다. 첫 번째는 제약을 완화하는 방식입니다. 예를 들어 4.0 ns에서 slack = -0.8 ns가 나왔다면 5.0 ns로 완화해서 통과시키는 것이고, 이건 사실상 사양을 낮추는 셈이라 실무에서는 마지막 카드에 가깝습니다. 두 번째는 RTL을 개선하는 방식인데, 이게 진짜 timing closure 연습에 가깝습니다. AXI-Lite 같은 블록이라면 주소 decode, read data mux, register map selection, write strobes 처리 쪽이 임계경로가 되기 쉬우니, 조건문 깊이를 줄이거나, 큰 조합논리를 2단으로 쪼개거나, 중간에 register를 하나 더 넣는 식으로 Tcomb를 20~50% 줄여보는 연습이 효과적입니다. 파이프라인을 1 stage 추가하면 latency는 1 cycle 늘지만, setup margin이 1 ns 이상 좋아지는 경우가 꽤 많아요.

다만 여기서 유지보수 관점도 같이 보셔야 합니다. timing만 맞추겠다고 AXI-Lite 응답 경로에 레지스터를 무턱대고 넣으면 read/write handshake 타이밍이 바뀌어서 testbench가 깨질 수 있습니다. 특히 ARVALID/ARREADY 이후 RVALID 생성 시점, AW/W 채널 정렬 방식, BVALID 응답 타이밍은 프로토콜 기대치와 연결되기 때문에, 성능 개선 전에 기능 시뮬레이션을 다시 돌려야 합니다. 현업에서는 timing 1건 잡겠다고 protocol bug 1건 새로 만드는 일이 더 치명적이라서, QoR만 보지 않고 기능 회귀까지 같이 묶어 봅니다.

가장 추천드리는 실습 순서는 이렇습니다. 현재 프로젝트를 하나 복사해서 원본은 보존하시고, 복사본에서 create_clock period만 줄여가며 최초로 slack < 0 이 되는 지점을 찾으세요. 그 다음 report_timing에서 worst path의 from/to register를 확인하고, 해당 always_ff 사이의 조합논리 깊이를 보시면 됩니다. 이후 if-else 체인을 case 구조로 단순화하거나, decode 결과를 미리 한 사이클 앞에서 만들어 두거나, mux fan-in을 줄이는 방식으로 수정한 뒤 다시 compile해 보시면, 같은 constraint에서 slack이 -0.6 ns에서 +0.2 ns로 넘어가는 식의 변화가 보일 가능성이 높습니다. 이 과정이 실무 timing closure의 축소판이라고 보시면 됩니다.

혹시 바로 써보실 수 있게 아주 단순한 예를 하나 드리면, sdc에서 create_clock -name clk -period 10.000 [get_ports clk] 라고 되어 있다면 5.000으로 먼저 바꿔 보시고, 여전히 통과하면 3.000까지 낮춰 보세요. 보통 소형 교육용 RTL은 10 ns에서는 너무 느슨하고, 3~5 ns 구간에서 경계가 드러나는 경우가 많습니다. 그 상태에서 report_timing summary와 Fmax summary를 같이 보시면 setup violation 연습이 훨씬 선명해집니다.

정리해서 말씀드리면, negative slack이 안 나오는 건 파일을 잘못 쓴 게 아니라 현재 환경에서 설계가 constraint를 만족했기 때문일 가능성이 높습니다. 강의 커리큘럼도 SDC 작성과 slack 분석, timing closure를 순차적으로 다루는 구조라서 자연스러운 흐름이고요. 먼저 clock period를 단계적으로 줄여서 violation을 의도적으로 만든 뒤, 그 다음에 조합논리 깊이 축소나 파이프라이닝으로 복구하는 방식으로 가시면 원하시는 “slack 해결까지의 전체 흐름”을 가장 제대로 체험하실 수 있습니다.

안녕하세요, 인프런 AI 인턴입니다. ghgh73082님.

Quartus에서 Timing Constraint를 적용한 후 타이밍 분석 결과에서 negative slack이 발생하지 않아 해결 과정을 연습해 보고 싶으신 상황으로 이해했습니다. Negative slack이 발생하지 않는다는 것은 종종 문제가 없다는 의미로 긍정적으로 볼 수 있지만, 학습 목적으로 일부러 slack을 만들어서 해결 과정을 경험하고자 하는 의도가 있으신 것 같습니다. 다음은 이를 시도해 볼 수 있는 몇 가지 방법입니다:

1. 인위적으로 타이밍 제약 강화하기

• 클럭 주기 단축: 현재 설정된 클럭 주기를 줄여 더 빠르게 신호가 전달되도록 요구하십시오. 예를 들어, 기존 클럭 주기가 10ns라면 이를 8ns로 줄여보는 것입니다.
  

  create_clock -period 8.0 [get_ports {clk}]

• 경로 지연 추가: 특정 신호 경로에 인위적인 지연 요소를 추가하여 타이밍 여유를 줄여볼 수 있습니다. 이는 RTL 코드 내에서 register 간 연결을 추가하거나, 기존 경로에 추가적인 로직을 삽입함으로써 달성할 수 있습니다.
  

2. 제약 조건 강화하기

• Input/Output Delay 조정: 포트의 입력 및 출력 지연을 변경해보세요.
  

  set_input_delay -clock clk 4.0 [get_ports {data_in}]
  set_output_delay -clock clk 3.0 [get_ports {data_out}]

3. 소프트웨어 시뮬레이션 및 변동 실험

• 타이밍 분석의 다른 시나리오를 시험하기 위해 여러 버전의 입력 데이터를 생성하거나, 메모리 속도 및 대역폭 관련 제약을 조정해볼 수 있습니다.
  

관련된 참고 자료

• Timing Constraints in Quartus
  

이러한 방법들로 인위적인 negative slack을 발생시킨 뒤 이를 개선하는 과정을 경험해 보실 수 있습니다. 추가적인 궁금한 점이 있으시면 이어서 질문해 주세요. 저는 질문자님의 이해를 돕고자 관련 정보를 제공하고 있으며, 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏

추가적인 피드백이 필요한 경우, 지식공유자께서는 새로운 관점에서 정보를 제공해 주실 것입니다.