Sadly, I still seem to be having this issue. Running threshold's test bench, I seem to be seeing it as well. I've attempted to reset all the files I touched (mostly just debug statements), so I don't know if there is an issue with threshold, but I don't understand why the fifos are filling up without reading (axi_fifo_short). I am going to try to find another machine to see if I threshold works there, but I am thinking that something else is going on somewhere.... --------- Original Message --------- Subject: RE: Re: [USRP-users] RFNoC fifo filling up From: "Jason Matusiak" <ja...@gardettoengineering.com> Date: 8/24/18 7:25 am To: "Sylvain Munaut" <246...@gmail.com> Cc: "Brian Padalino" <bpadal...@gmail.com>, "usrp-users" <usrp-users@lists.ettus.com>
Whoops, I misspoke on the SPP size. At some point I must have changed the SPP to 1024. So with a file size of 57344 bytes, it was 57344/8/1024 = 7 full packets that made it though. When I tried it at SPP=16, 3840 bytes were in the file sink. So 3840/8/16 = 30 packets made it through. This would leave me to believe that I am filling up that FIFO again, but I don't see that happening in the simulation. --------- Original Message --------- Subject: RE: Re: [USRP-users] RFNoC fifo filling up Date: 8/24/18 7:05 am To: "Sylvain Munaut" <246...@gmail.com> Cc: "Brian Padalino" <bpadal...@gmail.com>, "usrp-users" <usrp-users@lists.ettus.com> OK, let me elaborate since my first email was not very well written (I was throwing it out there on the way out the door). I spent all day yesterday thinking that I was making progress, the last simulation was copacetic, so I did a build over night, and yet again, no love. I started on this block about 2 weeks ago. Part way through, I realized that I was essentially making a block that acted a lot like noc_block_threshold combined with noc_block_siggen. I want to detect a signal above a threshold and instead of passing it through as-is (like the threshold block does), I want to send my own data through. So the main logic of my block revolves around the threshold axi_async_stream.v module that threshold uses since it handles the "tkeep" flag and the fact that I am not making a 1:1 block. I monitor the sample_t* signals coming from the async module since those are the inputs into the module (async takes the axi_wrapper data and decodes it). When I see a sample above my threshold, I assert the threshold_tkeep flag (the flag that tells async that I want to keep the incoming sample. So here is a rough flowgraph of my module: *AXI wrapper sends its data to async_stream (I do not touch those signals at all) *async outputs its stream of data/flags to "user" code (my module) *I have a tkeep wire that monitors the sample data to see if it is above my threshold or not (I am not monitoring sample_tavlid here since me keeping/not keeping data shouldn't really matter for this flag *sample_tvalid comes in and is wrapped around to threshold_tvalid (from "user" code back into async) *threshold_tready is the output of axi_round_and_clip_complex (that is the i_tready output of siggen's output axi_round_and_clip_complex) *threshold_tdata is the data coming out of axi_round_and_clip_complex (o_tdata) *threshold_tready is passed into axi_round_and_clip_complex's o_tready Now, to make sure that I don't have an issue with siggen spitting out data before the axi_interface is setup (since I am not using a physical enable like the original siggen module has), I have a register called first_byte (poor naming in hindsight). It starts out cleared and isn't asserted until sample_tvalid && sample_tready go high (basically not until the first sample is being output to "user" land, meaning that the rfnoc radio is up and passed its first sample through [this tells me that the axi interface is up and running]). That first_byte flag is used in the threshold_tkeep wire I mentioned above. So this means that async will be dumping any samples that might be accidentally sent to async by "user" code. I am guessing that I am still causing some sort of deadlock because I can simulate fine and get the proper results, but things timeout in a real flowgraph right after starting. My flowgraph ultimately dumps the samples into a time sink as well as a file sink. I can see on the time sink that data passed through a little. The file sink will show a handful of samples as well. On my most recent run, there are 57344 bytes in the file (so 7168 samples). With my SPP being 16 (which I also use as a vector size), that works out to be 448 packets. Note though, that the file size changes slightly on each run. One last comment. I have all sorts of permitations of rfnoc fifos without much change. My current flowgraph has an rfnoc:fifo follower by a dma fifo as the last two blocks before crossing into the host domain (I basically copied what fosphor does). A lot of words there, but hopefully someone can spot something stupid that I am doing here. --------- Original Message --------- Subject: Re: [USRP-users] RFNoC fifo filling up From: "Sylvain Munaut" <246...@gmail.com> Date: 8/23/18 5:31 am Cc: "Brian Padalino" <bpadal...@gmail.com>, "usrp-users" <usrp-users@lists.ettus.com> Hi, > Brian, I really only want to send data when appropriate. I don't have the > code in front if me at the moment, but I can have tvalid high while I wait > for tready, right. Actually tvalid high with tready low is completey expected. Because you CANNOT have tvalid depend on the status of tready. (i.e. waiting for tready to assert tvalid is a spec violation and _will_ cause dead locks). > So I don't see why it would be an issue if I change tdata while tvalid is > high and tready is low. But changing tdata which tvalid is high and tready low means that this data will be "lost" which ... although it won't cause a dead lock is a bit weird to just drop data randomly depending on the handshake process ... > But I've spent the last two days trying to debuf this before I found out it > was the axi fifo filling up. It is weird to me that it is slowly falling > behind. It makes me feel like tlast maybe has something to do with it..... You do assert tlast periodically right ? I mean you need to send packets, not a stream. Cheers, Sylvain
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
