두 명령어가 같은 사이클에 하나의 실행 자원을 요구합니다. 구조적 해저드는 데이터 해저드와 어떻게 다르고 어떤 설계로 줄이나요?

구조적 해저드는 같은 사이클에 하나뿐인 하드웨어 자원을 동시에 요구해서 생기고, 데이터 해저드는 값이나 순서가 아직 준비되지 않아 생깁니다. 두 명령어의 피연산자가 서로 독립이어도 단일 포트 메모리를 공유하면 충돌할 수 있습니다. 예를 들어 5단계 모델에서 사이클 4에 이전 명령어의 MEM과 뒤 명령어의 IF가 동시에 메모리 포트를 요구한다면, 한 요청을 사이클 5로 미루어 bubble을 넣어야 합니다. 이것은 add 결과를 다음 sub가 기다리는 RAW와 원인이 다릅니다.

해결책은 자원 복제, 포트 분리, 사용 시점 조정, stall입니다. instruction cache와 data cache를 분리하면 IF와 MEM이 각 포트를 사용할 수 있습니다. 단일 메모리 포트를 유지하면 arbitration이 한 요청을 선택하고 다른 명령어의 valid를 유지한 채 다음 cycle로 보냅니다. 실행 유닛을 두 개로 늘리는 방식도 있지만, 두 명령어가 동시에 결과를 만들면 register file의 write port나 공용 writeback bus가 다시 한계가 됩니다. 그러므로 “ALU를 늘리면 해결된다”는 답은 자원 그래프의 다음 병목을 놓칩니다.

판단할 때는 cycle별 점유표를 먼저 작성합니다. 예를 들어 cycle 4에 IF=I3, MEM=I1, EX=I2라면 단일 메모리 포트 모델에서는 IF 또는 MEM 중 하나를 표시하고, 분리 포트 모델에서는 둘을 동시에 허용합니다. 분리 포트의 이득은 해당 충돌의 bubble을 줄이는 것이지만 면적, 배선, 전력, 검증 경우의 수를 늘립니다. register-file read port가 두 개 필요한 경우와 세 개 필요한 경우도 같은 방식으로 세어야 합니다. 구조적 stall과 RAW stall을 따로 계수해야 최적화가 실제 병목을 겨냥했는지 확인할 수 있습니다. 정확한 포트 수와 arbitration은 대상 CPU 문서 없이는 일반화하지 않습니다.