You mentioned that your error happens when running from gnuradio. What
happens if you remove gnuradio from the equation and run "uhd_usrp_probe"?
Do you still get the error?
Rob
On Wed, Sep 7, 2022 at 10:31 AM Piotr Krysik <per...@o2.pl> wrote:
> Hi Adrián,
>
> This error mean that the block didn't respond to a control message
> during initialization.
>
> I've seen such errors when element of RFNoC graphs wasn't working
> correctly.
> Those situations were when:
> 1. replay block wasn't working correctly due to wrong clock for DDR
> SDRAM controller module,
> 2. I removed implementation of one of Ethernet ports (in order to get
> quicker builds in Vivado) but its end-point was left in the RFNoC graph.
> So it was probed during initialization but there was nothing that could
> respond.
>
> Best Regards,
> Piotr Krysik
>
> W dniu 06.09.2022 o 14:59, Adrián Campos Ramos pisze:
> > HI everyone
> >
> > Thank you very much. I made a controller and, according to the
> > simulation, it's working fine, at least as I wanted. However, I am
> > facing problems to implementate in the fpga. There is not problem when
> > i generate the .bit buf when i call in gnuradio, this error appears:
> >
> > WARNING] [UDP] The current send_buff_size of 212992 is less than the
> > minimum recommended size of 307200 and may result in dropped packets
> > on some NICs
> > [ERROR] [RFNOC::GRAPH] Error during initialization of block 0/DmaFIFO#0!
> > [ERROR] [RFNOC::GRAPH] Caught exception while initializing graph:
> > RfnocError: OpTimeout: Control operation timed out waiting for ACK
> > Traceback (most recent call last):
> > File
> > "/home/integrasys/rfnoc/src/uhd/fpga/usrp3/top/e320/build/untitled.py",
> > line 181, in <module>
> > main()
> > File
> > "/home/integrasys/rfnoc/src/uhd/fpga/usrp3/top/e320/build/untitled.py",
> > line 157, in main
> > tb = top_block_cls()
> > File
> > "/home/integrasys/rfnoc/src/uhd/fpga/usrp3/top/e320/build/untitled.py",
> > line 76, in __init__
> > self.rfnoc_graph = ettus_rfnoc_graph_0 =
> > ettus.rfnoc_graph(uhd.device_addr(",".join(("addr=192.168.1.23", ''))))
> > File "/usr/local/lib/python3/dist-packages/ettus/ettus_swig.py",
> > line 1153, in make
> > return _ettus_swig.rfnoc_graph_make(dev_addr)
> > RuntimeError: RuntimeError: Failure to create rfnoc_grap
> >
> > I attached my image.yml:
> >
> >
> > Thanks in advance.
> >
> > El jue, 1 sept 2022 a las 22:24, Wade Fife (<wade.f...@ettus.com>)
> > escribió:
> >
> > The DRAM on USRPs is half duplex, but the AXI bus is full duplex,
> > which makes the real world behavior more complicated. If you want
> > to simulate accurately for a specific USRP, you could pull in its
> > AXI interconnect, the Xilinx memory interface IP, and a DRAM
> > simulation model, then connect it together and match the USRP
> > design exactly, but this is a lot of work. There are examples that
> > are similar to this in fpga/usrp3/top/x300/sim/dram_fifo and
> > fpga/usrp3/top/n3xx/sim/dram_fifo. There's no example for E320,
> > but the idea is similar.
> >
> > Wade
> >
> > On Thu, Sep 1, 2022 at 5:38 AM Adrián Campos Ramos
> > <adrian.cam...@integrasys-sa.com> wrote:
> >
> > Thank you very much! I was testing the code and I got
> > something similar to what I wanted. However, in the simulation
> > the sim_ram is half duplex and my question is if the
> > implementation in the FPGA is also half or full duplex. And if
> > it is full, is there any way to simulate?
> >
> > Thanks in advance.
> >
> > Adrián
> >
> > El mié, 31 ago 2022 a las 16:22, Wade Fife
> > (<wade.f...@ettus.com>) escribió:
> >
> > OUT_FIFO_SIZE sets the size of the FIFO used to buffer
> > data read from the external DRAM. But the unit for this
> > parameter is log base 2 of the size. So, setting it to 20
> > means the output FIFO will be 2^20 words or 8 MiB
> > implemented in BRAM, which is too big for the FPGA to
> > support. You should probably leave it at the default
> > value. The amount of DRAM to use for the FIFO can be set
> > by the FIFO_ADDR_MASK parameter.
> >
> > It should behave like a true FIFO. So anything you write
> > to the input will come out on the output, but you can
> > buffer up to the size of the memory you have configured.
> > I'm not sure I understand your application exactly, but if
> > you only want to capture at a specific time, then you
> > should add logic to only write the data to the input of
> > the FIFO during those times and take care to handle
> > overflow when the FIFO fills. And add logic on the output
> > to only read when you want, taking care to handle
> > underflow when the FIFO empties.
> >
> > Wade
> >
> > On Wed, Aug 31, 2022 at 4:42 AM Adrián Campos Ramos
> > <adrian.cam...@integrasys-sa.com> wrote:
> >
> > Hi,
> >
> > Thank you very much, now I understand how it works and
> > it runs perfectly. However, it's not what I expected
> > since it does not FIFO behaviour, or I'm
> > doing something wrong. What I need is a FIFO that
> > stores the data of a signal when I activate a flag and
> > reads when I activate another flag continuously and
> > constantly. Currently, I have the FIFO implemented in
> > the FPGA but it takes too much resources so I want to
> > take advantage of the E320 RAM. I think the
> > axi_ram_fifo would be perfect for my project but as
> > far i can see, when space = 0 and occupied is full, it
> > starts to lose the continuity. On the other hand, I
> > don't know why but I can't increase the
> > FIFO_OUT_SIZE. With 10 there are outputs but if i
> > increase, for example, to 20 it doesn't.
> >
> > I attached a photo of the behavior of the
> > input_fifo/fifo_ram/ram.
> > p1.png
> >
> > El mar, 30 ago 2022 a las 19:54, Wade Fife
> > (<wade.f...@ettus.com>) escribió:
> >
> > Hello Adrián,
> >
> > REG_FIFO_FULLNESS is the number of bytes currently
> > stored in the RAM of the FIFO.
> >
> > FIFO_ADDR_W is a testbench parameter that defines
> > the amount of memory address space to use for the
> > simulated FIFOs. The unmodified testbench uses a
> > single memory to test two FIFOs. So the sum of the
> > memory used by both FIFOs must be less than the
> > size of the memory being simulated in order for
> > the testbench to work (i.e., 2 * 2**FIFO_ADDR_W
> > must not exceed 2**MEM_ADDR_W).
> >
> > IN_FIFO_SIZE and OUT_FIFO_SIZE control the size of
> > the input/output buffers used by the block. They
> > can affect the performance of the FIFO, but must
> > be large enough to hold two of the expected burst
> > memory transfer size, which I think is 512 words.
> >
> > The testbench is failing because it expects the
> > FIFO to be empty when the simulation begins.
> > Perhaps you have started inputting values before
> > it was expecting you to?
> >
> > Wade
> >
> > On Tue, Aug 30, 2022 at 3:13 AM Adrián Campos
> > Ramos <adrian.cam...@integrasys-sa.com> wrote:
> >
> > Hi everyone,
> >
> > First of all, thank you very much Rob Kossler
> > for the explanation. I made a "controller"
> > that sends and receives information at certain
> > points in time. However, I am facing problems
> > in relation to REG_FIFO_FULLNESS. I've been
> > changing the values of FIFO_ADDR_W,
> > IN_FIFO_SIZE and OUT_FIFO_SIZE but it didn't
> > work. Furthermore, I don't understand the
> > problem at all, is the input fifo or the
> > output fifo? or the ram?. The controller
> > mentioned before has only two counters, one to
> > activate the valid flag to send information
> > and another to activate the ready flag to
> > receive the information and, as far i could
> > see, it was working until the assert.
> >
> > This is the error that returns me the
> > simulation (the number that appears in the
> > image is for: `ASSERT_ERROR(val64 == 0,
> > $sformatf("Incorrect REG_FIFO_FULLNESS value!
> > %d",val64));
> >
> > Screenshot from 2022-08-30 10-10-52.png
> > On the other hand, the data that I send to RAM
> > is the value of a counter.
> >
> > I hope you can help me. Thanks in advance.
> >
> > Adrián Campos
> >
> > El jue, 18 ago 2022 a las 22:49, Rob Kossler
> > (<rkoss...@nd.edu>) escribió:
> >
> > Replace "upstream" with "downstream" below.
> >
> > On Thu, Aug 18, 2022 at 1:28 PM Rob
> > Kossler <rkoss...@nd.edu> wrote:
> >
> > Hi Adrian,
> > As you indicated, the RFNoC blocks
> > axi_ram_fifo and Relay both use the
> > FPGA RAM. axi_ram_fifo doesn't need
> > any registers for control because it
> > just accepts an AXI stream on the
> > input and forwards that exact stream
> > on the output. The "control" is in the
> > AXI tvalid/tready handshaking. Thus,
> > if the upstream block is not ready,
> > the FIFO starts filling up but does
> > not empty until the upstream block is
> > ready. But, for the Replay block,
> > this block stores the incoming stream
> > to RAM until you later decide to play
> > it out. It can be used in the
> > transmit path to load a waveform into
> > RAM such that it can be played out to
> > the Tx Radio without any help from the
> > host PC. Or, it can be used in the
> > receive path to store receive samples
> > as they arrive (up to the given RAM
> > memory depth) and then later
> > downloaded (played out) to the host PC
> > in non-realtime.
> >
> > While I don't know your specific
> > application, I wondered if the Replay
> > block (or the axi_ram_fifo) can
> > already implement your desired
> > functionality such that a custom block
> > is not needed.
> > Rob
> >
> > On Thu, Aug 18, 2022 at 8:25 AM
> > <adrian.cam...@integrasys-sa.com> wrote:
> >
> > I am making a custom block which
> > has to start storing data to be
> > read later, in other words store
> > the data in a FIFO. I am
> > interested in using the RAM
> > provided by the E320 so I want to
> > take advantage of the axi_ram_fifo
> > code. However, I don't really
> > understand the control of that
> > block, how can I control when to
> > start writing data to memory and
> > when to start reading it? I have
> > checked the registers in case it
> > could be controlled from there
> > like the replay block that has two
> > registers to start reading and
> > another one to do a restart but I
> > haven't seen anything like that.
> >
> > I hope you can help me. Thank you
> > very much in advance
> >
> >
> >
> _______________________________________________
> > USRP-users mailing list --
> > usrp-users@lists.ettus.com
> > To unsubscribe send an email to
> > usrp-users-le...@lists.ettus.com
> >
> > _______________________________________________
> > USRP-users mailing list --
> > usrp-users@lists.ettus.com
> > To unsubscribe send an email to
> > usrp-users-le...@lists.ettus.com
> >
> >
> > _______________________________________________
> > USRP-users mailing list -- usrp-users@lists.ettus.com
> > To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>
> _______________________________________________
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>
_______________________________________________
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com
