Source synchronous interface clocks: "Asynchronous (Timed Unsafe)"

[Schroeti]

Hi.

I have a FPGA (Cyclone 10 GX, Quartus prime pro 20.4) design which is the sink of 2 independent source synchronous interfaces. The clock edges are center aligned to the data. One of the interfaces is working at single data rate, the other one at double data rate.

The constraints were made according to AN433. Therefore i have a virtual clock and an input clock each. The virtual clock corresponds to the data launch clock of the data source.
The input clock of the DDR-interface is generated by the sourcing device (Cyclone V, LVDS) with a phase offset of +90° (PLL).
For the SDR interface input clock the source (Max10, HSTL 1.8V) just outputs the inverted data clock.

Now my Problem:
These interfaces are not working reliable. Any of them may fail to work after the next compilation and that may be temperature dependent. For me this looks like a timing issue. But there are no timing errors. Instead the Timing Analyzer reports on clock transfers "Asynchronous (Timed Unsafe)" between the virtual clocks and the input clocks.
Is this bad or not? What can i do to fix those interfaces?

What i also noticed is the following. An earlier version of the PCB, which now uses the Cyclone 10, uses a Cyclone V (Quartus prime lite 18.1) and hasn't those interface failure issues. At least after intruducing exactly these timing constraints which i am also using in the Cyclone 10 project now.

Here are the timing constraints of the DDR interface:

set ddr_clock_period 6.667

create_clock -name {clk_ddr_virtual} -period $ddr_clock_period
create_clock -name {clk_ddr_input} -period $ddr_clock_period -waveform "[expr {0.25 * $ddr_clock_period}] [expr {0.75 * $ddr_clock_period}]" [get_ports {<clock input port>}]
set_clock_groups -asynchronous -group [get_clocks {clk_ddr_virtual clk_ddr_input}]

set ddr_inputs {<data input ports>}

set_input_delay -max 0.5 -clock [get_clocks clk_ddr_virtual] [get_ports ${ddr_inputs}]
set_input_delay -max 0.5 -clock [get_clocks clk_ddr_virtual] -clock_fall [get_ports ${ddr_inputs}] -add_delay
set_input_delay -min -0.5 -clock [get_clocks clk_ddr_virtual] [get_ports ${ddr_inputs}] -add_delay
set_input_delay -min -0.5 -clock [get_clocks clk_ddr_virtual] -clock_fall [get_ports ${ddr_inputs}] -add_delay

set_multicycle_path -hold -end -rise_from [get_clocks clk_ddr_virtual] -rise_to [get_clocks clk_ddr_input] 2
set_multicycle_path -hold -end -fall_from [get_clocks clk_ddr_virtual] -fall_to [get_clocks clk_ddr_input] 2
set_false_path -setup -rise_from [get_clocks clk_ddr_virtual] -rise_to [get_clocks clk_ddr_input]
set_false_path -setup -fall_from [get_clocks clk_ddr_virtual] -fall_to [get_clocks clk_ddr_input]
set_false_path -hold -fall_from [get_clocks clk_ddr_virtual] -rise_to [get_clocks clk_ddr_input]
set_false_path -hold -rise_from [get_clocks clk_ddr_virtual] -fall_to [get_clocks clk_ddr_input]

[Schroeti]

What I forgot to mention is that the interfaces always work when the over all logic usage of the design is relatively low.

[Ash_R_Intel]

Hi,

This case belongs to the timing closure area and need further investigation. Is it possible for you to create an Intel Premier Support case and provide the design? Team can then provide better assistance in resolving the issue. You may contact local sales representative to do so.

Regards.

[sstrell]

I'm not sure why you have this:

set_clock_groups -asynchronous -group [get_clocks {clk_ddr_virtual clk_ddr_input}]

It's not needed and may be what the tool is complaining about.

If this is a DDR input, why do you have the multicycle exceptions?  There's no situation where multicycle is needed on a DDR input.

And is this same edge or opposite edge transfer?  If it's same edge transfer, your false paths are incorrect.  With same edge transfer, you want to "cut" opposite edge analysis, so the setup false paths should be rise_from/fall_to and fall_from/rise_to and the hold false paths should be rise_from/rise_to and fall_from/fall_to.

[Schroeti]

@sstrell This is an opposite edge transfer. Therefore the constraints are written this way. At least from what I could gather from AN433. But this note is really confusing for me.

But i never understood, why the transmission works when the sender delays (not advances) the clock signal by 90 degrees.

[Ash_R_Intel]

Hi,

I feel you are not constraining both the interfaces. The AN 433 recommends to create virtual clock and the input clock for the same interface. Virtual clock to be used for input delay constraint whereas input clock to specify the other parameters. I think you are doing this for one interface only.

I am not seeing constraints for second interface. Once you define that, then you can define false paths between them, or alternatively set_max_delay will also do.

Regards.

[Schroeti]

Sorry for the late response. Unfortunately this is not my only task.

The constraints i showed are only for one of the interfaces since they are independent of each other. Only the error is similar. My intention is to fix one of them to get an idea of what is going wrong. Everything else follows from this.

[Ash_R_Intel]

Hi,

Sorry for the late response. As you are constraining both the interfaces as per the AN, please check the timing report for the critical path(s). It is possible that the issue may lay somewhere else in the design.

Regards.

[Schroeti]

Now I have a interesting problem on this: With a signal tap in the design applied to the avalon mm interface of the problematic module it works.
Programmed with the .sof the module works.
Programmed with the .jic it fails to work.

What could be the side effects of the signal tap in this case?

[Ash_R_Intel]

This thread will be transitioned to community support. If you have a new question, feel free to open a new thread to get the support from Intel experts. Otherwise, the community users will continue to help you on this thread. Thank you