프로젝트/SoC 설계 및 프로그래밍

[SoC 설계 및 프로그래밍] 텀프로젝트 현황

아이스얼그레이 2022. 6. 15. 23:04

이번 학기에 수강중인 경북대학교 SoC 설계 및 프로그래밍 과목에서 진행중인 프로젝트에 관한 게시글입니다.

 

전문가가 아닌 사람이 작성하였고, 강의를 들으며 작성한 게시글이라 사실이 아닌 정보가 있을 수 있습니다.

 

한 달 전부터 Zynq-7000 이라는 SoC 보드를 사용해서 저포함 3명의 조원과 텀프로젝트를 진행하고 있습니다. 결과 발표를 약 1주일 남긴 현재 텀프로젝트 진행상황과 고쳐야 할 점에 대해 적어보려고 합니다.

 

이렇게 생긴 보드(Zynq-7000)를 사용해서 텀프로젝트를 진행중입니다. 꽤나 투박하게 생겼지만, 이 보드하나에 500만원 정도 한다고 합니다.. 대략적인 스펙으로는 ARM Cortex A9이라는 CPU가 탑재되어있고, 4.3인치 TFT LCD가 탑재되어 있습니다. 그리고 text lcd, 7segment, push button이 들어가 있습니다.

 

설계과정에서 크게 두 갈래로 나누어 집니다.

 

1. PL(Programmable Logic)

처음에는 Programmable이라는 말이 와닿지 않았는데, 프로젝트를 진행하면서 어느정도 이해가 되었습니다. FPGA(Field Programmable Gate Array)라는 반도체(?) 상에 무수히 많은 gate들이 들어있는데요. PL에서 verilog로 HDL을 짜면 그 동작을하는 회로가 gate level로 합성되어서 FPGA상에 실제 그 회로가 만들어지는 것 입니다.

 

 

2. PS(Processing System)

PL이 회로가 어떻게 구현되고 동작할지 기술하는 부분이라면, PS는 각 component(TFT lcd, text lcd 등)에 어떤 정보를 출력할지 처리하고 보내주는 역할을 합니다. 이때 C coding을 이용해 data를 처리하고 주고 받을 수 있습니다. 이 과정에서 AXI라는 bus를 통해 PS와 PL이 소통합니다. 말이 좀 어려운데 다음 Block diagram을 보면 PS와 PL의 관계를 이해하는데 도움이 될 겁니다.

 

 

위 사진처럼 PS와 PL이 AXI4-Lite라는 bus를 통해 소통하고(정확하게는 PS가 master이고 PL이 slave입니다.) PS에서 처리한 데이터를 각 IP에 보내줍니다. 여기서 IP는 PS와 PL의 연결을 위해 PL을 module화 한 것 입니다.

 

사실 위 그림은 많이 단순화 시킨 그림이고, 다음 그림(Block design이라고 합니다.)처럼 저 화살표 내에 수많은 input/output이 포함되어 있습니다.

 

 

3. 진행중인 프로젝트

저희 조가 진행중인 프로젝트의 주제는 TFT LCD 상에 체스게임을 구현하는 것 입니다.

 

원래 목표는 chess algorithm을 PS상에 이식해서 게임의 승패까지 판단할 수 있게 하는 것이었습니다. 하지만 생각보다 많이 많이 어렵더라구요... 그래서 chess algorithm은 걷어내고 체스판을 출력하고, 원하는 위치의 체스말을 이동하는 것 까지 구현하는 걸로 목표를 변경했습니다.

 

오늘 강의에 했던 구현한 부분까지 동영상으로 촬영해봤습니다.

 

 

신기하지 않나요??? 신기하다고 해주세요.. 저거 만드느라 C coding 진짜 오지게했습니다.

 

4. 고쳐야 할 점과 느낀 점

1. 버전 관리가 필요하다.

어쩌다보니 PS 상에 올라가는 main.c 파일을 제가 도맡아서 짜게 되었습니다. 코드를 짜다보니 함수도 많아지고 코드가 점점 방대해지더라구요. 그런데 마음은 급하고 이런 프로젝트 관리 경험이 없던터라 버전관리가 매우 힘들었습니다.

 

vscode에서도 코딩하고 vivado SDK에서도 코딩하고 그러다보니 정말 정신이 없더라구요.

 

그래서 다음에 프로젝트를 진행할 때는 git을 사용해서 좀더 체계적인 버전관리가 필요할 것 같습니다. 

 

2. 프로젝트를 같이 하는 조원과 소통이 필요하다.(진행상황과 내용에 대해)

이 부분도 이번 프로젝트에서 많이 느낀 점입니다. 일주일에 한 번 만나서 프로젝트를 진행하다보니 서로의 진행상황도 모르고, 구현하려는 내용을 다르게 알고있는 경우도 많았습니다.

 

그러다보니 설계 시간이 낭비되고 사소한 의견충돌이 생기더라구요. 그래서 프로젝트를 어느 정도까지 구현할지, 누가 어떤 파트를 맡을지 명확히하고 협업을 하는게 아주 중요한 것 같습니다.

 

3. 문서화가 필요하다.

이 부분은 시간관리 차원에서 필요한 것 같습니다. main.c도 제가 짜고 IP들을 합쳐서 unified system도 제가 처음 만들어서 이해하고 있는 내용이 많았습니다. 하지만 조원들이 모르는 내용을 한 명씩 붙잡고 알려주기에는 시간도 많이 들고, 저도 귀찮고 힘들더라구요.

 

그래서 명확하고 간결하게 개발 과정과, 코드 분석을 담은 문서를 만드는 것이 필요하다고 느꼈습니다.

 

 

뭐 이정도네요.

 

앞으로 토, 일, 월 각각 6시간씩 개발 시간이 주어지는데, 남은 시간동안 할 수 있는거 다 해볼 생각입니다.

 

결과 발표도 제가 하게 될 것 같아서 결과 발표 후 텀프로젝트 후기랑 코드 분석도 같이 해보겠습니다.