I don't see anything wrong with your YAML. Did you modify the DmaFIFO code (axi_ram_fifo), or are all the changes in your custom block? You could try building with a clean repo and with your custom block removed just to make sure everything is otherwise working fine with the DmaFIFO and your E320.
Wade On Thu, Sep 8, 2022 at 10:23 AM Adrián Campos Ramos < [email protected]> wrote: > The same > > > > El mié, 7 sept 2022 a las 18:19, Rob Kossler (<[email protected]>) 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 <[email protected]> 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 (<[email protected]>) >>> > 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 >>> > <[email protected]> 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 >>> > (<[email protected]>) 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 >>> > <[email protected]> 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 >>> > (<[email protected]>) 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 <[email protected]> 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 >>> > (<[email protected]>) escribió: >>> > >>> > Replace "upstream" with "downstream" below. >>> > >>> > On Thu, Aug 18, 2022 at 1:28 PM Rob >>> > Kossler <[email protected]> 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 >>> > <[email protected]> >>> 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 -- >>> > [email protected] >>> > To unsubscribe send an email to >>> > [email protected] >>> > >>> > _______________________________________________ >>> > USRP-users mailing list -- >>> > [email protected] >>> > To unsubscribe send an email to >>> > [email protected] >>> > >>> > >>> > _______________________________________________ >>> > USRP-users mailing list -- [email protected] >>> > To unsubscribe send an email to [email protected] >>> >>> _______________________________________________ >>> USRP-users mailing list -- [email protected] >>> To unsubscribe send an email to [email protected] >>> >> _______________________________________________ >> USRP-users mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> > _______________________________________________ > USRP-users mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ USRP-users mailing list -- [email protected] To unsubscribe send an email to [email protected]
