Using a different mem_ref_clk on an EMIF IP than the recommended

[Gsus]

Hi ,

We are doing a relatively complex design on which we are running into timing issues in the emif_usr_clk clock domain. We really need to get the functionality of the design sorted out so we were thinking about feeding a slower reference clock to the EMIF IP instead of the recommended value. The memory is an external DDR4 component device running at a nominal clock speed of 800 MHz. Our design uses an external 125 MHz oscillator as a reference clock, which is fed into a PLL which in turn generates the desired 200MHz reference clock for the EMIF IP. This clock is routed to an external pin and then routed back into the FPGA through the dedicated mem_ref_clk pin. We can easily play with this memory reference clock this way and we have tested that feeding a 150MHz clock into the mem_ref_clk input (while the EMIF IP is configured for a 200MHz reference clock) locks the EMIF PLL and memory write and read operations are successful (only for single word transactions, haven't tested bursts). So, the question would be, how reliable is the operation of the EMIF, or its PLLs, for slower than configured reference clocks?

[NurAida_A_Intel]

Hi Gsus,

It is recommended to use the fastest possible PLL reference clock frequency because it leads to better jitter performance. Selecting a slower frequency will impact performance. Hence, we recommended user to use the default value by check the "Use recommended PLL reference clock frequency" option.

Thanks

Regards,

NAli1

[HBhat2]

Hi GSuS,

I understand that in the EMIF IP you have set to 200MHz reference clock (listed in the IP), but actually the FPGA pin is getting 150MHz reference clock which is not listed in the list of possible reference frequencies.

In my view, It would not generate 800MHz memory clock with 150MHz. The reason being, when you select 200MHz as the input reference clock, the IP configures all the PLLs inside EMIF IP such that it assumes 200MHz input clock and does the required calculation of M & N (multiplication and division) values so that it will output 800MHz memory clock and 200MHz user clock (quarter/full rate controller). These values are static for one FPGA binary. When you feed 150MHz instead of 200MHz, the PLL blocks multiply and divide the reference clock with the previously set M & N values.

Simple example, we need to multiply by 4 to get 800MHz from 200MHz. Now if input frequency is 150MHz, then 150*4 = 600MHz. So, the design may work for some time with feeding the clock other than set clock in the EMIF IP, but it is not guaranteed to work continuously or provide the required performance/bandwidth.

With Regards,

HPB

[Gsus]

Thanks for your replies,

1. We are aware that using the recommended frequency yields the best jitter performance and bandwidth. That's the frequency we will eventually use once we get our failing paths solved.

2. We are feeding a 150MHz clock into a PLL that expects 200MHz, so we are as well expecting a slower memory clock (600MHz). This will of course deprecate the performance of our design, but that's a downside we can work with at this point in the project if that gets us a user clock in which we can have some timing certainty (Quarter usr clock configuration: 600MHz/4 = 150MHz).

3. Yes, 150MHz is not on the selectable frequencies list for an 800MHz memory clock. If we configured the PLL frequency for 100MHz (which is the immediate lower value selectable after 200MHz), the memory clock would be 800MHz and the user clock 800MHz/4 = 200MHz, which defeats our purpose of having a slower user clock. 

So far we have been able to test reference clock inputs as low as 100MHz (for a 200MHz configured EMIF) and ran memory tests for a couple of hours without issues. We wanted to know if any analog engineer with knowledge on the inner workings of the EMIF PLLs had any concern since there might be RC circuitry that could be affected by the significative difference in reference clock frequencies.

Thanks

Gsus

[NurAida_A_Intel]

Hi Sir,

The EMIF IP is validated on our board with osc that direct supply EMIF IP PLL_REF_CLK pin. The connection that you did is similar to PLL cascading within the FPGA. And if you make the cascading,

the IP rules checker will give you a fitter error. However, your case, the tools unable to detect it because you supply the clock to a IOPLL of the FPGA, the you route the clock out from FPGA and back to the PLL_REF_CLK pin of the EMIF IP. But the connection scheme is similar with the PLL cascade within the FPGA and it is even worse because routing out the clock outside the FPGA will affected by external noise. This connection definitely will create more jitter and timing issue is expected. In conclusion, I would say the connection is invalid. And if you want to characterize further, you can measure the jitter of the clock that you route back to FPGA from pll output pin. Compare it with the clock from oscillator.

Hope this helps.

Thanks

Regards,

NAli1