LVDS Serdes DPA FIFO reset recovery timing violation issue (Cyclone 10 GX)

[designEngineer]

I am trying to deserialize a 16 bit wide DDR data input running at 676 MHz using an LVDS SERDES IP and get recovery timing violations on the DPA FIFO resets. I am looking for help on fixing those in order for me to be able move forward with the design.

The LVDS SERDES IP settings are as follows:

General Settings:

-----------------

Functional mode: RX DPA-FIFO

Number of channels: 16

Data rate: 1352 Mbps

SERDES factor: 8

PLL Settings:

-------------

Desired inclock frequency: 676 MHz

Receiver Settings:

Enable rx_dpa_reset port: checked

Enable rx_fifo_reset port: checked

Clock Resource Summary:

-----------------------

Fast clock: 1352 MHz

Load enable: 169 MHz

Core clock: 169 MHz

So on the SERDES output side I have 128-bit wide data running at 169 MHz.

The user guide recommended initialization sequence is:

1. Assert PLL and DPA reset

2. Deassert PLL reset and monitor PLL lock

3. When PLL lock is stable, deassert DPA reset

4. Let DPA use training pattern to lock

5. When DPA lock asserts, assert FIFO reset for at least one parallel clock cycle

6. Deassert FIFO reset

I am following the recommendation and when building the FPGA end up with recovery timing violations from the DPA lock flop to the serdes DPA FIFO.

These are the details on how I am generating the resets:

rst_n           - external low active reset input pin

serdesPllLocked - PLL lock out of the SERDES block

clk_169         - rx core clock output of the SERDES block

serdesDpaReset  - DPA reset input to the SERDES block

reset_n_169     - reset for the 169 MHz clock domain logic

serdesFifoReset - DPA FIFO reset input to the SERDES block

//Reset logic

assign reset_n_int = rst_n & serdesPllLocked;

always @(posedge clk_169 or negedge reset_n_int) begin

  if (reset_n_int == 1'b0) begin

     serdesDpaReset <= 16'hFFFF;  // DPA reset assert

     reset_n_169   <= 1'b0;

  end

  else begin

     serdesDpaReset <= 16'h0000;  // DPA reset deassert

     reset_n_169   <= 1'b1;

  end

end

// reset ALL DPA FIFOs if ANY of the DPAs are not locked

assign serdesFifoReset = {16{(~&serdesDpaLock)}};

Attached is the timing report of one of the failing paths.

Is there something I am doing specifically wrong, or does anyone have recommendations on how to fix the timing violations?

Thank you so much!

[Rahul_S_Intel1]

Hi ,

I suspect is it because of the user logic presents makes the design to violate the timing

[designEngineer]

I am not sure I understand the reply. Would you mind describing the problem a bit further? Also, do you have a suggested change to fix the problem?

Thanks!

[Rahul_S_Intel1]

Hi ,

I am trying to explain the timing violation will not happen because of IP , the logic related to IP may create the timing violation , I am kindly requesting to check the logic behind the ip to resolve the timing issue .

Mean while I am not expert in timing , I will check with internal colleague who is expert in timing and will get back to you .

[designEngineer]

I understand that the timing violations can be cause by delay through the logic outside of the IP, however the recommendations state that the DPA FIFO should get a reset when the DPA locks and in order to do that I added these ports to the IP and use them outside the IP. I am trying to do this with as little delay as possible by using the DPA lock output almost directly as the DPA FIFO reset input. The signal is going only through a combinatorial inverter to get the polarity correct.

A suggestion of how else to do it that does not create timing violations would be greatly appreciated.

I am looking forward to hearing from your internal colleague who specializes in timing.

Thanks!

[Kenny_Tan]

Hi,

Is that possible for you to attached your design to look into it? Looking into the report, it would be hard to identify the problem. LVDS had two type, one is soft LVDS (supported in certain family device only) and hard LVDS, basically, not much constrain needed for hard LVDS.

You can refer to the email if you do not wish to published your design in public.

Thanks

[designEngineer]

Hi Kenny,

Thank you for looking into this. I will provide a stripped version of the project with the relevant logic through direct message.

Thanks!

[Kenny_Tan]

Hi,

Alternatively, you can provide your design privately. You can check your email on this.

Thanks,

[Kenny_Tan]

Hi,

Thanks for attaching the design.

I look into the recovery failure, it is internal of the LVDS module. Can you try the recommendation mention in

https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/ug/ug_altera_lvds.pdf

page 25

Sorry that Rahul provide a wrong assumption that inside the IP will not have the timing violation. This is untrue especially for LVDS.

Thanks,

Best regards,

Kenny Tan

[Kenny_Tan]

I manage to close the timing, the timing violation occur because your rx_dpa_locked[15:0] is connected back to your rx_fifo_reset[15:0]. This will cause recovery failure as there will be different clock transfer between the ports. I will attached back the design to you. You may check your email.

[Kenny_Tan]

Kindly note that we are working internally for this thread.

[Kenny_Tan]

Kindly note that this issue was resolve internally. This thread will be closed