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

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

결론부터 말씀드리면, 지금 에러의 본질은 iff 문법 자체라기보다는 “테스트벤치(.sv)를 Quartus 합성(synthesis)에 넣어서 돌리셨기 때문”인 경우가 대부분입니다. @(posedge clk iff cond) 형태의 iff는 SystemVerilog의 “조건부 이벤트 컨트롤(conditional event control)”로, 시뮬레이터에서는 잘 쓰이지만 합성 툴(특히 Quartus Synthesis)이 지원하는 합성 가능(SystemVerilog synthesizable subset) 문법에 포함되지 않는 경우가 흔합니다. 테스트벤치는 원칙적으로 합성 대상이 아니고, 시뮬레이션 전용으로 ModelSim/Questa 쪽에서 컴파일/실행하셔야 정상입니다.

현업 플로우 관점으로 정리하면, RTL(설계 파일)은 Quartus에 넣어 합성/피팅/타이밍을 보고, TB(검증 파일)는 ModelSim에서만 컴파일해서 파형을 봅니다. 예를 들어 AXI-Lite 검증에서 TB는 드라이버/모니터 성격이라 #delay, wait, fork-join, 조건 이벤트(iff) 같은 “시간/이벤트 기반 시뮬레이션 문법”을 적극 사용합니다. 반대로 합성은 클럭에 동기된 레지스터/조합논리로 하드웨어를 만들기 때문에, TB 문법을 합성기에 넣으면 지금처럼 문법 에러 혹은 합성 불가 경고가 나는 것이 정상에 가깝습니다.

그래도 “Quartus 컴파일이 꼭 돌아가야 한다”는 상황이 있으니, 해결책을 두 갈래로 드리겠습니다. 첫 번째는 가장 권장되는 방법으로, 테스트벤치를 Quartus 합성 대상에서 제외하는 것입니다. Quartus 프로젝트에 TB 파일이 추가되어 있으면, 해당 파일을 “컴파일 제외(Exclude from compilation)” 처리하시거나, 애초에 Quartus에는 RTL만 추가하고 TB는 ModelSim 프로젝트(do 파일)에서만 관리하시는 방식이 안전합니다. 실무에서도 이 방식이 90% 이상 표준입니다. 이렇게 하면 iff를 유지해도 상관없고, 시뮬레이터에서 의도한 대로 파형을 그대로 확인할 수 있습니다.

두 번째는 “문법을 Quartus가 알아먹는 형태로 바꿔서도 동작을 동일하게 만들기”입니다. 지금 코드의 의도는 AXI 핸드셰이크 타이밍을 맞추는 것이고, AXI(-Lite)에서 핸드셰이크는 한 클럭 에지에서 HANDSHAKE = VALID & READY가 1이 되는 순간으로 정의하는 게 일반적입니다. 즉 주소 채널이면 AR_HANDSHAKE = s_axi_arvalid & s_axi_arready, 읽기 데이터 채널이면 R_HANDSHAKE = s_axi_rvalid & s_axi_rready 같은 식입니다. @(posedge clk iff s_axi_arready);는 “s_axi_arready가 1인 클럭 에지까지 기다린다”는 의미인데, Quartus가 iff를 못 받으니 아래처럼 “클럭을 기준으로 루프를 돌면서 조건을 만족할 때까지 대기”로 바꾸시면 됩니다.

예를 들어 주소 핸드셰이크를 정확히 기다리려면 READY만 보지 말고 VALID까지 포함해서 다음처럼 쓰는 편이 더 안전합니다. 왜냐하면 실무에서 READY는 미리 1로 올라와 있는 슬레이브도 많고, 반대로 VALID를 내리는 타이밍과 섞이면 한 사이클 오해가 생기기 쉽기 때문입니다.

// ARVALID를 올린 뒤, ARVALID&ARREADY가 1이 되는 posedge까지 대기
s_axi_arvalid = 1'b1;
do begin
  @(posedge clk);
end while (!(s_axi_arvalid && s_axi_arready));

// 핸드셰이크가 일어난 직후(같은 에지 이후) ARVALID 내림
s_axi_arvalid = 1'b0;

읽기 데이터 채널도 동일하게 바꾸시면 됩니다.

// RVALID&RREADY가 1이 되는 posedge까지 대기
do begin
  @(posedge clk);
end while (!(s_axi_rvalid && s_axi_rready));

만약 원래 코드가 s_axi_rready를 항상 1로 두는 구조라면 조건은 s_axi_rvalid만 봐도 되지만, 현업에서는 마스터가 백프레셔를 주는 케이스(예: RREADY를 0으로 몇 사이클 내렸다가 다시 올리는 케이스)를 검증 항목에 넣는 경우가 많아서, 가능하면 VALID & READY로 기다리는 습관이 버그를 줄입니다. 정량적으로 말씀드리면, 단순 READY만 보고 대기하는 TB는 백프레셔 테스트를 추가하는 순간에 1~2사이클 타이밍 미스가 나서 “가끔씩만 깨지는” 형태의 재현 어려운 버그로 번지는 비율이 체감상 꽤 높습니다.

추가로 한 가지 체크 포인트를 꼭 말씀드리면, 질문에서 “testbench 파일을 synthesis 돌리니”라고 하셨는데, TB를 합성하는 것은 목적 자체가 맞지 않습니다. TB는 하드웨어가 아니라 검증용 소프트웨어(시뮬레이션 프로그램에 가까운 코드)라서, 합성을 통과시키는 방향으로 고치기 시작하면 오히려 검증 품질이 떨어질 가능성이 큽니다. 실무에서는 “합성 통과”가 목표가 아니라 “시뮬레이션에서 프로토콜 위반을 얼마나 많이 잡아내는가”가 목표이고, 그래서 TB 쪽은 합성 친화 문법을 일부러 피하고 시뮬레이션 친화 문법을 적극 씁니다.

정리하면, 가장 좋은 해결은 TB를 Quartus 합성 대상에서 빼고 ModelSim/Questa에서만 돌리시는 것이고, 부득이하게 Quartus 컴파일 에러를 없애야 한다면 @(posedge clk iff cond)를 do @(posedge clk); while(!cond); 또는 더 안전하게 while(!(VALID && READY)) @(posedge clk); 형태로 바꾸시면 됩니다.

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

현재 경험하고 계시는 문제는 iff 문법이 Quartus에서는 지원되지 않아서 발생하는 오류입니다. iff는 SystemVerilog의 일부이며, Verilog와는 다르게 보다 고급 이벤트 제어 기능을 제공합니다. 하지만 Quartus에서는 기본 Verilog 문법만 지원하여 이와 같은 오류가 발생합니다.

이를 해결하기 위해서는 iff 구문을 다른 방식으로 대체해야 합니다. @ (posedge clk iff s_axi_arready)와 같은 형식의 조건문을 아래와 같이 변환할 수 있습니다:

@(posedge clk);
if (s_axi_arready) begin
    ...
end

이 방식은 clk 신호의 상승 엣지에서 조건을 검사하여 필요한 로직이 실행될 수 있도록 보장합니다. 이렇게 코드의 논리 흐름을 변화시켜서 iff 문법 의존성을 피해야 합니다.

추가적으로 오류 내용을 더 이해하기 원하시면, Intel FPGA Knowledge Database에서 오류 번호를 검색해 보시면 더욱 다양한 해결책을 찾으실 수 있습니다.

• Verilog HDL 문법 오류 해결 방법 - Inflearn
  

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.