ALT2GXB rx_pll_locked

Question

All,

I'm having a bit of a struggle with the ALT2GXB instance. I have included in my ALT2GXB variation the rx_locktorefclk and rx_locktodata input ports. According to the Stratix II GX user manual, driving rx_locktorefclk to 1 and rx_locktodata to 0 should force the receiver PLL to lock to the reference clock.

Under this circumstance, the user manual indicates that rx_pll_locked should remain asserted indicating that the PLL is locked to the reference clock. When the ALT2GXB instance is configured to lock to data, the rx_pll_locked output will wander.

Now in my case, the rx_pll_locked is not staying asserted. The input data to the receiver is SD SDI video at 270Mbps. The receiver deserializer is configured to run at 2970Mbps for an oversampling rate of 11x. When the data pattern is a colorbar signal transmitted using the same reference clock, I have no problem. The rx_pll_locked signal remains asserted. However, when the data pattern is a pathological signal (a signal containing the maximum consecutive number of 1's or 0's allowed by the protocol) the rx_pll_locked signal wanders. This also occurs when the signal comes from some other source that does not use the same reference clock. This behavior leads me to believe that the PLL is actually trying to recover the clock from the data rather than locking to the reference clock.

It appears to be ignoring my rx_locktorefclk and rx_locktodata inputs.

Any ideas? I've been working on this one for a few days now.

Thanks,

Jake

altera_forum · Answer

All,

Problem solved. The rx_locktorefclk input was being ignored. Apparently the setting that instructs the transceiver to use the rx_locktorefclk input is part of the MIF reconfiguration file. I do reconfiguration in my design and I was using an old MIF file (prior to adding the rx_locktorefclk port to my ALT2GXB variation). I had assumed that the port was a hardware only setting.

Anyway, after updating my MIF file, the rx_locktorefclk input is acknowledged and the rx_pll_locked output behaves as expected.

A priceless new piece of knowledge at least.

Jake

altera_forum · Answer

Interesting.  I would have guessed it was hard-wired too.  When you select the locktorefclk, do you still get data?  My thought was that you'd receive bad data when locked to that, and that might be a secondary check on whether these control signals are actually doing anything.  I guess it doesn't matter since you figured it out.

altera_forum · Answer

Rysc,

Yes what drove me to this level of debugging was the fact that I was not able to recover the SD-SDI data stream. The core would still output data but because the clock was wandering, I couldn't make use of it (as the 11x oversampler expects a fixed clock). I initially targeted my oversampler believing the problem to be there.

Jake

altera_forum · Answer

hallo,

i read this thread and actually in my design i am using the altgx_reconfig block. When i read that you had updated your .mif file i thought i could ask this question in this thread:

how can i update my .mif file?

regards

altera_forum · Answer

The configuration for you transceiver is automatically created when you compile your project in Quartus. If you want Quartus to give you the "memory initialization file" (MIF) that represents enable the option in Quartus. It will then give you the MIF files during compilation. When I said I updated my MIF file. I meant that I was using an out-of-date MIF file for reconfiguring the transceiver. I had since changed the transceiver settings and needed to use the newer MIF file for reconfiguration.

Jake

Forum Discussion

ALT2GXB rx_pll_locked

7 Replies

Recent Discussions

GTS SDI II IP Core...what is the tx_vid_clkout frequency

Behavior of 10 GX Avalon-MM Interface for PCI Express* IP Core when byteenable=16'h0000

Does AXI Multi-Channel DMA IP support CvP ?

Request for private case.

MAX10 TSE reference design