8장. 레지스터 전송 수준 설계(RTL Design) [소스 다운로드]
레지스터 전송 수준(RTL, Register Transter Level)에서 디지털 회로 설계를 정의하는 특징을 들자면,
- 클럭 상세(clock-cycle detail)
- 비트 상세(bit-width detail)
C++의 템플릿(template)으로 디지털 하드웨어의 객체(레지스터 register 와 전선 wire)를 임의 비트 크기 자료형으로 표현할 수 있다. 이번 예제는 비트 상세 설계된 duc(digital up counter)/dds(direct digital synthesis) 다.
예제는 C 설계의 객체들이 비트 상세형으로 기술되었다. 템플릿으로 11비트, 18비트, 23 비트, 45비트 등 정수를 다양하게 기술하고 있다. 높은 추상화 수준의 언어로 알고리즘을 비트 상세 기술하면 장점보다 단점이 많다. 고유 자료형과 호환성이 떨어지고 무엇보다도 충분히 성숙된 RTL 언어가 있는데 높은 추상화 수준의 언어를 사용할 필요가 없다. 그렇더라도 비트 상세가 유리할 때도 있는 법이다. 비트단위 연산이 많거나 제어 집중적인 설계에 유리하다. 또한 추상성이 상이한 여러 모듈이 혼재하는 시스템 수준 설계와 통합 그리고 검증 환경(RTL/HDL과 Co-Simulation) 구축에 유리하다. C++ 언어로 작성된 테스트 벤치의 유연함과 실행 속도는 RTL/HDL에 비할바가 아니다. 추상화 수준이 높은 설계 도구(언어)라 할지라도 낮은 수준의 설계 방법론을 수용해야 하는 것은 필수 요건이다. 최상위 시스템 수준 설계 언어인 C++는 소프트웨어 개발은 물론 SystemC 크래스 라이브러리를 활용하여 하드웨어의 RTL 논리식 수준까지 가능하다.
예제 duc()는 4개의 하위 함수를 가지고 있다. 다른 합성 옵션 없이 입출력 인터페이스만 지정해 주고 합성했다.
자일링스의 Vitis HLS Tutorial 문서 UG871과 함께 제공된 소스에 문제가 있어서 수정 했다. 비티스 HLS 2021.1에서는 C 형식 임의 정밀도 'ap_cint.h' 가 지원 되지 않는듣하다. 임의 비트 폭 정수형 재정의(typedef) 문이 구문 오류를 낸다. 게다가 이 형식은 SystemC와 호환성도 없다.
typedef uint(N) acc_t;
typedef int18 srrc_data_t;
C 언어의 임의 비트 정수형을 비티스 HLS에서 정의한 C++의 ap_int<> 형식으로 바꿨다. 이 템플릿 자료형은 SystemC의 sc_int<>와 기능적으로 호환된다.
#ifdef SYSTEMC_LIB
#include <systemc.h>
#define ap_int sc_int
#define ap_uint sc_uint
#else
//#include "ap_cint.h"
#include <ap_int.h>
#endif
typedef ap_int<18> srrc_data_t;
원 소스 코드를 변경하였으므로 함께 제공 되었던 테스트를 거쳐야 한다. Vitis HLS의 설계절차를 모두 수행하여 Co-Simulation 까지 통과했다. 수정한 C++ 소스 코드가 원본과 일치한다는 뜻이다.
RTL/HDL-SystemC Co-Simulation 검증 환경을 구성하였다. 비트 폭 상세(bit-width detail) C++ 설계물은 HLS를 거쳐 클럭 상세(clock-cycle detail)이 추가된 RTL이 되었다. RTL과 C++ 설계물의 혼합 시뮬레이션은 최상위 추상화 수준에서 논리식 수준까지 폭넓게 지원하는 SystemC 검증 환경에서 이뤄진다.
데이터 시각화
파형(waveform) 보기와 통과 메시지(assertion message) 출력은 RTL 설계의 흔한 검증 방식이다. 하지만 수많은 출력을 문자로 보기엔 뭔가 서운하다. 출력 숫자들이 궁금하여 그림으로 보니 예제의 의도가 파악 되었다. 디지털 주파수 합성기 였다.
고위 합성 튜토리얼(High-Level Synthesis Tutorial)
[목차][이전][다음]
댓글 없음:
댓글 쓰기