2장. 요약: HLS 도구의 흐름(Tool Flow)

2장. 요약: HLS 도구의 흐름(Tool Flow)

[이 글은 자일링스의 Vitis HLS 도구의 흐름을 요약해 본다. 이 도구를 사용하면서 콘솔에 표시되는 로그 메시지를 바탕으로 작성 되었다. 내용 중 추리와 상상으로 인해 오류가 포함되었을 것이다. 읽는 이의 아량을 바라며 활용은 재량에 맞긴다.]

전자 설계 자동화(EDA) 도구 들의 중간 파일들을 너무나 많다. 추상화 단계를 낮추는 정도가 큰 만큼 깊게 들어가는 하위 폴더들과 중간 파일들의 정체를 좀처럼 알기 어렵다. 다행히 대부분 문자 문서 파일들이라 쉽게 열어볼 수 있지만 툴 들끼리 주고받는 형식이기에 이해 불가다. 그렇더라도 툴이 진행되는 과정에서 생성되는 폴더들의 구조와 중간 파일들을 눈에 익혀 두면 설계 자동화 과정을 이해 하는데 도움이 된다. 설계 자동화 도구가 내 뱉는 오류와 경고 메시지에 바르게 대처할 수 있어서 설계자의 부담을 덜고 최적의 결과를 얻기 용이하다. HLS 설계 흐름은 C/C++ 컴파일러 정도의 툴 성숙도에 이르지 못했고 추상화 전이의 간격이 매우 넓다. HLS 의 목표가 RTL 인데 소프트웨어 개발로 치면 추상성이 기계어 코드에 가깝다. 대부분 EDA 툴의 튜토리얼 초반에 폴더 구조를 먼저 설명하는 이유이기도 하다.

1. C 소스 파일

C 기반 설계를 시작은 C로 작성된 설계물과 이를 시험하기 위한 테스트 벤치가 있어야 한다. 시험에 사용할 C 소스 파일은 자일링스의 문서 UG871: Vivado HLS Tutorial 의 2장 실습에서 가져왔다.

2. C 시뮬레이션 (C Simulation)

HLS 프로젝트를 생성 하면 가장 먼저 할 일은 C 시뮬레이션이다. C 디자인 파일 fir.c 과 테스트 벤치 파일 fir_test.c 을 컴파일 하여 실행 파일을 만들고 실행시킨다.  테스트 벤치는 DUT(Design Under Test)인 C 함수 fir()을 main()에 불러온다. 시험용 테스트 입력을 생성하고 출력을 파일에 저장해 두었다가 참조 파일과 비교하여 검증 한다. 오류가 있다면 디버거를 활용하여 문제를 해결한다. 일반적인 C 어플리케이션 제작 과정과 같다. 자일링스 HLS는 C 컴파일러로 자체 C 컴파일러 툴을 사용한다.

HLS 고위 합성기를 한마디로 표현 하면 C 언어를 RTL 언어(Verilog 나 VHDL)로 변환 해주는 언어 변환기다. 자일링스 HLS 툴은 'apcc' 다. 자유 소프트웨어로서 공개 되어 있는 GCC를 기반으로 C/C++ 코드를 읽어 HDL 을 목표로 변환하는 C 컴파일러 인 셈이다.  apcc는 C 구문을 분석하면서 매우 복잡한 중간 파일들을 생성한다. 이 중간 파일들은 이어지는 C 합성(C Synthesis)에 활용된다.

C 시뮬레이션을 실시하면서 만들어진 중간 파일 중에 C 코드 파일도 있다.

    ....... /csim/build/apcc_db/fir.c
    ...... /csim/build/apcc_db/fir_test.c

C 설계를 읽어서 구문 분석후 재생산된 C 파일이므로 읽을 수 있겠으나 내용을 파악하기는 어렵다. 이 파일들의 이름이 C 설계 소스와 동일하므로 주의해야 한다. C 설계 와 테스트 벤치를 컴파일하여 얻은 csim/build/csim.exe 를 실행 시키는 것으로 C 시뮬레이션을 수행한다.

3. C 합성 (C Synthesis)

C 설계 파일을 읽어 RTL의 Verilog와 VHDL 코드들을 합성해 낸다. C/C++ 와 HDL은 컴퓨팅 언어의 면에서 추상성의 차이는 비슷하다. 둘다 현대 최신 컴퓨팅 언어가 갖춰야 할 다양한 요구, 특히 객체 지향성이 반영되었기 때문이다. 

두 언어는 목적에서 큰 차이가 있다. C 언어의 목표는 구축된 하드웨어에 절차를 제어하는 일련의 기계코드 생산이 목표지만 HDL은 하드웨어 구조를 건설하는 것이 목표다. 하드웨어는 작동방식에 있어서 병렬성이 기본이다. 여기에 전자회로의 물리적 지연특성을 교묘히 응용하고 클럭의 개념을 동원하여 순차 작동 회로를 꾸밀 수 있다.

종류를 막론하고 최신 컴퓨팅언어는 규칙이 강직한 문서 작성 도구다. 프로그램이라는 이 문서는 이 추상성을 이해한 인간이 읽고 쓰기 수월하도록 절차적으로 기술된다. 추상성이 높을 수록 언어의 강직성이 높아지는 경향이 있다. LLVM 이라는 컴퓨팅 언어 컴파일러의 프론트 엔드를 이용하면 컴퓨터 언어간의 변환을 수월케 해준다.

HLS/C 합성기도 LLVM을 활용한 프론트엔드에서 반복문을 찾아내고 하드웨어 구조를 만든어 낸다.  반복문(for-loop)을 푸는 과정(loop un-rolling)에서 자료 의존성(data dependency)을 검사하여 파이프라인 구조(pipeline architecture)를 추론해 내고 이를 제어할 FSM을 작성한다. 변수의 수명특성(variable life time)을 고려해 와이어(wire)로 할 것인지 레지스터(register)로 한것인지 결정한다. 모든 연산자가 하드웨어로 만들어지면 하드웨어의 크기가 너무 증가한다. 연산기 입출력에 와이어 혹은 레지스터가 연결됨에 따라 연산기 하드웨어를 공유할 수도 있으므로 자원 최적화를 실시하고 이를 제어할 FSM도 작성한다. 이런 일련의 과정이 하드웨어를 목표로 한 런-타임 최적화(run-time optimization)다. 하드웨어를 위한 런-타임 최적화는 최소 인터벌(interval minimization)이 되도록 하는 것이다.

3. 혼합 시뮬레이션(Co-Simulation)

C 에서 자동화 도구로 만들어진 RTL 을 검증하려고 원래 C 와 동일한 데이터를 내는지 확인해 보고자 한다.

두 설계물은 앞서 살펴본 대로 실행 방식이 완전히 다르다. RTL은 클럭(clock)이라는 시간 관리 기작에 따라 작동되는 반면 C 는 시점 이라는 개념도 없다. 유효한 출력을 내는 시점도 다르다.

C 테스트 프로그램에서 생성한 테스트 입력 파일을 HDL 시뮬레이션에 공유하여 각각의 출력을 비교한다. HDL 테스트 벤치는 HLS 툴을 이용해 C에서 자동으로 생성된다.

HLS 툴이 C에서 HDL로 변환하는 툴을 기반으로 하므로 C의 테스트 프로그램도 HDL 테스트 벤치로 자동변환 시킨다. 결국 HLS 설계 흐름에서 사람이 손댈 부분은 설계와 테스트용으로 C 코드 뿐이다. 과연 이 흐름에서 검증은 완전했을까?

---------------------------------------------------------------------------------
고위 합성 튜토리얼(High-Level Synthesis Tutorial)
[목차][이전][다음]