I'm back with an update. As I mentioned below, I don't think my CEs are
the main issue here (I haven't ruled it out completely) so to highlight
the issue I'm struggling with, I'll try to present a reproducible
example that does not involve my custom CEs:
Consider the block diagrams seen here: https://imgur.com/a/k3zcaJT.
According to my understanding of this article:
https://kb.ettus.com/RFNoC, they should be more or less equivalent.
Now consider two FPGA images: The stock image (found in something like
/usr/local/share/uhd/images) and a "custom" image built with
uhd_image_builder.py that has the same CEs as the stock image (2x DDC,
2x DUC, 1x DmaFIFO and 2x Radio, all provided by Ettus) and nothing else
(no FIFOs or FFTs or any of my own CEs).
The USRP Sink-based TX chain works as expected on both images. However,
the RFNoC: Radio-based TX chain works on the stock FPGA image but fails
on the other, the "custom" image. The first time the RFNoC: Radio-based
chain fails on the "custom" image, everything is just quiet (no error
messages in GRC and no spike on the spectrum analyzer). Subsequent runs
will fail with "RuntimeError: RuntimeError: BIST failed! (code: 1)"
until the USRP is rebooted. The uhd_image_builder.py script finished
without any errors, such as timing violations or other design rule
violations.
So, getting back to the original question: Why am I not seeing any
output while using the RFNoC: Radio-based TX chain on the "custom"
FPGA-image?
//
Leon
On 2019-05-08 22:40, zluudg wrote:
Ok, I think I have an idea what to look for now. Thanks a lot for the
quick replies!
//
Leon
On 2019-05-08 22:29, Nick Foster wrote:
Anything that might hang the bus. If you don't consume packets, if
you generate packets addressed to the wrong CE, if you don't set
tlast correctly.
On Wed, May 8, 2019 at 1:03 PM zluudg <zlu...@zluudg.xyz
<mailto:zlu...@zluudg.xyz>> wrote:
Cool, I'll take a closer look at my CEs then.
What behavior on the main AXI-Stream data interface of a CE would
count as "not playing nicely"? I know that a master may not wait
on the tready-signal of a slave before asserting its
tvalid-signal, but other than that I'm unsure what type of
behavior could cause issues.
//
Leon
On 2019-05-08 21:34, Nick Foster wrote:
Short answer: yes. If your block isn't playing nicely it can do
bad things to the NoC crossbar.
Best solution is to simulate the whole NoC block.
On Wed, May 8, 2019 at 12:20 PM zluudg <zlu...@zluudg.xyz
<mailto:zlu...@zluudg.xyz>> wrote:
I thought that my own CEs was just a sidenote in this
context since the Gnuradio block diagram I used as an
example consists solely of Ettus-provided blocks.
I have not simulated my RFNoC CEs with Verilog testbenches.
I have simulated my blocks in a VHDL testbench, but not with
the RFNoC-generated System Verilog skeleton code. My blocks
seem to work fine during live testing in RX-only systems,
though.
So as a question back to you, can my custom CEs cause
trouble for the Ettus-provided CEs (DmaFIFO, DUC, Radio)
even if they are unused in a block diagram such as the
example I gave in my previous mail? If so, I'll take a
closer look at my custom CEs.
//
Leon
On 2019-05-08 18:41, Nick Foster wrote:
Have you simulated your RFNoC CEs with Verilog testbenches?
On Wed, May 8, 2019 at 8:12 AM zluudg via USRP-users
<usrp-users@lists.ettus.com
<mailto:usrp-users@lists.ettus.com>> wrote:
Hello!
I'm having some issues while trying to transmit a
signal using the
RFNoC: Radio block in Gnuradio. My block diagram is:
Signal Source (constant) -> RFNoC: DmaFIFO ->
RFNoC: Radio (in
TX mode).
I run the block diagram by calling "python
top_block.py" from the
command line and I'm not getting any errors while it's
running .
However, I'm unable to quit it properly without having
to close the
terminal window and power-cycle the USRP. When
connecting the USRP to a
spectrum analyzer I see no signal whatsoever (I expect
to see a peak at
2.4 GHz).
Removing the DmaFIFO does not seem to make any
difference. My FPGA image
is a custom image with some of my CEs, but it was built
smoothly using
the "uhd_image_builder.py" script. I've also
experienced similar
problems while having a RFNoC: DUC between the DmaFIFO
and the Radio
block, also with a custom FPGA image. With the stock
FPGA image I was
able to get a signal with more or less the same
Gnuradio block diagram.
Why am I not seeing any output with my custom FPGA
images? All
suggestions appreciated.
I'll happily provide more info if needed, so don't
hesitate to ask. For
know, I'll just provide the basics:
OS: Ubuntu 18.04
uhd: rfnoc-devel, eec24d7b0
gnuradio: maint-3.7, c6c575309
gr-ettus: master, a909447
Thanks in advance!
//
Leon
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
<mailto: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
