Re: [USRP-users] n3xx master clock rate selection
EJ,
Great news! I've also filed a feature request for the 120MHz MCR to keep
things moving on that front. I'm glad you found an intermediate solution!
-Daniel
On Wed, Oct 24, 2018 at 5:07 PM EJ Kreinar wrote:
> Hi Daniel and others interested,
>
> To follow up on our discussion: I ended up making a "quick and dirty"
> rfnoc block to do rational resampling (integer upsample, fractional
> downsample). It's implemented by simply repackaging the existing duc and
> ddc blocks into a new combined noc_block. I've tested the FPGA and software
> targeting the n3xx and I can now hit my target rates of 2, 3, 6, & 10 MHz.
>
> I'm planning to use this block for now, and in case anyone else is
> interested I set up a couple PRs for the changes:
> - uhd: https://github.com/EttusResearch/fpga/pull/32/commits
> - fpga: https://github.com/EttusResearch/uhd/pull/219/commits
> - gr-ettus: https://github.com/EttusResearch/gr-ettus/pull/29/commits
>
> Cheers!
> EJ
>
> On Thu, Oct 18, 2018 at 5:56 PM EJ Kreinar wrote:
>
>> 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 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 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 m
Re: [USRP-users] n3xx master clock rate selection
Hi Daniel and others interested,
To follow up on our discussion: I ended up making a "quick and dirty" rfnoc
block to do rational resampling (integer upsample, fractional downsample).
It's implemented by simply repackaging the existing duc and ddc blocks into
a new combined noc_block. I've tested the FPGA and software targeting the
n3xx and I can now hit my target rates of 2, 3, 6, & 10 MHz.
I'm planning to use this block for now, and in case anyone else is
interested I set up a couple PRs for the changes:
- uhd: https://github.com/EttusResearch/fpga/pull/32/commits
- fpga: https://github.com/EttusResearch/uhd/pull/219/commits
- gr-ettus: https://github.com/EttusResearch/gr-ettus/pull/29/commits
Cheers!
EJ
On Thu, Oct 18, 2018 at 5:56 PM EJ Kreinar wrote:
> 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 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 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
Re: [USRP-users] n3xx master clock rate selection
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 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 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
Re: [USRP-users] n3xx master clock rate selection
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 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 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
Re: [USRP-users] n3xx master clock rate selection
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 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 re
Re: [USRP-users] n3xx master clock rate selection
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 th
Re: [USRP-users] n3xx master clock rate selection
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
[USRP-users] n3xx master clock rate selection
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
