SystemC와 HLS

Written by Keith
on 

개인적인 연구과제로 이들 토픽에 대해서 파고 있는 중이다. 하루가 생각보다 긴 시간인 것 같은데, 집중해서 뭔가를 진행할 수 있는 시간은 많아야 4시간 정도가 아닌가 한다. 그 외에는 원래 하던 일을 한다거나 기계적인 것에 가까운 일을 할 수 있다. 어떻게든 이 시간을 늘려보려고 하는데 생각만큼 잘 되지 않는다. 생각해보면 입시 공부를 한참 하던 시기에도 사실 책상에 앉아만 있었지 몰두할 수 있는 시간은 대개 4시간 정도였던 것 같다. 나머진 원래 아는 것들에 대해 확인하는 문제만 미친 듯 풀었지.

이런 식으로 따져보면 어떤 사람 하나가 습득할 수 있는 능력과 지식에도 한계가 생각보다 낮다는 뻔한 결론에 이르게 되고, 그래서 이 방면에 이름을 날리는 수준의 사람들은 대개 운이 아주 좋은 사람이란 걸 알게된다. 뭔가 좀 빨랐다든가 미리 투자(선점)를 해놓은 게 걸려들었던 것이다. 아니면 소 뒷걸음 치듯 했다든가. 대개 사람들이 많이 몰리는 분야에서 많이 안다거나 잘한다거나 떠들어봐야 의미가 없는 게 이미 많이 몰려왔다면 늦은 상태인 것이다. 경쟁이란 거 해봐야 예전 조정에서 과거 시험을 쳤든 전국적인 경연대회를 정기적으로 열어서 실력 측정을 하는 경우가 아니면 정말 뛰어난 사람이라도 별 수 없는 상태가 되는 것이다.

따라서, 물려받는 가업이 없고 소 뒷걸음질과 같은 행운도 없다면 그냥 수많은 사람들 중 하나로 살아가야 하는 것이다. 아니면 혹여나 뭔가 걸려들지 않을까 하고 외롭고 힘든 길을 무식하게 혼자 파 나가든가.

말이 잠깐 샜는데, SystemC라는 게 이것 저것 뒤져보니 90년대 말에 HDL을 C/C++로 시뮬레이션 하자라는 데서 착안해서 나온 게 아닐까 싶을 정도로 그렇게 만들어졌구나 싶다. SystemC라는 언어가 존재한다기 보단 몇 가지 template과 macro가 있을 뿐이다. 이것은 HDL에 좀 가깝게 기술을 할 수 있는 장점이 있어서 그것으로 verilog 같은 것으로 변환하기가 쉽고 C 문법을 따르니까 C 상에서 뭔가 실험을 하거나 검증하거나 할 수 있게 되는 것이다. 말이 C지 사실 그냥 C++이다. Macro가 C++에 만들어져있다. 사실 HDL의 구조상 C++에 가까울 수 밖에 없는데, C++의 문제는 하드웨어적인 시간 개념이 없고 다루는 데이터의 타입이 좀 두루뭉술 (두루 뭉술하다는 것은 1bit 수준으로 쪼개는 fine grain한 detaildㅣ 부족하단 것이다)하다는 것인데, 그것을 몇 개의 template를 만들어놓아 해결한 것이다.

HLS라는 것은 사실 이 system C를 verilog 혹은 그 중간 산물로 바꿔서 나머지는 기존 RTL tool chain으로 처리해버리는 방법론이 된다. 여러 가지 업체와 제품이 있긴 한데, 가장 중요한 것은 이게 얼마나 실제 산업계에서 쓰고 있는 것이냐에 따라 의미가 있고 없고가 결정난다. 다시 말해서 공개용 툴들처럼 너무 generic하면 역시 두루뭉술한 결과밖에 나올 수 밖에 없고 실제 어떤 용도로 (FPGA냐 ASIC이냐) 쓸 수 있느냐, 얼마나 일을 잘해내느냐 등등도 중요하게 된다. 결국, 잘 알려진 몇몇 EDA 회사의 제품만이 의미가 있고 나머지는 그냥 prototype에 불과하게 되는 것이다.

잘 알려진 공개용 툴 중에 panda/Bambu라는 걸 가져다가 빌드해서 써봤는데, 아쉽지만 좀 아니올시다 란 결과를 얻었고 Stratus라는 상용 제품을 써보면 그래도 뭔가 좀 일을 하는구나 하는 결과를 얻었다. 역시 비싸고 알아주는 회사 제품이 되다보니까 실전에서 쓸 수 있는 것 같다는 느낌을 받는데, 최종적으로 얻어지는 그런 느낌은 ‘이거 이렇게 계속 헤딩할 바에 그냥 verilog로 해버리는 게 맞는 거 아냐?’하는 것이다.

이게 나름대로의 방법론이 있고 순서가 있어서 거기에 맞춰서 그대로 따라가지 않으면 계속 에러를 내고 문제를 일으키게 되어있다. 사실 이게 공개용 혹은 open source 방법을 추구하지 않는 제품들의 특징이다. 또 예약어 (reserved words/macro)들이 있어서 일반 컴파일러를 통해서 컴파일 안되는 부분도 있다. 다시 말해서 systemC라는 게 그냥 매크로에 불과하기 때문에 HLS에게 제작자의 의지를 더 잘 알려주기 위해서 별도의 예약어를 더 사용해야 되고 그러다보면 덕지 덕지 붙어서 그냥 verilog로 간단하게 작성해버리느니 못한 결과를 얻게 된다는 것이다.

물론 verilog도 잘 쓰려고 하다보면 그것이 빌드되는 툴에 최적화해줄 필요가 있지만 말이다.

또 한 가지는 일반적인 C의 data type도 따라가면서 자체적인 data type들이 공존하는 상황이기 때문에, 여기서 뭔가 컴파일러라든가 최적화에 걸림돌이 되는 것 아닌가 하는 의심이 생긴다는 것이다. 몇 가지 테스트해봤을 때 컴파일러가 그 정도로 바보는 아닌 것 같다는 결론을 얻긴 했다. 다만 그 최종 결과는 사람이 읽어서 뭘 어쩌겠다 할 수 있는 수준은 아닌 게 확실했다. 이를테면 C 컴파일러가 작업해 놓은 것을 objdump로 다시 disassemble해놓은 상태에서 작업하는 것 보단 수월할 수 있겠지만, 사람들을 불러다 돈 주고 일을 시키면 말을 듣지 않을 지경인 것은 맞다. (이래서 기술자가 십장이나 업자가 되기 힘든 것이다 라고 나는 생각한다.)

좀 더 해보고 정리를 해봐야겠다.