HLS/SystemC Project: Canny Edge Detector, Part 1. C-Design
0. 개요
고위합성(HLS) 도구들이 실제 개발 프로젝트에 활용될 만큼 상당히 성숙되었다. 숙련된 설계자에 의해 수작업된 RTL 코드 대비 80%에 이르럿다고 주장한다[인텔]. 평균 경력자에 의해 개발이 수행될 경우 소요될 개발 기간을 따진다면 충분히 수용할 수 있는 수준이라고 할 만 하다. 저전력 대량생산용의 ASIC 이라면 다소 무리가 있겠으나 계산 지향적 시스템에 채택된 재구성이 가능한 FPGA에 대해 고속 하드 웨어 개발은 HLS로도 충분할 것이다. 특히 낮은 클럭으로도 높은 계산 성능이 요구되는 분야라면 더욱 그렇다. [원격측정, 우주항공, 의료, 군사]
HLS 기반의 설계 방법론의 가장 큰 장점은 알고리즘에서 디지털 회로까지 추상성 수준의 범위가 매우 넓음에도 설계도구의 핵심인 기술(설계)언어의 끊김을 없앴다는 점이다. C/C++ 는 알고리즘 개발 언어로서 압도적 위치에 있다. HDL은 하드웨어 설계 언어로서 확고하게 자리잡았다. C/C++에서 RTL/HDL로 변환해 주는 HLS는 이 둘사이의 깊은 골에 놓인 가교가 되었다. 따라서 HLS 도구가 받아들이는 C 코드는 표준 C/C++에서 벗어나지 않아야 한다. 또 다른 변종 혹은 유사 C/C++가 되지 말아야 한다.
하지만 아쉽게도 HLS 개발사 마다 자체적으로 C++ 크래스 라이브러리를 제공 하거나 심지어 변형된 C 문법을 제시하기 까지 한다. 이들이 제시하는 새로운 키워드 들은 대부분 지시자(pragma directive)에 가깝다. 또는 컴퓨터에 장착된 가속기 하드웨어(GPU, FPGA 애드온 보드)에 접근하기 위한 API를 크래스를 제공하는 경우다[인텔의 oneAPI/DPC++]. 이들은 합성용 이라기 보다 소프트웨어와 하드웨어의 실행 방식을 극복하려는 노력의 일환일 뿐이다.
C/C++와 RTL/HDL의 사이에 자료의 표현과 구문실행 방식에 큰 차이가 존재한다. 하드웨어를 목표로 작성된 C코드를 검증하려면 병렬 실행을 모의해야 한다. C 코드를 하드웨어처럼 실행시키기 위해 제공되는 라이브러리들은 대개 스트리밍, 메모리, FIFO 같은 입출력 인터페이스를 모의하기 위한 것들로 HLS의 목적과 무관하다. 심지어 C/C++ 조차 버거워 하는 현실을 감안해 볼 때 이를 위해 새로운 컴퓨팅 언어(DPC++ 같은)를 제시하는 것이 합당한지 의문이 든다.
그외 테스트 벤치 자동생성 같은 도구들을 제공하겠다며 괸시리 C 설계 코드를 기괴하게 만들기도 한다. 응용에 따라 매우 다양한 모습을 띄게되는 테스트 벤치는 일반화 할 수 없다. 그럼에도 HLS 툴 벤더들이 이미지 처리나 신호처리 라이브러리를 제공하려 드는 경우를 본다. 자사 툴 고객들의 검증 프로젝트 마다 대응하겠다는 각오가 아니면 그만두는 편이 좋겠다.
하드웨어 실행 방식을 모의하길 원한다면 이미 표준으로 제정된 SystemC라는 크래스 라이브러리를 활용하자. 저마다 검증환경의 구축은 사용자들에게 맞기고 함수의 블럭 입출력 핸드쉐이크, FIFO 및 메모리 인터페이스, 시스템 버스, IP 패키지 등과 같은 HLS 표준화와 표준 C 코드와 합성 지시자를 규격화 하는데 집중해 주길 바란다. 합성가능한 코딩 스타일에 관한 표준이 마련되자 HDL 기반의 설계 방법론이 확고하게 자리잡을 수 있었다.
이번 고위합성(HLS)과 SystemC 테스트벤치 프로젝트는 케니 윤곽선 추출기다. SystemC의 FIFO 채널을 이용해 시스템 수준 테스트 벤치를 구축해 놓음으로써 다단 알고리즘으로 구성된 처리기를 구성하는 각 알고리즘을 개별적으로 그리고 동시에 개발이 진행되고 검증될 수 있음을 보여줄 것이다. 표준 C/C++로 기술된 알고리즘을 SystemC의 FIFO 채널로 연결한 테스트 벤치와 함께 실행형 사양으로 제공될 것이다. 각 알고리즘은 최적의 HLS용으로 수정되고 검증되어야 한다. 모듈간 인터페이스는 FIFO로 규정하고 HLS의 입력으로 표준 C/C++ 로 기술된 코드만을 허용한다.
<그림>
1. 케니 외곽선 검출기
캐니 외곽선 검출기(Canny edge detector)는 영상인식과 같은 응용을 목적으로 외곽선 추출에 널리 활용되는 영상처리 기법으로 다단 알고리즘(multi-stage)으로 구성되었다. [Wiki]
다단 알고리즘(multi stage algorithm):
멀티미디어 처리기(압축 인코더, 특징 추출기등)들은 고품질과 고효율을 얻기 위해 다단 알고리즘으로 구성된다. 멀티미디어 압축기의 표준이라 할 수 있는 MPEG 처리기의 경우 기본적으로 DCT(Discrete Cosine Transform), 위신호 제거(Anti-aliasing), 양자화기(Quantizer), 허프만 코더(Huffman coder)들을 포함한다. 손실을 최소화 하면서도 최고의 압축효율을 얻기 위함이다.
캐니 외곽선 검출기는 영상인식을 위한 특징 추출의 전단계에서 더 나은 인식성능을 얻기 위한 영상처리기로 가우시언 필터(Gaussian filter), 소벨 필터(Sobel filter), 최대치 억제기(Non-Maximum suppressor) 그리고 이력 제거 필터(Hysteresis filter) 등 4가지 알고리즘으로 구성되었다. [주: 다수의 알고리즘(algorithm)을 연속적으로 적용하였으므로 처리기(operator 또는 processor)라 한다. 예를 들어 'MP3 알고리즘'은 적절한 명칭이 아니다. 'MP3 압축기'라고 해야 한다.
<그림>
케니 외곽선 검출기를 구성하는 각 알고리즘의 하드웨어는 고위합성기(HLS)로 합성하여 얻는다. 고위합성으로 얻어진 하드웨어 모듈은 SystemC 테스트 벤치에서 검증될 것이다. 검증은 원시 C 코드와 HLS를 목표로 변형된 C 코드 그리고 고위합성으로 얻어진 RTL/HDL 코드를 동일한 SystemC 테스트 벤치 상에서 출력을 비교한다. 각 알고리즘은 개별적으로 합성되고 검증과정을 거칠 것이며 최종 검증된 각 하위 모듈들은 모두 통합하여 최종 검증을 수행한다.
<그림>
검출기를 구성하는 하위 알고리즘을 기술한 C 코드들을 한데 모아 합성할 수도 있을 것이다. 하지만 성격이 다른 여러 모듈들이 합성이 가능하도록 일거에 준비되기 어렵고 검증과정에서 발생한 오류에 대해 어느 모듈의 문제인지 특정할 수 없게 된다. 하위 모듈로 분리하여 동시 개발을 진행하고 검증된 모듈을 모아 전체를 완성하는 이른바 분할정복(divide and conqure)이 유리하다.
2. 인터페이스(Interface)
함수를 호출하면서 인수를 전달하고 되돌림을 받아내는 일련의 절차를 함수 호출 규약(calling convention)이라 한다. C 언어를 포함한 고수준 언어는 함수 호출규약을 표준 문서화(LRM)되어 있다. 따라서 높은 추상화 수준 언어를 사용한 경우 굳이 인터페이스와 재사용에 대한 고려를 하지 않고 알고리즘 자체에 집중할 수 있다.
하드웨어 모듈 사이의 데이터 전송 규약을 인터페이스(interface)라 한다. C에 비해 추상화 수준은 매우 낮은 RTL/HDL에 인터페이스 규약의 표준은 없다. 뿐만 아니라 함수 호출과 되돌림에 해당하는 모듈의 개시와 종료에 대한 규약도 없다. 개별 설계 조직 마다 내부 규약을 갖추고 있기 마련이다. 컴퓨터의 주변 장치라면 시스템 버스 규정을 따르면 될테니 그나마 명확 하겠으나 모듈간 인터페이스는 매우 신중히 결정되어야 한다. C에서 RTL/HDL로 합성하는 HLS 도구들은 나름대로 인터페이스 규약을 갖추고 있다. 함수의 시작과 종료를 다루는 모듈 핸드쉐이크 제어와 입출력 전달 방식을 규정한다. 모듈 핸드쉐이크는 대기 신호에 대하여 시작 신호를 주는 것으로 모듈 동작을 개시하고 종료 신호로 동작이 완료 됐음을 알게 된다. 단일인수(scalar)인 경우 인수의 전달과 되돌림 값을 받는 과정은 핸드 쉐이크 절차에 포함 된다.
만일 인수가 배열(또는 벡터, vector) 라면 인터페이스는 크게 두 가지 방식을 취한다. 첫 번째 방식은 메모리 인터 페이스다.
두 번째 방식으로 선입선출(FIFO) 채널이다.
메모리 입출력 인터페이스는 주소와 읽기/쓰기 가 메모리 접근을 위해 반드시 주소지정 절차가 선행되어 클럭 소모가 있다. 이에 덧붙여 RAM 또는 ROM 메모리는 반응속도가 느리다. 따라서 통신 채널로는 FIFO를 선호한다. 이에 덧붙여 FIFO의 경우 내부 저장 공간을 자체적으로 운용하므로 입출력의 동시 접근을 허용한다. 다단 알고리즘 구조를 갖는 처리기의 경우 매우 유리하다. FIFO를 단순 저장 메모리 장치라 하지 않고 채널(channel)이라고 부른다.
인터페이스에 따라 설계가 완전히 달리진다. 분할된 하위 모듈들 사이의 인터페이스 규약을 미리 확정해두지 않으면 쓸모없는 설계가 될 것이다. 모듈이 적용될 시스템의 규정이 명확히 명시 되어야 한다.
3. HLS 목적의 C-모델 수정
알고리즘을 C언어로 기술한 것을 소프트웨어 모델이라고 하자. 알고리즘을 명확하고 적절하게 기술한다. 인수의 입출력은 재사용성의 관점에서 취급 하드웨어로 변활할 목적이라면 관점이 달라진다.
하드웨어를 목표로 C 모델을 변경할 때 기준:
인터페이스
자원활용
병렬성
변경후 표준 C 일것(이식성, 재사용성이 크게 훼손됨)
메모리 인터페이스의 경우. 배열이 일회성인가 또는 외부의 배열 저장소 포인터인가. 소프드웨에의 내부 임시저장소는 일회성으로 함수가 되돌려지는 순간 소멸. 대규모 저장소를 함수 내부에 두어도 동적 메모리 관리 기법을 쓴다면 부담이 없으나 하드웨어는 컴퓨팅 자원을 회수불가, 배열인수의 색인은 주소. 랜덤 주소와 순차 주소. FIFO 인터 페이스를 목표하는 경우 순차 주소되어야 한다.
SystemC 테스트 환경 구축후 소프트웨어 C모델과 하드웨어 C 모델의 검증
FIFO 채널. C++ 모델의 입출력 병렬처리 시뮬레이션
C++ 모델에 인터페이스 껍질 씌우기: 세가지
- 소프트웨어 모델
- 하드웨어 모델
- 출력비교 모델
세 가지 껍질 모두 동일한 인터페이스를 사용하여 재사용성을 높인다.
<그림>
4. 모델링 및 시뮬레이션 도구들
무료가 아니다. 상용 도구들이나 비용을 지불하지 않고 사용이 허가 되었다. FPGA 벤더의 자사 도구들 이거나 라이센스를 사다가 무료 제공한다. 자사 FPGA 제품의 시장 확보 방안으로 일부 기능을 특화하거나 일부 제한을 걸어두었다. 하지만 고맙게도 최근 배포되는 도구들은 제한이 거의 없어졌다. HLS 가 아직 널리 보급되지도 못한 탓에 이를 진흥하기 위한 방책이 아닐까 싶다. 물론 GNU 같은 공유 개발 개념이 자리잡은 탓도 컷을 것이다.
- C++ compiler: Visual Studio 2019 community version
- Data visualization: GNUPlot 5.4, GTKWave
- Testbench: SystemC 2.3.3
- HLS Tool: Xilinx' Vitis HLS 2021.1 and Microchip's SmartHLS (Legup)
- RTL simulator: QuestSim (Intel FPGA starter version, gcc and sccom)
5. 예제 소스 코드 다운로드 [link]
소스코드는 링크에서 내려받을 수 있다. C 모델과 SystemC로 작성한 테스트 벤치와 마이크로소프트 비쥬얼 스튜디오 2019 프로젝트, 퀘스타심 DO 스크립트들이 모두 포함 되었다.
도구 설치
- 비쥬얼 스튜디오 2019 C++ 와 피이썬 도구들을 함께 설치하자
- GNU Plot 은 설치후 bin 폴더를 PATH 에 추가해 두자
- HDL 시뮬레이터: 인텔 FPGA 스타터 버젼
- Xilinx VitisHLS & Microchip SmartHLS
폴더 구조
<그림>
실행
