li hongming authored Nov 19, 2023 and Maciej Lipinski committed Dec 04, 2023

Needs to be coupled with a relevant GW change

Apparently, this is helpful for WRS-FL v1.5. Explanation from Hongming:

    From: hongming
    Sent: 30 November 2023 01:24
    To: Maciej Marek Lipinski
    Subject: 回复： Re:WRS-FL integration into next WRS firmware release

    hi maciej

    > we do not fully see/understand how changing g_reverse_dmtd to false
    > could help in the problem you described. We need to discuss this change
    > (which is quite serious) before proceeding

    As you may see, we've changed the VCXO of helper PLL in new HW.
    There are two search direction for PLL, corresponding to two frequency
    relation between help clock and main/ext clock.
    As far as I remember, if the frequency of help clock is higher than
    main/ext clock, it should use help clock sampling main/ext clock, while
    if if the frequency of help clock is lower than main/ext clock, it should
    do the opposite.
    In our actual test, the actual frequency of VCXO may be slower than the
    claimed frequency. The help VCXO cannot reach the supposed value if we
    require the frequency of help clock to be higher than main/ext clock.
    What we observed it that in previous settings, the dac output of help
    clock reaches to be 64000+ when the dac output of main clock is 30000.
    After changing the g_reverse_dmtd and searching direction of help PLL,
    the dac output of help clock reaches to be 16500+ when the dac output
    of main clock is 30000.

    When we look at the hardware implementation to find out the reason, we
    have the following information:
    - We choose VCXO with a pull range of +-100ppm, without considerating
      the frequency statbility, making the actual APR to be only +-45ppm.
    - What's worse is that the Supply Voltage of VCXO is 3.3V and our DAC's
      maximun output is 2.5V.
    In current WR implementation, N=16384, which means that we need a VCXO
    with APR of 61ppm.