altera transceiver support burst mode?

[Altera_Forum]

Hi,  

 is there any possibility for altera stratix ii gx transceivers to support burst mode operation? any ideas?

[Altera_Forum]

What do you mean by burst mode? 

 Cheers, Dave

[Altera_Forum]

--- Quote Start ---  What do you mean by burst mode?  Cheers, Dave  --- Quote End ---    Hi Dave,  As we all know, transceivers need some training sequence to synchronize. Like XAUI for 10GE, it will send K28.5 and other signaling codes to ensure the lanes aligned and synchronized. If the transmission mode is not continuous, that is burst mode, high speed CDR will be required in order to recover the packet format. I have no idea whether Altera transceivers have that capability to recover the packet in ns scale, and how to operate on it?  Just for open discussion.

[Altera_Forum]

--- Quote Start ---   As we all know, transceivers need some training sequence to synchronize. Like XAUI for 10GE, it will send K28.5 and other signaling codes to ensure the lanes aligned and synchronized. If the transmission mode is not continuous, that is burst mode, high speed CDR will be required in order to recover the packet format. I have no idea whether Altera transceivers have that capability to recover the packet in ns scale, and how to operate on it?  Just for open discussion.  --- Quote End ---  I would still argue that this is not a burst mode :)  If you have 'traffic' that has bursts, and the interface uses CDR, then at the physical layer, there is a continuous toggling of bits, otherwise CDR will unlock. But, lets not get into a semantics argument.  I don't quite understand what you mean by 'recover a packet in ns scale'. Perhaps you could explain what you are trying to do.  I'm currently investigating using the receivers on the high-speed transceiver blocks for receiving data from high-speed ADCs with >5Gsps lane rates for the digitized data. The interface between the ADC and the transceiver is pretty much 'capture the bits', with no option for sending any protocol 'idle' characters and other such luxuries. If your application is similarly non-standard, perhaps I can help.  Cheers, Dave

[Altera_Forum]

--- Quote Start ---  I would still argue that this is not a burst mode :)  If you have 'traffic' that has bursts, and the interface uses CDR, then at the physical layer, there is a continuous toggling of bits, otherwise CDR will unlock. But, lets not get into a semantics argument.  I don't quite understand what you mean by 'recover a packet in ns scale'. Perhaps you could explain what you are trying to do.  I'm currently investigating using the receivers on the high-speed transceiver blocks for receiving data from high-speed ADCs with >5Gsps lane rates for the digitized data. The interface between the ADC and the transceiver is pretty much 'capture the bits', with no option for sending any protocol 'idle' characters and other such luxuries. If your application is similarly non-standard, perhaps I can help.  Cheers, Dave  --- Quote End ---    Hi Dave,  Have you ever heard about passive optical network. From the ONU to OLT, several clients will share the same physical link. In this case, ONU should send packet in optical layer to OLT in order not to interfere other clients packets. As a result, OLT should recover the clock very fast (packet usually contains preambles) - for detecting the effective packet.  In your case, what kind of transceivers I/O standard do you choose, basic or else? If there is no communication between nodes, do the links keep zero or send some training packets like K28.5.. Thank you for your discussion:)  Rick

[Altera_Forum]

Hi Rick, 

   --- Quote Start ---   Have you ever heard about passive optical network. From the ONU to OLT, several clients will share the same physical link. In this case, ONU should send packet in optical layer to OLT in order not to interfere other clients packets. As a result, OLT should recover the clock very fast (packet usually contains preambles) - for detecting the effective packet.   --- Quote End ---  I have heard of it, but have never looked at any of the details.  What you describe occurs on the fiber. What happens at the optical-to-electrical interface? Is it simply optical-to-electrical conversion of whatever is on the fiber, or is something smarter used?     --- Quote Start ---   In your case, what kind of transceivers I/O standard do you choose, basic or else? If there is no communication between nodes, do the links keep zero or send some training packets like K28.5..   --- Quote End ---  I use basic mode. There are two clocking methods that I need to investigate; lock-to-reference and lock-to-data. In lock-to-reference, the transceiver PLLs lock to an external reference clock and ignore the CDR recovered clock (if there is one), otherwise you can switch to a recovered clock (in lock-to-data mode). There are status bits in the transceiver block that indicate whether there is a CDR PLL lock. It sounds like you could use something similar; when there is no traffic, and the CDR PLLs lose lock-to-data, switch them back to lock-to-reference, then when data comes, they can go back to lock-to-data.  What you would need to investigate is how fast this can happen, and whether or not it will be sufficient to capture traffic. Given that the packet contains preambles, I suspect they are there for lock-to-data to occur. If you know the preamble length, and the worst-case lock-to-data time, you will be able to determine if it can work.  Cheers, Dave

[Altera_Forum]

--- Quote Start ---  Hi Rick,  I have heard of it, but have never looked at any of the details.  What you describe occurs on the fiber. What happens at the optical-to-electrical interface? Is it simply optical-to-electrical conversion of whatever is on the fiber, or is something smarter used?     --- Quote End ---    It's simply O/E or E/O conversion, without smarter used. Or, you have to get specified burst mode CDR chips for providing recovered clk and data. Actually, I don't want to do this since I need to redesign the board. That's why I ask for some details of FPGA and it's capability to support burst mode operation.     --- Quote Start ---   I use basic mode. There are two clocking methods that I need to investigate; lock-to-reference and lock-to-data. In lock-to-reference, the transceiver PLLs lock to an external reference clock and ignore the CDR recovered clock (if there is one), otherwise you can switch to a recovered clock (in lock-to-data mode). There are status bits in the transceiver block that indicate whether there is a CDR PLL lock. It sounds like you could use something similar; when there is no traffic, and the CDR PLLs lose lock-to-data, switch them back to lock-to-reference, then when data comes, they can go back to lock-to-data.  What you would need to investigate is how fast this can happen, and whether or not it will be sufficient to capture traffic. Given that the packet contains preambles, I suspect they are there for lock-to-data to occur. If you know the preamble length, and the worst-case lock-to-data time, you will be able to determine if it can work.  Cheers, Dave  --- Quote End ---    It's pretty cool that you provide your design details. I really would like to look into the clocking methods you mentioned: lock-to-reference, or lock-to-data. Can the clock methods choose by configuration or external control? The preamble could be programmed by myself. Still, I have no idea how long it needs to be the worse case lock-to-data. I will check it out soon with two dev boards with Altera Stratix II GX FPGA.  Where can I get more information or datasheet of clocking methods ? Thank you. If you have any questions on the high speed operation like 10GE, let me know.  Rick

[Altera_Forum]

Hi Rick, 

   --- Quote Start ---  It's simply O/E or E/O conversion   --- Quote End ---  Ok, so the lock-to-reference and lock-to-data modes would be needed.    --- Quote Start ---   It's pretty cool that you provide your design details. I really would like to look into the clocking methods you mentioned: lock-to-reference, or lock-to-data. Can the clock methods choose by configuration or external control?   --- Quote End ---  You can configure the Stratix IV GX transceivers as manual or automatic. The Stratix II GX might be different, I have not looked at their data sheets.    --- Quote Start ---   The preamble could be programmed by myself. Still, I have no idea how long it needs to be the worse case lock-to-data. I will check it out soon with two dev boards with Altera Stratix II GX FPGA.   --- Quote End ---  Given that you control the preamble, it should be possible to make it work.    --- Quote Start ---   Where can I get more information or datasheet of clocking methods?   --- Quote End ---  Listen to the transceiver webinar on the Altera web site. I think its the 2.5hr one. It has a nice overview of all the transceiver features.  Lets see if I can find it:  This one is 0.5 hrs: http://www.altera.com/education/training/courses/osiigx1115  This one is 2.5 hrs: http://www.altera.com/education/training/courses/o40nm1110  I'm pretty sure these both had comments on LTD and LTR modes. Just skip the boring parts :)    --- Quote Start ---   If you have any questions on the high speed operation like 10GE, let me know.   --- Quote End ---  I will, thanks!  Cheers, Dave

[Altera_Forum]

--- Quote Start ---  Hi Rick,  Ok, so the lock-to-reference and lock-to-data modes would be needed.  You can configure the Stratix IV GX transceivers as manual or automatic. The Stratix II GX might be different, I have not looked at their data sheets.  Given that you control the preamble, it should be possible to make it work.  Listen to the transceiver webinar on the Altera web site. I think its the 2.5hr one. It has a nice overview of all the transceiver features.  Lets see if I can find it:  This one is 0.5 hrs: http://www.altera.com/education/training/courses/osiigx1115  This one is 2.5 hrs: http://www.altera.com/education/training/courses/o40nm1110  I'm pretty sure these both had comments on LTD and LTR modes. Just skip the boring parts :)  I will, thanks!  Cheers, Dave  --- Quote End ---    Thanks Dave, I will check them out. As far as I know, the FPGA is not good to work in burst mode (i mean it need long to lock. I tested the stragix ii gx transceivers, from poweron to plllock - 41.28us, from rx_analogrest to rx_pll 30us and to rx_lockfreq need another 419.59us: you know it's really terrible).  I have no idea how it has been improved in the stratix iv or higher. But it seems it performs pretty good in your case!  Thanks.   Rick

[Altera_Forum]

Hi Rick, 

   --- Quote Start ---   As far as I know, the FPGA is not good to work in burst mode (i mean it need long to lock. I tested the stragix ii gx transceivers, from poweron to plllock - 41.28us, from rx_analogrest to rx_pll 30us and to rx_lockfreq need another 419.59us: you know it's really terrible).   --- Quote End ---  Those parameters are of interest for the system design. But they are not the timing parameters you really care about for your original question (as I see it anyway).  What you want to know is; given that the CDR PLLs are locked to the PLLREF clock, how long does it take for the CDR PLL to determine that an incoming data pre-amble is sufficient for lock-to-data to occur? Once LTD has occurred, you can switch over to using the recovered clock, and the CDR can recover real data.  See if you can determine that timing parameter.  Cheers, Dave