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?

• Related Articles

• 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, ...

• 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 ...

• 6199 - Byte to Pixel of CrossLink: Does the output data valid when lv_o becomes high?

  The pd_o outputs as soon as the lv_o is asserted high. So, within lv_o high assertions, data are valid.

• 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.

• 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 ...