Questions about PCI-Express clock domain

[Weng Tianxiang]

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]

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]

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

 

[Kai Harrekilde-Petersen]

Marcus Harnisch <marcus.harnisch@gmx.net> writes:

"Weng Tianxiang" <wtx@umem.com> 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>