function automatic과 표현식의 재사용

계산을 재사용해도 계약은 드러내야 합니다

SystemVerilog 함수는 시뮬레이션 시간을 소비하지 않고 값을 반환합니다. 합성 가능한 조합 RTL에서는 명시적인 입력에 의존하게 하고 모든 경로에서 반환값을 대입하며 지연이나 이벤트 제어를 넣지 않습니다. automatic은 시뮬레이션 모델에서 호출마다 인수와 지역 변수의 저장 공간을 따로 줍니다. 레지스터나 클록 사이클을 추가하는 것이 아닙니다.

다음 함수는 8개 입력 비트의 XOR를 계산합니다. 반복 횟수는 고정되어 있으며 대응하는 회로는 조합 패리티 축약입니다.

module parity_function (
  input  logic [7:0] data,
  output logic       parity,
  output logic [7:0] with_parity
);
  function automatic logic parity8(input logic [7:0] value);
    logic p;
    integer bit_index;
    begin
      p = 1'b0;
      for (bit_index = 0; bit_index < 8; bit_index = bit_index + 1)
        p = p ^ value[bit_index];
      parity8 = p;
    end
  endfunction
  assign parity = parity8(data);
  assign with_parity = {data[6:0], parity8(data)};
endmodule

with_parity는 의도적으로 data[7]을 버리고 parity를 붙입니다. 전체 입력을 보존하는 9비트 인코딩이 아니라 8비트입니다. 올바른 보조 함수를 사용해도 호출한 쪽에서 정보를 잃을 수 있다는 인터페이스의 결과를 드러내는 예제입니다.

반환 폭과 부호도 중요합니다

반환 타입은 1비트 logic입니다. 8비트 unsigned 두 값을 더하는 함수에서 carry가 계약에 포함되면 반환 폭은 9비트여야 합니다. 폭과 부호를 함께 문서화하세요. 함수 호출이 추가 carry를 자동으로 보존하거나 호출자의 목적지 폭을 바꾸지는 않습니다.

상수 이름과 폭 규칙을 인터페이스 가까이에 두세요. 인수 목록만으로 계산을 알 수 있을 것 같은데 함수가 바뀌는 모듈 전역 변수를 몰래 읽는 구조를 피합니다. 숨은 의존성은 재사용과 검증을 어렵게 합니다.

같은 함수를 호출한다고 직렬 공유 회로가 되는 것은 아닙니다

같은 함수를 두 번 사용한다고 합성이 시간 분할 연산기 하나를 반드시 만들지는 않습니다. 도구가 조합논리를 최적화할 수 있지만 직렬 공유에는 수락 정책·상태·결과 시점이 명시적으로 필요합니다. 소스 호출 횟수만으로 면적이나 처리율을 추정하지 마세요.

테스트벤치에서 이벤트를 기다리는 자극과 검사에는 task가 유용합니다. 함수와 시간을 사용하는 task는 역할이 다릅니다. 테스트벤치 강의에서는 하강 에지에서 입력을 바꾸고 다음 상승 에지 후 상태를 검사하는 task를 사용합니다.

실습 · 다른 알고리즘으로 참조값 구하기

data=0,1,3,8'h80,8'hFF를 검사하세요. 기대 parity는 각각 0,1,0,1,0입니다. data=8'h80이면 높은 입력 비트를 버리고 parity=1을 붙이므로 with_parity=8'h01입니다.

256개 입력값을 모두 검사합니다. 검사기는 DUT의 parity8을 호출하지 말고 정수에서 1인 비트 수를 세어 2로 나눈 나머지와 비교하세요. 같은 요구사항을 다른 방식으로 표현하여 함수를 검증합니다.

반복 상한을 7로 바꾸고 8'h80 단일 비트 검사가 실패하는지 확인하세요. 낮은 비트만 검사하면 높은 비트 누락을 발견할 수 없습니다. 다음에는 {data,parity8(data)}로 with_parity를 9비트로 바꾸고 기대값 모델도 수정합니다. 이것은 서식 개선이 아니라 인터페이스 변경입니다.