RTL 통합 검토와 확장 계획

인터페이스에서 먼저 정할 것

캡스톤을 RTL로 옮길 때는 배열 본체와 작업 래퍼의 책임을 나눕니다. 배열 본체는 등록된 A·B 전달, signed MAC, valid·태그와 전역 advance를 담당합니다. 래퍼는 작업 시작·clear, 행렬 크기, 공간 타일 좌표, 입력 공급과 스큐, 결과 저장 마스크, 출력 valid/ready를 담당합니다. 각 책임을 실제 신호 이름과 에지 계약으로 적으면 '배열이 돌아가는데 결과가 가끔 틀린다'는 모호한 문제를 줄일 수 있습니다.

기본 순서는 IDLE→CLEAR→RUN→COLLECT→SEND입니다. CLEAR는 첫 데이터 에지보다 앞에 하나의 초기화 에지를 보장합니다. RUN은 t=0..K+2N−3의 논리 에지에서 스케줄을 진행합니다. 마지막 RUN 에지 직후 배열 결과가 완성되므로 COLLECT가 다음 에지에 결과 버퍼로 복사합니다. SEND는 수신자가 준비된 에지에서 결과를 전송합니다. 상태 전환과 출력 관측 기준을 정하면 마지막 MAC과 결과 복사를 같은 에지에서 수행해 이전 acc를 읽는 오류를 막습니다.

예제로 통합 지연 계산하기

N=K=2에서 clear를 E−1, 계산을 E0..E3으로 실행합니다. E4에서 네 결과를 병렬 결과 버퍼에 복사한다고 별도 가정합니다. 출력 포트가 결과 한 개씩 보내고 ready가 항상 1이면 E5,E6,E7,E8에서 [[19,22],[43,50]]의 네 값을 행 우선 순서로 전송합니다. clear부터 마지막 전송까지 E−1..E8의 10개 상승 에지입니다. 계산만의 4개 에지와 구간이 다릅니다. output ready 대기는 SEND 에지만 늘리며 이미 계산된 결과를 바꾸지 않습니다.

한 결과의 payload에는 job, 전역 행·열, raw 또는 quantized 값인지의 표시를 포함하거나 인터페이스 계약으로 고정합니다. clear 전에 수신자가 모든 결과를 받았는지 또는 결과 버퍼에 안전하게 복사했는지 확인합니다. 배열 acc를 먼저 지우면 아직 전달하지 않은 값이 없어집니다. 결과 버퍼를 추가하면 배열의 다음 작업과 SEND를 겹칠 수 있지만, 버퍼 소유권과 job 분리를 검증해야 합니다.

확장마다 다시 확인할 계약

곱셈기에 파이프라인을 넣으면 누산기 갱신·태그·완료의 상대 지연이 바뀝니다. 링크만 한 에지라고 해서 k+i+j에서 결과가 바로 갱신되지는 않습니다. K축 타일링은 부분합 보존과 폭을 다시 정해야 합니다. 여러 job을 겹치면 누산기 상태와 결과 버퍼를 job별로 분리해야 합니다. FIFO를 추가하면 데이터·valid·태그를 하나의 payload로 저장하고 overflow·underflow를 검사합니다. 제어 코드를 추가한 것만으로 기존 지연 공식이 유지된다고 가정하지 않습니다.

실제 공개 설계에서 스크래치패드와 데이터 이동이 중요하다는 참고로 Gemmini 아키텍처 문서를 볼 수 있습니다. 이 단원의 상태기계와 예제는 학습용으로 직접 정한 계약입니다. 상용 가속기와의 성능 동등성이나 특정 제품 기능을 주장하지 않습니다.

제출 체크

최종 검토 자료에는 고정된 N·K·W·F 범위, signed 폭 계산, 경계 스케줄 한 표, 완료 정의, pause/reset 정책, 출력 전송 순서와 점수판 로그를 포함합니다. Node 예제 통과는 수치·시간 참조의 증거입니다. RTL 시뮬레이터에서 같은 fixture를 통과한 경우에만 RTL 시뮬레이션 통과를 추가하고, 합성·타이밍·도구 통합은 각각 실제 명령과 로그가 있을 때 기록합니다. 이 구분은 결과를 과장하지 않으면서 다음 구현 단계에서 재사용 가능한 정확한 기준을 남깁니다.