The same
El mié, 7 sept 2022 a las 18:19, Rob Kossler (<rkoss...@nd.edu>) escribió:
> 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
>
_______________________________________________
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com
