파이프라인 해저드(Pipeline Hazard)

    파이프라인 성능을 저해하는 파이프라인 해저드의 개요

    파이프파인 해저드의 개념

    - 파이프라인 프로세서에서 명령어 의존성(데이터, 컨트롤, 자원)을 발생 시킬 수 있는 문제

    - 파이프라인의 성능을 저해하는 요인, CPI(명령어당 실행 클럭 수)가 1이 되는 것을 방해하는 요소

    ※ CPI(Cycles Per Instruction) : CPU가 한 개의 명령어를 처리하는데 소요되는 평균 사이클 수

     

    파이프라인 해저드의 3가지 종류

    구조적 해저드

    - 하드웨어가 여러 명령들의 수행을 지원하지 않기 때문에 발생, 자원충돌(Resource Conflicts)

     

    데이터 해저드

    - 명령의 값이 현재 파이프라인에서 수행 중인 이전 명령의 값에 종속

    - RAW, WAR, WAW 해저드가 존재

     

    제어 해저드

    - 분기(jump나 brunch 등) 명령어에 의해서 발생 (분기를 결정하는 시점에 잘못된 명령이 파이프라인에 있을 경우 발생)

     

     

    파이프라인 해저드의 원인과 해결 방법

    구조적 해저드 (Structural Hazard)

    - 자원충돌 : H/W가 여러 명령들의 수행을 지원하지 않기 때문에 발생

    - 폰노이만 구조 : 프로세서의 구조적인 문제로 인해서 명령어 실행 불가

    - 프로세서가 하나의 Write Port를 가지는 경우에 아래와 같은 문제 발생

    구조적 해저드의 원인

     

    해결방안

    구조적 해저드의 해결방안

     

    - 충분한 자원을 확보

    - 하버드 아키텍처 : 데이터/명령 메모리의 구분

    - 해당 기능을 사용할 수 있을 때까지 지연(Pipeline stall, bubble)

     

     

    데이터 해저드 (Data Hazard)

    - 앞에서 실행된 명령어의 결과가 다음 명령어에 사용되어 발생하는 문제

    데이터 해저드 원인

    - RAW(Read After Write), WAW(Write After Write), WAR(Write After Read), RAR(Read After Read)의 4가지 데이터 의존성이 있지만 RAR은 문제가 없음

     

    구분 내용 예시
    RAW (Read After Write) - 이전 명령이 저장한 연산 결과를 후속 명령이 읽으려고 할 때 ADD R1, R2, R3
    ADD R4, R1, R5
    WAR (Write After Read) - 이전 명령이 값을 읽기 전에 후속 명령이 값을 쓰는 경우
    - 단일 파이프라인에서는 발생하지 않음
    ADD R1, R2, R3
    SUB  R2, R4, R1
    or R1, R6, R3
    WAW (Write After Write) - 이전 명령이 값을 쓰기 전에 후속 명령이 값을 쓰는 경우 ADD R1, R2, R3
    SUB R2, R4, R1
    or R1, R6, R3

     

    해결방안

    해결방안 설명
    Hardware interlocks - 현재사용중인 오퍼랜드가 기존에 사용 중인지 탐지한 후 필요에 따라 오퍼레이션 연산을 지연시켜주는 방법
    Operand forwarding - 레지스터 파일에 반영되기 전에 수행(EX) 단계에서 계산된 결과를 다음 인스트럭션의 수행단계로 전달하는 방법
    Delayed load - 컴파일러 수준에서 데이터 해저드를 발견하고 인스트럭션의 재정렬 및 필요 시 지연시키도록 no-operation 명령어를 삽입하는 방법
    Register Renaming - 원래 레지스터가 아닌 다른 레지스터에 할당해 사용
    WAR, WAW의 경우에 사용

     

    제어 해저드(Control Hazard)

     

     

    - 분기 명령어에 의해서 발생, 분기가 결정된 시점에 수행되지 않을 명령이 파이프라인에 존재

     

    해결방안

    해결방안 설명
    Stall 현재사용중인 오퍼랜드가 기존에 사용 중인지 탐지한 후 필요에 따라 오퍼레이션 연산을 지연시켜주는 방법
    Predict Branch Not Taken: 다음명령어 무조건 수행, taken시 명령어 취소
    Taken: 53%의 분기명령이 Taken, 타겟주소 계산을 위해 1사이클 분기 손실이 필요
    Fast Branches 분기결과를 ID(Instruction Decode) 단계에서 수행함
    Branch target buffer 메모리에 기존 분기문의 결과를 기록하여 분기문 발견 시 확인
    Loop buffer BTB의 확장으로 레지스터를 이용하여 loop발견시 정보를 기록/확인
    Branch Prediction 분기문 수행 전에 분기문을 예측하여 사용률 낭비를 줄임
    Delayed branch 컴파일러가 분기문을 발견 후 delay-slot no-op나 분기문과 관련 없이 수행되는 명령을 추가하도록 프로그램의 순서를 재배치함

     

    파이프라인 해저드 발생을 줄이기 위한 고려사항

    응용 프로그램 제작 시

    - 수행하고자 하는 응용 프로그램의 특성을 고려하여 해저드 해결 필요, 단순 반복적인 과학 연산의 경우 루프(Loop) 코드가 많으므로 분기를 항상 참으로 가정하여 예측 시 비용 대비 효과적, 반대로 분기 구조가 복잡한 코드에서는 복잡한 동적 분기 예측 기법 필요

     

    프로세스 제작 시

    - VLIW와 Super Scalar의 경우 파이프라인 해저드에 대한 발생 유형 및 해결책에 따라 달라질 수 있으므로 사용 할 프로세서의 특성을 고려하여 원인과 해결책 제시 필요

     

    연관 포스팅

    효율적인 명령어 처리, 명령어 파이프라인(instruction Pipeline)

    댓글

    Designed by JB FACTORY