5424 - CMOS-TO-DPHY IP: Why does the connection type is still "pad-pin"declared in Clarity even if the signal does not go to I/O pins but rather go to internal logic?

Solution

Clarity Designer builder for modules and IP such as cmos-to-dphy is intended to be stand alone and thus it automatically generates a pad-pin type of connection. It is already a known issue when this IP module is used or connected as part of the bigger design. This, however, does not disrupt the functionality due to the misleading connection type.

Related Articles
5924 - D-PHY to CMOS v1.2/CrossLink: Why does the DPHY RX channel signal did not move from LP to HS mode?
This is due to metastability encountered in v1.2. It is recommended to upgrade to DPHY to CMOS v1.3 with the corresponding IP fix.
5777 - [CrossLink] [MIPI D-PHY to CMOS Interface Bridge IP]: What can be the cause of frequency calculation error in DPHY to CMOS GPLL after clicking the 'Calculate PLL Frequencies' button of the DPHY-to-CMOS v1.3 Clarity GUI with provided configuration
With regards to D-PHY to CMOS v1.3 GUI, if the user happens to encounter the dialogue prompt saying that "the desired frequencies for this configuration could not be generated by the PLL", it means that it is not a recommended value that will be used ...
1315 - PCIE IP: Why is a DRC error generated associated with the PCI Core signal/pin serrn (SERR#)?
SERR# is defined as an Open-Drain pin in the PCI Local Bus Specifications. In certain PCI applications, a PCI agent might be required to monitor the SERR# pin so that the agent can properly respond to the system error condition. When using one of the ...
1102 - All FPGAs: Does Lattice PCIe IP support SERDES pins polarity inversion and PCIe lanes reversal?
Description: The PCIe specification provides a dedicated layout of the PCIe lanes on the connector. Due to the fixed location of the SERDES pins on Lattice device packages aligning package pins to PCIe lanes can either work perfectly or create a ...
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.

5424 - CMOS-TO-DPHY IP: Why does the connection type is still "pad-pin"declared in Clarity even if the signal does not go to I/O pins but rather go to internal logic?

5424 - CMOS-TO-DPHY IP: Why does the connection type is still "pad-pin"declared in Clarity even if the signal does not go to I/O pins but rather go to internal logic?

Related Articles

5924 - D-PHY to CMOS v1.2/CrossLink: Why does the DPHY RX channel signal did not move from LP to HS mode?

5777 - [CrossLink] [MIPI D-PHY to CMOS Interface Bridge IP]: What can be the cause of frequency calculation error in DPHY to CMOS GPLL after clicking the 'Calculate PLL Frequencies' button of the DPHY-to-CMOS v1.3 Clarity GUI with provided configuration

1315 - PCIE IP: Why is a DRC error generated associated with the PCI Core signal/pin serrn (SERR#)?

1102 - All FPGAs: Does Lattice PCIe IP support SERDES pins polarity inversion and PCIe lanes reversal?

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,