About Transceiver???

Generally speaking, Yes you can by using the "serdes" part available in some FPGAs and it works whether the stream is bursty or not as long as the link speed is not violated. Usually these serdes have multiple channels.

The serdes will need a suitable reference clock for its internal PLL. It will then recover the serial data into say bytes outputting also the byte clock.

You - the designer - will need extra work to lock to your stream and you will need to align the byte boundaries e.g. by using a state machine.

Additionally your board layout should accomodate the speed.

Practically, you need to instantiate a serdes receiver(and a transmitter if you are sending bytes as well). read its data sheet and once you done that then apply your lock/byte alignment algorithms to the byte stream which is output by the serdes rceiver. This should be done per channel if you are using more than one channel.

Locking to stream can be made easy by having the link send known patterns when idle(training pattern).

In case of serdes transmitter, just send your bytes across, it doesn't need any locking of course but you may send training patterns if the other receiver neds them. The receiver and transmiter may share the same reference clock.

Regards

Kaz

Thank you for your answer.

From your answer and the handbook of the stratix II GX(the transceiver supports data rate from 600MHz to 3.125GHz), that means I can recover the clock of 1Gbps bursty data stream through transceiver using maybe only 100MHz refclk. And I think the dk-pcie-2sgx90n(http://www.altera.com.cn/products/devkits/altera/kit-pciexpress_s2gx.html?f=devkt&k=g2) maybe a good dev board for realizing my design.

Now I have a another question. If the bursty input data rate is 1Gbps, what's the value should the refclk be? In an another word, what's the relationship between input data rate and refclk?

And what's the price of the dk-pcie-2sgx90n now? If it is too dear for me, is there any other cheap choice or replacement which can fullfil my request(recover 1Gbps bursty optical data stream)?

Hi,

The reference clock relationship is a matter for the PLL you are using. I mean any PLL has some restrictions on its input clock for a given output clock and is the consequence of divisions within the PLL. You can find out by instantiating the serdes and entring your requirements(including the link speed and the serializatio factor).

As to the price, I hope somebody else on this forum can help. I never used third party boards.

Regards

kaz

Hi, Kaz, you are so kind, thank you for your help! May I ask you some more questions?

I'm clear that I can recover the clock from 1Gbps bursty input data through the transceiver.

You know, my last goal is to recover the input data after recovering the clock. When the data rate is only under 500Mbps, I can use the FPGA to recover the input data by the way of oversampling through recovered clock.

But when the data rate is 1Gbps, althogh I can get the recovered clock, limited by the internal working speed of the FPGA(always below 1GHz), it seems that I can't use the oversampling to recover the input data.

Can the transceiver not only recover the clock, but also recover the input data? If the transceiver can finish it, I think I can deserialize the recovered data, then deal with them by FPGA. If the transceiver can't reach that request, what should I do after recovering the clock for the goal of recovering the bursty 1Gbps input data?

There're some references on the internet about recovering data whose rate is over 1Gbps. But most of them are suggesting to design special circuit to fullfil the request, I think it's not easy for us to make that special circuit. So our idea is to find a good FPGA dev board to finish it. We can realize recovering 100Mbps bursty input data, but puzzled by 1Gbps. If the transceiver can solve the problem of recovering 1Gbps bursty input data, I think it will be our best choice now.

Hope for your help!

Hi,

It seems to me that there is some confusion about serdes functionality.

Let us assume your serialisation ratio is 8. The receiver(serdes Rx) will recover both the bytes and the byte clock. You don't have to worry about data recovery, this is done for you by the serdes Rx. This means the serdes Rx deals with the nasty high speed work and gives you the data and its clock at a gentle speed(= link speed/8) suitable for processing inside the logic area of FPGA. This is so irrespective of data rate on the link as long as it is below the maximum link rate.

(Usually) it is your task is to align the byte boundary and lock to your stream before you can do any further processing. You also need to know when data is valid since it can be at any rate(serdes Rx wouldn't know that). The link itself will have a constant speed but data can be bursty. I mean, when you enter the link speed say 1Gbps then your data can be anything between zero~1G. Thus, there must be a protocol between you and the Tx to know when data is valid and when it is not. I don't see any relevance of upsampling in this context, please explain that if you wish.

Please note that devices are different and are changing continuously and may be your device will do things like byte-alignment automatically or even take over the task of stream detection/locking). My own experience was with stratix II and so may not exactly apply to your case in some details.

Regards

Kaz

We use the oversampling way to recover the 100Mbps data through recovered clock and FPGA.

The idea is in the attachment

Could you tell me if I can use the same way to recover 1Gbps data through FPGA and recovered clock from transceiver?

I had a quick look at your pdf.

I can see the difference of perspective now. I am referring to altera serdes while you are referring to xilinx data recovery circuits for some of their devices. In this case you have to do a lot more. I suggest you also post at www.fpgarelated.com (http://www.fpga-related.com) for their help.

Regards

kaz

Hi, I'm back!

I read the stratix handbook recently carefully. I found the transceiver really can recover 1Gbps input data with maybe 50MHz refclk.

I don't know wethear you are really understand what burst-mode data is. It's common in OBS(optical burst swithing) net. General speaking, the input data may contain two or more kinds of data stream whose rate is nearly 1Gbps but not the same for each other.

For example, there are 9000 bits in the input data stream. The rate of the 1--3000 bits is 1.0001Gbps, The rate of the 3001--6000 bits is 1.0000Gbps, The rate of the 6001--9000 bits is 0.9999Gbps. At first, I can get the 1GHz cruclk from refclk by the transceiver in the lock-to-refclk mode accurately, after at least 15us(the handbook said), the transceiver turns into lock-to-data mode.

If it lock the frequecy & phase of the first 3000 bits data and recover them successfully, can the CRU will recover the middle 3000 bits data accurately at once, not need to go back to the lock-to-refclk and then turn into lock-to-data to recover the middle 3000 bits data?

From theory, I think the CRU will recover the middle 3000 bits data at once. Because of the two sigals(up & down), I think them can tune the PFD to make the VCO always locking the input data automaticly. But wether the auto-fit speed of the VCO is fast enough to recover the burst-mode data in fact, I'm not sure.

So could Kaz or anybody else who have the expericen to recover the burst-mode with transceiver give me help and answer? Thanks a lot!!

Hi,

In principle, if you want to recover any clock from any data stream then you better force your data to be at a fixed rate.

So if your data is bursty, make it fixed rate by inserting false(dummy bits).

You will then need to recover one clock(at the fixed rate) and declare your lock state with celebration, the overhead cost is the data valid arrangement and that all data trnsmitted in the link must be sampled on the highest rate. This is cheaper than having to recover the clock on variable rate(which is not practical anyway, you will have to lock and relock).

This is what the previous serdes description was all about. As to meaning of bursty, I believe I understand it. I have lived so far a decade on bursty vdeo data.

kaz

Hi again,

To further explain my point:

The Tx guy must send you data according to an agreed format(protocol).

There are several scenarios.

For example: Tx may send 10 channels. Each channel will have its own bursty rate. But Tx will have to manage passing all data from their clock domains to the link (using various fifo techniques). Tx may need to pass data as packets with extra headers to indicate its start and which bytes are valid.

Tx may stuff the idle slots with a pattern e.g.(01010101) and the packet header may be the values(4=> 3 => 2 => 1 => go...)

The Rx can use these patterns to lock to the stream and detect packet/byte boundaries and then read valid data(once it receives the recovered raw bytes and its clock). Thus Rx reads the data that are valid only...

Kaz