Hi Scott,
Thanks for the pointers! I actually tried making these changes this
afternoon... This is what I came up with for the LMK table (it appears the
sysref_divider wants to be 500 for this rate based on the other
calculations):
```
clkout_divider = {120e6: 25, 122.88e6: 25, 125e6: 24, 153.6e6: 20}
pll1_n_divider = {120e6: 125, 122.88e6: 128, 125e6: 125, 153.6e6: 128}
sysref_divider = {120e6: 500, 122.88e6: 500, 125e6: 480, 153.6e6: 400}
pll2_prescaler = {120e6: 5, 122.88e6: 2, 125e6: 5, 153.6e6: 2}
pll2_n_divider = {120e6: 25, 122.88e6: 64, 125e6: 25, 153.6e6: 64}
```
And then the obvious changes in ad937x_device::set_master_clock_rate. As
expected, some plumbing was required in both magnesium.py and tdc_sync.py
to allow a 120MHz master clock rate.
The next roadblock comes down to the JESD configuration, specified here:
https://github.com/EttusResearch/uhd/blob/master/mpm/python/usrp_mpm/dboard_manager/mg_init.py#L249
... And the JESD configuration is probably where I'm going to leave it for
now, since this configuration now appears to involve potentially generating
IP and calculating more magic numbers. Hope this can help anyone else
looking down this path to this point.
I'm not a fan of the "fixed" fractional resampler from xilinx. Since I'm
looking at going through the effort of a new noc_block spinup anyway, I
would much prefer something programmable. I think I'll chase down the
"noc_block_fractional_resampler" instead and see where that leads.
Cheers,
EJ
On Thu, Oct 18, 2018 at 3:41 PM Daniel Jepson via USRP-users <
usrp-users@lists.ettus.com> wrote:
> EJ,
>
> We are continuing to investigate the rate selection and possibility of
> adding 120 MHz as an MCR option. Our initial choices were (in large part)
> driven by the available options and example code provided through their
> evaluation software. It appears there is leeway in choosing MCRs, although
> anything lower than 122.88 MHz will begin sacrificing BW. The JESD204b core
> throughput requirements must typically match exactly the data rates inside
> the AD9371, so it is simply a matter of configuring both the AD9371 and the
> FPGA with the correct parameters (nothing seems too impossible, just work
> to be done). Note there is a difference between the DEVCLK (reference
> clock) input to the AD9371 and the actual sampling rate inside the device.
> To facilitate synchronization, we match the reference clock rate to the
> actual sampling rate.
>
> To get you going in the mean time, Xilinx provides a free, fixed
> fractional resampler through the FIR Compiler that might be helpful and is
> fairly lightweight. It's AXI-Stream, so building it into the signal path
> shouldn't be too difficult.
>
> I'll report back when we have more information on the 120 MHz feature
> request.
>
> -Daniel
>
> On Wed, Oct 17, 2018 at 7:46 PM EJ Kreinar <ejkrei...@gmail.com> wrote:
>
>> So, I'm trying to understand the fundamental clock rate selection
>> limitations for the 9371... From what I understand, this is plausibly due
>> to some limitations of the JESD interface (?).
>>
>> This wiki answer suggests possible rates of 122.88M, 153.6M, 184.32M,
>> 245.76M, or 307.2M:
>> https://ez.analog.com/wide-band-rf-transceivers/design-support-ad9371/f/q-a/100289/ad9371-sync-clock-frequencies
>>
>> Then the 9371 datasheet also shows example rates of 122.88, 153.6,
>> 245.76, and 307.2 MHz: https://www.analog.com/en/products/ad9371.html
>>
>> So how is it that there's a master clock rate at 125MHz??
>>
>> EJ
>>
>> On Wed, Oct 17, 2018, 5:49 PM EJ Kreinar <ejkrei...@gmail.com> wrote:
>>
>>> Hi Daniel,
>>>
>>> Sad to hear that! By the way, I forgot to mention another important rate
>>> I need, 3 MHz, that also has an integer relationship to 120 MHz... Perhaps
>>> I'd like to make a formal feature request for 120 MHz master clock?? It
>>> strikes me as odd that so many of the "whole number" MHz sample rates are
>>> neglected on the n3xx series by default-- it's often the case that I'll
>>> want to interact with other hardware with baud rates at, say, 2 MHz or 10
>>> MHz or something, but I just don't have the fpga-based fractional
>>> conversions onhand right now...
>>>
>>> I'm certainly not afraid of nontrivial changes, so if the AD9371
>>> supports a clock rate that can give me these derived sample rates, I really
>>> see this as the best solution since other platforms can already achieve
>>> these rates without extra user-space processing requirements.
>>>
>>> However, if needed, potentially a "quick and dirty" approach might be to
>>> make an rfnoc fractional resampler that combines a DUC and DDC into one
>>> "ce", with a block controller to calculate the magical conversions... It's
>>> not an optimal solution but it might do the trick here. Anyone else
>>> interested in such an fpga-based fractional resampler?
>>>
>>> EJ
>>>
>>> On Wed, Oct 17, 2018, 1:52 PM Daniel Jepson via USRP-users <
>>> usrp-users@lists.ettus.com> wrote:
>>>
>>>> Hi EJ,
>>>>
>>>> The fundamental limitation comes from the AD9371. Although the
>>>> datasheet specifies a wide reference clock input range, there are only
>>>> certain supported rates within the public side of their API (at least that
>>>> I'm aware of). These include the rates you mentioned from the KB.
>>>>
>>>> Assuming the AD9371 allows it, adding a new MCR is not trivial and
>>>> would require a good deal of work across hardware, FPGA code, and MPM. The
>>>> fractional resampler sounds like a much better path forward, albeit
>>>> difficult right now.
>>>>
>>>> Hopefully that explains some of the background on the chosen MCRs.
>>>> Sorry it wasn't exactly what you were hoping for!
>>>>
>>>> -Daniel
>>>>
>>>> On Wed, Oct 17, 2018 at 10:50 AM EJ Kreinar via USRP-users <
>>>> usrp-users@lists.ettus.com> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> I'm working on an FPGA application on the n310/n300, and I'm bumping
>>>>> into a limitation of the master_clock_rate selection.... I'd like to be
>>>>> able to use sample rates in the FPGA of 2 MHz, 4 MHz, and 10 MHz, but none
>>>>> of these values are integer multiples of the supported rates (122.88e6,
>>>>> 125e6, 153.6e6 -- from here:
>>>>> https://kb.ettus.com/N300/N310_Getting_Started_Guides#Supported_Sample_Rates).
>>>>> This causes a problem in the FPGA since I would need a fractional
>>>>> resampler, which I dont currently have, unfortunately.
>>>>>
>>>>> What's the fundamental limitation of these master clock rates? I would
>>>>> have assumed that the AD9371-based architecture would have resulted in a
>>>>> wider variety of plausible clock rates, similar to the AD9361 on the E310.
>>>>> I havent found these limits yet in the software or FPGA, so any pointers
>>>>> where to look would be appreciated.
>>>>>
>>>>> As a follow up question, how feasible would it be to add a master
>>>>> clock rate of 120 MHz?? Any ideas where to make these changes? This would
>>>>> answer the mail for my sample rates of interest right now.
>>>>>
>>>>> Thanks!
>>>>> EJ
>>>>> _______________________________________________
>>>>> USRP-users mailing list
>>>>> USRP-users@lists.ettus.com
>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Daniel Jepson
>>>>
>>>> Digital Hardware Engineer
>>>>
>>>> National Instruments
>>>>
>>>>
>>>>
>>>> O: +1.512.683.6163
>>>>
>>>> daniel.jep...@ni.com
>>>> _______________________________________________
>>>> USRP-users mailing list
>>>> USRP-users@lists.ettus.com
>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>
>>>
>>> On Wed, Oct 17, 2018, 1:52 PM Daniel Jepson via USRP-users <
>>> usrp-users@lists.ettus.com> wrote:
>>>
>>>> Hi EJ,
>>>>
>>>> The fundamental limitation comes from the AD9371. Although the
>>>> datasheet specifies a wide reference clock input range, there are only
>>>> certain supported rates within the public side of their API (at least that
>>>> I'm aware of). These include the rates you mentioned from the KB.
>>>>
>>>> Assuming the AD9371 allows it, adding a new MCR is not trivial and
>>>> would require a good deal of work across hardware, FPGA code, and MPM. The
>>>> fractional resampler sounds like a much better path forward, albeit
>>>> difficult right now.
>>>>
>>>> Hopefully that explains some of the background on the chosen MCRs.
>>>> Sorry it wasn't exactly what you were hoping for!
>>>>
>>>> -Daniel
>>>>
>>>> On Wed, Oct 17, 2018 at 10:50 AM EJ Kreinar via USRP-users <
>>>> usrp-users@lists.ettus.com> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> I'm working on an FPGA application on the n310/n300, and I'm bumping
>>>>> into a limitation of the master_clock_rate selection.... I'd like to be
>>>>> able to use sample rates in the FPGA of 2 MHz, 4 MHz, and 10 MHz, but none
>>>>> of these values are integer multiples of the supported rates (122.88e6,
>>>>> 125e6, 153.6e6 -- from here:
>>>>> https://kb.ettus.com/N300/N310_Getting_Started_Guides#Supported_Sample_Rates).
>>>>> This causes a problem in the FPGA since I would need a fractional
>>>>> resampler, which I dont currently have, unfortunately.
>>>>>
>>>>> What's the fundamental limitation of these master clock rates? I would
>>>>> have assumed that the AD9371-based architecture would have resulted in a
>>>>> wider variety of plausible clock rates, similar to the AD9361 on the E310.
>>>>> I havent found these limits yet in the software or FPGA, so any pointers
>>>>> where to look would be appreciated.
>>>>>
>>>>> As a follow up question, how feasible would it be to add a master
>>>>> clock rate of 120 MHz?? Any ideas where to make these changes? This would
>>>>> answer the mail for my sample rates of interest right now.
>>>>>
>>>>> Thanks!
>>>>> EJ
>>>>> _______________________________________________
>>>>> USRP-users mailing list
>>>>> USRP-users@lists.ettus.com
>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Daniel Jepson
>>>>
>>>> Digital Hardware Engineer
>>>>
>>>> National Instruments
>>>>
>>>>
>>>>
>>>> O: +1.512.683.6163
>>>>
>>>> daniel.jep...@ni.com
>>>> _______________________________________________
>>>> USRP-users mailing list
>>>> USRP-users@lists.ettus.com
>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>
>>>
>
> --
>
> Daniel Jepson
>
> Digital Hardware Engineer
>
> National Instruments
>
>
>
> O: +1.512.683.6163
>
> daniel.jep...@ni.com
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
