Honored Contributor
Honored ContributorCarsten,
Without knowing more about the I/O IP and clocking architecture implementation it is difficult to say precisely what the issues are, but... It looks to me like you have three issues: 1. Resource contention. Two PLLs instantiated in the RTL are competing for the same resource in the silicon. This can happen with multiple ALTLVDS or transceivers when instances since there are dedicated clocks for them. Warning Message Type 1 makes this clear. **Warning Message Type1: Warning: The parameters of the PLL [x] and the PLL [x] do not have the same values - hence these PLLs cannot be merged 2. Incorrect MegaFunction I/O connections. Warning Messages of Type 2 indicate there are different sources (pins, registers, clock routing) for 2 separately instantiated PLL inputs. **Warning Message Type2: Warning: The input ports of the PLL [A] and the PLL [B] are mismatched, preventing the PLLs to be merged Warning: PLL [C] and PLL[D] have different input signals for input port ARESET 3. Using normal routing for clocks instead of dedicated clock routing. This probably means the clock is passing through logic - it's not just connected to clock ports of PLLs, registers, RAMs, etc. That degrades performance and generally is not good design practice. Don't do this unless you REALLY must. **Warning Message Type3: Warning: PLL [D] is not fully compensated and may have reduced jitter performance because it is fed by a non-dedicated input **Warning Message Type4: Warning: PLL [E] output port clk[0] feeds output pin "DviOClk~output" via non-dedicated routing -- jitter performance depends on switching rate of other design elements. Use PLL dedicated clock outputs to ensure jitter performance **Warning Message Type5: Warning: PLL [F] feeds output pin "Clk_66_E6_0~output" via non-dedicated routing -- jitter performance depends on switching rate of other design elements. Use PLL dedicated clock outputs to ensure jitter performance Good luck, Mike P.S. Have you tried using MySupport?
