Translate

2021년 8월 20일 금요일

1장. 고위합성 튜토리얼 개요 (Tutorial Description)

1장. 고위합성 튜토리얼 개요 (Tutorial Description)

요약

HLS 튜토리얼은 C, C++ 그리고 SystemC 등 높은 추상화 수준으로 기술된 코드(알고리즘)을 RTL(Register-Transfer Level: 데이터 전송의 클럭 단위 상세 수준) 하드웨어로 변환(transform)을 다룬다. C 코드에서 RTL로의 변환을 고위합성 High-Level Synthesis(HLS)이라 한다.

높은 추상화 수준의 C 코드(C++를 포함하여 통상적으로 이렇게 부른다)에서 낮은 클럭 단위 수준 RTL 로 변환할 때는 두가지 선택이 있다. 하드웨어의 크기(area)와 출력 성능(throughput; 계산에 소요되는 클럭의 갯수)이다. 이 선택을 기초로 변환 과정에서 최적화(optimization)가 이뤄진다. 합성(synthesis)은 높은 수준의 코드로부터 하드웨어(논리회로)를 추론(infer)해 내고 이를 최적화(optimize)하는 과정을 포함 한다.

자동화된 HLS 이전에는 원하는 하드웨어를 얻기 위해 C 코드에 인위적 수정이 불가피 했었다. 수정을 가하면 오류가 끼어드는 것을 피할 수 없다. 진정한 고위 합성은 원래의 C 코드를 변경하지 않고도 원하는 하드웨어를 합성해 내야 한다. 이 튜토리얼은 단지 합성 지시자(directives, 혹은 합성 옵션)만을 삽입 하므로서 어떻게 원하는 목적을 달성하는지 보게될 것이다.

이 튜토리얼에서 다루게 될 내용은 다음과 같다.

1. 고위합성 소개(High-Level Synthesis Introduction)

이 튜토리얼은 자일링스(Xilinx)사의 비바도 HLS 도구(Vivado HLS Tool)의 그래픽 개발 환경 Graphical User Interface (GUI)과 티클 Tcl 스크립트가 활용될 것이다.

2. C 코드의 유효성 평가 (C Validation)

HLS 설계는 높은 수준의 C, C++ (SystemC는 C++를 하드웨어 설계에 적합하도록 확장된 라이브러리 모음이다.)에서 시작한다. 합성하기 전에 이 코드들은 테스트 벤치(test-bench)에서 충분히 검증되어야 한다. 테스트 벤치는 설계와 동일한 추상화 수준의 언어 환경에서 작성하므로서 효과적으로 검증을 수행 할 수 있다. 이때 사용되는 기본적인 디버깅 기법은 소프트웨어 개발 과정에서의 그것과 동일하다.

아울러 임의 정밀도 자료형(arbitrary precision data types)과 그 디버깅을 다룬다. 알고리즘을 기술 할 때 필요이상으로 높은 정밀도를 갖는 자료형을 사용할 경우 하드웨어를 낭비하게 된다. 알고리즘이 적용될 시스템에서 규정된 정밀도에 따라 응용 분야에 맞도록 임의 정밀도를 갖도록 선언해 주는 것이 좋다. 고위합성 전에 이에 대한 충분한 검토 역시 테스트 벤치를 통해 실시한다.

합성 지시자(옵션)로 알고리즘의 자료형을 임의 변경 할 수 없다. 합성 지시자는 계산기의 구조(파이프라인 같은 병렬구조는 하드웨어의 크기를 좌우한다)와 제어기의 최적화(소요 클럭 수 및 지연)를 지시할 수 있다.

고수준 코드에서 채용된 자료형은 곧 데이터 패스(data-path)의 비트 폭(bit-width)을 지정하는 것과 같다. 하드웨어의 성능(크기, 지연 등)에 직접 영향을 준다. RTL은 클럭 상세 뿐만 아니라 데이터 패스의 비트폭 상세를 모두 포함하는 수준의 하드웨어 기술이다.

3. 인터페이스  합성(Interface Synthesis)

고수준 컴퓨터 프로그랙밍 언어에서 설계물은 함수로 기술된다. 함수의 호출과 반환 그리고 지역 및 전역 변수의 운용은 해당 언어에서 정해진 규칙을 따른다. C 언어에서 합성해낸 RTL 설계물 역시 작동의 시작과 끝이 있다. 입력으로 유효한 데이터가 제공되는 시점과 유효한 출력의 시점을 클럭 단위로 표시한다. 이를 핸드 쉐이크(hand-shake) 절차라 한다. 외부의 설계 모듈과 데이터를 주고받을 준비(ready)가 되어 있음을 수동적으로 표시하거나 능동적으로 요청(request) 하는 특별한 신호가 필요하다. 입출력 데이터와 교환방식의 규정을 인터페이스(interface) 라한다.

인터페이스 합성은 RTL 설계물이 인접 모듈과 데이터 및 주고 받는 절차(프로토콜 protocol)에 필요한 제어 신호를 포함한 입출력 포트들을 생성해 낸다. 블럭 수준의 입출력 프로토콜, 포트 입출력 프로토콜의 제어방법을 배우게 된다. 가령 외부의 메모리에 접근 하려면 데이터 외에 제어신호가 필요하다. 데이터를 가져오기 위해 주소를 미롯한 읽기 및 쓰기 제어 신호가 선행 되어야 한다. 선입선출(FIFO) 방식이나 AXI4-스트림은 저마다 표준화된 접근 절차를 가지고 있다. 인터페이스 합성은 어떤 입출력 방식을 사용할 것인지 정해 주기만 하면 함수의 데이터 패스와 함께 최적화된 입출력 프로토콜을 생성해 준다.

4. 임의 정밀도 자료형(Arbitrary Precision Types)

HLS 도구들은 C 언어에서 규정된 고유 자료형 이외에 비트 단위로 비트폭을 선언하고 고정 소수점 비트 위치를 지정할 수 있는 임의 정밀도  자료형을 제공한다. 

C 언어는 고유한 자료형을 사용한다. 고유 자료형들은 저마다 표현할 수 있는 값의 범위, 표현 방법들이 언어의 표준으로 고정되어 있다. 예를 들어 문자형, 단정도 정수형, 배정도 부동 소숫점 형은 각각 8, 16, 64 비트폭을 가지며 비트 위치 마다 의미가 규정되어 있다. 이런 규정은 높은 추상화 수준에서 자료형을 일일이 지정하는 번거로움을 덜어주고 오버플로우 같은 계산상 오류를 표준화 해줌 으로써 적절한 자료형의 선택을 수월케 한다. 이에 비해 RTL의 하드웨어 기술은 자료형의 표준은 없다. 다만 2진수 비트 단위의 상세만 있을 뿐이다. C 코드 알고리즘이 적용될 분야에 따라 최적의 비트폭을 갖는 자료형이 선택해야 한다. 실수 연산에 높은 추상화 수준의 부동 소숫점 자료형을 선택할 수 있으나 이를 바로 RTL에 적용하기에는 지나치게  정교하다. 따라서 알고리즘을 C 코드로 검증 하는 단계에서 부터 적절한 자료형을 적용하여 최적의 RTL 하드웨어를 얻을 수 있도록 한다.

임의 정밀도 자료형을 사용하면 C 고유 자료형에 비해 정밀도를 희생 하게 되므로 충분한 검증이 이뤄져야 한다. 적용된 분야에서 규정된 정밀도 허용범위를 만족하면서 하드웨어의 크기와 계산에 소요될 시간(클럭 수)을 최적화 시킬 수 있다.

5. 설계물 분석(Design Analysis)

단번에 C 코드에서 원하는 최적 RTL 결과를 얻는 경우는 매우 드물다. HLS 도구들은 매우 복잡한 하드웨어 합성을 수행하기 때문이다. 

높은 추상화 수준에서 가장 낮은 추상화 수준으로 변환은 매우 다양한 결과를 낼 수 있다. 추상화 수준 변환기의 한 예로 C 컴파일러가 있다. GCC 컴파일러의 옵션을 나열한 문서만 해도 수십쪽이 넘는다. [GCC compiler options summary] 동일한 실행방식인 소프트웨어의 추상화 수준 변환에도 이렇게 다양한 옵션이 있으며 변환된 결과에 커다란 영향을 미친다.

C 컴파일러는 인간이 읽을 수 있는 C 문서에서 기계가 읽을 수 있는 2진 코드로 변환한다. 2진 기계코드의 실행방식은 C 언어와 같은 순차적 실행이다. 하물며 실행 방식이 완전히 다른  RTL은 단순치 않다. RTL은 병렬 실행을 원칙으로 코딩 스타일에 따라 순차 실행 부분을 기술할 수 있다. 인간의 문서(human readable)'에서 '기계의 문서(machine readable)'로 변환을 '구문 통역(translation)'이라 한다면 실행방식의 변경이 동반되는 경우 '합성(synthesis)'이라 한다. '합성'은 더 많은 추론이 필요하며 숨겨진 코드를 생성한다. 높은 추상화 문서에서 함수의 호출과 반환을 구체적으로 기술되지 않지만 이를 수행하기 위해 컴파일러에 의해 추가되는 기계 코드들(push-pop 과 call-return 같은)이 있다. 인터페이스 합성기는 외부의 모듈과 데이터를 주고받기 위한 핸드 쉐이크 프로토콜(handshake protocol)을 생성하여 설계물에 포함 시킨다.

최적의 고위 합성의 결과를 얻으려면 생성된 RTL 설계물을 분석하여 효과적인 옵션을 찾아야 한다. 이때 고려할 사항으로 소요된 하드웨어 자원의 규모(size 또는 area), 가장긴 지연 경로(delay path), 소요된 클럭의 갯수(clock latency)들이 포함 된다. 이는 기능(functional)의 유효성과는 다른 물리적(physical) 수준의 검증이다.

C로 기술된 이산 코사인 변환 discrete cosine transform(DCT)을 가지고 RTL 합성 후 생성된 하드웨어를 분석해 보기로 한다. 분석을 바탕으로 합성 옵션을 달리하여 상이한 병렬 구조를 갖는 하드웨어가 생성될 수 있음을 보게 될 것이다. 이 과정에서 최적의 결과를 찾도록 한다.

C 컴파일러의 경우 엄청난 종류의 옵션이 있으나 대부분 표준 기본값이 정해져 있다. 특별한 경우가 아니면 대부분 조정하지 않는다. RTL 합성기는 옵션의 종류가 다양하지 않지만 각각이 결과에 미치는 영향이 매우 크므로 정확한 분석과 적용이 요구된다. 일단 C 수준에서 기능은 검증 되었으므로 이 단계의 설계 분석은 생성된 하드웨어의 분석(크기와 지연)에 집중 한다.

6. 설계물 최적화(Design Optimization)

행렬 곱셈기를 예제로 삼아 두가지 최적화 기법을 다뤄본다. 행렬 곱셈은 디지털 신호처리, 영상처리, 인공 지능등 여러 방면에 두루 사용되는 수학적 도구로서 매우 많은 곱셈과 덧셈 계산을 포함한다. 다행히도 단위 계산이 반복적인 특징을 가지고 있어서 병렬처리 구조로 꾸미기 수월하다. 설계 최적화는 설계물의 하드웨어 구조를 선택하는 기법을 다룬다. 고위 언어에서 가장 빈번한 반복 구문(for-loop 같은)을 다수의 동일 구조의 연산기를 직렬로 배치하는 파이프라인(pipeline) 병렬처리로 할 것인가 아니면 단일 연산기를 반복 사용하는 FSM(Finite State Machine) 제어기로 할 것인지 결정 한다. 이 결정에는 설계분석 후 설계요구도(specification)를 만족하는지 여부에 달렸다. 설계분석 후 합성 옵션의 변경에도 요구사양을 맞추지 못한다면 최초 C 코드의 수정이 불가피 할 때도 있을 것이다. 합성으로 얻은 RTL과 원 C코드를 비교하여 수정 위치를 정확하게 특정 함으로써 설계시간을 줄이고 수정으로 인한 오류를 최소화 할 수 있다.

7. RTL 검증(RTL Verification)

C 코드로 부터 생성된 RTL 설계물을 검증한다. 자동화된 합성기의 무결성을 믿고 싶지만 버그 없는 소프트웨어는 없다. 게다가 버그로 발생한 피해를 책임지는 툴 벤더도 없다. 그렇다고 의심만 할 수는 없으므로 검증이 필요하다. 다행히 자동화된 검증 도구들은 C 코드를 검증할 때 사용된 시험환경을 그대로 들여와 생성된 RTL을 시험할 수 있게 되었다. 추상화 수준 뿐만 아니라 언어와 구문 실행방식 조차 서로다른 설계물을 한 시뮬레이션 환경에서 수행 가능하다. 이를 CoSimulation 이라한다. 이 단계 실습은 C 로 작성된 테스트 벤치로 부터 자동화된 RTL 검증 절차를 보게될 것이다. 시뮬레이션 도구로 자일링스 비바도 시뮬레이터 XSim 과 멘토 그래픽스 사의 ModelSim을 사용 할 수 있다.

인터페이스 시뮬레이션은 파형을 살펴봐야 하겠으나 기능 검증은 대규모 기준값(golden-value)이 동원된다. 대규모 계산 입출력 값을 수동으로 비교하고 확인 하는 절차는 반드시 자동화 되어야 한다.

시스템 수준 설계라면 버스 규격 또한 만만치 않게 복잡하다. 특히 멀티 마스터 시스템 버스는 더욱 그렇다. 설계물이 이런 시스템의 한 부분을 차지할 목적이라면 인터페이스 검증시 파형을 살펴보는 경우는 거의 없을 것이다. 버스 기능 모델 BFM (Bus-Functio Model)이 제공되고 검증 상태를 메시지로 보는 표명 기반 검증(Assertion-Based Verification)이 효과적이다.

8. HLS IP 통합(Using HLS IP in IP Integrator)

고위 합성을 통해 생성된 RTL 설계물을 IP로서 패키지화 하는 방법을 다룬다. 패키지화 된 IP는 다른 시스템 설계 도구에서 라이브러리로 재사용 될 수 있다. 비바도 IP 카탈로그에 추가되어 비바도 디자인 스위트(Vivado Design Suite) 내에서 사용될 수 있다.

9. HLS IP 를 Zynq SoC 설계에 적용 하기 (Using HLS IP in a Zynq SoC Design)

HLS IP블럭은 Zynq®-7000 SoC 설계에 활용된다. 고위 합성으로 생성된 하드웨어 설계 블럭을 Zynq 시스템 프로세서에 통합하고 C 언어로 구동 소프트웨어(device driver)를 생성 시키는 법을 다룬다.

SoC 설계는 고성능 프로세서를 포함한다. IP화된 HLS 설계 블럭은 프로세서의 주변장치로 시스템에 통합 될 것이다. 아울러 주변장치 하드웨어를 구동하기 위한 소프트웨어가 필요하다. 시스템 프로세서의 버스의 프로토콜이 표준화 되어 있으므로 이를 구동하기 위한 구동 소프트웨어의 기본 구동 루틴은 자동 생성된다.

10. Using HLS IP in System Generator for DSP

고위합성으로 생성된 RTL 설계물을 자일링스 시스템 제네레이터(System Generator for DSP)에서 사용될 수 있도록 패키지화 하는 법을 배운다.

튜토리얼에 사용된 소프트웨어

이 튜토리얼은 자일링스 비바도 디자인 스위트 2017.1 이후 버젼을 적용한다.

튜토리얼을 수행할 컴퓨터의 요구사항

자일링스 비바도 디자인 스위트를 사용하려는 컴퓨터는 적어도 2GB 이상의 메모리 용량이 필요하다.

튜토리얼의 예제 파일들을 얻을 수 있는 곳

튜토리얼에 사용할 디자인 파일은 자일링스 웹 사이트를 통해 얻을 수 있다.

Vivado Design Suite Tutorial High-Level Synthesis UG871 (v2020.1) August 7, 2020
PDF / Design Files

--------------------------------------------------------------------------------------------
고위 합성 튜토리얼(High-Level Synthesis Tutorial)


댓글 없음:

댓글 쓰기