Arria V Transceiver Clocking

It would appear that the ONLY way to make use of the fractional PLL's built into the Arria V for the purposes of implementing a CMU PLL is to use the Native PHY mode available from the Mega Wizard.

Unfortunately, Quartus II 12.0(sp2) does not support the hard PCS logic built into the transcecivers but release 12.1 does support the Tx and Rx PCS logic which leaves us to reinvent the wheel and implement this set of logic within the fpga core. However, it remains to be seen if this mode supports bonded applications.

I have not heard if release 13.0 will provide an option in the Custom PHY to make use of a fractional PLL to act as the CMU....

One other issue with the Native PHY is that the PHY management interface does not appear to be supported.

Hi,

Two years later, I'm confronted to the same problem... Anything new about this?

I'm working on Quartus 13.1 and it seems like you can't yet configure the custom phy ip core with extern/fractional PLL...

I hope that I'm wrong.

Thanks in advance for your help,

Houssem

Hi,

I have sent a similar question to Altera Support team and received an answer from the CMU support group.

" transceivers consumes one additional transceiver as CMU."

1) a x8 bonded transceiver attempts to put the CMU in the middle transceivers ( total 9 transceivers)

2) a x4 bonded transceiver attempts to put the CMU in the beginning transceivers. ( total of 5 transceivers)

3) a single transceiver uses one additional transceiver as CMU. (total of 2 transceivers)

for system planning purposes,

1) single transceiver implementation use 200% as many transceivers as expected

2) quad transceiver implementation use 125% as many transceivers as expected

3) Octal transceiver implementation use 112% as many transceivers as expected

4) the pin assignments of the DK-START-5agxb3n preclude using all of the available serdes as transceivers.

An excellent example of QUAD transceiver implementation is the PCI-e x4 megawizzard.

An excellent example of OCTAL transceiver implementation is the PCI-e x8 megawizzard.

Indeed, the Custom PHY IP only offers CMU as for transceiver channel PLL (in Qts II 13.1.0 for the time being).

Keep in mind a channel PLL can be configured either as a CMU PLL for the TX PMA or a CDR to clock the RX PMA.

For Duplex operation, the channel PLL is necessary configured as a CDR. Therefore, the channel PLL is no longer available as a CMU PLL to clock the TX PMA. The only remaining TX PLL source is a fPLL (or an ATX PLL if you can afford Arria V GZ devices…). As fPLL frequency can be set up to 1.6GHz, this limits the data rate up to 3.2Gbps (the channel PLL VCO operates at half the data rate and serializer/deserializer are likely working on rising and falling edges of the VCO clock i.e., in DDR mode).

While the Custom PHY IP doesn’t offer any input for an external TX PLL source, the Native PHY does !

It is named “ext_pll_clk” (Tick “Use external TX PLL” in the TX PMA section of the Native PHY IP Core). Simply feed this input with a fPLL which frequency is set to half the TX data rate (remember: Max. frequency is 1.6GHz).

Channel bonding is another issue but using separate clock sources for your RX path and TX path should provide you enough flexibility to reach a proper instantiation scheme and get the fitter successfull.

Oliver