AXI 인터페이스 — AXI4·AXI4-Lite·AXI-Stream 비교

#한 줄 요약

“AXI는 control은 AXI4-Lite, memory는 AXI4 full, streaming은 AXI-Stream으로 나눠 쓰는 인터페이스 세트입니다.” Ready/valid handshake와 5 channel 구조를 알면 셋이 같은 가족이라는 게 보입니다.

#어떤 상황에서 쓰나

Zynq나 Versal 같은 SoC에서 PS(Cortex-A·R)와 PL(FPGA) 사이를 잇는 표준 인터페이스가 AXI입니다. HLS IP, custom RTL block, AXI DMA, Ethernet MAC, DDR controller 모두 AXI 변종 중 하나로 묶입니다.

ARM IP를 가져다 쓰는 SoC라면 PCIe 영역을 제외한 거의 모든 내부 버스가 AXI 위에 서 있습니다. AXI 셋의 차이만 명확히 알아도 datasheet 읽는 속도와 IP integration 작업이 크게 빨라집니다.

#핵심 개념

세 변종을 한 줄로 정리합니다.

AXI4 full의 5 channel은 모두 VALID·READY handshake로 움직입니다.

VALID·READY 둘 다 1인 cycle에 한 beat가 옮겨집니다. Slave가 못 받으면 READY=0이 되고 master는 데이터를 유지합니다. 자연스러운 backpressure가 protocol에 박혀 있습니다.

#코드 / 실제 사용 예

#AXI4-Lite — control register

1
void accel(int *in, int *out, int n, int mode) {
2
#pragma HLS INTERFACE m_axi     port=in   offset=slave bundle=gmem
3
#pragma HLS INTERFACE m_axi     port=out  offset=slave bundle=gmem
4
#pragma HLS INTERFACE s_axilite port=in   bundle=ctrl
5
#pragma HLS INTERFACE s_axilite port=out  bundle=ctrl
6
#pragma HLS INTERFACE s_axilite port=n    bundle=ctrl
7
#pragma HLS INTERFACE s_axilite port=mode bundle=ctrl
8
#pragma HLS INTERFACE s_axilite port=return bundle=ctrl
9
    /* ... */
10
}

s_axilite 쪽이 register map으로 합성됩니다. Linux side에서는 pci_iomap 또는 ioremap으로 잡은 뒤 다음처럼 다룹니다.

1
struct accel_regs {
2
    volatile uint32_t ap_ctrl;    /* bit0 START, bit1 DONE, bit2 IDLE */
3
    volatile uint32_t ap_gie;
4
    volatile uint32_t ier;
5
    volatile uint32_t isr;
6
    volatile uint32_t in_addr_lo;
7
    volatile uint32_t in_addr_hi;
8
    /* ... */
9
};
10

11
void accel_start(struct accel_regs *r, dma_addr_t in, dma_addr_t out, int n) {
12
    r->in_addr_lo  = lower_32_bits(in);
13
    r->in_addr_hi  = upper_32_bits(in);
14
    r->out_addr_lo = lower_32_bits(out);
15
    r->out_addr_hi = upper_32_bits(out);
16
    r->n           = n;
17
    wmb();
18
    r->ap_ctrl     = 0x1;          /* START */
19
}

ap_ctrl의 START·DONE·IDLE 비트는 Vitis HLS가 자동 생성하는 표준 control 레이아웃입니다.

#AXI4 full — burst length

1
#pragma HLS INTERFACE m_axi port=buf offset=slave bundle=gmem \
2
    max_read_burst_length=256 max_write_burst_length=256

AXI4 burst는 최대 256 beat입니다. 64-bit data bus라면 한 transaction에서 2 KB를 옮길 수 있습니다. Burst를 크게 잡을수록 DDR address phase overhead가 amortize되어 effective bandwidth가 올라갑니다.

#4 KB boundary 회피

AXI burst에는 지켜야 할 규칙이 있습니다.

• 한 burst는 4 KB boundary를 넘으면 안 됩니다.
• DMA controller는 이 split을 자동으로 처리하지만, 손수 만든 master는 직접 split해야 합니다.

1
/* Pseudo — 4 KB 안에 맞춰 split */
2
void split_burst(uint64_t addr, uint32_t len, axi_burst *out, int *nb) {
3
    int n = 0;
4
    while (len) {
5
        uint32_t to_boundary = 4096 - (addr & 0xFFF);
6
        uint32_t chunk = min(len, to_boundary);
7
        out[n++] = (axi_burst){ addr, chunk };
8
        addr += chunk;
9
        len  -= chunk;
10
    }
11
    *nb = n;
12
}

DMA controller 대부분이 이 split을 자동 처리하지만, raw AXI master를 직접 만들 때는 반드시 손으로 챙겨야 합니다.

#AXI-Stream — TLAST 표시

1
#include <hls_stream.h>
2
#include <ap_axi_sdata.h>
3

4
typedef ap_axiu<32, 1, 1, 1> pkt_t;     /* 32-bit data + side-band */
5

6
void parser(hls::stream<pkt_t> &in, hls::stream<pkt_t> &out) {
7
#pragma HLS INTERFACE axis port=in
8
#pragma HLS INTERFACE axis port=out
9
#pragma HLS INTERFACE s_axilite port=return bundle=ctrl
10

11
    pkt_t p;
12
    do {
13
#pragma HLS PIPELINE II=1
14
        p = in.read();
15
        p.data ^= 0xCAFEBABE;
16
        out.write(p);
17
    } while (!p.last);
18
}

TLAST는 패킷·프레임 끝을 표시하는 sideband 신호입니다. 비디오에서는 라인 끝, 네트워크에서는 packet 끝을 의미합니다.

#Outstanding transactions

Master는 앞선 요청의 응답을 받기 전에 다음 요청을 발사할 수 있습니다.

1
Time:   AR0  AR1  AR2  AR3
2
                       R0   R1   R2   R3

이때 outstanding 4는 응답을 아직 받지 못한 요청이 동시에 4개 떠 있다는 뜻입니다.

1
#pragma HLS INTERFACE m_axi port=buf max_read_outstanding=16 \
2
                                       max_write_outstanding=16

DDR controller는 latency가 보통 100-200 ns입니다. Outstanding 1이면 매 beat마다 idle 100 ns가 끼어 throughput이 1/5로 떨어집니다. 8-16 outstanding이 표준입니다.

#AXI ID 분리로 deadlock 회피

같은 ID로 서로 다른 slave를 때리면 문제가 생깁니다. AR(id=0)을 빠른 slave A에 보내고 같은 AR(id=0)을 느린 slave B에 또 보내면, B의 응답이 늦을 때 같은 ID FIFO의 순서 보장 때문에 A의 응답까지 함께 묶여 대기합니다. 이 상태가 길어지면 deadlock으로도 갑니다.

Master는 slave별로 ID를 다르게 발사합니다.

1
/* AR(id = slave_id | sequence) */
2
issue_read(0x10 | seq, slave_A_addr);
3
issue_read(0x20 | seq, slave_B_addr);   /* OoO 가능 */

#AXI Interconnect QoS

1
/* Vivado Block Design에서 ARQOS/AWQOS 설정 */
2
/* AXI Interconnect의 register로 master별 priority 변경 */
3

4
#define QOS_CRITICAL  15
5
#define QOS_HIGH      10
6
#define QOS_NORMAL    5
7

8
set_qos(axi_master_camera_id, QOS_CRITICAL);   /* frame drop 금지 */
9
set_qos(axi_master_cpu_id,    QOS_HIGH);
10
set_qos(axi_master_dma_id,    QOS_NORMAL);

DDR controller arbiter가 QOS 비트를 보고 우선순위를 결정합니다. 자율주행 control 경로처럼 deadline이 박힌 master는 QOS를 높게 줍니다.

#Zynq UltraScale+ PS-PL port

FPGA accelerator → AXI HP → DDR이 가장 일반적인 데이터 path입니다. CPU와 sharing이 잦으면 HPC나 ACP로 coherent 영역을 잡습니다.

#측정 / 성능 비교

Zynq UltraScale+에서 AXI4 m_axi를 burst length만 바꿔 측정한 효과입니다(DDR4-2400, 64-bit bus).

Outstanding 수의 효과는 다음과 같습니다.

Outstanding을 늘리면 latency가 거의 변하지 않으면서 throughput이 크게 올라갑니다. DDR access pattern이 random일수록 outstanding의 이득이 큽니다.

QoS가 없을 때와 있을 때의 차이도 큽니다. Camera·DPU master에 QoS=15를 주지 않으면 GPU의 큰 burst가 진행되는 동안 frame drop이 발생합니다.

#자주 보는 함정

같은 ID로 여러 slave에 발사

위에서 본 deadlock 패턴입니다. AXI Interconnect가 자동으로 ID extension을 붙이긴 하지만, raw master에서는 손으로 ID를 slave별로 분리해야 안전합니다.

Outstanding 1로 DDR 사용

1
#pragma HLS INTERFACE m_axi port=data max_read_outstanding=1

DDR latency를 매번 동기적으로 기다리는 형태가 됩니다. throughput이 한 자릿수 GB/s에서 막힙니다.

4 KB boundary 무시

1
/* Raw AXI master에서 */
2
issue_burst(addr=0x0FF0, len=64);   /* 0x0FF0 ~ 0x10EF, 4KB boundary 침범 */

Spec 위반이며 slave가 거부하거나 split해 동작이 의도와 달라집니다. DMA controller IP에는 자동 split이 있지만 직접 만든 master는 손으로 챙깁니다.

AXI-Lite로 큰 buffer 옮기기

1
#pragma HLS INTERFACE s_axilite port=buffer bundle=ctrl

AXI-Lite는 single-beat라서 4 KB buffer를 옮기면 1024개 transaction이 발생합니다. 큰 데이터는 m_axi를 씁니다.

QoS 모두 0

모든 master가 우선순위 0이면 round-robin이 됩니다. RT 경로의 master(카메라·display)가 굶주려 frame drop이 발생합니다. critical master는 명시적으로 QoS를 올립니다.

Stream에 TLAST 안 줌

1
pkt.data = sample;
2
out.write(pkt);                /* last 안 설정 */

DMA가 packet 끝을 못 잡아 transfer가 계속 대기 상태로 남습니다. Frame·packet 끝마다 pkt.last = 1을 명시합니다.

Cache coherent 영역에 ACP 대신 HP

CPU와 공유하는 영역인데 HP 포트로 접근하면 접근할 때마다 cache flush를 해야 합니다. CPU와 가속기가 같은 buffer를 자주 주고받으면 ACP·HPC를 씁니다. 매번 cache 관리하는 비용보다 hardware coherency가 훨씬 쌉니다.

#정리

• AXI는 AXI4 full(memory), AXI4-Lite(control), AXI-Stream(data) 세 변종으로 구성됩니다.
• 5 channel(AR·R·AW·W·B)이 모두 VALID·READY handshake로 움직입니다.
• AXI4 burst는 1-256 beat이며 4 KB boundary를 넘으면 안 됩니다.
• Outstanding transactions를 8-16으로 잡아 DDR latency를 감춥니다.
• AXI ID는 slave별로 분리해 deadlock을 피합니다.
• QoS는 RT critical master(카메라·display)를 굶기지 않기 위해 명시합니다.
• AXI-Stream의 TLAST·TKEEP·TUSER는 DMA·video·packet 처리의 핵심 sideband입니다.
• Zynq PS-PL은 HP·HPC·ACP·GP를 역할별로 골라 씁니다.
• HLS의 s_axilite/m_axi/axis 인터페이스는 결국 이 셋 위로 떨어집니다.

여기까지 Part 5(FPGA·accelerator·PCIe)였습니다. 시리즈 다음 Part로 이어집니다.

#관련 항목

• 5-05: Vitis HLS
• 5-02: CQ·SQ
• 5-03: DMA Completion
• PE 3-01: Bus Architecture