About Transceiver???

[Altera_Forum]

If there was a serial digital data stream whose speed was 1Gbps. Can I recovery these datas by transceiver? If I can, how to realize it? And another question, is the transceiver valid for recoverying burst-mode high speed serial digital data whose rate is 1Gbps or higher? 

 I know there are some refenrences about transceiver on the Altera's web, but maybe because of lacking enough knowledge about analog circuits, I can't understand the introduction of the transceiver very well, not mention to use it.   After reading some references and some questions & answers in this forum, I have some fuzzy comprehension about transceiver. In my opinion, there is one component on the dev board to supply refclk for transceiver. The refclk maybe only 100MHz, but the transceiver can recover the input data's clock(the input data maybe 1Gbps) by the refclk. Is my understanding right?   If my undstanding is right, that means I could recover the clock of the 1Gbps input data very easily. Am I right?  Maybe I haven't find a good refenrence about transeiver which is easy to understand. Anyway, could you give me some easy--understanding transceiver refenrences for some people who are not familiar with transceiver like me? If there are examples about how to use it in application, that's better.

[Altera_Forum]

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

[Altera_Forum]

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)?

[Altera_Forum]

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

[Altera_Forum]

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!

[Altera_Forum]

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

[Altera_Forum]

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?

[Altera_Forum]

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

[Altera_Forum]

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

[Altera_Forum]

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

[Altera_Forum]

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

[Altera_Forum]

Hi kaz, I'm a partner of ztr1918294 

Thank you for your kindly and professional answer, we learned a lot from you about transceiver.   I have another question, since the serdes Rx contains a internal PLL which is used to lock the data frequency, it should take some time for PLL to lock to reference data’s frequece, how long is the recovery time? I want to explain “recovery time” more clearly, Our data stream is a little special, the link will be all “0” when there’s no data, so it is impossible to lock the data frequency for PLL when the link is idle. and the link will be not all “0” until there a data frame transmitted on this link, so I think the PLL needs to relock the data frequecy for every data frame. “recovery time” I want to know is how long the serdes Rx is able to lock to the data’s frequency from a frame starts to transmit on the link

[Altera_Forum]

Hi, 

 You are right, the PLL will need sometime to lock as any PLL(this includes locking to ref clock then recovering data clock, say few microsec). The stream then has to be locked to(depends on how you lock to it, your state machine). You can arrange to monitor these two lock cases.  Equally, you are right, with an all-zero stream you are likely to run into trouble. Why not change the stream to any other fixed but alternating pattern. This also helps keeping locked to stream when idle.  You may wonder how to read valid data then. In my system I allocated many extra bytes at beginning of each packet. One byte was used to indicate the start of first valid byte and another byte to indicate the number of bytes to follow(you don't need this if it is fixed size).  You can add any information in the link as header to packets as long as your link speed is fast enough which I believe it can be e.g. channel number, any user parameters...  By the way, we used this link to pass our channels as well as remotely download all firmware and software to a flash. This is very attractive feature when you can update a buggy program through internet.  Hope this helps. Kaz

[Altera_Forum]

I am so grateful for your quick answers. 

 Actually we are carrying out a research on optical network technology called Optical Burst Switched (OBS), one of its features is the data link is not continuous but swiched all the time. for example, there are 3 nodes in an network, called A, B, C. node B and C is connected to node A through a optical switch. the optical switch will continuous change the optical path between A-B and A-C according the setup message, so it is inevitable to relock the data frequence when optical path changed.   therefore the recovery time is essential for our design, I don't know if it is fixed or can be estimated by some method, it will be very helpful if you can share us some material about this parameter.   Many Thanks, Liming

[Altera_Forum]

Hi, 

 I believe you can measure the lock time directly by using a counter in fpga that start counting up after a general reset that is applied to the Rx as well as the counter. The counter to stop when lock is flagged by the serdes Rx.  You can see the final counter result directly in a signal tap(ELA/chipscope) then convert it to time.  Remember there are two stages(A PLL lock followed Rx recovery lock which is what need to measure). Use any suitably fast clock for the signal tap counter  Kaz

[Altera_Forum]

It may be useful to check the GXB transceiver specification in detail. 

 The GXB clock recovery unit can be configured to tolerate up to 1000 ppm frequency deviation. If this amount is sufficient for your application, the lock time to phase steps is most likely the most serious issue. I didn't find an explicite CRU lock time specification, but it may be estimated from the maximum receiver PLL bandwidth of 60 MHz.

[Altera_Forum]

hello all 

 Could you please tell if it was successful to use CDR in side the ALtera FPGA to receive the burst traffic . thank you

[Altera_Forum]

Hi all 

I have a similar question  I need to design a CDR working at 160 Mbps, +/- 1% the input frame is NRZ biphase mark: 00110101101001.. ( max 2 consecutive "0" or "1" ) I can do it by using a ADN1814 : http://www.analog.com/en/clock-and-timing/clock-and-data-recoveryretiming/adn2814/products/product.html  but, is it possible to do the same by using the CRD inside transeiver of the ARRIA ? Thanks in advance for your help JJ