Re: [USRP-users] Unable to Load X310 Registers

[Jonathon Pendlum via USRP-users]

Hi,

I don't see anything inherently wrong with your code. Using the waveform
viewer, do you see the settings bus writes occur? You'll need to watch for
the condition where set_stb asserts and set_addr is equal to one of your
user register addresses.

Jonathon

On Tue, Oct 22, 2019 at 8:25 PM ishai alouche via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi,
>
> I am running a testbench on my architecture, and all default tests pass as
> expected. This includes TEST 4 which tests writing and reading back from
> registers. The problem is - the following tests prove the registers hold
> their initial (default) value and not the value I tried writing to them in
> TEST 4.
>
> Did I miss something in the process?
> what possible reasons may cause this problem?
>
> Scripts of both Testbench code and NoC_block code given below.
>
> Thanks in advance,
> Ishai
>
> *Testbench Code:*
>
> */**
>
> ** Test 4 -- Write / readback user
> registers***
>
>
> ***/`TEST_CASE_START("Write user registers");
>   random_word = 0;tb_streamer.write_user_reg(**sid_noc_block_TxChannelSrc,
> noc_block_TxChannelSrc.SR_MIN_*
>
> *BW, random_word[21:0]);random_word = 5;
> tb_streamer.write_user_reg(**sid_noc_block_TxChannelSrc,
> noc_block_TxChannelSrc.SR_MAX_*
>
> *BW, random_word[21:0]);random_word = 10;
> tb_streamer.write_user_reg(**sid_noc_block_TxChannelSrc,
> noc_block_TxChannelSrc.SR_BW_*
>
> *CHANGE_RATE, random_word[21:0]);random_word = 256;
> tb_streamer.write_user_reg(**sid_noc_block_TxChannelSrc,
> noc_block_TxChannelSrc.SR_PKT_*
> *SIZE, random_word[15:0]);`TEST_CASE_DONE(1);*
>
> *noc_block verilog code:*
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *localparam SR_USER_REG_BASE = 129;localparam [7:0] SR_MIN_BW = 129;
> //SR_USER_REG_BASE;  localparam [7:0] SR_MAX_BW = 130;//TeSR_USER_REG_BASE
> + 8'd1;  localparam [7:0] SR_BW_CHANGE_RATE = 131;//SR_USER_REG_BASE +
> 8'd2;  localparam [7:0] SR_PKT_SIZE   = 132; //SR_USER_REG_BASE +
> 8'd3;  wire [15:0] payload_length;  wire [21:0] min_BW;  wire [21:0]
> max_BW;  wire [21:0] BW_change_rate; cvita_hdr_encoder
> cvita_hdr_encoder (.pkt_type(2'd0), .eob(1'b0), .has_time(1'b0),
> .seqnum(12'd0), .payload_length(payload_*
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *length), .dst_sid(next_dst_sid), .src_sid(src_sid),
> .vita_time(64'd0),.header(s_axis_data_tuser));  // Set packet size
> setting_reg #(.my_addr(SR_PKT_SIZE), .awidth(8), .width(16),
> .at_reset(4)) // Set a safe default packet size in case packet size is
> never set  set_payload_length (.clk(ce_clk), .rst(ce_rst),
> .strobe(set_stb), .addr(set_addr), .in(set_data),.out(payload_length),
> .changed());   setting_reg #(.my_addr(SR_MIN_BW), .awidth(8),
> .width(22))  sr_min_bw (.clk(ce_clk), .rst(ce_rst),
> .strobe(set_stb), .addr(set_addr), .in(set_data), .out(min_BW),
> .changed());   setting_reg #(.my_addr(SR_MAX_BW), .awidth(8),
> .width(22))  sr_max_bw (.clk(ce_clk), .rst(ce_rst),
> .strobe(set_stb), .addr(set_addr), .in(set_data), .out(max_BW),
> .changed());   setting_reg #(.my_addr(SR_BW_CHANGE_RATE), .awidth(8),
> .width(22))  sr_bw_change_rate (.clk(ce_clk), .rst(ce_rst),
> .strobe(set_stb), .addr(set_addr), .in(set_data), .out(BW_change_rate),
> .changed()); *
>
>
> --
> ישי אלוש
> 054-5823400
> ___
> 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] Fwd: Failing to Instantiate Blocks ("No Binding Entity")

[Jonathon Pendlum via USRP-users]

Hi,

Did you include your generic_counter VHDL source file in Makefile.inc in
the fpga-src directory?

Jonathon

On Mon, Oct 7, 2019 at 3:46 PM ishai alouche via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi everyone,
>
> In my architecture I instantiated an FM_block.vhd, and in the FM_block I
> instantiated a generic_counter.vhd block.
>
> The problem:
>
> when I run the simulation I see that the FM_block is fine, but the
> generic_counter is unreferenced, and i get the following warning:
>
>
>
> *Starting static elaborationWARNING: [VRFC 10-122] generic_counter remains
> a black-box since it has no binding entity
> [/home/user/rfnoc_01/rfnoc-modules/rfnoc/fpga-src/FM_block.vhd:38]WARNING:
> [VRFC 10-122] generic_counter remains a black-box since it has no binding
> entity [/home/user/rfnoc_01/rfnoc-modules/rfnoc/fpga-src/FM_block.vhd:50]*
>
> I have also opened the project in Vivado and noticed the same thing: The
> file is unreferenced.
>
> Furthermore, I add the path of the two files (FM_block and
> generic_counter) to all of the Make files I could find, but to no avail.
>
> Please help!
>
> Thank in advance,
> Ish
>
> P.S. Further information:
>
> The syntax used to instantiate the FM_block is as follows (verilog):
>
>
>
> *  FM_block #(.COUNTER_WIDTH(22))  FM_block_i (.clk(ce_clk),
>  .rst(ce_rst), .en (s_axis_data_tready), .min_BW(min_BW),
>   .max_BW(max_BW), .BW_change_rate(BW_change_rate), .FM_out(data_out));*
>
> And the syntax used to instantiate the generic_counter is as follows
> (vhdl):
>
>
>
>
>
>
>
>
>
>
>
> *counter_change_rate : generic_counter  generic map(COUNTER_WIDTH =>
> COUNTER_WIDTH)  port map( clk=> clk,  rst  => rst,
> en  => en,  min_val  => (others => '0'),
>   max_val  => BW_change_rate,  new_output=>
> change_freq_en,  count_out  => open);*
>
>
>
> ___
> 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] Problems receiving with B210 and X310

[Michael Dickens via USRP-users]

Hi Andrew - That's certainly interesting! Have you tried a more recent
version of UHD? 3.14.1.1 is the latest release, and it might contain fixes
for the issue you're having. Worth a try IMHO. - MLD

On Mon, Oct 28, 2019 at 2:41 PM Boggio-Dandry, Andrew via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello,
>
>
>
> We are having trouble with spikes in received signals. This happens with
> both the X310 and B210. We have a stable setup using Ubuntu 17.10 and UHD
> 3.10.3.0. There are no receive problems. On Ubuntu 18.04 and/or Ubuntu
> 16.04, however, no matter the version of UHD these spikes appear. For
> example, our Ubuntu 17.10 running UHD 3.10.3.0 with a B210 and Ubuntu 18.04
> running UHD 3.10.3.0 with a B210 were both set to receive and captured the
> following *at the same time* using rx_samples_to_file --freq 2.484e9
> --rate 20e6 --gain 20 --args --wirefmt sc16 --file file_13.dat --duration 1.
> We did not transmit anything, we just wanted to capture the noise.
>
>
>
> *Plotting real part of received noise from Ubuntu 17.10, UHD 3.10.3.0
> setup:*
>
>
>
> *Plotting real part of received noise from Ubuntu 18.04, UHD 3.10.3.0
> setup:*
>
>
>
> As you can see, the spikes appear on the B210 capture on the machine
> running Ubuntu 18.04 with UHD 3.10.3.0. When you zoom in very close on the
> spikes:
>
>
>
>
>
> Any idea why this may be happening? Any suggestions would be appreciated.
>
>
>
>
>
> [image: Logo] 
>
> *Andrew Boggio-Dandry* *| Ph.D. Student*
>
> *Department of Electrical & Computer Engineering,*
>
> *University at Albany, State University of New York*
> *e:* aboggio-dan...@albany.edu
>
> *w:* https://www.andrewboggio.com
> *m:* 518-687-3102
>
> [image: facebook icon]  [image:
> twitter icon]  [image: linkedin icon]
>  [image: instagram icon]
> 
>
>
>
>
>
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>


-- 
Michael Dickens
Ettus Research Technical Support
Email: supp...@ettus.com
Web: https://ettus.com/
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] Problems receiving with B210 and X310

[Boggio-Dandry, Andrew via USRP-users]

Hello,

We are having trouble with spikes in received signals. This happens with both 
the X310 and B210. We have a stable setup using Ubuntu 17.10 and UHD 3.10.3.0. 
There are no receive problems. On Ubuntu 18.04 and/or Ubuntu 16.04, however, no 
matter the version of UHD these spikes appear. For example, our Ubuntu 17.10 
running UHD 3.10.3.0 with a B210 and Ubuntu 18.04 running UHD 3.10.3.0 with a 
B210 were both set to receive and captured the following at the same time using 
rx_samples_to_file --freq 2.484e9 --rate 20e6 --gain 20 --args --wirefmt sc16 
--file file_13.dat --duration 1. We did not transmit anything, we just wanted 
to capture the noise.

Plotting real part of received noise from Ubuntu 17.10, UHD 3.10.3.0 setup:
[cid:image001.png@01D58D9D.AB734DA0]

Plotting real part of received noise from Ubuntu 18.04, UHD 3.10.3.0 setup:
[cid:image002.png@01D58D9D.AB734DA0]

As you can see, the spikes appear on the B210 capture on the machine running 
Ubuntu 18.04 with UHD 3.10.3.0. When you zoom in very close on the spikes:

[cid:image003.jpg@01D58D9D.AB734DA0]

Any idea why this may be happening? Any suggestions would be appreciated.


[Logo]
Andrew Boggio-Dandry | Ph.D. Student
Department of Electrical & Computer Engineering,
University at Albany, State University of New York
e: aboggio-dan...@albany.edu
w: https://www.andrewboggio.com
m: 518-687-3102
[facebook icon] [twitter icon] 
  [linkedin icon] 
  [instagram icon] 




___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Expected FPGA compatibility number mismatch

[Nate Temple via USRP-users]

Hi Adnan,

Sorry for the delay in response, this email fell through the cracks. Is
this still an outstanding issue for you?

Regards,
Nate Temple

On Wed, Sep 11, 2019 at 8:33 AM Quadri,Adnan via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello,
>
> We were working on the Schimdl Cox and OFDM Equalizer blocks.
>
> We updated to the recent version of UHD and did the installation manually.
> There is a rfnoc installation as well, done earlier. (UHD in rfnoc is 4.0
> but the new one is 3.14)
>
> With the newly installed UHD and few changes, we could build FPGA image
> for Schmidl Cox and OFDM Equalizer.
>
> However, when we run the gnuradio flowgraph (which contains blocks
> required to setup a OFDM receiver), we get the following RunTime error -
>
> *RuntimeError: RuntimeError: Expected FPGA compatibility number 36, but
> got 35:*
>
> *The FPGA image on your device is not compatible with this host code
> build. *
>
> *Download the appropriate FPGA images for this version of UHD. *
>
> *Please run: *
>
>
> * "/home/sdr/rfnoc/lib/uhd/utils/uhd_images_downloader.py" *
>
>
> *Then burn a new image to the on-board flash storage of your *
>
> *USRP X3xx device using the image loader utility. Use this command: *
>
>
> *"/home/sdr/rfnoc/bin/uhd_image_loader"
> --args="type=x300,addr=192.168.10.2" *
>
>
> Should I uninstall rfnoc setup. I have already downloaded the images in
> the newly installed UHD directory.
>
> I built the image using uhd_image_builder and image_loader from the newly
> installed UHD directory. For environment setup for the new UHD I used the
> setup_env.sh script from rfnoc folder.
>
>
> Thanks,
> Adnan
> ___
> 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] cannot gr-uhd in poky

[Philip Balister via USRP-users]

Ettus seems to only maintain the uhd recipe for their embedded products.
You can find it in their meta-ettus layer. I'm not sure how easy it is
to add that and build for people using non-embedded USRP's with boards
like the wandboard. I'd love to see a pull request so meta-sdr can fully
support usrp's and things like wandboards etc again.

Philip

On 10/28/19 9:37 AM, Wael Ali wrote:
> Dear all,
> 
> I'm building a new poky yocto image with gnuradio and uhd pre-installed for
> a wandboard, and I'm using meta-sdr (sumo) layer, and I'm bitbaking a
> gnuradio-dev-image.
> And the problem is,
> 1- when I used the default recipes in meta-sdr sumo branch, uhd package
> gives a compilation error.
> 2- then I changed to uhd 3.13 but I kept all recipes in sumo branch as the
> same, after doing this, bitbake gives no errors, but after finishing, I
> didn't find any uhd installed.
> 3- I've tried many things for example,
>  - I add "uhd" to PACKAGECONFIG in gnuradio core recipe.
>  - I've created a new image recipe (gnuradio-custom-image.bb) where
> I manually add uhd and uhd-examples in "CORE_IMAGE_EXTRA_INSTALL".
>  - I changed all meta-sdr to "master" branch and I faced a
> integration problem with other layers as they are all "sumo" branch.
> 4- in all my trails I always get a gnuradio package with gr-uhd missing.
> 
> I hope I was missing something, and it's easy to solve.
> please I need help with this,
> thanks in advance
> 

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] cannot gr-uhd in poky

[Wael Ali via USRP-users]

Dear all,

I'm building a new poky yocto image with gnuradio and uhd pre-installed for
a wandboard, and I'm using meta-sdr (sumo) layer, and I'm bitbaking a
gnuradio-dev-image.
And the problem is,
1- when I used the default recipes in meta-sdr sumo branch, uhd package
gives a compilation error.
2- then I changed to uhd 3.13 but I kept all recipes in sumo branch as the
same, after doing this, bitbake gives no errors, but after finishing, I
didn't find any uhd installed.
3- I've tried many things for example,
 - I add "uhd" to PACKAGECONFIG in gnuradio core recipe.
 - I've created a new image recipe (gnuradio-custom-image.bb) where
I manually add uhd and uhd-examples in "CORE_IMAGE_EXTRA_INSTALL".
 - I changed all meta-sdr to "master" branch and I faced a
integration problem with other layers as they are all "sumo" branch.
4- in all my trails I always get a gnuradio package with gr-uhd missing.

I hope I was missing something, and it's easy to solve.
please I need help with this,
thanks in advance
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com