«

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" <> 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>

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" <> 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

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.

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" <> 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 <> 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>