In altera Transceiver, why some protocols need rate match fifo, some don't need?

PCIe, XAUI and GIGE specifications respectively state a ±300 and ±100ppm clock frequency tolerance between the bit rates of the transmitter and receiver at the two ends of a link.

So, if you want your product to be PCIe, XAUI or GIGE compliant, you have to implement a compensation device such a FIFO otherwise you can't put "PCIe, XAUI... Ready !" on your advertisement...

From a more technical point of view, I am wondering, perhaps as you, how two system reference clocks may have a frequency difference as great as 600ppm total (1.5MHz worst-case frequency delta for a 2.5Gbps in PCIe !...). Nowadays, any basic of-the-shelf VCXO can offer for a few dollars at least a 100ppm frequency stability over a wide temperature range. So you can find a better quality product with a slight "catalog research" effort.

In the end, the reason behind is probably that parts implemented for consumer electronics (like crystal oscillators) have to be as cheap as possible and that their default/poor quality may be compensated by "software" (gateware in our case)...

Hi genoli,

I understand that if the the ppm is exceeds the frequency tolerance between the bit rates of the transmitter and receiver at the two ends of a link, the transceiver will not work correctly?

But a silly question here, why the ppm will make them don't work?

Why my 8b/10b and remaining PCS blocks can not use the receiver slow clock rather than cmu slow clock? what will be the impact?

The reason i ask so is although the spec state that PCIE, GIGE and XAUI protocols are compulsory to use rate match fifo. But why i need to use? I just don't understand.

The rate match fifo and associated logic allow you to interface to a single clock domain that is local to your board (coreclk). The rate matching is done by inserting or deleting skip characters to keep the data flowing without overflowing or underflowing the phase compensation fifo. This saves you from managing the frequency differences yourself.

If it allowed you to remove the rate match fifo, the phase compensation fifo (which is small) may not be able to handle the differences in frequency causing you to drop or repeat parallel data words.

There are more details about how it works in the different device handbooks. For example, http://www.altera.com/literature/hb/stratix-iv/stx4_siv52001.pdf (http://www.altera.com/literature/hb/stratix-iv/stx4_siv52001.pdf)

sysysy,

unless you were to use the recovered slow clock as base for _everything else_ in your design, you'll have to, at some point cross, cross between the recovered slow clock domain and another (local) clock domain.

Unless these two clocks trace back to the exact same crystal, they'll drift: one of them will inevitably be a bit faster than the other and periodically you'll be short of data or in excess of data.

You need some kind of elastic scheme to deal with this. That's the job done by the rate matching FIFO.

In some applications (ie, SRIO) it's mandatory that all endpoints trace their reference clocks back to the same source (same crystal).

In this case, there is no drift and the rate matching FIFO is not needed.

Hi rbugalho,

you mentioned that,

--- Quote Start ---

In some applications (ie, SRIO) it's mandatory that all endpoints trace their reference clocks back to the same source (same crystal).

--- Quote End ---

Can i say that, SRIO only can transmit data within the same board?

It is impossible to transmit data from board 1 to board 2, because definitely both boards will use different on board oscillator or crstal already.

Am i right?

You can use SRIO to transmit among different boards... as long as the boards have a common clock reference.

It needs to be the same source, crystal, but you can distribute the clock among multiple boards using cables, backplanes, whatever.

Ie, SRIO is used in ATCA/µTCA crates, but there's a reference clock distributed by the crate to the boards.

But if you have different oscillators, then it's a no-go. You need another protocol which is elastic.