Summary of video interfaces/formats supported:
8-bit interface:
- YUV422 (interleaved) with discrete sync or embedded sync (BT.656).
- pixel- or line-multiplexed multi-video stream with embedded sync.
16-bit interface:
- RGB565 with discrete sync. Can alternatively use d3-d7 + d10-d15 + d19-d23.
- YUV422 (separate luma/chroma) with discrete sync or embedded sync (BT.1120).
24-bit interface:
- RGB888 or YUV444 with discrete sync or embedded sync (BT.1120).
"Embedded sync" means synchronization markers are embedded in the video data stream,
similar to the sync pulses embedded in analog composite video signals, and therefore the
interface only uses clk + data lines, no separate synchronization signals.
"Discrete sync" means separate vsync/hsync/de/fld signals (or some subset thereof) are
used to synchronize to the video timing. To use discrete sync, the video input port
requires at least vsync+hsync or vsync+de. Interleaved video additionally needs either
fld or vsync+hsync (in the latter case the field identification is determined by timing
of vsync relative to hsync, same as in analog video).
======== vin4a (VIP2 slice 1 input A) ========
It's a mix of different iosets so timing is probably degraded (unless you manage
to tune the iodelay manually), which will limit the max pixel clock supported.
Nearly a full-featured input, except only 23 of the 24 data signals are available;
you can pick any two of { d7, d8, d17 } but not all three.
For 24-bit RGB or YUV444, sacrificing d8 is probably the best option, since it is the
least significant bit of one channel. By default it will be green (for RGB) or Cb
(for YUV), but you can use the "repacker" to swap channels and e.g. make d8 the least
significant bit of the _blue_ channel instead to minimize the visual impact of its loss.
For 16-bit RGB or YUV422 input on d0-d15, you don't need d17 so there's no problem.
RGB565 can also be provided on d3-d7 (blue) + d10-d15 (green) + d19-d23 (red), i.e. the
most significant bits of RGB888. In this case neither d8 nor d17 is used.
P9.22 clk
P9.24 vsync
P9.26 hsync
P9.41 de
P9.12 d0 also available on P9.19
P9.11 d1 also available on P9.20 and P9.27
P8.17 d2
P8.27 d3
P8.28 d4 or fld
P8.29 d5
P8.30 d6
P8.46 d7 or d17
P8.37 d8 or d17
P8.38 d9
P8.36 d10
P8.34 d11 same pin as vin2b vsync, see comments there
P8.35 d12
P8.33 d13
P8.31 d14
P8.32 d15
P8.45 d16
- d17 see d7/d8 above
P8.43 d18
P8.44 d19
P8.41 d20
P8.42 d21
P8.39 d22
P8.40 d23
======== vin6a (VIP3 slice 1 input A) ========
All pins belong to a single ioset.
Although only d8-d15 are available for this input, it should be possible to use the
"repacker" to swap those with d0-d7, hopefully allowing this port to be used for any
of the supported 8-bit interfaces.
P8.09 clk
P9.18 vsync
P9.17 hsync
P8.08 d8
P8.07 d9
P8.10 d10
P9.42 d11
P9.28 d12
P9.30 d13
P9.29 d14
P9.31 d15
======== vin2b (VIP1 slice 1 input B) ========
All pins belong to a single ioset, except for vsync.
This interface is not ideal for use with discrete sync:
- it has vsync + de instead of vsync + hsync (hence no support for interleaved video).
- the vsync signal belongs to a different ioset than the other signals.
- vsync is on the same expansion header pin as vin4a d11, and stealing that pin from
it would pretty much limit vin4a to 8-bit input.
It would have been nice if VIP supported DE-only discrete sync, but afaict it does not.
This port is still fine for video with embedded sync (BT.656) of course.
P8.04 clk
P8.34 vsync see comments above
P8.03 de
P8.22 d0
P8.23 d1
P8.06 d2
P8.05 d3
P8.24 d4
P8.25 d5
P8.20 d6
P8.21 d7
Comments