Timing error on Arria 10 PCIe core design

Hi Sir,

Did you try this in the generated example design and get the same timing violation?

I have not done that, yet. I did a new compile today with pin location changes, and I get some improvement (worst-case negative slack is now ~800ps). But I also can now see some other timing violations, still in the PCIe/DMA core, but this time in a datapath:

-0.231

from node: qsys_design.synth_qys_inst.hchip_blob_inst|pcie_wrapper_inst|u0|pcie_a10_hip_0|pcie_a10_hip_0|g_avmm_256_dma.avmm_256_dma.altpcieav_256_app|hip_inf|rx_input_fifo|fifo_reg[0][24]

to node: qsys_design.synth_qys_inst.hchip_blob_inst|pcie_wrapper_inst|u0|pcie_a10_hip_0|pcie_a10_hip_0|g_avmm_256_dma.avmm_256_dma.altpcieav_256_app|hip_inf|rx_input_fifo|fifo_reg[7][210]

launch clock: qsys_design.synth_qys_inst.hchip_blob_inst|pcie_wrapper_inst|u0|pcie_a10_hip_0|pcie_a10_hip_0|wys~CORE_CLK_OUT

latch clock: qsys_design.synth_qys_inst.hchip_blob_inst|pcie_wrapper_inst|u0|pcie_a10_hip_0|pcie_a10_hip_0|wys~CORE_CLK_OUT

clock relationship: 4.000

This is more troubling, as it is a datapath. It is also a bit more puzzling, as it is probably a relatively low fanout path, so why shouldn't it make timing? And again, this is entirely within the PCIe macro, so I can't modify the code in any way.

I compile the arria 10 PCIe design and I don't see the timing issue. If the timing violation is come from the core, I should see the same from my design as well. Do you add any user logic to the reset of the IP core?

The timing errors are coming from the DMA portion of the core; the DMA is not hard IP, so place and route, and the resulting timing, are design-dependent. Just because it works for you does not mean it will work for me. Also, you may be using a different version of Quartus and a different operating system than I am using; unlike the old SR system, this ('The Community') lame excuse for customer service does not provide a mechanism to convey that information.

To answer your other question, I did register the reset output from the pcie core, which eliminated the errors in my user-generated code. But that does not solve the problems within the PCIe/DMA core.

I see the negative slack is more than 1ns (-1.119), it is unlikely due to place and route issue (usually place and route variation only give small timing difference). But looks like it is due to some extra constraint or routing that cause the issue.

So, may I know what is the Quartus version that you using? Maybe I should try in the quartus version and see if give worsen timing.

I am running QPP version 18.1.0 Build 222.

A few days ago I tried to partition and floorplan the design, but I was getting errors, including:

Error (14566): The Fitter cannot place 1 periphery component(s) due to conflicts with existing constraints (1 clock core fanout(s)). Fix the errors described in the submessages, and then rerun the Fitter.

It's not clear exactly where that error is occurring, but I did declare that reset signal from the PCIe core as a global. If I remove all of the Logic Lock regions, the error goes away. I will have to experiment a bit to find out which partition causes the problem when it is locked down.

I just did a build with some of the design floor-planned (but not the PCIe core), and the worst-case negative slack is now under 700ps. Here is a screenshot of chip planner; the bright green is the PCIe/DMA core.

That thing takes up a lot of space.

Hi Sir,

I compile PCIe example design in Arria10 using 18.1. The worst recovery slack that i get it 0.792. I think it is impossible the palce and routing cause the violation change from 792ps to -700ps.

What is the device speed grade (or OPN) that you use for your compilation?

Suggestion, can you duplicate a copy of your design to other directory. Remove other logic component as much as possible and remain PCIe IP, compile and see if you still get the same timing results.

OK, so I saved my design as an archive and created a new project from that. I stripped out everything except the PCIe code (w/ DMA) and a PLL, and added a module to sink/source all the Avalon interfaces from the core. This design makes timing with no trouble.

I built another project from that same archive. This time I left all of the IP and RTL in the project, and wiped the main .sdc file clean. I then put just the following into the .sdc file:

#**************************************************************

# Create Clock

#**************************************************************

create_clock -name {~ALTERA_CLKUSR~} -period 8.000 -waveform { 0.000 4.000 } [get_pins -compatibility_mode {~ALTERA_CLKUSR~~ibuf|o}]

create_clock -name {top_inst|emif|top_emif_0_ref_clock} -period 5.000 -waveform { 0.000 2.500 } [get_ports {emif_ref_clk}]

create_clock -name {pcie_refclk} -period 10.000 -waveform { 0.000 5.000 } [get_ports {pcie_refclk}]

create_clock -name {xcvr_refclk} -period 3.103 -waveform { 0.000 1.551 } [get_ports {xcvr_refclk}]

create_clock -name {oth_refclk} -period 8.000 -waveform { 0.000 4.000 } [get_ports {oth_refclk}]

create_clock -name {clk100} -period 10.000 -waveform { 0.000 5.000 } [get_ports {clk100}]

create_clock -name {clk100_1pps} -period 10.000 -waveform { 0.000 5.000 } [get_ports {clk100_1pps}]

create_clock -name {virt_clk_166} -period 6.000 -waveform { 0.000 3.000 }

create_clock -name {virt_clk_16} -period 59.608 -waveform { 0.000 29.803 }

#**************************************************************

# Derive PLL Clocks

#**************************************************************

derive_pll_clocks

#**************************************************************

# Derive Clock Uncertianty

#**************************************************************

derive_clock_uncertainty

I did this to rule out anything I had put in the .sdc that might be causing a problem. I got the same result as before (~ -700ps slack).

That mean is one of the SDC there causing the negative slack. Sorry, my suggestion is remove the SDC one by one and see which constraint cause the negative slack.