Page 5 · Radar over CSI-2

AWR2243 over CSI-2

The AWR2243 is a 76–81 GHz FMCW radar front end with no user DSP. Everything it measures leaves the chip as raw ADC samples, and CSI-2 is the production path for those samples. TI reuses the camera model directly: a radar frame is a CSI-2 frame and a chirp is a CSI-2 line.

RF3 TX, 4 RX, 76–81 GHz FMCW

BasebandIF bandwidth up to 20 MHz; ADC up to ~45 Msps per datasheet

ControlSPI from the host, mmWaveLink commands

CSI-21, 2 or 4 data lanes, 150–600 Mb/s per lane

Clock lane75–300 MHz DDR, continuous

LVDS (debug)4 data + bit clock + frame clock, up to 900 Mb/s

Where CSI-2 sits in the chip

The chirp engine sweeps the synthesizer, each RX chain mixes the echo down to IF, and four ADCs sample the IF. Samples go into an on-chip buffer. When a chirp's samples are complete, the CSI-2 transmitter wraps them, with a chirp header and optional quality data, into one long packet and sends it. While that packet goes out, the next chirp is already being sampled into the other half of the buffer.

The host never talks to the AWR2243 over CSI-2. It boots and configures the device over SPI (profile, chirp and frame configuration, the data path format, lane count and rate) and starts frames with a command or the SYNC_IN pin. CSI-2 only carries data out.

The AWR2243 treats a radar frame like a camera frame and a chirp like a camera line. Samples from chirp n are buffered on chip and leave as one long packet while chirp n+1 is sampled. The link only has to keep up on average across the chirp period.

How the stream is structured

CSI-2 concept	AWR2243 meaning
Frame Start / Frame End	Start and end of one radar frame (a burst of N chirps). TI describes these as the VSYNC equivalents.
Line Start / Line End	Brackets for one chirp (the HSYNC equivalents).
Long packet	One chirp: chirp profile and chirp number, ADC data from all four RX channels interleaved, and configurable chirp-quality data.
Virtual channel	The interface is VC-based; the commonly used configuration sends ADC data on VC 0.
Data type	Set by the mmWaveLink data-path configuration. Users report RAW8-type packets carrying 12, 14 or 16-bit real or complex samples. The receiver should treat the payload as bytes and unpack in software or fabric.
CRC	Generated on every long packet.

The exact byte packing (12-bit complex, 16-bit complex, real-only) is a configuration choice. The datasheet section "ADC Data Format Over CSI2 Interface" has the packing figures. Decide the format once, and derive the receiver's expected word count from it. A word-count mismatch is the first thing to check if packets arrive but don't parse.

Bandwidth math

The question to answer: can the link drain one chirp's data before the next chirp's data is ready?

Quantity	Formula	Example
Bytes per chirp	N_samp × N_RX × bytes/sample + CP + CQ	256 × 4 × 4 B (16-bit I + Q) = 4,096 B + header data
Link capacity	lanes × lane rate	4 × 600 Mb/s = 2.4 Gb/s = 300 MB/s
Packet time	(bytes + 6) × 8 / capacity + LP↔HS overhead	≈ 13.7 µs + ~0.5–1 µs ≈ 14.5 µs
ADC time per chirp	N_samp / f_s	256 / 10 Msps = 25.6 µs
Chirp period	idle + ramp (≥ ADC time)	e.g. 35 µs
Link utilization	packet time / chirp period	14.5 / 35 ≈ 41%

Sustained limit. With 16-bit complex samples and 4 RX, each sample instant is 4 × 32 = 128 bits. 2.4 Gb/s ÷ 128 bits = 18.75 Msps complex if the ADC ran continuously. With 12-bit complex packing (96 bits per instant) it is 25 Msps.
Burst vs average. At 20 Msps the ADC produces data faster than 2.4 Gb/s during the ramp, but the chirp idle time lets the link catch up. The rule is packet time ≤ chirp period, not ADC rate ≤ link rate.
Frame average. 128 chirps × 4 KB = 512 KB per frame per chip. At 20 frames/s that is about 10.5 MB/s average, but 300 MB/s peak during the chirp burst. Size the receiver's FIFO and DMA for the peak.

Why CSI-2 rather than LVDS

The AWR2243's LVDS port is faster per lane (900 vs 600 Mb/s), but TI positions it as a raw-capture and debug path, typically into a capture card. For a production host, CSI-2 is the better fit:

Framing is in the protocol. Frame and chirp boundaries arrive as packets, with frame numbers, instead of being inferred from a frame clock.
ECC on headers and CRC on every chirp give a per-chirp integrity signal you can log and act on.
LP idle between chirps cuts I/O power, which matters in a sealed radar enclosure.
Hard CSI-2 receivers exist on most automotive SoCs. On an FPGA host the effort is similar either way.

Two chips in cascade

In a two-chip cascade the master shares its 20 GHz LO so both chips chirp coherently: 6 TX × 8 RX = 48 virtual channels. The data paths stay independent. The FPGA receives two CSI-2 links and lines them up using the frame and chirp numbers.

The cascaded board pairs two AWR2243s. The master generates the 20 GHz LO and shares it with the slave, so both chirp coherently: 6 TX × 8 RX gives 48 virtual channels for angle estimation. A common frame trigger starts both chips together.

On the data side the two chips are independent CSI-2 transmitters, each with its own clock lane. The FPGA needs two complete receivers, each in its own clock region. It aligns the streams by frame number and the chirp number in the chirp header, not by arrival time, because the two links can differ by a few byte clocks.

Bring-up notes

Configure the CSI-2 lane rate and lane count on the AWR2243 first, then set the receiver's HS-SETTLE for that rate.
Scope one data lane: confirm LP-11 at ~1.2 V between chirps and a ~200 mV differential HS burst once per chirp period. The bursts line up with chirp timing, which is a useful sanity check.
Get Frame Start and Frame End short packets parsing before anything else. They're short, so the word count can't be wrong.
Count ECC corrections and CRC errors per frame. If errors correlate with TX enable or with particular chirp profiles, look at supply noise and coupling from the RF section (self-desense showing up as digital errors) before blaming the receiver.

Questions to expect

Why does a radar chip use a camera interface?

A radar frame of chirps looks like an image of lines: fixed-length rows produced at a regular rate. CSI-2 already provides framing, integrity checking, low-power idle and a large base of host receivers. TI reused it rather than inventing a radar-specific link.

What limits the chirp rate on the data side?

Each chirp's packet must finish before the next chirp's data is ready: packet time plus the LP/HS overhead must fit in the chirp period. With 4 lanes at 600 Mb/s and 4 KB chirps that's about 14.5 µs, so chirp periods below that need fewer samples, narrower samples, or fewer RX channels in the stream.

How did the board use this?

Each AWR2243 sent its chirps over a 4-lane CSI-2 link into the Zynq PL. The PL deserialized, checked CRC, and wrote chirps into DDR by DMA. Processing ran close to the sensor because the vehicle link (100BASE-T1, about 12.5 MB/s) could never carry the raw cube; only the processed output left the board.