Translate

2023년 9월 13일 수요일

오늘의 반도체 설계, 20년 전과 다를까?

오늘의 반도체 설계, 20년 전과 다를까?

각종 매체에 '반도체'라는 말이 등장 할 때 따라붙는 접미어를 보면 크게 '물질'과 '공정' 그리고 '설계'일 겁니다. '공정'은 '몇몇 나노 공정' 이라며, 숫자가 작을 수록 최신 공정이라며 뉴스꺼리로 주목을 많이 받습니다. 그리고 반도체 '물질' 역시 큰 주목을 받는데, 탄소 반도체, 초전도 반도체 등 입니다. 역시 신물질이라며 주목을 받죠. 그런데 '설계'에 관한 기사는 드믈고 그나마 '인력양성' 또는 '시스템 반도체' 라는 기사에 잠깐 언급되는 정도 입니다.

'공정'을 제조기술이라고 한다면 '설계'는 기능의 구현기술 이라고 하겠습니다. 말하자면 '설계'는 제조와 기능 사이에 연결고리가 되는 도면을 그리는 일입니다. 해야할 일이 많아지면 그 기능들을 수행할 전자회로는 복잡해 집니다. 그저 복잡하다고 표현 하는 정도가 아니라 너무나 복잡해 집니다. 요즘 PC에 사용되는 중앙연산장치 반도체(CPU) 내부의 트랜지스터 갯수는 수십억개 라고 합니다[참조]. 굳이 말로 표현하자면 이 반도체를 제조하려면 수십억(!)개의 부품으로 구성된 도면을 그려줘야 한다는 뜻입니다. 사람이 할일이 아니죠. 할 수도 없구요. 그래서 부품들을 모두 규격화 해놓고 수많은 부품을 규칙적으로 배치하고 배선해 주는 반도체 설계 자동화 도구라는 소프트웨어를 동원 합니다.

현대적인 반도체 설계는 할 일을 문서로 작성해 주면 자동화 소프트웨어가 이를 전자회로의 도면으로 변환해 줍니다. 이는 프로그래밍 언어로 할일을 작성하고 컴파일러로 실행 파일을 만드는 소프트웨어 개발과 다를바 없습니다. 요즘은 반도체 설계도 소프트웨어 개발 처럼 컴퓨터 언어로 할일을 작성해 주면 컴파일러(합성기와 배치배선기)가 알아서 도면을 작성해 줍니다. 그렇지 않고서야 어떻게 수십억개의 트랜지스터가 들어간 반도체 제조 도면을 만들겠습니까!

지지난 달 부터 대학에 나가 반도체 설계를 가르칠 기회가 생겨서 강의록을 만들려고 자료를 찾다가 20년 전의 반도체 설계 강좌 기사를 발견하여 읽어 봤습니다. 연재글 제목도 아주 매력적 입니다.

"마이크로프로세서 설계 무작정 따라하기" [링크]

컴퓨터 활용서나 코딩 교육 입문서에 '무작정 따라하기'가 붙은 제목은 봤어도 반도체 설계에 이런 제목이라니 매우 과감했다는 생각이 들더군요. 아마 그 시절의 시각에서 보면 어쩌면 황당했을 지도 모릅니다. 물론 적어도 전자공학을 전공하는 대학생을 염두에 둔 글이긴 하지만 따라하기에 필요한 도구(소프트웨어)들이 너무나 고가 인데다 쉽게 접근하기 어려웠기 때문 입니다. 물론 20년 전의 소프트웨어 개발 도구들(컴파일러)의 가격도 만만치 않았지만 마음만 먹으면 그럭저럭(?) 사용하는데 크게 무리는 없었지만 반도체 설계 도구들을 구하기는 매우 어려웠습니다. 도구의 희귀성으로 인해 오늘의 반도체 설계 인력 부족이라는 문제를 낳게 된 요인의 하나였을 것이라는 생각이 듭니다.

오늘 우리의 반도체 설계 여건은 20년 전에 비할 수 없이 달라졌습니다. 감히 엄두도 못내던 설계도구들이 제작사들의 관대함 덕분에 무료 라이센스가 발행되고 있습니다. 오픈 소스 소프트웨어는 소프트웨어 개발 도구 뿐만 아니라 반도체 설계도구도 예외는 아닙니다. 시뮬레이터, 컴파일러(합성기), 배치배선기, 레이아웃 편집기들은 교육용 뿐만 아니라 중소규모 반도체 설계용으로 손색이 없습니다. 이제 말그대로 '무작정 따라하기'에 장애가 없어졌습니다. 이에 덧붙여 국내 기관(ETRI 등), 대학 연구소에 설치된 실험용 공정에서 교육 목적으로 반도체 제작을 지원한다는 소식이 있으니 더욱 반갑습니다. 외국의 경우 이미 FPGA 를 사용한 반도체 설계가 취미로 자리하여 재미있는 '프로젝트' 들이 공개되는 것을 봅니다. 반도체 설계를 '무작정' 따라할 만큼 충분한 여건이 되었습니다.

한가지 덧붙이자면,

반도체와 관련된 뉴스의 화면에 방진복을 입은 작업자의 모습을 그만 봤으면 좋겠습니다. 팬데믹 사태를 격으며 힘들던 시절의 모습을 떠올리게 합니다. 청정실이라고는 하지만 마치 감옥에라도 갇혀있는 듣한 모습은 매력적이지도 않고 숨이 막힙니다. 반도체 업계는 마치 '공정'만 있는 듯이 보입니다. 허옇고 누런 색과 단조로운 기계적인 모습 대신 역동적인 화면(그래봐야 코드 리스팅이지만)과 설계자들의 자유분방한 화면을 보여주면 좋겠습니다. 적어도 시뮬레이션 화면의 파형 정도는 보여줘도 되는것 아닌가요? 소프트웨어 산업을 소개할 때처럼 남녀 설계자들의 매력적인 모습을 보여 줬으면 좋겠습니다.

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

두번째 덧붙이자면,

20년전이나 지금이나 '반도체 설계'는 규모만 커졌지 기조는 바뀐 것이 없습니다. 여기서 말하는 '설계'는 하드웨어용 언어로 작성된 할일(알고리즘)을 디지털 회로(트랜지스터 조합)로 변환해주는 과정을 말합니다. 오늘날 이런류의 '설계자동화'는 관심을 얻지 못합니다. 당연하게 여기게 된 것입니다. 마치 소프트웨어 언어의 컴파일러 제작이 고급 기술이 아닌 평범해 진것과 같은 이유 입니다. '하드웨어 문서에서 실리콘으로' 이어주던 자동화 기술이 정점에 이른 지금은 좀더 높은 수준의 자동화에 관심을 갖게 되었습니다. '하드웨어 문서'에서 '하드웨어' 라는 말을 빼려는 것입니다. 하드웨어를 목적으로 만든 문서를 전자회로로 바꾸는 설계 자동화는 평범해진 것입니다.

인간의 언어와 가깝도록 발전한 (소프트웨어) 프로그래밍 언어는 알고리즘을 수월하게 표현할 수 있습니다. 굉장히 많은 사람들이 이 언어를 이용해 전자회로에게 일을 시키고 있죠. 프로그래밍 언어로 작성된 알고리즘을 전자회로에서 작동시키려면 컴파일러라는 도구를 사용합니다. 이 도구는 범용 계산기(CPU, GPU 같은)에서 작동될 수 있도록 일반 문서를 기계용 문서로 바꿔 주는 역활을 합니다. 문제는 이 범용 계산기의 성능(처리속도)이 인공지능이나 기계학습처럼 대규모 데이터를 다뤄야 하는 응용에 만족스럽지 않다는 것입니다. 동시다발로 생성되는 데이터를 받아들이려면 그 숫자만큼의 컴퓨터가 필요한데 경제적으로나 기술적으로나 부담이 아닐 수 없습니다. 그래서 계산기에서 '범용'을 빼려고 합니다.

신경망이라고 하는 인간의 사고체계를 모형화하고 전자회로로 구현하고 싶어진 것입니다. 인간두뇌의 신경세포의 수 만큼은 아니더라도 수천(또는 수만개)개의 CPU가 서로 연결된 계산기를 만들고 싶어진 것입니다. 이런 계산구조의 유용성은 이미 증명되었습니다. 하지만 범용 CPU가 하나 달린 컴퓨터 여러개를 연결하려면 여간 수고로운게 아닙니다. 그래서 수천개의 CPU를 가진 컴퓨터를 만들려고 합니다. 다행이라면 신경망을 구성하는 계산기(신경세포)가 이것저것 다하는 범용 계산장치(CPU)보다 아주 단순하다는 것이죠. 손톱만한 반도체 위에 단순 계산장치 수천개를 서로 연결해 놓고자 합니다.

응용에 따라 알고리즘은 달라 집니다. 이 알고리즘은 프로그래밍 언어로 쉽게 작성 할 수 있습니다. 그래서 프로그래밍 언어로 작성된 알고리즘을 반도체 회로로 바꿔주는 자동화 도구가 등장 했는데 이를 고위합성(HLS, High-Level Synthesis)이라고 합니다.

어쨌든 계산을 수행하는 전자회로는 '하드웨어' 입니다. 이 하드웨어는 한번 만들어지면 고치지 못합니다. 그래서 컴퓨터는 다재다능하도록 만들어 놓은 범용 CPU를 두고 프로그램을 바꿔가며 해당기능을 수행 합니다. 이를 '소프트웨어'라고 합니다.

FPGA 라는 반도체 부품(IC)가 있습니다. 이 반도체는 논리적인 수준에서 구조를 바꿀 수 있습니다. 전자회로의 말단에 해당하는 트랜지스터는 고정되어 있지만 그보다 윗단계에서 산술논리 계산을 수행하는 계산기 구조를 마음대로 재구성 할 수 있습니다. 말하자면 특정 알고리즘에 맞춰 그에 최적화된 CPU로 변신 시킬 수 있는 반도체 부품이 바로 FPGA 라는 것입니다. 프로그램될 수 있는 하드웨어 입니다. 하드웨어가 소프트 해졌다는 뜻입니다.

HLS와 FPGA를 결합하여 프로그래밍 언어로 작성된 인공지능 알고리즘을 소프트해진 하드웨어에서 작동 시키고자 하는 연구가 한창이고 곧 실현될 조짐을 보이고 있습니다.

20년전에 반도체 설계라 하면 '하드웨어용 문서'를 작성하는 행위 였다면 오늘의 반도체 설계는 '하드웨어용'이라는 제약을 떼내고 '일반 문서'를 작성하는 행위로 바뀌었다는 것이 가장 큰 차이라 하겠습니다.

재작년(2021)에 Xilinx의 HLS 툴이 신통하길래 봐뒀는데 이렇게 유용할 줄은 생각도 못했습니다.

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

[참고]
[1] AI_accelerator, https://en.wikipedia.org/wiki/AI_accelerator
[2] Xilinx Research & Open Source Projects, https://www.youtube.com/@xilinxresearchopensourcepr321
[3] HLS Programming with FPGAs, https://www.youtube.com/@youngkyuchoi4260
[4] FINN tutorial at FPGA'21, https://xilinx.github.io/finn/2021/01/27/finn-tutorial-fpga21.html
[5] 고위합성 튜토리얼 개요 (Tutorial Description), https://hls-goodkook.blogspot.com/2021/08/1-tutorial-description.html

작성자: 시간: 댓글 없음:

2023년 8월 10일 목요일

Open Source HLS

3D raytraced game with open source C to FPGA toolchain
A look at CFlexHDL and PipelineC


Graphics demos implemented using PipelineC.

PipelineC
A C-like(1) hardware description language (HDL)(2) adding high level synthesis(HLS)-like automatic pipelining(3) as a language construct/compiler feature.

CflexHDL
Design digital circuits in C. Simulate really fast with a regular compiler!

LiteX
The LiteX framework provides a convenient and efficient infrastructure to create FPGA Cores/SoCs, to explore various digital design architectures and create full FPGA based systems.

LLVM
This repository contains the source code for LLVM, a toolkit for the construction of highly optimized compilers, optimizers, and run-time environments.

MyHDL
From Python to Silicon

NNgen
A Fully-Customizable Hardware Synthesis Compiler for Deep Neural Network

Veriloggen
A Mixed-Paradigm Hardware Construction Framework





작성자: 시간: 댓글 없음:

2021년 12월 17일 금요일

HLS/SystemC Project: Canny edge detector (Legup HLS)

 HLS/SystemC Project: Canny edge detector (Legup HLS)


Download source[link]


작성자: 시간: 댓글 없음:
라벨: ,

HLS/SystemC Project: Canny edge detector (Xilinx HLS)

 HLS/SystemC Project: Canny edge detector (Xilinx HLS)


Download source[link]


작성자: 시간: 댓글 없음:
라벨: ,

HLS/SystemC Project: Canny Edge Detector, Part 1. C-Design

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 기반의 설계 방법론이 확고하게 자리잡을 수 있었다.

(LLVM 같은 매우 정교한 C/C++ 언어 프론트 엔드)

이번 고위합성(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


폴더 구조

<그림>

실행


작성자: 시간: 댓글 없음:
라벨: ,
피드 구독하기: 글 (Atom)