Cộng đồng Hỏi & Đáp của Inflearn
câu hỏi đã được viết
BRAM의 Read / Write를 다 수행했는지 확인할 때 사용되는 num_cnt / i_num_cnt 관련 질문
Viết
·
90
1
안녕하십니까 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);
항상 감사합니다!!!
Câu trả lời 1
0
안녕하세요!!
추석연휴라서 답변이 조금 밀렸네요 ㅠ
질문 요지는 “왜 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 사이의 경계에서만 업데이트되도록 한 사이클 더 파이프라이닝하는 것도 좋습니다.
즐공하세요!