PowerPC 프로세서 탑재 Virtex FPGA에서 빠르고 간단한 BSP 생성

효율적인 BSP 생성

임베디드 프로세서를 탑재한 플랫폼 FPGA는 뛰어난 유연성과 통합성, 그리고 성능을 겸비하고 있다. 이제는 한 개의 프로그래머블 로직 디바이스(PLD)에 매우 정교하고 고도로 커스터마이즈된 임베디드 시스템을 개발할 수 있게 되었다.실리콘 기능의 진화에 따라, 가장 큰 과제는 설계 기법의 효율성과 생산성을 어떻게 유지할 것인가 하는 것이다. 임베디드 시스템의 개발에 있어서 핵심 작업의 하나는 BSP의 개발에 있다. BSP는 임베디드 소프트웨어 애플리케이션이 성공적으로 초기화되어 프로세서에 연결되어 있는 하드웨어 리소스와 통신하는데 필요하다. 일반적인 BSP 컴포넌트에는 부트 코드(boot code), 디바이스 드라이버 코드(device driver code), 초기화 코드가 있다.BSP는 마이크로프로세서 복합체(프로세서와 관련 주변장치)가 바뀔 때마다 작성할 필요가 있어, 상당한 시간과 수고가 요구된다. FPGA의 경우, 디자인의 빈번한 반복과 플랫폼 고유의 유연성에 의해 BSP의 관리 태스크는 한층 더 어렵게 된다(그림 1). 이러한 상황에서는 BSP를 관리하기 위한 효과적인 프로세스를 준비하는 것이 필요하다.자일링스 디자인 플로우와 소프트웨어 BSP 생성자일링스 프로세서를 설계하기 위해서는 하드웨어 플랫폼의 어셈블리 플로우와 임베디드 소프트웨어의 개발 플로우가 필요하다. 어느 플로우든 자일링스의 임베디드 개발 키트(EDK)에 있는 XPS (Xilinx Platform Studio) 툴로 관리된다.일반적으로, 설계는 프로세서와 그것에 접속되어 있는 컴포넌트를 XPS에서 조립하고 컨피규레이션하는 것부터 시작한다. 하드웨어 플랫폼을 정의하면, 시스템의 소프트웨어 파라미터를 컨피규레이션 할 수 있다.Platform Studio의 핵심 기능은 설계자가 프로세서와 주변장치, 그리고 임베디드 OS를 어떻게 선택하여 컨피규레이션 했는지에 따라, 커스터마이즈된 BSP를 생성하는 것이다. 시스템이 하드웨어 설계의 반복적인 변경을 통해 진화하는 것처럼, BSP도 플랫폼과 함께 진화한다.자동 생성되는 BSP는 임베디드 시스템 설계자에게 있어서 다음과 같은 이점을 제공한다.▲ 하드웨어 설계에 완전히 일치하는 BSP의 자동작성▲ 사전 인증된 컴포넌트를 사용함으로써 BSP의 설계 버그를 제거▲ 애플리케이션 소프트웨어의 개발에 즉시 착수할 수 있기 때문에 설계자의 생산성 향상윈드리버 VxWorks용 BSP 작성Platform Studio는 자일링스의 Virtex-II Pro와 Virtex-4의 각 FPGA에 탑재되어 있는 PowerPC 405 프로세서와 그 주변장치를 위해 커스터마이즈된 Tornado 2.0.x(VxWorks 5.4) 또는 Tornado 2.2.x( VxWorks 5.5) BSP를 생성할 수 있다. 생성되는 BSP에는 부트 코드, 디바이스 드라이버 코드, VxWorks 초기화 코드를 포함한 시스템에 필요한 모든 지원 소프트웨어가 포함되어 있다.Platform Studio에서 PowerPC 405 프로세서 기반의 하드웨어 시스템을 정의하면, 다음 3단계를 따르는 것만으로 VxWorks용 BSP를 생성할 수 있다.1. Software Settings 대화상자(그림 2)를 이용하여, 시스템에 사용하는 OS를 선택한다. Platform Studio의 유저는 타깃 OS로서 vxworks5_4 또는 vxworks5_5를 선택할 수 있다.2. OS가 선택되면, Library/OS Para- meters 탭을 선택하여 Tornado BSP를 커스텀 하드웨어용으로 변경한다(그림 3). 표준 I/O 디바이스(stdin과 stdout)로서 시스템 내에 임의의 UART 디바이스를 선택할 수 있다. 그 결과 선택된 디바이스는 VxWorks 콘솔 디바이스로 사용되어진다. 또한 연결되는 주변장치나 VxWorks OS에 긴밀하게 통합되는 디바이스를 선택할 수 있다. 예를 들어, VxWorks의 END (Enhanced Network Driver) 인터페이스에 자일링스의 10/100 Ethernet MAC를 통합할 수 있다. Ethernet 디바이스는 END 인터페이스에 반드시 연결될 필요는 없으며, VxWorks 애플리케이션으로부터 직접 액세스 하는 것도 가능하다.3. Tools ＞ Generate Libraries and BSP menu option을 선택하는 것으로 Tornado BSP를 생성한다. 생성된 BSP는 기존의 Tornado BSP를 닮아 있어 Platform Studio 프로젝트 디렉토리의 ppc405_0/bsp_ ppc405_0에 보관된다(그림 4).ppc405_0은 하드웨어 설계에서 PowerPC 405 프로세서의 인스턴스 이름(instance name)이다. Platform Studio의 유저는 다른 인스턴스 이름을 지정할 수 있으며, 이 경우 BSP에 대한 서브디렉토리 이름은 프로세서의 인스턴스 이름과 같아진다.Tornado BSP는 완전한 자기완결형이며, target/config에 있는 BSP용 표준 Tornado installation directory 등의 다른 디렉토리 위치로 옮길 수 있다.커스터마이즈된 BSP의 상세XPS에서 생성한 VxWorks용 BSP는 자일링스 디바이스 드라이버 코드의 배치 장소 이외의 다른 Tornado BSP와 대부분 같다.Tornado에 첨부되어 있는 Off-the-shelf 디바이스 드라이버 코드는 일반적으로 Tornado distribution directory 내의 target/src/drv 디렉토리에 보관되어 있다. Platform Studio에 의해 자동적으로 생성되는 BSP용 디바이스 드라이버 코드는 BSP 디렉토리 그 자체에 보관된다.코드의 보관 장소가 조금 다른 것은 FPGA를 기반으로 하는 임베디드 시스템의 다이내믹한 특성에 기인하고 있다. FPGA 기반의 임베디드 시스템은 새로운 IP 또는 변경된 IP를 이용하여 재프로그램 될 수 있기 때문에 디바이스 드라이버의 컨피규레이션이 바뀔 수 있어, 디바이스 드라이버의 소스 파일을 동적으로 배치할 필요가 있다. 그림 4에 자동 생성된 BSP의 디렉토리 트리를 보여준다. 자일링스의 디바이스 드라이버는 BSP의 ppc405_0_drv_csp/xsrc 서브디렉토리에 보관되어 있다.자일링스의 디바이스 드라이버는 일반적으로 한 개의 C header와 implemen- tation 파일로부터 구성되는 VxWorks 드라이버와 달리, C로 구현되어 여러 소스 파일로 분산되어 있다. 또한 디바이스 드라이버에 대해서는 OS에 의존하지 않는 implementation과, OS에 의존하는 옵션 implementation이 있다.드라이버 내에서 OS에 의존하지 않는 부분은 임의의 OS 또는 임의의 프로세서에서 사용할 수 있게 설계되어 있다. 이 부분은 기본적인 하드웨어의 기능성을 추상화하는 애플리케이션 프로그램 인터페이스(API)를 제공한다. 한편, 드라이버 내에서 OS에 의존하는 부분은 VxWorks와 같은 OS에서 사용할 수 있도록 드라이버에 조정을 가한다.시리얼 포트용 Serial IO 드라이버와 Ethernet 컨트롤러용 END 드라이버는 그 하나의 예이다. OS 의존형 드라이버를 필요로 하는 것은 표준 OS 인터페이스에 긴밀하게 통합할 수 있는 드라이버뿐이다.다른 BSP 파일이 build에 포함되어 있는 것처럼, 자일링스의 드라이버 소스 파일도 VxWorks 이미지의 build에 포함되어 있다. 어느 드라이버든, BSP 디렉토리에는 ppc405_0_drv_ .c라고 하는 이름의 파일이 있다. 이 파일에는 특정한 디바이스용 드라이버 소스 파일(* .c)을 포함하고 있어, BSP의 makefile에 의해 자동으로 컴파일 된다.이 프로세스는 VxWorks의 sysLib.c가 윈드리버 제공의 드라이버에 대한 소스를 포함시키는 방법과 유사하다. 자일링스의 드라이버를 다른 드라이버처럼 단지 sysLib.c에 포함시키지 않는 이유는 namespace의 경합과 보전성(main- tainability)의 문제를 고려하고 있기 때문이다. 자일링스의 드라이버가 모두 하나의 컴파일 유닛에 포함돼 있으면, 정적인 기능과 데이터는 더 이상 외부 접근이 어렵게 된다.이로 인해 디바이스 드라이버에 제약이 걸리고 OS로부터의 독립을 실현할 수 없게 되는 것이다.Tornado IDE와의 통합자동 생성된 BSP는 Tornado IDE에 통합된다(Project 기능). BSP는 Tornado의 make 툴을 이용하여 command line에서 컴파일하거나, Tornado의 Project에서 컴파일 할 수 있다.BSP가 생성되면, command line에서 간단히 make vxWorks를 입력하여 부트 가능한 RAM 이미지를 컴파일 할 수 있다. 단, 여기에는 Tornado 환경이 이미 셋업 되어 있어야 하며, 셋업은 Windows 플랫폼의 경우 host/x86-win32/bin /torVars.bat 스크립트를 사용하여 command line을 통해 실행할 수 있다. Tornado Project 기능을 사용하는 경우, 새롭게 생성된 BSP에 기반하여 프로젝트를 작성하고 나서, IDE를 통해 준비된 build 환경을 사용하여 BSP를 컴파일 할 수 있다.Tornado 2.2.x에서는 gnu 컴파일러 외에도 diab 컴파일러도 지원된다. Platform Studio에서 작성된 Tornado BSP는 makefile을 가지고 있지만, gnu 컴파일러 대신에 diab 컴파일러를 사용하고 싶을 경우에는 command line에서 makefile을 변경할 수 있다. TOOLS라고 하는 make 변수를 찾아, 값을 “gnu”가 아닌 “diab”로 설정한다. Tornado의 Project 기능을 사용할 경우에는 프로젝트가 최초로 만들어졌을 때에 희망하는 컴파일러를 선택할 수 있다.파일 50ppc405_0.cdf는 BSP 디렉토리에 있는데, BSP의 작성 중에 만들어진다. 이 파일은 디바이스 드라이버를 Tornado IDE 메뉴 시스템에 통합한다. 드라이버는 Hardware 폴더 내의 Peri-pherals 서브폴더에서 BSP로 훅(hook) 된다.그 아래로는 각각의 디바이스 드라이버 폴더가 있다. 자일링스의 디바이스 드라이버 메뉴를 그림 5에 제시한다.Tornado Project 기능의 Files 탭에는 자일링스의 디바이스 드라이버를 Tornado의 build 프로세스에 통합하기 위해서 사용되는 파일 수도 보여준다. 이들 파일은 Platform Studio에 의해 자동적으로 작성되기 때문에, 파일이 존재하는 것만 확인하면 된다. 그림 6에 드라이버 빌드 파일의 예를 제시한다.일반적으로 사용되는 몇 가지 디바이스들은 OS에 긴밀하게 통합되어 있어, 그 이외의 디바이스들은 디바이스 드라이버를 사용하는 것으로 애플리케이션에 직접 액세스 할 수 있다. VxWorks에 긴밀하게 통합되어 있는 디바이스 드라이버는 다음과 같은 것이 있다.· 10/100 Ethernet MAC· 10/100 Ethernet Lite MAC· 1 Gigabit Ethernet MAC· 16550/16450 UART· UART Lite· 인터럽트 컨트롤러· System ACE™ 기술· PCI이외의 디바이스와 각각의 디바이스 드라이버는 VxWorks 인터페이스에 긴밀하게 통합되어 있지 않지만, 유저 애플리케이션으로부터 각 디바이스 드라이버에 직접 액세스함으로써 이용할 수 있다.결론임베디드 프로세서 기반의 FPGA가 확대일로에 있는 가운데, 실리콘의 진화에 맞춰 설계자의 생산성을 높이기 위해서는 하드웨어와 소프트웨어의 플로우를 효율적으로 동기화해 결합시키는 툴 솔루션이 필요하다.자일링스의 유저는 Platform Studio와 VxWorks 5.4/5.5와의 통합에 대해 대단히 만족하고 있다. 자일링스는 앞으로도 윈드리버의 플로우에 대한 개발 지원을 계속할 방침이며, 가까운 장래에 VxWorks 6.0과 Workbench IDE도 지원할 계획이다.--마이크로프로세서 라이브러리 정의(MLD: Microprocessor Library Definition)다이내믹한 커스텀 BSP를 생성하는 기술은 마이크로프로세서 라이브러리 정의(MLD)라고 하는 자일링스 고유의 포맷에 기반하고 있다. 이 포맷은 서드파티 벤더가 커스텀 라이브러리와 OS 고유의 BSP를 생성할 수 있도록, XPS(Xilinx Platform Studio)에 플러그인 인터페이스를 제공한다(그림 7). 일반적으로 MLD 인터페이스는 서드파티 벤더가 자신의 독자 플로우용으로 작성하는 것이다. 이것에 의해 다음과 같은 애드온(add-on) 기능이 실현된다.· 커스텀 디자인의 규칙 체크· 타깃 OS 환경에 맞게 디바이스 드라이버를 커스터마이즈하는 기능· OS 툴 체인에 입각한 포맷과 폴더 구조로 BSP를 커스텀 생성하는 기능· 대상 하드웨어 시스템에 기반하여 OS/커널을 커스터마이즈하는 기능MLD 인터페이스는 ASCII-기반의 개방형 표준이다. 각 RTOS 플로우는 각각 독자적인 MLD 파일 세트를 갖는다. MLD 파일 세트는 다음 2개의 파일로 이루어진다.· 데이터 정의(.mld) 파일: Platform Studio에 의해 설정된 파라미터 세트를 통해 라이브러리나 OS를 정의하는 파일이다. 이들 파라미터 값은 Platform Studio의 내부 데이터베이스에 보관되어, 출력 생성 중에 스크립트 파일에 의해 사용된다.· .tcl 스크립트 파일: 커스텀 BSP를 작성하기 위해서 XPS에 의해 호출되는 파일이다. 이 파일은 설계 데이터베이스 전체에 액세스가 가능하므로, 플로우의 조건에 기반해 커스텀 출력 포맷을 작성할 수 있는 한 세트의 프로시저(procedure)가 포함되어 있다.MLD의 신택스에 대해서는 EDK 문서에 자세하게 설명되어 있다(“Platform Specification Format Reference Manual” at www.xilinx.com/ise/embedded/psf_rm.pdf.). EDK 인스톨레이션(installation) 디렉토리의 sw/lib/bsp에 MLD의 예도 소개하고 있다.특정 RTOS 플로우에 대한 MLD 파일이 작성되면, 그 다음에 호출될 때에 XPS가 픽업 할 수 있도록 이들 파일을 특정 패스에 인스톨 할 필요가 있다. 이로 인해, 특정 RTOS 메뉴의 선택이 XPS의 대화상자에서 활성화 된다(Project ＞SW Platform Settings ＞ Software Platform ＞ OS).현재 아래 언급한 파트너의 MLD 파일을 XPS 내에서 이용할 수 있다.· Wind River (VxWorks 5.4, 5.5): (Xilinx Platform Studio에 포함)· MontaVista (Linux): (Xilinx Platform Studio에 포함)· Mentor Accelerated Technologies (Nucleus): (www.xilinx.com/ise/embedded/mld/에서 다운로드 가능)· GreenHills Software (Integrity): (www.xilinx.com/ise/embedded/mld/에서 다운로드 가능)· Micrium (μc/OS-II): (www.xilinx.com/ise/embedded/mld/에서 다운로드 가능)· μcLinux: (www.xilinx.com/ise/embedded/mld/에서 다운로드 가능)

회원가입 후 이용바랍니다.

개의 댓글

회원로그인

작성자 비밀번호

댓글 내용입력

댓글 정렬

최신순 추천순 답글순

BEST댓글

BEST 댓글 답글과 추천수를 합산하여 자동으로 노출됩니다. 닫기

더보기

조진현 (webmaster@techworld.co.kr)

기자의 다른기사 보기

저작권자 © 테크월드뉴스 무단전재 및 재배포 금지