차세대 프로그래밍 논리 개발자

논리 합성의 시대 이전에는 엔지니어가 순수하게 논리로 이루어진 시스템 설계 의뢰를 받았을 것입니다. 레이더는 있지만 마이크로 컨트롤러는 없고, 디지털 신호 처리는 있지만 디지털 신호 프로세서 규격품은 없었습니다. 하지만 디지털 방식으로 처리되는 레이더가 있었습니다.

당시에는 신입 엔지니어가 아날로그 및 디지털 하드웨어를 설계하고 소프트웨어를 개발하는 방법을 알고 있을 것이라고 기대했습니다. 이렇게 다방면에 걸친 기술을 보유한 엔지니어를 간과해버리는 논리 설계의 미래가 우려됩니다. 목수가 망치만 가지고 있을 때는 모든 문제가 못처럼 보인다는 말이 있습니다. 우리에게 모든 문제가 소프트웨어 문제처럼 보이는 시기가 온 것일까요?

인터넷에서 “FPGA 응용 분야”라는 검색어로 검색하면 전기 공학을 선도하는 응용 분야들이 나옵니다. 인공 지능과 음성 인식부터 통신과 이미지 처리까지 다양한 응용 분야가 있습니다. 이러한 응용 분야의 문제는 특히 초보자에게 단순하지 않다는 것입니다. 이러한 응용 분야의 실행을 익히는 과정은 난이도가 높으며 쉽지 않은 주제들이 포함되어 있습니다.

프로그래밍 가능 논리 소자, 이러한 논리 소자의 통합 개발 환경(IDE 및 제조업체별 환경), 새로운 프로그래밍 패러다임(예: 하드웨어 기술 언어 즉 HDL, 동시 실행 수용 능력, 시간 컨셉)을 학습하고 응용 분야 자체를 이해해야 합니다. 이러한 주제들은 전문가가 아니면 실질적으로 익히기 어렵습니다. 이 때문에 프로그래밍 가능 논리 기술을 독학하려는 차세대 논리 설계자들이 이를 꺼리게 됩니다. 첫 번째 단계가 너무 높습니다. 이로 인해 사람들이 이 분야에서 멀어지게 되고 미래의 프로그래밍 가능 논리에 열의를 가지는 사람들이 줄어드는 것 같습니다. 인터넷에 보면 사람들이 프로그래밍 가능 논리 설계의 현재 상태로 인한 어려움을 호소하는 글들을 많이 볼 수 있으며 이러한 문제를 해결하기 위한 여러 오픈 소스 커뮤니티가 있습니다. 많은 사람이, 한 프로그램에서 다른 프로그램을 데이터처럼 처리하는 프로그래밍 기법인 메타 프로그래밍을 통해 문제를 해결할 수 있을 것으로 생각합니다.

프로그래밍 가능 논리 회사들은 위기에 처해 있습니다. 투자자들은 훨씬 기능이 뛰어나고 비싼 칩을 개발하기를 요구하는데 이러한 칩을 사용할 수 있는 사람은 상대적으로 적습니다. 이들의 해결책은 소프트웨어 개발자를 하드웨어 설계자로 바꾸는 것이며 새로운 도구를 통해 이를 실행하고 있습니다.

상위수준 합성(HLS) 컴파일러는 설계 추상화를 한 단계 더 끌어 올리며 우리를 논리 설계의 근본에서 더욱 멀리까지 데려다줍니다. 순전히 소프트웨어 기술로부터 정교한 하드웨어를 만들어 낼 수 있다는 것은 놀라운 일이지만 이럴 경우 사람들에게 어필할 수 있는 논리 설계의 본질적인 매력을 놓치게 됩니다. 최적화 면에서 사람이 컴퓨터를 앞지를 수 있다고 할 수는 없지만 과거에는 단순한 회로를 설계하는 일이 더 단순했다고 할 수 있습니다. 문제는 오늘날 단순한 회로의 설계가 예전보다 어렵다는 것입니다.

회로의 형태로 직접 만든 논리를 보며 큰 기쁨을 느꼈던 것을 기억하고 있습니다. 제 아이디어를 통해 필요한 장치의 개수를 최소화했던 것입니다. 1990년대 초반 프로그래밍 가능 논리를 배웠을 때는 제가 가진 회로 설계 지식을 128개의 논리 소자로 구성된 하나의 장치에 적용하여 실행할 수 있으며 이러한 논리 소자 하나하나를 직접 선택할 수 있다는 사실에 더욱 즐거웠습니다. 누구인지 모르는 특정 알고리즘 개발자의 전문성에 의존하지 않았습니다.

논리 설계가 진화하는 동안 소프트웨어 설계도 진화했습니다. 소프트웨어 설계는 대개 객체 지향 프로그래밍(OOP) 세계가 되었고, 일반적으로 사용되는 설계 패턴 라이브러리는 문서로 충분히 입증되었으며 코드 라이브러리에서 쉽게 확인할 수 있습니다. 제가 사용하는 설계 패턴 북은 예전에 많이 사용되었던 Design Patterns, Elements of Reusable Object-Oriented Software(저자: Erich Gamma 등)입니다. 흥미로운 사실은 하드웨어 설계가 객체 지향으로 시작되었지만 HDL의 개발로 발전이 멈추었다는 점입니다. HDL을 통해 설계를 재사용할 수 있지만 설계 라이브러리는 가장 근본적인 기능이 갖추고 있습니다. 인터넷에서 “7400 계열 집적 회로 목록”을 검색하면 초기 하드웨어 설계 패턴을 찾으실 수 있습니다. 흥미롭게도, Meilir Page-Jones는 자신의 저서인 Fundamentals of Object-Oriented Design in UML에서 집적 회로를 객체 설계의 좋은 예(응집도는 높고 결합도는 낮음)로 소개하고 있습니다. 하지만 사람들이 더욱 복잡한 프로그램 가능 논리 장치를 추구하게 되면서 단순하고 직접적인 논리 설계의 근본을 잃게 되었습니다. 오늘날의 설계 방법론은 논리를 실행하는 컴퓨터 알고리즘에 의존합니다. 이러한 방식은 프로그래밍 가능 논리 초보자들에게 걸림돌이 됩니다.

“TV 뒷면에 플러그로 연결하는 최초의 Pong 게임이 몇 줄의 코드로 작성되었는지” 물으신다면 답은 0입니다. 이 게임은 순수한 하드웨어(그림 1 참조)로 소프트웨어를 포함하지 않았습니다. 소프트웨어를 사용하지 않고 Pong을 설계할 수 있는 신입 엔지니어는 많지 않을 것입니다. “왜 그래야 하죠?”라고 묻는다면 저는 “관점을 확대하기 위해서, 그리고 이것이 가능하다는 사실을 알아야 하기 때문이며, 생각보다 간단하다.”고 대답할 것입니다.

그림 1: Pong 회로도(이미지: Adafruit 블로그에서 발췌, 출처 불명)

2019년 초 IEEE에서는 엔지니어들의 선호 및 비선호 프로그래밍 언어 목록을 발표했습니다. 이에 따르면 엔지니어들이 선호하는 언어는 Python입니다. 저도 동의합니다. 몇 년 전 Texas Instruments 설계 공모전에 심사위원으로 참여했는데 대학생 10팀 중 9팀이 프로젝트에 Python을 사용했더군요. VHSIC 하드웨어 기술 언어(VHDL)와 Verilog는 선호 목록에도 비선호 목록에도 없었습니다. IEEE의 편집자들이 HDL을 프로그래밍 언어로 간주하지 않을지도 모르지만, 설문조사 응답자들이 HDL은 고려조차 하지 않았을 가능성이 큽니다. 만약 그렇다면, 바로 이 때문에 이러한 언어나 논리 설계 자체를 고려하는 엔지니어들이 적은 것이며, 이는 논리 설계 분야에 있어 바람직하지 않은 징조입니다.

그러면 어떻게 해야 할까요? 어떻게 하면 신입 엔지니어들이 문제를 확인하고 소프트웨어적으로 또는 하드웨어적으로 솔루션을 고려하도록 할 수 있을까요? 결국 대부분의 문제는 어느 쪽으로든 해결할 수 있습니다. 제게 아이디어가 있습니다.

Arduino 플랫폼을 통해 많은 청년이 소프트웨어에 관심을 갖게 되었습니다. 이들은 엔지니어와 컴퓨터 과학자가 되기 위해 소프트웨어를 전공하고 있습니다. 어떻게 이런 일이 일어났을까요? Arduino는 소프트웨어 개발의 학습 난이도를 낮췄습니다. 따라서 소프트웨어 개발의 어려움이 줄어들었습니다.

기판 정의를 통해 링커 명령어 파일을 없앨 수 있었고 신호 이름이 표준이 되었으며 IDE는 컴필레이션 상세 정보를 숨겼습니다. Python의 장점 중 하나는 들여쓰기가 일정해야 하는 것과 같이 엄격한 형식을 따라야 한다는 것입니다. 이를 통해 가치가 낮은 임의적인 선택이 사라지고 전체적인 개발 공정이 간소화되어 개발자들의 생산성이 향상됩니다. 프로그래밍 가능 논리에도 이 같은 언어가 필요하며, 이를 통해 프로그래밍 가능 논리 업계가 표준에 따라 협업해야 합니다.

이러한 표준으로서 제안하는 바는 다음과 같습니다. Arduino에는 중첩 인터럽트 수용과 같이 기반 아키텍처를 수정하는 강력한 기능이 내재되어 있지 않으므로, 이 플랫폼에서 해결해야 하는 논리 문제가 현재 프로그래밍 가능 논리 소자가 모든 타이밍 제한사항을 충족하는 것과 같이 간단한 문제라고 가정해 보겠습니다. Arduino의 동급에 해당하는 프로그래밍 가능 논리 소자 기판(PLDB)의 클록은 1,000개의 논리 소자 설계가 작동할 만큼 속도가 느려야 합니다. 따라서 플랫폼에는 기능 확인만이 필요합니다.

Python을 선호하시는 분들이 많기 때문에 Python으로 PLDB를 지원하고 MyHDL의 nMigen(그림 2 참조) 또는 RTLIL이 있는 Yosys와 같은 프레임워크에 구축할 것을 제안합니다. 이를 통해 초보자들이 변환된 언어를 통해 논리 설계를 시뮬레이션하고 진리표를 작성하며 사용 가능한 Python 라이브러리에 액세스할 수 있게 될 것입니다. Python 라이브러리의 경우, Python을 통해 커뮤니티는 PyPI(Python package index)를 사용하여 강력한 공유 설계 패턴 부족 문제를 해결할 수 있는 재사용 가능한 하드웨어 블록을 배포할 수 있습니다. Python과 마찬가지로 nMigen은 메타 프로그래밍을 지원하기 때문에, 이 프레임워크는 간단한 설계를 지원하지만 플랫폼이 확장 가능하여 복잡한 설계를 지원합니다.

그림 2: Python 기반 프레임워크(이미지 출처: MyHDL.org 및 m-labs.hk)

호스트 PC와 PLDB 간 인터페이스는 PLDB 구성 학습에 사용할 호스트 PC의 API가 있는 PLDB 내장 마이크로 컨트롤러가 연결된 USB여야 Python 환경을 프로그래밍 가능 논리 개발에 적합하도록 자동 설정할 수 있습니다. 이러한 설정을 통해 합성, 위치 및 경로, 프로그래밍에 관한 상세 정보를 숨기고 PC에서의 시뮬레이션과 실제 하드웨어에서의 실행이 용이해집니다.

해결해야 할 간단한 논리 문제가 남아있지 않다고 생각하시는 분들을 위해, Digi-Key의 마이크로 컨트롤러 판매량 통계 자료를 보여드리겠습니다. 그림 3은 고객들이 구매하는 마이크로 컨트롤러 등급 분석이며 그림 4는 등급별 판매 단위 수입니다. 전체적으로 Digi-Key에는 8만 개 이상의 마이크로 컨트롤러 부품 번호가 있으며 전 세계 어느 곳이라도 즉시 배송 가능한 19,000대 이상의 마이크로 컨트롤러를 보유하고 있습니다. 다음 그림은 많은 엔지니어가 단순한 8비트 프로세서를 사용하고 있으며 Digi-Key가 다른 등급의 프로세서보다 8비트 마이크로 컨트롤러를 더 많이 선적하고 있음을 보여줍니다. 이는 복잡한 문제보다 단순한 문제가 더 많다는 것을 의미합니다.

그림 3: 마이크로 컨트롤러 유형별 Digi-Key 구매 고객 수(이미지 출처: Digi-Key Electronics)

그림 4: 마이크로 컨트롤러 유형별 Digi-Key 판매 단위 수(이미지 출처: Digi-Key Electronics)

Digi-Key의 목표는 논리 설계에 대한 정식 교육을 받지 않은 사람이라도, 누구든지 프로그래밍 가능 논리에 흥미를 갖도록 만드는 것이며, 이를 위해서는 개발 패러다임을 바꿔야 합니다.