PMA Direct Transceivers and ATX PLLs

Did you review the list of errata:

http://www.altera.com/literature/es/es_stratixiv_gx.pdf

Search for ATX in the document. There are a few errata listed. I'm not sure if its one that is affecting you.

Note the placement restrictions on p11, i.e., ATX PLLs cannot drive all the transceivers blocks on a side, but only the ones right next to it.

The GTs have a similar errata. I created a 32 x 10Gbps transceiver design using CMU PLLs and it was acceptable to Quartus.

Cheers,

Dave

Hi Dave,

Thank you for taking a look at this.

I did see the errata but the errors I'm seeing seem to be related to the difference in the clock settings between PMA direct transmitters and transmitters running in Basic mode. I can use two CMU transceivers within one block of the ATX PLL in PMA direct xN mode and it works fine. If I add two adjacent transceivers on normal channels and put them in PMA direct mode just like the CMU transceivers, that also works. If I run the basic transceivers in basic mode along with CMU transceivers in PMA direct mode, it fails, even if I check the Use ATX pll box in the normal transceiver megafunction. I'd much rather use the hardened transceiver functions where available instead of spending the LEs to implement the PCS in the fabric but it looks like there's a solution at least.

I could have sworn I got it working before but I can't seem to get it to compile now. Taking a closer look at the working CMU transceivers, the transmit clocks are coming from the ATX PLL and the receive clocks are coming from the PLL in bypass mode to drive the CDR. I wonder if this is just the graphic representation in the Chip Planner since the ATX PLL uses the xN clock lines. I'll see if I can at least get both basic and PMA direct receivers to play nice.

Thanks again,

Scott

--- Quote Start ---

I did see the errata but the errors I'm seeing seem to be related to the difference in the clock settings between PMA direct transmitters and transmitters running in Basic mode.

--- Quote End ---

Ok.

--- Quote Start ---

I can use two CMU transceivers within one block of the ATX PLL in PMA direct xN mode and it works fine. If I add two adjacent transceivers on normal channels and put them in PMA direct mode just like the CMU transceivers, that also works. If I run the basic transceivers in basic mode along with CMU transceivers in PMA direct mode, it fails, even if I check the Use ATX pll box in the normal transceiver megafunction.

--- Quote End ---

You're taking a nice systematic approach to this :)

I haven't tried to use the CMU transceivers since they would be too slow for my application.

--- Quote Start ---

I could have sworn I got it working before but I can't seem to get it to compile now.

--- Quote End ---

Perhaps you have changed Quartus versions since your last test? I just had a gnarly problem that Altera has yet to respond to (via an official SR):

http://www.alteraforum.com/forum/showthread.php?t=39893

--- Quote Start ---

Taking a closer look at the working CMU transceivers, the transmit clocks are coming from the ATX PLL and the receive clocks are coming from the PLL in bypass mode to drive the CDR. I wonder if this is just the graphic representation in the Chip Planner since the ATX PLL uses the xN clock lines.

--- Quote End ---

I haven't looked into the clock source in this much detail. However, I would expect the receiver CDR reference would be a direct route from whatever clock source you've chosen. When you configure the ALTGX you can select independent transmit and receive reference clocks, but if you enable the block for reconfiguration mode, those clock sources become a common signal. That implies the clocking is in fact common, and that the GUI is splitting them apart to make the visualization a little less mentally challenging.

--- Quote Start ---

I'll see if I can at least get both basic and PMA direct receivers to play nice.

--- Quote End ---

I have a couple of Stratix IV GX Development kits and a DE4. If there is something you want me to test, let me know ...

Cheers,

Dave

Hi Dave,

Wow, I really do appreciate the detailed response! I also appreciate the offer to help dig in but I don't want to drag you into my issue. I was hoping someone had crossed this bridge before but I certainly don't want to create more work for you than I already have.

It may be a Quartus issue but looking at the nature of the problem, it seems like maybe it's correctly asserting the rules now where it might not have in the past. I don't think I'd used PMA direct xN before but it explicitly states in the documentation that you have to use that mode if you use the ATX PLLs. The errors and documentation seem to agree but there are enough gaps in the manual that I still might have a chance to get what I'm looking for. My concern is that the receiver CDR clocks might use some of the same clock distribution resources as the ATX PLL, making it so they can't be used together. I'll have to dig a little deeper on that one and if I come up with something, I'll post an example here.

I'm not sure if you've gotten any response on the service request but I had put one in a while back for the Transceiver Toolkit on Stratix IV and the official answer I got was that the it has limited (i.e. no) support beyond the design examples. I wanted to see if I could get the low latency phy working (CMU transceivers in PMA direct mode) and see if I could push some of the required components into hierarchical blocks to reduce the size of the Qsys design and increase the number of channels , neither of which I got working due to some low level errors. In the end, I just worked around it.

Thanks again,

Scott

--- Quote Start ---

Wow, I really do appreciate the detailed response! I also appreciate the offer to help dig in but I don't want to drag you into my issue. I was hoping someone had crossed this bridge before but I certainly don't want to create more work for you than I already have.

--- Quote End ---

Thanks :)

--- Quote Start ---

It may be a Quartus issue but looking at the nature of the problem, it seems like maybe it's correctly asserting the rules now where it might not have in the past. I don't think I'd used PMA direct xN before but it explicitly states in the documentation that you have to use that mode if you use the ATX PLLs. The errors and documentation seem to agree but there are enough gaps in the manual that I still might have a chance to get what I'm looking for. My concern is that the receiver CDR clocks might use some of the same clock distribution resources as the ATX PLL, making it so they can't be used together. I'll have to dig a little deeper on that one and if I come up with something, I'll post an example here.

--- Quote End ---

The documentation is definitely lacking in places. However, the IP is so flexible, I can see the problem Altera has in providing all the possible combinations of modes ...

--- Quote Start ---

I'm not sure if you've gotten any response on the service request ...

--- Quote End ---

Nope, nothing other than "We have received your request ... "

--- Quote Start ---

but I had put one in a while back for the Transceiver Toolkit on Stratix IV and the official answer I got was that the it has limited (i.e. no) support beyond the design examples. I wanted to see if I could get the low latency phy working (CMU transceivers in PMA direct mode) and see if I could push some of the required components into hierarchical blocks to reduce the size of the Qsys design and increase the number of channels , neither of which I got working due to some low level errors. In the end, I just worked around it.

--- Quote End ---

That was my impression when I first looked at it. Its actually pretty easy to create an Avalon-MM system with access to the transmitter and receiver controls, including EyeQ. I ran a few eye pattern sweeps using Tcl and my own bit-error-rate logic. Unfortunately, the EyeQ feature in the Stratix IV series is too slow (it doesn't run at 10G speeds).

Cheers,

Dave