Forum Discussion

ScottHu2021's avatar
ScottHu2021
Icon for New Contributor rankNew Contributor
4 years ago

Instantiation of DDR3 SDRAM Controller with UniPHY intel FPGA IP

Dear,

We are develop an application with FPGA 5CEFA5F23C8 based on Quartus Prime Standard 18.1. One problem occurred during instantiating DDR3 controller IP core:

Our external memory is a DDR3 with clock frequency 300M. In the system design, we have an PLL with 25M input clock which derives a 100M clock.

The "PHY settings" of the DDR3 controller instantiation is as following:

1. Memory clock frequency: 300M;

2. PLL reference clock frequency: 100M;

And in the top entity, we create an instance of DDR3 controller as following:

ddrc ddrc_u
(
.pll_ref_clk ( clk _100M),
.global_reset_n ( pll_lock ),
.soft_reset_n ( pll_ddr_lock ),
.afi_clk ( afi_clk ),
.afi_half_clk ( ),
afi_reset_n ( afi_reset_n ),

...

}

we find that the DDR reading/writing can not work. But with the following change:

change the DDR3 controller's PLL reference clock from 100M to 25M.

The DDR reading/writing will work well.

So, what's the problem? Can not the PLL reference clock of the DDR controller be a PLL derived clock? Another question is: Is there a minimum limit of the PLL reference clock frequency for the memory driven by a clock with a specified frequency?

Thanks!

Scott

15 Replies

  • ScottHu2021's avatar
    ScottHu2021
    Icon for New Contributor rankNew Contributor

    Hi Adzim,

    Sorry for late reply. Because I can not reply your pose until now.

    Currently, we have re-designed the hardware, and add a 50M oscillator and assign its' output to one pin of DQ I/O bank. Unfortunately, the DDR3 still can not work with 300M frequency. Through the "cheating method" described above, the DDR can work at 150M Hz.

    The timing report of DDR controller is as following:

    Initializing DDR database for CORE ddrc_p0
    Finding port-to-pin mapping for CORE: ddrc_p0 INSTANCE: ddrc_u|ddrc_inst
    Report Timing: Found 10 setup paths (0 violated). Worst case slack is 1.461
    Report Timing: Found 10 hold paths (0 violated). Worst case slack is 0.303
    Report Timing: Found 10 recovery paths (0 violated). Worst case slack is 11.060
    Report Timing: Found 10 removal paths (0 violated). Worst case slack is 0.834
    Core: ddrc_p0 - Instance: ddrc_u|ddrc_inst
    setup hold
    Address Command (Slow 1100mV 85C Model) | 0.975 0.968
    Bus Turnaround Time (Slow 1100mV 85C Model) | 5.512 --
    Core (Slow 1100mV 85C Model) | 1.461 0.303
    Core Recovery/Removal (Slow 1100mV 85C Model) | 11.06 0.834
    DQS vs CK (Slow 1100mV 85C Model) | 0.45 0.562
    Postamble (Slow 1100mV 85C Model) | 0.817 0.817
    Read Capture (Slow 1100mV 85C Model) | 0.315 0.268
    Write (Slow 1100mV 85C Model) | 0.366 0.366

    BTW, in the "report top failing paths", there are some setup slack violations of NIOS address and data bus ( in our design, there is a NIOS implemented ), I am not sure if these timing violations will affect the DDR operation.

    Regards,

    Scott