Xillybus의 "Hello, world" 테스트
이 글은 Xillybus 시작하기의 세 번째 단계입니다. Xillybus가 포함된 비트스트림(bitstream)을 FPGA에 이미 로드했고, 호스트에는 드라이버를 설치한 상태입니다. 이제 간단한 테스트를 해볼 차례입니다. 이 테스트의 목적은 디바이스 파일(device files)이 제대로 생성되었고 실제로 동작하는지 확인하는 것입니다.
이 페이지에서는 Linux 호스트에서 Xillybus를 사용하는 경우를 다룹니다. Microsoft Windows용 비슷한 페이지도 있습니다.
여기서는 PCIe를 이용하는 Xillybus에 초점을 맞추지만, XillyUSB의 경우도 거의 동일합니다. 차이점은 이 페이지 하단에 정리되어 있습니다. Xillinux의 경우에도 PCIe와 직접 관련된 주제를 제외하면 모든 것이 같은 방식으로 동작합니다.
이 주제에 대한 자세한 내용은 Linux에서 Xillybus 시작하기를 참조하십시오.
PCIe 장치가 인식되었나요?
가장 먼저 확인할 것은 컴퓨터가 FPGA를 PCIe 장치로 인식하는지 여부입니다. 이를 위해 lspci 명령을 사용합니다. 이 명령은 컴퓨터가 PCIe 버스에서 발견한 모든 장치를 보여줍니다. 때로는 목록이 아주 길 수 있습니다.
예를 들어, Xilinx / AMD FPGA에서 Xillybus를 사용할 때의 출력은 다음과 같습니다.
$ lspci [ ... several lines ... ] 01:00.0 Class ff00: Xilinx Corporation Device ebeb [ ... several lines ... ]
그리고 Altera의 경우에는 다음과 같습니다.
01:00.0 Class ff00: Altera Corporation Unknown device ebeb
출력은 컴퓨터에 따라 조금씩 다를 수 있습니다. 중요한 부분은 "ebeb"입니다. 이것은 디바이스 ID(Device ID)로, Xillybus 장치임을 나타냅니다.
lspci 출력에 그런 행이 없다면 FPGA에 문제가 있는 것입니다. 흔히 FPGA에 로드된 비트스트림이 무엇인지 혼동되어 이런 일이 생깁니다.
드라이버가 제대로 시작되었나요?
다음 단계는 드라이버의 상태를 확인하는 것입니다. 가장 쉬운 방법은 커널 로그(kernel log)에서 "xillybus"라는 단어를 검색하는 것입니다. 예를 들어:
$ dmesg | grep xillybus
xillybus_pcie 0000:01:00.0: can't disable ASPM; OS doesn't have ASPM control
xillybus_pcie 0000:01:00.0: Created 5 device files.
출력 형식은 컴퓨터마다 다를 수 있습니다. ASPM에 관한 행은 정상적인 것이며 오류를 의미하지 않습니다. 그런 행이 없어도 문제없습니다.
"Created 5 device files"라고 표시된 행은 드라이버가 Xillybus를 성공적으로 초기화했음을 확인해 줍니다. 이 행이 없다면 드라이버 초기화에 문제가 발생한 것입니다.
커널 로그에 Xillybus와 관련된 다른 행이 있다면, 무엇이 잘못되었는지 파악하는 데 도움이 됩니다. 대개 FPGA의 로직에 문제가 있는 경우입니다. 특히 FPGA 내부의 PCIe 블록(block)이 잘못 구성되었을 때 이런 일이 자주 발생합니다. 예를 들어 데모 번들(demo bundle)에서 PCIe 블록의 파라미터를 변경하면 드라이버가 제대로 초기화되지 못할 수 있습니다.
커널 로그에 "xillybus"라는 단어가 들어 있는 행이 전혀 없는데 lspci 출력에는 "ebeb" 행이 있다면 어떨까요? 이는 드라이버가 커널에 로드되지 않았다는 뜻입니다. lsmod로 다음과 같이 확인해 보십시오.
$ lsmod | grep xillybus xillybus_pcie 16384 0 xillybus_core 28672 1 xillybus_pcie
이 예시는 드라이버가 커널에 로드되었을 때의 올바른 출력입니다. 숫자(16384와 28672)는 다를 수 있습니다. 이 목록에 xillybus_class도 함께 나타날 수 있습니다.
참고로 이 드라이버를 방금 설치했다면 컴퓨터를 재부팅하거나 insmod로 드라이버를 수동으로 로드해야 합니다.
"Hello, world"
드라이버는 /dev/xillybus_read_8, /dev/xillybus_read_32, /dev/xillybus_write_8, /dev/xillybus_write_32, /dev/xillybus_mem_8 등 다섯 개의 디바이스 파일을 생성합니다. IP Core Factory에서 커스텀 IP 코어(custom IP core)를 만들면 디바이스 파일의 개수는 물론 이름과 속성도 직접 선택할 수 있습니다.
하지만 지금 FPGA에는 데모 번들(demo bundle)이 들어 있습니다. 디바이스 파일 두 개를 사용해 보겠습니다.
데모 번들에는 read_8과 write_8 사이에 루프백(loopback)이 있습니다. 즉, 컴퓨터가 write_8에 데이터를 쓰면 FPGA가 read_8을 통해 똑같은 데이터를 되돌려 보냅니다. 이 루프백은 단지 시연용으로만 만들어졌습니다. 실용적인 다른 용도는 없습니다.
테스트 방법은 다음과 같습니다. 컴퓨터에서 터미널 창 두 개를 엽니다. 셸 프롬프트(shell prompt) 두 개를 확보할 수 있는 다른 방법을 사용해도 됩니다. 예를 들어 ssh 연결을 두 개 열어도 됩니다.
첫 번째 셸 프롬프트에서 다음을 입력합니다.
$ cat /dev/xillybus_read_8
그런 다음 두 번째 셸 프롬프트에서 다음을 입력합니다.
$ cat > /dev/xillybus_write_8
이제 두 번째 터미널에서 아무 내용이나 입력하고 ENTER를 누르십시오. 첫 번째 터미널에 같은 텍스트가 표시됩니다. 이를 통해 두 번째 터미널에서 입력한 텍스트가 디바이스 파일로 쓰인 뒤 FPGA에 도달하고, 다시 컴퓨터로 돌아와서 첫 번째 터미널에 표시되는 과정을 확인할 수 있습니다.
이 예제는 단순하지만, 그 동작 원리를 이해하는 것이 중요합니다. 특히 FPGA 안의 로직이 어떻게 이런 동작을 만들어 냈는지를 이해하는 것이 중요합니다. 여러분만의 로직을 통합하기 위한 출발점이 바로 이것입니다.
이 명령들이 권한 거부(permission denied) 오류로 실패하면 root 권한으로 다시 실행해 보십시오. 또는 앞서 제안한 대로 udev 파일을 설치하십시오.
XillyUSB
XillyUSB를 사용하는 경우에도 위에서 설명한 내용이 모두 적용되지만, 몇 가지 차이점이 있습니다.
XillyUSB에는 showdiagnostics라는 도구가 있어 FPGA와의 물리적 연결 품질을 검사할 수 있습니다. 원시 데이터 링크(raw data link)에 오류가 없는지 확인하기 위해 이 도구를 사용하는 것이 좋습니다. XillyUSB가 완벽하게 동작하는 것처럼 보여도 이 검사를 반드시 수행하는 것이 중요합니다. USB 3.0 프로토콜이 원시 데이터 링크에서 발생하는 오류를 숨겨 주기는 하지만, 그런 오류가 드물게는 버그처럼 보이는 문제를 일으킬 수 있기 때문입니다.
이런 종류의 오류를 참을 이유가 없습니다. 해결 방법은 대개 간단합니다. 예를 들어 컴퓨터의 다른 USB 포트를 사용하면 됩니다.
다른 차이점은 다음과 같습니다.
- lspci 대신 lsusb를 사용합니다.
- 드라이버 모듈은 xillyusb와, 어쩌면 xillybus_class입니다.
- 드라이버 설치 후 컴퓨터를 재부팅할 필요는 없습니다. 장치가 (연결이 해제된 뒤) USB 포트에 연결되면 드라이버가 자동으로 로드됩니다.
- 디바이스 파일의 이름은 조금 다릅니다. 예를 들어 /dev/xillybus_read_8 대신 /dev/xillyusb_00_read_8이라는 이름이 사용됩니다. 여기서 "00" 부분은 다를 수 있습니다.