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
[USRP-users] N3xx operational questions
Hi All, I've been working with the N3xx series for a week or so and I've hit a few issues in the "operational" side of things that are either not addressed in the manual or work differently than expected. I'll just handle this as a "laundry list" of items/issues... To start, I've been directly testing on the N300 so far. I reflashed the N300 SD card with version UHD-3.13.02 last week. 1. As a heads up, and I'm sure you're aware, I've had a fair bit of trouble coordinating the uhd_images_downloader with the correct images... First, when I originally built UHD-3.13.0.0 as described in the manual, there's no images provided for 3.13.0.0. I just noticed today that if I update to UHD-3.13 branch (currently 3.13.0.3) and run the downloader, it tries to pull images for 3.13.0.2, which is likely incompatible with the 3.13.0.3 head (noc shell seems to be updated to version 3 in the most recent 3.13.0.3). 2. I keep running into a number of issues trying to download new FPGA images. Could someone explain the mechanics of FPGA loading for N3xx? I'm assuming this is similar to X310, however I would have expected that a zynq-based platform would simply program to /dev/xdevcfg like the E310. More tactically, I have a few issues when trying to download FPGA images. If I run a "host mode update", then I get an unexpected error: ``` $ uhd_image_loader --args "type=n3xx,addr=10.1.151.245" --fpga-path=n3xx.bit [INFO] [UHD] linux; GNU C++ version 7.3.0; Boost_106501; UHD_3.13.0.3-14-gd1555232 [INFO] [MPMD] Initializing 1 device(s) in parallel with args: mgmt_addr=10.1.151.245,type=n3xx,product=n300,serial=3145FF4,claimed=False,skip_init=1 [INFO] [MPMD] Claimed device without full initialization. [WARNING] [MPMD IMAGE LOADER] RuntimeError: Component file does not exist: /home/ejk/fpga-build/he360-fpga-builder/src/uhd-fpga/usrp3/top/n3xx/build-N300_RFNOC_HG/n3xx.dts [INFO] [MPMD IMAGE LOADER] Starting update. This may take a while. [ERROR] [UHD] An unexpected exception was caught in a task loop.The task loop will now exit, things may not work.rpc::timeout: Timeout of 5000ms while calling RPC function 'get_log_buf' [INFO] [MPM.PeriphManager] Device serial number: 3145FF4 [INFO] [MPM.PeriphManager] Initialized 1 daughterboard(s). [INFO] [MPM.PeriphManager] init() called with device args `'. Error: rpc::timeout: Timeout of 2ms while calling RPC function 'update_component' ``` Fortunately, this error appears that it doesnt materially impact anything, and I can now probe the FPGA successfully afterwards. When trying to load FPGA images in embedded mode, first, I get an error when running uhd_images_downloader that suggests argparse is not installed into the rootfs: ``` root@ni-n3xx-3145FF4:~# uhd_images_downloader Traceback (most recent call last): File "/usr/bin/uhd_images_downloader", line 11, in import argparse ImportError: No module named argparse ``` Oddly, pip3 seems to be installed, and I can run `pip3 install argparse` but there's no pip or python2 argparse :( Anyway, if I scp a relevant image onto the N300 PS, I get a similar issue as over network mode. At one point, I found fpga programming in embedded mode crashed the N300 and require a hard reboot, but I cant recreate that right now so I'll leave that off my list. 3. Embedded mode vs host/network mode: Ideally, I would like to run the N3xx using both a high rate ethernet connection through the sfp's, and a connection to the Zynq PS over the RJ45. (not at the same time from the same program, but both ports physically connected)... However, I cannot succeed in switching between embedded mode and host mode without 1) physically unplugging the ethernet cables, or 2) taking down the IP interface that I'm not using at the moment. Is there a way to do this?? To give a specific example of behavior I see, I've set up the N300 to boot with 1GigE connection on sfp0 and RJ45 on the eth0. From a host device, in network mode, I fail to probe the N300: ``` $ uhd_usrp_probe --args "type=n3xx" [INFO] [UHD] linux; GNU C++ version 7.3.0; Boost_106501; UHD_3.13.0.HEAD-0-g0ddc19e5 [INFO] [MPMD] Initializing 1 device(s) in parallel with args: mgmt_addr=10.1.151.60,type=n3xx,product=n300,serial=3145FF4,claimed=False,addr=10.1.151.245 [INFO] [MPM.PeriphManager] init() called with device args `mgmt_addr=10.1.151.60,product=n300'. [ERROR] [UHD] Exception caught in safe-call. in ctrl_iface_impl<_endianness>::~ctrl_iface_impl() [with uhd::endianness_t _endianness = (uhd::endianness_t)0] at /home/ejk/prefix/gnuradio-default/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:60 this->send_cmd_pkt(0, 0, true); -> EnvironmentError: IOError: Block ctrl (CE_00_Port_30) no response packet - AssertionError: bool(buff) in uint64_t ctrl_iface_impl<_endianness>::wait_for_ack(bool, double) [with uhd::endianness_t _endianness = (uhd::endianness_t)0; uint64_t = long unsigned int] at /home/ejk/prefix/gnuradio-default/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:154 [ERROR] [MPMD] Failure during bloc
[USRP-users] rfnoc "graphs"
Hi, I'm looking for little more information on rfnoc graphs. I see in the rfnoc examples that you call the device3 create_graph function and then use the resulting pointer to connect blocks. Here are a few questions I have, but any info on the concepts would be helpful. - Can I create multiple graphs? I see that each graph is "named" at creation. What happens if there are multiple graphs? - It appears that I can't get outside access to a previously created graph in order to add to it. there is only the create_graph function. is this understanding correct? - What does the device3 clear function do with respect to graphs? Does it clear all previously "created" graphs and disconnect all of the previous connections? Thanks. Rob ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
