LVDS SERDES reference clock enforcement change in 18.1

[RPDM]

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 error: "Error(18694): The reference clock on PLL "xxxxx", which feeds an Altera LVDS SERDES IP instance, is not driven by a dedicated reference clock pin from the same bank. Use a dedicated reference clock pin to guarantee meeting the LVDS SERDES IP max data rate specification. "

Is it no longer possible to use the Dedicated Transceiver Reference Clock pins for this, especially for lower data rates?

Thanks,

Richard

[AnandRaj_S_Intel]

Hi Richard,

we appreciate your patience.

Yes, You are correct,Rules for LVDS SERDES IP as follows.

https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/ug/ug_altera_lvds.pdf

(Table 9)

1) Ref clock from the same bank as the LVDS and dedicated. 

Is correct if <23 channels.

2) Ref clock from another bank. 

  Is correct if >23 channels.

Let me know if this has helped resolve the issue you are facing or if you need any further assistance.

Best Regards,

Anand Raj Shankar

(This message was posted on behalf of Intel Corporation)

[RPDM]

Hi Anand,

Thanks - but why has it changed? 17.1 & 18.0 didn't have these rules. We now have a PCB design that cannot be compiled for under 18.1.

Regards,

Richard

[OAust]

Hi,

we are seeing the same problem. The rules seem reasonable for LVDS Rx, but not for LVDS Tx. Could this just be a bug? ​If it OK with a suboptimal routing for the clock for >23 channels, I cannot see why it should not be OK for a lower amount as well. If we are to use the LVDS Tx for a low speed link there is no problem with a bit of additional jitter.

Could we get a clear response from Intel on this issue? Is this something that will be fixed or is there a workaround?

Regards,

Oddgeir

[JosephC_Intel · Accepted solution]

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

[RPDM]

Hi Joseph,

I think it's a shame that this error checking wasn't in earlier Quartus versions, particularly as 17.1 & 18.0 allow a design that your LVDS IP Guides says shouldn't be allowed.

But I appreciate that this is ongoing work and thank you for detailed information you've provided.

Regards,

Richard

[MamaSaru]

Hi RPDM,

I have the same problem.

I found a workaround to make it fit.

Insert another x1 I/O PLL before driving SERDES PLL.

The connection between the inserted PLL and the SERDES PLL should use cascading input/output.

Hope this help.

Masaru

[gof00]

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!

[gof00]

Also the simple socket server reference/example design from intel fails on Cyclone 10 GX dev kit board (from Terasic) even if all clock and all serdes pins are located in the same bank as this error message request.

By default the simple socket server reference/example design for Cyclone 10 GX has two clocks. 125 MHz reference clock for PCS and 50 MHz clock from another bank (for the rest of the design).

You can simplify the design by driving all clock from one clock via iopll. But even if you generate 50 MHz clock by pll from 125 MHz dedicated clock input it still doesn't fit:

Error(18694): The reference clock on PLL "sss_qsys_inst|tse_0_tse|tse_mac|i_lvdsio_rx_0|core|arch_inst|internal_pll.pll_inst|altera_lvds_core20_iopll",

which feeds an Altera LVDS SERDES IP instance, is not driven by a dedicated reference clock pin from the same bank. Use a dedicated reference clock pin to guarantee meeting the LVDS SERDES IP max data rate specification.

It's the clear bug that can be easily reproduced when you try to compile the reference/example design in something newer than 18.0 pro.

[gof00]

Also the timing constraints for SGMII tx/rx (LVDS SERDES) in TSE are missed (the timing analyser reports about that). SGMII tx/rx ios are not constrained for delays.

From the formal point of view it's bad. From SGMII point of view it's irrelevant but gives the alarm bell.

There is more serious problem with clock constraints or clock domain crossing between PCS / SGMII bridge (LVDS SERDES) and MAC logic itself in TSE.

For some builds in 18.0 I have no link between phy and device itself. I can verify it from the PCS registers of TSE MAC. And it's on the Cyclone 10 GX reference board with the reference design from intel. MAC is ok but PCS fails.

As far as I tested it - it's because of two clocks from two different io banks.

Logically with the right clock domain crossing, the proper design and the correct clock constraints it must(!) be irrelevant or fail the timing(!). Timing is ok but in the real hardware it fails.

The reference sof file from the Dev Kit contents was compiled by the old version of Quartus and works ok.

However as soon as the placement of the logic inside of Cyclone is changed (for example Signal Tap is added or you recompile the reference design in the newer version of Quartus) it may fail in the real hardware. And the timing constraints are met (except the missed delays - for the test I left the original constraints intact).

So something is wrong or with the TSE / PCS hdl code and/or with the timing constraints.

Because of this limitation for the reference clock I added the internal pll just to generate 50 MHz clock from 125 MHz PCS reference clock. 

50 MHz clock becomes physically derived clock and the bug is bypassed! Builds are stable!

First of all for me it's another alarm bell about the clock constraints and clock domain crossing in TSE / PCS. (I just can't verify it more because I can't see the all source code).

Secondary there is far better and far more elegant solution for the reference clock limitation that is in the style of Altera and SDC rather than the typical badware from brand x (yes, in that respect brand x goes even worse.)

If the "bad placement" of the clock inputs affects the signals integrity, clock edges and the overall performance why it's not reflected by the timing analysis?

There is such good thing in SDC as the clocks uncertainty. Just increase it for the bad routing so if design has do the bad placement you see the timing failure! It's in line with the timing!

I understand that the reason this limitation is the high performance but not everybody needs the high clock rates. (For example I just need to use dev kit for a while and for me it’s unfair that I can’t use it with the latest Quartus.)

Also you can't protect yourself from the dumb users who has no idea about the timing. They will just fail their designs somewhere else and even ignore the timing failures from the timing analyser report. In fact from my recent experience in two companies I had to clean designs from the timing failures after brand x zombies in brand x software (that is far more manipulative) but failed(!) to turn them in the right direction.

It's better to take example from the success of Google with Chrome that was designed to be good first of all for the web developers(!) and not(!) for the web uses.