Re: [USRP-users] UHD diverge from origin/master
Thanks for the advice, Martin. Did a git hard reset of UHD, Checked out master, updated uhd-images submodule, built. Ran uhd images downloader Then rebuilt gnuradio. It seems to run correctly. -- Tom, N5EG On Fri, Aug 24, 2018 at 4:35 PM Martin Braun via USRP-users < usrp-users@lists.ettus.com> wrote: > On 08/24/2018 10:14 AM, Tom McDermott via USRP-users wrote: > > I installed and built gnuradio and UHD some time ago from the SBRAC > script. > > > > I am at the head of gnuradio maint-3.7, and am on uhd maint. My > > version of uhd is 3.10.2.0 and my FPGA > > images are also 3.10.2. There appears to be 3.10.3 FPGA available (for > > B205Mini). > > > > However git tells me that UHD has diverged from origin/maint although I > > have not made any changes > > to my local version. I am 30 ahead and 1023 behind origin/maint. A > > guess would be that something in > > uhd origin/maint repository was altered after I pulled from it, and that > > it is necessary to do a git hard reset of > > my local copy. > > > > Assuming I stick with gnuradio maint-3.7 should I then checkout a > > specific tag of uhd, or the > > head of uhd maint? > > Tom, > > we deprecated the UHD maint branches a few weeks ago (Michael West sent > an announcement), but for your case, that shouldn't matter. You can use > a broad range of versions of UHD with GNU Radio, so if you're on > maint-3.7 for GNU Radio, you can still use master branch for UHD, for > example. > > -- M > > ___ > USRP-users mailing list > 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
Re: [USRP-users] Max instantaneous bandwidth on USRP2
Hello Diniz, 40 MHz (analog filter bandwidth of the daughterboard). A USRP 2 can continuously stream at 50 MS/s (complex baseband samples) using the 8-bit wire mode. That means that the maximum bandwidth that the device can cover is limited by the analog filter bandwidth of the daughterboard, which is 40 MHz. But the 8-bit wire mode reduces the dynamic range of the data, and since the USRP 2 does not have a large internal buffer, you cannot really use the 16-bit wire mode at 50 MS/s (unless you are happy with very short, discontinous snapshots of I-Q data). The maximum sustainable rate at the 16-bit wire mode is 25MS/s (=25MHz max bandwidth). (Also, do not forget that the filters - either analog or digital - are not ideal, and that may further reduce the usable bandwidth of the device in some scenarios.) Regards, Kyeong Su Shin. 보낸 사람: Rafael Diniz via USRP-users 대신 USRP-users 보낸 날짜: 2018년 8월 25일 토요일 오전 8:48:21 받는 사람: usrp-users@lists.ettus.com 제목: [USRP-users] Max instantaneous bandwidth on USRP2 Hi all, Which is the maximum instantaneous bandwidth I can capture from a USRP 2 with a WBX daughterboard? Thanks, Rafael Diniz ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[USRP-users] Max instantaneous bandwidth on USRP2
Hi all, Which is the maximum instantaneous bandwidth I can capture from a USRP 2 with a WBX daughterboard? Thanks, Rafael Diniz signature.asc Description: OpenPGP digital signature ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] X310 RFNOC image 8 bytes too large
Andreas, you *should* be able to use the .bit file. Does this happen when you build from master branch? The Vivado version is correct. -- M On 08/23/2018 02:11 AM, Sylvain Munaut via USRP-users wrote: > Hi, > >> Just for curiosity: >> The .bit-file is exactly the same as the .bin-file, except that the >> .bit-file has an additional header, right? In my case (Vivado 2017.04), >> the header of the .bit-file is 124 Bytes while the uhd_image_loader >> assumes a header size of 116 Bytes. Depends this header size on the >> Vivado version or is there another effect leading to the different file >> sizes? > > Sorry, I have no idea ... never looked into it. > > Cheers, > > Sylvain > > ___ > USRP-users mailing list > 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
Re: [USRP-users] UHD diverge from origin/master
On 08/24/2018 10:14 AM, Tom McDermott via USRP-users wrote: > I installed and built gnuradio and UHD some time ago from the SBRAC script. > > I am at the head of gnuradio maint-3.7, and am on uhd maint. My > version of uhd is 3.10.2.0 and my FPGA > images are also 3.10.2. There appears to be 3.10.3 FPGA available (for > B205Mini). > > However git tells me that UHD has diverged from origin/maint although I > have not made any changes > to my local version. I am 30 ahead and 1023 behind origin/maint. A > guess would be that something in > uhd origin/maint repository was altered after I pulled from it, and that > it is necessary to do a git hard reset of > my local copy. > > Assuming I stick with gnuradio maint-3.7 should I then checkout a > specific tag of uhd, or the > head of uhd maint? Tom, we deprecated the UHD maint branches a few weeks ago (Michael West sent an announcement), but for your case, that shouldn't matter. You can use a broad range of versions of UHD with GNU Radio, so if you're on maint-3.7 for GNU Radio, you can still use master branch for UHD, for example. -- M ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[USRP-users] N310 timeout before streaming complete
Hi, This post is perhaps a continuation of a previous post "Problems with MPM 3.13 on N310", but I wanted to change the subject to reflect this current issue. The issue is an Rx streaming timeout. It can be easily duplicated with a stock Ettus example. Below you will find the console log which includes the command line parameters. Note the following: - I requested 31250 samples - There is a error "Timeout while streaming" indicated at the end - The final file size of 119340 indicates that 29835 samples were received - I do not have any reason to believe that the specific command line arguments below are needed to duplicate the issue. I just didn't bother to try other ones. In the other thread, I mentioned that my Rx timeout issue had gone away after switching to streaming mode STREAM_MODE_NUM_SAMPS_AND_DONE. However, the issue below occurs when using that mode so it will be a problem for me. Let me know if you have any questions. Rob irisheyes9@irisheyes9-Z240-SFF:/media/SSD_RAID/multi_pol$ txrx_loopback_to_file --tx-args="addr=192.168.61.2" --rx-args="addr=192.168.61.2" --nsamps=31250 --tx-rate=31.25e6 --rx-rate=31.25e6 --tx-channels=0,1 --rx-channels=2,3 --tx-freq=2500e6 --rx-freq=2500e6 Creating the transmit usrp device with: addr=192.168.61.2... [INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800; UHD_3.13.0.2-0-g0ddc19e5 [INFO] [MPMD] Initializing 1 device(s) in parallel with args: mgmt_addr=192.168.61.2,type=n3xx,product=n310,serial=315A34B,claimed=False,addr=192.168.61.2 [INFO] [MPM.PeriphManager] init() called with device args `mgmt_addr=192.168.61.2,product=n310'. [INFO] [0/DmaFIFO_0] Initializing block control (NOC ID: 0xF1F0D004) [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1320 MB/s) [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1336 MB/s) [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1331 MB/s) [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1349 MB/s) [INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD10011312) [INFO] [0/Radio_1] Initializing block control (NOC ID: 0x12AD10011312) [INFO] [0/DDC_0] Initializing block control (NOC ID: 0xDDC0) [INFO] [0/DDC_1] Initializing block control (NOC ID: 0xDDC0) [INFO] [0/DUC_0] Initializing block control (NOC ID: 0xD0C2) [INFO] [0/DUC_1] Initializing block control (NOC ID: 0xD0C2) Creating the receive usrp device with: addr=192.168.61.2... Using TX Device: Single USRP: Device: N300-Series Device Mboard 0: ni-n3xx-315A34B RX Channel: 0 RX DSP: 0 RX Dboard: A RX Subdev: Magnesium RX Channel: 1 RX DSP: 1 RX Dboard: A RX Subdev: Magnesium RX Channel: 2 RX DSP: 0 RX Dboard: B RX Subdev: Magnesium RX Channel: 3 RX DSP: 1 RX Dboard: B RX Subdev: Magnesium TX Channel: 0 TX DSP: 0 TX Dboard: A TX Subdev: Magnesium TX Channel: 1 TX DSP: 1 TX Dboard: A TX Subdev: Magnesium TX Channel: 2 TX DSP: 0 TX Dboard: B TX Subdev: Magnesium TX Channel: 3 TX DSP: 1 TX Dboard: B TX Subdev: Magnesium Using RX Device: Single USRP: Device: N300-Series Device Mboard 0: ni-n3xx-315A34B RX Channel: 0 RX DSP: 0 RX Dboard: A RX Subdev: Magnesium RX Channel: 1 RX DSP: 1 RX Dboard: A RX Subdev: Magnesium RX Channel: 2 RX DSP: 0 RX Dboard: B RX Subdev: Magnesium RX Channel: 3 RX DSP: 1 RX Dboard: B RX Subdev: Magnesium TX Channel: 0 TX DSP: 0 TX Dboard: A TX Subdev: Magnesium TX Channel: 1 TX DSP: 1 TX Dboard: A TX Subdev: Magnesium TX Channel: 2 TX DSP: 0 TX Dboard: B TX Subdev: Magnesium TX Channel: 3 TX DSP: 1 TX Dboard: B TX Subdev: Magnesium Setting TX Rate: 31.25 Msps... Actual TX Rate: 31.25 Msps... Setting RX Rate: 31.25 Msps... Actual RX Rate: 31.25 Msps... Configuring TX Channel 0 Setting TX Freq: 2500.00 MHz... Actual TX Freq: 2500.00 MHz... Configuring TX Channel 1 Setting TX Freq: 2500.00 MHz... Actual TX Freq: 2500.00 MHz... Configuring RX Channel 2 Setting RX Freq: 2500.00 MHz... Actual RX Freq: 2500.00 MHz... Configuring RX Channel 3 Setting RX Freq: 2500.00 MHz... Actual RX Freq: 2500.00 MHz... Checking TX: all_los: locked ... Checking RX: all_los: locked ... Setting device timestamp to 0... Timeout while streaming Done! irisheyes9@irisheyes9-Z240-SFF:/media/SSD_RAID/multi_pol$ ls -l *.dat -rw-rw-r-- 1 irisheyes9 irisheyes9 119340 Aug 24 14:33 usrp_samples.00.dat -rw-rw-r-- 1 irisheyes9 irisheyes9 119340 Aug 24 14:33 usrp_samples.01.dat irisheyes9@irisheyes9-Z240-SFF:/media/SSD_RAID/multi_pol$ ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Problems with MPM 3.13 on N310
Hi Rob,
Thanks for the update. We will look into it.
Regards,
Michael
On Fri, Aug 24, 2018 at 10:09 AM, Rob Kossler wrote:
> By the way, I just changed my "flush" sequence to use the end_of_burst
> flag (when streaming with STREAM_MODE_START_CONTINUOUS), but the issue
> still occurs. Attached are the modified source code and the resulting
> console log. The new flush sequence is shown below. Again, this is not an
> issue for me now since I changed to using STREAM_MODE_NUM_SAMPS_AND_DONE,
> but wanted to pass this along.
>
> // Shut down receiver
> stream_cmd.stream_mode = uhd::stream_cmd_t::STREAM_MODE_STOP_CONTINUOUS;
> rx_stream->issue_stream_cmd(stream_cmd);
> std::cout << "; Num samples received: " << num_total_samps << std::endl;
>
> while (not md.end_of_burst and md.error_code != uhd::rx_metadata_t::ERROR_
> CODE_TIMEOUT)
> {
> size_t n = rx_stream->recv(buff_ptrs, samps_per_buff, md, timeout);
> std::cout << " flush samples received: " << n << std::endl;
> } // Flush buffers
>
>
> On Thu, Aug 23, 2018 at 8:00 PM Rob Kossler wrote:
>
>> Thanks Michael,
>> Are you saying that when running with STREAM_MODE_START_CONTINUOUS, I can
>> expect a "md.end_of_burst==true" shortly after issuing the
>> STREAM_MODE_STOP_CONTINUOUS? If so, that seems like a much better method
>> for flushing all of the samples following the stop command.
>>
>> In any event, I have no problem switching over to use
>> STREAM_MODE_NUM_SAMPS_AND_DONE. My issue with one or two overruns was
>> several years ago and I believe it was specific to the B210 (and I don't
>> think that increasing start delays helped at that point, but I could be
>> wrong). And in general, I want to decrease rather than increase start
>> delays because my application runs in a fast-as-you-can
>> capture/process/display loop. So, the more I increase the start delay, the
>> slower my loop.
>> Rob
>>
>> On Thu, Aug 23, 2018 at 7:37 PM Michael West
>> wrote:
>>
>>> Hi Rob,
>>>
>>> Excellent feedback as always. Thank you. We will look into the RX
>>> burst behavior using STREAM_MODE_START_CONTINUOUS, but it may take some
>>> time. The flush routine should have a timeout for the recv() call and be
>>> looking for md.end_of_burst to exit, but I'm sure there is more to the
>>> issue than that. BTW, to avoid the overruns at startup, just set a start
>>> time a little in the future and minimize the amount of code between the
>>> issue_stream_cmd() call and the first recv() call.
>>>
>>> Regards,
>>> Michael
>>>
>>> On Thu, Aug 23, 2018 at 11:37 AM, Rob Kossler wrote:
>>>
Martin, Michael,
Sorry for the long delay in responding. I hadn't been monitoring the
user's list this past week and the replies you sent did not come directly
to my inbox. In any event, I compiled the latest MPM and it seems to work
fine. Thank you.
Now, to the secondary issue I mentioned in the first post of this
thread: rx streaming timeouts. These timeouts intermittently occur in my
application when doing repeated rx captures (i.e., error never occurs on
first capture). I tracked it down today to my application's use of
STREAM_MODE_START_CONTINUOUS rather than STREAM_MODE_NUM_SAMPS_AND_DONE for
the capture. After changing my code to use the latter, it works well with
no timeouts.
A couple of remarks:
- I don't know if this is of concern to you or not. Perhaps I
should be using it the new way anyway. A long time ago I had made the
decision to use STREAM_MODE_START_CONTINUOUS because I was getting one
or
two overflows right at the start of the capture (B210) and I didn't want
the capture to abort as it did if I used STREAM_MODE_NUM_SAMPS_AND_
DONE.
- With other products (B210 & X310), I have been using my
application and STREAM_MODE_START_CONTINUOUS for several years,
successfully. (That said, I do want to mention that I have had
occasional
issues ever since Ettus moved away from 3.9 such that I still use 3.9
when
I am able to do so. Perhaps this stream mode change would have fixed
such
occasional issues???)
- If you are interested in this issue, I modified the Ettus example
"txrx_loopback_to_file" to add a 'for loop' around the receive captures
and
changed the stream mode to always be STREAM_MODE_START_CONTINUOUS. The
changes I made are few and straightforward. If you run compile this
modified example and run with the command line shown in the terminal log
(see attached), you should be able to duplicate this issue.
Rob
On Thu, Aug 16, 2018 at 4:05 PM Martin Braun via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Rob,
>
> we pushed a fix for the TX spectrum issue to UHD-3.13 and master.
>
> -- M
>
> On 08/15/2018 05:24 PM, Michael West wrote:
[USRP-users] UHD diverge from origin/master
I installed and built gnuradio and UHD some time ago from the SBRAC script. I am at the head of gnuradio maint-3.7, and am on uhd maint. My version of uhd is 3.10.2.0 and my FPGA images are also 3.10.2. There appears to be 3.10.3 FPGA available (for B205Mini). However git tells me that UHD has diverged from origin/maint although I have not made any changes to my local version. I am 30 ahead and 1023 behind origin/maint. A guess would be that something in uhd origin/maint repository was altered after I pulled from it, and that it is necessary to do a git hard reset of my local copy. Assuming I stick with gnuradio maint-3.7 should I then checkout a specific tag of uhd, or the head of uhd maint? -- Tom, N5EG ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Problems with MPM 3.13 on N310
By the way, I just changed my "flush" sequence to use the end_of_burst flag
(when streaming with STREAM_MODE_START_CONTINUOUS), but the issue still
occurs. Attached are the modified source code and the resulting console
log. The new flush sequence is shown below. Again, this is not an issue
for me now since I changed to using STREAM_MODE_NUM_SAMPS_AND_DONE, but
wanted to pass this along.
// Shut down receiver
stream_cmd.stream_mode = uhd::stream_cmd_t::STREAM_MODE_STOP_CONTINUOUS;
rx_stream->issue_stream_cmd(stream_cmd);
std::cout << "; Num samples received: " << num_total_samps << std::endl;
while (not md.end_of_burst and md.error_code !=
uhd::rx_metadata_t::ERROR_CODE_TIMEOUT)
{
size_t n = rx_stream->recv(buff_ptrs, samps_per_buff, md, timeout);
std::cout << " flush samples received: " << n << std::endl;
} // Flush buffers
On Thu, Aug 23, 2018 at 8:00 PM Rob Kossler wrote:
> Thanks Michael,
> Are you saying that when running with STREAM_MODE_START_CONTINUOUS, I can
> expect a "md.end_of_burst==true" shortly after issuing the
> STREAM_MODE_STOP_CONTINUOUS? If so, that seems like a much better method
> for flushing all of the samples following the stop command.
>
> In any event, I have no problem switching over to use
> STREAM_MODE_NUM_SAMPS_AND_DONE. My issue with one or two overruns was
> several years ago and I believe it was specific to the B210 (and I don't
> think that increasing start delays helped at that point, but I could be
> wrong). And in general, I want to decrease rather than increase start
> delays because my application runs in a fast-as-you-can
> capture/process/display loop. So, the more I increase the start delay, the
> slower my loop.
> Rob
>
> On Thu, Aug 23, 2018 at 7:37 PM Michael West
> wrote:
>
>> Hi Rob,
>>
>> Excellent feedback as always. Thank you. We will look into the RX burst
>> behavior using STREAM_MODE_START_CONTINUOUS, but it may take some time.
>> The flush routine should have a timeout for the recv() call and be looking
>> for md.end_of_burst to exit, but I'm sure there is more to the issue than
>> that. BTW, to avoid the overruns at startup, just set a start time a
>> little in the future and minimize the amount of code between the
>> issue_stream_cmd() call and the first recv() call.
>>
>> Regards,
>> Michael
>>
>> On Thu, Aug 23, 2018 at 11:37 AM, Rob Kossler wrote:
>>
>>> Martin, Michael,
>>> Sorry for the long delay in responding. I hadn't been monitoring the
>>> user's list this past week and the replies you sent did not come directly
>>> to my inbox. In any event, I compiled the latest MPM and it seems to work
>>> fine. Thank you.
>>>
>>> Now, to the secondary issue I mentioned in the first post of this
>>> thread: rx streaming timeouts. These timeouts intermittently occur in my
>>> application when doing repeated rx captures (i.e., error never occurs on
>>> first capture). I tracked it down today to my application's use of
>>> STREAM_MODE_START_CONTINUOUS rather than STREAM_MODE_NUM_SAMPS_AND_DONE for
>>> the capture. After changing my code to use the latter, it works well with
>>> no timeouts.
>>>
>>> A couple of remarks:
>>>
>>>- I don't know if this is of concern to you or not. Perhaps I should
>>>be using it the new way anyway. A long time ago I had made the decision
>>> to
>>>use STREAM_MODE_START_CONTINUOUS because I was getting one or two
>>> overflows
>>>right at the start of the capture (B210) and I didn't want the capture to
>>>abort as it did if I used STREAM_MODE_NUM_SAMPS_AND_DONE.
>>>- With other products (B210 & X310), I have been using my
>>>application and STREAM_MODE_START_CONTINUOUS for several years,
>>>successfully. (That said, I do want to mention that I have had
>>> occasional
>>>issues ever since Ettus moved away from 3.9 such that I still use 3.9
>>> when
>>>I am able to do so. Perhaps this stream mode change would have fixed
>>> such
>>>occasional issues???)
>>>- If you are interested in this issue, I modified the Ettus example
>>>"txrx_loopback_to_file" to add a 'for loop' around the receive captures
>>> and
>>>changed the stream mode to always be STREAM_MODE_START_CONTINUOUS. The
>>>changes I made are few and straightforward. If you run compile this
>>>modified example and run with the command line shown in the terminal log
>>>(see attached), you should be able to duplicate this issue.
>>>
>>> Rob
>>>
>>>
>>> On Thu, Aug 16, 2018 at 4:05 PM Martin Braun via USRP-users <
>>> usrp-users@lists.ettus.com> wrote:
>>>
Rob,
we pushed a fix for the TX spectrum issue to UHD-3.13 and master.
-- M
On 08/15/2018 05:24 PM, Michael West wrote:
> Hi Rob,
>
> We have reproduced the TX corruption issue and we are
troubleshooting.
> In the meantime, you can try using the head of UHD-3.13 with the
> force_reinit=1 as Martin suggested. If that doesn't do the trick, we
> did
Re: [USRP-users] RFNoC fifo filling up
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" , "usrp-users" 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" , "usrp-users" 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
Re: [USRP-users] RFNoC fifo filling up
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" , "usrp-users" 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
