Below is a practical, engineering-style implementation scheme for connecting an [FPGA](https://www.ampheo.com/c/fpgas-field-programmable-gate-array) to a MIPI interface. In practice “MIPI” almost always means:

* MIPI CSI-2 (camera sensors → FPGA), or
* MIPI DSI (FPGA → display panel)

And both typically run over MIPI D-PHY (the physical layer).


**1) First decision: Does your FPGA have a real MIPI D-PHY (hard PHY) or not?**
**Scheme A — FPGA with (hard) MIPI D-PHY support (cleanest)**

Pick an FPGA family that is designed for MIPI bridging/vision and provides D-PHY + CSI-2/DSI IP.
Example: Lattice CrossLink / CrossLink-NX are positioned specifically as low-power “video bridging” FPGAs and advertise fast MIPI D-PHY bridging solutions.

Lattice also offers a CSI-2/DSI D-PHY Receiver IP (soft/hard D-PHY options and multi-lane support).

**Block diagram (CSI-2 camera in):**

MIPI Sensor
  (CSI-2 over D-PHY)
        │  (Clk + N data lanes)
        ▼
[ D-PHY RX (hard/soft) ]
        ▼
[ CSI-2 Packet Layer ]
  - lane align / deskew
  - ECC/CRC check
  - virtual channel, data-type decode
        ▼
[ Pixel/AXI-Stream ]
        ▼
[ ISP / DMA / DDR Framebuffer / ML ]

**Block diagram (DSI display out):**

`[ Video / Framebuffer ] -> [ DSI Packetizer + Timing ] -> [ D-PHY TX ] -> MIPI DSI Panel`

If you’re on [AMD](https://www.ampheo.com/manufacturer/amd)/Xilinx, this is the typical model: MIPI CSI-2 Receiver Subsystem captures camera data and outputs it as AXI-based streams.

The associated MIPI D-PHY core provides the D-PHY RX interface and deskew support for higher line rates (implementation differs by device family).

(Also note: some vendor example designs/IP flows may require specific licenses. )

**Scheme B — FPGA WITHOUT MIPI D-PHY (very common): use an external bridge/PHY**

Most general-purpose FPGAs cannot directly terminate/handle D-PHY reliably at high speed without dedicated PHY/IP support see above. So you insert a bridge chip that converts MIPI to something “FPGA-friendly” (parallel RGB, LVDS, etc.).

**B1) Camera (CSI-2) → FPGA (no D-PHY): use CSI-2-to-Parallel bridge**

A standard option is a CSI-2/parallel bridge such as Toshiba TC358746, which can be configured as CSI-2 receiver or transmitter and bridges CSI-2 to a 24-bit parallel port (and the reverse direction).

**Typical block diagram:**

MIPI CSI-2 Camera
   │ (D-PHY)
   ▼
[ TC358746 (CSI-2 RX) ]  -->  24-bit Parallel (RGB/YUV/RAW) + PCLK/HS/VS
   │ I2C/SPI control
   ▼
FPGA (parallel capture) -> processing -> storage/output

This scheme is popular when:

* your FPGA has lots of GPIO but no D-PHY,
* lane rate is high and you don’t want a risky “soft D-PHY” hack,
* you want simpler FPGA RTL (parallel video capture is straightforward).

**B2) FPGA → Display panel (DSI) without implementing DSI: use DSI-to-LVDS/eDP bridge**

If your output is a laptop-style LCD that accepts LVDS (or you can convert), a bridge like [TI](https://www.ampheo.com/manufacturer/texas-instruments) [SN65DSI83](https://www.onzuu.com/search/SN65DSI83) accepts MIPI DSI (D-PHY, up to 4 lanes) and outputs LVDS (FlatLink).

**Typical block diagram:**

FPGA RGB (parallel) + timing
        ▼
[ DSI Bridge (e.g., SN65DSI83) ]  <- (if it expects DSI) OR -> LVDS panel

(Depending on the bridge direction you need, you pick the right part; SN65DSI83 is specifically a DSI-to-LVDS bridge with a D-PHY receiver. )

**Scheme C — “Soft D-PHY / resistor network” (only for narrow cases)**

There are community/legacy approaches that split HS/LP signaling into LVDS + LVCMOS and attempt D-PHY compatibility on some FPGA I/O banks, but this is speed/robustness limited and usually not what you choose for a product unless you’ve proven it thoroughly. (Good for experiments; risky for production.)

**2) Hardware connection rules that matter (regardless of scheme)**
**CSI-2 / DSI wiring basics**

* One Clock lane + 1/2/4 data lanes (most common)
* Short, impedance-controlled differential routing (typically ~100 Ω differential), good return paths, ESD protection near [connector](https://www.onzuu.com/category/connector-interconnects)
* Keep pair lengths matched within each differential pair; keep lane-to-lane skew controlled if you’re pushing high lane rates

**Power/IO domains on bridge/PHY chips**

Bridges often have a dedicated MIPI D-PHY core supply (commonly 1.2 V) plus I/O supplies for control/parallel ports. For example, TC358746 lists separate supplies (core/D-PHY vs I/O).

**3) FPGA design blocks you’ll implement (CSI-2 example)**

If you have CSI-2 coming into the FPGA (either directly via D-PHY IP, or indirectly via a bridge output), your internal pipeline usually looks like:

1. Lane capture / deserialization (or parallel capture)

2. Packet parsing

* detect frame start/end
* handle virtual channels and data types
* validate ECC/CRC (often handled by vendor IP)

3. Pixel unpacking

RAW10/12 packing → pixel words

4. Line/frame buffering

* FIFO for line
* DDR frame buffer if you need random access / scaling

5. Processing

ISP (debayer, color correction) or ML/[DSP](https://www.ampheo.com/c/dsp-digital-signal-processors)

6. Output

HDMI/DP, LVDS, Ethernet streaming, PCIe, etc.

On AMD/Xilinx, the CSI-2 RX subsystem explicitly targets this style of output by providing AXI4-based sensor data out of the subsystem.

**4) Quick “which scheme should I choose?” guide**

* You want the simplest BOM + highest performance and can choose FPGA family
→ Scheme A (FPGA with D-PHY + CSI-2/DSI IP)
* You already have a mainstream [FPGA](https://www.ampheoelec.de/c/fpgas-field-programmable-gate-array) without D-PHY and just need it to work
→ Scheme B (external MIPI bridge/PHY) using CSI-2↔Parallel bridges like TC358746

and/or DSI bridges like SN65DSI83 for display conversion

* You’re prototyping for learning at modest speeds
→ Scheme C can be explored, but expect edge cases.