Translate

2021년 9월 8일 수요일

3장. C 설계의 바름 검증 (C Validation)

 3장. C 설계의 바름 검증 (C Validation)

개요
실습 폴터구조
실습 1. GNUPLOT 를 이용한 도식화
실습 2: GNUPLOT, Windows GDI+, SDL Lib 그리고 Python을 내장한 SystemC 테스트 벤치
    2-1. sc_fifo<T> 채널을 이용한 시스템 수준(System Level) 테스트 벤치
    2-2. sc_signal<T*>
    2-3. sc_signal<T>, 클럭 상세(clock-level data transfer) 데이터 전송
실습 3. Arbitrary Precision Type

----------------------------------------------------------------------------------------------------

개요

합성이나 검증 도구들이 제아무리 우수 하더라도 최초 C 설계가 바르게 되었어야 한다는 점은 두말할 나위가 없다. 앞선 fir() 예에서 해봤듯이 검증 벡터 파일을 읽어 설계의 출력과 비교하는 방식이 비교적 수월하다. 하지만 미리 만들어 놓은 벡터 파일에 오류(error)와 손상(defect)으로부터 무결함과 모든 경우를 충분히 고려되었다고(completeness) 보장 되어야 한다.

검증용 참조 벡터 파일이 어짜피 알고리즘을 통해 만들어 졌다면 굳이 중간에 벡터 파일을 만들고 이를 다시 테스트 벤치에서 읽어 들이는 위험(또는 버거로움)을 감수할 필요는 없다. 차라리 알고리즘을 테스트 벤치에 포함 시킴으로서 검증 벡터 훼손의 위험을 차단할 수 있다. 멀티미디어 신호처리, 기계학습 응용처럼 대규모 시험용 입력 벡터와 검증 벡터를 요구하는 경우 파일 입출력 또한 시뮬레이션에 상당한 부담이 된다.

HDL 도 파일 입출력 같은 테스트 벤치 작성용 APl들을 갖추고 있으나 고수준 컴퓨팅 언어에 비할 바가 못된다. 특히 알고리즘 개발과 검증용의 우수한 시스템 소프트웨어 패키지들이 제공하는 API를 들여다 쓰려면 C/C++ 테스트 벤치의 필연성은 부정하기 어렵다. 다만 소프트웨어 개발용의 C 언어에는 하드웨어 묘사를 위한 시간(time management)과 사건처리(event process) 그리고 하드웨어 채널(HW channel)의 개념이 없다. 이를 극복하기 위해 HDL에 C 루틴을 연결해 주는 여러 기준(PLI/VPI, VHPI, FLI, DPI 등등)이 존재하지만 복잡하기도 하거니와 해당 HDL 이나 특정 툴 벤더에 종속되어서 알고리즘 코드를 변경해 주어야 하는 일까지 생긴다. 따라서 C 알고리즘과 합성으로 얻은 RTL/HDL을 변경없이 적용할 수 있고 충분히 검증된 시스템 툴 API 들과 라이브러리 들을 사용할 수 있는 SystemC를 사용해야 하는 이유라 할 것이다.

실습 폴더 구조

실습1. GNUPLOT 를 이용한 도식화 [다운로드]

신호처리에서 많이 쓰이는 해밍 윈도우(Hamming Window) 함수를 HLS를 목표로 작성한 C 설계와 순수 C 모델과 비교 검증하는 테스트벤치를 작성해 본다. 윈도우 함수는 단순 하지만 곱셈의 연산량이 매우 많아 실시간 처리를 위해 파이프라인 구조의 하드웨어를 구성하면 효과적이다. [참고: Window Function을 쓰는 이유 / Window Function ]

해밍 윈도우 함수의 효과를 도식적으로 확인 할 수 있도록 파워 스펙트럼으로 보여준다. 이를 위해 C 로 작성된 simple_fft2() 를 테스트 벤치에 포함 시켰고 입출력 데이터를 그림으로 확인하기 위해 gnuplot 툴을 테스트 벤치에 연동 시켰다. 결과를 그림으로 보면서 DSP에서 윈도우 함수의 효용성을 직관적으로 확인해 볼 수 있다. [참고: Simple DFT in C , gnuplot homepage ]


테스트 벡터와 연산의 결과를 파일로 생성하고 외부의 도구를 이용해 읽고 확인하는 번거로운 과정 없이 테스트벤치에 내장하므로서 검증의 생산성을 높인다. 수많은 신호처리 라이브러리와 소프트웨어를 검증에 사용 할 수 있다는 점은 설계 검증에 C 언어를 사용하는 가장 큰 장점 중에 하나다. Numerical RecipePython NumPy, MatLab 등 이미 이공계 뿐만 아니라 모든 산업의 개발업무에 적용되고 있다.

실습 2: GNUPLOTWindows GDI+SDL Lib 그리고 Python을 내장한 SystemC 테스트 벤치

2-1. sc_fifo<T> 채널을 이용한 시스템 수준(System Level) 테스트 벤치 [다운로드]

아직 하드웨어 구조가 구체적으로 정해지지 않았으므로 비트 상세(bit-wise detail) 및 클럭 상세(clock detail) 의 테스트 벤치 구성이 불가하다. 하지만 SystemC는 시스템 수준의 기술을 위해 모듈간 다양한 통신체널을 제공한다. 시스템 수준의 모델 기술을 위해 제공되는 FIFO 채널을 이용해 모듈간 통신 연결을 구성한다.

sc_fifo<> 채널로 연결된 모듈간 통신은 핸드쉐이크가 필요없다. 이 통신 채널 내에서 전송을 제어 한다. 테스트 벡터 생성 모듈 sc_stimulus에서 각 모듈로 데이더 전송의 동기가 별도의 핸드쉐이크 없이 채널 내에서 맞춰 질 수 있음을 보기 위해 sc_fifo 채널의 깊이가 달리 하였다.

2-2. sc_signal<T*> [다운로드]

모듈간 데이터 전송은 채널을 통해 이뤄진다. SystemC에서 제공하는 기본 채널로 sc_signal<T>가 있다. 채널에 실릴 수 있는 자료형(data type) T는 C/C++ 의 모든 자료형이 가능 하다. 값 뿐만 아니라 주소(포인터) 사용도 가능하다. sc_signal 채널은 sc_fifo 와는 달리 채널내에 전송 동기를 맞추는 기작이 포함되어 있지 않다. 따라서 별도의 핸드 쉐이크 신호가 필요하다. 시뮬레이션 개시를 위해 reset 이 사용 되었고 시뮬레이션 진행은 클럭 clock 신호를 따른다. 하지만 모듈간 데이터 전송은 여전히 클럭 상세는 아니다.

2-3. sc_signal<T>, 클럭 상세(clock-level data transfer) 데이터 전송 [다운로드]

아직 HLS 가 이루어 지기 전이지만 모듈 간 클럭 상세수준(clock-level)의 데이터 전송을 모델링 해보자. 매 클럭 마다 데이터가 채널에 실린다. 클럭 상세 모델의 경우 채널에서 데이터 전송 동기를 맞춰주지 않으므로 핸드 쉐이크(request-ready handshake) 과정이 필요하다.

앞의 예제에서 SystemC 테스트 벤치에 내장 시킨 파이썬(Python)은 Numpy와 matplotlib를 이용해 그래프를 그리는 용도로 사용 했었다. 앞으로 사용할 RTL 시뮬레이터인 ModelSim에 SystemC 테스트 벤치를 적용할 것이다. 유감 스럽게도 matplotlib 가 그래픽 드라이버 호환성이 떨어져 ModelSim 에서 사용 할 수 없었다. 다행히 gnuplot은 사용 가능 하다. 따라서 Python의 용도를 파워 스펙트럼 구하는 용도로 변경 하였다. C 로 작성된 fft 소프트웨어를 그대로 Python 함수로 만들었다.

아직 C 설계가 합성되기 전이지만 SystemC 테스트 벤치에서 모듈 간 데이터 전송은 클럭 상세 수준이다. Python을 내장한 SystemC 테스트 벤치가 HDL 시뮬레이터에서 실행 가능 하다. 이 SystemC 테스트 벤치는 향후 HLS 된 RTL Co-Simulation 에 사용될 것이다.


실습 3. Arbitrary Precision Type [다운로드]

고수준 추상화 언어에서 자료형의 기본 단위는 바이트(byte, 8-비트) 다. 컴퓨터 구조의 태생적으로 한개 문자를 표현하기 위한 비트폭을 기본 단위로 정한 데서 연유한다. 디지털 하드웨어에서 자료의 기본 단위는 2진수 한자리로서 비트(bit)다. 알고리즘이 적용될 분야에 필요한 만큼의 정밀도와 숫자의 가변 범위에 따라 자료의 폭을 비트 단위로 정해야 하드웨어의 낭비가 없다. C 언어에서 하드웨어를 설계 할 때 성능좋은 합성기라면 테스트 값으로 알고리즘을 적용하여 가변 비트 폭을 정해 줄 수도 있으나 아직 그 수준에 이르진 못했다. 사실 설계의 검증에 사용된 테스트 벡터가 실사용에 충분할 만큼 마련되었다고 장담하기도 어렵다. 따라서 C 설계 단계에서 부터 설계자가 오버플로우 같은 연산 오류를 방지하고 정밀도 측정을 바탕으로 구체적인 비트폭을 결정할 수 있어야 한다.

HLS 도구들은 이러 점을 감안 하여 자료의 비트폭을 구체적으로 표현한 기법을 제공한다. 다행히 C++의 템플릿은 임의의 자료형을 선언하는 방법을 제공한다. 예를 들어 16비트와 32비트 자료형을 C/C++에서 정의하면 다음과 같다.

typedef int16_t in_data_t;
typedef int32_t out_data_t;

이를 구체적으로 32비트 폭의 자료 객체임을 명시하는 방법으로 SystemC 에서는 다음과 같이 선언한다.

#include "systemc.h"
typedef sc_int<16> in_data_t;
typedef sc_int<32> out_data_t;

자료형의 비트단위 구체화는 비트 단위 상세의 하드웨어를 겨냥한 것이다. 

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

댓글 없음:

댓글 쓰기