Clock pessimism removal

[ChristophD]

I need to time constrain a source-synchronous interface between a Cyclone10GX and a LVDS camera interface running at  ~596MBPS.  (I'm using Quartus prime pro 19.3)

The FPGA drives out a 124MHz clk (generated by a PLL inside the FPGA) that is recovered and multiplied by 4 in the Camera by a PLL. The camera sends back 4:1 serialized data on 80 LVDS lines and a synchronous 124MHz clock. This clock is recovered in the FPGA by a PLL and serves to deserialize the input. Finally I managed to define generated clocks to describe the situation. But in the Timing analysis, the pessimism for the common clock path to the Camera PLL output is not removed, though exactly the same path is mentioned in the "Data arrival" and the "Data required" clock section (input of the base clock on Pin W24 to output of the Camera drive clock on Pin E22). 

Without this common path pesimism removal the timing cannot be closed as the  differences between fast and slow model over the whole path with input/PLL/output are ~2ns.

What can I do to get this pessimism removed?

[SyafieqS]

Hi Dietz,

You may refer to link below related to Design Guidelines for Implementing LVDS Interfaces in Cyclone Series Devices and Timing Pessimism

1. https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/an/an479.pdf

2. https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/ug/ug-qpp-timing-analyzer.pdf - pg 15

[ChristophD]

Hi SyafieqS_Intel,

I know these documents and the second describes what the timing pessimism (common clock path pessimism) is and that it is removed during timing analysis. Usually there is a line in the timing analyzer report (and in the Timing analyzer GUI) that shows the removed timing pessimism. But not in this case, though both signals share most of the clock path (cf. attached file "NoPessimismRemoval.txt") . What's wrong?

Best regards

Christoph Dietz

[SyafieqS]

Chris,

Can you share the design file that suppose to show the removed timing pessimism?

Attached the qar here.

[ChristophD]

SyafieqS,

I prepared a minimal design showing the phenomenon. The topology is still as mentioned in my first post, however, I reduced the number of data lanes to 2 and removed all signal treatment and control.

You should especially look at the setup and hold timing of the "from: i_slv2_ser4*" data lane inputs. Without removing the common clock path pessimism introduced by the common Main pll, the timing analyzer will always  show failed timing...

Also on other paths the design fails due to the not removed clock pessimism....

I hope you can help me!

Thank you

Christoph Dietz

[SyafieqS]

Hi Chris,

Thanks, Ill check and reproduce the issue.

[Ryan_S_Intel]

Was able to see it with this, "report_timing -from [all_inputs] -setup -npaths 100 -pairs_only -extra_info none -detail full_path -panel_name {all input}"

How come you have the incoming clock and data being generated from the clock sent out?  I get that it is the topology, but basically you're asking for that delay to be completely removed by CCPP, so if you just describe the incoming clock and data with a create_clock, then it would work.

My guess is what you're asking isn't feasible.  CCPP removal doesn't just look for commonalities between Data Arrival and Required, but I believe is tied into the timing models.  (Many years ago, when sending clock and data out for a source-synchronous transmit, we didn't fully remove all the CCPP between those paths, and it took a while for the timing analyzer to implement because it was pretty low-level.  So I really doubt it will just work for your case.

If I were to take a guess, the reason you want this is to synchronously timing the clock that is sent off chip and wrapped back around with the original clock that sends it?  

[SyafieqS]

Chris,

Any update from previous Ryan's reply?