PCI e clocking

Hello,

I don't have the specification of PCI e ( that doesn't help ! ) and I'm trying to figure out how the clock scheme works on PCI express.

For me when using serial high speed links, the clock was included within the

8B/10B and hardware low layers stuffs. I did a design with aurora and MGT on fiber links, and no clock was transmitted as a signal, it was integrated on the data line.

For me PCIe is the same thing but on LVDS. And I saw on a reference design that a LVDS clock was given the PCIe interface chip and send to the bus connector.

So when I design a PCIe board, what is the clock scheme to implement ? Clock generation or not on the bus ?!!

I'm missing something. Obviously.....

Thanks for your help !

Stéphane.

Reply to
sjulhes
Loading thread data ...

Our design is a board with PCI/PCIe 4x interface. My question concern is on the PCI express bus connector side.

Stéphane.

"mk" a écrit dans le message de news: snipped-for-privacy@4ax.com...

the

Reply to
sjulhes

"sjulhes" schrieb im Newsbeitrag news:43c75f44$0$19976$ snipped-for-privacy@news.free.fr...

PCIe reference clock 125MHz may (but doesnt have to!) be transmitted in the PCIe connector

however Virtex2Pro MGT do not guarantee safe locking from data only, so external PLL circtuit that delivers MGT clock (from ref clock) is required for Virtex PCIe solution.

check out the materials from nital, you will see that PLL circuit in some of their data sheet for their PCIe boards

--
Antti Lukats
http://www.xilant.com
Reply to
Antti Lukats

At what level are you implementing PCIE ? Are you doing a controller where your interface is to the PHY ? Even if then you need a parallel interface to the PHY (most probably through PIPE) and the clock for PIPE is generated by the PHY at a low speed. There is a no clock at the wire for PCIE. The receive side is supposed to recover the clock by looking at the 8b10b encoded data (and tolerate dropped/added bits by using some extra codes added by the protocol). The PIPE level PHY should isolate you from all clocking at 2.5 GHz speed.

Reply to
m

Do yourself a favor and buy a copy of the spec. In the long run it's cheaper than redesigning due to mis-information.

he

My copy of the PCIe spec says the nominal frequency is 100MHz

+/-300ppm. It also clearly states that the reference clock does not need to be used by the plug- in card, but I don't see anywhere that the system doesn't have to provide it.

The point of delivering a reference clock was to reduce the depth of FIFO's dealing with differences in clock generation between ends of a link. The spec says the plug-in card should maintain its own reference clock within

+/-600ppm of the system reference if the system reference isn't used (not too hard with a crystal oscillator, but still easier to use the system reference if you can).

of

Reply to
Gabor

Gabor wrote: [snip]

"REFCLK-/REFCLK+ (required): low voltage differential signals."

- PCI Express Card Electromechanical Specification, Rev. 1.1, chapter 2, "Auxiliary signals"

Reply to
Gabor

"Gabor" schrieb im Newsbeitrag news: snipped-for-privacy@o13g2000cwo.googlegroups.com...

Hi Gabor,

I hope you replied to the OP and not to my comments, I do know the specs.

V2Pro MGT have CDR hard lock region +150 -110 ppm, what is not sufficent to cover the +-300 ppm spec requirement of PCIe, those if V2PRo MGT are used and external PLL solution is required.

so that is what I was referring to

V4MGT have extended CDR lock region that covers the +-300 ppm PCIe spec requirement

--
Antti Lukats
http://www.xilant.com
Reply to
Antti Lukats

Hello,

The PCI Express Base Specification v1.1 doesn't specify a reference clock; the reason is that PCI Express is designed to operate without a common reference clock between components. What the PCI Express Base Specification v1.1 does specify is the allowed ppm difference (+/- 300 ppm) on the unit interval (400 ps). Technically, you can use whatever reference clock you want, at whatever frequency you may desire, as long as your device's transmitter observes the UI specification and your device's receiver is able to lock onto a signal (from another device) that also observes the UI specification. In the most general case, this a pleisochronous interface.

While we are on the topic of common signals distributed to components, the PCI Express Base Specification v1.1 does not specify a common, distributed reset signal. It also does not specify a common, distributed power managment event signal. There are mechanisms to communicate these "events" in-band.

Now, all that being said, there is another document, the PCI Express Card Electromechanical Specification v1.1, which defines a standard card and slot form factor. One of the features of this form factor is the availability of a distributed reference clock that is nominally 100 MHz and has specified electrical characteristics. You can use it, or not. If you need some other frequency, like 125 MHz, or you need it in some other electrical signaling standard, you will need to provide for that conversion.

There are some significant advantages to using this reference clock. One is that you don't need to provide your own oscillator. Another advantage of using a common reference clock is that it turns what was a pleisochronous interface into something that is mesochronous which will, based on the specifications, tolerate the use of spread spectrum clocking on the reference clock. I am also told that this arrangement enables CDR circuits in receivers to lock much more quickly, facilitating low latency exits from PCI Express power saving states. I think that's because the lock to data step doesn't have far to go from the lock to reference, but I don't design PLLs so don't quote me on that.

The PCI Express Card Electromechanical Specification v1.1 also defines a reset signal, PERST#, and a power management event signal, WAKE#. These provide an alternate side-band (versus in-band) mechanism for signaling these events. Their operation and use is described in this separate document because they are NOT part of the base specification.

Eric Crabill Xilinx, Incorporated

Reply to
daniveras

Thank you all for your answers.

Stéphane.

"sjulhes" a écrit dans le message de news:

43c75f44$0$19976$ snipped-for-privacy@news.free.fr...

the

Reply to
sjulhes

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.