> > Your suggestion seems to: > > a. Assume that the required period should be in ns, not in > > 16*ns units. > > b. mishandles the +8/-8 in the calculation. > > c. Doesn't seem to consider the upper bound on period. > > Duh, you would have to convert the result into the proper form for the HW > register and add bounds checking. I mean, that goes without saying. > The important fact is that your algorithm it not optimal for ppm < 60.
Your algorithm ignores the HW limitation. Consider (ppb == 1): your logic would output N == 7, *M == 7000000000, Which has perfect accuracy [N / *M is 1 / 10^9]. But the solution for 'period' * 16 + 8 == 7 * 10^9 isn't a whole number, so this result doesn't really reflect the actual approximation error since we couldn't configure it to HW. The original would return val == 1, period == 62499999; While this does have some error [val / (period * 16 + 8) is slightly bigger than 1 / 10^9, error at 18[?] digit after dot], it's the best we can configure for the HW. One simple adjustment we could do is simply break from the loop If 'diff == 0'. At least for small PPB value this would be hit relatively quickly. > > One thing I still don't get is *why* we're trying to optimize this > > area of the code - > > So you prefer using 21 64-bit divisions when using 8 produces better results? No. In an ideal world, I would have liked optimizing everything. But in this world if I do find time to spend on optimizations I rather do that for the stuff that matters. I.e., datapath.
