Problem with EMIF IP and the related clocks in the .sdc file

[MSenk1]

I have instantiated a EMIF IP in Quartus 19.4.

Alle emif clock are generated as the timing analyser shows (see attachment.

But when I set a false path in the .sdc file for such a clock I get the following error messages.

Reading SDC File: 'DP/rtl/example.sdc'

Clock uncertainty is not calculated until you update the timing netlist.

Ignored filter at example.sdc(88): main_top_1|fra_0|dram_0|emif_c10_0_core_usr_clk could not be matched with a clock or keeper or register or port or pin or cell or partition

Ignored set_false_path at example.sdc(88): Argument <from> is not an object ID

Ignored filter at example.sdc(89): main_top_1|fra_0|dram_0|emif_c10_0_wf_clk_0 could not be matched with a clock or keeper or register or port or pin or cell or partition

Ignored set_false_path at example.sdc(89): Argument <from> is not an object ID.

In all other IPs (like HDMI etc.) this works fine.

Why not in this IP.

Regards

Mike

[sstrell]

Which Cyclone 10 are you using, GX or a different variant and are you using Quartus Standard or Pro? And what is your goal for the false path? What are you trying to do?

I'm not sure why you would want to false path a clock path, but if it's a hardened path (hence my device question), it wouldn't be able to be cut.

#iwork4intel

[BoonT_Intel]

Hello,

Yes, first thing is we don't recommend to set the IP path to false path.

Second thing is EMIF is hard IP unlikely other soft IP like HDMI/DP, thus it might unable to set to false path.

[MSenk1]

Hello,

I'm using a Cyclone 10 GX with Quartus Pro.

The clock I'm talking about is the 'usr_clk'; which is connected to the Avalon MM slave side , not to the dram hardware side.

The 'usr_clk' is connected to one side of an asynchronous FIFO. The other side of the FIFO is connected to another clock. There are a few signal like aclr and rdreq of the FIFO which have clock crossing signals.

I have to set false paths or asynchronous clock groups in order to get a reasonable timing.

How could I achieve this?

Do you have any idea?

Mike

[sstrell]

As you state, you should use asynchronous clock groups. This cuts the paths between the clock domains, through the FIFO, not the clock paths themselves:

set_clock_groups -asynchronous -group usr_clk -group <clock on other side of FIFO>

#iwork4intel

[BoonT_Intel]

Thanks. @sstrell​ 

[MSenk1]

Thank you, I was able to solve my issue, knowing that one of the clocks is a hardened path.