인코더와 우선순위: 여러 요청 중 하나 고르기

디코더의 반대 방향에도 조건이 필요합니다

디코더^{i디코더 이진 코드에 대응하는 출력 선을 활성화하는 회로입니다. enable이 있으면 비활성일 때 모든 출력을 0으로 만들 수 있습니다. 자세히 보기}는 주소를 원핫^{i원핫 여러 비트 중 정확히 하나만 1인 표현입니다. 모두 0도 허용하는 조건은 one-hot-or-zero로 구별합니다. 자세히 보기} 선택선으로 바꿉니다. 인코더는 활성 입력의 위치를 주소로 바꿉니다. 하지만 일반 원핫 인코더는 입력이 하나만 켜졌다는 가정이 필요합니다. 여러 입력이 동시에 1이면 어느 위치를 보고할지 추가 명세가 있어야 합니다.

4비트 요청 $r_3r_2r_1r_0$에서 번호가 큰 요청을 우선한다고 정하겠습니다. 입력이 모두 0일 때는 valid=0, index=00으로 둡니다. index=00만 보고 요청이 없다고 판단하면 r0의 요청과 혼동됩니다.

표의 -는 0이든 1이든 같은 결과라는 뜻입니다. 시뮬레이션의 X를 입력해도 된다는 뜻은 아닙니다. 각 패턴은 위에서부터 서로 배타적으로 정의되어 있습니다.

1011이면 index=11입니다. 0110이면 r2가 r1보다 우선하므로 index=10입니다.

RTL은 우선순위를 드러내야 합니다

always_comb begin
  valid = |request;
  index = 2'b00;
  if      (request[3]) index = 2'd3;
  else if (request[2]) index = 2'd2;
  else if (request[1]) index = 2'd1;
end

request[0]만 1이면 기본 index=0이고 valid=1입니다. 모든 경로에 기본값을 주어 조합회로에 기억 동작이 생기지 않게 합니다. 입력 16개를 검사하면서 valid=1일 때 선택된 비트가 1인지, 그보다 높은 비트는 모두 0인지 확인하세요.

선택과 공정성은 다른 문제입니다

r3가 계속 1이면 r0는 계속 선택되지 않습니다. 이 회로는 고정 우선순위만 구현합니다. 요청을 공정하게 처리하려면 이전 선택을 기억하는 중재 방식이 필요하며, 그때는 순차회로가 됩니다.

실습 · 요청, 선택 주소, grant를 함께 관찰하기

처음 요청 1011에서는 r3가 선택됩니다. r3를 끄면 r1이 선택되고 index=01, grant=0010이 됩니다. r0를 켜고 꺼도 r1이 1인 동안에는 선택 결과가 바뀌지 않아야 합니다.

‘모두 끄기’를 누른 결과와 r0만 켠 결과를 비교하세요. 두 경우 모두 index=00이지만 valid와 grant가 다릅니다. 후단 회로가 index만 읽으면 없는 요청을 처리할 수 있습니다.

선택된 요청만 1인 grant는 index와 valid를 다시 디코딩한 결과입니다.

검증할 불변식은 세 가지입니다. grant에는 최대 하나의 1만 존재하고, grant가 1인 위치에는 실제 요청이 있으며, 선택된 번호보다 큰 모든 요청은 0입니다. 이 실습은 요청을 소비하거나 이전 선택을 기억하지 않습니다. r3가 계속 켜져 있을 때 낮은 요청이 기다리는 모습은 고정 우선순위의 특성입니다.