Questions about PCI-Express clock domain

Discussion in 'VHDL' started by Weng Tianxiang, Apr 14, 2005.

  1. Hi,
    I would like to ask for your opinions on one design issue.

    Our PCI-Express design has 3 clocks: one from local clock source on our
    board to generate DDR signals;
    Another two clocks are from transition line and receiving clock is
    extracted from transition 8B/10B signals.

    There are two methods we are considering:
    Our most VHDL control code is based the receiving clock extracted
    from 8B/10B signals and the handling is synchonous with receiving data.


    Another design uses its local clock to handle the received data.

    If there is any problem with the first method?

    Thank you.

    Weng
     
    Weng Tianxiang, Apr 14, 2005
    #1
    1. Advertising

  2. "Weng Tianxiang" <> writes:

    > Hi,
    > I would like to ask for your opinions on one design issue.
    >
    > Our PCI-Express design has 3 clocks: one from local clock source on our
    > board to generate DDR signals;
    > Another two clocks are from transition line and receiving clock is
    > extracted from transition 8B/10B signals.
    >
    > There are two methods we are considering:
    > Our most VHDL control code is based the receiving clock extracted
    > from 8B/10B signals and the handling is synchonous with receiving data.
    >
    >
    > Another design uses its local clock to handle the received data.
    >
    > If there is any problem with the first method?


    Just make sure that you are using a PLL to extract and stabilizing the
    receive clock. Also, make sure that in case the 8B/10B input ceases,
    that you are able to switch over to an internally generated clock for
    the PLL.

    If you do this, I don't see any problems in using the receiving clock.


    Kai
    --
    Kai Harrekilde-Petersen <khp(at)harrekilde(dot)dk>
     
    Kai Harrekilde-Petersen, Apr 14, 2005
    #2
    1. Advertising

  3. Hi,
    Here are more details about the design.

    3 Modules:
    1. DDR controller;
    2. DMA engine;
    3. PCI-Express interface;

    DDR controller uses local clock; OK;
    PCI-Express interface uses transition line clock for receiving part;
    OK.
    Now the problem is for DMA engine;
    My opinion is DMA engine must use local clock to make it robust in any
    situations;
    My collegue wants to use extracted clock from transition line to clock
    DMA engine.

    What is your opinion?

    Weng
     
    Weng Tianxiang, Apr 14, 2005
    #3
  4. "Weng Tianxiang" <> writes:

    > What is your opinion?


    Agreeing with all reasons stated by Kai, I can only recommend staying
    in your local clock domain fro as much of your logic as possible. You
    *will* have to deal with transmission errors which will spoil the
    recovered clock. Use the receive clock only to dump data into a FIFO
    (if there is more than one lane you'll have to have at least one for
    lane alignment).

    Best regards,
    Marcus
     
    Marcus Harnisch, Apr 16, 2005
    #4
  5. Weng Tianxiang

    mk Guest

    On 14 Apr 2005 15:31:22 -0700, "Weng Tianxiang" <> wrote:

    >Hi,
    >Here are more details about the design.
    >
    >3 Modules:
    >1. DDR controller;
    >2. DMA engine;
    >3. PCI-Express interface;
    >
    >DDR controller uses local clock; OK;
    >PCI-Express interface uses transition line clock for receiving part;
    >OK.
    >Now the problem is for DMA engine;
    >My opinion is DMA engine must use local clock to make it robust in any
    >situations;
    >My collegue wants to use extracted clock from transition line to clock
    >DMA engine.
    >
    >What is your opinion?
    >
    >Weng


    Another option is to use an elasticity buffer and isolate the
    recovered clock completely. This way the output of the elasticity
    buffer is synchronized to the local clock and you don't have any
    clock-domain issues anymore. PCI Express spec gives you enough help to
    accomplish this relatively easily.

    I am also curious if you are implementing your own PHY or whether you
    are using an existing PHY. If the latter, does the PHY support PIPE ?
    If yes, you don't have any problems to start with.
     
    mk, Apr 17, 2005
    #5
  6. Marcus,
    I fully agree with your opinions and I don't understand why you agree
    with all reasons stated by Kai.
    "Just make sure that you are using a PLL to extract and stabilizing the

    receive clock." I don't agree with the idea.

    This clock may be wrong and data error can be detected by CRC, but if
    the extracted clock is used, when error is detected, it is too later to
    protect your code.

    Thank you.

    Weng
     
    Weng Tianxiang, Apr 19, 2005
    #6
  7. "Weng Tianxiang" <> writes:
    > I fully agree with your opinions


    > and I don't understand why you agree with all reasons stated by Kai.
    >
    > "Just make sure that you are using a PLL to extract and stabilizing
    > the receive clock."


    IIRC, I said I'd agree with the reasons, *not* with the conclusions
    that were drawn. Kai was pointing out (although indirectly) that the
    recovered clock is unreliable.

    The additional effort to switch back and forth between internal and
    recovered clock is IMHO pointless since in either case you'd have to
    maintain the internal clock. Why not use it to begin with? Behavior of
    the chip will be much more predictable, too. I wouldn't want to think
    about verifying the two-clock-system.

    I guess working with all sorts of 10GB SerDes stuff in the past made
    me read more into the message that I was following up to than what had
    actually been written. Sorry about that.

    Best regards,
    Marcus
     
    Marcus Harnisch, Apr 19, 2005
    #7
  8. Marcus Harnisch <> writes:

    > "Weng Tianxiang" <> writes:
    >> I fully agree with your opinions

    >
    >> and I don't understand why you agree with all reasons stated by Kai.
    >>
    >> "Just make sure that you are using a PLL to extract and stabilizing
    >> the receive clock."

    >
    > IIRC, I said I'd agree with the reasons, *not* with the conclusions
    > that were drawn. Kai was pointing out (although indirectly) that the
    > recovered clock is unreliable.


    Yup, that was my point. I was indirect on purpose - the original
    posting smelled of homework, so I thought that I'd leave something for
    "the student" to figure out :)

    As an example of problems arising from an unreliable receive clock,
    I've recently debugged a problem where we saw our Ethernet switch
    forwarding packets with CRC errors. After much gnashing of teeth,
    pulling of hairs etc, we found that we could provoke it by injecting a
    1 nsec spike on the receive clock. When the spike occurs, both the
    datapath and the CRC logic double-clocks, but while the datapath
    samples another 64 bit of data, the CRC logic doesn't change state
    because of the logic depth is so big that no inputs to the CRC state
    register had changed state -> the CRC is OK at the end of the frame.

    Had the CRC checker been in the local clock domain, and checked the
    data there, this error wouldn't have happened.


    Kai
    --
    Kai Harrekilde-Petersen <khp(at)harrekilde(dot)dk>
     
    Kai Harrekilde-Petersen, Apr 20, 2005
    #8
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Valentin Tihomirov

    Are clock and divided clock synchronous?

    Valentin Tihomirov, Oct 23, 2003, in forum: VHDL
    Replies:
    11
    Views:
    3,340
    louis lin
    Oct 28, 2003
  2. Sebastian
    Replies:
    1
    Views:
    932
  3. Replies:
    4
    Views:
    740
    Peter Alfke
    Apr 27, 2006
  4. bart
    Replies:
    0
    Views:
    399
  5. Replies:
    7
    Views:
    523
Loading...

Share This Page