Xillybus의 "Hello, world" 테스트
이것은 Xillybus를 시작하기 위한 세 번째 단계입니다. Xillybus를 포함하는 bitstream은 이미 FPGA에 로드되어 있고 driver는 host에 설치되어 있습니다. 이제 간단한 테스트를 할 차례입니다. 이 테스트의 목적은 device files가 생성되었고 작동하는지 확인하는 것입니다.
이 페이지에서는 Linux host의 Xillybus 에 대해 설명합니다. Microsoft Windows에 대한 유사한 페이지가 있습니다.
여기서는 PCIe 와 함께 Xillybus 에 초점을 맞추겠지만 XillyUSB와 모든 것이 거의 동일합니다. 차이점은 이 페이지 하단에 나열되어 있습니다. Xillinux의 경우 PCIe와 직접 관련된 주제를 제외하고 모든 것이 동일한 방식으로 작동합니다.
이 항목에 대한 자세한 내용은 Getting started with Xillybus on Linux를 참조하십시오.
PCIe device가 감지됩니까?
가장 먼저 확인해야 할 것은 컴퓨터가 FPGA를 PCIe device로 인식하는지입니다. 이 목적으로 "lspci" command를 사용합니다. 이 command는 컴퓨터가 PCIe bus에서 찾은 모든 devices를 보여줍니다. 때로는 매우 긴 목록입니다.
예를 들어, 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"입니다. 이것은 이것이 Xillybus device임을 나타내는 Device ID입니다.
lspci의 출력에 그러한 행이 없으면 FPGA에 문제가 있는 것입니다. 종종 그 이유는 FPGA에 어떤 bitstream이 로드되는지에 대한 혼란 때문입니다.
driver가 제대로 시작되었습니까?
다음 단계는 driver의 상태를 확인하는 것입니다. 가장 쉬운 방법은 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"라고 표시된 행은 driver가 Xillybus를 성공적으로 초기화했음을 확인합니다. 이 행이 없으면 driver초기화에 문제가 있는 것입니다.
Xillybus와 관련된 kernel log 의 다른 행이 있는 경우 무엇이 잘못되었는지 설명하는 데 도움이 될 수 있습니다. 이것은 일반적으로 FPGA의 logic에서 발생하는 문제입니다. 특히 FPGA 의 PCIe block이 잘못 구성되었을 때 이런 일이 발생하는 경향이 있습니다. 예를 들어 demo bundle에서 PCIe block 의 매개변수를 변경하면 driver가 제대로 초기화되지 않을 수 있습니다.
kernel log에는 "xillybus"라는 단어가 포함된 행이 없지만 lspci의 출력에는 "ebeb"가 포함된 행이 있으면 어떻게 됩니까? 이는 driver가 kernel에 로드되지 않았음을 의미합니다. 다음과 같이 lsmod 로 이를 확인합니다.
$ lsmod | grep xillybus xillybus_pcie 16384 0 xillybus_core 28672 1 xillybus_pcie
이 예는 driver가 kernel에 로드될 때 올바른 출력을 보여줍니다. 숫자(16384 및 28672)는 다를 수 있습니다. xillybus_class 도 이 목록에 나타날 수 있습니다.
이 driver를 방금 설치한 경우 컴퓨터를 다시 시작하거나 insmod를 사용하여 driver를 수동으로 로드해야 합니다.
"Hello, world"
driver는 5개의 device files를 생성합니다. /dev/xillybus_read_8, /dev/xillybus_read_32, /dev/xillybus_write_8, /dev/xillybus_write_32 및 /dev/xillybus_mem_8. IP Core Factory에서 custom IP core를 생성하는 경우 생성되는 device files 의 수와 이름 및 속성을 선택할 수 있습니다.
그러나 현재 FPGA 에는 demo bundle이 포함되어 있습니다. 두 개의 device files를 사용해 봅시다.
read_8 와 write_8사이에 demo bundle 에 loopback이 있습니다. 이것은 컴퓨터가 data를 write_8에 기록할 때 FPGA가 read_8을 통해 정확히 동일한 data를 반환한다는 것을 의미합니다. 이것은 데모용일 뿐입니다. 이 loopback에는 다른 실용적인 용도가 없습니다.
테스트는 다음과 같습니다. 컴퓨터에서 두 개의 terminal windows를 엽니다. 또는 두 개의 shell prompts를 제공하는 다른 배열을 활용하십시오. 예를 들어 두 개의 ssh connections입니다.
첫 번째 shell prompt에 다음을 입력하십시오.
$ cat /dev/xillybus_read_8
그런 다음 두 번째 shell prompt에 다음을 입력합니다.
$ cat > /dev/xillybus_write_8
이제 두 번째 terminal 에 아무 내용이나 입력하고 ENTER를 누릅니다. 동일한 텍스트가 첫 번째 terminal에 나타납니다. 이것은 텍스트가 첫 번째 device file에 쓰여진 다음 FPGA에 도달하고 마지막으로 컴퓨터로 다시 반환되는 방법을 보여줍니다.
이 예제는 간단하지만 작동 방식을 이해하는 것이 중요합니다. 특히 FPGA 의 logic이 어떻게 이런 일이 일어났는지 이해하는 것이 중요합니다. 이것은 자신의 logic을 통합하기 위한 출발점입니다.
이러한 commands가 permission denied 오류로 인해 실패하면 root로 반복합니다. 또는 이전에 제안한 대로 udev 파일을 설치합니다.
XillyUSB
XillyUSB를 사용하는 경우 위에 언급된 모든 사항이 적용되지만 몇 가지 차이점이 있습니다.
XillyUSB 에는 FPGA와의 물리적 연결 품질을 검사하기 위한 showdiagnostics 라는 도구가 있습니다. raw data link 에 오류가 없는지 확인하려면 이 도구를 사용하는 것이 좋습니다. XillyUSB가 완벽하게 작동하는 것처럼 보이더라도 이를 확인하는 것이 중요합니다. 그 이유는 USB 3.0 protocol이 raw data link에서 오류를 숨기지만 이러한 오류는 여전히 버그처럼 보이는 드문 문제를 일으킬 수 있기 때문입니다.
이런 종류의 오류를 용인할 이유가 없습니다. 솔루션은 종종 간단합니다. 예를 들어 컴퓨터의 다른 USB plug를 사용하는 것입니다.
기타 차이점:
- lspci대신 lsusb를 사용하십시오.
- driver의 modules는 xillyusb 와 아마도 xillybus_class입니다.
- driver를 설치한 후 컴퓨터를 다시 시작할 필요가 없습니다. device가 USB plug 에 연결되면(연결 해제 후) driver가 자동으로 로드됩니다.
- device files 의 이름은 약간 다릅니다. 예를 들어 /dev/xillybus_read_8대신 이름이 /dev/xillyusb_00_read_8입니다. "00" 부분은 다를 수 있습니다.