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

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

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