HLS and High-level Hardware Design

HLS를 위한 코드는 하드웨어를 모델링 하지만 동시에 소프트웨어이기도 합니다. 이는 소프트웨어 업계에서 사용되는 여러 개발 방법론과 도구들 역시 하드웨어 개발에 적용될 수 있음을 의미합니다. HLS가 RTL에 비해 높은 생산성을 보여주려면 하드웨어에 대한 이해뿐만 아니라 이러한 소프트웨어에 대한 지식도 필요합니다. 이번 글에서는 HLS를 활용할 때 고려해 보면 좋을만한 것들을 소개합니다.

Clean Code

소프트웨어 업계에서는 이해하기 쉽고, 유지 보수가 쉽고, 재사용성이 높은 코드를 작성하는 것이 중요합니다. 어떻게 코드를 작성하는 것이 더 나은지에 대한 책들이 많습니다. 예를 들면 변수의 life time은 짧을수록 좋다, 변수는 locality가 높아야 한다, 함수는 기능적 응집성이 높아야 한다, 함수는 한 가지 일만 해야 한다, 변수나 함수 이름 잘 짓는 방법 등의 내용들이 있죠. 이러한 것들 모두 HLS를 위한 코드 작성에도 당연히 적용될 수 있고, 적용되어야 합니다. High-level에서 코드를 작성한다면 당연히 소프트웨어 업계가 오랫동안 고민해왔던 것들을 받아들이지 않을 이유가 없습니다.

관련 도서

• Clean Code, Robert C. Martin
• Code Complete 2, Steve McConnell

Unit Test

유닛 테스트는 코드의 개별 단위를 독립적으로 검증하는 테스트 방법입니다. 하드웨어 업계에서도 검증이 중요하지만 소프트웨어 역시 마찬가지입니다. 버그를 줄이고, 유지 보수를 쉽게 만들어 줍니다. 심지어는 TDD(테스트 주도 개발) 방법론도 있습니다. 개별 코드를 테스트하는 방법은 여러 가지가 있을 수 있습니다. 검증하는 코드는 하드웨어로 합성되면 안 되기 때문에 #ifdef __SYNTHESIS__같은 전처리기 지시문으로 검증 코드를 감싸서 코드 내부에 부분 부분 검증 코드를 집어넣을 수도 있고, 아니면 직접 개별 코드를 검증하는 테스트 벤치를 여러 개 작성할 수도 있죠. 그러나 제가 권장하고 싶은 방법은 Catch2나 GoogleTest와 같은 테스트 프레임워크를 사용하는 것입니다. 하드웨어 업계의 UVM이나 VMM과 비슷한 역할이죠. HLS 코드 내에 검증 코드가 들어있으면 코드도 읽기 힘들고 테스트 코드의 관리가 어려워지고, 직접 개별 모듈의 테스트 벤치를 작성하면 팀 안에서 사람들마다 서로 다른 구조의 테스트 환경이 만들어질 수 있으니 하나의 통일된 프레임워크를 쓰는 게 좋은 것 같습니다.

Lint

하드웨어에만 린트가 있는 게 아닙니다. 소프트웨어 업계에도 린트가 있습니다. 사소한 버그와 실수를 방지해 주는 것부터 회사나 팀이 일관된 코딩 스타일을 사용하도록 도와줍니다. 또한 권장되는 코딩 스타일이나 문법을 추천해 줍니다.

Summary

하드웨어 설계 분야에도 물론 좋은 책들과 자료가 있지만, 소프트웨어 커뮤니티에 비하면 작게 느껴지는 게 사실입니다. HLS를 활용한 하드웨어 설계가 매력적인 이유는 소프트웨어 업계가 고민하고 만들어놓은 결과물들을 사용할 수 있다는 거죠. 위에서 말한 것 이외에도 개발 방법론이나 프로젝트 관리 방법, 디버깅하는 방법, 프로젝트 디렉터리 구조, 리팩토링, CI/CD, 코드 리뷰 문화 등 하드웨어 개발에도 적용될 수 있는 것들이 많이 있습니다.

물론 적용하기 어려운 것들도 있습니다. Boost 라이브러리 같은 것들은 하드웨어로 합성이 불가능할 가능성이 크기 때문에 사용이 어렵습니다. 또한 하드웨어에서는 동적 할당 같은 것이 불가능하므로 대부분의 소프트웨어 디자인 패턴은 적용되기 어렵습니다. HLS 툴에 따라 virtual function 등 몇몇 C++ 문법이 지원되지 않는 경우도 있기 때문에 클래스 설계에도 제약이 있습니다. 이런 것들은 잘 판단하셔서 적용하기 힘든 내용들은 건너뛰는 게 좋겠죠. 물론 테스트 벤치 작성에는 도움이 되리라 생각합니다.

HLS를 활용한 하드웨어 개발이 단순히 RTL 코드를 HLS 코드로 대체하는 것이 아니라 프로젝트 관리 방식과 개발 방법 또한 high-level에 맞게 적용되면 좋을 것 같습니다.