Timing constraints of Intel IPs

[anonimcs]

Hi all,

I have a design on Quartus 21.3 Pro and I noticed that the External Memory Interface IP for DDR4 memory has some timing violations within the IP core. I would expect that these kind of IP cores have their own timing constraints with their own .sdc files. But it seems that these constraints are not applied when I compiled my design. And I cannot find the generated .sdc file either. Do you know how I can generate that .sdc file and add it into the project by (not sure about this part) Assignments -> Settings -> Timing Analyzer -> ?

Thanks in advance

[sstrell]

What exact paths are failing?  Usually failures in the core for an EMIF would be due to connections to the user logic, not the IP itself which is usually hardened in the I/O (which target device?).

[anonimcs]

Hi,

The failing paths are included in the screenshot attached here. The target device is an Arria 10

[RichardTanSY_Intel]

The sdc is automatically generated when you "Generate HDL" for the EMIF IP. You can search the .sdc files in the Project Navigator.

Or go to Assignment > Setting > Timing Analyzer > SDC Files to include in the project.

Quartus should detect and list out all the sdc file in the project.

Seems to me the failing path is from EMIF IP to the other part of design. Could you scroll your mouse to the failing path, Right-Click on it, Locate Path (failing path) in the Technology Map Viewer to confirm this is true?

Regards,

Richard Tan

[anonimcs]

Hi,

In Assignment -> Setting -> Timing Analyzer I see the EMIF ip being added here (the .ip file), but not the generated .sdc file. I think (and hope) Quartus is detecting the generated .sdc and adding it here automatically, even though it doesn't show the generated .sdc files here.

For the failing path (I clicked on the one at the top in my previous screenshot), I do see the `tile_ctrl_inst` being highlighted in the Technology Map Viewer.

[RichardTanSY_Intel]

I don't understand your first paragraph. Does the Quartus able to detect the sdc file? If the sdc is detected and added to the project, then the sdc does get generated.

Do you Locate Path and Not Locate Node? Seem to be you Locate Node the From Node.

Please confirm.

Perhaps you could share your .qar design (Project > Archive Project) so that I can investigate it further.

Regards,

Richard Tan

[anonimcs]

Hi @RichardTanSY_Intel ,

This is what I meant by my first paragraph above. Please see the screenshot attached regarding the Timing Analyzer settings of the project. But it's my bad, when I expand the IP itself I can see the .sdc file added here.

This is the path analysis in the Technology viewer after I ran the command locate [get_timing_paths -npaths 10] -tmv on the tcl console of the Timing Analyzer.

For a Quartus archive, please send me an email with a link to upload the .qar file, the archive file is simply too large to add here.

[RichardTanSY_Intel]

Hi,

I have sent you an email with the steps to provide the project.

Regards,

Richard Tan

[anonimcs]

Hi @RichardTanSY_Intel ,

I uploaded the project archive with the username you provided. Looking forward to your feedbacks.

Thanks in advance

[anonimcs]

Hi @RichardTanSY_Intel ,

Any updates from your side ?

[RichardTanSY_Intel]

Hi,

It seems the failure path is from the peripheral to the core.

You can open QSYS interconnect and check whether it is feasible to add a pipeline to the timing failing path. Please see the example below, as shown in the attachment.

Regards,

Richard Tan

[anonimcs]

---

@RichardTanSY_Intel wrote:

Hi,

Please see the example below, as shown in the attachment.

---

Which attachment, and which example ?

And the failing path is from the IP to the interconnect, how am I supposed to add something inbetween ? It will end up with the same error as I'll connect the IP to another component in the Platform Designer for pipelining the failing signal...

[RichardTanSY_Intel]

I just uploaded the attachment. I can say the system is not perfect when uploading attachment or images. Took a bit of time in between.

[anonimcs]

I enabled all pipelines visible in "mm_interconnect_2" for both directions (Command and Response), and also tried optimizing the timing of the design by following these steps (https://www.intel.com/content/www/us/en/docs/programmable/683106/24-1-19-2-3/optimizing-timing.html) but the total slack of the failing paths are even worse than the ones in the screenshot I shared before. 

[RichardTanSY_Intel]

I think I have found what could be causing the problem.

It might be due to the location assignments in your design, causing it to be over-constrained with placement that's hard to meet timing.

Once I disabled all the location assignments in the assignment editor, the setup timing violation was resolved.

Could you please check and confirm this from your side ?

Regards,

Richard Tan

[anonimcs]

By location assignments did you mean the pin assignments ? I cannot change that as that would require a complete new PCB design..

[RichardTanSY_Intel]

nstead of enabling all pipelines in mm_interconnect_2 at once, could you try to incrementally increase the pipelines one by one to see if it improves?

Also, try using different Compiler Setting Optimization Modes to see if it gets better.

As the slack is getting <0.100, you might want to try running a seed sweep.

I am running different iterations with various settings to see if it can close the timing.

Regards,

Richard Tan

[anonimcs]

I have found a timing fix by tinkering around the Fitter settings, adding the lines below in my .qsf seems to fix timing issues. However, one should not need to try out every single setting out there, there must be another way of fixing the timing for the DDR4 EMIF IP. As you suggested, I already tried incrementing those one by one in addition to adding all of them at once, didn't help..

set_global_assignment -name OPTIMIZATION_MODE "SUPERIOR PERFORMANCE"
...<pin assignments inbetween>
set_global_assignment -name PLACEMENT_EFFORT_MULTIPLIER 2.0
set_global_assignment -name GLOBAL_PLACEMENT_EFFORT "MAXIMUM EFFORT"

[RichardTanSY_Intel]

I am glad to hear that you are able to close the timing.

With the location assignment being locked out, we are left with optimizing the compiler settings for better placement.

Since the issue has been resolved, can we consider this thread closed?

Regards,

Richard Tan

[anonimcs]

Although the timing is now met, I'm still not satisfied with the way I had to fix the timing violations of the Intel's IP. I would be happy if we can keep the Fitter settings in default (Balanced optimizing) and fix whatever timing violation in the logic itself.

[RichardTanSY_Intel]

As we have IP experts for the respective IPs, could you file a new case requesting the EMIF IP owner to review your IP?

They can check if there are any configuration settings that might help with the timing. Typically, the timing within the IP is already managed by the IP's SDC file.

Regards,

Richard Tan