DDMTD: disable reverse option, it needs to be coupled with relevant changes to wrpc-sw

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.