BRAM의 Read / Write를 다 수행했는지 확인할 때 사용되는 num_cnt / i_num_cnt 관련 질문

Question

안녕하십니까 Matbi님 너무 잘 학습하고 있습니다.   [의문사항] [1번] Matbi님이 작성하신 코드처럼   num_cnt를 reg로 선언하고 always block으로 num_cnt <= i_num_cnt를 하게 되면   clk소모에 따른 delay도 발생하고 HW resource도 사용한다는 단점이 있는거라고 생각하는데 맞을까요?   [2번] 1번이 맞다면 단점 외에 장점이 있기 때문에 저렇게 작성하신걸까요? 어떤 장점이 있는걸까요?   [3번] 아래처럼 기술해도 되는걸까요? // 기존 코드 assign is_read_done = o_read && (addr_cnt_read == num_cnt-1); // reg와 always 구문 없이 // input wire로 입력되는 i_num_cnt를 그대로 사용하는 경우 assign is_read_done = o_read && (addr_cnt_read == i_num_cnt-1);   항상 감사합니다!!!

semisgdh · Answer

안녕하세요!! 추석연휴라서 답변이 조금 밀렸네요 ㅠ 질문 요지는 “왜 i_num_cnt를 바로 쓰지 않고 레지스터 num_cnt에 캡처하느냐” 로 이해했습니다. 결론부터 말하면, 비교 기준을 트랜잭션 단위로 고정 하고 타이밍을 안정화 하려는 의도입니다. 항목별로 답드리겠습니다. 맞습니다. num_cnt를 레지스터로 두면 플립플롭 자원이 들고, i_run에 캡처되는 시점만큼 한 사이클의 지연이 생깁니다. 다만 이 비용은 보통 폭만큼의 FF(예: AWIDTH비트)라서 매우 작고, 시스템 타이밍 측면에선 이득이 더 큽니다. 장점은 세 가지가 핵심입니다. 원자성 보장 : i_num_cnt가 트랜잭션 도중 바뀌어도, 캡처된 num_cnt는 끝날 때까지 값이 고정됩니다. done 비교 기준이 흔들리지 않습니다. 타이밍/글리치 차단 : 상위 로직의 조합 경로가 길거나 글리치가 있어도 FF에서 한번 끊어 주므로 비교 경로가 짧고 깨끗해집니다(타이밍 클로저 유리). 리셋·상태 경계 명확화 : 코드처럼 o_done에서 0으로 클리어하면 트랜잭션 경계가 분명해집니다. 차기 트랜잭션 시작 전에 기준값이 남아있어 생기는 스파이크를 예방합니다. addr_cnt_read == i_num_cnt-1 로 바로 비교해도 합성은 됩니다. 다만 권하지 않습니다. 이유는 트랜잭션 중 i_num_cnt가 변하면 완료 펄스가 앞당겨지거나 사라질 수 있습니다. 상위에서 오는 조합경로가 길어지면 크리티컬 패스가 그쪽으로 누수됩니다. i_num_cnt==0 일 때 i_num_cnt-1 은 언더플로로 전비트 1이 되어 오동작 위험이 큽니다(레지스터도 마찬가지라서 보통 i_num_cnt>0 전제·assert나 가드 로직을 둡니다). 정리하면, num_cnt를 레지스터로 캡처하는 건 “리소스 소모 대비 안정성/재현성/타이밍 이득”이 확실합니다. 실무에선 입력을 그대로 쓰기보다 트랜잭션 시작에 캡처해서 쓰는 패턴을 기본으로 가져가시면 안전합니다. 필요하면 i_run 과 o_done 사이의 경계에서만 업데이트되도록 한 사이클 더 파이프라이닝하는 것도 좋습니다. 즐공하세요!