Re: [USRP-users] RFNoC fifo filling up

[Brian Padalino via USRP-users]

On Wed, Aug 22, 2018 at 5:32 PM Jason Matusiak <
ja...@gardettoengineering.com> wrote:

> 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. So I don't see why it would be an issue if I change
> tdata while tvalid is high and tready is low.
>

Changing tdata after tvalid was asserted while tready is low is a violation
of the AXI4 streaming spec I am pretty sure.  Don't do this.


>
> 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.
>

The computation clock for the rfnoc blocks is around 214MHz.  The radio
sends stuff out at 200MHz, so you will always produce more and faster than
the radio can keep up naturally.  It's inherent in the system.

Are you saying you are producing samples which should have gone out of the
radio by the time you're making more, and the downstream FIFO's are not
cleared out?  This is a different problem altogether.

I guess, if you can go back to the beginning, what exactly is happening
that you are not sure about?  Did you find this out using just simulation,
or did you instrument an ILA inside the FPGA and are observing actual
signals in the FPGA showing this phenomenon?

Sorry for the confusion, but I think I misunderstood your original issue.
Clarification is good to have.

Brian

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

Re: [USRP-users] RFNoC fifo filling up

[Jason Matusiak via USRP-users]

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. So I don't see why it would be an issue if I change tdata while 
tvalid is high and tready is low.
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.
 Original message From: Brian Padalino  
Date: 8/22/18  4:04 PM  (GMT-05:00) To: Jason Matusiak 
 Cc: "USRP-users@lists.ettus.com" 
 Subject: Re: [USRP-users] RFNoC fifo filling up 
On Wed, Aug 22, 2018 at 3:53 PM Jason Matusiak via USRP-users 
 wrote:
This is a long shot, but I have been fighting with my rfnoc block the last few 
days trying to figure out why it won't work.  I am basically combining the 
threshold block and the siggen block (so it takes in values, and spits out data 
based on the siggen parameters).
 
My block has been spitting some samples on startup and then just stops.  
Digging around, what I can see is that the axi_fifo_short's FIFO primitive is 
filling up.  If I add debug to my testbench, I can see that my data is slowly 
losing the war on reading as fast as I am writing.  Once it is full, I end up 
in a deadlock it appears.
 
Since this is somewhat custom, there probably isn't a good answer, but does 
anyone have a suggestion where to look into this?  The main module where I 
think my axi_interfaces are getting screwed up somehow (on my end) is the 
axi_async_stream.v module.
 
ANY help would be appreciated
It sounds like you want your siggen block to be able to produce samples without 
following the flow control coming back to you (tready).
Unfortunately, you can't.  You need to obey tready and stop the generation of 
samples accordingly.
Is this what's happening?  Your siggen block kicks off, and at some point, 
tready goes low, but you still want to push tvalid and tdata out?
Brian
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] RFNoC fifo filling up

[Brian Padalino via USRP-users]

On Wed, Aug 22, 2018 at 3:53 PM Jason Matusiak via USRP-users <
usrp-users@lists.ettus.com> wrote:

> This is a long shot, but I have been fighting with my rfnoc block the last
> few days trying to figure out why it won't work.  I am basically combining
> the threshold block and the siggen block (so it takes in values, and spits
> out data based on the siggen parameters).
>
> My block has been spitting some samples on startup and then just stops.
> Digging around, what I can see is that the axi_fifo_short's FIFO primitive
> is filling up.  If I add debug to my testbench, I can see that my data is
> slowly losing the war on reading as fast as I am writing.  Once it is full,
> I end up in a deadlock it appears.
>
> Since this is somewhat custom, there probably isn't a good answer, but
> does anyone have a suggestion where to look into this?  The main module
> where I think my axi_interfaces are getting screwed up somehow (on my end)
> is the axi_async_stream.v module.
>
> ANY help would be appreciated
>

It sounds like you want your siggen block to be able to produce samples
without following the flow control coming back to you (tready).

Unfortunately, you can't.  You need to obey tready and stop the generation
of samples accordingly.

Is this what's happening?  Your siggen block kicks off, and at some point,
tready goes low, but you still want to push tvalid and tdata out?

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

[USRP-users] RFNoC fifo filling up

[Jason Matusiak via USRP-users]

This is a long shot, but I have been fighting with my rfnoc block the last few 
days trying to figure out why it won't work.  I am basically combining the 
threshold block and the siggen block (so it takes in values, and spits out data 
based on the siggen parameters).
 
My block has been spitting some samples on startup and then just stops.  
Digging around, what I can see is that the axi_fifo_short's FIFO primitive is 
filling up.  If I add debug to my testbench, I can see that my data is slowly 
losing the war on reading as fast as I am writing.  Once it is full, I end up 
in a deadlock it appears.
 
Since this is somewhat custom, there probably isn't a good answer, but does 
anyone have a suggestion where to look into this?  The main module where I 
think my axi_interfaces are getting screwed up somehow (on my end) is the 
axi_async_stream.v module.
 
ANY help would be appreciated
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] ValueError: recv_buff_size must be larger than the recv_frame_size.

[Andrew Danowitz via USRP-users]

Update, I get this error even if I don't use any rfnoc components, and just
use a standard UHD source going into the qt gui time sink.

Thanks,
Andrew

On Wed, Aug 22, 2018 at 11:12 AM, Andrew Danowitz <
and...@whitefoxdefense.com> wrote:

> Hi,
>
> I rebuilt everything using the latest recipes for rfnoc and e3xx-rfnoc.
> Now when I try to run any rfnoc flow-chart on the e310, I get the following
> error:
>
> ValueError: recv_buff_size must be larger than the recv_frame_size.
>
> Even if I just take an rfnoc: radio block and connect it directly to a qt
> time sink, I get:
>
> Initializing block control (NOC ID: 0x5B888C918ACDF7F3)
> thread[thread-per-block[0]: ]: ValueError:
> recv_buff_size must be larger than the recv_frame_size.
>
> Has anyone run into this before? Where are these buffer and frame sizes
> set?
>
> Thanks,
> Andrew
>

-- 

Information contained, linked, or attached to this email and all verbal 
communications from WhiteFox Defense to your entity in the prior 30 days 
constitute proprietary and confidential information unless otherwise 
indicated and is therefore subject to obligations in any executed 
confidentiality agreements. Further, this email is intended solely for the 
use of the individual or entity to whom they are addressed. If you are not 
the intended recipient and this message has been addressed to you in error, 
please promptly notify i...@whitefoxdefense.com 
 and destroy all copies of the message and 
any attachments. This email and attachments may contain technical data as 
defined in the International Traffic In Arms Regulations (ITAR) 22 CFR 
120.10 or the Export Administration Regulations (EAR) 15 CFR Parts 730 – 
780.  Export of this material may be controlled by these regulations and 
may not be exported or transferred to non-U.S. persons without prior 
written approval from the U.S. government.
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] ValueError: recv_buff_size must be larger than the recv_frame_size.

[Andrew Danowitz via USRP-users]

Hi,

I rebuilt everything using the latest recipes for rfnoc and e3xx-rfnoc. Now
when I try to run any rfnoc flow-chart on the e310, I get the following
error:

ValueError: recv_buff_size must be larger than the recv_frame_size.

Even if I just take an rfnoc: radio block and connect it directly to a qt
time sink, I get:

Initializing block control (NOC ID: 0x5B888C918ACDF7F3)
thread[thread-per-block[0]: ]: ValueError:
recv_buff_size must be larger than the recv_frame_size.

Has anyone run into this before? Where are these buffer and frame sizes set?

Thanks,
Andrew

-- 

Information contained, linked, or attached to this email and all verbal 
communications from WhiteFox Defense to your entity in the prior 30 days 
constitute proprietary and confidential information unless otherwise 
indicated and is therefore subject to obligations in any executed 
confidentiality agreements. Further, this email is intended solely for the 
use of the individual or entity to whom they are addressed. If you are not 
the intended recipient and this message has been addressed to you in error, 
please promptly notify i...@whitefoxdefense.com 
 and destroy all copies of the message and 
any attachments. This email and attachments may contain technical data as 
defined in the International Traffic In Arms Regulations (ITAR) 22 CFR 
120.10 or the Export Administration Regulations (EAR) 15 CFR Parts 730 – 
780.  Export of this material may be controlled by these regulations and 
may not be exported or transferred to non-U.S. persons without prior 
written approval from the U.S. government.
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Creating New GR Blocks for E310

[Andrew Danowitz via USRP-users]

When you source environment-setup-armv7ahf-vfp-neon-oe-linux-gnueabi it
points python to the e310/ARM version of Python that comes to the SDK.
Since gr_modtool needs to run on your host system to set up a new OOT
module, the ARM version of python won't work for you. Your best bet is to
open a new terminal, source your e310/setup_env.sh, and then develop your
OOT module as needed. Only source
environment-setup-armv7ahf-vfp-neon-oe-linux-gnueabi
at the end when it's time to build and install your OOT module into your
cross-compile build. Another alternative, do development and testing of
your OOT module on a pybomb prefix set up for x86 gnuradio and just
copy-paste-make-install the directory to your cross-compile prefix at the
end.

On Wed, Aug 22, 2018 at 1:53 AM, shachar J. brown via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi everyone,
>
> I'm having trouble creating a new gr block for my e310.
>
> I compiled uhd and gnuradio from source as instructed in the following
> page:
> https://kb.ettus.com/Software_Development_on_the_E310_and_E312
>
> Now, when I try using the "gr_modtool newmod" command on my development
> device (pc), I receive the following error:
>
>
> user@user-OptiPlex-7040:~/prefix/src$ gr_modtool newmod DF_project
> Traceback (most recent call last):
>   File 
> "/home/user/prefix/sysroots/x86_64-oesdk-linux/usr/lib/python2.7/site.py",
> line 553, in 
> main()
>   File 
> "/home/user/prefix/sysroots/x86_64-oesdk-linux/usr/lib/python2.7/site.py",
> line 535, in main
> known_paths = addusersitepackages(known_paths)
>   File 
> "/home/user/prefix/sysroots/x86_64-oesdk-linux/usr/lib/python2.7/site.py",
> line 266, in addusersitepackages
> user_site = getusersitepackages()
>   File 
> "/home/user/prefix/sysroots/x86_64-oesdk-linux/usr/lib/python2.7/site.py",
> line 241, in getusersitepackages
> user_base = getuserbase() # this will also set USER_BASE
>   File 
> "/home/user/prefix/sysroots/x86_64-oesdk-linux/usr/lib/python2.7/site.py",
> line 230, in getuserbase
> from sysconfig import get_config_var
>   File 
> "/home/user/prefix/sysroots/x86_64-oesdk-linux/usr/lib/python2.7/sysconfig.py",
> line 10, in 
> 'stdlib': '{base}/'+sys.lib+'/python{py_version_short}',
> AttributeError: 'module' object has no attribute 'lib'
>
>
> Note: I've set up the environment using the  
> "environment-setup-armv7ahf-vfp-neon-oe-linux-gnueabi"
> in the prefix directory, as I've done while compiling uhd and gnuradio.
>
> Note2: The sdk is seemingly not well supported, and I had to install six
> (a VOLK dependency) manually to complete the gnuradio compilation.
>
> Thanks for your time,
> Steve
>
>
>
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>

-- 

Information contained, linked, or attached to this email and all verbal 
communications from WhiteFox Defense to your entity in the prior 30 days 
constitute proprietary and confidential information unless otherwise 
indicated and is therefore subject to obligations in any executed 
confidentiality agreements. Further, this email is intended solely for the 
use of the individual or entity to whom they are addressed. If you are not 
the intended recipient and this message has been addressed to you in error, 
please promptly notify i...@whitefoxdefense.com 
 and destroy all copies of the message and 
any attachments. This email and attachments may contain technical data as 
defined in the International Traffic In Arms Regulations (ITAR) 22 CFR 
120.10 or the Export Administration Regulations (EAR) 15 CFR Parts 730 – 
780.  Export of this material may be controlled by these regulations and 
may not be exported or transferred to non-U.S. persons without prior 
written approval from the U.S. government.
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] standard RFNoC block controller missing?

[Daniel Rauschen via USRP-users]

Hi EJ,

you are making good points there.
I have to investigate a little bit more, because I kind of assumed that 
it had to be the spp parameter.

My RFNoC graph is a Rx-Tx loop back. I will try a clean install next week.
Did the axi interface behavior change, or why should I expect to change 
my verilog code depending on uhd versions?


Daniel

On 22.08.2018 03:52, EJ Kreinar wrote:

Hi Daniel,

First,  a general note... The "warnings" you point out here are a red 
herring -- it's just a change in logging verbosity for the more recent 
UHD that does not indicate any fundamental behavior changes.


> My custom block jgen_0 depends on the correct samples per packet 
(spp) value, which is somehow ignored by the uhd driver.
> This makes my jgen_0 block fail to work. With one of the older 
versions of uhd it worked like a charm.


Ah! This sounds a real problem. How are you using "spp"? Is this 
passed as a command line parameter? What's your RFNoC graph look like? 
I've noticed in some cases the spp parameter does not always get 
propagated (or used) correctly in the corresponding FPGA blocks, and 
each block has a capability to edit its output SPP as needed. There 
may be any variety of places where the spp parameter behavior deviates 
between software versions.


Also, how are you debugging the SPP failure? That is, what makes you 
think the SPP is wrong? I'll also mention depending on the versions of 
uhd you're using, you may require corresponding FPGA changes.


EJ



On Tue, Aug 21, 2018 at 1:35 PM Daniel Rauschen 
> wrote:


Since I get the before mentioned warnings I get those three, too.

[WARNING] [RFNOC] Assuming max packet size for 0/Radio_0
[WARNING] [RFNOC] Assuming max packet size for 0/jgen_0
[WARNING] [RFNOC] Assuming max packet size for 0/DmaFIFO_0

My custom block jgen_0 depends on the correct samples per packet
(spp) value, which is somehow ignored by the uhd driver.
This makes my jgen_0 block fail to work. With one of the older
versions of uhd it worked like a charm.

Daniel

On 21.08.2018 18:03, EJ Kreinar wrote:

What makes you think your build environment is wrong?

Everything you've showed so far seems to be working as usual...

EJ

On Tue, Aug 21, 2018, 10:50 AM Daniel Rauschen
mailto:daniel.rausc...@fkie.fraunhofer.de>> wrote:

Hi EJ,

if I am not wrong, then then my build environment is broken :(
With these two warnings my whole project does not run.
I will try to revert to a stable release of 3.12.

Daniel

On 21.08.2018 13:11, EJ Kreinar wrote:

Hi Daniel,

Fortunately, you're not doing anything wrong!

The warning indicates UHD could not find a *custom* block
controller for that particular block. Therefore, UHD
attaches the default block controller instead. The DDC and
DUC, for example, have custom block controllers and will not
show that warning. You can find block controller source code
at uhd/host/lib/rfnoc, if I remember correctly.

EJ

On Tue, Aug 21, 2018, 6:31 AM Daniel Rauschen via USRP-users
mailto:usrp-users@lists.ettus.com>> wrote:

Hi all.

I upgraded recently to the latest UHD master branch with
-DENABLE_RFNOC=ON (fpga is also on master). So I did
pretty much the
tutorial, but everything on master branch...When I build
a custom FPGA
Image for a x310 I get the following warning after
flashing and running
uhd_usrp_probe:

[WARNING] [RFNOC] Can't find a block controller for key
FFT, using
default block controller!
[INFO] [0/FFT_1] Initializing block control (NOC ID:
0xFF70)
[WARNING] [RFNOC] Can't find a block controller for key
FIFO, using
default block controller!
[INFO] [0/FIFO_0] Initializing block control (NOC ID:
0xF1F0)

What am I doing wrong?

With best regards,

Daniel




___
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] X310 RFNOC image 8 bytes too large

[Andreas Leuenberger via USRP-users]

Hi all,

I try to build a RFNOC FPGA image for the USRP X310 according to the 
"Getting Started with RFNoC Development" web page 
(https://kb.ettus.com/Getting_Started_with_RFNoC_Development).

Command:
$ ./uhd_image_builder.py window fft -d x310 -t X310_RFNOC_HG -m 5 
--fill-with-fifos


The build process is successful with several critical warnings (see the 
attachment with the output of the build process).


When I try to load to new image, the error message "The specified FPGA 
image is too large" aborts the process.

My command to load the FPGA image:
$ uhd_image_loader --args "type=x300,addr=192.168.40.2" --fpga-path 
~/workarea-rfnoc/uhd/fpga-src/usrp3/top/x300/build/usrp_x310_fpga_RFNOC_HG.bit
[INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800; 
UHD_4.0.0.rfnoc-devel-788-g1f8463cc
Error: RuntimeError: The specified FPGA image is too large: 15878040 vs. 
15878032


Do you have any idea what is going wrong? And do I have to worry about 
the critical warnings?


Versions:
FPGA (https://github.com/EttusResearch/fpga.git): branch: rfnoc-devel, 
last tag: v3.12.0.0, commit 1b40696a7ede5c2593f36276071460f08bbf24b2, 
Author: Martin Braun , Date:   Thu Jun 14 
18:45:39 2018 -0700

Vivado: v2017.4_AR70455
Python 2.7.12

Thank you for your help,
andreas

palindrome@palindrome1001:~/workarea-rfnoc/uhd/fpga-src/usrp3/tools/scripts$ 
./uhd_image_builder.py window fft -d x310 -t X310_RFNOC_HG -m 5 
--fill-with-fifos
--Using the following blocks to generate image:
* window
* fft
Adding CE instantiation file for 'X310_RFNOC_HG'
changing temporarily working directory to 
/home/palindrome/workarea-rfnoc/uhd/fpga-src/usrp3/tools/scripts/../../top/x300
Setting up a 64-bit FPGA build environment for the USRP-X3x0...
- Vivado: Found (/opt/Xilinx/Vivado/2017.4/bin)

Environment successfully initialized.
make -f Makefile.x300.inc bin NAME=X310_RFNOC_HG ARCH=kintex7 
PART_ID=xc7k410t/ffg900/-2 BUILD_1G=1 BUILD_10G=1 SFP0_1GBE=1 SFP1_10GBE=1  
RFNOC=1 X310=1  TOP_MODULE=x300 EXTRA_DEFS="BUILD_1G=1 BUILD_10G=1 SFP0_1GBE=1 
SFP1_10GBE=1  RFNOC=1 X310=1 "
make[1]: Entering directory 
'/home/palindrome/workarea-rfnoc/uhd/fpga-src/usrp3/top/x300'
BUILDER: Checking tools...
* GNU bash, version 4.3.48(1)-release (x86_64-pc-linux-gnu)
* Python 2.7.12
* Vivado v2017.4_AR70455 (64-bit)
Using parser configuration from: 
/home/palindrome/workarea-rfnoc/uhd/fpga-src/usrp3/top/x300/dev_config.json
[00:00:00] Executing command: vivado -mode batch -source 
/home/palindrome/workarea-rfnoc/uhd/fpga-src/usrp3/top/x300/build_x300.tcl -log 
build.log -journal x300.jou
CRITICAL WARNING: [filemgmt 20-1440] File 
'/home/palindrome/workarea-rfnoc/uhd/fpga-src/usrp3/top/x300/build-ip/xc7k410tffg900-2/ddr3_32bit/ddr3_32bit/user_design/rtl/clocking/mig_7series_v4_0_tempmon.v'
 already exists in the project as a part of sub-design file 
'/home/palindrome/workarea-rfnoc/uhd/fpga-src/usrp3/top/x300/build-ip/xc7k410tffg900-2/ddr3_32bit/ddr3_32bit.xci'.
 Explicitly adding the file outside the scope of the sub-design can lead to 
unintended behaviors and is not recommended.
[00:00:12] Current task: Initialization +++ Current Phase: Starting
[00:00:12] Current task: Initialization +++ Current Phase: Finished
[00:00:12] Executing Tcl: synth_design -top x300 -part xc7k410tffg900-2 
-verilog_define BUILD_1G=1 -verilog_define BUILD_10G=1 -verilog_define 
SFP0_1GBE=1 -verilog_define SFP1_10GBE=1 -verilog_define RFNOC=1 
-verilog_define X310=1 -verilog_define GIT_HASH=32'hf1b40696
[00:00:12] Starting Synthesis Command
CRITICAL WARNING: [Constraints 18-1056] Clock 'FPGA_CLK' completely overrides 
clock 'FPGA_CLK_p'.
CRITICAL WARNING: [Vivado 12-4739] set_clock_groups:No valid object(s) found 
for '-group [get_clocks bus_clk]'. 
[/home/palindrome/workarea-rfnoc/uhd/fpga-src/usrp3/top/x300/timing.xdc:72]
CRITICAL WARNING: [Vivado 12-4739] set_clock_groups:No valid object(s) found 
for '-group [get_clocks ioport2_clk]'. 
[/home/palindrome/workarea-rfnoc/uhd/fpga-src/usrp3/top/x300/timing.xdc:72]
CRITICAL WARNING: [Vivado 12-4739] set_clock_groups:No valid object(s) found 
for '-group [get_clocks ioport2_clk]'. 
[/home/palindrome/workarea-rfnoc/uhd/fpga-src/usrp3/top/x300/timing.xdc:73]
CRITICAL WARNING: [Vivado 12-4739] set_clock_groups:No valid object(s) found 
for '-group [get_clocks rio40_clk]'. 
[/home/palindrome/workarea-rfnoc/uhd/fpga-src/usrp3/top/x300/timing.xdc:73]
CRITICAL WARNING: [Vivado 12-4739] set_clock_groups:No valid object(s) found 
for '-group [get_clocks bus_clk]'. 
[/home/palindrome/workarea-rfnoc/uhd/fpga-src/usrp3/top/x300/timing.xdc:74]
CRITICAL WARNING: [Vivado 12-4739] set_clock_groups:No valid object(s) found 
for '-group [get_clocks radio_clk]'. 
[/home/palindrome/workarea-rfnoc/uhd/fpga-src/usrp3/top/x300/timing.xdc:74]
CRITICAL WARNING: [Vivado 12-4739] set_clock_groups:No valid object(s) found 
for '-group [get_clocks bus_clk_div2]'. 
[/home/palindrome/workarea-rfnoc/uhd/fpga-src/usrp3/top/x300/timing.xdc:75]

[USRP-users] Creating New GR Blocks for E310

[shachar J. brown via USRP-users]

Hi everyone,

I'm having trouble creating a new gr block for my e310.

I compiled uhd and gnuradio from source as instructed in the following page:
https://kb.ettus.com/Software_Development_on_the_E310_and_E312

Now, when I try using the "gr_modtool newmod" command on my development
device (pc), I receive the following error:


user@user-OptiPlex-7040:~/prefix/src$ gr_modtool newmod DF_project
Traceback (most recent call last):
  File
"/home/user/prefix/sysroots/x86_64-oesdk-linux/usr/lib/python2.7/site.py",
line 553, in 
main()
  File
"/home/user/prefix/sysroots/x86_64-oesdk-linux/usr/lib/python2.7/site.py",
line 535, in main
known_paths = addusersitepackages(known_paths)
  File
"/home/user/prefix/sysroots/x86_64-oesdk-linux/usr/lib/python2.7/site.py",
line 266, in addusersitepackages
user_site = getusersitepackages()
  File
"/home/user/prefix/sysroots/x86_64-oesdk-linux/usr/lib/python2.7/site.py",
line 241, in getusersitepackages
user_base = getuserbase() # this will also set USER_BASE
  File
"/home/user/prefix/sysroots/x86_64-oesdk-linux/usr/lib/python2.7/site.py",
line 230, in getuserbase
from sysconfig import get_config_var
  File
"/home/user/prefix/sysroots/x86_64-oesdk-linux/usr/lib/python2.7/sysconfig.py",
line 10, in 
'stdlib': '{base}/'+sys.lib+'/python{py_version_short}',
AttributeError: 'module' object has no attribute 'lib'


Note: I've set up the environment using the
"environment-setup-armv7ahf-vfp-neon-oe-linux-gnueabi" in the prefix
directory, as I've done while compiling uhd and gnuradio.

Note2: The sdk is seemingly not well supported, and I had to install six (a
VOLK dependency) manually to complete the gnuradio compilation.

Thanks for your time,
Steve
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com