6197 - All Nexus: Is Pixel to Byte IP's (P2B) RGB666 tightly packed?

RGB666 is only packed, thus, can only see data type 1E. The user can still use RGB666 loosely packed using RGB888 since the mapping are the same. For the loosely packed, it need to zero out input bits [7:6], [15:14] and [23:22]. In pixel-to-byte GUI, the user can only select RGB666 as packed.

On another note, the DT found in the directives is going to the input of DPHY TX. Signal data_type_o in pixel-to-byte module is not used in the reference design that you see.

Related Articles
7208 - Pixel-to-Byte IP version 1.5: Why does the byte data from Pixel-to-Byte IP version 1.5 shows missing pixels data?
Description: There is a known issue in Byte to Pixel IP version 1.5, which it causes the MIPI data packets missing. Solution: There is no planned fix for version 1.5. Please upgrade the IP to version 1.6 or above.
6396 - Byte-to-Pixel IP v1.4.0: Why are there no exception constraints between the byte clock and pixel clock, e.g. set_clock_groups constraints for each clock in the IP LDC file?
The set_clock_groups or any exception constraints were not defined in the IP LDC file as it would be difficult if the IP is used in a system design and the customer wants to analyze the paths between the clocks or does not want the clock domain ...
5788 - [Pixel to Byte Converter IP Core]: How to control the input signals (fval_i/dval_i/txfr_en_i/txfr_req_o)?
The fv_i and lv_i signals are only for CSI-2 mode, and unused in DSI mode. The user can leave it undriven if they are using DSI mode. If, however, they are using it for CSI mode, these signals should indicate frame valid and line valid pulses. The ...
7681 - Pixel-to-Byte IP v1.7.0: Why do I encounter interruption on the MIPI long packet transmission after a while when connecting lp_en_o from P2B v1.7.0 to lp_en_i of DPHY_TX? However, when I delay the lp_en_o by one clock and then connect to DPHY TX,
The lp_en flag needs to be delayed depending on the data type / number of pixel lanes. User would need to fine tune between the lp_en_o and lp_en_i to get the correct transmission.
6321 - CrossLink-NX: Why are there no exception constraints between the byte clock and pixel clock, e.g. set_clock_groups constraints for each clock in the IP LDC file?
The set_clock_groups or any exception constraints were not defined in the IP LDC file as it would be difficult if the IP is used in a system design and the customer wants to analyze the paths between the clocks or does not want the clock domain ...

6197 - All Nexus: Is Pixel to Byte IP's (P2B) RGB666 tightly packed?

6197 - All Nexus: Is Pixel to Byte IP's (P2B) RGB666 tightly packed?

Related Articles

7208 - Pixel-to-Byte IP version 1.5: Why does the byte data from Pixel-to-Byte IP version 1.5 shows missing pixels data?

6396 - Byte-to-Pixel IP v1.4.0: Why are there no exception constraints between the byte clock and pixel clock, e.g. set_clock_groups constraints for each clock in the IP LDC file?

5788 - [Pixel to Byte Converter IP Core]: How to control the input signals (fval_i/dval_i/txfr_en_i/txfr_req_o)?

7681 - Pixel-to-Byte IP v1.7.0: Why do I encounter interruption on the MIPI long packet transmission after a while when connecting lp_en_o from P2B v1.7.0 to lp_en_i of DPHY_TX? However, when I delay the lp_en_o by one clock and then connect to DPHY TX,

6321 - CrossLink-NX: Why are there no exception constraints between the byte clock and pixel clock, e.g. set_clock_groups constraints for each clock in the IP LDC file?