죄송합니다. 더 이상 지원되지 않는 웹 브라우저입니다.

CATAPULT HLS로 안경 없는 ULTRA-D 3D 실현

PDF 다운로드

글/ERIC LEENMAN, SENIOR DIGITAL DESIGNER, SEECUBIC/STREAMT V NET WORKS

서론

StreamTV Networks Inc.(StreamTV)에서는 2011년부터 Ultra-D™ 기술을 개발하는 프로젝트를 진행해 왔으며 로스앤젤레스, 필라델피아, 런던, 에인트호번, 베이징과 타이베이에 지사를 두고 운영하고 있다. StreamTV의 주된 사명은 무안경(glasses-free) 3D 기술을 대중 시장에 도입하는 것이다. 당사는 기존의 2D 비디오 에코시스템에 Ultra-D 기술 레이어를 얹기 위해 연구 개발에 적극적으로 몰두하고 있다.
당사의 활동 범위는 영화 및 게임 업계용 콘텐츠 제작부터 방송 및 스트리밍 업계에서의 콘텐츠 유통, 나아가 세트 제작업체에 Ultra-D 지적 재산(IP)을 통합하도록 파트너 업체를 지원하는 것까지 경계를 가리지 않고 널리 뻗어 나가고 있다. 기술 연구, 개발과 산업화는 네덜란드 에인트호번에 위치한 StreamTV의 전액 출자 자회사인 SeeCubic에서 담당한다.
LCD와 OLED 패널에서 끊임없는 혁신이 이루어지고 기술이 발달하면서 4K 해상도가 생활 속에 깊이 침투하고 있으며 다음 기술 발달의 지표로서 8K가 대두되고 있다. 이러한 패널은 5인치부터 100인치까지 크기를 가리지 않고 다양하게 출시된다. StreamTV에서는 이와 같은 각종 패널을 자사에서 보유한 Ultra-D 기술을 사용하여 무안경 3D 스크린으로 바꿀 수 있다. 이렇게 하려면 이용 가능한 2D 및 스테레오 콘텐츠 전체를 StreamTV의 독점 재산 실시간 알고리즘을 사용해 Ultra-D로 변환해야 한다.
실시간 변환(Real-Time Conversion, RTC) IP 블록은 이 알고리즘을 구현한 것이다. 당사 비즈니스 개발팀에서는 엔지니어링 부서에 이 RTC IP 블록을 SoC 내에 통합할 수 있는 형태로 개발해달라고 요청했다. 이렇게 요청하던 당시만 해도 SoC와의 협력관계 체결 여부가 아직 결정되지 않은 상황이었다. 따라서 실리콘 기술, 인터페이스, 프로토콜, 메모리와 대역폭 요구사항과 같은 기본적인 설계 매개변수를 아직 알 수 없었다. 결과적으로 기술 사양을 작성할 수 없었다는 말이다.
하지만 SoC와 협력관계를 체결하려면 IP 블록의 개념 증명이 필요했다. 이와 같은 상호 종속 관계가 존재한 탓에 당사는 “사면초가”의 상황에 부딪히고 말았다. 사양 없이는 블록을 개발할 수가 없는데, SoC와의 협력 관계는 개념 증명 블록이 없으면 더 이상 추진할 수 없었던 것이다. 이 백서에서는 이 문제를 해결하는 데 Catapult® High-Level Synthesis(HLS)가 어떤 역할을 했는지 기술하였다.

RTC IP 변환 작업에 대한 이해

RTC IP는 동영상을 Ultra-D로 변환하는 역할을 한다(그림 1). 2D 동영상의 경우, 이미지를 2D 심도 예측 (Depth Estimation) 함수로 보내 심도 맵을 만든다. 그런 다음 이 이미지와 심도 맵을 모두 Ultra-D 렌더링 블록으로 보낸다. 스테레오 동영상의 경우, 왼쪽과 오른쪽 이미지를 스테레오 심도 예측(Stereo Depth Estimation) 함수로 보내 여기서도 심도 맵을 만든다. 그런 다음 왼쪽 이미지와 심도 맵을 Ultra-D 렌더링 블록으로 보낸다.

[그림 1] RTC IP 블록으로 2D 및 스테레오 동영상 지원

심도 맵이란 입력 이미지와 같은 해상도의 흑백 이미지를 말한다. 이 심도 정보를 픽셀 그레이스케일 형식으로 캡처한다. 다시 말해 픽셀에 흰색이 많을수록 앞쪽에 있고, 픽셀이 어두울수록 뒤쪽에 위치한다는 뜻이다. 입력 그림의 컬러 픽셀마다 그와 연관된 심도 픽셀이 있다. 두 가지 심도 예측 함수는 렌더링에 필요한 메타데이터도 생성한다.

기존 설계 플로우의 한계 이해

RTC IP는 기존과는 완전히 다른, 새로운 하드웨어 블록이었다. 사실 그래서 편리하기도 했는데, 레거시 코드를 지원할 필요도 없고 이전 버전이나 오래된 표준 등 옛날 것과의 호환성을 따질 필요가 없었기 때문이다.
프로젝트의 출발점으로는 C++ 알고리즘과 관련 문서를 이용할 수 있었다. 시스템 아키텍트와 설계팀이 참석한 세션을 여러 차례 열어 변환 알고리즘의 모든 블록을 빠짐없이 설명했다. 설계의 중요한 부분을 분석하고, 그 결과 블록 다이어그램을 작성하고 더 많은 문서를 작성하였다. 기존 설계 플로우에 대하여 RTL 알고리즘을 직접 손으로 코딩했다. SoC에 통합할 목적으로 작성한 RTL 코드는 처음에는 개념 증명의 의미로 FPGA 플랫폼용으로 작성되었다. 그림 2가 그 설계 플로우를 나타낸 것이다.

[그림 2] 기존 설계 플로우

이 플로우에는 근본적인 문제점이 몇 가지 있었는데, 대표적인 예를 들면 다음과 같다.
1. 디지털 설계자가 문서와 골든 레퍼런스 모델(C++ 언어로 작성)을 이해할 수 있어야 했다. 그런 다음 상세한 RTL 디지털 설계를 수동으로 생성하였다. 이런 작업을 하는 데 시간이 무척 오래 걸렸다.
2. 상세한 디지털 설계는 RTL 코드로 구현했는데, 이것은 오류가 발생할 확률이 높은 과정이었다.
3. RTL 코드는 품질을 보증하려면 광범위한 검증을 거쳐야 한다. RTL 테스트와 검증 환경을 설정하고 각종 테스트를 모두 설계하는 데에는 개발팀의 상당한 수고가 든다.
4. 첫 단계로 FPGA 시험기를 만들어야 한다. 이 플랫폼에서 코드가 제대로 작동하도록 하기 위해 FPGA에만 특정된 설계 실례를 코드에 끼워 넣는다. 예를 들어 FPGA 클럭 주파수에 부합하려면 입력과 출력에 버퍼를 등록하고/거나 레지스터를 추가하여 지연 시간을 보상해야 한다. 따라서 RTL 코드는 어느 정도 기술을 가린다고 볼 수 있다.

이런 문제점 외에도 이 플로우는 시간이 오래 소요된다는 문제가 있다. 업계 사례를 살펴보면 개발 업무의 60% 이상이 검증에 소비된다는 것을 알 수 있다. 따라서 이 플로우를 사용해 SoC에 적합한 IP를 구현한다는 소기의 목적을 이루는 데에는 여전히 “사면초가”의 문제가 남아 있었다. RTL 코드는 FPGA에만 특정된 코드가 되기 쉽고, 첫 FPGA 시험기를 만드는 데에는 설계팀에 너무 과중한 업무 부담이 부과되기 때문이다.

새로운 설계 플로우 소개

우리는 이 문제를 해결할 잠재적인 해법을 찾아 오랫동안 HLS 플로우의 개발 과정을 알아보고 주시해 왔다. 우리는 비교적 작은 회사이기 때문에, 위험 요소를 최소화하기 위해서는 신기술이라고 해도 이미 자리를 잡았으며 실제 프로덕션 프로젝트에서 검증이 된 것만 채택할 수밖에 없다.
그러다 약 2년 전쯤 비슷한 시기에 두 가지 중대한 사건이 일어났다. 하나는 전에 퇴사한 동료가 NVIDIA®에서 Catapult HLS를 사용해 좋은 결과를 얻었다는 긍정적인 경험담을 전해준 것이고, 다른 하나는 에인트호번에서 열린 하이테크 이벤트에 참석했는데 그곳에서 HLS 플로우의 가능성을 본 것이다. 이 두 가지 일을 겪으면서 HLS 기술이 어느 정도 성숙했다는 것을 알 수 있었다. 중요한 것은 HLS 플로우가 FPGA에서 SoC 기술로 용도 변경을 할 때 적합한 기술로 유망해 보였다는 것, 그리고 설계 단계 후반부에 사양을 변경해도 감당할 수 있는 플로우라는 점이었다. 이런 점까지 더해지면서 HLS가 우리의 “사면초가” 문제를 해결할 수도 있겠다는 생각이 들었다.
Catapult HLS는 ASIC 또는 FPGA 구현을 대상으로 C++ 및/또는 SystemC 설명으로부터 고품질 RTL을 생성하여 하드웨어 설계 솔루션을 제공한다. 신속한 설계와 검증을 보장하며 바로 시뮬레이션과 RTL 합성에 투입할 수 있는 RTL을 도출하는 것이 특징이다.
우리는 Mentor에 문의하여 우리 설계에 Catapult HLS를 어떻게 이용하면 좋을지 의논했다. RTC IP 블록의 전반적인 구조를 나타내는 작은 C++ 코드 샘플을 만들어 이를 Mentor로 보내 평가를 의뢰하는 것부터 시작했다. 이 샘플 코드에는 RTC IP 블록의 설계 단계부터 이미 확인된 몇 가지 어려운 문제점이 있었다.
Mentor에서는 처음 나눈 논의 내용과 코드 샘플의 평가 결과를 바탕으로 Catapult HLS를 사용할 수 있도록 기간 한정 전체 평가판 라이선스를 제공했다. 이 기간 동안 Mentor에서는 사흘 동안 두 차례 현장 지원을 제공했는데, 우리는 이 기회를 활용해 샘플 C++ 코드를 논의하고 그간 직면했던 모든 문제를 해결했으며 결과적으로 설계가 RTL 시뮬레이터에서 올바로 작동하는 성과를 올렸다. 그것도 RTL 코드를 한 줄도 손으로 쓰지 않고 말이다. 새 HLS 설계 플로우(그림 3)는 우리 회사 내 디지털 및 알고리즘 설계의 세상을 완전히 바꿔 놓았다.

[그림 3] 새로운 HLS 설계 흐름

이 새로운 HLS 설계 플로우의 요점을 몇 가지만 소개하면 다음과 같다.
* 합동 팀: 알고리즘 설계자와 디지털 설계자가 함께 하드웨어 블록을 만든다. 각 설계자는 자기 전공 분야의 전문가로서의 역할을 고수한다. 같은 C++ 언어를 사용함으로써 두 분야가 진정으로 하나로 통합된다. 이렇게 하면 기존 플로우에서 흔히 일어날 수 있는 인간적인 해석 오류를 배제할 수 있는데, C++을 RTL 코드로 변환할 때는 수동 작업으로 관여할 필요가 없기 때문이다.
* 하드웨어 생성에 단일 설계 언어 사용: 이 프로젝트에서는 C++ 코드를 KPN(Kahn Processing Network) 방식으로 (다시) 써야 했다. 이렇게 해야 하드웨어 유사성을 모델링할 수 있기 때문이다. KPN 방식으로 쓴 C++ 코드는 Catapult에서 이해할 수 있는 형식이므로 이를 토대로 하드웨어가 생성된다.
입력 데이터 형태로 툴에 제공된 구체적인 기술 정보는 정리를 마치고 바로 합성할 수 있으며 해당 기술에 적합한 RTL이다. 이것도 FPGA용 Altera/Intel® Quartus® 소프트웨어와 같은 백엔드 툴에서 이해할 수 있는 형식이다.
* HLS 지침: 구체적인 지침을 제공하여 Catapult에 하드웨어 합성 방법을 지시한다(그림 4).

[그림 4] 지침은 기술 대상을 가지고 실험할 때 같은 코드를 사용하는 데 필수적

지침은 각 블록의 데이터 처리량 및 지연 시간과 같은 타이밍 작동 측면을 추가한다. 지침은 하드웨어 생성에 영향을 미친다. 예를 들어 루프의 언롤링 여부 및 그 방식을 지정하거나 매 네 번의 클럭 사이클마다 한 개의 루프를 실행해야 한다고 지정하여 면적에 영향력을 행사할 수 있다. 루프를 언롤링하지 않으면 면적을 절약하게 된다. 우리가 원하는 요구사항이 클럭 사이클 한 번에 루프 본체(loop body)를 두 번 실행해야 하는 것이라면 루프를 언롤링해도 된다.
이렇게 하면 성능 요구사항에 부합한다. 그런 다음 하드웨어에 필요한 면적을 정당화하는 것이다. 따라서 지침이라는 수단을 통해 최소한의 리소스로 적절한 데이터 처리량을 선택하는 것이다. Catapult는 블록 타이밍의 일정을 자동으로 만들고, 처리 상태 머신을 만들며 필요한 경우 지연 시간을 보상한다.

* 기술 사양: 백엔드 프로세스는 손으로 쓴 RTL과 같다. HLS 플로우에서는 기술이 일종의 지침이므로, 서로 다른 대상에 대하여 서로 다른 RTL을 생성할 수 있다(그림 5 참조).

[그림 5] 같은 골든 레퍼런스 코드를 사용하여 서로 다른 기술 지정

Catapult에서는 C++ 코드가 기술 데이터와 별개로 분리되어 있어 코드를 변경하지 않고 기술만 변경할 수 있다. 예컨대 Altera®(Intel) 기술 라이브러리에서는 생성된 RTL이 150MHz로 실행되지만 TSMC 라이브러리를 선택하면 다른 설계를 생성하여 클럭 속도 450MHz로 실행할 수 있는 것이다.

블록 전체 검증 수행

우리는 C++ 함수를 사용하여 알고리즘 코드를 작성한다. 사용한 함수가 올바른지 증명하기 위해
광범위한 테스트도 작성하는데, 이것도 C++ 언어이다. 이러한 기존 코드에서 함수를 하나 선택하여 이를 하드웨어로 바꾸면 나머지 코드는 테스트벤치로 사용된다. Catapult는 자동으로 소프트웨어 테스트벤치와 하드웨어 생성 RTL 사이를 연결하는 일종의 접착제가 된다. 따라서 테스트벤치를 RTL로 수동으로 작성하지 않고도 C++ 테스트를 디지털 시뮬레이션에 재활용할 수 있다. 이렇게 하면 테스트 생성과 검증 코드는 물론 하드웨어 설계에도 단일한 환경을 제공하는 것이 된다.
예를 들어 그림 6과 같이 pre_filter와 edge_detect라는 두 가지 하위 블록을 포함한 필터 블록이 하나 있다고 가정해 보자. 하드웨어 블록은 물론 블록 테스트도 C++로 설명된다.

[그림 6] 블록 전체에 대한 테스트 수행

설계자는 지침을 작성하여 Catapult에 pre_filter의 하드웨어를 생성하도록 지시한다. 그리고 Catapult/SCVerify를 사용하여 이 pre_filter 블록을 시뮬레이션하면 된다. C++ 코드를 전혀 변경하지 않고도 이제 블록 테스트, 필터와 edge_detect를 테스트벤치로 사용할 수 있으며 이것이 이렇게 생성된 하드웨어를 오고 가는 스티뮬러스를 제공하는 것이다(그림 6의 왼쪽 부분 참조).
이 방법은 edge_detect 하드웨어 블록을 만드는 데에도 쓰인다(그림 6에는 표시되지 않음). 그런 다음 설계자가 pre_filter와 edge_detect를 인스턴스화하는 필터 구성 지침을 작성한다. 이번에도 Catapult/SCVerify를 사용해 이 필터 블록을 시뮬레이션할 수 있다. C++ 코드를 전혀 변경하지 않고도 블록 테스트를 테스트벤치로 사용하고, 이것이 생성된 하드웨어를 오고 가는 스티뮬러스를 제공한다(그림 6의 오른쪽 부분 참조).
이 검증 프로세스는 C++ 함수 전체를 블록 전체에 걸쳐 하드웨어로 변환하는 작업을 지원한다. C++ 블록 테스트가 전체 함수의 테스트벤치이다. C++ 함수는 100% 검증된 하드웨어 표현형이다.

팀 조직에 미치는 영향

HLS 플로우로 전환하면 C++ 코드가 다음과 같은 요소를 나타낸다는 뜻이 된다.
* 소프트웨어
* 소프트웨어 테스트
* 검증 테스트벤치
* 하드웨어 코드

이제 설계팀과 검증 팀이 같은 언어를 사용하여 작업하므로 사내에서 팀과 프로젝트를 조직하는 방식 자체가 흔들리게 되었다. 이제 전보다 팀 규모가 작아졌고, 유지해야 할 코드 베이스도 작아진 것이다. 이와 같은 변화로 인해 프로젝트팀에서 새로 도입한 HLS 방법론을 최대한 유리하게 활용할 수 있게 되었고, 그 결과 이전에 이용하던 방법론에 비해 제품 출시 기간을 단축할 수 있었다.

MENTOR의 지원 서비스

RTL 플로우에서 HLS 플로우로 전환하려면 상당한 학습 곡선이 요구될 수 있다. 그래서 첫 프로젝트를 진행할 때에는 Mentor에서 지원을 받는 것이 무척 중요했다. Mentor에는 프로젝트를 진행하는 동안 고객사에 FAE(Field Application Engineer)를 파견하는 정책이 있다. 이 정책은 양쪽에 모두 무척 유익한데, 파견된 엔지니어가 프로젝트에 관해 익히고 깊은 부분까지 숙지할 수 있으면서 동시에 관계자 모두가 프로젝트 목표를 확실히 이해하고 목표를 달성할 수 있기 때문이다. 우리의 의견을 간략히 정리하면 다음과 같다.
* 첫 프로젝트에는 우수한 지원 서비스가 필수적이었다.
* HLS 방법론과 툴 사용법에 관해 다루는 기본적인 방문 교육으로 시작함으로써 모두가 학습 곡선에 동참할 수 있었다.
* 현장에 설계를 잘 아는 FAE가 있다는 것이 그 자체로 귀중한 리소스가 되었다.
* 설계 문제가 발생할 때 현장에서 즉시, 노련한 엔지니어의 조언을 구할 수 있으면 시간이 확실히 절약된다.
* Catapult HLS의 장점 누리기
프로젝트 완료 후 Catapult HLS를 이용하면 크게 두 가지 장점이 있다는 것을 알 수 있었다.
* 시간 절약: Catapult HLS를 이용하면서 개발 시간이 50% 이상 단축되었다. 덕분에 소규모 인원으로 구성된 기존 팀이 사내에서(인근 계약업체 인원 몇 명을 추가 동원함) 프로젝트를 완수할 수 있었다.
이런 방식으로 일하자 의사 전달 과정이 간략해지면서 심층적인 설계 변경에 대해서도 간편하게
논의할 수 있어 프로젝트 제조간접비가 크게 절약되었다. HLS를 익히는 데 드는 학습 시간은 설계자 1인당 약 3개월이 걸렸지만, 개발 시간이 단축된 만큼 첫 프로젝트를 실행하면서 그 시간을 충분히 돌려받았다고 볼 수 있다.
* 마감이 임박한 설계 변경에 맞춰 조정: 이 툴은 수많은 이점과 설계 유연성을 제공한다. 알고리즘 변경을 개발 프로세스 후반에 적용할 수 있어서 여러 가지 설계 옵션을 자유롭게 시도해볼 수 있다. 이처럼 유연성이 보장되기 때문에 첫 구현만 완료해도 설계가 제대로 작동할 가능성이 커지고, 면적 및/또는 성능에 맞춰 최적화하기 위해 나중에 미세 조정 및/또는 변경을 적용할 수 있다. 예를 들면 다음과 같다.
- 우리는 히스토그램 블록의 최초 버전을 구현하여 이것을 하드웨어에서 실행할 수 있다는 것을 입증하고자 했다. 여기서 필요한 요구사항은 픽셀마다 1픽셀/클럭의 데이터 처리량으로 읽기누적-쓰기 작업을 해야 한다는 것이었다. Catapult를 이용하자 대상 하드웨어에서는 이 작업을 예약할 수 없는 것으로 드러났다. 그래서 시스템 품질을 저하하지 않고 알고리즘을 변경하였다.
- 다른 블록에서는 복수의 처리 단계에서 진정한 하드웨어 분할이 사용되었다. 간단한 첫 번째 구현에서는 복수의 나눗셈 인스턴스화를 적용하여 솔루션이 적절하다는 것이 입증되었다. 그러나 Catapult에서는 이러한 하드웨어 나눗셈이 온전히 활용되지 않는다는 것을 알 수 있었다(모든 클럭 사이클에서 활성 상태가 아님). 따라서 이후에 설계를 최적화하여 하나의 나눗셈만 사용하도록 했는데, 이 나눗셈이 모든 처리 단계의 분할 작업을 실행하도록 하였으며 툴이 서브 블록 분할, 데이터 라우팅과 파이프 라이닝까지 대폭 변경하였다. 이런 유형의 변경 작업은 수동 RTL 코드로는 절대 불가능했을 것이다. 작업량이 방대한 데다 관련 검증에 드는 수고가 지나치게 과도하기 때문이다.

설계 버그 통계 분석

이 프로젝트에서 RTL의 95%는 Catapult HLS를 사용하여 생성하고 5%만 수동으로 생성했으므로, 수동 RTL 코드의 양이 HLS 코드에 비해 상대적으로 적다. Catapult HLS로 생성한 블록의 인터페이스에는 표준 채널 프로토콜을 적용하였다. 수동 RTL을 작성하여 이 채널 프로토콜을 외부 인터페이스에 연결하였다. 이 코드의 버그를 분석하자 20%는 HLS 생성 RTL에서, 80%는 수동 RTL에서 발견된 것으로 나타났다(그림 7).

[그림 7] 설계 버그 통계

HLS 생성 코드에서 발견된 버그를 좀 더 자세히 나눠보면 5%는 C++ 코드가 예상 하드웨어에 어떤 식으로 변환되는지 이해가 부족해 발생한 것이고 15%는 우리가 HLS 지침을 작성할 때 오류가 있었기 때문에 발생한 것이었다. 예를 들면 다음과 같다.
* 파이프라인 상태 머신을 정지(stall) 모드로 해야 하는데 실수로 플러시(flush) 모드로 설정했다.
* FIFO 숫자를 지정할 때 너무 작은 수를 지정하여 채널에 데이터 라인 전체를 저장할 스토리지가 부족하여 데드록이 발생했다.

수동 RTL에서 버그가 발생한 주된 원인은 프로토콜 위반이었다. 테스트벤치 환경에 버스 기능 모델(BFM)이 있어 트랜잭션의 변형을 생성하고 캡처할 수 있었다. 그리고 새 버그가 나타날 때마다 테스트 목록에 새 테스트를 추가해 목록을 길게 늘였다. 또한 트랜잭션의 무작위 변형을 더 많이 만들어 프로토콜 커버리지를 개선하고 회귀를 방지하고자 했다. 수동 RTL에서 버그가 발생한 다른 이유로는 레지스터 인터페이스 내 불일치 문제와 클럭 도메인 교차 문제 등이 있었다.

프로젝트를 통해 얻은 교훈과 향후 설계 전망

HLS 설계 플로우라는 맥락에서 기존 디지털 설계를 이해하는 것이 무엇보다 중요한다. HLS를 이용하면 디지털 설계자가 메인 설계 블록은 C++로 설계하면서도 HLS가 적합하지 않은 경우에는 여전히 SystemVerilog 또는 VHDL을 이용할 수 있다.
같은 코드를 사용하는 합동 팀으로 일하면서 올바른 설계를 유지하는 데 큰 도움이 되었다. C++ 도메인에서 디버깅을 하면 나중에 시뮬레이션이나 하드웨어 테스트 중에 디버깅을 하는 수고를 덜 수 있다. HLS를 처음 쓰는 소프트웨어 설계자는 디지털 설계를 잘 이해해야 한다. Catapult는 흔한 소프트웨어 컴파일러와는 다르다. 코드가 C++ 언어로 쓰인 실제 하드웨어 설명이다. 따라서 이제 “좋은 코드”와 “나쁜 코드”라는 개념을 나누는 기준이 달라졌다. “이 코드를 사용하면 우리가 설계한 하드웨어가 나올까?”
설계 사이클 후반에 블록 또는 하위 블록 아키텍처를 변경할 수 있고, 특히 사양 변경을 적용할 수 있으면 무척 유익한다. 이 덕분에 코드를 일일이 수동으로 변경하지 않고도 여러 가지 다양한 선택지를 둘러볼 수 있었다. 기존 RTL 방식에 따르면 이것은 불가능한 일이었는데, 출시 기간 및/또는 검증 테스트 (부분적) 재실시 등의 부담이 컸기 때문이다.
결론적으로 가장 중요한 것은 HLS 설계자는 C++ 코드가 생성된 하드웨어를 도출하는 방식과 그 이유를 이해해야 한다는 것이다. 마지막이지만 절대 사소하지 않은 사실은 StreamTV/SeeCubic 내에서 Catapult HLS가 앞으로 거의 모든 신규 프로젝트에 이용될 것이라는 점이다. Catapult HLS는 IP 개발에 효과적이고 성숙한 기술이라는 것이 검증되었기 때문이다.

leekh@seminet.co.kr
(끝)
<저작권자(c) 반도체네트워크, 무단 전재-재배포 금지>