몇 달에 걸쳐 진행된 LIN controller IP RTL 설계가 끝나서 verification을 위해 체크리스트를 작성하고 있는데요, 이 글에 한 번 정리해 보려고 합니다. 혹시나 수정해야 할 부분이 있다면 메일 환영입니다!!
Verification on testbench
Register Read/Write
IP는 내부에 있는 register를 세팅하여 컨트롤됩니다. 이 register는 버스 접근을 통해 read/write 되는데요, 저는 APB bus를 기준으로 설계했습니다.
Register의 기본값이 제대로 읽히는지
Register에 값이 제대로 쓰이고 읽히는지
확인해야 합니다. 이는 모든 IP가 거쳐야 하는 가장 기본적인 testcase입니다.
Data transfer
그다음으로는 데이터 송수신이 제대로 되는지 확인해야 합니다. 저는 controller 2개를 BFM(Bus functional model)을 붙여서 연결하고 test를 진행했습니다.
BFM이 뭔지는 다음에 설명해 드리도록 하겠습니다. 쉽게 설명하자면 모듈을 컨트롤하는 core의 역할을 한다고 보시면 되겠습니다. Master tx, Master rx가 잘 되는지 확인했습니다.
Sleep, wakeup
이 controller는 다른 IP에는 없는 sleep, wakeup 기능이 있는데요, 이러한 기능들이 잘 작동하는지 확인했습니다.
Error case
마지막으로 인위적으로 error가 발생하는 case를 만들어 LIN controllor가 이상을 잘 감지하는지 확인했습니다. 제가 설정한 error case는 다음과 같습니다.
Master/Slave mode
- Bit error
- Checksum error
- Timeout error
Slave mode only
- Break error
- Sync error
- Parity error
그럼, 하나씩 자세히 알아볼까요?
Bit error
이 protocol의 byte field는 1 start bit + 8 data bit + 1 stop bit로 총 10-bit입니다. (break field 제외)
start bit는 항상 low, stop bit는 항상 high이므로 그렇지 않을 경우 에러가 발생합니다. 인위적으로 start bit를 high, 또는 stop bit를 low로 만들어서 에러를 발생시키고 controller가 이를 감지하는지 test합니다.
Checksum error
Master tx/rx 모두 마지막에 checksum check를 합니다. 만약 checksum 계산 결과가 맞지 않으면 checksum error가 발생합니다.
인위적으로 다른 checksum 값을 입력하여 controller가 이를 감지하는지 확인합니다. (Enhanced checksum, classical checksum)
Timeout error
Byte field마다 inter-byte space라는 것이 존재합니다. 이건 spec 문서를 뒤져봤는데 딱히 정의되어 있지 않았었습니다. 그래서 제가 LIN controller를 설계할 때 이전 byte field의 stop bit 상황에서 다음 byte field의 start bit로 넘어가는 조건이 LIN bus가 high에서 low로 떨어지는 것이었습니다. (byte field 사이의 inter-byte space 시간을 모르니까요;;)
그런데 어떤 이유에서든지 bus에서 신호가 들어오지 않으면 LIN slave 모듈이 작동이 이상해지는데요, 절대 이렇게 돼서는 안 됩니다. 그래서 통신 중간에 일정 시간 이상 신호가 들어오지 않으면 timeout error가 검출되고 interrupt를 발생시켜서 모듈을 초기화할 수 있도록 만들었습니다.
Break error (slave only)
앞에서 언급했듯 break field를 제외하면 stop bit 때문에 LIN slave는 stop bit 때문에 적어도 10-bit 안에 high 신호를 받게 됩니다. 오직 break field에서만 13-bit 이상의 low 신호를 받게 됩니다.
그런데 만약 slave는 break field라고 인식하고 있는데 13-bit 이내에 high 신호를 받게 되면 어떻게 될까요? 이건 slave에서 설정된 통신 속도가 master에 설정된 통신 속도와 맞지 않던지, 아니면 어떤 이유로 이 slave가 통신 중간에 참여했다고 볼 수 있습니다. (하드웨어니까 충격 같은 외부적 요인이 있을 수도 있잖아요?)
첫 번째 상황이든 두 번째 상황이든 문제가 있으니 slave controller가 에러를 검출하도록 설계했습니다.
Sync error (slave only)
Sync field에서는 slave가 항상 0x55의 값을 받습니다. 만약 값이 맞지 않으면 master – slave 간의 통신속도가 맞지 않는 상황이므로 에러가 발생합니다.
Parity error (slave only)
마지막 에러 case로 PID에서 parity 에러를 검출하도록 설계했습니다.
Slave controller는 master controller로부터 받은 PID 값으로 parity를 계산합니다. 계산된 parity와 전달받은 parity가 다르면 에러를 발생시킵니다.
FPGA test
설계한 controller를 SoC에 올려서(2 channel) FPGA 합성을 하고 데이터 통신 test를 진행했습니다.
Test without LIN transceiver
먼저는 FPGA 보드 상에서 transceiver 없이 io 핀끼리 연결해서 test를 진행했습니다. 원래는 1-wire 통신이지만 저희가 구매한 transceiver는 보드와 연결되는 부분에 TX/RX pin이 있어서 output enable을 만들어서 설계하고 보드 핀에 할당했습니다.
그래서 test 환경을 그림으로 나타내면 다음과 같습니다.
이 test는 당연히 통과했지만 다음부터가 문제였습니다;;
Test with LIN transceiver
실제 통신에서는 transceiver를 연결해서 통신합니다. Transiver는 FPGA에서 나온 digital 신호를 analog 신호로 바꿔줍니다. 그리고 1.8V 또는 3.3V인 보드 output을 실제 통신 전압인 9~18V로 바꿔줍니다. 저희는 MIKROE의 LIN CLICK 제품을 사용했습니다.
먼저 테스트 환경 그림은 다음과 같습니다.
실제 transceiver의 모습을 보면서 설명을 드릴게요.
이 transceiver는 Master와 Slave 모드를 동시에 지원하지 않더라고요, 그게 좀 아쉬웠습니다. Slave mode가 기본인데 Master로 바꾸기 위해서는 납땜해서 바꿔줘야 합니다;;; 사용하는 전압도 같은 방법으로 선택하는데, 저는 3.3V를 썼습니다. 그리고 transceiver의 전원 LED가 있습니다.
LIN BUS Connector는 실제 1-wire 신호를 주고받는 부분입니다. 연결 사진은 다음과 같습니다.
빨간 선으로 연결한 port가 LIN BUS이고 흰 선으로 연결한 부분은 VS인데, VS 때문에 고생 좀 했습니다;;;Transceiver 뒷면에는 FPGA 보드와 연결되는 핀들이 있습니다.
Transceiver의 핀 중 EN, 3.3V, GND 중 하나, TX/RX 핀을 사용합니다. WK 핀도 써야 하나 했는데 실제 테스트에 영향을 주지는 않았습니다. EN과 3.3V 핀에 3.3V power supply를 연결하고 GND에 GND, TX/RX를 FPGA에 연결했습니다. Power와 GND를 연결하면 LED 등이 들어옵니다.
처음에는 LIN BUS Connector에 있는 VS 핀에 대한 설명이 딱히 없어서 VS를 사용하지 않고 test를 진행했는데 이러면 신호가 나오지 않았습니다. 조사해 보니까 VS 핀에 reference voltage를 넣어줘야 하더라고요. 그러니까 LIN BUS는 inout인 거고 VS는 input인 겁니다. VS에 input 된 전압으로 LIN BUS 전압이 결정됩니다, 저는 10V로 사용했습니다.
그래서 transceiver를 거쳐 FPGA에 들어가는 신호는 다음과 같습니다.
그런데 한 가지 주의할 점이 있습니다. 저는 transceiver의 TX/RX는 output과 input만 나오는 줄 알았는데 transceiver RX는 BUS 신호를 그대로 내보냅니다. 그런데 TX – BUS – RX 간의 delay가 있어서 Master 입장에서 rx의 경우 문제가 발생할 수 있습니다.
이 delay 때문에 rtl 수정이 필요했는데,,,, 글이 너무 길어져서 혹시 무슨 문제였는데 궁금하시면 메일로 물어보시면 되겠습니다!!
Test with PLIN
검증 환경 세팅
이제 IP 검증의 마지막 파트입니다. 지금까지는 제가 설계한 controller끼리 연결해서 data transfer test를 진행했는데요, 다른 controller랑 연결을 해봐야겠죠?? 저는 PEAK 사의 PCAN USB PRO FD(이하 PLIN)로 test를 진행했습니다.
PLIN이 있어도 제어 프로그램이 있어야 하겠죠?? PEAK 홈페이지에서 설치 파일을 다운로드할 수 있습니다.
해당 파일을 다운로드하고 설치를 진행하는 과정에서 LIN device driver 옵션을 반드시 설정해야 제어 프로그램을 사용할 수 있습니다.
PLIN을 PC와 연결하면 아래 사진에서 보이는 빨간색 박스의 초록 등이 점멸합니다. 점멸을 확인하고 설치된 프로그램를 실행하면 아래와 같이 사용할 포트를 선택하고 master or slave를 설정하고 통신속도를 설정한 뒤 connect를 하면 파란색 박스의 초록 등이 점멸합니다. 이러면 프로그램을 사용할 준비가 끝난 겁니다.
Frame 생성 후 통신
Connect를 완료하면 다음과 같은 창을 볼 수 있습니다. 여기서 Frame을 생성하고 통신을 시작할 수 있습니다.
Tx Frame
우선 제어 프로그램에서 master로 설정하고 PID를 0x20으로 설정하겠습니다. Classic checksum과 Enhanced checksum에서 Classic으로 설정하고 Direction을 Publisher로 설정합니다, 이 말은 PLIN이 data를 보내겠다는 의미입니다. Length의 경우에는 PID에 따라 자동으로 바뀝니다.
이렇게 설정하면 Data 입력하는 부분이 활성화되는데 0x33, 0x22, 0x11, 0xCA로 설정하고 프레임 설정을 완료합니다.
Rx Frame
Rx로 세팅할 때는 Direction을 Subscriber로 설정합니다. 이럴 경우 Data 입력하는 부분이 비활성화됩니다.
Frame 설정을 끝내면 Frame 목록에 다음과 같이 frame이 생성된 것을 확인할 수 있습니다.
이렇게 frame을 확인하고 난 뒤 테스트하려는 controller와 BUS를 연결합니다. 포트는 RS232 형식이며 pin mapping은 다음과 같습니다.
연결을 위해서는 4, 5 또는 6, 9번 핀을 사용하면 됩니다.
- Pin 4: BUS
- Pin 5 or 6: GND
- Pin 9: Vref
9번 핀에 넣어줄 Vref는 테스트하려는 controller의 transceiver와 같은 voltage를 넣어줘야겠죠?? 이렇게 테스트할 환경 준비가 끝났다면 아까 생성해 준 Frame을 선택하고 spacebar를 누르면 통신이 시작됩니다. 그러면 Receive 부분에 통신 결과가 나옵니다. 아래 사진은 0x21 – master rx frame의 통신 결과입니다.
이렇게 PLIN test를 함으로써 제가 설계한 controller가 protocol spec 표준에 부합하는지 테스트해 볼 수 있었습니다. 확실히 이 방법으로 테스트하니까 제 controller 2개를 붙여서 테스트할 때는 발견하지 못했던 bug를 찾아낼 수 있었습니다.
여러 가지가 있었는데 그중 하나는 checksum 계산 방법이었는데요, data를 다 더하고 맨 마지막에 invert를 해야 하는데 안 했더라고요;; 찾아서 다행입니다. ㅠㅠ
