Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
11 years ago

Basic Problems with altlvds_rx ipcore on CycloneV

Dear everyone, I have to receive LVDS data stream based on altlvds_rx on cycloneV device. LVDS data pairs are 500Mbps with accompany 250MHz clock(DDR mode). I set following parameters in the ipcore:

deserialization factor: 10

data rate: 500Mbps

clock frequency: 250MHz

phase alignment of rx_in to rx_inclock: 90.0

At the meantime I also set following constraint in sdc:

create_clock -name lvdsrx_inclk -period 4.000 -waveform { 0.000 2.000 } [get_ports "rx_inclock"]

After compilation, I find that there are hold timing errors inside the altlvds_rx ipcore, check the attachment.

The strange thing is that all the problem is inside the altlvds_rx itself, and I have no idea how to make a change.

Note that I have already set fitter to optimize hold timing for all paths.

Question:

1. Should I create lvdsrx_inclk clock in SDC? This is required or not?

2. If yes, how to correct this timing error?

15 Replies

Show More
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    11 years ago

    also notice that rx clk is not data clk but just ref for PLL which will read data on a gnerated clk to match 600Mbps and will then output a parallel clk at 1/10 of that.

    The internal data clock will have some jitter.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    11 years ago

    This is not how the PLL works, but how it is analyzed. Finite numbers are used to say where the edges occur, and so rounding does occur. When default setup and hold relationships are determined, it needs to be determined if it's a rounding issue or a real shift. That's the problem that had to be fixed. For jitter, that's part of clock uncertainty and calculated after the default setup and hold relationships are calculated and doesn't have an affect.

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    11 years ago

    at the end what matters is who should look after such strage violations; the tool or the user.

    You enter PLL rx clk as 300MHz(3.333 period as displayed by wizard) then you supply that clk and enter sdc as 3.333

    If the tool gets it wrong then it is a bug by definition. I haven't seen anywhere in TQ advice about rounding issues with respect to figures for clk period. I also entered sdc as "300MHz" instead of period and ended up with same strange violations.

    Certainly the device seems to achieve such speeds at periods below or above 3.333
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    11 years ago

    Yes, it's a rounding issue between different frequencies so they're no longer exact multiples of each other and is a bug. Improvements have been made in this, but can't be ported into existing architectures because it would change timing analysis on existing designs.

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    11 years ago

    Hello Rysc and kaz, thank you for your in-depth analysis. My problem is gone, and thank you again!