Intel FPGA: Source-synchronous input using PHY Lite

Question

I have been trying for several months to get hold of information about how to use an Intel PHY Lite IP (for Arria 10 or Cyclone 10 GX) to implement a source-synchronous input interface:

• Last December, I asked this question on the official Intel FPGA forums, but received no useful replies.
• I asked a very similar question here on electronics.stackexchange, which helped me to confirm that PHY Lite is the correct solution to my problem.
• I then asked this question about PHY Lite in the official Intel forums, but received no useful replies.
• I recently re-phrased that into a similar question about PHY Lite in the official forums, but have received no replies yet (after 2 days).

What I have learnt so far

Besides the PHY Lite user guide, my main source of information is Intel's AN756, which describes how to migrate high-speed GPIO to the PHY Lite IP core.

There is a whole subsection related to source-synchronous interfaces. But unfortunately, there is no text description, just this one diagram showing an input interface:

diagram

My main difficulty is that the upper half of this figure (showing traditional GPIO) has two external inputs: Data and Clock. However, the lower half (PHY Lite) has three: Data, Strobe In and Ref Clock. So I don't understand what Strobe In and Ref Clock need to be connected to. In particular, I want to know if my PCB schematics need to be changed to support PHY Lite.

I can see from Table 3 of AN756 that the external (source-synchronous) clock should be connected to strobe_in:

screenshot

This is also confirmed in Table 1:

screenshot

However, I don't fully understand the role of ref_clk. I know it is recommended that this clock comes from a dedicated clock pin, but it is possible to use a quartus.ini hack to allow this clock to come from inside the FPGA (PLL).

Table 78 of the PHY Lite user guide points out that ref_clk must be synchronous with strobe_in "to ensure the dqs_enable signal is in-sync with strobe_in":

enter image description here

However, I am not sure if this is relevant for a simple source-synchronous input. The dqs_enable logic seems to be somehow related to synchronization of rdata_en, which is just tied high in my use case (AN756, Table 3):

enter image description here

It seems like maybe I just want strobe_in and ref_clk to both be driven by the external (source-synchronous) clock. But this fails to build, I think because they need to be separate pins.

So I'm totally stuck. I simply don't understand how to connect ref_clk and strobe_in. Any help would be very gratefully appreciated.

Answer 1

My company was somehow able to contact an engineer at Intel, who solved the problem immediately.

In summary:

1. The refclk and strb pins (two FPGA pins) must both be driven by the same external clock.
2. There is a bug in all versions of Quartus up to and including 21.4, which prevents the IO delay chains from being configured correctly. Therefore, the design will typically fail timing, even if everything has been configured correctly. As a workaround (until the bug is fixed in Quartus 22.1), the IO delay chains can be configured manually (see details below).

Here is the content of the (excellent) E-mail:

Quartus should automatically change the IO delay chain settings such that each IO is optimized for both setup and hold however there appears to be a problem with the automatic delay chain calculation algorithm in 21.3 which is why you are seeing lots of hold violations while your setup looks good.

I have checked in 21.4 and can confirm that the same issue exists in that version too. I can however confirm that this issue has been resolved in the latest internal release of 22.1 which is due for release very soon.

As a temporary solution (prior to the release of 22.1) you can manually set the IO delay chain values using the assignment below.

set_instance_assignment -name IO_12_LANE_INPUT_DATA_DELAY_CHAIN 60 -to InData

You can apply this to all InData pins (as in the assignment above) however to get the optimum solution you will need to apply different values on a per-pin basis which is also supported. I am looking at what specific settings are required to close timing and will update you in due course.

You can see the delay chain values used in the "Delay Chain Summary" section of the Route Stage report.

I tested the assignment above in 21.3 and the interface closed timing.

With regard to the refclk versus the strobe, ideally these should both originate from the same clock source such that they are PPM aligned. This will prevent the internal FIFO within the PHYLITE IP from overflowing/underflowing. The simplest solution is to connect the same clock on your board to both the strobe and refclk pins of the device.

We applied these changes in our project and it met timing. Correct behavior has been confirmed in simulation.

• gyuunyuu: Often when it comes to esoteric knowledge, getting in touch with an FAE is the only way forward.
• Harry: @gyuunyuu This is actually the only time I can recall an FAE being useful in the past ~15 years I have been working with FPGAs (from all the major vendors). Your mileage may vary, but I don't agree that contacting an FAE is typically a good way to move forwards.
• gyuunyuu: I have come across FAE that was just a salse guy, his technical knowledge seemed to be quite poor. He certainly knew about the clock speed and power dissipation figures e.t.c to sell device but that was about it. This was from Microsemi. I wish I could name him here, he kept called Libero SoC as Liberaero. Don't know what that was. But I have personally known Intel FAEs that were good and knew when to push things into the pipe to be handled by the "mother-ship" which is somewhere in the USA I believe where Altera headquarters exist where all the tools and silicon are designed.