RISC-V 개념은 좋지만 갈길이 쉽지 않은 아키텍쳐

시절 덕에 10대 때 부터 assembly 어를 사용해 왔던 나에겐, 30년 넘게 다양한 CPU를 다루다 보니 각각 아키텍쳐에 대한 아쉬운 점을 많이 느낄 수 있었다.

초기 8bit CPU인 Z80의 경우 assembly는 주변 기기를 직접 제어하기 위한 수단이었으나, (사실 저 시절  c언어 컴파일러는 커녕, 어셈블리 컴파일러도 구할 수 없었고, 내장 basic에서 기계어 코드를 직접 입력하는 식으로 많이 사용하였다. 그나마 저장 장치인 disk drive 도 귀하던 시절이었다) 16bit 시절 8086 / 88 을 사용하면서 디스크 드라이브가 기본이 되었고, ms-dos에 내장된 debug 로 assembly를 맛보다 MASM (micro soft macro assembly)로 넘어오게 되었다.

하지만 참으로 버그도 많았고 (이때 MASM은 가격도 만만했고, 정품을 쓰면서 컴파일러의 버그를 한국 마이크로 소프트에 직접 문제 재기 하기도 하였다) 이 때문에 여기서도 어쩔 수 없이 Op-code 를 분석 할 수 밖에 없었다.

32bit 이후로는 assembly compiler 는 믿을 수 있게 되어 굳이 op-code를 외우면서 쓸 일은 없어졌지만, 호환성 등의 문제가 생길 때 마다 간간히 비교를 하게 되었다.

한 때 CISC 와 RISC 는 서로 논쟁을 벌이며 지금까지 오고 있지만, 누가 승자라고 할 수 없었고,

지금과 같은 64bit 에서 일정한 크기로 op-code를 만든다는 것은 기본 크기가 커져 의미도 없고, 오히려 코드 크기를 줄여 용량과 속도를 잡으려는 ARM 의  thumb mode 와 같은 시도가 있는 상황에서는 의미가 없어지게 되었다.

RISC-V는 32bit 로 정렬된 정통 RISC 를 표방하려.. 하였으나..

                              (출처: riscv-spec ver2.2)

위에서 설명한 것과 같이 ARM의 thumb 모드와 같이 코드의 밀도를 높이는 것이 유행이다 보니 16bit 단위의 가변 크기 코드를 기본 지원하고 있다.

물론 RISC가 코드 크기 정렬만으로 말할 순 없지만, CISC의 내가 아는 유일한 아키텍쳐인 x86 역시 코드를 일정 크기로 디코딩하여 파이프라인에 넣는 방식으로 가고, 64bit로 와서는 불필요한 명령들을 삭제하는 분위기이기 때문에 굳이 RISC냐 CISC냐의 구분은 예전 세대의 일로 생각된다.

다시 돌아와, RISC라 해도 요즘 같이 다양한 기능을 요구하는 세상에서 정형화 된 크기에 모든 기능을 다 넣는다면 기본 OP-CODE크기가 매우 커져야 하고, 그것은 불필요한 메모리 낭비와 속도 저하로 이어지게 된다.

그렇다고 예전 x86시절과 같이 기본 단위 크기도 없는 난잡한 op-code 크기는 branch 예측등과 같이 속도 증가를 위한 설계를 매우 복잡하게 만든다.

어느 정도 룰을 가지고 가고 예외를 적당히 추가하는 것이 이상적이지 않을까 생각 된다.

나는 CPU반도체 개발자가 아니다 보니, 프로그래머 입장에서 얇은 지식으로 이러면 좋지 않을까 라는 생각을 하고 있었는데, RISC-V는 이런 여러가지 이론적인 바람들을 현실로 구현하는 듯한 부분들이 많았다.

근래 들어 RISC-V 아키텍쳐를 채용한 SOC 제품들이 보이기 시작했고, 거래처 중 두 곳에서 RISC-V로 제품을 내놓았다.

이 중 한 업체의 SOC를 채용하여 제품 화 해본 결과 생각보다 생각 이하의 성능과 안정성에 실망이 컷다.

물론 칩 제조사의 실수와 한계로 인한 부분도 있지만, 공개 아키텍쳐의 한계 또한 있었다.

지금은 어느 정도 안정화 하여 사용하고 있지만, 성능의 한계는 어쩔 수 없었고, 이와 관련하여 칩 업체와의 미팅에서 이야기를 나눌 기회가 있었다.

RISC-V가 국내에서 아직 활성화가 어려운 이유를 정리해 보면 다음과 같았다.

1. 부가 가속 기능에 대한 표준화가 어렵다. ARM이나 X86의 경우 SIMD와 같은 가속 계열 명령이 어느 정도 표준화 되어있고 기본 탑재가 되어있어 요즘같이 대량의 멀티미디어나 수집 데이터를 처리할 일이 많을 경우 처리 속도에서 이득을 볼 수 있다.

하지만, RISC-V의 SIMD에 해당하는 벡터 연산은 표준화가 최근 들어 합의 되었고, 그나 마도 옵션이기 때문에 채택하지 않은 칩들이 많다. 아마도 기본 부분 안정화도 어려운데, 해당 기능까지 적용할 여유가 없어서 인 듯 하다.

2. RISC-V 숙련된 개발자를 구하기 어렵다. 특히 중소기업의 경우 해당 반도체 설계 엔지니어를 구하기는 어렵고, 어떻게 구해도 주로 대기업을 가기 전에 실습 해 보기 위한 거쳐가는 과정으로 있다 가는 사람들이 많다고 한다. 실제 거래처 중 한 곳 역시, RISC-V 코어 개발자 분이 제품 하나를 만들고 이직을 하여, 더 이상 RISC-V 코어 부분은 건들지 못하고 주변 기능만 변경하여 내보내고 있다 하였다. 결국 RISC-V로는 일부 모델만 추가로 내놓고, 라이선스 비용을 내더라도 ARM으로 변경하는 부분을 고민한다 하였다.

3. ARM이라는 완성된 선택지가 있다. 거래처들은 RISC-V가 무료 아키텍처라는 점에 혹하여 도전하였다가, 엔지니어 확보 및 타 아키텍쳐와 성능 경쟁을 하기 위해 투자해야 하는 비용을 겪고 나면,  비록 라이선스 비용이 있지만 이미 완성된 ARM을 사용하는 것이 적은 인력으로 개발해야 하는 중소기업이나 중견기업 입장에서는 더 나은 선택일 수 있다고 말하였다.

대 부분 중소, 중견 기업의 경우 CPU 제조사가 아닌, 특정 작업을 잘 하는 SOC의 개발을 주로 하는데, CPU아키텍쳐에 투자하는 것 보다, 아키텍쳐는 믿을만하고 성능 나오는 ARM같은 아키텍쳐를 사용하고, 주요 기능의 기술 개발에 투자하는 것이 좋을 수 있다는 이야기였다.

나 같은 특이한 것을 좋아하는 개발자는 ARM이나 x86과 같은 대기업 주도의 제품보다 새롭고 창의 적인 것을 좋아하다 보니 RISC-V에 호감이 많이 가지만, 생업이 우선이다 보니 현재로선 RISC-V를 밀 용기가 나지 않는다. 결국 현재 RISC-V제품으로는 저가형 일부 모델에만 채용하고,  차기 제품으로는 다시 ARM 아키텍쳐를 검토하고 있는 중이다.

처음에는 미미했던 open source의 linux 가 급 성장 한 것 처럼, RISC-V도 지금은 미미하지만 어느 정도 때가 무르익으면 급성장 하지 않을까 하는 생각을 가지고, 앞으로도 지켜볼 생각이다.

CIF 480 Embedded DVR 개발기

우여 곡절 끝에 X86으로 DVR을 완성하고 한숨 돌렸을 때였다.

개발 하고 나서 보면 반성할 점도 많고 후회되는 부분도 많은 제품이었다.

다행인건 , 그렇게 해서라도 잘 동작은 해줬다는 것이었다.

시간이 지나고 새로운 DVR 개발에 대한 요청이 들어왔다.

기간은 6개월,  당시 TOP3 안에 드는 보안업체에 주력 납품될 H.264 코덱 지원하는 DVR개발이었다.

성능은 CIF480 FPS, 당시 그 정도 성능을  내는 저가형 Embedded 제품은 없다고 봐야 하는 것과 마찬가지였다. 아직  hisilicon 칩이 라인업과 성능이 애매하던 시절이었다.

가능성을 조사를 하기 위한 한달의 여유를 경영진에 요청하였다.

일단 코덱의 경우 이전 제품을 만들면서 Softlogic 사와 좋은 관계를 유지하게 되어 , 신형 H.264 코덱에 대한 정보를 받을 수 있었다.

Softlogic사의 코덱인 Solo6110이 새로 출시 될 예정이었고, 압축, 재생 성능과 비디오 출력 기능이 있어 코덱 + 비디오, OSD  기능을 한번에 해결할 수 있었다.

다음은 SOC였다. (메인 CPU)

Solo6110 개발용 EVK 에 장착된 SOC는 프리스케일사의 Power PC 계열의 SOC였다.

이것으로 개발하면 초기 개발은 비교적 쉬워지겠지만 몇 가지 이유가 마음에 걸려 다른 SOC를 찾기로 했다.

일단, 가격이 비싸다. 당시 해당 SOC는 20$ ~ 30$ 가량 하던 SOC로 목표 금액인 200$ 에 맞추기 위해서는 SOC가 차지하는 비중이 너무 컷고, 칩이 크다보니 주변 구성 칩들도 가격이 적지 않았다.

그리고 Big-endian 이었다. 나는 PC 친화적인 방향으로 하여 개발 편의성과 PC 와 연동을 쉽게 하는 것을 목표로 삼고 있었기 때문에, Little-Endian 을 선호하였다.

SOC를 선정하기 위해 아래와 같은 조건의 SOC를 팀원들과 함께 찾아보았다.

1. 가격이 15$ 이하일것

2. Little endian 일것

3. PCI bus 필수 지원 (Solo6110 코덱이 PCI BUS)

4. SATA 지원 (하드디스크 지원 및 백업용 ODD 지원)

마음에 쏙 드는 칩은 없었고, 지금도 그렇지만 문서상 사양과 실제 사용 가능한 사양이 일치하지 않는 경우도 많았다.

여러 칩 벤더의 영업분들과 미팅을 하였고, Cortina 사의 DS3516으로 결정하였다.

칩 사양은 아래와 같았다.

CPU: ARM9TDMI

clock: 200Mhz

RAM TYPE: SDRAM

PCI BUS: 있음

USB : 2.0

SATA : 3G (2gen)

가격 : 8$

Power PC에 비하면 매우 부족한 CPU 성능이었지만, 다른 부가 기능들이 충분히 만족하였으므로, 부족한 CPU성능을 최적화로 극복해 보기로 했다.

부족한 성능을 극복하기 위하여 이번에도 Solo6110의 드라이버를 직접 개발하기로 했다.

DVR의 제일 많이 사용하는 데이터 전송인 압축된 데이터 전송, OSD 출력에 CPU 의존성을 최대한 낮추기 위하여 PCI BUS MASTER DMA를 최대한 활용해야만 했다.

덕분에 DVR의 엔진과도 같은 상당한 기능을 Solo6110 드라이버에서 담당하게 되었다.

덩치 큰 드라이버 개발도 쉽지 않았지만, 생각보다 CPU의 제약 사항도 많았다.

ARM9TDMI 의 성능 한계 상 나눗셈 연산이 매우 느렸고, unaligned memory access 를 지원하지 않아, 데이터를 읽을 때에는 반드시 변수 크기의 배수 주소에서 읽어야만 했다.

무슨 뜻이냐면, 32bit int 형 변수를 읽으려면 32bit는 4byte 이므로 4의 배수 포인터에 있는 변수만 읽을 수 있고, 4의 배수가 아닐 경우 읽은 값이 깨져서 들어오거나 일부 CPU는 unaligned exception error 가 발생한다.

평소에는 컴파일러가 변수 크기에 맞춰 주소 정렬을 해주어 상관 없지만, 통신 등으로 binary 데이터를 분석 할 때에는 정렬이 되어있지 않는 경우를 대비하여 정렬된 주소에 한 바이트 씩 복사한 후 값을 읽어야 한다.

우여곡절 끝에 기본 기능을 완성하고 백업을 위한 ODD(광학 드라이브, CD라이터나 DVD라이터)를 연결할 차례가 되었다.

여기서 한번 뒤통수를 맞게 된다. SATA포트에 장착한 DVD Writer 가 동작하지 않는 것이었다.

확인 결과, DS3516은 분명 SATA를 지원하지만, 프로토콜을 하드디스크를 위한 ATA 만 지원하고, ODD 드라이브를 위한 ATAPI를 지원하지 않는 것이었다. 

이미 샘플보드를 만든 상황에서 급하게 비상 회의를 열고, PCI 버스를 확장하여 SATA컨트롤러인 sil3512를 추가하기로 한 것이다.

긴급으로 칩을 수배하여 수정된 보드에 다시 DVD Writer를 작동 시켰다.

이번에는 데이터가 깨지기 시작하는 것이었다.

확인 결과 DS3516는 PCI 의 burst 전송이 512 byte 이상 되면 데이터가 깨지는 현상이 발생하는 문제가 있었던 것이었다.

두 번째 난관은 비교적 평온하게 해결했다. 저가형 CPU다 보니 워낙 난관이 많았다 보니, 하드웨어 수정이 아닌 펌웨어나 소프트웨어 수정 작업은 그리 크게 느껴지지 않은 것이었다.

결국 DVD Write 하는 펌웨어, 소프트웨어도 직접 개발하여 PCI burst 를 512byte까지만 사용하도록 제약을 하였고, 직접 개발하게 되었으니 여기 서도 CPU를 최대한 쓰지 않게 하기 위하여 일반적인 DVD 백업처럼 iso 이미지 파일을 만든 후, 전송하여 굽는 방식이 아닌, 실시간으로 생성하여 iso 이미지를 저장할 공간 확보를 할 필요가 없도록 만들어, 백업 시간을 대폭 줄였다.

느린 CPU로 이것이 가능 한 이유는 DVD-writer들이 buffer under-run 방지 기술이 적용되어서 타이망의 제약을 받지 않아서 이기도 했다.

전화위복이라 하였던가, DVD-write 기능 직접 개발로 인해, 힘은 들었지만, 개발된 제품은 DVD backup이 타 제품보다 빠른 제품으로 인정받게 되었다.

중간에 예상치 못한 문제로 개발 기간도 2개월 가량 추가 되었고, sil3512 관련 부품이 추가되어 원가가 조금 오르긴 했지만, 목표했던 200$보다 저렴한 제품을 만들 수 있게 되었다.

다행히도 제품은 성공적으로 개발되어 보안회사에 무사히 납품할 수 있게 되었다.

척박한 중소기업 고군분투기 - 2

팀장이 자신감을 얻고 다른 회사의 스카웃 제의를 받고 떠났고 나와 하드웨어 단 두 명만 남은 상태에서, 사장님께선 나에게 제안을 하셨다. 너가 팀장이 되어 보라고.

아직 30이 되지 못한 20대 말 나이로선 파격적인 제안이었다.

젊은 나이에 작지만 연구소 탑이 된 나에게는 기쁨과 연구소 운영에 대한 두려움으로 가득 찬 상태였다.

우선 사람을 구해야 한다는 생각에 주변 인맥을 동원하여 젊고 의욕 있는 사람들을 영입하고 채용하여 나를 포함해 6명의 팀을 구성할 수 있었다.

연구소를 운영할 인원을 만드는 고비는 넘어갔지만, 개발한 제품에 대한 결과물을 내야 하는 것과 불러온 사람들에 대한 책임감이 중압감이 되어 버렸다.

회사에서 야근을 밥 먹듯 하게 되었고, 관리부에 부탁하여 야전 침대를 갖춰 놓고, 월요일에 출근하여 수요일에 집에 가 씻고 옷을 갈아입고 오고, 목요일에 출근해 토요일에 퇴근하는 것이 일상이 되어버렸다.

정말 많은 것을 공부하고 개발하였다.

윈도우용 디바이스 드라이버를 개발하였고, 최초로 EDMA 를 적용한 PCI 칩을 이용하여 page 단위의 bus master 를 구현하였고, 외주 개발을 맡긴 소프트웨어 wavelet 영상 코덱이 성능과 안정성이 나오지 않자, 예전에 공부했던 mpeg 을 기반으로 MMX 가속을 지원하는 소프트웨어 코덱도 개발하였다.

책임감과 열정은 나의 지식의 폭을 넓히는 것에 많은 도움이 되었고, 결과물도 나쁘지 않게 나오기 시작하여 안정되는 듯 하였지만, 기업 경영이라는 것은 그것 만으로 잘 되는 것은 아니었다.

가격 비싸고 운용이 힘든 PC DVR 제품들이 밀려나고, 값싸고 튼튼하고 다루기 쉬운 Embedded DVR이 대세가 되어 버린 것이었다.

계열 사업인 빌딩자동화, CATV 사업 역시 시대에 뒤쳐져 회사는 어려운 상황이 되었고, 급여도 재 때 들어오지 않게 되어 힘들어 하는 연구원들을 감당할 자신이 없어진 나는 퇴사를 결정하게 되었다.

실적이 좋은 일부 연구원은 지인을 통하여 아는 회사에 입사 시켰지만, 대부분은 남게 되었고, 미안한 마음과 밀린 급여로 인한 생활고의 한계를 느끼며 나오게 되었다.

또 한번 회사 일로 마음의 상처를 입게 된 것 같다.

지금은 50의 나이지만, 나는 사업하기에는 멘탈이 강하지 못하다는 한계를 알고 있기 때문에 개인 사업은 엄두도 못 내고 있다.

결혼은 안 했지만, 나만 바라보고 서울로 올라온 어머니와 동생들의 고생을 덜기 위해서라도 빨리 직장을 찾아야 했고, 면접 보러 다닐 때 마다 겪게 되는 연봉 줄다리기를 하던 중, 제일 원만하게 진행된 안양의 위성 세톱박스 업체에 선임연구원으로 들어가게 되었다.

급여가 밀리지 않고 나온다는 것 만으로도 살 것 같았다.

연구소는 연구소장님과 기획을 담당하는 책임, 하드웨어 담당하는 책임과 선임, 막내 연구원 , 그리고 나 6명이었다.

이 중 펌웨어를 개발할 수 있는 사람은 나밖에 없었다.

당시 사용하던 OS는 ATi (비디오카드의 ATI가 아니다) 누클리어스라는 RTOS였다.

처음 다뤄 본 OS와 SOC 였지만, OS개발이나 마이컴 , 디바이스 드라이버 개발을 해본 감을 활용하니 생각보다 적응이 빨랐고, 1달 반정도 후부터는 결과물을 내기 시작했다.

3개월 쯤 되어서는 새로운 SOC에 리눅스를 탑재하기 위하여 부트로더를 포팅도 할 수 있게 되었다.

살만해 지니, 다니고 있는 회사의 현실이 눈에 들어오기 시작했다.

팀장의 책임의 무거움에서 해방된 후련함을 느끼면서 선임 연구원으로서 회사를 다니고, 할일 하고 정시 퇴근 했던 나에게 슬슬 야근하라는 압박이 들어오기 시작했다.

그 시절이 그런 것이었는지, 그 회사가 그런 것인지 , 일이 없어도 회사에서 야근하면서 상사들을 외롭지 않게 해주는 것이 미덕인 분위기가 나에게는 매우 불편하게 느껴졌다.

당시 서울 북쪽인 은평구에서 안양까지 편도 2시간 , 왕복 4시간 거리를 대중교통으로 출퇴근 했던 나에게 야근은 회사에서 자고 가라는 뜻이나 다름 없었다.

야근해 달라는 성원에 하루 큰 맘 먹고 야근을 했지만, 해야 할 일에 대한 계획이나 일정 관리가 없었던 탓에 딱히 할 일은 없고 간간히 소장님과 책임들이 심심하지 않게 잡담이나 나눠 주는 것 외에 할 일은 없었다.

한번 해본 야근은 실망만 커졌고, 생각보다 위성 세톱 박스에 대한 흥미가 떨어지고 있던 중, 해드헌팅 업체로 부터 연락을 받게 되었다.

----

lepton 3.1 개발 기행

 어느 날 회사로 부터 lepton 3.1을 이용한 열화상 네트워크 카메라를 개발하자는 결정이 내려왔다.

예전 회사에서도 사용을 위하여 타진은 한 적이 있었지만 높은 가격으로 인해 다른 모듈이 선택 되는 것이 자주 있었다. 최근 160에 한정하여 합리적인 가격이 되었다 한다.

드디어 밀당만 하던 lepton이 나와 이렇게 인연을 맺게 되었다.

합리적인 가격 제품이 목표였기 때문에 SOC는 Eyenix의 EN675로 하였다.

아직 아쉬운 점도 많지만, 그에 비해 장점 및 가격 대 성능 비가 매우 좋은 제품이다.

lepton은 80x60해상도의  1.X 대에 주로 보았기 때문에 큰 어려움이 없을 것으로 생각하였다.

하지만 오산이었다.

lepton 3.1 은 160x120 해상도인데 제어는 i2c, 데이터 전송은 spi로 한다.

lepton 1x의 경우 SYNC 인터럽트가 들어오면 데이터를 받아들이고, 그 중, 유효한 데이터 (ID 의 상위 비트를 확인하여)만 해당 온도 데이터만 사용하고 나머지는 버리면 된다.

lepton 시리즈는 SPI로 온도나 영상 데이터를 선택하여 전송할 수 있는데, 특이한 점은 데이터는 20fps가 넘게 전송하는데, 그 중에서 유효한 데이터만 골라서 사용하고 나머지는 동일한 데이터 복재이거나 불필요한 데이터라는 것이다.

아마도 원래는 20fps 넘게 출력이 가능하지만, 수출 제약으로 9fps 보다 밑으로 전송하기 위해서 나머지 프레임을 막아버린 것이 아닌가 생각이 된다.

80x60해상도의 lepton 1x는 적당히 SPI로 데이터를 받아들이면서 유효한 데이터만 골라 사용하면 되는데 lepton 3.x 는 더 큰 난관이 존재한다.

전송 단위 크기를 lepton 1x를 그대로 사용하기 때문에, 원래는 160x120 해상도인 19200 픽셀 씩 전송해줘야 하는데, 80x60 크기인 4800 pixel 씩 전송한다.

즉, 그림 한 장을 4조각으로 잘라 전송하는 것이다.

그림 4장이 연속으로 온 후 lepton 1x와 마찬가지로 불필요한 데이터를 전송하다 다시 주기가 되면 그림 4장을 연속으로 전송한다.

그러면 그림 4장을 받아 조립하여 사용하면 그만 이라 생각했지만 실수였다.

80x60은 데이터 전송 하나가 하나의 완성된 그림이기 때문에 한 프레임 정도 놓쳐도 다음 프레임을 받아 표시하면 된다. 하지만 160x120인 lepton 3.x 는 4프레임이 연속으로 받아야 한 장면이 완성되기 때문에 중간에 하나라도 빠지면 다음 4프레임 모두 잘 받을 때 까지 기다리거나 다른 프레임과 함께 조립하여야 하는데 이 경우 대상이 움직임이 있으면 영상 찢어짐 현상이 발생한다.

SPI로 그림 4개 연속으로 받아오는 것이 뭐가 그리 어렵나 생각할 수 있는데, SPI 통신 자체는 어려운 것이 아니지만, 가져오는 타이밍에 제약이 걸려 있다면 이것은 문제가 된다.

보통 lepton에서 데이터를 가져올 때 GPIO3번에 SYNC 출력으로 설정하고, SYNC 신호가 들어오면 3ms 이내에 SPI로 데이터를 가져와야 한다.

lepton의 매뉴얼을 보면, lepton은 타이밍과 통신에 매우 민감하니 lepton이 연결된 i2c와 spi에 다른 기기를 연결하지 말고 단독으로 사용하는 것을 권장한다고 써있을 정도이다.

시험 삼아 SYNC 신호 후 타이밍을 벗어나 SPI 요청을 하면 매뉴얼에서 경고한 것과 같이 0x00 이나 0xFF 데이터가 잔뜩 들어오게 된다.

타이밍이 맞지 않을 경우 SPI데이터는 깨지며, 최악의 경우 재 동기화라 하여 lepton과 SOC의 SPI 통신 간 동기화 작업을 해야 한다.

아실 분은 아시겠지만, 리눅스의 context switching 주기는 10ms 간격이다.

보통 SPI 드라이버를 개발 할 때 여러 User application으로부터 들어오는 요청들을 순차적으로 처리하기 위하여 예약을 실행하고, kernel thread에서 순차적으로 수행하는 방식을 사용한다.  즉 요청 시 10ms 의 대기를 고려하여 개발해야 한다는 뜻인데, 이는 lepton의 허용 범위를 넘는 상황이다.

ST micro와 같은 micom의 경우 user application과 kernel 과의 경계가 없어 이런 고민을 할 필요가 없지만 linux 환경에서는 달랐다.

이를 해결하기 위해, 어쩔 수 없지 linux의 기존 SPI 드라이버를 제거하고, leptop 전용 드라이버를 개발하기로 했다.

자원을 dts로 설정하는 platform 기반 드라이버로 설정하고, 리눅스에 입력할 dts에 lepton항목으로 자원을 할당했다.

자원으로는 사용할 대상의 SPI 레지스터들과 interrupt와 SYNC 입력을 받을 GPIO를 설정하였다.

user application으로 부터 요청은 ioctl로 받도록 spi 가 아닌 misc 드라이버로 등록하였고,

gpio interrupt를 설정하여 GPIO interrupt가 발생하면 예약된 버퍼 들 중 빈 버퍼로 SPI DMA 전송이 수행되고, DMA 전송이 완료되면 SPI interrupt가 발생하여, 버퍼 입력이 완성되었음을 을 marking하고 다음 SYNC 인터럽트를 대기하는 방식으로 드라이버를 개발하였다.

결과는 성공이었다. 스코프로 파형을 보면 SYNC 가 발생하고 SPI 클럭과 데이터가 1ms 가량 내에 시작되는 것을 볼 수 있었다.

데이터도 다행히 빠지지 않고 잘 들어와 문제 없이 출력 되었다.

초 당 9 fps 도 되지 않는 모듈에 이렇게 까지 공을 들이는 것은 뭔가 아이러니 하지만, 좋은 경험을 했다고 생각하기로 했다. 

CPU bit별 발전에 따른 변화

 80년대 부터 컴퓨터를 접해본 나로서는 개인용 컴퓨터 기준으로 8bit ~ 64bit 까지 고루 겪어보게 되었다.

컴퓨터에 관심이 많아 개발을 일찍 시작하게 되면서 CPU에서 있다가 사라진 것들도 보개되고 반대로 없다가 생겨난 것도 보게 되었다.

아직 128bit 는 범용 CPU에 적용되려면 한참 걸릴 것 같으니 지금까지 겪어왔던 개인용 PC의 CPU들의 특징을 정리해 보려 한다.

​

[8bit CPU]

처음 접한 컴퓨터는 주로 MSX와 Apple 로 나뉘던 8bit CPU기반 PC들이었다.

CPU로 보자면 Z80과 mod6502 로 양 분 되던 시기 였다.

이들의 공통적인 특징은 기본 연산이 8bit 라는 점, 곱셈과 나눗셈 기능이 없다는 점, 그리고 일부 CPU (Z80)의 경우 IO 포트 영역이 따로 있다는 점으로 생각 된다.

​

CPU가 제어 가능한 주소 영역의 크기는 CPU의 bit수를 따라 가는 것이 일반적이다. 8bit CPU는 기본 연산이 8bit이기 때문에 주소 공간도 8bit 가 일반적이어야 겠지만, 아무리 가정용 컴퓨터라 하더라도 256byte (8bit = 256)로 소프트웨어를 운용한다는 것은 너무 심한 한계인 것이다.

그래서 일반적으로 8bit CPU들은 주소영역 제어만 예외적으로 16bit를 사용하고, 이를 위하여 일부 주소 제어 관련 레지스터들을 16bit로 만들어 놓았다.

​

일부 PC의 경우 16bit (64Kbyte)의 한계를 넘기 위해서 paging 방식을 사용하였다. 여기서 paging은 요즘 CPU에서 가상 메모리를 위해 사용하는 paging 과 결과적으로는 유사하지만, CPU가 아닌 외부장치의 도움을 받아 동작하는 paging이라 보면 된다.

MSX의 경우 16Kbyte 단위로 주소 공간을 나누어 연결되는 RAM이나 ROM, 주변기기를 교체하여 사용할 수 있도록 하여 일부 기종은 512Kbyte라는 초기 16bit PC와 맞먹는 RAM을 장착하기도 하였다.

또한 여담이지만 이 물리적 페이징 기능을 사용하여 (이것도 엄연한 페이징이므로) 멀티 테스킹을 구현한 OS도 있었다.

​

[16bit CPU]

개인용 컴퓨터, 게임기가 활성화 되면서 CPU는 더이상 군이나 기업을 위한 것이 아니게 되었고, 많은 CPU 제조사들이 가종용, 게임용 CPU를 경쟁적으로 출시하였다. 이때 눈에 띄는 두가지 CPU가 있는데, 8086/8088과 mc68000 이었다.

80x86 시리즈와 68000 시리즈는 같은 16bit지만 가는길이 너무 달랐다.

8086의 경우 16bit 지만 주소공간은 20bit를 가지고 있었고, Z80처럼 부족한 주소공간을 배려하여 I/O 포트 공간이 별도로 있었다.

68000의 경우 버스만 16bit 였고, 레지스터 및 연산은 32bit였다.

주소 공간은 24bit로 전체적으로 8086을 압도하고 있었다.

하지만 8086을 만든 intel은 상위 모델 개발에 힘을 쓰는 것이 아닌, 8bit PC와 경쟁하기 위하여 원가절감에 열을 올리고 있었고, 결과 나온 제품이 외부 8bit bus를 사용한 8088 이었다.

MS 창립자인 빌게이츠 마저 메모리 640Kbyte 면 누구나 문제없이 쓸수 있다 라고 할정도 였으니...

기술적으로는 68000 이 선도하고 있었지만, PC시장에 자리를 잡아버린 8086 으로 진입이 어려워져, 주로 게임기나 워크스테이션 등 마이너 한 영역에서 사용되게 되었다.

참고로 mc68000은 이전 모델인 6800의 상위 모델이라는 뜻도 있지만, 칩 제조에 사용된 트렌지스터 수가 68000개라 이름이 그렇게 결정되었다는 이야기도 있다.

​

[32bit]

16bit 치고 제약이 심한 8086/8088 은 그 한계가 빨리 왔다.

업무용으로 사용하기 때문에 적은 데이터를 빠르게 처리만 하면 된다라고 생각했던 intel이었지만, 멀티미디어라는 시대를 만나면서 생각을 바꾸지 않을 수 없었다.

중간에 80286이라는 메모리 용량을 16Mbyte까지 늘릴 수 있는 16bit CPU를 만들었지만, 기존 소프트웨어도 호환이 안되고, 용량이나 속도가 압도적으로 빠른것도 아니었기 떄문에 보호모드에 대한 시험 작품이나 좀 더 빠른 8086으로 만족해야 했었다.

이 후 칼을 갈던 intel은 80386이라는 걸출한 32bit CPU를 만들어 내었다.

당시 32bit CPU들이 서버용으로 많이 나와있었고, MC68000은 이미 32bit의 기반이 되어있었기 때문에 살짝 업그레이드 하여 완벽한 32bit 모델을 내놓았지만, PC 시장에서는 80386의 경쟁상대가 되지 못하였다.

바로 16bit 호환성 때문이었다.

32bit는 주소공간이 기본적으로 4GByte 나 되었기 때문에 당시 사람들은 이번에야 말로 이보다 큰 주소공간이나 메모리를 쓸 일은 없을것이라 생각했다.

16bit CPU와 32bit CPU의 큰 차이를 말하라 한다면 CPU 차원의 paging 지원으로 생각 한다.

이때부터 PC는 가정에서 게임이나, 특수한 소프트웨어 하나를 돌리는 빈도보다 작고 생활에 자주 쓰이는 소프트웨어를 쓰는 빈도가 높아지기 시작했다.

그 큰 메모리 공간에 작은 소프트웨어 하나만 실행시키기에는 CPU 성능과 메모리를 낭비하는 것이나 다름 없었다.

이때 부터 업체들은 작은 프로그램들을 동시에 여러개 실행 시킬 수 있는 멀티테스크를 지원하는 OS개발과 이를 쉽게 사용하기 위한 GUI를 사용하기 시작했다.

16bit 시절부터 일부 CPU에서 셀렉터 개념으로 메모리의 구간을 지정하여 나누어 쓸 수 있는 기능을 제공하였지만, 여러 프로그램을 동시에 돌리는 효율이 매우 좋지 않았다. 이를 극복할 수 있는 것이 paging이었다.

​

여러 업체들이 멀티 테스킹 OS를 지원하기 위하여 mmu (memory management unit)을 탑재하기 사작하였고, intel은 진심으로 multi tasking을 지원하기 위하여 tss (task state segment)와 16bit 소프트웨어를 multi taske 하기 위한 v86모드를 지원하였다.

새로운 32bit를 지원하면서 mmu도 내장하고 multi task도 잘 지원하면서 기존 16bit 소프트웨어도 활용할 수 있는 CPU니 PC 분야에서는 이를 대항할 CPU가 없을 정도였다.

당시 RISC와 CISC 간의 효율성 논란이 심하기도 하였는데, 80386이 CISC라는 점을 들어 RISC CPU에서 80386을 빠르게 애뮬레이션 할 수 있다고 호기롭게 나서는 개발 업체도 있었지만, 이는 RISC와 CISC의 장단점을 제한된 상황에서 생각한 오산이었다.

실제로 나온 제품은 사용하기 어려울 정도로 느렸고, 이런 호환성 이야기는 지금도 간간히 나오지만, 여러세대 전의 CPU가 아닌 이상 최신 CPU를 빠르게 애뮬레이션 하는 CPU는 아직까지 보지 못했다.

​

본론으로 돌아와 GUI가 활성화 되면서 사람들은 멀티 미디어에 관심을 가지게 되었고, 이는 CPU 및 하드웨어 , OS 개발자들에게 시작되는 지옥의 서막이었다.

​

멀티미디어 데이터의 특징은 일부 복잡한 연산도 있지만, 그보다 더 필요한 것이 단순한 대량의 데이터 연산 및 출력이었다.

그래픽 카드들은 경쟁하기 위해 1년도 되지 않아 더 높은 해상도와 색상을 지원하는 그래픽 카드를 쏟아 내었고, CPU와 메모리는 높아진 해상도와 색상으로 인해 메가 단위 용량의 그래픽 데이터를 전송하고 출력하느라 쉽게 한계에 다다르게 되었다.

이 후 32bit CPU들은 멀티미디어 가속을 위한 기능 위주로 발전을 하게 된다.

8bit 시절 64Kbyte 메모리에서 4Mbyte 면 어마한 차이가 있었지만, 겨우 1024x768해상도의 2 ~ 3Mbyte 가량 하는 그림 한장이면 용량이 반이상 차버리게 되었다.

킬로바이트 시절이 엇그제 같은데 멀티미디어가 등장하면서 시대는 Mega를 건너뛰고 Giga를 요구하게 되었다.

​

[64bit]

32bit 라는 4Gbyte의 주소공간으로 한계에 다다르자 intel 은 PAE (물리주소 확장)등으로 발악을 해보고, 새로운 64bit CPU 개발로 판을 바꿔보려고 한 시도를 할 때, AMD에서는 AMD64라는 새로운 규격으로 시장을 흔들었다.

64bit CPU는 일부 서버용 CPU를 제외하고는 32bit 시절보다 빨리 활성화 되진 않은 것 처럼 느껴진다.

​

생각라기로는 mips 나 arm , power 등 다른 CPU들은 PC 시장에서 밀려나면서 주로 임베디드 시장을 바라 봤는데, 임베디드 시장에서는 멀티미디어 장비가 아닌 이상 32bit로도 매우 넘치는 사양이었다. 현재까지도 임베디드 시장에서는 8bit CPU도 간간히 쓰일 정도인데, 64bit는 불필요한 고퀄리티라 할수 있었다.

하지만 스마트 폰이 대중화 되기 시작하면서 PC의 기능을 스마트 폰에서도 같이 쓰기 시작하자 스마트폰용 CPU들이 64bit로 넘어오기 시작했다.

​

64 bit 주소공간은 18446 엑사 바이트의 방대한 크기를 지원하기 때문에 초기에는 64bit 주소를 다 쓰기 어려워 40bit 만 사용하는 CPU들이 주로 나왔다.

하지만 딥러닝 등 대량의 데이터 처리가 필요한 AI나 빅데이터 처리가 필요해 지면서 48bit 지원으로 늘어나더니, 지금은 64bit 다 지원하는 CPU도 나오기 시작하고 있다.

​

[없어지는 것들]

CPU가 이만큼 진화하면서 불필요해지고 없어져 가는 것들도 생기게 된다.

​

- 1byte 디버깅 소프트웨어 인터럽트

8086 시절, 코드를 디버깅 하기 쉽게 하기 위하여 intel에서는 0xCC 1byte 로

int 3 이라는 소프트웨어 인터럽트를 호출하는 명령을 만들었다.

코드를 디버깅 하기 위하여 원래 코드 값을 백업해 두고 그자리에 0xCC 한바이트

만 집어 넣으면 브레이크 포인트를 걸을 수 있는 당시로선 효과적인 도구였다.

하지만, 보안으로 인해 실행 코드 영역에 쓰기 작업이 금지되는 요즘 시절에

위와 같은 디버깅 방식은 효율이 좋지 않고, CPU에 디버깅 레지스터들이 지원

되면서 64bit에 와서는 해딩 기능이 삭제되었다.

​

- io port 영역

주소 영역이 부족하던 시절에는 주변기기 장착을 위해 별도의 io용 주소 영역을

만들었었다. 하지만, 메인 주소공간이 빠르게 넓어지고, 별도 IO 공간 구현에

자원 낭비를 하는 것이 비효율적이 되자, 지금은 사라지고 있다.

​

- tss

80386이 나왔을 때 multi task 를 보다 빠르게 구현하기 좋은 도구였으나,

멀티미디어, AI 등 다양한 가속이 나오고 io port 영역 마저 사라지는 추세에서는

유연하지 못한 tss 는 불필요하게 되었다. intel도 64bit에서는 형식상 유지만

하고 실질적인 multi task에서는 사용하지 않고 있다.

​

- inc , dec

c 언어에서 보면 i++, i-- 와 같은 하나씩 증가하거나 감소시키는 명령이 있었다.

생각 보다 사용빈도가 높아 intel에서는 이를 CPU 차원에서 지원하여 보다 빠른

실행속도를 구현하였으나, 근래에 들어와서는 생각보다 효율이 없어 64bit 부터

없에는 추세이다.

​

- selector 기반 보호모드

16bit 시절 paging 을 쓰기전에 나왔던 보호모드는, 호환을 이하여 유지는

하였지만, 지금은 다들 flat 모드 위주로 사용하기 때문에 굳이 유지해야 할

필요가 없는 기능이 되었다. 64bit에서 사라지는 추세이다.

​

- 16bit, 32bit 호환 모드

더 이상 16bit 시절 소프트웨어나 구형 32bit 소프트웨어를 운영할 필요가

없어지면서, 64bit에서는 해당 기능들을 삭제해 가는 추세이다.

intel 도 x86S 라는 16bti, 32bit 호환모드를 제거하는 모드에 대한 표준안을

만들면서 준비하는 중이다.

​

쓰다보니 거의 CPU 변천사가 되어버렸다.

넋두리 처림 나열된 내용을 보면 내 글 실력도 많이 부족하다는 것을 느낀다.

계속 정리하며 글을 쓰다 보면 언젠가 실력이 늘지 않을까 생각한다.