Illustrative camera: 1,920 × 1,080 active pixels, 30 frames/s and RAW10 payload packing, with no compression. Active payload is 1,920 × 1,080 × 30 × 10 = 622.08 Mb/s. With two equally loaded data lanes the active-payload average is 311.04 Mb/s per lane before packet and physical overhead.
This average is a lower bound, not a selected D-PHY lane rate: line bursts, packet headers/CRC, blanking policy, transition time and implementation limits still matter. CSI-2 carries the camera stream. A DSI panel is a separate display endpoint with its own video/command mode and DCS/generic command contract.
Budget a camera stream without confusing it with display control — worked trace
Illustrative isolated example; not measured silicon behaviour.
Quantity | Value | What it establishes |
|---|---|---|
Active pixels per frame | 2,073,600 | No blanking or packet overhead counted |
RAW10 payload | 20,736,000 bits/frame | Ten bits per active pixel under this packing assumption |
Thirty frames per second | 622.08 Mb/s total | Active-data average only |
Two data lanes | 311.04 Mb/s each before overhead | Not proof that a 312 Mb/s lane setting will work |
No. It leaves essentially no allowance for overhead and ignores when line bursts must finish. Build the line-time budget and check the actual PHY/receiver configuration.
Scope: a conventional forwarded-clock D-PHY camera path, using the basic CSI-2 packet concepts present in CSI-2 v1.3/D-PHY v1.2. The public MIPI CSI-2 version-history table identifies that pairing; public feature descriptions are not a replacement for the licensed revision when implementing wire timings. DSI display operation is a separate protocol and panel contract, not another name for CSI-2 camera packets.
In this D-PHY teaching model LP signalling uses single-ended states, while HS data signalling is differential. HS entry and exit surround an HS burst; do not label the start-of-transmission sequence as a normal LP data packet. The clock-lane operating mode and timing limits must come from the selected PHY configuration.
In the conventional D-PHY example here, a clock lane accompanies high-speed data lanes. Lane count, supported lane rate and packet overhead bound payload capacity. This is not a universal lane diagram for CSI-2: C-PHY and other supported mappings have different physical signalling. Select the actual protocol/PHY revisions before defining wire-level serialization or packed-pixel byte order.
Separate the packet route from data-lane mode changes
Conventional forwarded-clock CSI-2/D-PHY scope from the lesson. A separate clock lane accompanies the data lanes. Rows are causal mode milestones, not electrical timings or simulation samples.
Milestone | Data-lane view | Packet interpretation |
|---|---|---|
Before burst | LP idle in this example | No completed packet inferred |
Enter high-speed operation | HS entry sequence under the selected PHY rules | Do not treat entry as a payload byte |
High-speed transfer | HS burst carries encoded traffic | CSI-2 receiver interprets the packet stream |
Leave high-speed operation | HS exit back to LP idle | One burst is not asserted to equal exactly one packet |
What to notice
The packetiser-to-data-lanes-to-receiver route and the PHY mode sequence describe different abstractions.
No wire-level durations, clock-lane mode policy or one-packet-per-burst guarantee is invented here.
No. Packet boundaries come from the CSI-2 packet stream. This conceptual mode sequence does not impose a one-to-one packet-to-burst mapping.
For the conventional CSI-2 packet example, long packets carry a header including data type and word count, payload and payload CRC; short packets carry frame synchronisation information. Frame Start and Frame End delimit the example frame, while Line Start and Line End packets are optional in the referenced CSI-2 receiver example (Microchip UG0763 revision 1.0). Do not import DSI video timing names as universal CSI-2 packet names.
Check the sensor's complete frame schedule and the receiver's line, buffering and service contract. Blanking, packet bursts and downstream memory service all affect capacity. Frame drops are a symptom with several possible causes, not proof of insufficient blanking alone.
Camera payload budget before packet and PHY overhead
Illustrative uncompressed 640×480 RAW10 camera at 30 frames/s, exactly ten packed bits per active pixel, no embedded-data rows or extra padding. Each line has 800 payload bytes. Assume the selected sensor/receiver support the chosen rates. For a preliminary planning bound only, reserve 20% of aggregate lane rate for overhead/idle; this is not a MIPI-prescribed efficiency.
Quantity / configuration | Calculation | Decision at this boundary |
|---|---|---|
Active image payload | 640 × 480 × 30 × 10 = 92.16 Mb/s | A lower bound on required transport capacity. |
Two data lanes at 100 Mb/s each | 200 × 0.8 = 160 Mb/s planning capacity | Average-rate budget fits; still inspect burst and buffering requirements. |
One data lane at 100 Mb/s | 100 × 0.8 = 80 Mb/s planning capacity | Does not fit the stated payload at this assumed efficiency. |
Memory consumer pauses | Accumulate incoming bytes during the pause | Enough average lane capacity does not prevent receiver FIFO overflow. |
What to notice
Include packet headers/footer, supported blanking and actual HS entry/exit costs in the real schedule; a guessed efficiency is not final signoff.
Word count counts packet payload bytes, not pixels. This chosen 640-pixel RAW10 line has 800 payload bytes under the stated packing assumption.
No. Incoming bursts can fill finite buffering during a service pause even when long-term average rates fit. Correlate packet arrivals, receiver occupancy and downstream service, then size or limit traffic under an explicit maximum-pause assumption.
Virtual channels multiplex multiple data streams on same lanes.
RAW, RGB, YUV formats differ in bits-per-pixel and packing.
Lane remapping or polarity correction is implementation-dependent; verify supported wiring and configuration at both ends.