Instantiation of DDR3 SDRAM Controller with UniPHY intel FPGA IP

[ScottHu2021]

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

[AdzimZM_Intel]

Hi Scott,

How your PLL ref clock going to drive clock of 100M when the input is 25M?

I think the limitation is depends on the device but I don't know the exact number of it.

Regards,

Adzim

[ScottHu2021]

Hi Adzim,

one question:

Must the PLL reference clock  be from an external clock input (i.e. an oscillator output)  and the clock pin must be placed in the same I/O bank as the uniphy's ? （refer to the "External Memory Interface Handbook Volume 3 /Section III. DDR2 and DDR3 SDRAM Controller with UniPHY User Guide:  If the PLL input reference clock pin does not have the same I/O standard as the memory interface I/Os, a no-fit might occur because incompatible I/O standards cannot be placed in the same I/O bank.)

Scott

[ScottHu2021]

Hi Adzim,

Currently,  only the following configuration can make DDR3 reading/writing work:

1. Set the "PLL reference clock frequency" in the "PHY Settings" to 100M (actually, I think it should be 25M);  The 100M clock is the system clock derived by a PLL;

2. But while instantiating the DDR controller， we connect the clk_25m  to the .pll_ref_clk as following.

ddrc ddrc_u
(
.pll_ref_clk ( clk_25m),
.global_reset_n ( pll_lock ),
.soft_reset_n ( pll_ddr_lock ),
.afi_clk ( afi_clk ),
.afi_half_clk ( ),
.afi_reset_n ( afi_reset_n ),
.afi_reset_export_n ( afi_reset_export_n ),
.mem_a ( mem_a ),
.mem_ba ( mem_ba ),
.mem_ck ( mem_ck ),
.mem_ck_n ( mem_ck_n ),
.mem_cke ( mem_cke ),
.mem_cs_n ( mem_cs_n ),
.mem_dm ( mem_dm ),
.mem_ras_n ( mem_ras_n ),
.mem_cas_n ( mem_cas_n ),
.mem_we_n ( mem_we_n ),
.mem_reset_n ( mem_reset_n ),
.mem_dq ( mem_dq ),
.mem_dqs ( mem_dqs ),
.mem_dqs_n ( mem_dqs_n ),
.mem_odt ( mem_odt ),
.avl_ready_0 ( w_adc_avl_rdy ),
.avl_burstbegin_0 ( w_adc_avl_bb ),
.avl_addr_0 ( w_adc_avl_addr ),
.avl_rdata_valid_0 ( ),
.avl_rdata_0 ( ),
.avl_wdata_0 ( w_adc_avl_data ),
.avl_read_req_0 ( 1'b0 ),
.avl_write_req_0 ( w_adc_avl_wr ),
.avl_size_0 ( 1'b1 ),
.avl_be_0 ( 4'hF ),
.avl_ready_1 ( w_gpif_avl_rdy ),
.avl_burstbegin_1 ( w_gpif_avl_bb ),
.avl_addr_1 ( w_gpif_avl_addr ),
.avl_rdata_valid_1 ( w_gpif_avl_rvld ),
.avl_rdata_1 ( w_gpif_avl_data ),
.avl_wdata_1 ( ),
.avl_read_req_1 ( w_gpif_avl_rd ),
.avl_write_req_1 ( 1'b0 ),
.avl_size_1 ( 1'b1 ),
.avl_be_1 ( 4'hF ),
.mp_cmd_clk_0_clk ( clk_100m ),
.mp_cmd_reset_n_0_reset_n ( pll_lock ),
.mp_cmd_clk_1_clk ( clk_100m ),
.mp_cmd_reset_n_1_reset_n ( pll_lock ),
.mp_rfifo_clk_0_clk ( clk_100m ),
.mp_rfifo_reset_n_0_reset_n ( pll_lock ),
.mp_wfifo_clk_0_clk ( clk_100m ),
.mp_wfifo_reset_n_0_reset_n ( pll_lock ),
.local_init_done ( local_init_done ),
.local_cal_success ( local_cal_success ),
.local_cal_fail ( local_cal_fail ),
.oct_rzqin ( oct_rzqin ),
.pll_mem_clk ( ),
.pll_write_clk ( ),
.pll_locked ( pll_ddr_lock ),
.pll_write_clk_pre_phy_clk ( ),
.pll_addr_cmd_clk ( ),
.pll_avl_clk ( ),
.pll_config_clk ( ),
.pll_mem_phy_clk ( ),
.afi_phy_clk ( ),
.pll_avl_phy_clk ( )
);

clk_25m is the output of the entity ALTCLKCTRL, because in our hardware design, the 25M clock (from external oscillator ) input pin is not placed in the the address/command bank of DDR3 controller,  so I use the ALTCLKCTRL' output (its input is the external 25M clock) as the pll_ref_clk of the DDR3 controller:

25M clock  from external oscillator => Clock Control Block => DDR controller PLL reference clock.

With this configuration, DDR3 can work. 

But the problem is that:  if 25M clock is used as the PLL reference clock of DDR3 controller, the "PLL reference clock frequency" in the "PHY Settings" should be set to 25M but not 100M.

Another question is that the usage of "25M clock  from external oscillator => Clock Control Block => DDR controller PLL reference clock." is correct or not.

Any suggestion is appreciated!

Scott

[AdzimZM_Intel]

Hi Scott,

How about the board connection?

Are you using the right clock?

Is there any timing issue from the Quartus compilation?

Have you used the 25M setting in the PLL ref clock frequency?

[ScottHu2021]

Hi AdzimZM,

How about the board connection?

=>Sorry,  what board connection you mean? BTW, the FPGA used is 5CEFA5F23C8.

Are you using the right clock?

=> In the design, we only have one 25M clock input from external oscillator (the pin assigned is not located the same I/O bank as the uniphy's).       And then through a clock control block,   the clock is provided to the DDR3 interface input  ( pll_ref_clk, as shown above) and to a PLL which       derives a 100M clock to drive the other logics.

Is there any timing issue from the Quartus compilation?

=> Yes, only some timing violation issues.  

Have you used the 25M setting in the PLL ref clock frequency?

=> If we  set the PLL ref clock frequency of the DDR3 controller to 25M, the DDR3 reading/writing can not work.  But with 100M setting, the                DDR3 works well and also the other logics.  The clock summary reported by the Timing Analyzer is as following:

altera_reserved_tck Base 33.333 30.0 MHz 0.000 16.666
clk Generated 10.000 100.0 MHz 0.000 5.000   ==> clk is the output from clock control block, it should be 25M.
clk_in_25M Base 10.000 100.0 MHz 0.000 5.000  ==> input clock from external osicalltor
ddrc_u|ddrc_inst|ddrc_p0_sampling_clock Generated 3.333 300.03 MHz 0.000 1.666
ddrc_u|ddrc_inst|pll0|pll_afi_clk Generated 3.333 300.03 MHz 0.000 1.666
ddrc_u|ddrc_inst|pll0|pll_avl_clk Generated 16.666 60.0 MHz 0.416 8.749
ddrc_u|ddrc_inst|pll0|pll_avl_phy_clk Generated 16.666 60.0 MHz 0.416 8.749
ddrc_u|ddrc_inst|pll0|pll_config_clk Generated 50.000 20.0 MHz 0.000 25.000
ddrc_u|ddrc_inst|pll0|pll_dq_write_clk Generated 3.333 300.03 MHz 2.499 4.165
gpif_clk Base 20.000 50.0 MHz 0.000 10.000
mem_ck[0] Generated 3.333 300.03 MHz 0.000 1.666
mem_ck_n[0] Generated 3.333 300.03 MHz 1.666 3.333
mem_dqs[0]_IN Base 3.333 300.03 MHz 0.000 1.667
mem_dqs[0]_OUT Generated 3.333 300.03 MHz 0.000 1.666
mem_dqs[1]_IN Base 3.333 300.03 MHz 0.000 1.667
mem_dqs[1]_OUT Generated 3.333 300.03 MHz 0.000 1.666
mem_dqs_n[0]_OUT Generated 3.333 300.03 MHz 0.000 1.666
mem_dqs_n[1]_OUT Generated 3.333 300.03 MHz 0.000 1.666

From the reporting,  we can see the frequency of the clock "clk" and "clk_in_25M" is not correct.  

We defines the base clock and the generated clock in .sdc file as following:

#**************************************************************
# Create Clock
#**************************************************************

create_clock -name {altera_reserved_tck} -period 33.333 -waveform { 0.000 16.666 } [get_ports {altera_reserved_tck}]
create_clock -name {clk_in_25M} -period 40 [get_ports {clk_in_25M}]
create_clock -name {gpif_clk} -period 20.000 -waveform { 0.000 10.000 } [get_ports {gpif_pclk}]
create_generated_clock -name clk -source [get_ports {clk_in_25M}] [get_pins {clkin_u|altclkctrl_0|clkin_altclkctrl_0_sub_component|sd1|outclk}]
create_generated_clock -name clk_100m -source [get_pins {clkin_u|altclkctrl_0|clkin_altclkctrl_0_sub_component|sd1|inclk}] -multiply_by 4 [get_pins {clkin_u|altclkctrl_0|clkin_altclkctrl_0_sub_component|sd1|outclk}]
set_clock_groups -logically_exclusive -group [get_clocks {clk_in_25M}] -group [get_clocks {gpif_clk}]

I am not sure if the PLL reference clock must be an external clock input?  or can be another DLL output or the output of the clock control block?

Thanks a lot!

[AdzimZM_Intel]

Hi Scott,

Every PLL can cover some area of the I/O interfaces.

I think the DDR3 interface can be support at the right side of the Cyclone V device.

So that you need to use the PLL at that area.

But the Quartus can already set for you where by you can see which PLL has been used in the Quartus Compilation Report.

Usually the clock pin is placed in the Address and Command I/O bank.

The clock should be from the Oscillator as you mentioned.

May I see the timing report for DDR?

Thanks,

Adzim

[ScottHu2021]

Hi Adzim,

In our design, the clock input pin is not placed in the same I/O bank as DDR interface's, and it is used as the PLL reference clock of the DDR3 controller through a clock control block.

• With the PLL reference clock frequency setting of 100M, the DDR3 can work, and the DDR timing report is as following:

report_ddr -panel_name "DDR" -multi_corner
Initializing DDR database for CORE ddrc_p0
Finding port-to-pin mapping for CORE: ddrc_p0 INSTANCE: ddrc_u|ddrc_inst
PLL clock ddrc_u|ddrc_inst|pll0|pll1~PLL_OUTPUT_COUNTER|divclk not driven by a dedicated clock pin or neighboring PLL source. To ensure minimum jitter on memory interface clock outputs, the PLL clock source should be a dedicated PLL input clock pin or an output of the neighboring PLL. Timing analyses may not be valid.
Report Timing: Found 10 setup paths (0 violated). Worst case slack is 0.048
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.589
Report Timing: Found 10 removal paths (0 violated). Worst case slack is 0.965
Core: ddrc_p0 - Instance: ddrc_u|ddrc_inst
setup hold
Address Command (Slow 1100mV 85C Model) | -0.186 1.878
Bus Turnaround Time (Slow 1100mV 85C Model) | 4.322 --
Core (Slow 1100mV 85C Model) | 0.048 0.303
Core Recovery/Removal (Slow 1100mV 85C Model) | 11.589 0.965
DQS vs CK (Slow 1100mV 85C Model) | 0.44 0.552
Postamble (Slow 1100mV 85C Model) | 0.817 0.817
Read Capture (Slow 1100mV 85C Model) | 0.307 0.26
Write (Slow 1100mV 85C Model) | 0.633 0.639
DDR Timing requirements not met

• With the PLL reference clock frequency setting of 25M, the DDR3 writing/reading failed, and the DDR timing report is as following:

report_ddr -panel_name "DDR" -multi_corner
Initializing DDR database for CORE ddrc_p0
Finding port-to-pin mapping for CORE: ddrc_p0 INSTANCE: ddrc_u|ddrc_inst
PLL clock ddrc_u|ddrc_inst|pll0|pll1~PLL_OUTPUT_COUNTER|divclk not driven by a dedicated clock pin or neighboring PLL source. To ensure minimum jitter on memory interface clock outputs, the PLL clock source should be a dedicated PLL input clock pin or an output of the neighboring PLL. Timing analyses may not be valid.
Report Timing: Found 10 setup paths (0 violated). Worst case slack is 1.949

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.631
Report Timing: Found 10 removal paths (0 violated). Worst case slack is 0.838
Core: ddrc_p0 - Instance: ddrc_u|ddrc_inst
setup hold
Address Command (Slow 1100mV 85C Model) | 0.955 0.948
Bus Turnaround Time (Slow 1100mV 85C Model) | 4.322 --
Core (Slow 1100mV 85C Model) | 1.949 0.303
Core Recovery/Removal (Slow 1100mV 85C Model) | 11.631 0.838
DQS vs CK (Slow 1100mV 85C Model) | 0.44 0.552
Postamble (Slow 1100mV 85C Model) | 0.817 0.817
Read Capture (Slow 1100mV 85C Model) | 0.307 0.26
Write (Slow 1100mV 85C Model) | 0.633 0.639

Thanks,

Scott

[AdzimZM_Intel]

Hi Scott,

Would you able to place the clock in the same I/O bank?

I can see that there is timing violation in 100M setting but not in 25M setting.

I wondering if both settings are passing calibration?

Please let me know.

Thanks,

Adzim

[ScottHu2021]

Hi Adzim,

I try to use "External Memory Interface Toolkit" to generate the reports,  but there is always an error:

Error occurred while running the System Console command design_link {/designs/ddrc_example.sof} {/devices/5CE(BA5|FA5)@1#USB-1}. System Console returned the result java.util.concurrent.ExecutionException: java.lang.Exception: design_link: Device /devices/5CE(BA5|FA5)@1#USB-1 is not compatible with design /designs/ddrc_example.sof (Design is for 5CGXFC7C7F23C8 but device ID is 02B220DD=5CEBA5/5CEFA5)
invoked from within
"design_link /designs/ddrc_example.sof /devices/5CE(BA5|FA5)@1#USB-1 "
invoked from within
"interp eval $slave {
design_link /designs/ddrc_example.sof /devices/5CE(BA5|FA5)@1#USB-1

}". You must shutdown the toolkit and restart.

I try to reduce JTAG frequency to 6MHz but nothing helped.

With the PLL reference clock frequency setting of 100M, I used oscilloscope to measure the frequency of memory interface clock "MEM_CK" and find the clock is 75M . It seems reasonable,  because in our DDR controller configuration,  memory clock frequency is : 300MHz,  PLL reference clock frequency is 100MHz, rate on avalon_mm interface: full. If the PLL reference clock is given an 25M external clock, the MEM_CK should be 75M (25M * 3 ?)). Isn't it?

Regards,

Scott 

[AdzimZM_Intel]

Hi Scott,

I think that the EMIF Debug Toolkit had a conflict with the design file whereby the targeting device is not compatible.

Maybe you should verify the link file is corrects for the device.

With the PLL reference clock frequency setting of 100M, I used oscilloscope to measure the frequency of memory interface clock "MEM_CK" and find the clock is 75M . It seems reasonable, because in our DDR controller configuration, memory clock frequency is : 300MHz, PLL reference clock frequency is 100MHz, rate on avalon_mm interface: full. If the PLL reference clock is given an 25M external clock, the MEM_CK should be 75M (25M * 3 ?)). Isn't it?

Yes, I think so.

Regards,

Adzim

[ScottHu2021]

Hi Adzim,

I think we may find the root cause, that is the DDR timing constraint can not meet because the PHY's  PLL reference clock pin is not the same I/O bank as the PHY's. 

We try to use another DLL to derive a 50M clock with the 25M clock input, and then use the 50M derived clock to drive the DDR controller with the DDR's PLL refence clock frequency setting of 100M, the DDR reading/writing has no problem.  We observed that the MEM_CK is 150M which is our expectation (that means the wrong clock frequency configuration cheats the DDR3 controller generator).

So, the testing result shows that DDR can not run with 300M frequency if the PLL reference clock input pin is not located at the I/O bank as PHY's. But we are not sure that if the conclusion is correct or not. Would you like to help us to confirm this? If so, we will change the 25M clock input pin location.

Thanks!

Scott

[AdzimZM_Intel]

Hi Scott,

I'm not sure if you receive my latest feedback or not.

But I will post it again.

Sorry for any inconvenience.

The PLL reference clock may be assigned in the Address/Command I/O bank or in DQ I/O bank.

But for debugging flexibility, users are recommend to assign it in the Address/Command I/O bank.

Regards,

Adzim

[AdzimZM_Intel]

Hi Scott,

Do you have any update on this topic?

Thanks,

Adzim

[ScottHu2021]

Hi Adzim,

we also monitored the signal "local_cal_success" exported from the controller interface which together with the "local_init_done" are high after power-on.  So, the calibration and initialization process should succeeded.

Regards,

Scott

[ScottHu2021]

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