What version of UHD are you trying to use?
I'm not a python expert, but I think in UHD 3.15 and earlier, there isn't
support for the RFNoC API in Python, just MultiUSRP. Hopefully someone will
correct me if I'm wrong. The RFNoC API is exposed for Python in UHD 4.0.
Either version should work with
Rob,
Thanks for the feedback! I like your suggestions. In fact, the bypass
option is one that we've discussed a few times, since it would be very
useful for debug and would allow some blocks to be statically routed that
currently use the crossbar. We definitely want to make things easier for
Hi Julian,
There is an AXI4-Lite to CtrlPort bridge, but I don't think there's a
CtrlPort to AXI4-Lite bridge, which I think is what you need. You can of
course write your own. A basic bridge would be pretty simple. You can take
a look at the AXI4-Lite to CtrlPort bridge here:
Just to clarify the issue, ce was correct for other targets, it just
doesn't work on E-series, which is an oversight in the getting started
guide. Changing it to rfnoc_chdr is a good solution for E310.
Thanks,
Wade
On Thu, Feb 18, 2021 at 7:54 AM Aaron Rossetto via USRP-users <
Hi,
I suggest you take a look at the addsub RFNoC block, which uses a simple
HLS module.
https://github.com/EttusResearch/uhd/blob/master/fpga/usrp3/lib/rfnoc/blocks/rfnoc_block_addsub/rfnoc_block_addsub.v
In that block, I think they just pull in the HDL code generated by the HLS
tool, but I
Hi Mark,
This is curious. If I recall, someone else was having trouble with -g, but
it worked for me last time I tried it. I will try it again to see if I can
reproduce anything. In the meantime, you can run rfnoc_image_builder and
make in separate steps. See if this works:
# Generate the build
I like your first idea. To get rid of the warning, I think your block just
needs to finish the last packet cleanly on each output port (i.e., TLAST
needs to be asserted on the last word written to the NoC shell). The second
idea will probably work too, but it won't necessarily get rid of the
I believe RFNoC tries to flush any partially transmitted packets out of
blocks during initialization before resetting them. The idea is to get rid
of any leftover data that might still be in the data pipes. I think a
timeout means the noc_shell never saw the end of the last packet before the
Yes, I have done it. I'll share an example with you. Putting your IP
in-tree is also an option.
Thanks,
Wade
On Thu, Jan 21, 2021 at 5:01 PM Cédric Hannotier via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Dear all,
>
> On 08/01/21 18:58, Cédric Hannotier via USRP-users wrote:
> > Dear
I believe the SPP argument can also affect the transmit SPP. If you call
tx_streamer.send() with buffers larger than SPP, then it will split them
into SPP-sized packets. tx_streamer.get_max_num_samps() should return the
currently configured SPP.
Wade
On Fri, Jan 15, 2021 at 8:06 AM Ephraim
See also
https://files.ettus.com/manual/page_configuration.html#config_stream_args_args
You might also refer to the benchmark_rate example, which takes arguments
to set the SPP for RX and TX separately.
Wade
On Wed, Jan 13, 2021 at 11:21 AM Marcus D Leech via USRP-users <
I don't think the streamer changes the packet size. I believe what the
block sends is what goes out on the wire (plus network headers). I wonder
if the size is not being set correctly by the block, or maybe the way
you're checking the length isn't looking at the actual packet size? That's
why I
Hi Cédric,
You can probably just call $finish() instead of test.end_tb() to stop the
simulation in both CLI and GUI modes. If you want the summary at the end,
take a look at what end_tb() does in PkgTestExec.sv. Also, note that the
test object isn't required. You can remove all the test calls
The block ultimately determines the size of the packets that are sent out.
Some block controllers (like the radio) use the spp argument to set the
length that the block generates. I don't know what's going on in your case,
but I would suggest looking at how the packet length is being controlled by
Hi Ofer,
The Replay block should work fine with E320. It was reverted because the
DMA FIFO was needed in the default image. You can customize and build your
own FPGA images if you need something custom.
Thanks,
Wade
On Sat, Jan 9, 2021 at 12:30 PM Ofer Saferman via USRP-users <
Hi Cédric,
I'll attempt to answer your questions. I'm more familiar with the
hardware/HDL side of things.
1. The default clock for rfnoc blocks is rfnoc_chdr_clk and this clock is
always present. You can use this clock for everything, unless you need a
different clock (e.g., a faster clock to
It's not specific to N3xx. It can occur when you use the same bitstream and
change the crossbar routing between runs.
Wade
On Wed, Dec 16, 2020 at 4:42 PM Rob Kossler wrote:
> Thanks Wade,
> That fixes it for my test case with 2 switchboards in series. I'll let
> you know if I see anything
Rob,
I think I found the source of the IQ swap issue you observed. This fixes it
for me:
diff --git a/host/lib/rfnoc/mgmt_portal.cpp b/host/lib/rfnoc/mgmt_portal.cpp
index a54efaaf7..7b09c540b 100644
--- a/host/lib/rfnoc/mgmt_portal.cpp
+++ b/host/lib/rfnoc/mgmt_portal.cpp
@@ -617,6 +617,24 @@
Hi Rob,
I was able to reproduce the issue, so I'll see if I can get to the bottom
of it. I'm glad you're able to work around it for now. Thanks for letting
us know about it!
Wade
On Mon, Dec 14, 2020 at 8:59 AM Rob Kossler wrote:
> Hi Wade,
> I tried the command to re-load the FPGA, but I
Thanks for the updates. If you just want to reload the FPGA, try running
"overlay rm n310 && overlay add n310" on the N310. This should simply
reload the FPGA using the bistream already in the flash.
Wade
On Fri, Dec 11, 2020 at 6:45 PM Rob Kossler wrote:
> Wade,
> The following also fails
Hi Rob,
The SEPs do have the ability to swap I and Q. This is because on the host
computer, I is usually in the lower bits and Q is in the upper bits of each
32-bit word, but in RFNoC, for historical reasons, I goes in the upper bits
and Q in the lower bits. The software programs the IQ swapping
Hi Maria,
I think you need to change the dstport on line 86 to from x300_radio to
radio_iface. When there are unresolved connections, the tool outputs the
list of connections available. The one you want is (('radio0',
'radio_iface', 'slave'),). You can also check the port name in the
Hi Dario,
The generation of the IP should be the same in tree and out of tree, so it
is strange that the netlist simulation file isn't generated for you. I'd
like to try it to see if I get that behavior, but I'm currently traveling
so it might be a while before I am able to.
I wanted to let you
Hi Nick,
Maybe others will chime in but I'll share what I know. The intent was to
have a new block tool that would generate Verilog and C++ templates for a
complete block, but it wasn't completely finished for the UHD 4.0 release.
It currently generates all the HDL, but register generation and
Yes, that's correct. There's a radio_1x64.yml you can use to get a single
channel radio. You might consider removing the FIFO if you don't need it.
Wade
On Tue, Nov 24, 2020 at 8:46 AM Maria Muñoz via USRP-users <
usrp-users@lists.ettus.com> wrote:
>
>
> -- Forwarded message -
>
Hi Dario,
I'm not sure why you're getting that error. Your initial command doesn't
look right ("GUI=1 make n310_rfnoc_image_core") but maybe that's just a
typo. Did you perhaps make changes to the clocking or constraints in the
design? I wouldn't expect building with the ILA to cause this
Hi Rob,
I pulled the cmul module (which uses complex_multiplier.xci) into an OOT
block. I didn't run into any problems. I was able to compile for N310 and
X310 and my OOT simulation worked fine. Here's how I added the
complex_multiplier to my simulation Makefile:
# Include complex_multiplier IP
Building the X310 FPGA does require a Xilinx Vivado license. It is not one
of the FPGAs for which the free version of the tool works.
You can find instructions for building the FPGA in the user manual:
https://files.ettus.com/manual/md_usrp3_build_instructions.html
Thanks,
Wade
On Fri, Nov 20,
Hi Maria,
I assume you're using UHD 3.15 or earlier, since you mentioned the "fpga
repository". I've never tried what you're suggesting, so I don't know what
challenges you'll run into. I think changing NUM_CHANNELS_PER_RADIO will do
what you want, but it will have some side effects, like
Dustin,
It sounds like the software thinks the control port FIFO is filling up. Are
you issuing a lot of timed commands, maybe far into the future? I wonder if
issuing commands faster than they are being executed could cause the FIFO
on the FPGA to fill up with commands.
You could try increasing
Rob,
The -I option is meant for out-of-tree blocks, which are supposed to follow
the same structure as the example. The switchboard.yml file is missing a
line that indicates where its makefile.srcs is:
makefile_srcs:
"${fpga_lib_dir}/blocks/rfnoc_block_switchboard/Makefile.srcs"
See one of the
Hi Rob,
All the blocks should get reset when you create the RFNoC graph. But the
DRAM controller and related AXI4 interconnect are outside of RFNoC, so it
doesn't get reset when the blocks are reset. It's possible that the DRAM
logic is in a bad state as well. It doesn't look like there's a way
Philip,
All the files are located in that same location Michael mentioned, sorted
by product and named by release. So this should never go stale.
https://files.ettus.com/binaries/cache/
If you're ever unsure which one is the right one for your version, you can
check the manifest file, which is
Arash,
You might consider following the build process in the documentation after
making your changes rather than trying to manage your own project. When you
run "make X310_HG" it builds the FPGA in what Xilinx calls "non-project
mode". That's the normal process we use. In your case, you created
Hi Jim,
I'm so glad you're trying this out! This is a known issue that we're hoping
to fix very soon, so you probably did everything right. In the meantime,
you could put your block in-tree for testing purposes. You can also
interact with it as "0/Block#0". I'll see if we can add a note to the
No, I'm not aware of anyone who's tried 4 channels simultaneously yet.
Wade
On Fri, Sep 4, 2020 at 6:18 PM Rob Kossler wrote:
> Hi Wade,
> Thanks for the info. Sounds like I might need to wait for the fixes that
> will allow multiple DRAM ports to work.
>
> Do you know if anyone has tested for
Hi Rob,
We actually just added the Replay to the default images, so that should
show up in the next release candidate, along with some fixes that will
allow multiple DRAM ports to work. It looks like you're missing the
connection to the DRAM data port. Here's an example of what to add for each
Yes, this is intentional. There is a lot of active development going on for
UHD 4.0 and the Replay block will be in there soon.
Thanks for the details with respect to port > 1. I will let you know what I
find.
Wade
On Fri, May 1, 2020 at 1:22 PM Rob Kossler wrote:
> And, one more thing
See my responses below.
On Fri, May 1, 2020 at 11:08 AM Rob Kossler wrote:
> Thanks Wade,
> A few follow up questions:
>
>- Regarding play_halt(), it sounds like this should never used if you
>are planning to start playout again (and the replay output feeds the DUC
>input). Is this
Hi Rob,
I wanted to give you a quick update. I was able to reproduce the issue you
found. There were two problems.
First, the example you shared calls play_halt() for the replay block each
time replay is stopped. This basically stops it as soon as possible, even
if that means it can't send a
Hi Rob,
Thanks for the example! I'd take a look to see if I can reproduce the issue
and figure out what's going on. I've been working recently on the Replay
block, so I'm very interested to understand what's going on.
Thanks,
Wade
On Thu, Apr 23, 2020 at 1:36 PM Rob Kossler via USRP-users <
As far as I can tell, the LED color hasn't changed. Page 13 has the SFP
status LEDs, which show through the panel above the SFPs. These are green
for link (left, above the SFP) and yellow for activity (right, above the
SFP).
Page 14 has the "LINK" LED, which shows through on the opposite end of
Yes, you can ignore that error.
Thanks,
Wade
On Tue, Feb 26, 2019 at 9:56 AM Leandro Echevarría via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Hey everyone,
>
> Upon building my own custom RFNoC images for an X310 using Vivado GUI, I'm
> getting a critical warning stating the following:
Hello James,
Unfortunately, the Replay block doesn't currently support timed commands,
so the behavior you saw is expected. This is something that we have
discussed as a future improvement. In the mean time, I think that your
Verilog modifications might be the right approach.
Thanks,
Wade
On
400 Msps would be 1.6 GB/s for sc16 samples. I think X310 bus_clk is 166.66
MHz for a peak throughput of 166.66 MHz * 8 bytes/cycle = 1.333 GB/s, so it
would require two separate replay blocks (separate buses, not just separate
channels).
I don't know if the memory bandwidth would be adequate
Hi Jason,
The longer run times might be explained by the tool struggling to meet
timing. I can't say off the top of my head what's wrong without looking at
the timing report. Do you have an updated post_route_timing_summary.rpt
file yet? Buried in there it should say exactly what's not meeting
Dan,
I've been testing and I was able to reproduce something that might be your
issue. I'm still testing, but if you want to try the following change, it
might fix your issue. Simply delete this line and rebuild the FPGA:
I assume the N3xx code used to use the 2x version and it wasn't renamed
when it was switched to 4x. Normally the instance name would correspond to
the module name.
I'll see if I can reproduce this on an N310.
Wade
On Mon, Nov 5, 2018 at 1:58 PM Lundberg, Daniel <
Hi Dan,
You can use the viv_modify_bd command to open the BD file in Vivado then
use the "Address Editor" tab to change how slave ports map to the master
port, which connects to DRAM. For example, after running "setupenv.sh" you
could run "viv_modify_bd ip/axi_intercon_2x64_256_bd/
Rob,
Thanks for the patch! I was looking into that flushing in the example and
it does not seem to occur on X310 but I was able to see a delay on N310.
It's not immediately clear to me why there would be a difference between
products, but I will investigate. 10 seconds seems like more samples
Hi Rob,
The Replay block was only tested with X310/N310. E310 doesn't have the PL
DRAM connected like it is on those products. In theory the Replay block
could be used on E310, but it hasn't been tried. It would take some work to
get the memory interface set up and connected to the Replay block
. Additionally, the script will
> insert the following two lines rather than the ones you used. Will this
> work as well?
> wire ce_clk = radio_clk;
> wire ce_rst = radio_rst;
>
> Rob
>
> On Fri, Oct 19, 2018 at 12:48 PM Wade Fife via USRP-users <
> usrp-users@lists.ettus.
Dan,
The UHD exception you saw appears to be due to ce_clk and ce_rst not be
connected in the RFNoC variant that you built (N310_RFNOC_HG; it works in
N310_HG). You can fix this for now by connecting them in
rfnoc_ce_auto_inst_n310.v (see diff below, or refer to
rfnoc_ce_default_inst_n310.v as an
Hi Dan,
I'll see if I can reproduce this with the current master. In the meantime I
suggest just double checking that the fpga-src submodule is also up to
date. Currently, uhd master is at 7130059 and fpga should be at 340bb07. I
know that error would occur with older versions of the FPGA code.
Is it possible that you're loading the wrong .bit file (not the X310
version) from the command line?
Wade
On Thu, Sep 27, 2018, 6:11 PM Jason Meyer via USRP-users <
usrp-users@lists.ettus.com> wrote:
> The command produces output as if there is no issue. It shows the progress
> of the image
55 matches
Mail list logo
