Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
15 years ago

ALTLVDS CoreClk with Odd Deserialization Factors

Hello.

I am trying to configure an instantiation of an FPD-Link transmitter using the ALTLVDS megafunction and am getting confused by one particular property.

In table 5 of the user manual for ALTLVDS it states:

"For example, if tx_inclock signal is connected to a 500 MHz input reference clock, and the parallel data rate is not 500 MHz, register the parallel data using the tx_coreclock signal that runs at the output serial data rate divided by the

deserialization factor. this frequency matches the parallel data rate from the fpga core."

I would take from this that Core Clock then is the clock that is used to clock the parallel data from the pre-register into the function block, as indicated in the diagram by the little DFF symbol clocked by tx_inclock.

The problem is that whenever the deserializtion factor is odd CoreClk is half what it should be.

E.g. If the data rate for each channel is 840mb/s with a deserialization factor of four then CoreClk must be 210MHz, and it is.

But if I change the deserialization factor to 7 it becomes 84MHz, when it should be 168.

If I enable the CoreClk output and simulate it, it is indeed running slower than my parallel data should supposedly be.

While in my simulation with the pre-register connected to inclock there appears to be no data loss I don't really understand why, since surely CoreClk is clocking data in from THAT at half the rate it should be?

Could someone please explain where i've gone wrong in my understanding of CoreClk and how it works?

2 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    15 years ago

    Hi Sebastion,

    Which FPGA do you use? Some families (like Cyclone III) have dual datarate input circuits, so that could be the reason for the frequency you mention. But that doesn't explain the odd/even difference.

    In general, if you can avoid an odd serialization factor, do so. I've had a lot of trouble with it. See some recent theads at this forum. If you are sticked to an odd (de)serialization, at least do not use RAM as a buffer (tab 2 or 3 of the MegaWizard).

    Succes, Ton
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    15 years ago

    Hi std_logic_vector, thank you for your reply.

    I am building for the Cyclone III and was not aware that it had that circuitry and so that is probably it, since imnmy simulation it was working even though I could not determine why.

    Unfortunately the FPD-Link specification requires 3 channels with a deserialization factor of 7 and so it must be odd, but it is simulating correctly as far as I can tell and so I am glad I now know why.

    (If I do run into any more problems are are also FPD-Link IP Cores so I may try one of those)

    Thanks for the tip about the RAM buffer, I'll see if I cant figure out how to disable its use. (This is the first time ive used ALTLVDS so Im just learning my way around it)