Success.
So there were a couple issues I’ll document here for completeness. There was a
comment about having local IP mentioned, so I went down that route.
I made a copy of the axi_fft and Makefile in a rfnoc_myblock/lib/ip directory.
From there I created a new Vivado project and loaded the
Hello Jon,
Thanks for your help. Certainly seeing a change in behavior now. The
axi_fft.xci is being referenced in the Adding IP phase, but ultimately the same
error occurs. I think, if I understand what the log says, that the IP is
locked and cannot be rebuilt for my device which is differen
I see now. Simulation is a bit different than building images. To prevent
building every IP for every simulation, the exact IP you want to use needs
to be added to the test bench Makefile. It is pretty easy. Add the
following to the test bench Makefile in rfnoc/testbenches//Makefile:
LIB_IP_DIR =
I did follow that Getting Started guide and produce the text book
rfnoc_tutorial OOT module and simulated it without issue.
Then next thing I did was to create a second OOT module and name it nd_fft. So
the same generic OOT module with a different name. That too simulated without
issue.
So n
Hi Rich,
The standard Ettus in-tree Vivado IP, which includes the axi_fft, is
automatically included. You do not need to do anything. Have you went
through the RFNoC getting started guide (
https://kb.ettus.com/Getting_Started_with_RFNoC_Development)? I think that
will help you understand the FPGA
Hey Andrew,
If the OOT repo is set up correctly, you will not need to add the OOT
Xilinx IPs manually -- I regularly (daily, in fact) build FPGA images in
uhd-fpga that use OOT Xilinx IP and OOT HLS, and this can be a fully
automated command-line process using the Makefile includes.
Let me know i
It's true that uhd_image_builder.py will pull in all RFNOC IPs
automatically, but if you go to simulate an OOT rfnoc block that relies on
an IP, in my experience, you have to launch Vivado and add the UHD IP
directory to your project.
On Mon, Sep 3, 2018 at 8:43 PM, Jon Pendlum via USRP-users <
us
If you only need integer decimation, noc_block_ddc should have everything
you need or close to it. Averaging across FFTs can be done with
noc_block_vector_iir. For an example, check out the
flowgraph rfnoc_vector_iir.grc in gr-ettus.
Jonathon
On Tue, Sep 4, 2018 at 3:23 PM Rich Maes wrote:
> I’
I’d like to add a configurable decimator and some averaging logic to the output
of the FFT. So I’ll be adding some new registers to the control bloc and
verilog, but the overall core will still be very similar.
I’ll take a look at the examples you reference below to see if that gets me
going
Hey Rich,
Do you want to customize the FFT IP or use it as is? If you are using it as
is, there is no need to do anything. All in-tree code and IP is
automatically included as part of the FPGA build. If you want to customize
it, I suggest copying the FFT IP into your OOT and using
https://github.c
10 matches
Mail list logo
