I'm connecting a V2Pro Rocket IO to a Agilent optical interface and am having problems getting the RocketIO receiver to reset properly and generate the correct data. The design originally used a Vitesse serial<->parallel interface chip and that worked fine. Since we have a spare RocketIO, we'd like to use it instead of the Vitesse chip. I'm running the link at 1062.5 Gbit/sec, so the reference clock for the RocketIO is 53.125MHz. Because of the optical protocol I'm talking to, I can't use clock correction, so I'm using the RXRECCLK to clock data+K_codes out of the RocketIO. Since RXRECCLK runs at the bit_rate/20, I'm using a 2 byte wide receiver interface. The problem I'm seeing is the receiver does not appear to reset and lock to the data source properly. My reset state machine looks for bad K codes and some other problems, and if needed, it generates a long reset signal to the ROcketIO receiver, then waits a while for it to come back to life. Unfortunately, the RocketIO does not appear to reset correctly. I'll see bad K codes and other garbage. If I disconnect the optical link, then reconnect it, I'll sometimes be able to get reasonable info out of the RocketIO. To generate the 53.125MHz reference clock, I'm dividing a high quality 106.25MHz reference clock in the FPGA to drive the RocketIO. Anyone have any hints? Thanks! John Providenza
Xilinx RocketIO receiver reset problem
Started by ●June 22, 2006
Reply by ●June 22, 20062006-06-22
Of course, 5 minutes after I posted the message I found the answer. I was never asserting the ENPCOMMAALIGN signal to the RocketIO, so it never really appeared to sync to the incoming data stream. It now looks OK. John P johnp wrote:> I'm connecting a V2Pro Rocket IO to a Agilent optical interface and > am having problems getting the RocketIO receiver to reset properly > and generate the correct data. The design originally used a Vitesse > serial<->parallel interface chip and that worked fine. Since we have > a spare RocketIO, we'd like to use it instead of the Vitesse chip. > > I'm running the link at 1062.5 Gbit/sec, so the reference clock for > the RocketIO is 53.125MHz. Because of the optical protocol I'm > talking to, I can't use clock correction, so I'm using the RXRECCLK > to clock data+K_codes out of the RocketIO. > > Since RXRECCLK runs at the bit_rate/20, I'm using a 2 byte wide > receiver interface. > > The problem I'm seeing is the receiver does not appear to reset > and lock to the data source properly. My reset state machine looks > for bad K codes and some other problems, and if needed, it generates > a long reset signal to the ROcketIO receiver, then waits a while for > it to come back to life. > > Unfortunately, the RocketIO does not appear to reset correctly. I'll > see bad K codes and other garbage. If I disconnect the optical link, > then reconnect it, I'll sometimes be able to get reasonable info out > of the RocketIO. > > To generate the 53.125MHz reference clock, I'm dividing a high quality > 106.25MHz reference clock in the FPGA to drive the RocketIO. > > Anyone have any hints? > > Thanks! > > John Providenza
Reply by ●June 25, 20062006-06-25
Thanks for posting the answer - so many do not bother. cheers, /MikeJ> Of course, 5 minutes after I posted the message I found the answer. > > I was never asserting the ENPCOMMAALIGN signal to the RocketIO, > so it never really appeared to sync to the incoming data stream. > > It now looks OK. > > John P > >