Zynq 기반 설계를 위한 공동 시뮬레이션

Xilinx Zynq 7000 및 Zynq UltraScale+ MPSoC와 같은 이기종 SoC(System-on-Chip) 장치는 고성능 처리 시스템과 최첨단 프로그래밍 가능 논리를 결합합니다. 이 조합을 통해 최적의 솔루션을 제공하도록 시스템을 설계할 수 있습니다. 사용자 인터페이스, 통신, 제어 및 시스템 구성은 프로세서 시스템(PS)에서 처리할 수 있습니다. 한편 PL(Programmable Logic)은 이미지 처리 및 산업 응용 프로그램에서 사용되는 것과 같은 병렬 특성을 활용하는 짧은 지연 시간, 결정론적 기능 및 처리 파이프라인을 구현하는 데 사용할 수 있습니다.

PS와 PL 간의 통신은 여러 메모리 매핑된 인터페이스에 의해 제공됩니다. 이러한 인터페이스는 AXI(Advanced eXtensible Interface)를 사용하여 각 방향에서 마스터 및 슬레이브 통신을 제공합니다.

그림 1. PS와 PL 간의 AXI 상호 연결을 보여주는 Zynq 아키텍처(출처:Xilinx)

구성 및 제어 기능이 PS에 의해 수행되는 경우 범용 AXI 마스터 인터페이스가 PS에서 PL로 사용됩니다. 이를 통해 소프트웨어(SW)가 레지스터를 구성할 수 있으므로 PL에서 원하는 IP 코어 동작이 가능합니다. 더 복잡한 작업에서는 추가 처리 또는 통신을 위해 PL에서 PS 메모리 공간으로 많은 양의 데이터를 전송하고자 할 수 있습니다. 이러한 전송은 고성능 인터페이스를 활용하므로 구성 및 사용에 훨씬 더 복잡한 소프트웨어가 필요합니다.

PS와 PL 간의 상호 작용을 확인하는 것은 설계 팀에 과제를 제시합니다. 2015 Embedded Markets Survey에서는 엔지니어링 팀이 직면한 주요 설계 과제 중 하나로 디버깅을 확인했으며 개선된 디버깅 도구의 필요성도 확인했습니다. 초기에는 버스 기능 모델을 사용할 수 있지만 이러한 모델은 종종 단순화되어 개발된 SW 드라이버와 애플리케이션을 동시에 검증할 수 없습니다. 모든 기능을 갖춘 모델을 사용할 수 있지만 엄청나게 비쌀 수 있습니다. 이기종 SoC 설계를 구현할 때 가능한 한 빠른 시점에 PL과 PS 요소를 함께 검증할 수 있는 검증 전략이 필요합니다.

전통적으로 검증은 초기에 개별적으로 설계의 각 요소(기능 블록)에 대해 수행되었습니다. 모든 블록을 함께 확인하는 것은 첫 번째 하드웨어가 도착할 때 발생합니다. PS에서 실행할 응용 프로그램을 개발하는 소프트웨어 엔지니어링 팀은 Linux 커널에 사용을 지원하는 데 필요한 모든 모듈이 포함되어 있고 올바른 장치 트리 blob이 있는지 확인해야 합니다. 이는 일반적으로 하드웨어 가상화를 수행하는 무료 오픈 소스 호스팅 하이퍼바이저인 QEMU(Quick Emulator의 약자)를 사용하여 확인됩니다.

한편, PL 설계를 올바르게 검증하기 위해 로직 검증 팀은 로직이 필요에 따라 작동하는지 검증하기 위해 애플리케이션 소프트웨어에서 발행한 것과 같은 명령을 생성하고 시퀀싱해야 합니다. 그러나 이러한 두 가지 접근 방식 모두 소프트웨어와 하드웨어의 진정한 상호 작용을 포착하지 못하므로 이러한 상호 작용과 관련된 오류를 감지하기가 매우 어렵습니다. 이렇게 하면 개발 일정이 지연되고 개발 프로세스 후반부에 제기된 문제를 해결하고 수정하는 데 항상 더 많은 비용이 들기 때문에 개발 비용이 증가합니다.

최종 하드웨어가 도착하기 전에 HW 및 SW 상호 작용을 확인하기 위해 중간 단계에서 개발 보드를 사용할 수 있습니다. 그러나 실제 하드웨어의 디버그는 복잡할 수 있으므로 하드웨어에 추가 계측 로직을 삽입해야 합니다. 계측 논리를 포함하기 위해 비트 파일을 다시 생성해야 하므로 이 삽입에 추가 시간이 걸립니다. 물론 이러한 구현 변경은 설계의 기본 동작에도 영향을 미치므로 문제를 마스킹하거나 디버깅 빌드에서만 명백하게 드러나는 새로운 문제를 도입할 수 있습니다.

따라서 공동 시뮬레이션을 사용하여 SW 및 HW 설계를 모두 검증할 수 있다는 것은 몇 가지 중요한 이점을 제공합니다. 개발 주기 초기에 수행할 수 있으며 개발 하드웨어가 도착할 때까지 기다릴 필요가 없으므로 디버깅 비용과 영향을 줄일 수 있습니다. 또한 이러한 접근 방식은 레지스터 및 PS와 PL 간의 상호 작용과 관련하여 더 많은 가시성을 제공하므로 프로세스 초기에 버그를 발견하고 제거하는 데 도움이 됩니다.

HW 및 SW 공동 시뮬레이션

SW와 HW 간의 Co-Simulation에는 SW 시뮬레이션 에뮬레이션 환경과 상호 작용할 수 있도록 HW 설계를 검증하는 데 사용되는 로직 시뮬레이션 도구가 필요합니다.

Aldec의 Riviera-PRO(2017.10) 출시는 Riviera-PRO와 QEMU 사이에 브리지를 제공하여 이러한 HW 및 SW 공동 시뮬레이션을 가능하게 하여 Linux 기반 Zynq 개발을 위해 개발된 소프트웨어의 실행을 가능하게 합니다.

그림 2. HW 및 SW 검증 환경 브리징(출처:Aldec)

이 브리지는 QEMU와 Riviera-PRO 간의 통신 채널을 정의하기 위해 SystemC TLM(트랜잭션 레벨 모델링)을 사용하여 생성되었습니다. SW와 HW의 동시 검증은 양방향으로 정보를 전송할 수 있는 Bridge의 능력에 의해 촉진됩니다.

이 통합 시뮬레이션 환경 내에서 엔지니어링 팀은 표준 및 고급 디버그 방법론을 사용하여 검증이 진행되면서 발생할 수 있는 모든 문제를 해결할 수 있습니다. Riviera-PRO의 경우 여기에는 HDL 내에서 중단점 설정, 데이터 흐름 검사, QEMU에서 실행되는 SW 애플리케이션에서 실행되는 코드 적용 범위 및 경로 분석과 같은 기능이 포함됩니다. QEMU의 경우 SW 팀은 Gnu DeBugger(GDB)를 사용하여 커널과 드라이버를 모두 계측하여 중단점을 사용하여 코드를 단계별로 실행할 수 있습니다.

이 공동 시뮬레이션 접근 방식은 하드웨어 시뮬레이션 환경 내에서 더 나은 가시성과 디버깅 기능을 제공할 뿐만 아니라 대상 하드웨어용으로 개발된 동일한 Linux 커널을 QEMU 내에서 사용할 수 있도록 하는 이점이 있습니다. 다시 말하지만, 이는 개발 중인 애플리케이션을 지원하는 데 필요한 모든 패키지와 요소가 커널에 올바르게 포함되어 있는지 조기 검증을 제공합니다.

PWM 예

이 공동 시뮬레이션 환경을 보여주기 위해 간단한 예제를 만들었습니다. 이 예에서는 PL 내에 IP 코어를 배치하고 범용 AXI 인터페이스를 통해 이를 Zynq PS에 연결합니다. 레지스터 공간에 대한 AXI 액세스로 활성화되면 IP 코어는 펄스 폭 변조(PWM) 신호 출력을 생성합니다. PWM 신호의 지속 시간은 0 ~ 100% 범위 내에서 선택 가능하며 IP 코어의 레지스터 공간 내 레지스터에 의해 다시 정의됩니다. 따라서 이 코어의 일반적인 사용 사례에서는 IP 코어를 활성화하고 구성하기 위해 Zynq PS에서 실행되는 소프트웨어가 필요합니다. 단순히 격리된 IP 코어를 시뮬레이션하는 것만으로는 원하는 코어 작동이 적절하게 시연되지 않습니다. IP 코어를 올바르게 확인하려면 Linux 운영 체제를 실행할 때 PS에서 출력 펄스 폭을 활성화하고 실행할 수 있어야 합니다.