Stratix 10 : Critical Warning: DDR Timing requirements not met

[Renardo18]

I have two DDR4 ('DDR A' and 'DDR B') in my project, and I am using two DDR4 EMIF controller for Stratix 10.

My problem is the 2 of them don't meet timing, the compilation report gives this kind of messages for both of them (setup and hold timing values change between them).

Info: Core: emif_fpga_b_emif_s10_0_altera_emif_arch_nd_191_y322eui - Instance: memory_ddr4x72_wrapper_b|u1|emif_s10_0|emif_s10_0

Info: setup hold
Info: Address/Command (Fast 900mV 0C Model) | 0.176 0.176

Info: Core (Fast 900mV 0C Model) | 0.762 -5.928

Info: Core Recovery/Removal (Fast 900mV 0C Model) | 0.827 1.703

Info: DQS Gating (Fast 900mV 0C Model) | 0.53 0.53

Info: Read Capture (Fast 900mV 0C Model) | 0.036 0.036

Info: Write (Fast 900mV 0C Model) | 0.058 0.058

Info: Write Levelling (Fast 900mV 0C Model) | 0.141 0.141

Critical Warning: DDR Timing requirements not met

1st question : How can I solve that?

My other problem is that when I run timing analyzer GUI I have 29 failing path only in DDR A. They are all from : {memory_ddr4x72_wrapper_a|u0|emif_s10_0|emif_s10_0|ecc_core|core|ecc|internal_master_wr_data[xxx]}

and -to :{memory_ddr4x72_wrapper_a|u0|emif_s10_0|emif_s10_0|arch|arch_inst|io_tiles_wrap_inst|io_tiles_inst|tile_gen[xxx].lane_gen[xxx].lane_inst|lane_inst~phy_reg1}

With different values of xxx.

Why do I see failing path only in DDRA and not in the 2 DDRs when I report timing ?

Does anyone have a solution? How can I do to meet timing within the EMIF IP Core? Are the timing related to the board and package skews settings that I define in the IP ?

Please note that I have already posted this message, but it has been closed because I haven't replied fast enough.

An intel employee told me to run the following command :

if {![is_post_route]} {
set_min_delay -from [get_keepers "memory_ddr4x72_wrapper_a\|u0\|emif_s10_0\|emif_s10_0\|ecc_core\|core\|ecc\|internal_master_wr_data\[*\]*"] -to {memory_ddr4x72_wrapper_a|u0|emif_s10_0|emif_s10_0|arch|arch_inst|io_tiles_wrap_inst|io_tiles_inst|tile_gen[*].lane_gen[*].lane_inst|lane_inst~phy_reg1} 4.114
}

The path with the worst negative slack of my paths had a Data Delay of 3.74. I then added 10% to this value as you told me : 3.74*1.1 = 4.114

But this made it worse, I went from 48 failing path to more than 500 ones..

[AdzimZM_Intel]

Hi Renardo18,

I have sent an email to you.

Please take a look.

Regards,

Adzim

[Renardo18]

Here are the parameters (and the failing paths) for DDR A, the one that is failing timing.

Here are the parameters for DDRA

[Renardo18]

Here are the parameters for DDR B (the one that MEETS timing):

[AdzimZM_Intel]

Thank you for sharing!

I will take a look on the IP setting while waiting for the small design.

Regards,

Adzim

[Renardo18]

Hi,

I have the smaller design but I can't join it here (it is too heavy = 1.8Gb).

How can I send it to you?

Thanks

[Renardo18]

Hi,

I uploaded the design on GOOGLE DRIVE, please let me know if you can access it :

https://drive.google.com/file/d/1FbZXZv0ehWfqtJIM4aJgh710teFFBgaF/view?usp=sharing

Regards

[AdzimZM_Intel]

Hello,

Please allow us some times to debug on this project.

We will provide the update to you later.

Regards,

Adzim

[AdzimZM_Intel]

Hello,

I have checked the design and run the Fast Forward Timing Closure Recommendation.

You have to add pipeline or register to the paths that has been recommended in the report.

Regards,

Adzim

[AdzimZM_Intel]

Here the report.

[Renardo18]

Hi Adzim, 

Can you confirm that you have add the pipelines registers and it has solved the timing violations in the DDR controller ? Because I don't see why adding pipeline between a register controller and the 40G ethernet IP would solve timing in the DDR controller?

2 months ago, in a previous message posted on intel community forum, the first thing you told me was to run FAST-FORWARD compilation, and I have added several recommandations and done many design changes to be compliant with the report, and it didn't change anything.

Also please note that I am on vacation until July 21st. Would it be possible not to close this topic until then?

Also please confirm that applying these pipelines on the reset of the 40G ethernet IP will solve timing in the DDR controller (I have serious doubts about it)?

Thanks

[AdzimZM_Intel]

Hello Renardo18,

The timing issue has occurred at the core transfer path.

Then the timing closure issue is between the EMIF IP and other design block.

You can remove other IP in the design and just have both EMIF IPs in your design.

Try to compile the design and check if there is any timing violation.

Don't use IOPLL as the reference clock to the EMIF IP.

21st July is about 2 weeks and it's too long.

I need to close it first.

Then you can file another thread for requesting on timing closure recommendation.

Regards,

Adzim

[Renardo18]

Hi Adzim,

You said : " Then the timing closure issue is between the EMIF IP and other design block.". How do you know that?

From what I see, the timing closure issue is between :{memory_ddr4x72_wrapper_a|u0|emif_s10_0|emif_s10_0|ecc_core|core|ecc|internal_master_wr_data[xxx]}

and :{memory_ddr4x72_wrapper_a|u0|emif_s10_0|emif_s10_0|arch|arch_inst|io_tiles_wrap_inst|io_tiles_inst|tile_gen[xxx].lane_gen[xxx].lane_inst|lane_inst~phy_reg1}

So between emif_core|ECC|internal_master_wr_data AND emif_core|tile|lane|phy

So not between the core and another design block?

I have added the pipeline asked in the report.

I am relaunching the build.