이 예시는 버스트 범위와 캐시 라인이 같습니다
32바이트 캐시 라인과 8바이트씩 4회 전송하는 WRAP 버스트를 가정합니다. 요청 주소가 0x1018이면 전송 주소는 0x1018, 0x1000, 0x1008, 0x1010 순서입니다. 요청한 데이터가 라인 앞쪽 데이터보다 먼저 옵니다.
이 관계는 버스트 전체 바이트 범위가 캐시 라인과 정확히 일치하도록 구성한 예시의 전제입니다. AXI가 모든 캐시의 라인 크기를 알고 그 끝에서 자동으로 돌아간다는 뜻은 아닙니다.
WRAP 규약과 CPU 전달 경로가 모두 필요합니다
Arm IHI0022H의 AXI WRAP 길이는 2·4·8·16회이며 시작 주소는 한 전송의 바이트 크기에 정렬됩니다. 랩 범위는 전송당 바이트 수와 전송 횟수의 곱으로 정해집니다. 인터커넥트·컨트롤러의 지원과 변환 동작도 확인합니다.
필요한 단어를 먼저 받아도 캐시가 전체 라인 완료까지 기다리면 CPU는 일찍 재개하지 못합니다. 돌아온 단어를 CPU에 직접 전달하고 아직 채우지 않은 부분을 유효한 데이터로 오인하지 않게 관리하는 경로가 필요합니다.
실행을 먼저 재개했다고 전체 속도가 빨라지는 것은 아닙니다
ZipCPU의 2025년 명령 fetch 사례는 라인 뒤쪽으로 분기한 뒤 필요한 단어를 먼저 전달하는 원리를 설명합니다. 남은 충전이 공유 버스를 계속 점유하면 뒤따르는 데이터 접근은 다시 기다릴 수 있습니다.
해당 글의 성능 이득은 당시 정량화되지 않았고 데이터 캐시 변경도 미완성이었습니다. 대상 시스템에서 첫 단어 지연, 라인 완료, 프로그램 실행시간과 자원 비용을 따로 측정하기 전에는 보편적인 향상률을 주장하지 않습니다.
- 요청 단어
0x1018 먼저 전달
- 라인 충전
0x1000 → 0x1008 → 0x1010
- 전체 실행
후속 버스 경합까지 측정