23 / 24 · 개념
성능 측정과 설계 검토 마무리
관찰 구간과 정지 원인을 명시하고 기능 모델의 증거 범위를 정리합니다.
내용은 무료로 볼 수 있습니다. 수강 신청하면 학습 기록을 저장할 수 있어요.
숫자와 시간의 계약을 다시 확인한다
완성한 장치는 계산값만 맞으면 끝나는 것이 아닙니다. 원하는 입력 속도를 받을 수 있는지, 상대가 멈췄을 때 손실 없이 기다리는지, 마지막 항목과 reset 경계를 처리하는지 확인해야 합니다. 성능 보고에는 관찰 구간, 수락 입력 수, 전달 출력 수, 입력·출력 정지 횟수와 각 거래 latency를 함께 적습니다. 입력을 제시한 횟수를 처리량으로 보고하면 full 동안 거절된 입력까지 성능에 포함하게 됩니다.
예를 들어 에지 0 직후부터 에지 20 직후까지의 20개 클록 간격 동안 12개를 전달했다면 관찰 처리량은 12/20=0.6거래/사이클입니다. 클록 주기 5ns이면 기간은 100ns이고 120M거래/s입니다. 멈춤 없는 구조의 최대 200M거래/s와 실제 관찰 120M거래/s를 구분합니다. 생산자 입력이 드문지 소비자가 자주 멈추는지에 따라 같은 관찰 처리량이라도 개선 지점이 다릅니다.
개별 latency는 출력의 tag로 수락 에지를 찾아 계산합니다. tag7이 에지 4에 수락되고 에지 11에 전달되면 7사이클, 같은 주기에서 35ns입니다. capstone의 무정지 지연 3사이클보다 네 사이클 길지만 결과 손실은 아닙니다. 평균만 기록하면 일부 거래가 아주 오래 기다리는 현상을 숨길 수 있어 최소·평균·최대 또는 전체 표를 사용합니다. 고정 지연 검사는 정지가 없는 경로에만 적용합니다.
| 관찰 | 가능한 원인 | 다음 확인 |
|---|---|---|
| FIFO가 자주 full | 소비자 또는 뒤 단계가 느림 | output-ready와 단계 valid |
| 출력이 자주 empty | 입력 부족 또는 내부 bubble | 실제 accepted와 단계 이동 |
| 한 단계 ready 경로가 길음 | 많은 버퍼의 조합 ready 연결 | 구현 타이밍 보고 |
| tag 순서가 틀림 | 동반 데이터 정렬 오류 | 단계별 tag·valid 추적 |
깊은 FIFO는 burst를 흡수하지만 정지 이후 기다리는 항목 수와 평균 latency도 늘 수 있습니다. 정상 상태에서 평균 outstanding은 도착률×평균 체류 시간과 관계가 있지만, 시작·종료·취소가 섞인 짧은 관찰에 그 관계를 기계적으로 적용하지 않습니다. 먼저 충분히 긴 안정 구간인지, 누적 수락과 전달이 균형인지 확인해야 합니다. 이번 작은 과정에서는 직접 에지 표로 계산하는 것이 더 명확합니다.
설계 검토에서는 수치 범위, 부호, 축소 지점, valid 이동, full 교체, reset 취소, 메모리 지연과 hazard 정책을 차례로 확인합니다. 합성한 경우에는 실제 레지스터·메모리 자원과 최악 경로를 확인하고 기능 모델과 구분하여 보고합니다. Node 실행 파일 통과는 제공된 정수·순서 모델의 실행 증거입니다. HDL을 실제로 컴파일하지 않았으면 컴파일 검증으로, 배치 후 timing이 없으면 동작 주파수 검증으로 쓰지 않습니다.
후속 확장으로 포화 연산, 연산 코드 전달, 메모리 응답 버퍼 또는 여러 레지스터 의존성을 추가할 수 있습니다. 새 기능마다 먼저 바뀌는 계약을 적고 기대 큐·경계 벡터·취소 회계도 같이 바꾸세요. 데이터패스 확장은 연산자 하나를 더하는 것뿐 아니라 저장·수락·해석의 의미를 유지하는 작업입니다.
직접 생각해 보기
50클록 간격 동안 30개를 전달했고 주기는 4ns입니다. 관찰 처리량을 거래/사이클과 거래/s로 구하세요. tag3의 수락 에지 8, 전달 에지 15라면 latency도 구하세요.
해설 보기
30/50=0.6거래/사이클입니다. 기간 200ns이므로 30/200ns=150M거래/s입니다. tag3 latency는 15-8=7사이클=28ns입니다. 이는 관찰한 값이며 무정지 최대 성능과 별도로 적습니다.