FPGA Intellectual Property
PCI Express*, Networking and Connectivity, Memory Interfaces, DSP IP, and Video IP
6486 Discussions

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

designEngineer
New Contributor I
1,827 Views

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!

0 Kudos
11 Replies
Rahul_S_Intel1
Employee
1,721 Views

Hi ,

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

0 Kudos
designEngineer
New Contributor I
1,721 Views

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!

0 Kudos
Rahul_S_Intel1
Employee
1,721 Views

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 .

 

 

0 Kudos
designEngineer
New Contributor I
1,721 Views

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!

0 Kudos
Kenny_Tan
Moderator
1,721 Views

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

0 Kudos
designEngineer
New Contributor I
1,721 Views

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!

0 Kudos
Kenny_Tan
Moderator
1,721 Views

Hi,

 

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

 

Thanks,

0 Kudos
Kenny_Tan
Moderator
1,721 Views

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

0 Kudos
Kenny_Tan
Moderator
1,721 Views

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.

0 Kudos
Kenny_Tan
Moderator
1,719 Views

Kindly note that we are working internally for this thread.


0 Kudos
Kenny_Tan
Moderator
1,707 Views

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


0 Kudos
Reply