Forum Discussion

RPDM's avatar
RPDM
Icon for Occasional Contributor rankOccasional Contributor
8 years ago
Solved

LVDS SERDES reference clock enforcement change in 18.1

Hi, In Quartus 17.1 & 18.0, on an Arria 10, I was able to use a Dedicated Transceiver Reference Clock to feed the PLL used to generate some LVDS outputs. In 18.1, my existing design generates an er...
  • JosephC_Intel's avatar
    JosephC_Intel
    8 years ago

    Hi Richard ,

    What being communicated by Anand on October 10, 2018 is correct. We've been discussed internally back and forth regarding this inquiry. At design perspective, we do not encourage to use TX ref clk for LVDS SERDES. Quartus II Tools should have and had to blocked this setting even in earlier version released.

    So, what being captured in Table 9 in LVDS SERDES Guide is determined on how this operational setting going to works. Any standalone interfaces less than 23 channels required a refclk pin in within the same IO Bank whereby for those interfaces that consist of more than 23 channels, we would recommend to use channels 23-71 for refclk input sharing.

    On the other hand, we are working on a fix on future release (Tentative) to have more error checking. This will make sure users isn't using the clock from another IOPLL or some other sources from IO Bank.

    For your PCB design, we would recommend to used Quartus V18 if this suite yours product or change your design based on later Quartus LVDS SERDES characterizations. Otherwise, this options will not be allowed from Quartus V18.1 and onward.

    I hope this addressed yours doubt and thanks for using this forum to get support.

    Thanks,

    Joseph

    Intel Customer Support

gof00's avatar
gof00
Icon for New Contributor rankNew Contributor
7 years ago

The actual problem is that this strict rule create the problem for the Triple Speed Ethernet on Cyclone 10 GX dev kit.

The fact is that periodically builds in Quartus 18.0 with the Triple Speed Ethernet MAC / PCS can't negotiate 1000 Mbits speed.

I just took the simple socket server reference/example design from Cyclone 10 GX dev kit examples and added a bit of my logic that is synchronous to Qsys clock and by switching Signal Tap on and off (plus rebuild) I can "fix" the speed negotiation problem.

Timing constraints are from the original SSS design and met so I can put 99% that Triple Speed Ethernet is not constrained properly for 18.0! Now I need to brute-force it with other version such as 17.1, 19.1, 19.2 or try solution from MamaSaru.

It's not fun even if it's still better than brand x. Just to stop brand x lovers/zombies be happy about that issue I can add that at my last two jobs I had to deal with designs for brand x where timing just failed (timing was not constrained and it was not met!) but these designs were pushed or into production or for evaluation by customers such as Comcast in US.

(In fact it's a typical problem for brand x. You can guess how I was "happy" so as a bit of payback I will not(!) mention cores where brand x missed its timing constraints and I had to fix it ;-)

So please update all reference designs of the Cyclone 10 GX dev kit (and other kits) to the latest version of Quartus.

In Altera's times new versions / improvements of Quartus were tested against the customers designs. It will be good to do the same thing with the reference designs/examples from Altera. Because you may not have the option to stay on the previous version of Quartus. I can fix my code but fixing code from the vendor is giving the reason for another brand x zombie with its fake smile just stick to you.

Again it's time to have the measurable advantage and Good Luck!