[USRP-users] RFNoC Replay block example

[Rob Kossler via USRP-users]

There are a couple of issues with the replay block example:
- It doesn't work correctly for ports other than the default port because
some function calls have missing "port" args or they are set to zero rather
than using the specified port (see attached patch file with changes).
- It can take a very long time to flush the samples.  Is there any way
around this?  Note that I am using a sample rate of 12.5 MS/s and it takes
several seconds (perhaps up to 10) to flush.  I am not certain how
consistent the time is.

Rob
diff --git a/host/examples/replay_samples_from_file.cpp b/host/examples/replay_samples_from_file.cpp
index 70c0272..f9ef3cd 100644
--- a/host/examples/replay_samples_from_file.cpp
+++ b/host/examples/replay_samples_from_file.cpp
@@ -344,7 +344,7 @@ int UHD_SAFE_MAIN(int argc, char *argv[])
 
 stream_cmd.stream_mode = uhd::stream_cmd_t::STREAM_MODE_STOP_CONTINUOUS;
 cout << endl << "Stopping replay..." << endl;
-replay_ctrl->issue_stream_cmd(stream_cmd);
+replay_ctrl->issue_stream_cmd(stream_cmd, replay_chan);
 
 
 ///
@@ -353,10 +353,10 @@ int UHD_SAFE_MAIN(int argc, char *argv[])
 uint16_t prev_packet_count, packet_count;
 
 cout << "Waiting for replay data to flush... ";
-prev_packet_count = replay_ctrl->sr_read64(uhd::rfnoc::SR_READBACK_REG_GLOBAL_PARAMS, 0) >> 32;
+prev_packet_count = replay_ctrl->sr_read64(uhd::rfnoc::SR_READBACK_REG_GLOBAL_PARAMS, replay_chan) >> 32;
 while(true) {
 std::this_thread::sleep_for(std::chrono::milliseconds(100));
-packet_count = replay_ctrl->sr_read64(uhd::rfnoc::SR_READBACK_REG_GLOBAL_PARAMS, 0) >> 32;
+packet_count = replay_ctrl->sr_read64(uhd::rfnoc::SR_READBACK_REG_GLOBAL_PARAMS, replay_chan) >> 32;
 if (packet_count == prev_packet_count) break;
 prev_packet_count = packet_count;
 }
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] RFNoC block fpga control source issues

[Samuel Prager via USRP-users]

Hi Jonathon,

Yes I don’t really see how this what about the fifo flop vs fifo would be 
causing the issue either so it would make sense if there is something more 
complex going on...

I am using chdr framer to generate my command packet headers, which is where it 
was causing problems. I haven’t had any problems using it with data packets.

Yes the commands go out shortly before I start streaming TX data to the radio 
from my block.

What’s interesting is the correct number of settings bus writes were always 
being initiated in the radio at the right time. The commands actually coming 
out of the chdr_framer were oddly just from previous bursts.

I’m not sure how helpful this is, but I took some screenshots of the ila probes 
showing the complete transaction:

https://drive.google.com/open?id=1FwQe2ky0vsU_jjAa24U-_oTGhtvI3jK8

The signals are ordered from top to bottom as - 1-4 : command body going in to 
chdr_framer: tdata, tvalid, tready, state of my block
- 5-7 : cmd packets leaving chdr_framer : tdata, tvalid, tready
- 8-10 : cmd in port packets received by the radio : tdata, tvalid, tready
- 11-12 : settings bus of radio set data, set addr, set stb

There are some additional screenshots of the transactions here, that attempt to 
show the described behavior by the chdr_framer.
https://drive.google.com/open?id=1JRdzt27e2uyEs9DIDSTNHhRk_qB9W897

One other interesting behavior, is that when I kill my software application and 
restart it, the first command that comes out of chdr framer is a command sent 
while the previous instance of my application was running.

This can be seen for example in the image by my command to write radio SR 0x99 
(rx cmd time hi). My block to sends 0x0, but the cmd out of chdr framer and the 
ultimate settings bus write is 0xa

Sam
On Oct 31, 2018, 1:23 AM -0700, Jon Pendlum , wrote:
> Hi Sam,
>
> Interesting find. Fundamentally, chdr_frame was designed to buffer and 
> release on packet boundaries. This is due to the crossbar being packet 
> switched and ensures packets flow through the crossbar at full rate. 
> Generally, that is only important for sample data, which could have large 
> packets generated slowly due to a low sample rate.
>
> All that said, I am not seeing why switching to axi_fifo_flop2 is causing an 
> issue. chdr_framer is not used anywhere in the settings bus data path. I 
> wonder if there is a more complex interaction going on here. The 
> flow_control_responder in noc_shell does use chdr_framer and its output does 
> eventually mux with response packets generated from setting bus writes.
>
> Do you send these commands only while streaming? If so, can you try to send 
> them when not streaming and see if you have the same issue?
>
> Jonathon
>
> > On Wed, Oct 31, 2018 at 5:19 AM Samuel Prager  wrote:
> > > Hi Jonathon,
> > >
> > > I have identified the cause of this problem as being chdr_framer.v. It 
> > > appears to not be adhering to the axi_stream protocol and is holding onto 
> > > packets until the fifo is full even when o_tready is asserted, causing 
> > > the described behavior.
> > >
> > > The root cause is the switch to axi_fifo_flop2 for the header fifo 
> > > (changed with commit that eb0ae36). The problem is fixed completely by 
> > > switching this back to an axi_fifo_short.
> > >
> > > Thanks,
> > >
> > > Sam
> > > On Oct 25, 2018, 7:36 PM -0700, Samuel Prager , wrote:
> > > > Hey Jonathon,
> > > >
> > > > I had a chance to debug this a little further (On an N300) and have 
> > > > observed the following behavior:
> > > >
> > > > The command packets are getting through to the radio block but are 
> > > > being buffered somewhere along the line so that the first command is 
> > > > either not received or not processed until exactly 16 have been sent.
> > > >
> > > > So if I am sending commands in a loop, there is a 16 command delay 
> > > > before the settings bus writes and a rx command is triggered in the 
> > > > radio.
> > > >
> > > > This seems to indicate that there is a buffer somewhere that doesn’t 
> > > > pass the commands until it is full.
> > > >
> > > > Any thoughts on what the culprit could be?
> > > >
> > > > Sam
> > > > On Oct 23, 2018, 11:17 PM -0700, Jon Pendlum , 
> > > > wrote:
> > > > > Hey Sam,
> > > > >
> > > > > There have been some changes to noc_shell, maybe they are related to 
> > > > > your issue. If you want to try to debug this on the FPGA, I suggest 
> > > > > using chipscope on the file cmd_pkt_proc.v. That is the state machine 
> > > > > that receives command packets and issues settings bus writes. You 
> > > > > should be able to see your command packets come in and get processed 
> > > > > by the state machine. You can double check the command packet / timed 
> > > > > command vita time versus the radio core's vita time. You can also see 
> > > > > if the state machine gets stuck in a certain state.
> > > > >
> > > > > Jonathon
> > > > >
> > > > > > On Wed, Oct 24, 2018 at 9:44 AM Samuel Prager  
> > > 

Re: [USRP-users] RFNoC Replay block for E310?

[Jason Matusiak via USRP-users]

I might be speaking out of turn here since I don't really know what the replay 
block does.  But in the past, I successfully created a block that used a .coe 
file as a generated signal I transmitted over and over again.  It was a pretty 
easy OOT module that just used a Xilinx core if I remember right.
 
 
- Original Message - Subject: Re: [USRP-users] RFNoC Replay 
block for E310?
From: "Wade Fife via USRP-users" 
Date: 10/30/18 1:57 pm
To: "Rob Kossler" 
Cc: "usrp-users" 

  Hi Rob,
 
The Replay block was only tested with X310/N310. E310 doesn't have the PL DRAM 
connected like it is on those products. In theory the Replay block could be 
used on E310, but it hasn't been tried. It would take some work to get the 
memory interface set up and connected to the Replay block (you would want to 
hook it up similarly to how its done on X310/N310), and there might be resource 
challenges depending on what you're trying to fit in the design. But I'm not 
aware of a specific reason why it couldn't work.
 
Thanks,
 
Wade


  On Mon, Oct 29, 2018 at 10:26 AM Rob Kossler via USRP-users 
 wrote:
 Hi, I have successfully compiled & used the RFNoC replay block with an X310.  
Now, I would like to do the same with an E310.  After some quick investigation, 
I noticed that the "use_replay" logic has been included in both "n3xx_core.v" 
and "x300_core.v" but not in "e310_core.v" or any other E310 verilog files.  I 
also noticed that application note AN-642, Using the RFNoC Replay Block, 
specifically mentions support for the X300/X310 and N310, but no mention of the 
E310.
 
I'm wondering if I just need to modify "e310_core.v" to implement similar logic 
to that in "n3xx_core.v" and/or "x300_core.v" in order to get this working on 
the E310?  Or, is there some reason that this will not work such that I am 
wasting my time?
 
Thanks.
Rob

___
 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
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Saturation issue with low amplitude (USRP N310)

[Lundberg, Daniel via USRP-users]

I appreciate the responsiveness.  I am fairly new to the N310 and the RFNOC 
blocks, so I would not entirely rule out the possibility of user error at this 
point.  If there are additional diagnostics I could supply, please let me know.
-Dan

From: Michael West 
Sent: Tuesday, October 30, 2018 8:00 PM
To: Lundberg, Daniel 
Cc: Serge Malo ; USRP-users@lists.ettus.com
Subject: Re: [USRP-users] Saturation issue with low amplitude (USRP N310)

Thank you for everyone's input.  We are aware and taking this very seriously.  
We tried unsuccessfully to reproduce the issue on multiple devices using both 
the v3.13.0.3-rc1 tag and head of master.  We will continue investigating and 
report back with any new information.

Regards,
Michael

On Mon, Oct 29, 2018 at 7:07 AM Lundberg, Daniel via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:
I think I am seeing the same or a similar problem using the latest master 
(which I think is roughly equivalent to 3.13.0.3 RC1, correct me if I am wrong) 
on an N310.
When I save a signed 16-bit binary file and feed it into the 
replay_sample_from_file example, I can only provide it with a full-scale 
amplitude of ~8 bits in amplitude (+/- 2^8-1), or I get saturation / strange 
corruption of the waveform.  Changing the gain does not seem to have any 
effect.  The N310 is supposed to have a 14-bit DAC, and conversations with 
Ettus imply that the replay block is too simple to cause this, so the problem 
is probably pretty far upstream?  I have described the problem to Ettus, and 
they suggested checking most of the things you and I have already tested 
(gains, input files, etc…).

From: USRP-users 
mailto:usrp-users-boun...@lists.ettus.com>> 
On Behalf Of Serge Malo via USRP-users
Sent: Monday, October 29, 2018 9:55 AM
To: sdorm...@eng.ucsd.edu
Cc: USRP-users@lists.ettus.com
Subject: Re: [USRP-users] Saturation issue with low amplitude (USRP N310)

Hi all,

any news on this saturation issue concerning the N310 with UHD 3.13.0.3 RC1?
I would like to know if Ettus is aware of this problem, and if a new UHD 
version is coming with a correction?

Thanks!

Best regards,
Serge


- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
- - - - - - - - - -
Serge Malo
CDO & Co-founder, Skydel Solutions
Cell: 1-514-294-4017
www.skydelsolutions.com
Twitter: @skydelsol
Avis : Ce message est confidentiel et protégé par le secret professionnel. Si 
vous n'êtes pas le destinataire, veuillez informer l'expéditeur par courriel 
immédiatement et effacer ce message et en détruire toute copie. / Notice: This 
message is confidential and privileged. If you are not the addressee, please 
inform the sender by return e-mail immediately and delete this message and 
destroy all copies.


On Wed, 17 Oct 2018 at 16:53, Ali Dormiani via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:
Attempt 2. Sorry for breaking mailing list rules with the attachments. Here is 
a google drive link to the screenshots, GRC file, and binary files. (3 MB zip)

https://drive.google.com/a/eng.ucsd.edu/file/d/1TvmHuEMFb2QpkiMMdiUEW6aVoUfLYayi/view?usp=sharing

We have three sliders in GNUradio.

1. TX gain

2. RX gain

3. Digital Gain (multiply constant block between our binary file and the UHD 
block.

We also have one TX connected directly to an RX with a 30 dB analog attenuation 
for safety.

Our binary files were generated in MATLAB and are normalized to unity magnitude.

Attached, please find the GRC file and our binary files. For reference, the 
waveform we made is a multitone signal so it should be a bunch of evenly spaced 
spikes. I have included some screenshots too. Additionally we have verified 
this strange behavior with a spectrum analyzer.
By playing around with the sliders you can see how narrow the zone is for good 
results. Intuitivly it seems like TX and RX gain don't really matter. They just 
shift the narrow usability zone for Digital gain.

On Wed, Oct 17, 2018 at 12:45 PM Ali Dormiani 
mailto:sdorm...@eng.ucsd.edu>> wrote:
We have three sliders in GNUradio.

1. TX gain

2. RX gain

3. Digital Gain (multiply constant block between our binary file and the UHD 
block.

We also have one TX connected directly to an RX with a 30 dB analog attenuation 
for safety.

Our binary files were generated in MATLAB and are normalized to unity magnitude.

Attached, please find the GRC file and our binary files. For reference, the 
waveform we made is a multitone signal so it should be a bunch of evenly spaced 
spikes. I have included some screenshots too. Additionally we have verified 
this strange behavior with a spectrum analyzer.
By playing around with the sliders you can see how narrow the zone is for good 
results. Intuitivly it seems like TX and RX gain don't really matter. They just 
shift the narrow usability zone for Digital gain.



On Wed, Oct 10, 2018