AMBA IP 설계를 위한 기본 지식

ARM 코어를 이용한 SoC 시스템의 IP 설계 방법 ②

IP의 기본 구조AMBA를 지원하는 IP 뿐만 아니라 모든 CPU에 연결되는 주변장치들은 비슷한 구조를 가지고 있다. 이 글을 읽는 독자가 CPU를 이용한 원보드 마이컴을 설계한 경험이 있다면 쉽게 이해할 수 있을 것이다. 물론 경험이 없다고 해도 그리 우려할 만한 것은 아니다. 일반적으로 생각을 해보면 어떠한 구성요소가 필요한지 알 수 있다.먼저 주변장치는 CPU의 버스에 연결 되므로 CPU에서 생성이 되는 버스의 프로토콜을 분석하고 대응하는 회로가 필요함을 알 수 있다. CPU에서 생성된 버스가 주변장치 중에 자신에게 해당하는지를 먼저 판단하고 버스의 트랜잭션이 READ 또는 WRITE인지를 판단하여 그에 대응한 동작을 수행하게 된다. 버스에서 여러 주변장치를 선택하는 것은 버스상의 어드레스를 이용하여 어드레스 디코더를 구성함으로써 가능하다. 여기서 어드레스 디코더는 시스템 설계자에 의해 구성된 메모리 맵을 기초로 하여 필요한 입력 어드레스라인과 출력의 개수를 결정한다. 어드레스 디코더의 출력은 각 슬레이브 IP의 HSEL 입력으로 사용이 된다. HSEL에 의해 선택된 IP는 CPU의 트랜잭션이 무엇인지를 판단해야 하는데 일반적으로 READ 또는 WRITE 중에 한 가지이다. READ 트랜잭션에서 슬레이브는 CPU에 해당 어드레스에 대응되는 데이터를 HRDATA를 통하여 전송하고 WRITE에서는 반대로 해당 어드레스에 대응되는 레지스터에 HWDATA의 값을 저장한다. 따라서 여기서 필요한 부분은 AMBA 버스를 감시하고 AMBA에 의하여 정의된 트랜잭션을 수행할 수 있는 버스 wrapper이다. 이 버스 wrapper는 주로 유한 상태기계(FSM: Finite State-Machine)로 구성이 된다.다음으로 AMBA 버스를 통하여 CPU와 설계한 IP가 서로 데이터를 교환할 수 있는 부분이 필요하다. 마스터에서 생성되는 버스 프로토콜에 따라서 READ와 WRITE 시 데이터의 방향에 따라 저장된 데이터를 마스터로 전송하거나 마스터에서 나온 데이터를 저장할 공간이 필요로 된다. 이 부분은 일반적으로 교환되는 데이터의 양이 적거나 간단한 IP를 설계하는 경우에 몇 개의 레지스터들로 구현이 되며 데이터의 양이 많은 경우는 dual-port RAM 또는 FIFO 등을 이용하여 구현 된다. 멀티미디어 처리 IP와 같이 데이터의 양이 많은 경우에 FIFO를 버퍼로 하여 설계를 하게 된다.마지막으로 필요한 부분은 마스터에 의해 전송되고 레지스터나 메모리에 저장된 데이터를 이용하여 IP의 용도에 맞는 동작을 수행하는 부분이다. 이 부분은 구현하고자 하는 IP의 목적에 따라 처리 방법이 달라지며 설계자는 레지스터에 저장된 데이터를 어떠한 방식으로 처리할 것인가를 결정해야만 하고 설계 방식에 따라 IP의 성능 및 게이트 사이즈 등이 결정된다. 아마도 설계자에게 가장 어려운 부분이 이 동작 부분을 설계하는 것이다. 대부분의 경우 동작하는 부분은 동작의 순서를 제어하기 위한 유한 상태기계와 처리를 담당하는 데이터패스로 구성이 되며, 신호처리를 가속하기 위하여 DSP로 구현이 되는 경우도 있다.앞에서 설명한 3부분을 모아보면 AMBA 버스에 대한 버스를 위한 상태기계와 데이터 교환을 위한 레지스터 부분 그리고 동작을 처리하기 위한 부분으로 세분화됨을 알 수 있다.AHB 마스터를 위한 Bus Wrapper마스터는 AHB에서 능동적인 부분으로 READ와 WRITE에 대한 트랜잭션을 초기화하고 AHB 프로토콜을 기반으로 이들 트랜잭션에 대한 정확한 타이밍을 생성하는 역할을 수행한다. 여기서는 AHB의 address phase와 data phase로 구성이 되는 기본 전송 방식을 이용하여 설명한다.먼저 address phase 동안에 마스터는 수행하고자 하는 트랜잭션에 대응하는 어드레스와 제어 신호를 드라이브해야만 한다. 마스터가 생성하는 실제 어드레스와 제어 신호들은 어플리케이션과 back-end 마스터 로직에 의존한다. Data phase 동안에 마스터는 슬레이브에 WRITE 트랜잭션에 대해서는 WRITE 데이터를 드라이브하고 READ 트랜잭션에 대해서는 마스터에서 발생한 트랜잭션을 수행하는 슬레이브에서 생성한 READ 데이터를 샘플링한다.또한 슬레이브에서 트랜잭션의 수행에 대한 응답 신호를 샘플링한다. 응답신호에 따라 마스터는 트랜잭션이 종료되었는지 다시 수행해야 할 지 또는 다음 transaction을 수행해도 되는지를 결정한다.앞서 설명한 동작을 수행할 수 있는 버스 wrapper를 위한 상태도는 다음의 그림 2와 같다. 그림의 상태도는 마스터 IP를 설계하기 위하여서는 반드시 이해를 하고 있어야 하는 부분으로 상태도를 HDL로 코딩함으로써 적당한 버스 wrapper를 구현할 수 있다. 상태도의 구성은 마스터의 back-end 로직에 의하여 결정되기 때문에 상태도의 구현은 설계자에 따라 매우 다양하게 표현될 수 있다. 또한 Burst 전송 방식이나 에러에 대응하는 처리 등을 포함하는 경우 아주 복잡한 상태도로 표현이 된다.아래의 그림 2를 보면 어떻게 AHB에 호환이 되는 신호들을 생성하는 것이 좋은지를 잘 보여주고 있다. 그림에서 주의해야 할 것은 마스터가 버스에 대한 승인(grant)없이 IDEL 상태에서 Address Phase로 이동을 하면서 어드레스와 제어신호를 생성한다는 것이다. 이것은 상태도가 Mealy-Machine의 형태로 구현이 되었고 신호들이 멀티플렉서에 의하여 구현이 되고 아비터가 마스터에게 액세스를 승인할 때 까지 버스 구성요소의 나머지들은 나타나지 않기 때문이다.AHB 슬레이브를 위한 Bus WrapperAHB 슬레이브는 버스구조에서 수동적인 구성요소이다. 즉 마스터에 의하여 선택이 되는 경우에 활성화되어 주어진 IP의 동작을 수행하게 되고 버스에 대한 어떤 트랜잭션도 발생시킬 수 없기 때문이다. 슬레이브를 계획할 때 중요한 요구사항은 버스 상에서 발생하는 연속된 이벤트를 이해하고 이벤트에 대응하는 설계를 하는 것이다. 이벤트에 대한 이해는 AMBA 버스의 트랜잭션에 대한 타이밍을 이해하는 것과 같다. AHB의 상태도에서 모든 AHB 트랜잭션은 address phase와 data phase의 2개의 상태로 구성 되고, 따라서 슬레이브의 버스 wrapper를 구현하는 한 가지 방법은 트랜잭션에 대하여 이들 상태에 대응하는 상태도를 구현하는 것이다. 그림 4는 슬레이브를 위한 상태도를 보인 것이다.애플리케이션의 종류와 back-end 슬레이브 로직의 구현 방식은 상태도의 변경이 가능하다는 것을 의미한다. Address phase 동안에 어드레스 디코더 로직은 마스터에서 생성된 어드레스를 이용하여 슬레이브를 선택한다. 일단 선택이 되면, 슬레이브는 트랜잭션을 위하여 어드레스와 제어신호를 샘플 하여야만 한다. 이들 어드레스는 래치 또는 레지스터에 저장이 된다. 트랜잭션의 data phase 동안에, 슬레이브는 address phase 동안에 샘플한 어드레스와 제어에 대응한 동작을 수행한다. Data phase 동안에는 레지스터에 저장된 데이터를 마스터로 전송하거나 내부의 레지스터에 저장하는 작업을 수행한다.AHB Slave 버스 Wrapper의 설계AHB Slave를 위한 상태도를 이용하여 버스 Wrapper를 설계하기 위해서는 다시 한 번 AHB 버스의 동작을 이해하는 것이 중요하다. AMBA의 버스 타이밍 중에서 간단한 타이밍을 가지는 2-phase의 전송 트랜잭션을 고려한다. 2-phase의 타이밍은 설계자가 쉽게 AMBA의 AHB를 이용할 수 있는 타이밍을 제공한다.그림 5는 AHB의 2-phase 전송을 위한 타이밍 다이어그램을 보인 것이다. 이러한 2-phase 전송은 오른쪽의 그림처럼 파이프라인(pipeline) 전송이 가능하므로 이를 지원할 수 있어야 한다. 그림에서 보인 중요한 포인트는 다음과 같이 요약할 수 있다.● Address phase에서 발생한 A의 전송을 위한 HADDR과 제어신호들은 Data phase에서 B을 위한 HADDR과 제어신호로 바뀐다는 점이다. A의 Data phase에서 보이는 HADDR과 제어신호는 다음의 B를 전송하기 위한 Address phase의 신호이므로 A의 Data phase에서 올바른 동작을 수행하기 위해서는 HADDR과 제어신호를 슬레이브가 저장하고 있어야만 한다. 이를 위하여 Address phase의 끝부분의 HCLK의 rising edge를 기준으로 이들을 샘플링하여 저장한다.● Data phase에서 마스터는 WRITE 트랜잭션을 위한 HWDATA를 어서트 하거나 READ를 위하여 HRDATA를 샘플링한다. 따라서 슬레이브 IP는 마스터의 transaction을 HWRITE 신호를 이용하여 분석하고 이에 적절한 응답을 해야만 한다. 마스터의 트랜잭션이 READ인 경우 Data phase 안에서 요구되는 데이터를 HRDATA 버스를 통하여 전송한다. 마스터는 Data phase 다음의 HCLK의 rising edge에서 슬레이브로부터 전송된 데이터를 샘플링한다.● HTRANS의 경우 항상 NONSEQ로부터 시작하고 연속된 전송일 경우 SEQ로 변경 된다. 이러한 경우에 주의할 점은 1024Bytes의 경계를 포함하는 전송을 구현하면 안 된다. 이 부분은 ARM 프로세서를 사용하는 경우에 지켜져야 하는 규칙이다.AHB Slave를 위한 간단한 상태도의 작성AHB 슬레이브 IP를 구현하기 위하여 설계자는 자신의 상태도를 구현할 수 있어야만 한다. 앞의 설명과 같이 가장 간단한 상태도는 Address phase와 Data phase의 상태만을 가지는 상태도를 구현할 수 있다. 이 경우에는 AHB에서 규정한 많은 경우, 즉 에러에 대한 대응 같은 부분, 전송에 지연이 발생한 경우 등이 반영이 되지 않을 수도 있다. 그러나 이러한 부분을 제외한 순수한 전송의 의미로서 고려하면 동작에는 문제가 없다.그림 6은 Address phase와 Data phase만을 고려한 상태도를 보인 것이다. 이 상태도의 경우 HREADY를 통한 전송의 지연이나 에러가 발생한 경우에 대응은 고려하지 않았다. 그러나 전송을 위한 측면에서 보면 파이프라인 전송을 지원할 수 있다.좀더 복잡한 전송을 고려한다면 다음의 그림 6에서 보인 상태도를 보면 된다. 그림 7은 AHB Slave의 복잡한 동작을 상태도롤 구현한 것으로 그림 6의 부분이 위의 박스로 보인 부분으로 포함되어 구현이 된 것을 볼 수 있다. 이러한 상태도는 마스터에 의한 AHB의 복잡한 트랜잭션을 효과적으로 대응할 수 있는 방법을 제공한다. 또한 Slave IP에서 발생할 수 있는 전송의 지연이나 에러에 대하여 대응하는 방법이 같이 제공되고 있다.AHB Slave의 상태도의 구현은 FSM의 HDL 구현 방법에 의하여 쉽게 코딩이 가능하다. 상태도의 출력은 AHB 버스로부터 받은 신호들의 그룹을 IP의 로컬에서 사용할 수 있도록 로컬 신호들로 변경하는 역할을 수행한다. 대표적인 신호들로 HADDR을 LADDR로, HWRITE를 LWRITE로 변경하는 것인데 이들 신호들은 Data phase에서 사용되므로 래치나 레지스터에 저장하여 출력한다. 또한 HCLK와 HRESET 신호는 래치하지 않고 그냥 출력하여도 문제가 되지 않으며 데이터 신호들에 대하여 특별히 고려할 것은 없다.레지스터의 파일레지스터 파일은 슬레이브 IP와 마스터가 데이터를 교환하기 위하여 사용하는 부분으로 이들 레지스터 파일을 설계하기 위해서는 우선 레지스터의 종류와 역할 그리고 중요한 것은 레지스터를 구분하기 위한 어드레스를 부여하여야 한다는 것이다. 이러한 어드레스를 통하여 프로그래머는 각각의 레지스터에 대한 데이터를 읽고 쓰는 것이 가능하기 때문이다.각각의 레지스터는 1워드를 저장할 수 있는 메모리와 같으며 마스터에서 Slave의 동작을 위하여 주어야 하는 데이터의 양에 의하여 쓰기를 위한 레지스터의 수가 결정이 되고, Slave에서 마스터로 전송해 주어야 하는 데이터의 양에 따라서 읽기 레지스터의 수가 결정된다.레지스터 파일에 대한 어드레스의 부가는 주로 HADDR의 LSB인 HADDR[1:0]을 제외한 하위의 어드레스를 사용한다. LSB의 2비트를 제외하는 것은 레지스터에 대한 액세스를 워드 단위(32비트)로 수행한다는 것을 의미한다. 만약에 워드 단위가 아닌 Half-Word나 바이트 단위로 액세스하는 경우에는 어드레스에 대한 고려가 필요하다.다음 그림 8은 레지스터의 구조를 보인 것으로 HDL 코드로 설계할 경우에는 레지스터에 대한 부분과 어드레스 디코더 그리고 MUX 부분을 이해하고 있다면 빠른 설계가 가능하다. 레지스터에 데이터를 쓰는 경우에는 마스터에서 생성된 어드레스를 이용하여 어떠한 레지스터에 값을 써야할 것인가를 결정하여야 하는데 이때 설계된 어드레스 맵을 이용하여 디코더에 입력으로 주어주면 된다. 레지스터에 대한 어드레스는 주로 HADDR의 하위 부분을 이용하므로 디코더에 필요한 하위 어드레스를 입력으로 주어준다. 레지스터의 입력이 되는 데이터는 HWDATA에 공통으로 연결이 된다. 그러나 디코더의 출력은 항상 1개의 출력만이 활성화되고 나머지는 비활성화 되므로 항상 1개의 레지스터에만 데이터를 쓰는 것이 가능하다.레지스터의 값을 읽어 오는 경우를 고려하면, 레지스터의 출력은 항상 보여지므로, 사실 플립플롭의 출력인 Q는 항상 출력이 되고 있고 Q에 부가된 회로가 없다면 어디에서든지 설계자는 Q의 값을 볼 수 있다. 이들 레지스터의 출력을 선택하여 HRDATA 버스로 전송하여 주면 된다.마스터 또한 읽고자 하는 레지스터를 선택하기 위하여 주어진 어드레스 맵을 이용하며, 이 레지스터는 한 번의 트랜잭션에 대하여 단 지 1개의 레지스터 값만을 읽을 수 있다. 따라서 여러 개의 레지스터 값 중에 1개를 선택하기 위하여 MUX를 이용하여 설계한다. MUX의 선택을 위한 제어신호로서 HADDR의 하위 부분을 사용하고 MUX가 READ 트랜잭션일 경우에 데이터를 출력할 수 있도록 제어신호의 추가가 필요하다. 이러한 제어신호는 MUX에 enable 단자를 부가함으로써 쉽게 구현이 가능하다.맺음말앞에서 우리는 AMBA의 기본 구성 요소인 Master, Slave, Arbiter, Decoder에 관해 기본적인 이해를 했다. 그리고 AHB Master bus wrapper, AHB slave bus wrapper, register file의 설계 방법에 관해 알아보았다.예제를 통해 IP설계의 기초가 되는 AMBA의 동작을 정확히 아는 것이 중요하다. web상에 많은 예제들을 찾아볼 수 있으므로 이런 예제를 통해 실제적인 경험을 해보기를 권한다.

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

개의 댓글

회원로그인

작성자 비밀번호

댓글 내용입력

댓글 정렬

최신순 추천순 답글순

BEST댓글

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

더보기

김가희 (webmaster@techworld.co.kr)

기자의 다른기사 보기

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