SPRUIE9D May 2017 – May 2024 DRA74P , DRA75P , DRA76P , DRA77P
The video mux connects video ports of different ISS sub-modules. Figure 9-5 below summarizes all possible connections using the following conventions:
Connections are enabled by selecting a source for each destination by configuring the relevant ISS_VMUX .[destination] register. Before changing a connection, SW shall ensure that pixel clocks of the old and the new sources are inactive. That can be guaranteed by disabling the clock with the relevant bit in ISS_CLKCTRL. The video mux contains width and frequency conversion FIFO that should naturally drain their data. However, in some particular cases (e.g. path is stalled by the source and FIFO still contains data when the source is switched) it may be necessary to explicitly empty those using the ISS_VMUX_RESET register. In some cases, it may also be necessary to reset the data destination module to ensure that it starts from a clean state when the previous data stream was aborted. Once the video connection has been properly configured, SW should first enable the destination module and only enable the source module when the destination is ready to receive data.
It is possible that a given source is connected to multiple destinations (i.e. broadcast). Several paths support flow control (i.e. the source could be stalled when one of the destinations cannot accept the data to avoid data corruption). An error event is triggered when the source could not be stalled (because the data source doesn't support flow control).
The memory storage format used for the full resolution stream should match the format received from the camera. However, the format used by the CAL engine may be different.
Generally speaking, CAL_B is used as general purpose pixel read and write DMA engine.
ISP and either NSF3V or GLBCE can operate independently from each other and may be used in memory to memory mode when they are attached to pixel read and/or write DMA engine like CAL. The choice of the DMA depends on the use case requirements (i.e. available internal datapath, available processing resources, etc.)
Table 9-11 summarizes the characteristics of the different source and destination video ports managed by the video mux.
Port | Type | Max. CLK (MHz) (OPP_HIGH)(1) | Channel # | Data width | HS | HE | VS | VE | FLD | WEN | STALL |
---|---|---|---|---|---|---|---|---|---|---|---|
CAL_B BYSin | Sink | 532 | 4 | 16 | X | X | X | X | |||
NSF3V in | Sink | 532 | 1 | 16 | X | X | X | X | X | ||
GLBCE in | Sink | 532 | 1 | 16 | X | X | X | X | X | ||
ISP in | Sink | 532 | 1 | 16 | X | X | X | X | X | ||
CAL_B BYSout | Source | 532 | 4 | 16 | X | X | X | X | |||
CAL_B VP | Source | 532 | 2 | 16 | X | X | X | X | X | ||
NSF3V out | Source | 532 | 1 | 16 | X | X | X | X | X | ||
GLBCE out | Source | 532 | 1 | 16 | X | X | X | X | X |
Table 9-12 summarizes how connections are physically implemented. It indicates for each possible connection shown in Figure 9-5
Path | SRC | Width translation | Freq converter | ISS_VMUX Register | ISS_VMUX_IRQ | Destination | Notes |
---|---|---|---|---|---|---|---|
I | CAL_B_BYS_OUT | W64_16_A | F304_426_D | NSF3V_IN=CAL_B_BYS_OUT | W64_16_A_OVR_IRQ F304_426_D_OVR_IRQ | NSF3V_IN | |
J | CAL_B_BYS_OUT | W64_16_B | F304_426_D | GLBCE_IN=CAL_B_BYS_OUT | W64_16_B_OVR_IRQ F304_426_D_OVR_IRQ | GLBCE_IN | |
K | CAL_B_OUT | W32_16_A | F304_426_E | ISP_IN=CAL_B_OUT | W32_16_A_OVR_IRQ F304_426_E_OVR_IRQ | ISP_IN | |
V | NSF3V_OUT | W16_64_A | F426_304_B | CAL_B_BYS_IN=NSF3V_OUT | W16_64_A_OVR_IRQ F426_304_B_OVR_IRQ | CAL_B_BYS_IN | |
X | GLBCE_OUT | W16_64_B | F426_304_B | CAL_B_BYS_IN=GLBCE_OUT | W16_64_B_OVR_IRQ F426_304_B_OVR_IRQ | CAL_B_BYS_IN |
The data source may generate additional horizontal blanking (PCLK pulses between HE and HS) and vertical blanking (additional lines) that is always forwarded to the destination accordingly to the performed width translation (that is, one PCLK pulse translates into 4 PCLK pulses in a 4->1 width translation bridge) and frequency translation (that is, one PCLK pulse in the source clock domain translates into one PCLK pulse in the destination clock domain). Therefore, a pixel clock that is too fast could also lead to a FIFO overflow in a down conversion. It is SW responsibility to set a suitable pixel clock using PCLK divider in the data source, if available.