Re: [USRP-users] DMA FIFO latency with X310

[EJ Kreinar via USRP-users]

Simple math is not working out for me today-- Maybe it's the holidays??

I think a 9000 *byte* packet would be 9000*8/1e9 = 72 microseconds

... However the FFT input needs 8192 *samples* which is 8192*4*8/1e9 = 262
microseconds!

Seems like your latency is driven by sending data over the network here

EJ

On Wed, Dec 30, 2020, 11:37 AM Marcus D Leech 
wrote:

> Simple math.
>
> A 9000 *byte* packet is 72000 *bits*
>
> At 1.0e9 *bits/sec* that’s a latency of 720usec
>
>
>
> Sent from my iPhone
>
> > On Dec 30, 2020, at 8:55 AM, Jorge Arroyo Giganto via USRP-users <
> usrp-users@lists.ettus.com> wrote:
> >
> > 
> > Hi EJ,
> >
> > Yes, I tried replacing the DMA FIFO with a normal FIFO and the latency
> got a bit worse and more irregular (I'm guessing that's due to not
> smoothing that burstiness in the Ethernet interface with the DMA FIFO you
> mentioned).
> >
> > I have just tried your graph suggestion (Host -> FFT -> FIFO -> Host)
> and the latency looks about the same but in the FFT block instead. Also I
> had to use packets with spp=256 in the tx streamer in order to match the
> spp that the FFT block accepts or I would get an error when building the
> streamer. Maybe making the FFT block somehow be able to accept bigger
> packets would decrease the latency?
> >
> > About the theoretical latency for a packet of 8192 bytes you mention,
> shouldn't it be 8192*4 bytes assuming that each sample is a sc16 (2 bytes
> for the real part and 2 bytes for the imaginary part of each sample)? Then
> this latency I am experiencing would make more sense?
> >
> > Thank you so much for your feedback, I will also keep in mind your
> comment about the way I am using RFNoC.
> >
> > Best regards,
> >
> > Jorge
> >
> > ___
> > 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] DMA FIFO latency with X310

[EJ Kreinar via USRP-users]

Can you replace the DMA FIFO with a normal FIFO? The DMA FIFO is mostly
used for continuous streaming-- it provides a data buffer using off-chip
DRAM that smooths out any burstiness in the ethernet interface so there's
no overflows/underruns-- but it should not be needed for your application.

You might try the following rfnoc graph: Host -> FFT -> FIFO -> Host

With that graph you'll be able to directly observe the latency presented to
the FFT block by the ethernet transport only. Using a 1G interface for a
packet of 8192 bytes gives a theoretical best one way latency of 65 us...
It is a long way from 200 us-- but already higher than the FFT compute
time.

Finally, I will add... in my opinion using rfnoc explicitly as a
network-attached coprocessor is probably not an ideal use case. I will
often set up loopback tests like you are doing here, but mostly this is to
validate custom compute blocks and I don't care about latency. Afterwards I
will embed the blocks into stream processing that's attached directly to a
radio.

Best regards,
EJ

On Wed, Dec 30, 2020, 4:15 AM Jorge Arroyo Giganto via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi Nick,
>
> I am running the X310 interface at 1Gbit using the SFP Adapter that came
> with the X310.
>
> At first I fowollowed the advice from Ettus USRP Manual
> 
> of setting the MTU to 1500 and _frame_size=1472 when running at
> 1Gbit, however I actually got better results in terms of latency setting
> the MTU to 9000 and _frame_size=8000. I also tried using other
> intermediate and smaller values but the results didn't get any better.
>
> Best regards,
>
> Jorge
> ___
> 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] Carrier frequency jumps on E310

[EJ Kreinar via USRP-users]

I think we may have found a batch of e310s a few years ago (circa summer
2017 iirc?) that had bad oscillators and were traced back to the TCXO
manufacturer.

I don't remember the exact symptoms off the top of my head but those
discrete frequency jumps look a little familiar

EJ


On Tue, Nov 24, 2020, 2:49 PM Marcus D. Leech via USRP-users <
usrp-users@lists.ettus.com> wrote:

> On 11/24/2020 02:38 PM, Luke Whittlesey wrote:
> > I'm in the process, but it's a lengthy process. There is something
> > messed up with the C API in 3.15, so it doesn't work for me as a
> > simple drop in replacement. Would it be wise to try to jump straight
> > to 4.0?
> The jump to 4.0 might be more traumatic.
>
>
> > On Tue, Nov 24, 2020 at 2:40 PM Marcus D Leech 
> wrote:
> >> R suggest updating to a UHD 3.15 environment first.
> >>
> >> Sent from my iPhone
> >>
> >>> On Nov 24, 2020, at 1:54 PM, Luke Whittlesey <
> luke.whittle...@gmail.com> wrote:
> >>>
> >>> I'm seeing this on two E310s that are a few years old. I just swapped
> >>> the sd card into a brand-new E310 and I am NOT seeing the frequency
> >>> jumps. So, same exact software, but different aged E310s. Is there
> >>> possibly a difference in hardware leading to this?
> >>>
>  On Tue, Nov 24, 2020 at 1:04 PM Luke Whittlesey
>   wrote:
> 
>  I would say they are proportional to frequency. Attached is what it
>  looks like at 5GHz. There are jumps of 400Hz and 220Hz.
> 
> > On Tue, Nov 24, 2020 at 11:50 AM Marcus D Leech <
> patchvonbr...@gmail.com> wrote:
> >
> > Try at lower and higher frequencies—are the jumps the same or
> proportional to frequency?
> >
> > Sent from my iPhone
> >
> >> On Nov 24, 2020, at 11:27 AM, Luke Whittlesey via USRP-users <
> usrp-users@lists.ettus.com> wrote:
> >>
> >> On the E310 I'm seeing discrete jumps in the carrier. The carrier
> will
> >> intermittently jump around in steps of about 50Hz. Sometimes it will
> >> jump by about 200Hz. I've attached a waterfall display, but I don't
> >> know if attachments will make it through.
> >>
> >> My setup is:
> >> E310 SG3
> >> UHD3.11 using the C-api
> >> Timing Reference is "internal"
> >> Center Frequency 1GHz
> >> I/Q signal is a stream of 1,0... for a CW at the carrier
> >>
> >> I can see the same thing when I set the timesource to "gpsdo", but I
> >> wouldn't expect it when I set it to "internal". My gut says that
> this
> >> is being caused by some timesource correction loop. If this is the
> >> case is there a way to disable this?
> >>
> >> Thank you
> >> 
> >> ___
> >> 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] rfnoc questions:‏‏

[EJ Kreinar via USRP-users]

Agree on all points.

A few further thoughts:

> I saw in the article (" Measured Latency Introduced by RFNoC
Architecture" )that the nocshell and the axi wrapper have a big latency
(100nanosec and 1.7microsec) . There is a way to drop down the latency ?

First, I probably would not classify 100 me as "high latency"-- if your ce
clock is at 200 MHz that's just 20 clock cycles! Not too bad.

Second, the root cause of the large latency from the cited paper is because
the crossbar is fundamentally a N-to-N "packetized" switch Before any
data goes onto the crossbar, the noc_shell accumulates a full packet of
data within a fifo in the noc_shell and then the entire packet is sent to
the crossbar at the bus_clk rate. An easy way to decrease the latency, at
the expense of more overhead, is to simply decrease the packet size.
(There's some lower limits here... a packet size of like 4-10 would
probably be troublesome, but I've heard 60ish is a reasonable number and
should decrease latency down to 300 nanoseconds or so assuming ce_clk 200
MHz)

If you would like to fully AVOID the overhead of the packetized crossbar
because you need absolute minimal latency, you could theoretically add
side-channels between rfnoc blocks, or insert your logic into a different
part of the design (like the radio block, perhaps). I have heard of these
strategies working for some people, but I really wouldn't recommend that
for a beginner rfnoc user since you would effectively break all the helpful
utilities that come along with rfnoc as-is (automatic builds,
reusability/modularity of rfnoc blocks, etc).

EJ



On Tue, Aug 11, 2020, 9:32 AM Brian Padalino via USRP-users <
usrp-users@lists.ettus.com> wrote:

> On Tue, Aug 11, 2020 at 6:18 AM Daniel Ozer via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hi everyone,
>> Im just started  developing on the usrp X310 platform and i have some
>> questions :
>>
>> 1. Is the crossbar is capable to transfer data between 2 rfnoc blocks at
>> maximum rate of the crossbar clock ?(bus_clk=187.5MHZ)
>>
>
> Yes.  Each port can handle 200MHz worth of bandwidth, but it cannot handle
> full bandwidth from both radios at the same time.  You'd need multiple
> crossbar ports for that.
>
>>
>> 2. if i have this theoretical chain : rfnoc: block1 ->  rfnoc: block2 ->
>> rfnoc: block3 ->  rfnoc: block4
>>  Is every block can send data to the next block at the maximum rate of
>> the crossbar clk ?
>>
>
> Yes.  The crossbar acts as a switch.
>
>
>>
>> 3. I have a chain :  rfnoc: signal source -> rfnoc: DUC (1M to 200M) ->
>> rfnoc:radio_block.
>> how is it possible that the connection between the duc and the radio
>> block doesn't throw an error because the transfer rate is bigger than the
>> clk speed of the crossbar ?
>>
>
> The bus widths are different between the two domains.  Most everything on
> ce_clk is 32-bit IQ samples, whereas the bus_clk domain is 64-bits wide.
>
>
>>
>> 4. Is it possible to change the crossbar clk to ce_clk=214MHZ instead of
>> bus clk ?
>>
>
> Maybe, but what would be the point?  You'll probably end up not being able
> to close timing on the design, but that's just a guess.
>
>
>>
>> 5. I saw in the article (" Measured Latency Introduced by RFNoC
>> Architecture" )that the nocshell and the axi wrapper have a big latency
>> (100nanosec and 1.7microsec) . There is a way to drop down the latency ?
>>
>
> I don't know how to address this.  Maybe a link to the article and to
> figure out where the "large" latencies are?  What is your target latency?
>
> Brian
> ___
> 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] How to find and link OOT module with gnuradio 3.8?

[EJ Kreinar via USRP-users]

Ron,

Yes, that looks right on target with my results... A little baffling to me
though... linking against OOTs seems like a fairly standard use case but
maybe it's less common than I thought. It's definitely needed for rfnoc
though.


Mohamed Yaaseen,

The change that worked for me was to update GR_CMAKE_DIR in gr-ettus to
${CMAKE_MODULES_DIR)/gnuradio-ettus. Then I rebuilt and installed gr-ettus,
and my OOT could then call find_package(gnuradio-ettus) and link against
gnuradio-ettus.

But I'm really not a cmake expert in any way, so I don't know if this is
the "right" answer. Personally I'm satisfied with the GR_CMAKE_DIR change,
but it does change the package name for downstream users...

I guess the broader question is then... What is "desired" behavior provided
by default from gr_modtool for finding and linking OOTs?

EJ

On Tue, Jun 30, 2020, 10:53 AM Mohamed Yaaseen 
wrote:

> Hello EJ Kreinar,
>
> I just came across this situation. I was trying to create a rfnoc gain
> tutorial oot module using rfnomodtools. But, when I was doing cmake I got
> some errors with respect to find_package(ettus).
> I was just fiddling around with cmakefiles as I am not familiar with cmake
> and stuff.
>
> But, I found a problem with the gr-ettus module itself. In the gr-ettus
> module ettutsConfig.cmake file, there is a line
> *include("${CMAKE_CURRENT_LIST_DIR}/ettusTarget.cmake"). *
> This is the file that rfnoc OOT searches in order to find the
> package ettus. But, while make && make install gr-ettus module installs 
> *gnuradio-ettusTargets.cmake
> *file at the location. Hence, rfnoc OOT module throws an error message
> during cmake.
>
> When I corrected the line in gr-ettus and reinstalled it, my OOT module
> was able to compile  successfully.
>
> But, I am now facing errors during the make process.
>
> I believe the rfnocmodtools template code present inside gr-ettus has not
> been migrated for 3.8 even though gr-ettus is migrated.
>
> In the meantime I will also try to fix the error which is thrown during
> make process. And update you in this thread if I have any success
>
> If you are able to get past the make process also and install it in gr
> 3.8. It would be really great...!!!
>
> Regards,
> Mohamed Yaaseen
>
> On Tue, 30 Jun 2020 at 16:01, EJ Kreinar via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hi gnuradio and usrp-users,
>>
>> I'm trying to update rfnoc OOT modules for gnuradio 3.8 (gasp).
>>
>> But I'm having trouble finding and linking to gr-ettus specifically, and
>> I wonder how we're supposed to call find_package() and then link to
>> OOT modules in general with the updated cmake workflow... Trying to find
>> and link gr-ettus, I've tried a few things...
>>
>> 1) find_package(ettus)
>>
>> I believe this worked against gnuradio-3.7. Now, I get the following
>> error during cmake configure...
>>
>> ```
>> --   No package 'ettus' found
>> CMake Error at /usr/local/lib/cmake/ettus/ettusConfig.cmake:41 (include):
>>   include could not find load file:
>> /usr/local/lib/cmake/ettus/ettusTarget.cmake
>> ```
>>
>> 2) find_package(gnuradio-ettus)
>>
>> This seems more promising, since GR_LIBRARY_FOO seems to
>> install gnuradio-ettus cmake files into the lib/cmake/ettus install
>> location. This fails in cmake configure with the following error:
>>
>> ```
>> CMake Error at gr-theseus/CMakeLists.txt:84 (find_package):
>>   By not providing "Findgnuradio-ettus.cmake" in CMAKE_MODULE_PATH this
>>   project has asked CMake to find a package configuration file provided by
>>   "gnuradio-ettus", but CMake did not find one.
>>
>>   Could not find a package configuration file provided by "gnuradio-ettus"
>>   with any of the following names:
>>
>> gnuradio-ettusConfig.cmake
>> gnuradio-ettus-config.cmake
>>
>>   Add the installation prefix of "gnuradio-ettus" to CMAKE_PREFIX_PATH or
>> set
>>   "gnuradio-ettus_DIR" to a directory containing one of the above files.
>> If
>>   "gnuradio-ettus" provides a separate development package or SDK, be
>> sure it
>>   has been installed.
>> ```
>>
>>
>> Interestingly, if I change the GR_CMAKE_DIR *inside gr-ettus* to point to
>> ${CMAKE_MODULES_DIR)/gnuradio-ettus (
>> https://github.com/EttusResearch/gr-ettus/blob/b69260655e974786ea6e611bd91ab578b13ec72a/CMakeLists.txt#L69),
>> then the gnuradio-ettus cmake modules get installed to
>> lib/cmake/gnuradio-ettus. Then, in my OOT module, calling
>> find_package(gnura

[USRP-users] How to find and link OOT module with gnuradio 3.8?

[EJ Kreinar via USRP-users]

Hi gnuradio and usrp-users,

I'm trying to update rfnoc OOT modules for gnuradio 3.8 (gasp).

But I'm having trouble finding and linking to gr-ettus specifically, and I
wonder how we're supposed to call find_package() and then link to OOT
modules in general with the updated cmake workflow... Trying to find and
link gr-ettus, I've tried a few things...

1) find_package(ettus)

I believe this worked against gnuradio-3.7. Now, I get the following error
during cmake configure...

```
--   No package 'ettus' found
CMake Error at /usr/local/lib/cmake/ettus/ettusConfig.cmake:41 (include):
  include could not find load file:
/usr/local/lib/cmake/ettus/ettusTarget.cmake
```

2) find_package(gnuradio-ettus)

This seems more promising, since GR_LIBRARY_FOO seems to
install gnuradio-ettus cmake files into the lib/cmake/ettus install
location. This fails in cmake configure with the following error:

```
CMake Error at gr-theseus/CMakeLists.txt:84 (find_package):
  By not providing "Findgnuradio-ettus.cmake" in CMAKE_MODULE_PATH this
  project has asked CMake to find a package configuration file provided by
  "gnuradio-ettus", but CMake did not find one.

  Could not find a package configuration file provided by "gnuradio-ettus"
  with any of the following names:

gnuradio-ettusConfig.cmake
gnuradio-ettus-config.cmake

  Add the installation prefix of "gnuradio-ettus" to CMAKE_PREFIX_PATH or
set
  "gnuradio-ettus_DIR" to a directory containing one of the above files.  If
  "gnuradio-ettus" provides a separate development package or SDK, be sure
it
  has been installed.
```


Interestingly, if I change the GR_CMAKE_DIR *inside gr-ettus* to point to
${CMAKE_MODULES_DIR)/gnuradio-ettus (
https://github.com/EttusResearch/gr-ettus/blob/b69260655e974786ea6e611bd91ab578b13ec72a/CMakeLists.txt#L69),
then the gnuradio-ettus cmake modules get installed to
lib/cmake/gnuradio-ettus. Then, in my OOT module, calling
find_package(gnuradio-ettus) finds gr-ettus, and
target_link_libraries( gnuradio-ettus) links successfully.

So: Is this right? Am I missing something obvious here? Should gnuradio OOT
modules set their GR_CMAKE_DIR to gnuradio-?

Thanks for the help!
EJ
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] HELP: needed with RFNoC & gr-ettus & PFB

[EJ Kreinar via USRP-users]

Hi Mohamed,

I'll see if I can field a few of your questions...

3. I am currently pseudo-maintaining theseus-cores repo:
gitlab.com/theseus-cores/theseus-cores By that I mean Im not currently
actively developing anything for it (my spare time available to work on
open source fpga has decreased), but I haven't given up on it :p I've
tested these builds against UHD 3.15 as of approx December 2019.

Part of this repo includes a M/2 polyphase filter bank implementation that
includes fpga-based channel selection (so you don't need to return all
channels from fpga to processor). A couple caveats for your application: I
believe the number of channels is constrained to a power of 2, and I
suspect there's a bug with channel selection for more than 64 channels. But
overall it's probably a decent place to start; several people have used
theseus-cores successfully to test polyphase filtering. Happy to field any
related questions here.

4. I've found the rfnoc 4.0 spec as an app note here:
https://files.ettus.com/app_notes/RFNoC_Specification.pdf

While I'm excited for the 4.0 update, Im afraid I can't provide any better
context on rfnoc 4.0 progress or tooling maturity at this point, hopefully
others can step in with that info!

Hope this helps,
EJ

On Sat, Jun 6, 2020, 5:35 AM Mohamed Yaaseen 
wrote:

> Hello Guys,
>   recently I have started looking into the RFNoC platform. I have
> successfully installed RFNoC and was able to build fpga images with
> default pre-built modules like fft etc. I haven't; however started with the
> gain module from "Getting started tutorial"  .
>
> My system setup,
>
> USRP x310  with XG image (connected to PC using dual 10 Gig Ethernet)
>
> uhd -  UHD 3.15 LTS branch
> gnuradio --   maint-3.8   branch
> gr-ettus-- maint-3.8  branch
> vivado system edition (with HLS, Model Composer, DSP system generator)
> - 2018.03v
>
> fpga images and code was submoduled as part of uhd hence they are at\
>  ~/{UHD SRC DIR}/fpga-src/usrp3/..
>
> all installed in a custom prefix (~/workspace/installs/stable) without
> pybombs.
> I have couple of questions and errors I got  that I want help with
>
>
>1.  As of this branch UHD 3.15 LTS, it was mentioned I should use
>uhd_image_builder_gui.py or uhd_image_builder.py script. So, when I used
>it, I couldn't find target type  X310_RFNOC_HLS_HG . Is it removed or what
>up with that ?
>2.  Second is with respect to gr-ettus (I came to know that there are
>some major changes going with this in upcoming UHD 4.0 I will come to that
>in later points). So, as per tutorial we have to use rfnodmodtools which is
>part of gr-ettus to create our own OOT  RFNoC module. But, I faced one
>error with it and I  fixed that error (I am not sure if it is a correct
>fix). I have raised an issue here in gr-ettus repo. please anyone let me
>know if this is a issue or if I was doing something wrong. Because the is
>is with respect to path of rfnocmodtools template. Here is the link for the
>issue: https://github.com/EttusResearch/gr-ettus/issues/45
>3. Third, as this will be my first time working with RFNoC and FPGA
>(atleast with Xilinx, I have some experience from my studies).  My main
>interest with RFNoC is that I wanna create a channelizer, for 160MHz and
>split up into 80 channels each of 2 MHz (critically sampled). and take
>everything to the PC for 80x demod & 80x symbol sync. What is the latest
>development in that direction? I got to know a repo called gr-theseus. Is
>it maintained still ? Can I start from there or should I start from
>scratch. I am looking to connect with is anyone working/worked with PFB
>4. Last one, how is the structure gonna change in future with UHD 4.0
>&  gr-ettus gonna, it would really helpful if someone could explain (very
>confucsed with this coz i couldn't find uhd_image_builder etc.) this
>workflow with new updates and what you guys recommend should start with
>3.15 LTS or switch UHD 4.0 because by the I finish PFB i might have to port
>to a completely new workflow. But in any case, I need gnuradio integration
>
>
> I know it is a lot of questions, sorry guys. But, when I started setup
> with RFNoC, I faced many questions like this, and I felt others might have
> these too. These points will allow people who might need them to get their
> answers in a single place.
>
> Any help, answers, suggestions  or improvements  for these questions will
> be really helpful and are highly welcomed !
>
> Thanks and Regards.
> Yaaseen
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Fractional downsampling in rfnoc

[EJ Kreinar via USRP-users]

Hi Snehasish,

A few thoughts...

> 25msps and tried dividing it into 16 channels. I should have returned
625kspsx2 sample rate each channel

Based on your screen shot I'm guessing you started with 10 Msps and used 16
channels to get 625 kHz channel spacing (with 1250 ksps per channel). Is
that correct?

> But you can see the snaphshots, if a tune into 955.4MHz and try to get a
channel on index 0 ie the center freq, it works well and I am able to
decode GSM Burst from it. But if I try to add index 2(which is 955.8MHz),
the amplitude in the spectrum falls and also I am not able to decode any
GSM burst

Is it correct that your "index 2" center frequency is targetting 400 kHz
offset from the center frequency? If so, I dont expect this would work.
Using a channel spacing of 625 kHz, the closest channel you could receive
next to 955.4 MHz would be 956.025 MHz. Based on your screenshot it
actually seems like the peak energy you're looking for may be lower than
the channel frequency by about 200 kHz?

This is one downside of the polyphase channelizer in this particular
implementation. The channel outputs are consistently spaced and cannot be
changed except by moving the sample rate, center frequency, or number of
channels.

EJ

On Fri, Apr 24, 2020 at 8:31 AM Snehasish Kar 
wrote:

> Hello EJ
>
> I tried using your channelizer. Its really a helpful module. The challenge
> I faced when i tried using it with a input sample rate of 25msps and tried
> dividing it into 16 channels. I should have returned 625kspsx2 sample rate
> each channel. But you can see the snaphshots, if a tune into 955.4MHz and
> try to get a channel on index 0 ie the center freq, it works well and I am
> able to decode GSM Burst from it. But if I try to add index 2(which is
> 955.8MHz), the amplitude in the spectrum falls and also I am not able to
> decode any GSM burst. The same happens when i tune 955.8MHz and try to get
> index  14(ie 955.4MHz), I don't see the spectrum, the same happens for 128
> and 256 channel (input sample rate 50msps). Can you please let me know if I
> am going wrong somewhere.   I have attached the snapshots and flow graph
> for your reference. My uhd version is UHD_3.14.0.0-0-unknown.
>
> Regards
> Snehasish
>
>
> --
> *From:* EJ Kreinar 
> *Sent:* Friday, April 24, 2020 4:22 PM
> *To:* Snehasish Kar 
> *Cc:* Jonathon Pendlum ;
> USRP-users@lists.ettus.com 
> *Subject:* Re: [USRP-users] Fractional downsampling in rfnoc
>
> Hi Snehasish,
>
> Since you're already working with theseus-cores, I assume you've found the
> rfnoc polyphase channelizer has channel downselection already integrated
> into rfnoc and gnuradio (brief write up about it here:
> https://www.theseus-cores.com/2019/12/17/rfnoc-deinterleaving-polyphase-channelizer/).
> I believe this worked with UHD-3.14 when I tested last December. Wondering
> if this works for you or if there's other updates you might need?
>
> EJ
>
> On Fri, Apr 24, 2020, 12:56 AM Snehasish Kar via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
> Hello Jonathon
>
> I tried building the fractional downsampler again and was successful to
> build it in this version of UHD: UHD 4.0.0.rfnoc-devel-409-gec9138eb. Also
> there is a channelizer available at
> https://github.com/e33b1711/rfnoc-ppchan . But the problem with this
> channelizer is, it sends almost 25.6msps samples to the host. Also the
> number of packet it sends, creates a overflow in the host even with 10gig
> sfp cable. So what I am planning is to make a de-interleaver, which will be
> responsible for channel down-selection. Please let me know your thoughts on
> this.
>
> Can you please let me know how to set the packet size on any rfnoc block.
>
> Regards
> Snehasish
> --
> *From:* Jonathon Pendlum 
> *Sent:* Sunday, April 19, 2020 8:58 AM
> *To:* Snehasish Kar 
> *Cc:* usrp-users@lists.ettus.com 
> *Subject:* Re: [USRP-users] Fractional downsampling in rfnoc
>
> Hi Snehasish,
>
> I forgot about that error. I actually made an issue about it on their
> repo: https://github.com/SynchronousLabs/rfnoc-SynchronousLabs/issues/2.
> Unless they provide an EDIF or their source code, you can only use their
> code for simulation. Certainly a disappointing oversight on their part.
>
> Jonathon
>
> On Sat, Apr 18, 2020 at 6:21 PM Snehasish Kar 
> wrote:
>
> Hello Jonathon
>
> Tried building the fractional downsampler from synchronous labs and have
> encountered the following error:
> source file was generated for simulation and is not permitted as input to
> synthesis
> [/home/snehasish/rfnoc-SynchronousLabs/rfnoc/fpga-src/fract_dec_filter.vhd:241995]
>
> Can you please help me with it.
>
> Regards
> Snehasish
> --
> *From:* Jonathon Pendlum 
> *Sent:* Friday, April 17, 2020 9:22 PM
> *To:* Snehasish Kar 
> *Cc:* usrp-users@lists.ettus.com 
> *Subject:* Re: [USRP-users] Fractional downsampling in rfnoc
>
> Hello Snehasish,
>
> Unfortunately, the 

Re: [USRP-users] Fractional downsampling in rfnoc

[EJ Kreinar via USRP-users]

Hi Snehasish,

Since you're already working with theseus-cores, I assume you've found the
rfnoc polyphase channelizer has channel downselection already integrated
into rfnoc and gnuradio (brief write up about it here:
https://www.theseus-cores.com/2019/12/17/rfnoc-deinterleaving-polyphase-channelizer/).
I believe this worked with UHD-3.14 when I tested last December. Wondering
if this works for you or if there's other updates you might need?

EJ

On Fri, Apr 24, 2020, 12:56 AM Snehasish Kar via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello Jonathon
>
> I tried building the fractional downsampler again and was successful to
> build it in this version of UHD: UHD 4.0.0.rfnoc-devel-409-gec9138eb. Also
> there is a channelizer available at
> https://github.com/e33b1711/rfnoc-ppchan . But the problem with this
> channelizer is, it sends almost 25.6msps samples to the host. Also the
> number of packet it sends, creates a overflow in the host even with 10gig
> sfp cable. So what I am planning is to make a de-interleaver, which will be
> responsible for channel down-selection. Please let me know your thoughts on
> this.
>
> Can you please let me know how to set the packet size on any rfnoc block.
>
> Regards
> Snehasish
> --
> *From:* Jonathon Pendlum 
> *Sent:* Sunday, April 19, 2020 8:58 AM
> *To:* Snehasish Kar 
> *Cc:* usrp-users@lists.ettus.com 
> *Subject:* Re: [USRP-users] Fractional downsampling in rfnoc
>
> Hi Snehasish,
>
> I forgot about that error. I actually made an issue about it on their
> repo: https://github.com/SynchronousLabs/rfnoc-SynchronousLabs/issues/2.
> Unless they provide an EDIF or their source code, you can only use their
> code for simulation. Certainly a disappointing oversight on their part.
>
> Jonathon
>
> On Sat, Apr 18, 2020 at 6:21 PM Snehasish Kar 
> wrote:
>
> Hello Jonathon
>
> Tried building the fractional downsampler from synchronous labs and have
> encountered the following error:
> source file was generated for simulation and is not permitted as input to
> synthesis
> [/home/snehasish/rfnoc-SynchronousLabs/rfnoc/fpga-src/fract_dec_filter.vhd:241995]
>
> Can you please help me with it.
>
> Regards
> Snehasish
> --
> *From:* Jonathon Pendlum 
> *Sent:* Friday, April 17, 2020 9:22 PM
> *To:* Snehasish Kar 
> *Cc:* usrp-users@lists.ettus.com 
> *Subject:* Re: [USRP-users] Fractional downsampling in rfnoc
>
> Hello Snehasish,
>
> Unfortunately, the standard library of blocks does not have a Fractional
> Decimator. Your best bet is to try to use the one made by Synchronous Labs
> a few years ago. Their code is on github here:
> https://github.com/SynchronousLabs/rfnoc-SynchronousLabs. Since it was
> built, RFNoC has had some changes that will need to be fixed, but I think
> this is your only option versus writing one from scratch.
>
> Jonathon
>
> On Thu, Apr 16, 2020 at 6:35 PM Snehasish Kar via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
> Hello
>
> I am trying to use the RFNOC based M/2 channelizer from
> https://github.com/theseus-cores/theseus-cores/releases/tag/v1.1.0 . I am
> trying to divide 25 MHz spectrum into 124 subchannels each of bandwidth
> 200KHz. I am capturing the signal at 200msps and I need to decimate it to
> 25.6msps(25MHz/128 channels). Please help me in understanding how this can
> be achieved using RFNoC, is there’s any block already defined for
> fractional downsampling.
>
> Thanks & Regards
> Snehasish
>
> Get Outlook for iOS 
> ___
> 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] Modifying RFNoC ddc block for 16 parallel instances

[EJ Kreinar via USRP-users]

Hi Snehasish,

That's good to hear! Out of curiosity what was failing timing?

If you put together a merge request for your fix I'll take a look and try
to merge that in.

EJ

On Fri, Apr 24, 2020, 12:07 AM Snehasish Kar via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello Jonathon
>
> I need to use a sample rate between 20ksps to 1msps.
>
> Btw I tried following Brian's advice about breaking the logic. I was able
> to use to build a fpga image with 2x1:4 DDC block. Though I required 1:16
> DDC block, but still it is great to start working.
>
> @Brian Padalino : Thanks a lot for the help.
>
> Regards
> --
> *From:* Jonathon Pendlum 
> *Sent:* Friday, April 24, 2020 9:00 AM
> *To:* Snehasish Kar 
> *Cc:* Brian Padalino ; usrp-users@lists.ettus.com <
> usrp-users@lists.ettus.com>
> *Subject:* Re: [USRP-users] Modifying RFNoC ddc block for 16 parallel
> instances
>
> Hi Snehasish,
>
> The DDC supports a wide range of sampling rates. Depending on the rates
> you want, some of the DDC filters could be removed to reduce utilization or
> there may be a better architecture to fit your situation. What rates do you
> need to support?
>
> Jonathon
>
> On Thu, Apr 23, 2020 at 3:19 AM Snehasish Kar via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
> Hello Brian
>
> While writing the bitstream it gave an error stung the current design
> didn’t satisfy the timing constraint.
>
> I tried creating 12 blocks of DDC 1 to 2, blocks but that failed too
> saying the placer couldnot place more than 5% of the movable instances in
> the design.
>
> Regards
> Snehasish
>
> Get Outlook for iOS 
> --
> *From:* Brian Padalino 
> *Sent:* Thursday, April 23, 2020 4:19:14 AM
> *To:* Snehasish Kar 
> *Cc:* usrp-users@lists.ettus.com 
> *Subject:* Re: [USRP-users] Modifying RFNoC ddc block for 16 parallel
> instances
>
> On Wed, Apr 22, 2020 at 6:17 PM Snehasish Kar 
> wrote:
>
> Hello Brian
>
> Thanks for your response, actually I tried using DDC 1 to n block as given
> here, but giving 1 to 8 channels have a timing issue, while generating the
> build. So I thought it as an alternative plan.
>
>
> https://gitlab.com/theseus-cores/theseus-cores/-/blob/master/fpga-rfnoc/README.md#dsp-utilsnoc_block_ddc_1_to_n
>
>
> What was the timing issue?  Is it possible for you to break up the logic
> to help relax timing constraints?
>
> Brian
>
> ___
> 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] Block parameters in NOC block testbenches

[EJ Kreinar via USRP-users]

Hi Nick,

I feel like you might be looking for something like this-- just a defparam
inside the testbench after the RFNOC_ADD_BLOCK macro?
https://gitlab.com/theseus-cores/theseus-cores/-/blob/master/fpga-rfnoc/testbenches/noc_block_ddc_1_to_n_tb/noc_block_ddc_1_to_n_tb.sv#L25

Let me know if you had something else in mind though...
EJ

On Fri, Feb 21, 2020, 3:16 PM Nick Foster via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi all,
>
> I'm wondering if there's any good way to instantiate blocks in testbenches
> with testbench-defined block parameters. The macro `RFNOC_ADD_BLOCK takes
> care of defining all the NOC bus interfaces, but there's no place to define
> block parameters.
>
> Say I have a NOC block which takes a parameter N_TAPS. How can I
> instantiate the block in the testbench with a testbench-defined N_TAPS
> parameter without setting it as the default in the block's module?
>
> Nick
> ___
> 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] RFNOC_OOT_SRCS cleared in top/n3xx/Makefile.srcs

[EJ Kreinar via USRP-users]

Ah -- It's fairly common for the "OOT.inc" builds to break between releases
or when new devices are added, so I usually send in the PRs to clean it up.

In this case, I havent tried 3.15 yet, so I wouldnt have found any issues
with the OOT builds yet.

EJ

On Thu, Jan 30, 2020 at 4:03 PM Rob Kossler  wrote:

> EJ,
> I don't quite understand your comments. I'm talking about Ettus code in
> the 3.15 release.
> Rob
>
> On Thu, Jan 30, 2020 at 3:57 PM EJ Kreinar  wrote:
>
>> Whoa there,
>>
>> I havent updated any of my code to UHD-3.15 yet so you're a bit ahead of
>> me! I usually make the relevant PRs if/when OOT build process breaks -- so
>> I'd recommend sending over the relevant PR to fpga repo? Will probably help
>> me a few months down the line :P
>>
>> Thanks!
>> EJ
>>
>> On Wed, Jan 29, 2020 at 5:28 PM Andrew Payne via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> I had the same issues! I just ended up putting my verilog file paths in
>>> Makefile.n3xx.inc and it works. This might need to be fixed unless I did
>>> something wrong.
>>>
>>> On Wed, Jan 29, 2020 at 16:18 Rob Kossler via USRP-users <
>>> usrp-users@lists.ettus.com> wrote:
>>>
 I have been struggling all day with why I can't build my OOT rfnoc
 blocks for the N310 using v3.15.0.0.  It appears that the problem is that
 there is a file top/n3xx/Makefile.srcs that is clearing the RFNOC_OOT_SRCS
 variable after it is set in the users OOT makefile. I just commented the
 line in top/n3xx/Makefile.srcs and that seems to do the trick.  Is this a
 known issue?


 # Makefile.n3xx.inc
 ...
 include $(BASE_DIR)/n3xx/Makefile.OOT.inc
 include $(BASE_DIR)/n3xx/Makefile.srcs
 ...

 # Makefile.srcs
 RFNOC_OOT_SRCS = \
 ___
 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] RFNOC_OOT_SRCS cleared in top/n3xx/Makefile.srcs

[EJ Kreinar via USRP-users]

Whoa there,

I havent updated any of my code to UHD-3.15 yet so you're a bit ahead of
me! I usually make the relevant PRs if/when OOT build process breaks -- so
I'd recommend sending over the relevant PR to fpga repo? Will probably help
me a few months down the line :P

Thanks!
EJ

On Wed, Jan 29, 2020 at 5:28 PM Andrew Payne via USRP-users <
usrp-users@lists.ettus.com> wrote:

> I had the same issues! I just ended up putting my verilog file paths in
> Makefile.n3xx.inc and it works. This might need to be fixed unless I did
> something wrong.
>
> On Wed, Jan 29, 2020 at 16:18 Rob Kossler via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> I have been struggling all day with why I can't build my OOT rfnoc blocks
>> for the N310 using v3.15.0.0.  It appears that the problem is that there is
>> a file top/n3xx/Makefile.srcs that is clearing the RFNOC_OOT_SRCS variable
>> after it is set in the users OOT makefile. I just commented the line in
>> top/n3xx/Makefile.srcs and that seems to do the trick.  Is this a known
>> issue?
>>
>>
>> # Makefile.n3xx.inc
>> ...
>> include $(BASE_DIR)/n3xx/Makefile.OOT.inc
>> include $(BASE_DIR)/n3xx/Makefile.srcs
>> ...
>>
>> # Makefile.srcs
>> RFNOC_OOT_SRCS = \
>> ___
>> 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] Building RFNoC Image with OOT Module on X310 - Module not found

[EJ Kreinar via USRP-users]

Felix, thanks for the catch. That looks like a problem I may have
introduced by accident a few months ago. This PR should fix it, hopefully:
https://github.com/EttusResearch/fpga/pull/47/files

Note I expect this would get merged into master and potentially not
backported to whatever version of uhd-fpga you're using, so I'd recommend
keeping what you have locally if it works for you :D

EJ

On Wed, Jan 8, 2020 at 8:00 AM Felix Greiwe via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi EJ,
>
> thank you for your answer! To make my error more traceable, I created a
> new OOT Module and added the default gain block from rfnoc getting
> started.
>
> I also took your advice and looked at the uhd_image_builder.py script. I
> noticed very strange behaviour, because my print statements suggested,
> that the script did not include my makefile.srcs because it first edited
> the path
>
> /home/lskt/rfnoc/src/rfnoc-blocks_lskt/ to
> /home/lskt/rfnoc/src/rfnoc-blocks_lskt/rfnoc and a bit later to
> /home/lskt/rfnoc/src/rfnoc-blocks_lskt/rfnoc/rfnoc/fpga-src/ .
>
> As you can see two rfnoc's here hence it did not find the makefile.src in
> /fpga-src. The changes (marked with fgr) in the create_oot_include
> here seem to resolve the issue, hopefully helpful for other people too and
> maybe even a major bug?:
>
> def create_oot_include(device, include_dirs):
> """
> Create the include file for OOT RFNoC sources
> """
> oot_dir_list = []
> target_dir = device_dict(device.lower())
> dest_srcs_file = os.path.join(get_scriptpath(), '..', '..', 'top',\
> target_dir, 'Makefile.OOT.inc')
> incfile = open(dest_srcs_file, 'w')
> incfile.write(OOT_SRCS_FILE_HDR)
> if include_dirs is not None:
> for dirs in include_dirs:
> currpath = os.path.abspath(str(dirs))
> if os.path.isdir(currpath) & (os.path.basename(currpath) ==
> "rfnoc"):
> # Case 1: Pointed directly to rfnoc directory
> oot_path = currpath
> elif os.path.isdir(os.path.join(currpath, 'rfnoc')):
> # Case 2: Pointed to top level rfnoc module directory
> oot_path = os.path.join(currpath, 'rfnoc')
> elif os.path.isfile(os.path.join(currpath, 'Makefile.inc')):
> # Case 3: Pointed to a random directory with a Makefile.inc
> oot_path = currpath
> else:
> print('No RFNoC module found at ' +
> os.path.abspath(currpath))
> continue
> if oot_path not in oot_dir_list:
> oot_dir_list.append(oot_path)
> named_path = os.path.join('$(BASE_DIR)',
> get_relative_path(get_basedir(), oot_path))
> incfile.write(OOT_DIR_TMPL.format(oot_dir=named_path))
> if os.path.isfile(os.path.join(oot_path, 'Makefile.inc')):
> # Check for Makefile.inc
> incfile.write(OOT_INC_TMPL)
> elif os.path.isfile(os.path.join(oot_path, 'rfnoc',
> 'Makefile.inc')):
> # Check for Makefile.inc
> incfile.write(OOT_INC_TMPL)
> #elif os.path.isfile(os.path.join(oot_path, 'rfnoc',
> 'fpga-src', 'Makefile.srcs')): # Original
> elif os.path.isfile(os.path.join(oot_path, 'fpga-src',
> 'Makefile.srcs')): # Anders fgr
> # Legacy: Check for fpga-src/Makefile.srcs
> # Read, then append to file
> # curr_srcs = open(os.path.join(oot_path, 'rfnoc',
> 'fpga-src', 'Makefile.srcs'), 'r').read() # Original
> curr_srcs = open(os.path.join(oot_path, 'fpga-src',
> 'Makefile.srcs'), 'r').read() # Anders fgr
> # curr_srcs = curr_srcs.replace('SOURCES_PATH',
> os.path.join(oot_path, 'rfnoc', 'fpga-src', '')) #
> Original
> curr_srcs = curr_srcs.replace('SOURCES_PATH',
> os.path.join(oot_path, 'fpga-src', '')) # Anders fgr
> print('Searching for Makefile.srcs: ' + curr_srcs) #fgr
> incfile.write(OOT_SRCS_TMPL.format(sources=curr_srcs))
> else:
> print('No valid makefile found at ' +
> os.path.abspath(currpath))
> continue
>
> However 30 minutes later in the build I got the next errror and again have
> no idea what to do. My command was:
>
> ./uhd_image_builder.py gain ddc fft -I
> /home/lskt/rfnoc/src/rfnoc-blocks_lskt/ -d x310 -t X310_RFNOC_HG -m 6
> --fill-with-fifos
>
> Using Vivado 2018.3 and UHD 3.15.0.0-124-geb448043
>
>
> Erros are:
>
> ERROR: [DRC MDRV-1] Multiple Driver Nets: Net bus_clk_gen/inst/CLK_OUT4
> has multiple drivers: radio_clk_gen/inst/clkout1_buf/O, and
> bus_clk_gen/inst/clkout4_buf/O.
> ERROR: [DRC MDRV-1] Multiple Driver Nets: Net
> radio_reset_sync/reset_double_sync/synchronizer_false_path/value[9]_9 has
> multiple drivers:
>
> 

Re: [USRP-users] Default RFNoC image for N310 does not compile

[EJ Kreinar via USRP-users]

Ah, Sorry for the confusion. I assume anyone using the split_stream block
is already building FPGA images from source... To clarify, I'm referring to
rebuilding the FPGA images from source using the uhd-fpga repo, which
follows the instructions here:
https://files.ettus.com/manual_archive/v3.14.1.1/html/md_usrp3_build_instructions.html

Depending on the target platform you may also need a Vivado license (or
trial license). You'll want to clone the uhd-fpga repo, then `git checkout
UHD-3.14`, then `git cherry-pick 1102779f`, THEN build the images.

Definitely a bummer there's not a patched image released. I didnt realize
there were images "in the wild" that used split stream block

EJ

On Thu, Dec 19, 2019 at 11:05 AM Jeff S via USRP-users <
usrp-users@lists.ettus.com> wrote:

> EJ,
>
> I'm finding that I have the same problem after installing 3.14.1.1.
>
> I did the following:
>
> $ uhd_images_downloader
> $ uhd_image_loader --args "type=n3xx"
>
>
> which is what I thought we were supposed to do, but I got the same error
> on my uhd_usrp_probe that Robert did.
>
> I'll see if I can figure out how to cherry-pick the fpga branch.  That may
> be more research since I have a lot of new stuff I "git" to learn.
>
> Jeff
>
>
> --
> *From:* USRP-users  on behalf of EJ
> Kreinar via USRP-users 
> *Sent:* Thursday, December 19, 2019 7:44 AM
> *To:* robert.poehlm...@dlr.de 
> *Cc:* USRP-users@lists.ettus.com 
> *Subject:* Re: [USRP-users] Default RFNoC image for N310 does not compile
>
> The split stream bug seems to have been fixed in October on the master
> branch: https://
> github.com/EttusResearch/fpga/commit/1102779f49d44c9e8b88ce7251d203eb62ae26c9 
> (but
> not yet ported onto 3.14)
>
> I just cherry-picked 1102779f onto my uhd-fpga UHD-3.14 and it cleaned it
> up for me.
>
> I assume this will eventually make it to the UHD-3.14 branch? But if not
> the cherry pick works fine
>
> EJ
>
> On Thu, Dec 19, 2019, 4:00 AM Robert via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
> Hi Nate,
>
>
> some news from my side about this issue:
>
> - For v3.15.0.0-rc2, the error shows up when using split_stream or
> packet_resizer block (and possibly others)
>
>
> I then followed your advice and went back to v3.14.1.1, which should be
> stable. Here two problems pop up:
>
> - Timing constraints are no fulfilled (using Viado 2017.4)
>
> - A similar error pops up when probing the device:
>
>
> [INFO] [0/PacketResizer_0] Initializing block control (NOC ID:
> 0x12E5)
> [ERROR] [UHD] Exception caught in safe-call.
>   in ctrl_iface_impl<_endianness>::~ctrl_iface_impl() [with
> uhd::endianness_t _endianness = (uhd::endianness_t)0]
>   at /usr/local/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:52
> this->send_cmd_pkt(0, 0, true); -> EnvironmentError: IOError: Block ctrl
> (CE_10_Port_D0) no response packet - AssertionError: bool(buff)
>   in uint64_t ctrl_iface_impl<_endianness>::wait_for_ack(bool, double)
> [with uhd::endianness_t _endianness = (uhd::endianness_t)0; uint64_t = long
> unsigned int]
>   at /usr/local/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:142
>
> [ERROR] [MPMD] Failure during block enumeration: EnvironmentError:
> IOError: [0/PacketResizer_0] sr_read64() failed: EnvironmentError: IOError:
> Block ctrl (CE_10_Port_D0) no response packet - AssertionError: bool(buff)
>   in uint64_t ctrl_iface_impl<_endianness>::wait_for_ack(bool, double)
> [with uhd::endianness_t _endianness = (uhd::endianness_t)0; uint64_t = long
> unsigned int]
>   at /usr/local/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:142
>
> Error: RuntimeError: Failed to run enumerate_rfnoc_blocks()
>
>
> Is there a fix available for ctrl_iface.cpp?
>
>
> Regards,
>
> Robert
> --
> *Von:* Pöhlmann, Robert
> *Gesendet:* Mittwoch, 11. Dezember 2019 12:14:40
> *An:* Nate Temple
> *Cc:* USRP-users@lists.ettus.com
> *Betreff:* AW: [USRP-users] Default RFNoC image for N310 does not compile
>
>
> Hi Nate,
>
>
> the image does compile now with the patch. However there still seems to be
> s.th. wrong on the host side. When running uhd_usrp_probe, it fails when
> it reaches the split_stream block:
>
>
> [INFO] [0/SplitStream_0] Initializing block control (NOC ID:
> 0x5757)
> [ERROR] [MPMD] Failure during block enumeration: EnvironmentError:
> IOError: [0/SplitStream_0] sr_write() failed: AssertionError: not
> _outstanding_seqs.empty()
>   in uint64_t ctrl_iface_impl<_endianness>::wait_for_ack(bool, double)
> [with uhd::endianness_t _endianness = (uhd::endianness_t)0; uint64_t = long
> unsi

Re: [USRP-users] Default RFNoC image for N310 does not compile

[EJ Kreinar via USRP-users]

The split stream bug seems to have been fixed in October on the master
branch: https://
github.com/EttusResearch/fpga/commit/1102779f49d44c9e8b88ce7251d203eb62ae26c9
(but
not yet ported onto 3.14)

I just cherry-picked 1102779f onto my uhd-fpga UHD-3.14 and it cleaned it
up for me.

I assume this will eventually make it to the UHD-3.14 branch? But if not
the cherry pick works fine

EJ

On Thu, Dec 19, 2019, 4:00 AM Robert via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi Nate,
>
>
> some news from my side about this issue:
>
> - For v3.15.0.0-rc2, the error shows up when using split_stream or
> packet_resizer block (and possibly others)
>
>
> I then followed your advice and went back to v3.14.1.1, which should be
> stable. Here two problems pop up:
>
> - Timing constraints are no fulfilled (using Viado 2017.4)
>
> - A similar error pops up when probing the device:
>
>
> [INFO] [0/PacketResizer_0] Initializing block control (NOC ID:
> 0x12E5)
> [ERROR] [UHD] Exception caught in safe-call.
>   in ctrl_iface_impl<_endianness>::~ctrl_iface_impl() [with
> uhd::endianness_t _endianness = (uhd::endianness_t)0]
>   at /usr/local/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:52
> this->send_cmd_pkt(0, 0, true); -> EnvironmentError: IOError: Block ctrl
> (CE_10_Port_D0) no response packet - AssertionError: bool(buff)
>   in uint64_t ctrl_iface_impl<_endianness>::wait_for_ack(bool, double)
> [with uhd::endianness_t _endianness = (uhd::endianness_t)0; uint64_t = long
> unsigned int]
>   at /usr/local/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:142
>
> [ERROR] [MPMD] Failure during block enumeration: EnvironmentError:
> IOError: [0/PacketResizer_0] sr_read64() failed: EnvironmentError: IOError:
> Block ctrl (CE_10_Port_D0) no response packet - AssertionError: bool(buff)
>   in uint64_t ctrl_iface_impl<_endianness>::wait_for_ack(bool, double)
> [with uhd::endianness_t _endianness = (uhd::endianness_t)0; uint64_t = long
> unsigned int]
>   at /usr/local/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:142
>
> Error: RuntimeError: Failed to run enumerate_rfnoc_blocks()
>
>
> Is there a fix available for ctrl_iface.cpp?
>
>
> Regards,
>
> Robert
> --
> *Von:* Pöhlmann, Robert
> *Gesendet:* Mittwoch, 11. Dezember 2019 12:14:40
> *An:* Nate Temple
> *Cc:* USRP-users@lists.ettus.com
> *Betreff:* AW: [USRP-users] Default RFNoC image for N310 does not compile
>
>
> Hi Nate,
>
>
> the image does compile now with the patch. However there still seems to be
> s.th. wrong on the host side. When running uhd_usrp_probe, it fails when
> it reaches the split_stream block:
>
>
> [INFO] [0/SplitStream_0] Initializing block control (NOC ID:
> 0x5757)
> [ERROR] [MPMD] Failure during block enumeration: EnvironmentError:
> IOError: [0/SplitStream_0] sr_write() failed: AssertionError: not
> _outstanding_seqs.empty()
>   in uint64_t ctrl_iface_impl<_endianness>::wait_for_ack(bool, double)
> [with uhd::endianness_t _endianness = (uhd::endianness_t)0; uint64_t = long
> unsigned int]
>   at /usr/local/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:139
>
> Error: RuntimeError: Failed to run enumerate_rfnoc_blocks()
>
>
>
> Regards,
>
> Robert
> --
> *Von:* Nate Temple 
> *Gesendet:* Dienstag, 10. Dezember 2019 17:57:20
> *An:* Pöhlmann, Robert
> *Cc:* USRP-users@lists.ettus.com
> *Betreff:* Re: [USRP-users] Default RFNoC image for N310 does not compile
>
> Hi Robert,
>
> This patch/line change detailed below should resolve that issue and will
> be included in the official 3.15.0.0 release:
>
> ---
>  usrp3/lib/rfnoc/noc_shell.v | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/usrp3/lib/rfnoc/noc_shell.v b/usrp3/lib/rfnoc/noc_shell.v
> index 927f40a70..732d41afa 100644
> --- a/usrp3/lib/rfnoc/noc_shell.v
> +++ b/usrp3/lib/rfnoc/noc_shell.v
> @@ -267,7 +267,7 @@ module noc_shell
>.o_tdata({set_addr_bclk[8*k+7:8*k],
> set_data_bclk[32*k+31:32*k]}),
>.o_tvalid(set_stb_bclk[k]), .o_tready(set_stb_bclk[k]));
>
> -   localparam [31:0] STR_SINK_FIFO_SIZE_BYTES =
> 2**(STR_SINK_FIFOSIZE[8*k+7:8*k]+3);
> +   localparam [31:0] STR_SINK_FIFO_SIZE_BYTES = (k < INPUT_PORTS) ?
> 2**(STR_SINK_FIFOSIZE[8*k+7:8*k]+3) : 0;
> // "Lines" is the most useful unit for the command FIFO size, since
> // commands take either 2 or 3 lines. Software can do the rest of
> the
> // math to figure out how many actual command packets it can send.
>
>
>
> Regards,
> Nate Temple
>
> On Tue, Dec 10, 2019 at 8:46 AM  wrote:
>
>> Hi Nate!
>>
>>
>>
>> I followed the guide in
>> https://files.ettus.com/manual/md_usrp3_build_instructions.html, thus
>> ended up with Vivado 2018.3 and then later found out this requires UHD
>> 3.15. Thanks for pointing me to the Vivado bug. I thought with 2018.3.1
>> this would be fixed, but apparently that is not the case. Now I went back
>> to 2018.3 (clean re-install) and installed the patch AR#71898. The standard
>> N310 

[USRP-users] uhd_find_devices discovery protocol

[EJ Kreinar via USRP-users]

Hi all,

I'm sure this pops up every now and then, but I'm having trouble finding a
definitive answer.

What protocol is uhd_find_devices using to actually find the Ettus devices?
I seem to recall this is UDP -- are there any specific ports used?

I have low-rate USRPs on a network with switches/routers in the way, and I
need to make sure we're not blocking the uhd_find_devices or other relevant
UHD traffic...

Thanks for the help!
EJ
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] transmitting on two channels with replay block

[EJ Kreinar via USRP-users]

Just to pile on yet another fpga option: Nick Foster and others here have
experimented with custom rfnoc blocks that have two connections to the
rfnoc crossbar rather than just one... Hypothetically, a custom replay
block with a split stream and two crossbar connections (one for each
output) could support the full rate to two different transmitters, rather
than needing to split the crossbar bandwidth across all output ports.

Of course, it does require some serious fpga and software surgery to
support this custom mode, so I'd definitely recommend going with Nate
Temple's userspace DPDK suggestion.

However, I'll also mention something fun... The new iteration of rfnoc,
available on the "master-next" branch of uhd and uhd-fpga (essentially UHD
4.0), has an FPGA architecture that can provide the full crossbar bandwidth
*per port* which means this "hacked" paradigm is supported in the next
version of rfnoc without too much heartburn (theoretically, at least)

EJ

On Wed, Dec 11, 2019, 10:08 AM Nate Temple via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi Thomas,
>
> One option instead of using the Replay block could be to stream 2x 200e6
> from your host.
>
> On the X310, this requires using a SRAM image and DPDK. DPDK support was
> added with UHD 3.14.1.0 for the X310, I'd suggest to use 3.14.1.1 at this
> time though.
>
> Some links on DPDK:
>
> https://www.dpdk.org/
> http://files.ettus.com/manual/page_dpdk.html
>
> I've been able to run 2x2 @ 200e6 with the X310 with DPDK using a 4 GHz
> CPU.
>
> ./benchmark_rate --rx_rate 200e6 --rx_channels 0,1 --tx_rate 200e6
> --tx_channels 0,1 --args
> "addr=192.168.10.2,second_addr=192.168.20.2,use_dpdk=1,num_recv_frames=512,enable_tx_dual_eth=1,skip_ddc=1,skip_duc=1"
>
> num_recv_frames=512 can help if you're seeing overflows.
>
> enable_tx_dual_eth=1 is required for 2x TX @ 200e6
>
> skip_ddc=1,skip_duc=1 can help as well since you'd be sending at full rate.
>
>
>
> Regards,
> Nate Temple
>
> On Wed, Dec 11, 2019 at 7:03 AM Rob Kossler via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> I do not think it is possible using the stock FPGA image.  However, I can
>> think of a couple of possibilities:
>>
>>- On the N310, Ettus includes 4 FIFO blocks (rather than the DmaFIFO
>>which used the off-FPGA RAM for memory), to provide capability for 4x125
>>MS/s streaming. Perhaps if you built an X310 FPGA image with 2 such FIFO
>>blocks, you could use these rather than the DmaFIFO and achieve the 
>> desired
>>streaming.  Note that this requires a Vivado license to build your own 
>> FPGA
>>image, but does not require FPGA experience because you would be building
>>an image with "stock" blocks.  One caution though is that streaming at 
>> this
>>very high rate still requires a high performance host and so it is still
>>possible that you would have underruns if your host could not keep up.  If
>>you go this route, I believe you will likely need to use the "DPDK"
>>capability which is a bit of a pain to configure and get it working
>>properly.
>>- Another possibility is to create a custom RFNoC block that is
>>similar to the replay block but that uses FPGA memory to store a fixed
>>duration waveform and then plays it out cyclically like the replay block.
>>The Ettus 'window' RFNoC block provides a good example of how to store
>>coefficients and play them out repeatedly.  But, making the needed
>>modifications is not a trivial task except for someone who is pretty good
>>at FPGA programming.
>>
>> Given that you were trying the replay block, I'm guessing that your Tx
>> waveforms are of fixed duration.  What is the duration (in number of
>> samples) that you require?
>> Rob
>>
>> On Wed, Dec 11, 2019 at 5:05 AM Thomas Harder 
>> wrote:
>>
>>> Thank you Rob for this comment.
>>>
>>> But I am not sure if I understand you correctly. Do you want to say,
>>> that it is *IMPOSSIBLE* to stream TX two different waveforms
>>> synchronized  on the 2 channels of the x310 with the full bandwidth of
>>> 200MS/s on each channel?
>>>
>>> That is what I am trying the last 6 months full time, starting with
>>> Labview under windows and then UHD under Linux with a Dell Precision 5820
>>> desktop (16GB RAM, Intel Xeon W-2125 CPU@ 4.GHz x8) with MXI
>>> connection, dual 10Gbit connection(Intel X520-DA2), the replay block
>>> recently: always the same result: continuous underruns.
>>>
>>> If you can confirm that this is not possible without an important FPGA
>>> change (because I have no experience in this field and I have not the time
>>> to invest into it), I must search for another solution to create two
>>> different synchronized RF waveforms with 160MHz bandwidth (optical,
>>> electronical,…) because this will be just a part of my experimental setup
>>> but it is crucial to go on .
>>>
>>> I am thankful for any advise,
>>>
>>> Thomas
>>>
>>>
>>>
>>>
>>>
>>> *From: *Rob Kossler 
>>> *Sent: *Tuesday, 

Re: [USRP-users] Configure build for RFNoC block with custom IP

[EJ Kreinar via USRP-users]

Hi Rob,

I do this pretty often, and the uhd-fpga repo does let you use the
Makefile.OOT.inc files to add OOT repos to device builds.

If you follow the Makefile examples in github.com/ejk43/rfnoc-ootexample,
then use the uhd_image_builder.py script to add the OOT repo, it should
recognize the Makefile.inc in the OOT repo and set up the device's
Makefile.OOT.inc for you.

I get the impression others here have had success with this approach too,
but let me know if this doesn't work for you for any reason?

EJ

On Tue, Dec 10, 2019, 5:51 PM Rob Kossler via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi,
> I created my own FFT IP core and corresponding xci file using Vivado and
> created a new RFNoC block to use it, noc_block_myfft.  I was able to
> manually modify the makefile in the rfnoc/testbenches/noc_block_myfft_tb/
> folder to add a new makefile which I created next to the xci file.  I did
> this following an example from the stock noc block testbenches.  This works
> for me.
>
> However, now when I want to build an actual FPGA image, the IP core is not
> found.  I can copy it to usrp3/top/e300/ip/ and then adjust the Ettus
> makefiles accordingly, but this doesn't seem like the best approach.
>
> Is there a preferred way to locate custom IP when used with OOT rfnoc
> blocks and then configure makefiles such that they will be found in the
> build?
> 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

Re: [USRP-users] E312 - Migrating OOT Modules to the USRP

[EJ Kreinar via USRP-users]

There are definitely a few datatype gotchas with nocscript.

In your flowgraph screenshot I'm seeing a parameter with an "int"type. Is
that passed directly to your gain block set_arg? You might want to change
the parameter type to "float" in gnuradio, or cast to float in the entry
box for your gain block (e.g. `float(intnumber)`).

Either way it should be a float type when you call set_arg
EJ



On Fri, Nov 22, 2019, 2:52 PM Jonathan Lockhart 
wrote:

> Well that did do the trick, can't believe I missed that earlier, thanks
> for spotting that EJ.
>
> Now I got a new error. The check for the value of gain is failing, yet the
> default valued loaded should be 1.0 if you look at the XML file. Here is
> the error.
>
> [TRACE] [RFNOC] [NocScript] Executing and asserting code: GE($gain, 0.0)
> AND LE($gain, 32767.0)
> Traceback (most recent call last):
>   File "rfnoc_myGain_usrp.py", line 223, in 
> main()
>   File "rfnoc_myGain_usrp.py", line 212, in main
> tb = top_block_cls(fpga_path=options.fpga_path,
> host_ip_addr=options.host_ip_addr, rx_digital_gain=options.rx_digital_gain,
> rx_freq=options.rx_freq, rx_gain=options.rx_gain)
>   File "rfnoc_myGain_usrp.py", line 117, in __init__
> self.tutorial_gain_0.set_arg("gain", rx_digital_gain)
>   File
> "/home/root/newinstall/usr/lib/python2.7/site-packages/tutorial/tutorial_swig.py",
> line 315, in set_arg
> return _tutorial_swig.gain_sptr_set_arg(self, *args)
> RuntimeError: RuntimeError: [NocScript] Error: Invalid Gain!
>
> So the check message is firing b/c it failed the check, from my
> understanding, but 1.0 as a double is GE to 0.0 and LE to 32767.0. In
> running the alternate bit file with the "digital gain" RFNoC block from the
> gr-ettus files, it also gives the same failure.
>
>
> On Fri, Nov 22, 2019 at 2:05 PM Jonathan Lockhart 
> wrote:
>
>> Well then, ran right over that in my troubleshooting. I am building a new
>> bit file now to validate the change to the XML as I had moved on to
>> something else.
>>
>> I will reply with the results.
>>
>> -Jon
>>
>> On Fri, Nov 22, 2019 at 1:12 PM EJ Kreinar  wrote:
>>
>>> Oh!
>>>
>>> I suspect you want...
>>>
>>> 
>>>   
>>> ...
>>>   
>>> 
>>>
>>> (Rather than two nested "args")
>>>
>>> That ought to do it...
>>> EJ
>>>
>>> On Fri, Nov 22, 2019, 11:55 AM Jonathan Lockhart 
>>> wrote:
>>>
 So here is the trace for the gain block, and it certainly is loading
 the right XML file it seems. 樂

 [DEBUG] [RFNOC] Reading XML file
 /home/root/newinstall/usr/share/uhd/rfnoc/blocks/gain.xml for NOC ID
 0xB7DD64941A952AAC
 [TRACE] [RFNOC] [RFNoC Factory] block_ctrl_base::make()
 [DEBUG] [RFNOC] Reading XML file
 /home/root/newinstall/usr/share/uhd/rfnoc/blocks/gain.xml for NOC ID
 0xB7DD64941A952AAC
 [TRACE] [RFNOC] [RFNoC Factory] Using controller key 'gain' and block
 name 'gain'
 [DEBUG] [RFNOC] Reading XML file
 /home/root/newinstall/usr/share/uhd/rfnoc/blocks/gain.xml for NOC ID
 0xB7DD64941A952AAC
 [INFO] [0/gain_0] Initializing block control (NOC ID:
 0xB7DD64941A952AAC)
 [DEBUG] [0/gain_0] Checking compat number for FPGA component
 `noc_shell': Expecting 5.1, actual: 5.1.
 [TRACE] [0/gain_0] Adding port definition at xbar/gain_0/ports/in/0:
 type = 'sc16' pkt_size = '0' vlen = '0'
 [TRACE] [0/gain_0] Adding port definition at xbar/gain_0/ports/out/0:
 type = 'sc16' pkt_size = '0' vlen = '0'
 [DEBUG] [E300] [E300] Setting up dest map for host ep 112 to be stream 3

 However I don't show it instantiating any of the args. I did vim the
 file and it appears correct (output below).

 
 
 
   gain
   gain
   
 B7DD64941A952AAC
   
   
   
 
   GAIN
   128
 
   
   
   
 
   gain
   double
   1.0
   GE($gain, 0.0) AND LE($gain, 32767.0)
   Invalid Gain!
   
 SR_WRITE("GAIN", IROUND($gain))
   
 
   
   
   
 
   in0
   sc16
 
 
   out0
   sc16
 
   
 


 Regards,
 Jon



 On Fri, Nov 22, 2019 at 10:51 AM Jonathan Lockhart <
 jlockhar...@gmail.com> wrote:

> NVM, I got it set. I am teasing through the long console output now.
> Might of wanted to set the file log instead. Live and learn.
>
> On Fri, Nov 22, 2019 at 10:20 AM EJ Kreinar 
> wrote:
>
>> Good progress, agreed it looks like the gain arg isn't getting
>> created here...
>>
>> If you run with log level trace, rfnoc should (might?) indicate the
>> xml file it loaded. I'd try to find that xml and confirm it looks like 
>> what
>> you expect, with the gain arg entry.
>>
>> Also, perhaps grep your prefix and share directories on the embedded
>> device to search for any other xml 

Re: [USRP-users] E312 - Migrating OOT Modules to the USRP

[EJ Kreinar via USRP-users]

Good progress, agreed it looks like the gain arg isn't getting created
here...

If you run with log level trace, rfnoc should (might?) indicate the xml
file it loaded. I'd try to find that xml and confirm it looks like what you
expect, with the gain arg entry.

Also, perhaps grep your prefix and share directories on the embedded device
to search for any other xml files that might match the noc id or provide
the same "gain" block... I've definitely fought with conflicting xml
definitions before, you might be seeing that here.

EJ

On Fri, Nov 22, 2019, 9:36 AM Jonathan Lockhart 
wrote:

> Hey EJ,
>
> Sorry for being slow I had to dig around to set that UHD Log variable,
> which easy enough it was just a simple export. I then ran uhd_usrp_probe
> with the --tree and setting the fpga to my bit file. Here is the output
> from the probe.
>
> root@ettus-e3xx-sg3:~# uhd_usrp_probe --args="fpga=./newinstall/e300.bit"
> --tree
> [INFO] [UHD] linux; GNU C++ version 4.9.2; Boost_105700;
> UHD_3.14.1.HEAD-0-g0347a6d8
> [INFO] [E300] Loading FPGA image: ./newinstall/e300.bit...
> [INFO] [E300] FPGA image loaded
> [INFO] [E300] Detecting internal GPS
>  [INFO] [E300] GPSDO found
> [INFO] [E300] Initializing core control (global registers)...
>
> [INFO] [E300] Performing register loopback test...
> [INFO] [E300] Register loopback test passed
> [INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD1000)
> [WARNING] [RFNOC] Can't find a block controller for key gain, using
> default block controller!
> [INFO] [0/gain_0] Initializing block control (NOC ID: 0xB7DD64941A952AAC)
> [INFO] [0/DDC_0] Initializing block control (NOC ID: 0xDDC0)
> [WARNING] [RFNOC] Can't find a block controller for key FFT, using default
> block controller!
> [INFO] [0/FFT_0] Initializing block control (NOC ID: 0xFF70)
> /
> /name
> /mboards
> /mboards/0
> /mboards/0/name
> /mboards/0/codename
> /mboards/0/fpga_version
> /mboards/0/fpga_version_hash
> /mboards/0/clock_source
> /mboards/0/clock_source/value
> /mboards/0/clock_source/options
> /mboards/0/sensors
> /mboards/0/sensors/temp
> /mboards/0/sensors/ref_locked
> /mboards/0/sensors/gps_locked
> /mboards/0/sensors/gps_time
> /mboards/0/sensors/gps_position
> /mboards/0/sensors/gps_gpgga
> /mboards/0/sensors/gps_gprmc
> /mboards/0/eeprom
> /mboards/0/dboards
> /mboards/0/dboards/A
> /mboards/0/dboards/A/rx_eeprom
> /mboards/0/dboards/A/tx_eeprom
> /mboards/0/dboards/A/gdb_eeprom
> /mboards/0/dboards/A/rx_frontends
> /mboards/0/dboards/A/rx_frontends/A
> /mboards/0/dboards/A/rx_frontends/A/name
> /mboards/0/dboards/A/rx_frontends/A/sensors
> /mboards/0/dboards/A/rx_frontends/A/sensors/temp
> /mboards/0/dboards/A/rx_frontends/A/sensors/rssi
> /mboards/0/dboards/A/rx_frontends/A/sensors/lo_locked
> /mboards/0/dboards/A/rx_frontends/A/gains
> /mboards/0/dboards/A/rx_frontends/A/gains/PGA
> /mboards/0/dboards/A/rx_frontends/A/gains/PGA/range
> /mboards/0/dboards/A/rx_frontends/A/gains/PGA/value
> /mboards/0/dboards/A/rx_frontends/A/connection
> /mboards/0/dboards/A/rx_frontends/A/enabled
> /mboards/0/dboards/A/rx_frontends/A/use_lo_offset
> /mboards/0/dboards/A/rx_frontends/A/bandwidth
> /mboards/0/dboards/A/rx_frontends/A/bandwidth/value
> /mboards/0/dboards/A/rx_frontends/A/bandwidth/range
> /mboards/0/dboards/A/rx_frontends/A/freq
> /mboards/0/dboards/A/rx_frontends/A/freq/range
> /mboards/0/dboards/A/rx_frontends/A/freq/value
> /mboards/0/dboards/A/rx_frontends/A/dc_offset
> /mboards/0/dboards/A/rx_frontends/A/dc_offset/enable
> /mboards/0/dboards/A/rx_frontends/A/iq_balance
> /mboards/0/dboards/A/rx_frontends/A/iq_balance/enable
> /mboards/0/dboards/A/rx_frontends/A/gain
> /mboards/0/dboards/A/rx_frontends/A/gain/agc
> /mboards/0/dboards/A/rx_frontends/A/gain/agc/enable
> /mboards/0/dboards/A/rx_frontends/A/gain/agc/mode
> /mboards/0/dboards/A/rx_frontends/A/gain/agc/mode/value
> /mboards/0/dboards/A/rx_frontends/A/gain/agc/mode/options
> /mboards/0/dboards/A/rx_frontends/A/filters
> /mboards/0/dboards/A/rx_frontends/A/filters/DEC_3
> /mboards/0/dboards/A/rx_frontends/A/filters/DEC_3/value
> /mboards/0/dboards/A/rx_frontends/A/filters/FIR_1
> /mboards/0/dboards/A/rx_frontends/A/filters/FIR_1/value
> /mboards/0/dboards/A/rx_frontends/A/filters/HB_1
> /mboards/0/dboards/A/rx_frontends/A/filters/HB_1/value
> /mboards/0/dboards/A/rx_frontends/A/filters/HB_2
> /mboards/0/dboards/A/rx_frontends/A/filters/HB_2/value
> /mboards/0/dboards/A/rx_frontends/A/filters/HB_3
> /mboards/0/dboards/A/rx_frontends/A/filters/HB_3/value
> /mboards/0/dboards/A/rx_frontends/A/filters/LPF_BB
> /mboards/0/dboards/A/rx_frontends/A/filters/LPF_BB/value
> /mboards/0/dboards/A/rx_frontends/A/filters/LPF_TIA
> /mboards/0/dboards/A/rx_frontends/A/filters/LPF_TIA/value
> /mboards/0/dboards/A/rx_frontends/A/antenna
> /mboards/0/dboards/A/rx_frontends/A/antenna/options
> /mboards/0/dboards/A/rx_frontends/A/antenna/value
> /mboards/0/dboards/A/rx_frontends/B
> 

Re: [USRP-users] E312 - Migrating OOT Modules to the USRP

[EJ Kreinar via USRP-users]

Okay, great...

You might want to try increasing the log level. Export
UHD_LOG_CONSOLE_LEVEL=trace or debug and try to make sure the correct xml
file is getting applied to the block correctly.

There's also something like a "--tree" parameter in the uhd_usrp_probe so
try running the probe with the tree option to print out the device tree and
look for the arguments assigned to your new block.

Let's see if any of that helps figure out what's going on...
EJ

On Thu, Nov 21, 2019, 4:01 PM Jonathan Lockhart 
wrote:

> Also, when I compiled from the OOT directory for ARM, I used this command,
> which I pieced together from the RFNoC build guide, and the release-4 guide
> for cross-compiling gr-ettus.
>
> cmake
> -DCMAKE_TOOLCHAIN_FILE=~/rfnoc/src/gnuradio/cmake/Toolchains/oe-sdk_cross.cmake
> -DCMAKE_INSTALL_PREFIX=/usr
> -DUHD_FPGA_DIR="/home/jon/rfnoc/src/uhd/fpga-src/" ../
>
> Regards,
> Jon
>
> On Thu, Nov 21, 2019 at 3:48 PM Jonathan Lockhart 
> wrote:
>
>> Greetings EJ,
>>
>> So, from the tutorial, they have you edit the gain.xml file, and this is
>> what I have for it.
>>
>> 
>> 
>> 
>>   gain
>>   gain
>>   
>> B7DD64941A952AAC
>>   
>>   
>>   
>> 
>>   Gain
>>   128
>> 
>>   
>>   
>>   
>> 
>>   gain
>>   double
>>   1.0
>>   GE($gain, 0.0) AND LE($gain, 32767.0)
>>   Invalid Gain!
>>   
>> SR_WRITE("GAIN", IROUND($gain))
>>   
>> 
>>   
>>   
>>   
>> 
>>   in0
>>   sc16
>> 
>> 
>>   out0
>>   sc16
>> 
>>   
>> 
>>
>> There is an args value and it is declared as gain.
>>
>> So from there, I followed your second suggestion and tried to find where
>> it was installed when I did the cross compile. It was not placed in the
>> "GRC_BLOCKS_PATH" of "/share/gnuradio/grc/blocks" like the default RFNoC
>> blocks. It was instead placed in "/share/uhd/rfnoc/bocks" so I added that
>> to the setup.env file, included below.
>>
>> LOCALPREFIX=~/newinstall/usr
>> export PATH=$LOCALPREFIX/bin:$PATH
>> export LD_LOAD_LIBRARY=$LOCALPREFIX/lib:$LD_LOAD_LIBRARY
>> export LD_LIBRARY_PATH=$LOCALPREFIX/lib:$LD_LIBRARY_PATH
>> export PYTHONPATH=$LOCALPREFIX/lib/python2.7/site-packages:$PYTHONPATH
>> export PKG_CONFIG_PATH=$LOCALPREFIX/lib/pkgconfig:$PKG_CONFIG_PATH
>> export
>> GRC_BLOCKS_PATH=$LOCALPREFIX/share/gnuradio/grc/blocks:$GRC_BLOCKS_PATH
>> export UHD_RFNOC_DIR=$LOCALPREFIX/share/uhd/rfnoc/
>> export UHD_IMAGES_DIR=$LOCALPREFIX/share/uhd/images
>> export
>> GRC_BLOCKS_PATH=$LOCALPREFIX/share/uhd/rfnoc/blocks:$GRC_BLOCKS_PATH
>>
>> Unfortunately, after re-sourcing the setup.env, I still get the same
>> message.
>>
>>   File "rfnoc_myGain_usrp.py", line 223, in 
>> main()
>>   File "rfnoc_myGain_usrp.py", line 212, in main
>> tb = top_block_cls(fpga_path=options.fpga_path,
>> rx_gain=options.rx_gain, rx_digital_gain=options.rx_digital_gain,
>> rx_freq=options.rx_freq, host_ip_addr=options.host_ip_addr)
>>   File "rfnoc_myGain_usrp.py", line 117, in __init__
>> self.tutorial_gain_0.set_arg("gain", rx_digital_gain)
>>   File
>> "/home/root/newinstall/usr/lib/python2.7/site-packages/tutorial/tutorial_swig.py",
>> line 315, in set_arg
>> return _tutorial_swig.gain_sptr_set_arg(self, *args)
>> RuntimeError: LookupError: Path not found in tree:
>> /mboards/0/xbar/gain_0/args/0/gain/value
>>
>> I looked at some of your examples (which have been very helpful to get me
>> this far) from what I believe is your github someone linked me. Everything
>> appears to match what it should, for what gain is trying to accomplish.
>>
>> Regards,
>> Jon
>>
>> On Thu, Nov 21, 2019 at 3:27 PM EJ Kreinar  wrote:
>>
>>> Hi Jon,
>>>
>>> The rfnoc "nocscript" xml definition can create arguments and attach to
>>> the device tree like you are trying to set there (it's not compiled
>>> directly, but rather created dynamically from the xml definition)
>>>
>>> Recommended debugging...
>>> 1. Check your OOT gain block xml (in rfnoc/blocks) and make sure it has
>>> a "gain" field in the "args" list. You'll also want to make sure it writes
>>> your desired register, but I don't think you're even getting that far
>>> 2. Make sure the block xml is installed on the e310 embedded prefix and
>>> is found at run time during uhd_usrp_probe and when running your
>>> application. If it's not in the right place or not attaching to your block
>>> then it won't create the gain argument
>>>
>>> I'm guessing it's one of those two possibilities...
>>> EJ
>>>
>>> On Thu, Nov 21, 2019, 3:19 PM Jonathan Lockhart via USRP-users <
>>> usrp-users@lists.ettus.com> wrote:
>>>
 Greetings,

 I was able to get the ARM cross compile working. I removed the build
 directory and re-sourced the dev environment and then the cross-compile
 used the -mfloar=hard flag. Not sure what caused the issue earlier and why
 it wasn't picking it up.

 Now I have a different issue. So I have completed this guide:
 

Re: [USRP-users] Receiving IO Block Error when Using RFNoC Split Stream

[EJ Kreinar via USRP-users]

Cool!

I'll point out that your new build actually got past the old failure point
you noted before, which was immediately after attempting to interact with
the SplitStream RFNOC block!

```
[INFO] [0/SplitStream_0] Initializing block control (NOC ID:
0x5757)
[ERROR] [UHD] Exception caught in safe-call.
[...etc...]
```

I second Nick's thought. Try adding a FIFO after the second split-stream
port.

Though on further inspection, I actually doubt this particular application
would work at all, since it looks like you're trying to push 56 MHz
through the RFNoC FPGA->ARM transport and then through ZMQ. The E310
definitely cannot handle that sort of load, and you might get undefined
behavior in RFNOC fosphor because the underflow will propagate back to the
RFNoC Radio and momentarily stop the RF stream before restarting...

EJ

On Thu, Nov 14, 2019 at 6:05 PM Nick Foster  wrote:

> I also haven't tested to see if this is a gr-ettus limitation or a UHD
> limitation.
>
> On Thu, Nov 14, 2019 at 3:04 PM Nick Foster  wrote:
>
>> You can't have heterogenous output destinations on RFNoC blocks -- i.e.,
>> you can't send one output to the host and one output to another RFNoC block.
>>
>> I'm not sure why this limitation exists as there is no architectural
>> reason I can see.
>>
>> Nick
>>
>> On Thu, Nov 14, 2019 at 12:35 PM Jonathan Lockhart 
>> wrote:
>>
>>> Greetings EJ,
>>>
>>> So went and dug out the E312 b/c I couldn't wait and unfortunately that
>>> didn't resolve the issue I was experiencing. I cherry picked the new
>>> split_stream block, I am using the same flow graph as provided before, but
>>> when it goes to run on the E312 I get the following error.
>>>
>>> Traceback (most recent call last):
>>>   File "rfnoc_fosphor_radio_network_usrp.py", line 281, in 
>>> main()
>>>   File "rfnoc_fosphor_radio_network_usrp.py", line 271, in main
>>> tb.start()
>>>   File
>>> "/home/root/localinstall/usr/lib/python2.7/site-packages/gnuradio/gr/top_block.py",
>>> line 109, in start
>>> top_block_start_unlocked(self._impl, max_noutput_items)
>>>   File
>>> "/home/root/localinstall/usr/lib/python2.7/site-packages/gnuradio/gr/runtime_swig.py",
>>> line 3671, in top_block_start_unlocked
>>> return _runtime_swig.top_block_start_unlocked(*args, **kwargs)
>>> RuntimeError: uhd_rfnoc_SplitStream(9): missing connection from output
>>> port 0
>>>
>>> Looks like something is missing from the split stream. I assume it needs
>>> to be fixed in the verilog.
>>>
>>> I attached a screenshot of the new, cleaned up GNU radio file. I had to
>>> remove a FIFO and switch to using a throttle b/c I wasn't able to get it
>>> all to fit in the bit file.
>>>
>>> Regards,
>>> Jon
>>>
>>> On Wed, Nov 13, 2019 at 10:46 AM Jonathan Lockhart <
>>> jlockhar...@gmail.com> wrote:
>>>
 Greetings EJ,

 Thanks for the info. I haven't had time to grab the new block as my dev
 box is packed for moving this weekend. I will get it downloaded and try it
 as soon as I can.

 Regards,
 Jon

 On Sat, Nov 9, 2019 at 9:48 AM EJ Kreinar  wrote:

> Hi there,
>
> Just want to chime in since I recently went through the upgrade
> process to UHD-3.14...
>
> Can you confirm you're using uhd-3.14? If so, this is actually a
> split stream fpga bug caused by the commit Jon referred to, not the "not
> enough bandwidth" problem.
>
> Fortunately, rather than referring the old commit, the bug seems to
> have been fixed in October on the master branch: https://
> github.com/EttusResearch/fpga/commit/1102779f49d44c9e8b88ce7251d203eb62ae26c9
> (but not yet ported onto 3.14)
>
> I just cherry-picked 1102779f onto my UHD-3.14 and it cleaned it up
> for me.
>
> I assume this will eventually make it to the UHD-3.14 branch? But if
> not the cherry pick works fine
>
> EJ
>
>
> On Fri, Nov 8, 2019, 2:43 PM Jonathan Lockhart via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Jonathon,
>>
>> I will give that a try and see if it works.
>>
>>
>> Nick,
>>
>> If the revert on Split_Stream fails, I will try switching from ce_clk
>> to bus_clk and give that a try.
>>
>>
>> Regards,
>> Jon
>>
>> On Fri, Nov 8, 2019 at 1:52 PM Nick Foster 
>> wrote:
>>
>>> Jonathon (Pendlum), correct me if I'm wrong, but I think this is the
>>> usual split-stream-demands-more-bandwidth-than-RFNoC-bus-allows problem.
>>>
>>> Jonathan (Lockhart), if I'm right, then in your
>>> rfnoc_ce_auto_inst_e310.v, if you change the ce_clk/ce_rst in the
>>> noc_block_split_stream instantiation to bus_clk/bus_rst, this may fix 
>>> the
>>> problem.
>>>
>>> Nick
>>>
>>> On Fri, Nov 8, 2019 at 10:20 AM Jonathon Pendlum <
>>> jonathon.pend...@ettus.com> wrote:
>>>
 Hi Jon,

 Can you try reverting commit 

Re: [USRP-users] running an rfnoc testbench without installing gnuradio

[EJ Kreinar via USRP-users]

Hi Rob,

I do this often. Usually I just clone uhd-fpga adjacent to my repo under
test and then basically call `make xsim` in the testbench folder.

Here's a couple example testbenches:
https://gitlab.com/theseus-cores/theseus-cores/tree/master/fpga-rfnoc/testbenches

With an example script running in a CI system:
https://gitlab.com/theseus-cores/theseus-cores/blob/master/.gitlab-ci.yml#L24

As an aside, you can also do something similar to build rfnoc FPGA images
without needing a gnuradio install. I've set up this repo to contain git
submodules pointing to compatible versions of uhd-fpga and theseus-cores:
https://gitlab.com/theseus-cores/theseus-uhd-builder Just clone with the
extra `--recursive` flag and it will pull the corresponding repos at the
correct SHA1s.

Hope this helps!

EJ

On Wed, Sep 18, 2019, 9:31 PM Rob Kossler via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi,
> I have been designing custom noc blocks and successfully building images
> and running testbenches using a local workstation for which I have sudo
> permission.  But, now I would like to do my builds and run my testbenches
> on a server which is administered by the university for which I do not have
> such permission.
>
> The administrator has installed Vivado 2018.3 and I have successfully run
> the uhd_image_builder script to build the default image for the E310.
> However, now I am wondering if it is possible to run testbenches without
> first installing / building UHD / gnuradio, gr-ettus and perhaps lots of
> other pre-reqs.  Is it possible for me to run testbenches without these
> things?
>
> 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

Re: [USRP-users] RFNoC Issue with 32 Bit Axi Stream | Error in Concat to 64 Bit | VHDL

[EJ Kreinar via USRP-users]

Hi Felix,

Sounds like you've had a lot of progress since you wrote the first email;
well done!

Keep at it and send questions as needed. We're happy to help! Best regards,
EJ

On Tue, Aug 13, 2019 at 3:41 AM Felix Greiwe via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi,
>
> i found myself not to be familiar with the Core Concept of interpreting
> Data in FPGA's as IQ-Data. After i partitioned my 32 Bit Input Data in 16
> Bit I and 16 Bit Q Data, and additionally edited my testbench similar to
> the addsub testbench of one of the pre-installed rfnoc-blocks, my
> testbench passed.
>
> In the following link I stumbled upon some help regarding the testbenches
> and other useful information which helped me a lot.
>
>
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2018-March/056076.html
>
> Best regards,
>
> Felix Greiwe
>
>
>
> > Hello together,
> >
> > recently i started RFNoC development using an USRP x310. After finishing
> > the RFNoC getting started Guide i created an OOT Module including VHDL.
> > First i simply forwarded the Input Data to the output which worked just
> > fine. After that i wanted to add a constant, for example 5_dec., to my
> > signal (32 Bit) and receive the sum as an output in the testbench. Here
> > the problems started:
> > Instead of receiving 5,6,7,8,9 for input of 0,1,2,3,4; i got
> >
> > 5+2^32+2^34
> > 6+2^32+2^34
> > 7+2^32+2^34 etc.
> >
> > I figured out, that i got the right results in 32 Bit, but that somewhere
> > in the axi_wrapper and/or the noc_shell my results gets concatted to 64
> > Bit, always using the first result (here the number 5) as the 32 msb's
> and
> > the actual sum results as the lsb's thus changing my signal.
> >
> > Wondering, i tested some more stuff like just setting the lowest bit of
> 32
> > Bit input Data Vector to one etc. and get the same problems of wrong
> > vector connections.
> >
> > Only when i changed the width parameter of the axi_wrapper to 64 Bit (and
> > also sending 64 Bit Data) i got the expected results.
> >
> > Now my question: Is this a bug or am i maybe using the axi_wrapper wrong?
> > I could not find an error comparing my code to the one of the
> > tutorial_gain block.
> >
> > Any help to understand this is appreciated.
> >
> > Sincerly
> >
> > Felix
> >
> >
> >
> > ___
> > 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] RFNoC Polyphase Channelizer updates

[EJ Kreinar via USRP-users]

Hi Royce,

Can you walk me through your use case real quick?

- How many channels?
- How wide is each channel?
- Are the channels equally spaced?

The polyphase channelizer in theseus-cores currently has a static number of
"max channels" that get instantiated which is not insignificant. We've
discussed exposing a build-time parameter that could scale down the max
number of channels to save some resources, but 1) that hasn't been
implemented yet and 2) I'm not totally confident it would fit in the e310
anyway.

But lets think through your scenario and we can discuss where we'd need the
channelizer to go for it to work... for example, you probably also need the
FPGA-based channel downselection in the channelizer -- the E310 wont be
able to return all channels in real time! Or, we could consider other
approaches -- the DDC channelizer in theseus-cores might be workable if you
have just small number of channels and you need arbitrary spacing/channel
widths.

EJ

On Thu, Aug 8, 2019, 8:52 AM Royce Connerley 
wrote:

> EJ:
>
> I want to pick a few narrowband channels scattered over about 5 MHz.  I
> would like to be able to use your channelizer in an E310.  Do you think it
> could fit in the E310’s FPGA?  When I run uhd_image_builder with just the
> channelizer and a FIFO, I’m seeing the following errors:
>
> ERROR: [Place 30-640] Place Check : This design requires more RAMB36/FIFO
> cells than are available in the target device. This design requires 324 of
> such cell types but only 140 compatible sites are available in the target
> device. Please analyze your synthesis results and constraints to ensure the
> design is mapped to Xilinx primitives as expected. If so, please consider
> targeting a larger device.
> ERROR: [Place 30-640] Place Check : This design requires more RAMB18 and
> RAMB36/FIFO cells than are available in the target device. This design
> requires 703 of such cell types but only 280 compatible sites are available
> in the target device. Please analyze your synthesis results and constraints
> to ensure the design is mapped to Xilinx primitives as expected. If so,
> please consider targeting a larger device.
> ERROR: [Place 30-640] Place Check : This design requires more RAMB36E1
> cells than are available in the target device. This design requires 324 of
> such cell types but only 140 compatible sites are available in the target
> device. Please analyze your synthesis results and constraints to ensure the
> design is mapped to Xilinx primitives as expected. If so, please consider
> targeting a larger device.
>
> Royce Connerley
>
> On Jul 24, 2019, at 6:34 PM, EJ Kreinar  wrote:
>
> Hi Royce,
>
> Phil and I have been working on the channelizer in the theseus-cores repo
> here: gitlab.com/theseus-cores/theseus-cores
>
> The master branch has a (potentially) working channelizer, at least
> according to my recent tests on the x310, as long as the network interface
> supports the desired output rate.
>
> There's also an fpga solution for channel downselection in a branch that
> Phil put together. The ball is in my court to turn the crank and merge to
> master with supporting software, but I haven't gotten much of a chance
> recently.
>
> If you're interested in testing we could definitely use some more people
> to give it a shot :D Let me know if you need a sample bitstream or if you
> can build one yourself.
>
> EJ
>
> On Wed, Jul 24, 2019, 4:39 PM Royce Connerley via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> At the 2018 GRCon, EJ Kreinar spoke about improvements to the RFNoC
>> polyphase channelizer.  Has there been any activity on this?
>>
>> Royce Connerley
>> ___
>> 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] RFNoC Polyphase Channelizer updates

[EJ Kreinar via USRP-users]

Very cool! Feel free to reach out if you have any questions or issues.

Right now it's set up as a M/2 channelizer, and the output rate is 2x input
rate. All the channels come out interleaved and have to be deinterleave in
software (you'll see in the example flowgraph).

Cheers,
EJ

On Thu, Jul 25, 2019, 11:14 AM Nick Foster  wrote:

> I'll test! Forgot about this one and now have a very good use case for it.
> I'll let you know how it goes.
>
> On Wed, Jul 24, 2019 at 4:35 PM EJ Kreinar via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hi Royce,
>>
>> Phil and I have been working on the channelizer in the theseus-cores repo
>> here: gitlab.com/theseus-cores/theseus-cores
>>
>> The master branch has a (potentially) working channelizer, at least
>> according to my recent tests on the x310, as long as the network interface
>> supports the desired output rate.
>>
>> There's also an fpga solution for channel downselection in a branch that
>> Phil put together. The ball is in my court to turn the crank and merge to
>> master with supporting software, but I haven't gotten much of a chance
>> recently.
>>
>> If you're interested in testing we could definitely use some more people
>> to give it a shot :D Let me know if you need a sample bitstream or if you
>> can build one yourself.
>>
>> EJ
>>
>> On Wed, Jul 24, 2019, 4:39 PM Royce Connerley via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> At the 2018 GRCon, EJ Kreinar spoke about improvements to the RFNoC
>>> polyphase channelizer.  Has there been any activity on this?
>>>
>>> Royce Connerley
>>> ___
>>> 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] RFNoC Polyphase Channelizer updates

[EJ Kreinar via USRP-users]

Hi Royce,

Phil and I have been working on the channelizer in the theseus-cores repo
here: gitlab.com/theseus-cores/theseus-cores

The master branch has a (potentially) working channelizer, at least
according to my recent tests on the x310, as long as the network interface
supports the desired output rate.

There's also an fpga solution for channel downselection in a branch that
Phil put together. The ball is in my court to turn the crank and merge to
master with supporting software, but I haven't gotten much of a chance
recently.

If you're interested in testing we could definitely use some more people to
give it a shot :D Let me know if you need a sample bitstream or if you can
build one yourself.

EJ

On Wed, Jul 24, 2019, 4:39 PM Royce Connerley via USRP-users <
usrp-users@lists.ettus.com> wrote:

> At the 2018 GRCon, EJ Kreinar spoke about improvements to the RFNoC
> polyphase channelizer.  Has there been any activity on this?
>
> Royce Connerley
> ___
> 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] RFNoC OOT Issues

[EJ Kreinar via USRP-users]

I havent seen anything too egregious inspecting the files you sent.

A few debugging ideas...
- Are you able to run the simulation testbench correctly for
noc_block_fmdemod?
- I didnt see your file that corresponds with the ip/Makefile.inc (
https://github.com/ejk43/rfnoc-ootexample/blob/master/rfnoc/ip/Makefile.inc).
Do you have that file in your tree, and does it correctly point to the IP
you're trying to build?

If your code is on github link I could take a look that way -- might be
easier to diagnose.
EJ



On Tue, Jul 23, 2019 at 7:53 AM Kirsten S Leong  wrote:

> I've attached the makefiles of the IPs and the other subdirectories in the
> rfnoc folder.
>
>
> Thanks,
>
> Kirsten
> --
> *From:* EJ Kreinar 
> *Sent:* Monday, July 22, 2019 6:36:27 PM
> *To:* Kirsten S Leong 
> *Subject:* Re: RFNoC OOT Issues
>
> Okay sounds good.
>
> Rfnoc devel branch should be fine, but it's now getting a bit old. The
> most updated guidance I would recommend is to use one of their tagged
> branches, say v3.13.x.x or v3.14.x.x. The software needs a cmake compile
> flag "-DENABLE_RFNOC 1" but that's a bit downstream...
>
> The most likely scenario here is that the makefiles for building the IP
> aren't quite right. Can you copy or attach the makefiles from the ip folder
> and subdirectories?
>
> Also, building the IP inside the fpga folder is intended behavior-- it's
> all generated to retarget each part you build for.
>
> EJ
>
> On Mon, Jul 22, 2019, 9:19 PM Kirsten S Leong  wrote:
>
> Yes, I emailed the mailing list. I'll shift over there once I have access
> to my work email.
>
> I pulled from the rfnoc-devel branch and the data width converter is in
> the ip folder of my OOT module.
>
> Thanks,
> Kirsten
> --
> *From:* EJ Kreinar 
> *Sent:* Monday, July 22, 2019 5:33:02 PM
> *To:* Kirsten S Leong 
> *Subject:* Re: RFNoC OOT Issues
>
> Hi Kirsten,
>
> Not sure what you mean by the usrp users site? You should be able to just
> email the mailing list at usrp-users@lists.ettus.com
>
> Anyway, first what version of uhd-fpga are you using?
>
> Also, is this ip from your OOT module?
>
> Feel free to send to the usrp-users mailing list too if you'd like to chat
> there.
>
> Best regards,
> Ej
>
>
>
> On Mon, Jul 22, 2019, 4:52 PM Kirsten S Leong  wrote:
>
> Hello,
>
>
> I first submitted a post to the USRP-users site but it hasn't been
> accepted for a week. It's my first time building an RFNoC image and was
> running into issues on my custom OOT block which uses Xilinx IPs and a data
> width converter. I modeled the Makefiles after the ones in your example
> repository but I get the error:
>
>
> make[1]:***No rule to make target
> '/home/kleong/projects/fpga/usrp3/top/x300/build-ip/xc7k410tffg900-2/axis_dwidth_converter_32to64/axis_dwidth_converter_32to64.xci',
> needed by 'bin'. Stop.
>
> make[1]: Leaving directory '/home/kleong/projects/fpga/usrp3/top/x300'
>
> Makefile:119: recipe for target 'X310_RFNOC_HG' failed
>
> make: *** [X310_RFNOC_HG] Error 2
>
>
> This occurs when I run the command ./uhd_image_builder.py fmdemod -t
> X310_RFNOC_HG -d X310 -I /home/kleong/projects/rfnoc-fmdemod/rfnoc/
> --fill-with-fifos
>
>
> The block can be successfully simulated, but I'm not sure why make file is
> looking for the IPs in the fpga repository.
>
>
> Thanks,
>
> Kirsten
>
>
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] E310 v3.15.0.0 pre-release

[EJ Kreinar via USRP-users]

Hi Brent,

What's the ballpark programming time using uhd_image_loader on the e310?

I currently swap in/out fpga images using the args parameter on the e310
since the fpga size is pretty small. In some cases the application
introspects the required fpga resources, and dynamically chooses the
correct bitstream at runtime... Just wondering if there's a way I can use a
similar workflow with uhd_image_loader on the MPM architecture...

EJ

On Fri, Jun 28, 2019, 9:07 PM Brent Stapleton via USRP-users <
usrp-users@lists.ettus.com> wrote:

> The 3.15 pre-release updates the E310 to use MPM (as you know), and brings
> it more in line with other MPM devices. You'll have to use the
> `uhd_image_loader` to update the FPGA image; device args are not used by
> the UHD session to load the FPGA image. The E310 will still load the FPGA
> image at the beginning of the session (and load an idle image when there is
> no active UHD session), but that image is not determined by the session.
> You shouldn't need to touch it manually (we recommend using
> uhd_image_loader), but the image is stored on the filesystem at
> /lib/firmware/e310_sg1.bin.
>
> Brent
>
> On Fri, Jun 28, 2019 at 5:27 PM d.des via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Marcus Leach wrote:
>> >What happens if you specify an fpga image that doesn't actually
>> >exist?
>> >Does it error out?
>>
>>
>> It ignores the bad file, even though the args seem to be making it
>> pretty far into the process. I still can't find where uhd loads the
>> .bit file.
>>
>> I'm using the version on the referenced SD image from Ettus's site, not
>> bit-baking the latest from meta-ettus.
>>
>> Here's the result for the pre-compiled uhd that was on the SD image at
>> debug log level 0: The results are similar on
>>
>> root@ni-e31x-309C7C2F:~# uhd_usrp_probe --
>> args="fpga=filethatdoesntexist"
>> [INFO] [UHD] linux; GNU C++ version 7.3.0; Boost_106600;
>> UHD_3.15.0.git-0-g6563c537
>> [DEBUG] [MPMD] Discovering MPM devices on port 49600
>> [DEBUG] [MPMD] Discovering MPM devices on port 49600
>> [TRACE] [UDP] Creating udp transport for 10.1.1.255 49600
>> [TRACE] [UDP] Creating udp transport for 127.255.255.255 49600
>> [TRACE] [UDP] Creating udp transport for 10.1.1.255 5
>> [TRACE] [UHD] Device hash: 2130689100
>> [DEBUG] [PREFS] Loaded system config file /etc/uhd/uhd.conf
>> [DEBUG] [PREFS] Loaded user config file /home/root/.uhd/uhd.conf
>> [DEBUG] [PREFS] Loaded system config file /etc/uhd/uhd.conf
>> [DEBUG] [PREFS] Loaded user config file /home/root/.uhd/uhd.conf
>> [DEBUG] [PREFS] Loaded system config file /etc/uhd/uhd.conf
>> [DEBUG] [PREFS] Loaded user config file /home/root/.uhd/uhd.conf
>> [INFO] [MPMD] Initializing 1 device(s) in parallel with args:
>> mgmt_addr=127.0.0.1,type=e3xx,product=e310_sg1,serial=309C7C2,claimed=F
>> alse,fpga=filethatdoesntexist
>> [DEBUG] [MPMD] Claiming mboard 0
>> [DEBUG] [MPMD] Device args:
>> `mgmt_addr=127.0.0.1,type=e3xx,product=e310_sg1,serial=309C7C2,claimed=
>> False,fpga=filethatdoesntexist'. RPC address: 127.0.0.1
>> [TRACE] [MPMD] Initializing mboard, connecting to RPC server address:
>> 127.0.0.1 mboard args:
>> mgmt_addr=127.0.0.1,type=e3xx,product=e310_sg1,serial=309C7C2,claimed=F
>> alse,fpga=filethatdoesntexist number of crossbars: 1
>> [INFO] [MPM.PeriphManager] Found 1 daughterboard(s).
>> [TRACE] [MPMD] MPM reports device info:
>> claimed=True,connection=local,description=E300-Series
>> Device,eeprom_version=,fpga=,fpga_version=1.0,fpga_version_hash=f52a643
>> .clean,mpm_version=1.2,name=ni-e31x-
>> 309C7C2F,pid=30674,product=e310_sg1,rev=4,rpc_connection=local,serial=3
>> 09C7C2,type=e3xx
>> [TRACE] [MPMD] MPM reports dboard info for slot 0:
>> eeprom_version=n/a,pid=272,rev=3,serial=309991A
>> [TRACE] [MPMD] Checking MPM compat number. Expected: 1.2 Actual: 1.2
>> [DEBUG] [MPMD] Initializing mboard 0
>> [DEBUG] [MPMD] Found 3 motherboard sensors.
>> [DEBUG] [MPMD] Found 2 updateable motherboard components.
>> [TRACE] [MPMD] Enumerating RFNoC blocks for xbar 0. Total blocks: 3
>> Base port: 1 Local address: 2
>> [TRACE] [MPMD] Creating new transport to mboard: 0 SID: 00:00>02:10
>> User-defined xport args:
>> mgmt_addr=127.0.0.1,type=e3xx,product=e310_sg1,serial=309C7C2,claimed=F
>> alse,fpga=filethatdoesntexist
>> [TRACE] [MPMD] make_transport(): Creating new transport of type: CTRL
>> [TRACE] [MPMD] make_transport(): request_xport() gave us 1 option(s).
>> [TRACE] [MPMD] Making (muxed) stream with num 0
>> [TRACE] [MPMD] xport info: send_sid==00:00>02:10 recv_sid==02:10>00:00
>> endianness==LE recv_buff_size==10880 send_buff_size==10880
>> [DEBUG] [DEVICE3] Port 0x10: Found NoC-Block with ID 12AD10003310.
>> [DEBUG] [RFNOC] Reading XML file
>> /usr/share/uhd/rfnoc/blocks/radio_e31x.xml for NOC ID
>> 0x12AD10003310
>> [TRACE] [MPMD] Creating new transport to mboard: 0 SID: 00:00>02:11
>> User-defined xport args:
>> mgmt_addr=127.0.0.1,type=e3xx,product=e310_sg1,serial=309C7C2,claimed=F
>> 

Re: [USRP-users] Introducing Theseus Cores: Open source FPGA cores for DSP and SDR

[EJ Kreinar via USRP-users]

Hi Robert,

Thanks for the feedback!

> Do you plan to provide pre-built FPGA images containing Theseus Cores in
the future for certain USRP devices? I guess this would make it even easier
for first time users and would well suit the "batteries included" concept.

I've been considering this idea for a while now. I really like the concept
of having a few prebuilt bitstreams available, especially for usrp users
who maybe haven't gotten into rfnoc or FPGA builds.

On the other hand, I'd need a license to build images for the relevant
targets, and I'm afraid I don't have access to a license I can use in that
capacity. Also the permutations of cores and devices gets pretty large to
support.

So before I chase this idea down any further, I'm curious if there's
broader interest in having prebuilt downloadable bitstreams with a wider
selection of rfnoc cores... As a quick audience poll: anyone interested?
And what devices/configurations would you most like to see?

EJ

On Thu, May 2, 2019, 10:24 AM Robert via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi!
>
> I agree with Johannes that Schmidl OFDM sync would be a nice
> extension.
>
> Do you plan to provide pre-built FPGA images containing Theseus Cores in
> the future for certain USRP devices? I guess this would make it even easier
> for first time users and would well suit the "batteries included" concept.
>
> Cheers
> Robert
>
> -Original Message-
> From: USRP-users [mailto:usrp-users-boun...@lists.ettus.com] On Behalf Of
> Johannes Demel via USRP-users
> Sent: Thursday, May 02, 2019 9:55 AM
> To: usrp-users@lists.ettus.com
> Subject: Re: [USRP-users] Introducing Theseus Cores: Open source FPGA
> cores for DSP and SDR
>
> Hi EJ,
>
> this sounds like a very interesting project. Since you asked for ideas,
> I guess it would be nice to have a Schmidl style OFDM
> synchronization block.
>
> Cheers
> Johannes
>
> Am 29.04.19 um 02:00 schrieb EJ Kreinar via USRP-users:
> > Hi all,
> >
> > I'm very happy to announce the (very modest) release of the Theseus
> > Cores project: https://gitlab.com/theseus-cores/theseus-cores
> >
> > Theseus Cores is designed to provide open source FPGA cores for digital
> > signal processing and software defined radio, plus the means to *use*
> > the FPGA cores in real life In practice, that mostly means FPGA code
> > propagates up through RFNoC blocks which have both UHD and Gnuradio
> > software hooks for users to attach to. In the future it would be great
> > to support other FPGA platforms if there's interest too.
> >
> > So far, Theseus Cores provides the following RFNoC FPGA blocks and
> > corresponding software:
> > - *Polyphase M/2 Channelizer*: A polyphase channelizer where each
> > channel outputs 2x sample rate and is compatible with
> > perfect-reconstruction. Thanks to Phil Vallance for re-implementing the
> > channelizer described in his GRCon 2017 presentation-- it works!
> > - *"1-to-N" DDC Chain*: Parameterized instantiations of "N" independent
> > DDCs, where each DDC is connected to the *first* input (a very basic,
> > brute force channelizer). Note I've seen several mailing list
> > discussions in the past year about 1-to-4 or 1-to-8 DDC channelizers --
> > this block provides the generalized version of that scenario.
> > - *DUC + DDC Rational Resampler*: A "hacked" rational resampler,
> > consisting of a DUC and a DDC back-to-back. It's not pretty, but it can
> > occasionally be helpful.
> >
> > Furthermore, in an effort to TRY to create an open source FPGA project
> > that doesnt catastrophically break on a regular basis, we've set up
> > continuous integration tests for both software and FPGA. Dockerfiles are
> > provided here (https://gitlab.com/theseus-cores/theseus-docker). Theseus
>
> > Cores also pushes tagged docker images for various versions of UHD and
> > Gnuradio, where the branches for UHD-3.13, UHD-3.14, UHD's master, and
> > gnuradio's maint-3.7 are rebuilt weekly. This may be of auxiliary use to
> > people building UHD and gnuradio in a CI scenario:
> > https://hub.docker.com/u/theseuscores
> > <https://github.com/theseus-cores/theseus-cores>
> > *What's next??* It's a modest list of features so far, but I'm sure we
> > can all sympathize that things move slowly when developing FPGA code.
> > Here's a quick rundown of a few ideas on the horizon:
> > - Arbitrary resampling
> > - Channel downselection for the M/2 channelizer (currently all channels
> > must be output... it's far more useful to select a subset of channels to
> > return and just grab those)
> >

[USRP-users] Introducing Theseus Cores: Open source FPGA cores for DSP and SDR

[EJ Kreinar via USRP-users]

Hi all,

I'm very happy to announce the (very modest) release of the Theseus Cores
project: https://gitlab.com/theseus-cores/theseus-cores

Theseus Cores is designed to provide open source FPGA cores for digital
signal processing and software defined radio, plus the means to *use* the
FPGA cores in real life In practice, that mostly means FPGA code
propagates up through RFNoC blocks which have both UHD and Gnuradio
software hooks for users to attach to. In the future it would be great to
support other FPGA platforms if there's interest too.

So far, Theseus Cores provides the following RFNoC FPGA blocks and
corresponding software:
- *Polyphase M/2 Channelizer*: A polyphase channelizer where each channel
outputs 2x sample rate and is compatible with perfect-reconstruction.
Thanks to Phil Vallance for re-implementing the channelizer described in
his GRCon 2017 presentation-- it works!
- *"1-to-N" DDC Chain*: Parameterized instantiations of "N" independent
DDCs, where each DDC is connected to the *first* input (a very basic, brute
force channelizer). Note I've seen several mailing list discussions in the
past year about 1-to-4 or 1-to-8 DDC channelizers -- this block provides
the generalized version of that scenario.
- *DUC + DDC Rational Resampler*: A "hacked" rational resampler, consisting
of a DUC and a DDC back-to-back. It's not pretty, but it can occasionally
be helpful.

Furthermore, in an effort to TRY to create an open source FPGA project that
doesnt catastrophically break on a regular basis, we've set up continuous
integration tests for both software and FPGA. Dockerfiles are provided here
(https://gitlab.com/theseus-cores/theseus-docker). Theseus Cores also
pushes tagged docker images for various versions of UHD and Gnuradio, where
the branches for UHD-3.13, UHD-3.14, UHD's master, and gnuradio's maint-3.7
are rebuilt weekly. This may be of auxiliary use to people building UHD and
gnuradio in a CI scenario: https://hub.docker.com/u/theseuscores

*What's next??* It's a modest list of features so far, but I'm sure we can
all sympathize that things move slowly when developing FPGA code. Here's a
quick rundown of a few ideas on the horizon:
- Arbitrary resampling
- Channel downselection for the M/2 channelizer (currently all channels
must be output... it's far more useful to select a subset of channels to
return and just grab those)
- Channel reconsonstruction *after* the M/2 channelizer (maybe)
- OFDM receiver (maybe)

We need more ideas and contributors! Now that this thing exists, I would
LOVE to see Theseus Cores fill itself out with some of the more common DSP
utilities that really should be available as open-source... it would be
absolutely amazing to provide a library of components and applications for
FPGA developers in a similar way that gnuradio provides for the software
community. Please reach out with suggestions for relevant FPGA utilities or
applications you'd like to see -- or even better, if you have ideas or code
you're willing to share with the project! If you are interested in getting
involved in any way, I would be happy to hear from you.

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

Re: [USRP-users] noc script SR_WRITE missing port argument

[EJ Kreinar via USRP-users]

Hi Rob, and various Ettus folk,

(Resurrecting an old unreplied thread here...)

This exact issue came up to bite me this this week and I'm curious how this
would be implemented. I consider this a solvable bug in RFNOC in its
current state.

Initially, I expected that if I have a nocscript arg that includes an
"SR_WRITE" action on a specific port, then the action would be applied to
the corresponding port:

```

  enable
  int
  0
  GE($enable, 0) AND LE($enable, 1)
  SR_WRITE("ENABLE_OUTPUT", $enable)
  1

```

This only ever writes to port 0 (consistent with a "sr_write" call without
a specified port).

Secondly I tried hardcoding the port input to SR_WRITE like so:

```

  enable
  int
  0
  GE($enable, 0) AND LE($enable, 1)
  SR_WRITE("ENABLE_OUTPUT", $enable, 1)
  1

```

And this becomes a runtime crash, of course, because the code here clearly
indicates that the NocScript SR_WRITE does not support a "port" argument:
https://github.com/EttusResearch/uhd/blob/master/host/lib/rfnoc/nocscript/block_iface.cpp#L28

So I see two potential solutions...
1. Use the "X" field of the nocscript to indicate which port
the SR_WRITE applies to (a nice solution)
2. Add an optional "port" input to the SR_WRITE argument, similar to the
"SET_ARG" and "SET_VAR" commands (then my second solution would apply)

Any thoughts? I couldnt puzzle out how #1 would work in the nocscript
architecture, but #2 seems pretty straightforward to me

By the way, the workaround I found is to instantiate a block controller
that adds a "set_coerced_subscriber" onto the "enable/value" property tree
which calls the *correct* sr_write function with the corresponding port.

EJ


On Thu, Jul 26, 2018 at 12:04 PM Rob Kossler via USRP-users <
usrp-users@lists.ettus.com> wrote:

> When trying to set a custom register in a noc block with multiple ports, I
> noticed that there is no noc script SR_WRITE that includes the port
> argument.  Is this on the list to be added?
>
> 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

Re: [USRP-users] Creating RFNOC block that changes stream rate

[EJ Kreinar via USRP-users]

Some more thoughts...

Are you programming the axi_rate_change SR_N, SR_M, and SR_CONFIG registers
when you run on hardware? You might be able to do this with the XML
definition, but you may also need a block controller like the
ddc_block_ctrl_impl in uhd. Don't forgot the config register-- this seems
to latch in the N & M values.

I probably wouldn't worry about the axi_tag_time unless timed commands are
really important to your application... For most "run of the mill" rfnoc
applications with gnuradio it's usually safe to ignore timed commands, so
you might be able to simplify some logic if you wanted to take out the
axi_tag_time.


As another example you can reference, see this unmerged PR from a month or
so ago that combines a DUC and DDC into a single rfnoc block:
https://github.com/EttusResearch/fpga/pull/32 Also the corresponding uhd PR
with the software controller:
https://github.com/EttusResearch/uhd/pull/219/files

(These PRs didn't make it into the main branches but they will live on,
soon, in a new consolidated OOT repo)

EJ

On Tue, Dec 18, 2018, 6:19 PM Andrew Danowitz  Thanks for the reply. I do set simple_mode and I propagate tuser into and
> out of axi_rate_change the same way noc_block_ddc does. I also have my
> block running properly in Vivado simulation. Is there anything else I
> should check? I also included axi_tag_time. Could that be causing an issue?
>
> Thanks!
> Andrew
>
> On Tue, Dec 18, 2018 at 10:11 AM EJ Kreinar  wrote:
>
>> Hi Andrew,
>>
>> Quick thoughts:
>> - Are you setting SIMPLE_MODE(0) in the axi_wrapper?
>> - Are you propagating tuser into and out of the axi_rate_change block?
>>
>> The axi_rate_change block updates tuser, which the axi_wrapper uses to
>> create output packets when SIMPLE_MODE is disabled.
>>
>> Also, have you run in a simulation testbench? Simulation should be able
>> to expose these issues before targetting hardware to make debugging a bit
>> easier.
>>
>> EJ
>>
>>
>>
>> On Tue, Dec 18, 2018 at 1:04 PM Andrew Danowitz via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Hi all,
>>>
>>> I'm trying to create an rfnoc block that takes in a stream of data at
>>> Sample rate n, does some processing to turn i-q values into real samples,
>>> and outputs data at a rate of n/2 by packing real values into both i and q
>>> channels of the output stream. I've tried to incorporate the
>>> axi_rate_change block and the axi_tag_time block a-la noc_block_ddc, but
>>> whenever I try to run it I keep getting a timeout error. If I take out the
>>> channel packing block and keep the rate n-to-n, the module works fine.
>>>
>>> Does anyone have any advice?
>>>
>>> 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
>>>
>>
> --
> 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 

Re: [USRP-users] Creating RFNOC block that changes stream rate

[EJ Kreinar via USRP-users]

Hi Andrew,

Quick thoughts:
- Are you setting SIMPLE_MODE(0) in the axi_wrapper?
- Are you propagating tuser into and out of the axi_rate_change block?

The axi_rate_change block updates tuser, which the axi_wrapper uses to
create output packets when SIMPLE_MODE is disabled.

Also, have you run in a simulation testbench? Simulation should be able to
expose these issues before targetting hardware to make debugging a bit
easier.

EJ



On Tue, Dec 18, 2018 at 1:04 PM Andrew Danowitz via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi all,
>
> I'm trying to create an rfnoc block that takes in a stream of data at
> Sample rate n, does some processing to turn i-q values into real samples,
> and outputs data at a rate of n/2 by packing real values into both i and q
> channels of the output stream. I've tried to incorporate the
> axi_rate_change block and the axi_tag_time block a-la noc_block_ddc, but
> whenever I try to run it I keep getting a timeout error. If I take out the
> channel packing block and keep the rate n-to-n, the module works fine.
>
> Does anyone have any advice?
>
> 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 mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] cross-compiling for N310

[EJ Kreinar via USRP-users]

If I recall correctly the only place QT is used would be in the RFNoC
Fosphor host code to display the fosphor output. This typically runs on a
PC, not an embedded device like E310 or N310. Unless you really need to use
QT on the N310, definitely the easiest solution here would be to just
disable qt for gr-ettus.

I usually disable QT in gr-ettus for my cross compile builds using `cmake
..  -DENABLE_QT=OFF`

Hope this helps,
EJ

On Tue, Dec 18, 2018 at 11:21 AM Jason Matusiak via USRP-users <
usrp-users@lists.ettus.com> wrote:

> I got it by running: uhd_images_downloader -t sdk -t n3xx
>
> based on instructions here:
> https://files.ettus.com/manual/page_usrp_n3xx.html#n3xx_software_dev_sdk
>
> It does not appear to have gnuradio installed
>
> OK, gnuradio seems to build fine for cross-compile, it is when I get to
> the gr-ettus step which is next (needed for RFNoC).  I haven't tried
> running gnuradio, but it builds.
>
>
>
> - Original Message -
> Subject: Re: [USRP-users] cross-compiling for N310
> From: "Philip Balister" 
> Date: 12/18/18 10:25 am
> To: "Jason Matusiak" , "Ettus Mail List" <
> usrp-users@lists.ettus.com>
>
> On 12/18/2018 08:17 AM, Jason Matusiak via USRP-users wrote:
> > It looks like qt4 was not included in the cross-compile build. If I look
> at my working e300 cross-compile, I have a folder:
> /opt/gnuradio/e300/sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/include/qt4/
> >
> > (in fact, there is a tone of stuff in that include).
> >
> > If I look in the N310 directory, it doesn't exist:
> /opt/gnuradio/N310/sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/include/
> >
> > (and there are very few files/folders in there at all.
> >
> > I will look into building it by hand, but I am guessing that it will
> just lead to more things needing to be cross-compiled
>
> Where did you get the toolchain? Does the N310 have gnuradio installed?
> Feels like the sdk may not have the packages you need to build gnuradio
> installed.
>
> Try disabling qt4 and seeing if you can get gnuradio to build like that
> as a test.
>
> Philip
>
> >
> >
> >
> > - Original Message - Subject: RE: cross-compiling for
> N310
> > From: "Jason Matusiak" 
> > Date: 12/17/18 3:15 pm
> > To: "Ettus Mail List" 
> >
> > OK, I see the first mistake. I was copying-and-pasting my notes for the
> E310 which had a different sysroot. Once I made the change to the proper
> one, it seems like it got past the rfnoc issue (or I haven't hit it yet
> with this new error).
> >
> > I am not getting:
> > - Found PkgConfig:
> /opt/gnuradio/N310/sysroots/x86_64-oesdk-linux/usr/bin/pkg-config (found
> version "0.29.2")
> > -- Found UHD:
> /opt/gnuradio/N310/sysroots/cortexa9hf-neon-oe-linux-gnueabi/usr/lib/libuhd.so
>
> > -- Found PythonLibs:
> /opt/gnuradio/N310/sysroots/cortexa9hf-neon-oe-linux-gnueabi/usr/lib/
> libpython2.7.so (found suitable version "2.7.14", minimum required is
> "2")
> > CMake Warning at
> /opt/gnuradio/N310/sysroots/x86_64-oesdk-linux/usr/share/cmake-3.10/Modules/FindQt4.cmake:620
> (message):
> > /usr/bin/qmake-qt4 reported QT_INSTALL_LIBS as "/usr/lib64" but QtCore
> > could not be found there. Qt is NOT installed correctly for the target
> > build environment.
> > Call Stack (most recent call first):
> > CMakeLists.txt:149 (find_package)
> >
> > CMake Error at CMakeLists.txt:151 (message):
> > Qt not found.
> >
> > -- Configuring incomplete, errors occurred!
> > See also
> "/opt/gnuradio/N310/src/gr-ettus/n310-build/CMakeFiles/CMakeOutput.log".
> > See also
> "/opt/gnuradio/N310/src/gr-ettus/n310-build/CMakeFiles/CMakeError.log".
> >
> > I feel like I had this issue before with an E310 build and Phil B had to
> make mods to the toolchain. Has anyone else seen and got around this?
> >
> >
> >
> > - Original Message - Subject: cross-compiling for N310
> > From: "Jason Matusiak" 
> > Date: 12/17/18 1:35 pm
> > To: "Ettus Mail List" 
> >
> > Has anyone successfully created a new build for an N310 (RFNoC version
> in particular)? I was going to bring it up to date, but seem to be having
> issues.
> >
> > I ran: uhd_images_downloader -t sdimg -v
> > To get the *.sh image for cross-compiling:
> oecore-x86_64-cortexa9hf-neon-toolchain-nodistro.0.sh
> >
> > I then install it like I do for the E310.
> >
> > I create a src directory and pull down uhd and its sub-module fpga-src.
> I've tried main, master, and UHD-3.13, and they all build fine, but give me
> issues later on. In my cmake I make sure to have -DENABLE_RFNOC=ON and I
> see it checked when I run cmake-gui.
> >
> > I then pull down gnuradio, and build like I normally do.
> >
> > Lastly, I pull down gr-ettus. When I run: cmake
> -DCMAKE_TOOLCHAIN_FILE=$PREFIX/src/gnuradio/cmake/Toolchains/oe-sdk_cross.cmake
> -DENABLE_DOXYGEN=OFF -DCMAKE_INSTALL_PREFIX=/usr ..
> >
> > It mostly works and then errors out with:
> >
> > -- Found PkgConfig:
> /opt/gnuradio/N310/sysroots/x86_64-oesdk-linux/usr/bin/pkg-config (found
> 

Re: [USRP-users] does uhd_image_builder work with N310

[EJ Kreinar via USRP-users]

Hi Jason and Rob,

I'm using OOT RFNoC builds for N300 and N310 successfully. What version are
you on?

All I *think* I needed was the commit here, which I see is now on both
master and UHD-3.13 branches:
https://github.com/EttusResearch/fpga/commit/cad653b5598d7c7728c9674675ae3b59f51daa14

I personally have not progressed beyond the 3.13.0.0/3.13.0.1 tag (...I
havent "made the leap" to the new compat_shell yet), but I've cherry-picked
the referenced commit to get OOT builds working for me.

EJ



On Fri, Dec 14, 2018 at 10:54 AM Rob Kossler via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi Jason,
> I had mentioned this same issue on Oct 29 ("RFNoC build issue for OOT
> block"), but never got any response.  I had to abandon RFNoC development on
> the N310 in favor of doing it on the X310 and I have not returned to the
> N310.
> Rob
>
> On Fri, Dec 14, 2018 at 10:20 AM Jason Matusiak via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> I finally got an N310 to play with.  I was trying to build a custom RFNoC
>> FPGA image, but it keeps erroring out.
>>
>> The command I am running is:
>> ./uhd_image_builder.py -d N310 -t N310_RFNOC_XG -I
>> /opt/gnuradio/N310/src/rfnoc-nocblocks -y
>> /opt/gnuradio/N310/src/rfnoc-nocblocks/fpga_build/n310_4ddc_2keepMinN_2split.yml
>>
>> The debug is:
>>
>> ./uhd_image_builder.py -d N310 -t N310_RFNOC_XG -I
>> /opt/gnuradio/N310/src/rfnoc-nocblocks -y
>> /opt/gnuradio/N310/src/rfnoc-nocblocks/fpga_build/n310_4ddc_2keepMinN_2split.yml
>> Using yml file. Ignoring command line blocks arguments
>> ddc
>> {'extraports': None, 'parameters': {'NOC_ID': "64'hDDC0___",
>> 'NUM_CHAINS': 2}, 'clock': 'ce'}
>> ddc
>> {'extraports': None, 'parameters': {'NOC_ID': "64'hDDC0___",
>> 'NUM_CHAINS': 2}, 'clock': 'ce'}
>> ddc
>> {'extraports': None, 'parameters': {'NOC_ID': "64'hDDC0___0001",
>> 'NUM_CHAINS': 1}, 'clock': 'ce'}
>> ddc
>> {'extraports': None, 'parameters': {'NOC_ID': "64'hDDC0___0001",
>> 'NUM_CHAINS': 1}, 'clock': 'ce'}
>> keepMinN
>> {'extraports': None, 'parameters': None, 'clock': 'ce'}
>> keepMinN
>> {'extraports': None, 'parameters': None, 'clock': 'ce'}
>> split_stream
>> {'extraports': None, 'parameters': None, 'clock': 'ce'}
>> split_stream
>> {'extraports': None, 'parameters': None, 'clock': 'ce'}
>> [{'block': 'ddc', 'parameters': {'NOC_ID': "64'hDDC0___",
>> 'NUM_CHAINS': 2}}, {'block': 'ddc', 'parameters': {'NOC_ID':
>> "64'hDDC0___", 'NUM_CHAINS': 2}}, {'block': 'ddc',
>> 'parameters': {'NOC_ID': "64'hDDC0___0001", 'NUM_CHAINS': 1}},
>> {'block': 'ddc', 'parameters': {'NOC_ID': "64'hDDC0___0001",
>> 'NUM_CHAINS': 1}}, {'block': 'keepMinN', 'parameters': None}, {'block':
>> 'keepMinN', 'parameters': None}, {'block': 'split_stream', 'parameters':
>> None}, {'block': 'split_stream', 'parameters': None}]
>> --Using the following blocks to generate image:
>> * ddc
>> * ddc
>> * ddc
>> * ddc
>> * keepMinN
>> * keepMinN
>> * split_stream
>> * split_stream
>> Adding CE instantiation file for 'N310_RFNOC_XG'
>> changing temporarily working directory to
>> /opt/gnuradio/N310/src/uhd/fpga-src/usrp3/tools/scripts/../../top/n3xx
>> Setting up a 64-bit FPGA build environment for the USRP-N3x0...
>> - Vivado: Found (/opt/Xilinx/Vivado/2017.4/bin)
>>
>> Environment successfully initialized.
>> make -f Makefile.n3xx.inc bin NAME=N310_RFNOC_XG ARCH=zynq
>> PART_ID=xc7z100/ffg900/-2 SFP0_10GBE=1 SFP1_10GBE=1 BUILD_10G=1 RFNOC=1
>> N310=1 TOP_MODULE=n3xx EXTRA_DEFS="SFP0_10GBE=1 SFP1_10GBE=1 BUILD_10G=1
>> RFNOC=1 N310=1"
>> make[1]: Entering directory
>> `/opt/gnuradio/N310/src/uhd/fpga-src/usrp3/top/n3xx'
>> BUILDER: Checking tools...
>> * GNU bash, version 4.2.46(2)-release (x86_64-redhat-linux-gnu)
>> * Python 2.7.5
>> * Vivado v2017.4 (64-bit)
>> Using parser configuration from:
>> /opt/gnuradio/N310/src/uhd/fpga-src/usrp3/top/n3xx/dev_config.json
>> [00:00:00] Executing command: vivado -mode batch -source
>> /opt/gnuradio/N310/src/uhd/fpga-src/usrp3/top/n3xx/build_n3xx.tcl -log
>> build.log -journal n3xx.jou
>> CRITICAL WARNING: [filemgmt 20-1440] File
>> '/opt/gnuradio/N310/src/uhd/fpga-src/usrp3/top/n3xx/build-ip/xc7z100ffg900-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
>> '/opt/gnuradio/N310/src/uhd/fpga-src/usrp3/top/n3xx/build-ip/xc7z100ffg900-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:33] Current task: Initialization +++ Current Phase: Starting
>> [00:00:33] Current task: Initialization +++ Current Phase: Finished
>> [00:00:33] Executing Tcl: synth_design -top n3xx -part xc7z100ffg900-2
>> -verilog_define SFP0_10GBE=1 -verilog_define SFP1_10GBE=1 -verilog_define
>> BUILD_10G=1 -verilog_define RFNOC=1 -verilog_define N310=1 -verilog_define
>> GIT_HASH=32'hf494ae8b
>> 

Re: [USRP-users] rfnoc build works for E310, doesn't meet timing with X310

[EJ Kreinar via USRP-users]

First, it's really not failing by much -- you got under 7 ns, so it's
*almost* there.

Two suggestions:

1. If the input/output of the block does not go directly into axi_wrapper,
try adding an axi_flop at the end to insert a one-cycle delay. This could
break up a critical path if you have a few "0-delay" blocks in a row. If
this goes into axi_wrapper, it should probably be fine

2. This is a smoking gun:

`(vector_cnt == (of_n-1)*keep_m)`

See if you can find a way around the multiply operation and I expect it
will work just fine.

EJ



On Thu, Nov 8, 2018 at 9:47 AM Jason Matusiak 
wrote:

> Gents, thanks for the input.  I actually found the section I needed in the
> timing report just before you guys wrote (I hate trying to sift through
> those).  It is indeed my block that is causing issues.  I was getting ready
> to try to break out my testbench and start playing with it by adding some
> registers to see if that helps (the testbench worked before, so I won't
> know if this helps timing, but I could at least make sure I didn't break
> anything.
>
> Excellent point on the clock differences.  I was stuck down a rabbit hole
> as to why the E310 would be fine, but not the X310, but that makes sense.
> I was just getting lucky I guess at the slower clock rates.
>
> Here is the relevant timing issue:
>
>
> ---
> From Clock: ce_clk
> To Clock: ce_clk
>
> Setup : 8006 Failing Endpoints, Worst Slack -2.711ns, Total Violation
> -4376.156ns
> Hold : 0 Failing Endpoints, Worst Slack 0.035ns, Total Violation 0.000ns
> PW : 0 Failing Endpoints, Worst Slack 1.565ns, Total Violation 0.000ns
>
> ---
>
>
> Max Delay Paths
>
> --
> Slack (VIOLATED) : -2.711ns (required time - arrival time)
> Source: x300_core/inst_keepMinN/sr_n/out_reg[2]_replica/C
> (rising edge-triggered cell FDRE clocked by ce_clk {rise@0.000ns
> fall@2.333ns period=4.667ns})
> Destination: x300_core/inst_keepMinN/keepMinN/vector_cnt_reg[12]/R
> (rising edge-triggered cell FDRE clocked by ce_clk {rise@0.000ns
> fall@2.333ns period=4.667ns})
> Path Group: ce_clk
> Path Type: Setup (Max at Slow Process Corner)
> Requirement: 4.667ns (ce_clk rise@4.667ns - ce_clk rise@0.000ns)
> Data Path Delay: 6.966ns (logic 5.340ns (76.654%) route 1.626ns (23.346%))
> Logic Levels: 10 (CARRY4=5 DSP48E1=2 LUT1=1 LUT3=1 LUT5=1)
> Clock Path Skew: -0.053ns (DCD - SCD + CPR)
> Destination Clock Delay (DCD): -1.659ns = ( 3.008 - 4.667 )
> Source Clock Delay (SCD): -2.028ns
> Clock Pessimism Removal (CPR): -0.422ns
> Clock Uncertainty: 0.054ns ((TSJ^2 + DJ^2)^1/2) / 2 + PE
> Total System Jitter (TSJ): 0.071ns
> Discrete Jitter (DJ): 0.082ns
> Phase Error (PE): 0.000ns
>
> (and it continues with more stuff that I don't think is particularly
> useful).
>
>
>
> So, it is plain to see that something I am doing inside my block is very
> stupid (though accomplishes what I wanted.  I can post the code, so maybe
> someone can spot the issue (I really think it is a registering problem that
> I need to do on the output side).  Please excuse the simplicity of the
> code, I needed to through something together VERY fast, and instead of
> being elegant, I went with easy to code up.
>
>
>
> The block's title is a little misleading, it basically keeps M vectors out
> of N vectors.  So if the vector size is 512, and M==2 and N==10.  I will
> pass through 1024 samples, and then dump the next 4096 samples.  Then wash,
> rinse, repeat.  The verilog is attached since I was having trouble keeping
> formatting when I pasted it here.
>
>
>
>
>
>
> - Original Message -
> Subject: Re: [USRP-users] rfnoc build works for E310, doesn't meet timing
> with X310
> From: "EJ Kreinar" 
> Date: 11/8/18 9:09 am
> To: "Jason Matusiak" 
> Cc: "USRP-users@lists.ettus.com" 
>
> Hi Jason,
>
> That actually makes sense to me... Bus clk on the e310 is usually 50 MHz
> if I remember correctly (and if it didn't change), and the max radio_clk is
> something like 64ish MHz.
>
> Max clock rates on the x310 are, I believe, more like 200-215 MHz. So
> logic in the x310 nominally needs to settle within 5 ns while logic on the
> e310 can have a luxurious 15-20 ns. Xilinx will try very hard to optimize
> timing and the build for x310 could take a LONG time.
>
> If you can access the timing report, it will often show critical paths,
> but the text report is often unintelligible to me. I have also built in GUI
> mode before (like setting up a ILA core) because the Vivado interface for
> organizing and understanding timing failures are actually pretty helpful.
>
> I'd also suggest, if you'd like some verilog input, to send the relevant
> code you think might continue to the timing errors, and we can take a look
> for ideas? It could 

Re: [USRP-users] rfnoc build works for E310, doesn't meet timing with X310

[EJ Kreinar via USRP-users]

Hi Jason,

That actually makes sense to me... Bus clk on the e310 is usually 50 MHz if
I remember correctly (and if it didn't change), and the max radio_clk is
something like 64ish MHz.

Max clock rates on the x310 are, I believe, more like 200-215 MHz. So logic
in the x310 nominally needs to settle within 5 ns while logic on the e310
can have a luxurious 15-20 ns. Xilinx will try very hard to optimize timing
and the build for x310 could take a LONG time.

If you can access the timing report, it will often show critical paths, but
the text report is often unintelligible to me. I have also built in GUI
mode before (like setting up a ILA core) because the Vivado interface for
organizing and understanding timing failures are actually pretty helpful.

I'd also suggest, if you'd like some verilog input, to send the relevant
code you think might continue to the timing errors, and we can take a look
for ideas? It could potentially lead to a quick solution if you're up for
it. A MaxNinM block sounds like it could easily contribute to poor timing
depending on the implementation.

EJ


On Thu, Nov 8, 2018, 8:11 AM Jason Matusiak via USRP-users <
usrp-users@lists.ettus.com wrote:

> OK, this has befuddled me for 3 days and I can't seem to get past it.  I
> have a prefix that seems to work fine.
>
> Here are my working steps for building a bitfile on an E310:
> cd /opt/gnuradio/e300/src/uhd/fpga-src/usrp3/tools/scripts
>
> source ../../top/e300/setupenv.sh
>
> ./uhd_image_builder.py keepMinN ddc split_stream axi_fifo_loopback -d e310
> -t E310_RFNOC_sg3 -I /opt/gnuradio/e300/src/rfnoc-nocblocks
>
> This build and runs fine.  keepMinN is a small custom block I made that
> doesn't use much resources and has been working fine for weeks.
>
> Now, if I open a new terminal and run this:
>
> cd /opt/gnuradio/e300/src/uhd/fpga-src/usrp3/tools/scripts
> source ../../top/x300/setupenv.sh
> ./uhd_image_builder.py keepMinN ddc ddc split_stream axi_fifo_loopback -d
> x310 -t X310_RFNOC_XG -I /opt/gnuradio/e300/src/rfnoc-nocblocks -m 5
>
> it never seems to meet timing.  Now, I have done this with and without the
> "-m" directive, that doesn't seem to matter.  The only real difference in
> the command is the second ddc block.
>
> So what the heck could be causing these issues?  If anything, I would have
> expected the X310 build to be fine and the E310 to not meet timing.
> Another odd thing (though I am chalking it up to the X310 doing more) is
> that the X310 build is taking A LOT longer.  I don't recall it taking this
> long before, but I am not sure.
>
> It tell me to look at the report_timing_summary, but it hasn't updated yet
> (it keeps running for a bit after throwing the timing warning).  If I
> remember though, I think that the issue it had was with the ce_clk for some
> reason.
> ___
> 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] N3xx operational questions

[EJ Kreinar via USRP-users]

Hi Martin,

Thanks for the detailed feedback! I'll not worry about FPGA loading
timeouts. I'm also not terribly concerned about local FPGA loading either,
though it is perhaps worth noting if the uhd_image_loader and
uhd_images_downloader should default to python3 on the n3xx PS.

> It is not. UHD/MPM will always derive and fill out mgmt_addr, but you're
supposed to be able to override it `addr=...,mgmt_addr=...`.

Okay-- This issue sounds like a red flag for me. I have not had a single
successful `uhd_usrp_probe` when both eth0 and sfp0 (1Gig) are connected
and enabled to the same network. I am using the "3.13.0.2-20180829" sdimg
and the tagged 3.13.0.2 software. Would you recommend trying a different
software version?

I'm also suspicious that my configuration is maybe slightly different than
normal... Since I'm using 1 GigE, and I'm not terribly concerned about
streaming throughput, I connected both the eth0 and sfp0 to a network
switch, and my host computer uses a single ethernet connection to access
both interfaces on the same subnet. Could this be causing a problem that is
not typically exercised?

> Some logs would be helpful. We sometimes get (rare) reports of MPM
crashes, but we are having a hard time reproducing them. To resolve stuck
FPGA issues, reloading the FPGA image might also help. However, these are
also not intended. Is this on custom images you've built?

Yes, if I remember correctly the crashes have been with custom images, and
I'm doing potentially dangerous things like asynchronously polling FPGA
registers.

How can I access MPM logs? The best I've found so far is to stop the usrp
service,  then manually run the program with increased console verbosity.
Is there documentation how to configure the logging? I'll set this up for
next time.

Thanks!
EJ


On Fri, Nov 2, 2018 at 5:53 PM Martin Braun  wrote:

> On Wed, Oct 24, 2018 at 3:02 PM EJ Kreinar via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hi All,
>>
>> I've been working with the N3xx series for a week or so and I've hit a
>> few issues in the "operational" side of things that are either not
>> addressed in the manual or work differently than expected. I'll just handle
>> this as a "laundry list" of items/issues...
>>
>> To start, I've been directly testing on the N300 so far. I reflashed the
>> N300 SD card with version UHD-3.13.02 last week.
>>
>> 1. As a heads up, and I'm sure you're aware, I've had a fair bit of
>> trouble coordinating the uhd_images_downloader with the correct images...
>> First, when I originally built UHD-3.13.0.0 as described in the manual,
>> there's no images provided for 3.13.0.0. I just noticed today that if I
>> update to UHD-3.13 branch (currently 3.13.0.3) and run the downloader, it
>> tries to pull images for 3.13.0.2, which is likely incompatible with the
>> 3.13.0.3 head (noc shell seems to be updated to version 3 in the most
>> recent 3.13.0.3).
>>
>
> EJ, the FPGA images tagged in the manifest in the UHD repo should always
> work with that version of UHD, meaning that uhd_images_downloader should
> always pull the correct images. The latest filesystem might not contain the
> latest FPGA images -- then you simply run uhd_images_downloader. This gives
> us the option to more incrementally update our filesystems (and your
> downloads), and we don't need to update all the Gigabytes of
> filesystem-related files. Note that we did remove the 3.13.0.0 images after
> the following release, because it had some issues with the newest hardware
> revision (which have been resolved).
>
> A combo of
>
> uhd_images_downloader -t n3xx -t sdimg
> uhd_images_downloader -t n3xx -t fpga
>
> will always give you up-to-date images.
>
>
>>
>> 2. I keep running into a number of issues trying to download new FPGA
>> images. Could someone explain the mechanics of FPGA loading for N3xx? I'm
>> assuming this is similar to X310, however I would have expected that a
>> zynq-based platform would simply program to /dev/xdevcfg like the E310.
>>
>
> Yep, it's the same! The N3xx manual has some notes (see Section "Updating
> the FPGA"). You can omit --fpga-path for a default image.
>
>>
>> More tactically, I have a few issues when trying to download FPGA images.
>> If I run a "host mode update", then I get an unexpected error:
>>
>> ```
>> $ uhd_image_loader --args "type=n3xx,addr=10.1.151.245"
>> --fpga-path=n3xx.bit
>> [INFO] [UHD] linux; GNU C++ version 7.3.0; Boost_106501;
>> UHD_3.13.0.3-14-gd1555232
>> [INFO] [MPMD] Initializing 1 device(s) in parallel with args:
>> mgmt_addr=10.1.151.245,type=n3xx,product=n300,serial=3145FF4,claimed=Fals

Re: [USRP-users] n3xx master clock rate selection

[EJ Kreinar via USRP-users]

gt; Sad to hear that! By the way, I forgot to mention another important
>>>> rate I need, 3 MHz, that also has an integer relationship to 120 MHz...
>>>> Perhaps I'd like to make a formal feature request for 120 MHz master
>>>> clock?? It strikes me as odd that so many of the "whole number" MHz sample
>>>> rates are neglected on the n3xx series by default-- it's often the case
>>>> that I'll want to interact with other hardware with baud rates at, say, 2
>>>> MHz or 10 MHz or something, but I just don't have the fpga-based fractional
>>>> conversions onhand right now...
>>>>
>>>> I'm certainly not afraid of nontrivial changes, so if the AD9371
>>>> supports a clock rate that can give me these derived sample rates, I really
>>>> see this as the best solution since other platforms can already achieve
>>>> these rates without extra user-space processing requirements.
>>>>
>>>> However, if needed, potentially a "quick and dirty" approach might be
>>>> to make an rfnoc fractional resampler that combines a DUC and DDC into one
>>>> "ce", with a block controller to calculate the magical conversions... It's
>>>> not an optimal solution but it might do the trick here. Anyone else
>>>> interested in such an fpga-based fractional resampler?
>>>>
>>>> EJ
>>>>
>>>> On Wed, Oct 17, 2018, 1:52 PM Daniel Jepson via USRP-users <
>>>> usrp-users@lists.ettus.com> wrote:
>>>>
>>>>> Hi EJ,
>>>>>
>>>>> The fundamental limitation comes from the AD9371. Although the
>>>>> datasheet specifies a wide reference clock input range, there are only
>>>>> certain supported rates within the public side of their API (at least that
>>>>> I'm aware of). These include the rates you mentioned from the KB.
>>>>>
>>>>> Assuming the AD9371 allows it, adding a new MCR is not trivial and
>>>>> would require a good deal of work across hardware, FPGA code, and MPM. The
>>>>> fractional resampler sounds like a much better path forward, albeit
>>>>> difficult right now.
>>>>>
>>>>> Hopefully that explains some of the background on the chosen MCRs.
>>>>> Sorry it wasn't exactly what you were hoping for!
>>>>>
>>>>> -Daniel
>>>>>
>>>>> On Wed, Oct 17, 2018 at 10:50 AM EJ Kreinar via USRP-users <
>>>>> usrp-users@lists.ettus.com> wrote:
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> I'm working on an FPGA application on the n310/n300, and I'm bumping
>>>>>> into a limitation of the master_clock_rate selection I'd like to be
>>>>>> able to use sample rates in the FPGA of 2 MHz, 4 MHz, and 10 MHz, but 
>>>>>> none
>>>>>> of these values are integer multiples of the supported rates (122.88e6,
>>>>>> 125e6, 153.6e6 -- from here:
>>>>>> https://kb.ettus.com/N300/N310_Getting_Started_Guides#Supported_Sample_Rates).
>>>>>> This causes a problem in the FPGA since I would need a fractional
>>>>>> resampler, which I dont currently have, unfortunately.
>>>>>>
>>>>>> What's the fundamental limitation of these master clock rates? I
>>>>>> would have assumed that the AD9371-based architecture would have resulted
>>>>>> in a wider variety of plausible clock rates, similar to the AD9361 on the
>>>>>> E310. I havent found these limits yet in the software or FPGA, so any
>>>>>> pointers where to look would be appreciated.
>>>>>>
>>>>>> As a follow up question, how feasible would it be to add a master
>>>>>> clock rate of 120 MHz?? Any ideas where to make these changes? This would
>>>>>> answer the mail for my sample rates of interest right now.
>>>>>>
>>>>>> Thanks!
>>>>>> EJ
>>>>>> ___
>>>>>> USRP-users mailing list
>>>>>> USRP-users@lists.ettus.com
>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> Daniel Jepson
>>>>>
>>>>> Digital

[USRP-users] N3xx operational questions

[EJ Kreinar via USRP-users]

Hi All,

I've been working with the N3xx series for a week or so and I've hit a few
issues in the "operational" side of things that are either not addressed in
the manual or work differently than expected. I'll just handle this as a
"laundry list" of items/issues...

To start, I've been directly testing on the N300 so far. I reflashed the
N300 SD card with version UHD-3.13.02 last week.

1. As a heads up, and I'm sure you're aware, I've had a fair bit of trouble
coordinating the uhd_images_downloader with the correct images... First,
when I originally built UHD-3.13.0.0 as described in the manual, there's no
images provided for 3.13.0.0. I just noticed today that if I update to
UHD-3.13 branch (currently 3.13.0.3) and run the downloader, it tries to
pull images for 3.13.0.2, which is likely incompatible with the 3.13.0.3
head (noc shell seems to be updated to version 3 in the most recent
3.13.0.3).

2. I keep running into a number of issues trying to download new FPGA
images. Could someone explain the mechanics of FPGA loading for N3xx? I'm
assuming this is similar to X310, however I would have expected that a
zynq-based platform would simply program to /dev/xdevcfg like the E310.

More tactically, I have a few issues when trying to download FPGA images.
If I run a "host mode update", then I get an unexpected error:

```
$ uhd_image_loader --args "type=n3xx,addr=10.1.151.245" --fpga-path=n3xx.bit
[INFO] [UHD] linux; GNU C++ version 7.3.0; Boost_106501;
UHD_3.13.0.3-14-gd1555232
[INFO] [MPMD] Initializing 1 device(s) in parallel with args:
mgmt_addr=10.1.151.245,type=n3xx,product=n300,serial=3145FF4,claimed=False,skip_init=1
[INFO] [MPMD] Claimed device without full initialization.
[WARNING] [MPMD IMAGE LOADER] RuntimeError: Component file does not exist:
/home/ejk/fpga-build/he360-fpga-builder/src/uhd-fpga/usrp3/top/n3xx/build-N300_RFNOC_HG/n3xx.dts
[INFO] [MPMD IMAGE LOADER] Starting update. This may take a while.
[ERROR] [UHD] An unexpected exception was caught in a task loop.The task
loop will now exit, things may not work.rpc::timeout: Timeout of 5000ms
while calling RPC function 'get_log_buf'
[INFO] [MPM.PeriphManager] Device serial number: 3145FF4
[INFO] [MPM.PeriphManager] Initialized 1 daughterboard(s).
[INFO] [MPM.PeriphManager] init() called with device args `'.
Error: rpc::timeout: Timeout of 2ms while calling RPC function
'update_component'
```

Fortunately, this error appears that it doesnt materially impact anything,
and I can now probe the FPGA successfully afterwards.

When trying to load FPGA images in embedded mode, first, I get an error
when running uhd_images_downloader that suggests argparse is not installed
into the rootfs:

```
root@ni-n3xx-3145FF4:~# uhd_images_downloader
Traceback (most recent call last):
  File "/usr/bin/uhd_images_downloader", line 11, in 
import argparse
ImportError: No module named argparse
```

Oddly, pip3 seems to be installed, and I can run `pip3 install argparse`
but there's no pip or python2 argparse :(

Anyway, if I scp a relevant image onto the N300 PS, I get a similar issue
as over network mode.

At one point, I found fpga programming in embedded mode crashed the N300
and require a hard reboot, but I cant recreate that right now so I'll leave
that off my list.

3. Embedded mode vs host/network mode: Ideally, I would like to run the
N3xx using both a high rate ethernet connection through the sfp's, and a
connection to the Zynq PS over the RJ45. (not at the same time from the
same program, but both ports physically connected)... However, I cannot
succeed in switching between embedded mode and host mode without 1)
physically unplugging the ethernet cables, or 2) taking down the IP
interface that I'm not using at the moment. Is there a way to do this??

To give a specific example of behavior I see, I've set up the N300 to
boot with 1GigE connection on sfp0 and RJ45 on the eth0. From a host
device, in network mode, I fail to probe the N300:

```
$ uhd_usrp_probe --args "type=n3xx"
[INFO] [UHD] linux; GNU C++ version 7.3.0; Boost_106501;
UHD_3.13.0.HEAD-0-g0ddc19e5
[INFO] [MPMD] Initializing 1 device(s) in parallel with args:
mgmt_addr=10.1.151.60,type=n3xx,product=n300,serial=3145FF4,claimed=False,addr=10.1.151.245
[INFO] [MPM.PeriphManager] init() called with device args
`mgmt_addr=10.1.151.60,product=n300'.
[ERROR] [UHD] Exception caught in safe-call.
  in ctrl_iface_impl<_endianness>::~ctrl_iface_impl() [with
uhd::endianness_t _endianness = (uhd::endianness_t)0]
  at
/home/ejk/prefix/gnuradio-default/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:60
this->send_cmd_pkt(0, 0, true); -> EnvironmentError: IOError: Block ctrl
(CE_00_Port_30) no response packet - AssertionError: bool(buff)
  in uint64_t ctrl_iface_impl<_endianness>::wait_for_ack(bool, double)
[with uhd::endianness_t _endianness = (uhd::endianness_t)0; uint64_t = long
unsigned int]
  at
/home/ejk/prefix/gnuradio-default/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:154

[ERROR] [MPMD] Failure during 

Re: [USRP-users] getting GPS time from RFNoC bitfile on E310

[EJ Kreinar via USRP-users]

Hi Jason,

I don't have that change available now, but you can pretty easily make a
mod to add the get_mboard_sensor functionally into an rfnoc block.

I'd recommend starting with gr-ettus... take a look through the updates to
radio_block_impl.cc and .h to see how to add new functionality (Darek Kozel
has a particularly relevant commit about a year ago):
https://github.com/EttusResearch/gr-ettus/commits/master/lib/rfnoc_radio_impl.cc

You'll also need to update some software in uhd to make things happy. Hope
this helps! I agree it's one of those things that might be nice to have in
the main tree.

EJ

On Mon, Oct 22, 2018, 11:08 AM Jason Matusiak via USRP-users <
usrp-users@lists.ettus.com> wrote:

> I was trying to get GPS from a python OOT module block, but it doesn't
> look like it is possible when running RFNoC mode.
>
> I have top_block passed in, and I tried the command:
>
> print
> self.top_block.uhd_rfnoc_streamer_radio_0.get_mboard_sensor('gps_position')
>
> But I get the error:
>
> print
> self.top_block.uhd_rfnoc_streamer_radio_0.get_mboard_sensor('gps_position')
> AttributeError: 'rfnoc_radio_sptr' object has no attribute
> 'get_mboard_sensor'
> thread[thread-per-block[0]: ]: SWIG director
> method error. Error detected when calling 'feval_ll.eval'
>
>
>
> Any idea how to do this?  I tried poking through the mailing list as well
> as the USRP manual, but I don't see any way to do it when you are an RFNoC
> radio.
>
>
>
> ~Jason
> ___
> 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] n3xx master clock rate selection

[EJ Kreinar via USRP-users]

DUC and DDC into one
>>> "ce", with a block controller to calculate the magical conversions... It's
>>> not an optimal solution but it might do the trick here. Anyone else
>>> interested in such an fpga-based fractional resampler?
>>>
>>> EJ
>>>
>>> On Wed, Oct 17, 2018, 1:52 PM Daniel Jepson via USRP-users <
>>> usrp-users@lists.ettus.com> wrote:
>>>
>>>> Hi EJ,
>>>>
>>>> The fundamental limitation comes from the AD9371. Although the
>>>> datasheet specifies a wide reference clock input range, there are only
>>>> certain supported rates within the public side of their API (at least that
>>>> I'm aware of). These include the rates you mentioned from the KB.
>>>>
>>>> Assuming the AD9371 allows it, adding a new MCR is not trivial and
>>>> would require a good deal of work across hardware, FPGA code, and MPM. The
>>>> fractional resampler sounds like a much better path forward, albeit
>>>> difficult right now.
>>>>
>>>> Hopefully that explains some of the background on the chosen MCRs.
>>>> Sorry it wasn't exactly what you were hoping for!
>>>>
>>>> -Daniel
>>>>
>>>> On Wed, Oct 17, 2018 at 10:50 AM EJ Kreinar via USRP-users <
>>>> usrp-users@lists.ettus.com> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> I'm working on an FPGA application on the n310/n300, and I'm bumping
>>>>> into a limitation of the master_clock_rate selection I'd like to be
>>>>> able to use sample rates in the FPGA of 2 MHz, 4 MHz, and 10 MHz, but none
>>>>> of these values are integer multiples of the supported rates (122.88e6,
>>>>> 125e6, 153.6e6 -- from here:
>>>>> https://kb.ettus.com/N300/N310_Getting_Started_Guides#Supported_Sample_Rates).
>>>>> This causes a problem in the FPGA since I would need a fractional
>>>>> resampler, which I dont currently have, unfortunately.
>>>>>
>>>>> What's the fundamental limitation of these master clock rates? I would
>>>>> have assumed that the AD9371-based architecture would have resulted in a
>>>>> wider variety of plausible clock rates, similar to the AD9361 on the E310.
>>>>> I havent found these limits yet in the software or FPGA, so any pointers
>>>>> where to look would be appreciated.
>>>>>
>>>>> As a follow up question, how feasible would it be to add a master
>>>>> clock rate of 120 MHz?? Any ideas where to make these changes? This would
>>>>> answer the mail for my sample rates of interest right now.
>>>>>
>>>>> Thanks!
>>>>> EJ
>>>>> ___
>>>>> USRP-users mailing list
>>>>> USRP-users@lists.ettus.com
>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Daniel Jepson
>>>>
>>>> Digital Hardware Engineer
>>>>
>>>> National Instruments
>>>>
>>>>
>>>>
>>>> O: +1.512.683.6163
>>>>
>>>> daniel.jep...@ni.com
>>>> ___
>>>> USRP-users mailing list
>>>> USRP-users@lists.ettus.com
>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>
>>>
>>> On Wed, Oct 17, 2018, 1:52 PM Daniel Jepson via USRP-users <
>>> usrp-users@lists.ettus.com> wrote:
>>>
>>>> Hi EJ,
>>>>
>>>> The fundamental limitation comes from the AD9371. Although the
>>>> datasheet specifies a wide reference clock input range, there are only
>>>> certain supported rates within the public side of their API (at least that
>>>> I'm aware of). These include the rates you mentioned from the KB.
>>>>
>>>> Assuming the AD9371 allows it, adding a new MCR is not trivial and
>>>> would require a good deal of work across hardware, FPGA code, and MPM. The
>>>> fractional resampler sounds like a much better path forward, albeit
>>>> difficult right now.
>>>>
>>>> Hopefully that explains some of the background on the chosen MCRs.
>>>> Sorry it wasn't exactly what you were hoping for!
>

Re: [USRP-users] n3xx master clock rate selection

[EJ Kreinar via USRP-users]

So, I'm trying to understand the fundamental clock rate selection
limitations for the 9371... From what I understand, this is plausibly due
to some limitations of the JESD interface (?).

This wiki answer suggests possible rates of 122.88M, 153.6M, 184.32M,
245.76M, or 307.2M:
https://ez.analog.com/wide-band-rf-transceivers/design-support-ad9371/f/q-a/100289/ad9371-sync-clock-frequencies

Then the 9371 datasheet also shows example rates of 122.88, 153.6, 245.76,
and 307.2 MHz: https://www.analog.com/en/products/ad9371.html

So how is it that there's a master clock rate at 125MHz??

EJ

On Wed, Oct 17, 2018, 5:49 PM EJ Kreinar  wrote:

> Hi Daniel,
>
> Sad to hear that! By the way, I forgot to mention another important rate I
> need, 3 MHz, that also has an integer relationship to 120 MHz... Perhaps
> I'd like to make a formal feature request for 120 MHz master clock?? It
> strikes me as odd that so many of the "whole number" MHz sample rates are
> neglected on the n3xx series by default-- it's often the case that I'll
> want to interact with other hardware with baud rates at, say, 2 MHz or 10
> MHz or something, but I just don't have the fpga-based fractional
> conversions onhand right now...
>
> I'm certainly not afraid of nontrivial changes, so if the AD9371 supports
> a clock rate that can give me these derived sample rates, I really see this
> as the best solution since other platforms can already achieve these rates
> without extra user-space processing requirements.
>
> However, if needed, potentially a "quick and dirty" approach might be to
> make an rfnoc fractional resampler that combines a DUC and DDC into one
> "ce", with a block controller to calculate the magical conversions... It's
> not an optimal solution but it might do the trick here. Anyone else
> interested in such an fpga-based fractional resampler?
>
> EJ
>
> On Wed, Oct 17, 2018, 1:52 PM Daniel Jepson via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hi EJ,
>>
>> The fundamental limitation comes from the AD9371. Although the datasheet
>> specifies a wide reference clock input range, there are only certain
>> supported rates within the public side of their API (at least that I'm
>> aware of). These include the rates you mentioned from the KB.
>>
>> Assuming the AD9371 allows it, adding a new MCR is not trivial and would
>> require a good deal of work across hardware, FPGA code, and MPM. The
>> fractional resampler sounds like a much better path forward, albeit
>> difficult right now.
>>
>> Hopefully that explains some of the background on the chosen MCRs. Sorry
>> it wasn't exactly what you were hoping for!
>>
>> -Daniel
>>
>> On Wed, Oct 17, 2018 at 10:50 AM EJ Kreinar via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Hi all,
>>>
>>> I'm working on an FPGA application on the n310/n300, and I'm bumping
>>> into a limitation of the master_clock_rate selection I'd like to be
>>> able to use sample rates in the FPGA of 2 MHz, 4 MHz, and 10 MHz, but none
>>> of these values are integer multiples of the supported rates (122.88e6,
>>> 125e6, 153.6e6 -- from here:
>>> https://kb.ettus.com/N300/N310_Getting_Started_Guides#Supported_Sample_Rates).
>>> This causes a problem in the FPGA since I would need a fractional
>>> resampler, which I dont currently have, unfortunately.
>>>
>>> What's the fundamental limitation of these master clock rates? I would
>>> have assumed that the AD9371-based architecture would have resulted in a
>>> wider variety of plausible clock rates, similar to the AD9361 on the E310.
>>> I havent found these limits yet in the software or FPGA, so any pointers
>>> where to look would be appreciated.
>>>
>>> As a follow up question, how feasible would it be to add a master clock
>>> rate of 120 MHz?? Any ideas where to make these changes? This would answer
>>> the mail for my sample rates of interest right now.
>>>
>>> Thanks!
>>> EJ
>>> ___
>>> USRP-users mailing list
>>> USRP-users@lists.ettus.com
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>
>>
>> --
>>
>> Daniel Jepson
>>
>> Digital Hardware Engineer
>>
>> National Instruments
>>
>>
>>
>> O: +1.512.683.6163
>>
>> daniel.jep...@ni.com
>> ___
>> USRP-users mailing list
>> USRP-users@lists.ettus.com
>> http://lists.ettus.com/mailma

Re: [USRP-users] n3xx master clock rate selection

[EJ Kreinar via USRP-users]

Hi Daniel,

Sad to hear that! By the way, I forgot to mention another important rate I
need, 3 MHz, that also has an integer relationship to 120 MHz... Perhaps
I'd like to make a formal feature request for 120 MHz master clock?? It
strikes me as odd that so many of the "whole number" MHz sample rates are
neglected on the n3xx series by default-- it's often the case that I'll
want to interact with other hardware with baud rates at, say, 2 MHz or 10
MHz or something, but I just don't have the fpga-based fractional
conversions onhand right now...

I'm certainly not afraid of nontrivial changes, so if the AD9371 supports a
clock rate that can give me these derived sample rates, I really see this
as the best solution since other platforms can already achieve these rates
without extra user-space processing requirements.

However, if needed, potentially a "quick and dirty" approach might be to
make an rfnoc fractional resampler that combines a DUC and DDC into one
"ce", with a block controller to calculate the magical conversions... It's
not an optimal solution but it might do the trick here. Anyone else
interested in such an fpga-based fractional resampler?

EJ

On Wed, Oct 17, 2018, 1:52 PM Daniel Jepson via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi EJ,
>
> The fundamental limitation comes from the AD9371. Although the datasheet
> specifies a wide reference clock input range, there are only certain
> supported rates within the public side of their API (at least that I'm
> aware of). These include the rates you mentioned from the KB.
>
> Assuming the AD9371 allows it, adding a new MCR is not trivial and would
> require a good deal of work across hardware, FPGA code, and MPM. The
> fractional resampler sounds like a much better path forward, albeit
> difficult right now.
>
> Hopefully that explains some of the background on the chosen MCRs. Sorry
> it wasn't exactly what you were hoping for!
>
> -Daniel
>
> On Wed, Oct 17, 2018 at 10:50 AM EJ Kreinar via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hi all,
>>
>> I'm working on an FPGA application on the n310/n300, and I'm bumping into
>> a limitation of the master_clock_rate selection I'd like to be able to
>> use sample rates in the FPGA of 2 MHz, 4 MHz, and 10 MHz, but none of these
>> values are integer multiples of the supported rates (122.88e6, 125e6,
>> 153.6e6 -- from here:
>> https://kb.ettus.com/N300/N310_Getting_Started_Guides#Supported_Sample_Rates).
>> This causes a problem in the FPGA since I would need a fractional
>> resampler, which I dont currently have, unfortunately.
>>
>> What's the fundamental limitation of these master clock rates? I would
>> have assumed that the AD9371-based architecture would have resulted in a
>> wider variety of plausible clock rates, similar to the AD9361 on the E310.
>> I havent found these limits yet in the software or FPGA, so any pointers
>> where to look would be appreciated.
>>
>> As a follow up question, how feasible would it be to add a master clock
>> rate of 120 MHz?? Any ideas where to make these changes? This would answer
>> the mail for my sample rates of interest right now.
>>
>> Thanks!
>> EJ
>> ___
>> USRP-users mailing list
>> USRP-users@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>
>
> --
>
> Daniel Jepson
>
> Digital Hardware Engineer
>
> National Instruments
>
>
>
> O: +1.512.683.6163
>
> daniel.jep...@ni.com
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>

On Wed, Oct 17, 2018, 1:52 PM Daniel Jepson via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi EJ,
>
> The fundamental limitation comes from the AD9371. Although the datasheet
> specifies a wide reference clock input range, there are only certain
> supported rates within the public side of their API (at least that I'm
> aware of). These include the rates you mentioned from the KB.
>
> Assuming the AD9371 allows it, adding a new MCR is not trivial and would
> require a good deal of work across hardware, FPGA code, and MPM. The
> fractional resampler sounds like a much better path forward, albeit
> difficult right now.
>
> Hopefully that explains some of the background on the chosen MCRs. Sorry
> it wasn't exactly what you were hoping for!
>
> -Daniel
>
> On Wed, Oct 17, 2018 at 10:50 AM EJ Kreinar via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hi all,
>>
>> I'm working on 

[USRP-users] n3xx master clock rate selection

[EJ Kreinar via USRP-users]

Hi all,

I'm working on an FPGA application on the n310/n300, and I'm bumping into a
limitation of the master_clock_rate selection I'd like to be able to
use sample rates in the FPGA of 2 MHz, 4 MHz, and 10 MHz, but none of these
values are integer multiples of the supported rates (122.88e6, 125e6,
153.6e6 -- from here:
https://kb.ettus.com/N300/N310_Getting_Started_Guides#Supported_Sample_Rates).
This causes a problem in the FPGA since I would need a fractional
resampler, which I dont currently have, unfortunately.

What's the fundamental limitation of these master clock rates? I would have
assumed that the AD9371-based architecture would have resulted in a wider
variety of plausible clock rates, similar to the AD9361 on the E310. I
havent found these limits yet in the software or FPGA, so any pointers
where to look would be appreciated.

As a follow up question, how feasible would it be to add a master clock
rate of 120 MHz?? Any ideas where to make these changes? This would answer
the mail for my sample rates of interest right now.

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

Re: [USRP-users] Can't find a block controller for key FFT, using default block controller!

[EJ Kreinar via USRP-users]

In place of some repo with a git edit, I've copied the relevant changes
from git format-patch below (not sure if it will apply cleanly to the
current codebase, but the intent should be clear). As you can see it's
pretty much a one-liner that just removes the "print" part of the
UHD_SAFE_CALL.

---
 host/lib/rfnoc/ctrl_iface.cpp | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/host/lib/rfnoc/ctrl_iface.cpp b/host/lib/rfnoc/ctrl_iface.cpp
index 11dfa7aaa..48f0e6da2 100644
--- a/host/lib/rfnoc/ctrl_iface.cpp
+++ b/host/lib/rfnoc/ctrl_iface.cpp
@@ -54,10 +54,14 @@ public:

 virtual ~ctrl_iface_impl(void)
 {
-UHD_SAFE_CALL(
+try{
 // dummy peek with the purpose of ack'ing all packets
 this->send_cmd_pkt(0, 0, true);
-)
+}
+catch(const std::exception ){ \
+// Dont print the output
+// _UHD_SAFE_CALL_WARNING(code, e.what());
+}
 }

 /***
-- 

EJ


On Tue, Sep 25, 2018 at 7:55 AM Jason Matusiak <
ja...@gardettoengineering.com> wrote:

> I wouldn't mind seeing your solution to #2 as well.  The messages
> certainly make things look more ominous than they actually are.
>
>
>
> - Original Message -
> Subject: Re: [USRP-users] Can't find a block controller for key FFT, using
> default block controller!
> From: "EJ Kreinar via USRP-users" 
> Date: 9/24/18 7:51 pm
> To: "Rich Maes" 
> Cc: "USRP-users@lists.ettus.com" 
>
> Hi Rich,
>
> This all looks OK to me.
>
> 1) the block controller warning just indicates there's no *custom* block
> controller for a particular block. By default the XML noc block definition
> will typically populate read/write registers in a default block controller
> just fine.
>
> 2) the errors at the end are expected for the e310, as you have indicated.
> I've suppressed these myself; perhaps I'll write this up and provide an out
> of tree fix for those of us who dont want to always see the errors output
> to console.
>
> EJ
>
> On Mon, Sep 24, 2018, 5:35 PM Rich Maes via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Re-pining this question
>>
>> On Sep 2, 2018, at 10:48 PM, Rich Maes  wrote:
>>
>> I am running a cross-compiled UHD environment on a E310.  I have a couple
>> warning that appear when I am running my uhd_usrp_probe with a custom FPGA
>> image.  The image I have created has 2 FFT’s and 2 Windows in it.  The
>> warning indicate that the controller blocks cannot be found for the FFT’s.
>>
>> Later, at the bottom of the run, I get some errors like the following
>> [ERROR] [UHD] Exception caught in safe-call.
>>
>> I would like to confirm that the lack of a controller for the FFT is a
>> real problem that needs to be resolved.
>>
>> Relative to the exceptions at the end, I have read that although this is
>> an error, it does not prevent running applications
>>
>> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2017-March/051914.html
>>
>>
>>
>> root@ettus-e3xx-sg3:~/localinstall/usr/share/uhd/images# uhd_usrp_probe
>> --args='fpga=usrp_e310_fpga_RFNOC_sg3.bit'
>> [INFO] [UHD] linux; GNU C++ version 4.9.2; Boost_105700;
>> UHD_4.0.0.rfnoc-devel-702-geec24d7b
>> [INFO] [E300] Loading FPGA image: usrp_e310_fpga_RFNOC_sg3.bit...
>> [INFO] [E300] FPGA image loaded
>> [INFO] [E300] Initializing core control (global registers)...
>>
>> [INFO] [E300] Performing register loopback test...
>> [INFO] [E300] Register loopback test passed
>> [INFO] [0/Radio_0] Initializing block control (NOC ID:
>> 0x12AD1000)
>> [INFO] [0/Window_0] Initializing block control (NOC ID:
>> 0xD053)
>> [INFO] [0/Window_1] Initializing block control (NOC ID:
>> 0xD053)
>> [WARNING] [RFNOC] Can't find a block controller for key FFT, using
>> default block controller!
>> [INFO] [0/FFT_0] Initializing block control (NOC ID: 0xFF70)
>> [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)
>>   _
>>  /
>> |   Device: E-Series Device
>> | _
>> |/
>> |   |   Mboard: E3XX SG3
>> |   |   product: 30675
>> |   |   revision: 7
>> |   |   serial: 3150D1D
>> |   |   mac-addr: 00:80:2f:19:10:70
>> |   |   FPGA Version: 255.0

Re: [USRP-users] Can't find a block controller for key FFT, using default block controller!

[EJ Kreinar via USRP-users]

Hi Rich,

This all looks OK to me.

1) the block controller warning just indicates there's no *custom* block
controller for a particular block. By default the XML noc block definition
will typically populate read/write registers in a default block controller
just fine.

2) the errors at the end are expected for the e310, as you have indicated.
I've suppressed these myself; perhaps I'll write this up and provide an out
of tree fix for those of us who dont want to always see the errors output
to console.

EJ

On Mon, Sep 24, 2018, 5:35 PM Rich Maes via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Re-pining this question
>
> On Sep 2, 2018, at 10:48 PM, Rich Maes  wrote:
>
> I am running a cross-compiled UHD environment on a E310.  I have a couple
> warning that appear when I am running my uhd_usrp_probe with a custom FPGA
> image.  The image I have created has 2 FFT’s and 2 Windows in it.  The
> warning indicate that the controller blocks cannot be found for the FFT’s.
>
> Later, at the bottom of the run, I get some errors like the following
> [ERROR] [UHD] Exception caught in safe-call.
>
> I would like to confirm that the lack of a controller for the FFT is a
> real problem that needs to be resolved.
>
> Relative to the exceptions at the end, I have read that although this is
> an error, it does not prevent running applications
>
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2017-March/051914.html
>
>
>
> root@ettus-e3xx-sg3:~/localinstall/usr/share/uhd/images# uhd_usrp_probe
> --args='fpga=usrp_e310_fpga_RFNOC_sg3.bit'
> [INFO] [UHD] linux; GNU C++ version 4.9.2; Boost_105700;
> UHD_4.0.0.rfnoc-devel-702-geec24d7b
> [INFO] [E300] Loading FPGA image: usrp_e310_fpga_RFNOC_sg3.bit...
> [INFO] [E300] FPGA image loaded
> [INFO] [E300] Initializing core control (global registers)...
>
> [INFO] [E300] Performing register loopback test...
> [INFO] [E300] Register loopback test passed
> [INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD1000)
> [INFO] [0/Window_0] Initializing block control (NOC ID:
> 0xD053)
> [INFO] [0/Window_1] Initializing block control (NOC ID:
> 0xD053)
> [WARNING] [RFNOC] Can't find a block controller for key FFT, using
> default block controller!
> [INFO] [0/FFT_0] Initializing block control (NOC ID: 0xFF70)
> [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)
>   _
>  /
> |   Device: E-Series Device
> | _
> |/
> |   |   Mboard: E3XX SG3
> |   |   product: 30675
> |   |   revision: 7
> |   |   serial: 3150D1D
> |   |   mac-addr: 00:80:2f:19:10:70
> |   |   FPGA Version: 255.0
> |   |   FPGA git hash: 1b40696-dirty
> |   |   RFNoC capable: Yes
> |   |
> |   |   Time sources:  none, internal, external
> |   |   Clock sources: internal
> |   |   Sensors: temp, ref_locked
> |   | _
> |   |/
> |   |   |   RX DSP: 0
> |   |   |
> |   |   |   Freq range: 0.000 to 0.000 MHz
> |   | _
> |   |/
> |   |   |   RX DSP: 1
> |   |   |
> |   |   |   Freq range: 0.000 to 0.000 MHz
> |   | _
> |   |/
> |   |   |   RX Dboard: A
> |   |   |   ID: E310 MIMO XCVR (0x0110)
> |   |   |   Serial: 314E574
> |   |   | _
> |   |   |/
> |   |   |   |   RX Frontend: A
> |   |   |   |   Name: FE-RX2
> |   |   |   |   Antennas: TX/RX, RX2
> |   |   |   |   Sensors: temp, rssi, lo_locked
> |   |   |   |   Freq range: 50.000 to 6000.000 MHz
> |   |   |   |   Gain range PGA: 0.0 to 76.0 step 1.0 dB
> |   |   |   |   Bandwidth range: 20.0 to 5600.0 step 0.0 Hz
> |   |   |   |   Connection Type: IQ
> |   |   |   |   Uses LO offset: No
> |   |   | _
> |   |   |/
> |   |   |   |   RX Frontend: B
> |   |   |   |   Name: FE-RX1
> |   |   |   |   Antennas: TX/RX, RX2
> |   |   |   |   Sensors: temp, rssi, lo_locked
> |   |   |   |   Freq range: 50.000 to 6000.000 MHz
> |   |   |   |   Gain range PGA: 0.0 to 76.0 step 1.0 dB
> |   |   |   |   Bandwidth range: 20.0 to 5600.0 step 0.0 Hz
> |   |   |   |   Connection Type: IQ
> |   |   |   |   Uses LO offset: No
> |   |   | _
> |   |   |/
> |   |   |   |   RX Codec: A
> |   |   |   |   Name: E3x0 RX dual ADC
> |   |   |   |   Gain Elements: None
> |   | _
> |   |/
> |   |   |   TX DSP: 0
> |   |   |
> |   |   |   Freq range: 0.000 to 0.000 MHz
> |   | _
> |   |

Re: [USRP-users] Compilation error while using HLS IP

[EJ Kreinar via USRP-users]

Hi Arnika,

Good catch. It looks like the commit here changed HLS generation:
https://github.com/EttusResearch/fpga/commit/615d9b8eeb94ee2d19c3b1e7aa526d4999495e05

I tested the addsub_hls testbench, which runs fine. However, it seems as
though the devices (e300, n3xx, x310) have no process to include the addsub
output sources in the build. I havent had a chance to confirm success yet,
but here's a possible fix pushed to my fork:
https://github.com/ejk43/fpga/tree/fix-new-hls-builds

EJ

On Mon, Sep 10, 2018 at 10:19 AM Arnika Zoe via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi all,
> After updating fpga source to most recent master branch, I noticed that
> rfnoc blocks, which uses HLS generated IP cores, are no longer synthesizing
> with the project. Furthermore, viv_hls_ip_builder is not starting at all. I
> think that the reason of this problem is missing HLS targets in main x300
> makefile (Makefile.x300.inc). Could someone confirm this issue / propose
> solution?
>
> Error from building example provided by Ettus (addsub_hls):
>
> ERROR: [Synth 8-439] module 'addsub_hls' not found
> [/workarea/fpga/usrp3/lib/rfnoc/noc_block_addsub.v:88]
> ERROR: [Synth 8-285] failed synthesizing module 'noc_block_addsub'
> [/workarea/fpga/usrp3/lib/rfnoc/noc_block_addsub.v:8]
> ERROR: [Synth 8-285] failed synthesizing module 'x300_core'
> [/workarea/fpga/usrp3/top/x300/x300_core.v:8]
> ERROR: [Synth 8-285] failed synthesizing module 'x300'
> [/workarea/fpga/usrp3/top/x300/x300.v:20]
> ERROR: [Common 17-69] Command failed: Synthesis failed - please see the
> console or run log file for details
> [00:03:07] Current task: Synthesis +++ Current Phase: Starting
> [00:03:07] Current task: Synthesis +++ Current Phase: Finished
> [00:03:07] Process terminated. Status: Failure
> --
> Best regards
> Arnika
> ___
> 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] axi_round_and_clip busted?

[EJ Kreinar via USRP-users]

I've also used axi_round_and_clip successfully.

I did find an edge case where part of the logic is incorrectly removed if
the WIDTH_OUT == CLIP_BITS. This was (very recently) updated:
https://github.com/EttusResearch/fpga/commit/454b17c501d333b06831ae535b6e60ba86d850af

I'd be curious to see if this particular scenario applies to you.

EJ

On Fri, Aug 31, 2018, 6:19 PM Nick Foster via USRP-users <
usrp-users@lists.ettus.com> wrote:

> I've successfully used axi_round_and_clip in a number of designs and it
> seems to simulate fine for me. Xsim or vsim? How is it being instantiated?
> What weird internal simulation issues are you seeing?
>
> Nick
>
> On Fri, Aug 31, 2018 at 2:58 PM Andrew Danowitz via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> When I try to use axi_round_and_clip in my design, simulation won't run
>> and has weird internal simulation issues. If I build it into an rfnoc
>> image, the flow graph doesn't return any data. Has anyone else run into
>> this?
>>
>> --
>> 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 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 not compatible with FPGA master noc_shell

[EJ Kreinar via USRP-users]

Personally I appreciate the recent public-facing FPGA development and
release cadence, and it's understandable the repos can become out of sync
(I seem to remember seeing a warning about more development on the master
branches a few months ago). One problem though is that the current
tutorials and rfnoc instructions are not exactly set up to handle
out-of-sync master branches. Cloning uhd-fpga from the uhd submodule within
pybombs sounds like a great solution.

As a matter of good practice, might I suggest updating tutorials and the
rfnoc OOT fpga build process to point to the uhd-fpga submodule, rather
than an adjacent uhd-rpga repo clone? This would probably help others avoid
this sort of compatibility problems in the future.

Just a thought,
EJ

On Fri, Aug 31, 2018, 5:56 PM Andrew Danowitz via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi Brent,
>
> Sounds good. I think the gnuradio pybombs recipe pulls in volk as a
> submodule. I think they manage it with the line "gitargs: --recursive" in
> their recipe.
>
> On Fri, Aug 31, 2018 at 2:15 PM, Brent Stapleton via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> The underlying reason for the mismatches is that, because the
>> uhd/fpga-src submodule points to a commit on fpga, we need THAT commit to
>> be on the fpga master branch. So, by necessity, we'll always have some
>> amount of time in which the two repositories are out of sync (that is, fpga
>> is ahead of uhd). This window was longer than usual, and we apologize for
>> that. In the future, if hiccups like this are an absolute deal-breaker for
>> you, please consider using the submodule pointer, or one of the UHD release
>> branches.
>>
>> Regarding PyBOMBS, as far as I can tell, there isn't a silver bullet in
>> this situation. I like the idea of the uhd-fpga recipe tracking
>> uhd/fpga-src, but I don't think git can clone submodules. The best thing
>> that comes to mind is to have the uhd-fpga recipe populate the uhd/fpga-src
>> submodule, which just saves the effort of manually updating the submodule.
>> If you have a better suggestion, we'd love to hear it.
>>
>> Best Regards,
>> Brent
>>
>> On Thu, Aug 30, 2018 at 5:28 PM Juan Francisco 
>> wrote:
>>
>>> It seems that this issue has tripped up several people.  It might be
>>> prudent to not push the FPGA changes to master until you have the
>>> corresponding UHD updates ready to go.
>>>
>>> On Thu, Aug 30, 2018 at 12:49 PM Brent Stapleton <
>>> brent.staple...@ettus.com> wrote:
>>>
 Hi Juan,

 In general, FPGA images built from the submodule in the uhd repository
 will be compatible with UHD built from that commit. The HEADs of the two
 master branches (uhd and fpga) do not have that guarantee. For example, the
 HEAD of uhd master branch (as I write this email) is the git
 commit 3b42e6f0, and the submodule points to the commit c3987555 on fpga.
 Those both use NoC shell compat number 4.

 We'll get the noc shell compat 5 changes out ASAP though, so don't
 throw away that image.

 Regards,
 Brent

 On Wed, Aug 29, 2018 at 7:14 PM Juan Francisco via USRP-users <
 usrp-users@lists.ettus.com> wrote:

> There appears to be a compatibility mismatch for the latest FPGA
> master and UHD.  I built a new image from fpga master today, but
> uhd_usrp_probe from UHD (w/ -DENABLE_RFNOC=ON) gives me the error message
> below:
>
> [INFO] [0/DmaFIFO_0] Initializing block control (NOC ID:
> 0xF1F0D000)
> [ERROR] [0/DmaFIFO_0] Major compat number mismatch for noc_shell:
> Expecting 4, got 5.
> Error: RuntimeError: FPGA component `noc_shell' is revision 5 and UHD
> supports revision 4. Please either upgrade UHD  (recommended) or downgrade
> the FPGA image.
>
> Thanks,
> Juan
> ___
> 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
>>
>>
>
> --
> 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 

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

[EJ Kreinar via USRP-users]

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 <
daniel.rausc...@fkie.fraunhofer.de> 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 <
> 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 <
>> 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

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

[EJ Kreinar via USRP-users]

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

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

[EJ Kreinar via USRP-users]

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

Re: [USRP-users] Debugging RFNoC siggen

[EJ Kreinar via USRP-users]

Hi Koen,

There's also a potential deadlock situation to watch out for: If your block
output samples to the axi_wrapper *before* UHD software assigns a
destination address, I've seen the axi_wrapper FIFO become full and
deadlock somewhere in the transmit path. This was an issue several 6-12
months ago with the noc_block_siggen, at least, and the siggen enable
register needed to be enabled explicitly *after* UHD had called "connect".

I'm not confident this is still an issue, or if it's been fixed in the
intermediate time, but it's something to watch out for. Based on my rough
understanding of your block, it sounds like the ready signal from the
axi_wrapper might go high immediately after the block initializes, and your
user block would then try to dump a lot of data into the axi_wrapper before
things are configured.

EJ

On Fri, Aug 10, 2018 at 6:18 AM Jon Pendlum via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi Koen,
>
> Your block should not wait on tready, that is a violation of the AXI spec.
> Some blocks actually wait for tvalid to be asserted before asserting tready
> (that is permitted by the spec), which would cause a deadlock in your
> situation. You can work around that by putting an axi_flip_flop in the path
> since it will always assert tready when it can.
>
> However, I don't think that is your issue. You should be interfacing your
> logic with the AXI wrapper instance in your block. AXI wrapper's
> s_axis_data_tready signal essentially connects to a FIFO, so you should see
> it assert. Do you see that?
>
> Jonathon
>
>
> On Fri, Aug 10, 2018, 5:52 PM TIMMEN Koen via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hello all,
>>
>>
>>
>> Last week I posted a question, on how I could confirm that a custom RFNoC
>> signal generator (piloted from a UHD API) functioned as intended. I
>> received the tip to probe my block using the Vivado ILA. A great idea,
>> because I did not know this existed (I am quite new in FPGA design) and it
>> is a useful tool.
>>
>>
>>
>> Now, I was able to confirm that my custom block is functioning as
>> intended by placing an ILA internal to it. However, no actual samples are
>> ever generated due to a design choice I made; sample generation is only
>> triggered when the block receives a tready signal from a downstream block.
>> In this case a DUC block. In other words, the block stays dormant, waiting
>> to receive a trigger.
>>
>>
>>
>> That leaves me with the question why it never receives this signal. Could
>> someone explain to me at what point a DUC block will assert its tready
>> signal? I was under the impression that as soon as I connected the blocks
>> (using uhd::rfnoc::graph::connect()) as follows: SIGGEN à DUC à Radio,
>> the DUC and Radio blocks would be asserting their ready samples directly
>> after. But apparently this is not the case.
>>
>>
>>
>> Thank you for your replies,
>>
>>
>>
>> Koen
>>
>>
>>
>>
>>
>>
>> ___
>> 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] RFNoc Blocks with Xilinx IP

[EJ Kreinar via USRP-users]

Hi Brendon, and usrp-users (adding the mailing list back to the
conversation),

This sounds like a problem with the makefile setup. You'll want to check
that your sources are correctly added to the DESIGN_SRCS variable in your
testbench Makefile (see below for reference...).  Directories variables all
need to point to the correct place (your equivalent RFNOC_OOTEXAMPLE_DIR is
set up correctly in the testbench Makefile and used correctly in the
ip//Makefile.inc).

One thing I'll do to help debug is use makefile warnings. For example, this
should print out the .xci file source location when building. (If it's
blank, or not there, something's definitely wrong)

```
RFNOC_OOTEXAMPLE_DIR = $(abspath ../../)

# Include makefiles and sources for all IP components
# *after* defining the LIB_IP_DIR
include $(RFNOC_OOTEXAMPLE_DIR)/ip/complex_to_magphase_oot/Makefile.inc

DESIGN_SRCS += $(abspath \
$(LIB_IP_COMPLEX_TO_MAGPHASE_OOT_SRCS) \

$(warning $(LIB_IP_COMPLEX_TO_MAGPHASE_OOT_SRCS))
)
```

Hope this helps,
EJ


On Fri, Jul 27, 2018 at 8:09 AM Chetwynd, Brendon - 0551 - MITLL <
brendon.chetw...@ll.mit.edu> wrote:

> EJ,
>
>
>
> Thanks for the repo.  I was able to successfully get it up and running
> with your example.
>
>
>
> I am attempting to add my own module with two Xilinx IP blocks (one
> CORDIC, one Data Width Converter).
>
>
>
> Any sort of gotchas I should be worried about?  I have modified the
> scripts in what seems like a logical fashion, but when attempting to
> simulate the modules do not get properly elaborated (interesting enough I
> see my new module being compiled and elaborated, but when simulation begins
> the scripts complain about not finding the module.
>
>
>
> Thanks,
>
> Brendon
>
>
>
>
> 
>
> Brendon Chetwynd Technical
> Staff
>
> MIT Lincoln Laboratory
>
>  Cyber Systems and Operations (Group
> 51)
>
>
>
> 244 Wood StreetLexington, MA
> 02420-9185
>
>781-981-8212
> (office)
>
> brendon.chetw...@ll.mit.edu781-879-4635 (cell)
>
>781-387-3030 (pager)
>
>781-981-7548 (fax)
>
>
> 
>
>
>
> *From:* EJ Kreinar 
> *Sent:* Saturday, July 21, 2018 6:59 PM
> *To:* Neel Pandeya 
> *Cc:* Chetwynd, Brendon - 0551 - MITLL ;
> USRP-users@lists.ettus.com
> *Subject:* Re: [USRP-users] RFNoc Blocks with Xilinx IP
>
>
>
> Hi Brendon,
>
>
>
> I went ahead and updated the OOT example repo to be compatible with Vivado
> 2017.4 and the uhd-fpga "master" branch:
> https://github.com/ejk43/rfnoc-ootexample
>
>
>
> The simulation testbenches now run using uhd-fpga master. Let me know if
> this works for you. Thanks!
>
> EJ
>
>
>
> On Fri, Jul 20, 2018 at 1:01 PM EJ Kreinar  wrote:
>
> Hi Brendon,
>
>
>
> I have an example repo that shows how to use out-of-tree makefiles with
> xilinx IP (.xci definitions): github.com/ejk43/rfnoc-ootexample
>
>
>
> Please feel free to copy this format-  a few other rfnoc developers on the
> mailing list indicated it has worked for them too.
>
>
>
> Note that the rfnoc blocks are currently targeting the uhd-fpga source
> code as of Vivado 2015.4, and the testbenches will NOT currently run
> against most recent uhd-fpga and Vivado 2017.4. I would really appreciate a
> PR to update the IP to use vivado 2017.4 and noc blocks with the new inputs
> to the noc_shell :) I'll update it "eventually" but no idea when exactly.
>
>
>
> Hope this helps! Looking forward to seeing your OOT fpga blocks :)
>
>
>
> EJ
>
>
>
> On Fri, Jul 20, 2018, 12:19 PM Neel Pandeya via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
> Hello Brendon:
>
>
>
> Could you describe in more detail what you're trying to do, or how you
> want to add your Xilinx IP?
>
>
>
> Are you still using "rfnocmodtool" to add your custom RFNoC blocks?
>
>
>
> The flow described in that document, and in the Application Note below, is
> the primary/intended way to add IP to an RFNoC installation.
>
>
>
> https://kb.ettus.com/Getting_Started_with_RFNoC_Development
>
>
>
> Please note that you should use the head of the UHD master branch, not the
> "rfnoc-devel" branch, when using RFNoC.
>
>
>
> --​Neel Pandeya
>
>
>
>
>
>
>
>
>
> On 20 July 2018 at 07:01, Chetwynd, Brendon - 0551 - MITLL via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
> I have been following the following blog post:
>
>
>
>
> http://www.synchronouslabs.com/blog/creating-a-custom-rfnoc-block-with-using-xillinx-ip
>
>
>
> Near the end, it instructs the user to add the Xilinx IP files (.xci for
> example) to the UHD project directory.
>
>
>
> However, as this is a clone of the Ettus Research repo (
> 

Re: [USRP-users] Error with multiple block output ports

[EJ Kreinar via USRP-users]

Hi,

I'll add a few thoughts since I've looked into this a bit...

> Although rfnoc supports different number of inputs and outputs uhd does
not and you'll get all sorts of issues trying to address this.

To clarify what I've seen in behavior and in the code, there are some
places in UHD software that assume rfnoc ports perform "pass-through"
operations, ie, that input port 0 is connected to output port 0, input port
1 to output port 1, etc. In most cases supported by "legacy mode" with
RFNoC, the pass-through operation makes sense (Radio -> DDC -> FIFO ->
Processor), but it does not seem to translate well into the fully arbitrary
/ more advanced scenarios possible with low-level RFNoC control...

Specifically, the original crash on this email thread appears to originate
from this sr_write operation in the device3_io_impl.cpp: (
https://github.com/EttusResearch/uhd/blob/master/host/lib/usrp/device3/device3_io_impl.cpp#L569
)

```
std::vector >
upstream_radio_nodes =
blk_ctrl->find_upstream_node();
UHD_RX_STREAMER_LOG() << "Number of upstream radio nodes: " <<
upstream_radio_nodes.size();
for(const boost::shared_ptr :
upstream_radio_nodes) {
node->sr_write(uhd::rfnoc::SR_RESP_OUT_DST_SID,
xport.send_sid.get_src(), block_port);
}
```

Clearly, it does not make sense to use block_port in the sr_write call
above because block_port is defined earlier as the output port of the
*downstream block* (in this case, the splitstream). Assuming this line is
changed (I have not tried a fix yet), it may also expose other issues in
UHD that assume pass-through block ports. In fact, just this one example
brings up another architectural questions. If the SR_RESP_OUT_DST_SID of
the radio block can only be assigned to ONE rx_streamer, then where are the
messages routed if you have multiple rx_streamers downstream from the same
radio output port (e.g. after a splitstream)? Does only one rx_streamer get
the benefit of receiving messages from the radio block? Is this even a
problem? I have not investigated far enough to find out.

EJ


On Tue, Jul 24, 2018 at 8:30 AM Dario Pennisi via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi guys,
> Although rfnoc supports different number of inputs and outputs uhd does
> not and you'll get all sorts of issues trying to address this.
> This is the reason why adder block also has a subtract output...
> Another issue is that loopback within fpga does not work. This means that
> signals in a chain have to originate or terminate on the host. If you have
> paths completely contained in rfnoc domain some streamers will not be
> enabled and you'll have to enable them manually.
> Finally remember that ports share the bandwidth of a single axi port so
> make sure total bandwidth is below it. For x310 axi bw is around 300 msps
>
>
> Dario Pennisi
>
>
>
>
> On Tue, Jul 24, 2018 at 1:56 PM +0200, "Carlos Alberto Ruiz Naranjo via
> USRP-users"  wrote:
>
> Please, any help?? :( :( :(
>>
>> 2018-07-12 19:13 GMT+02:00 Brassard, Sean M. :
>>
>>> We never received any help from Ettus on this and never got past the
>>> problem.
>>>
>>>
>>>
>>> Sean
>>>
>>>
>>>
>>> *From:* Carlos Alberto Ruiz Naranjo [mailto:carlosruiznara...@gmail.com]
>>>
>>> *Sent:* Thursday, July 12, 2018 2:42 AM
>>> *To:* Barker, Douglas W.
>>> *Cc:* Jonathon Pendlum; Yim, Kaun J.; usrp-users@lists.ettus.com;
>>> Brassard, Sean M.
>>>
>>> *Subject:* Re: [USRP-users] Error with multiple block output ports
>>>
>>>
>>>
>>> I have the same problem, any help? ^^
>>>
>>>
>>>
>>> 2017-06-06 13:45 GMT+02:00 Barker, Douglas W. via USRP-users <
>>> usrp-users@lists.ettus.com>:
>>>
>>> Hello,
>>>
>>>
>>>
>>> Is there any update on our issue?
>>>
>>>
>>>
>>> Thanks
>>>
>>> Doug
>>>
>>>
>>>
>>> *From:* Jonathon Pendlum [mailto:jonathon.pend...@ettus.com]
>>> *Sent:* Monday, May 29, 2017 2:16 AM
>>>
>>> *To:* Barker, Douglas W.
>>> *Cc:* usrp-users@lists.ettus.com
>>> *Subject:* Re: [USRP-users] Error with multiple block output ports
>>>
>>>
>>>
>>> Try fixing these issues, especially the first one, and see if that helps:
>>>
>>>
>>>
>>> - In uhd_rfnoc_split_stream.xml, the RX stream args defines 2 channels
>>> instead of 3.
>>>
>>> - In noc_block_split_stream.v, the ACTIVE_MASK on split_stream_fifo is
>>> set to have only two active outputs.
>>>
>>>
>>>
>>> On Fri, May 26, 2017 at 8:03 AM, Barker, Douglas W. <
>>> douglas.bar...@jhuapl.edu> wrote:
>>>
>>> Jonathon,
>>>
>>>
>>>
>>> I’ve attached the XML files that I was using.
>>>
>>>
>>>
>>>
>>>
>>> Thanks!
>>>
>>> Doug
>>>
>>>
>>>
>>> *From:* Jonathon Pendlum [mailto:jonathon.pend...@ettus.com]
>>> *Sent:* Thursday, May 25, 2017 3:46 PM
>>> *To:* Barker, Douglas W.
>>> *Cc:* usrp-users@lists.ettus.com
>>> *Subject:* Re: [USRP-users] Error with multiple block output ports
>>>
>>>
>>>
>>> Hi Doug,
>>>
>>>
>>>
>>> Can you share your Noc Script XML file?
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Jonathon
>>>
>>>
>>>
>>> On Fri, May 19, 2017 at 2:17 PM, Barker, 

Re: [USRP-users] RFNoc Blocks with Xilinx IP

[EJ Kreinar via USRP-users]

Hi Brendon,

I went ahead and updated the OOT example repo to be compatible with Vivado
2017.4 and the uhd-fpga "master" branch:
https://github.com/ejk43/rfnoc-ootexample

The simulation testbenches now run using uhd-fpga master. Let me know if
this works for you. Thanks!
EJ

On Fri, Jul 20, 2018 at 1:01 PM EJ Kreinar  wrote:

> Hi Brendon,
>
> I have an example repo that shows how to use out-of-tree makefiles with
> xilinx IP (.xci definitions): github.com/ejk43/rfnoc-ootexample
>
> Please feel free to copy this format-  a few other rfnoc developers on the
> mailing list indicated it has worked for them too.
>
> Note that the rfnoc blocks are currently targeting the uhd-fpga source
> code as of Vivado 2015.4, and the testbenches will NOT currently run
> against most recent uhd-fpga and Vivado 2017.4. I would really appreciate a
> PR to update the IP to use vivado 2017.4 and noc blocks with the new inputs
> to the noc_shell :) I'll update it "eventually" but no idea when exactly.
>
> Hope this helps! Looking forward to seeing your OOT fpga blocks :)
>
> EJ
>
> On Fri, Jul 20, 2018, 12:19 PM Neel Pandeya via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hello Brendon:
>>
>> Could you describe in more detail what you're trying to do, or how you
>> want to add your Xilinx IP?
>>
>> Are you still using "rfnocmodtool" to add your custom RFNoC blocks?
>>
>> The flow described in that document, and in the Application Note below,
>> is the primary/intended way to add IP to an RFNoC installation.
>>
>> https://kb.ettus.com/Getting_Started_with_RFNoC_Development
>>
>> Please note that you should use the head of the UHD master branch, not
>> the "rfnoc-devel" branch, when using RFNoC.
>>
>> --​Neel Pandeya
>>
>>
>>
>>
>> On 20 July 2018 at 07:01, Chetwynd, Brendon - 0551 - MITLL via USRP-users
>>  wrote:
>>
>>> I have been following the following blog post:
>>>
>>>
>>>
>>>
>>> http://www.synchronouslabs.com/blog/creating-a-custom-rfnoc-block-with-using-xillinx-ip
>>>
>>>
>>>
>>> Near the end, it instructs the user to add the Xilinx IP files (.xci for
>>> example) to the UHD project directory.
>>>
>>>
>>>
>>> However, as this is a clone of the Ettus Research repo (
>>> https://github.com/EttusResearch/fpga.git), I am wondering if there is
>>> another way to do it that is compliant with the RFNOC build process.
>>>
>>>
>>>
>>> Specifically, I would like to drop my customized Xilinx IP within my own
>>> rfnoc repository.
>>>
>>>
>>>
>>> Any advice?
>>>
>>>
>>>
>>> Thanks,
>>>
>>> Brendon
>>>
>>>
>>>
>>>
>>>
>>> ___
>>> 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] RFNoc Blocks with Xilinx IP

[EJ Kreinar via USRP-users]

Hi Brendon,

I have an example repo that shows how to use out-of-tree makefiles with
xilinx IP (.xci definitions): github.com/ejk43/rfnoc-ootexample

Please feel free to copy this format-  a few other rfnoc developers on the
mailing list indicated it has worked for them too.

Note that the rfnoc blocks are currently targeting the uhd-fpga source code
as of Vivado 2015.4, and the testbenches will NOT currently run against
most recent uhd-fpga and Vivado 2017.4. I would really appreciate a PR to
update the IP to use vivado 2017.4 and noc blocks with the new inputs to
the noc_shell :) I'll update it "eventually" but no idea when exactly.

Hope this helps! Looking forward to seeing your OOT fpga blocks :)

EJ

On Fri, Jul 20, 2018, 12:19 PM Neel Pandeya via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello Brendon:
>
> Could you describe in more detail what you're trying to do, or how you
> want to add your Xilinx IP?
>
> Are you still using "rfnocmodtool" to add your custom RFNoC blocks?
>
> The flow described in that document, and in the Application Note below, is
> the primary/intended way to add IP to an RFNoC installation.
>
> https://kb.ettus.com/Getting_Started_with_RFNoC_Development
>
> Please note that you should use the head of the UHD master branch, not the
> "rfnoc-devel" branch, when using RFNoC.
>
> --​Neel Pandeya
>
>
>
>
> On 20 July 2018 at 07:01, Chetwynd, Brendon - 0551 - MITLL via USRP-users
>  wrote:
>
>> I have been following the following blog post:
>>
>>
>>
>>
>> http://www.synchronouslabs.com/blog/creating-a-custom-rfnoc-block-with-using-xillinx-ip
>>
>>
>>
>> Near the end, it instructs the user to add the Xilinx IP files (.xci for
>> example) to the UHD project directory.
>>
>>
>>
>> However, as this is a clone of the Ettus Research repo (
>> https://github.com/EttusResearch/fpga.git), I am wondering if there is
>> another way to do it that is compliant with the RFNOC build process.
>>
>>
>>
>> Specifically, I would like to drop my customized Xilinx IP within my own
>> rfnoc repository.
>>
>>
>>
>> Any advice?
>>
>>
>>
>> Thanks,
>>
>> Brendon
>>
>>
>>
>>
>>
>> ___
>> 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] GNU radio receiving file, X310

[EJ Kreinar via USRP-users]

Hi Nives,

Doesnt look like anyone mentioned it yet, but this seems to me like a
common "gotcha" with RFNoC: You need at least two RFNoC blocks
back-to-back! I've had weird problems otherwise, and as far as I know using
just one RFNoC block is not yet officially supported (correct??).

Try a different flowgraph: `File Source => Throttle => RFNoC FIFO (index 0)
=> RFNoC FIFO (index 1) => File sink`

Make sure your RFNoC build has two FIFOs and that in GRC you set the fifo
indices to be 0 and 1 on each block.

Hope this helps...
EJ

On Thu, Jun 14, 2018 at 1:28 PM Marcus D. Leech via USRP-users <
usrp-users@lists.ettus.com> wrote:

> On 06/14/2018 01:01 PM, Michael West via USRP-users wrote:
>
> There may also be an issue with buffered I/O and how the flowgraph is
> stopped.  The kill flowgraph button in the main window of GRC is like
> hitting Ctrl-C.  Try closing the empty window that pops up.  You can also
> try making the file sink unbuffered and see if that makes a difference.
>
> Regards,
> Michael
>
> Given that Gnu Radio is already buffering, using the "unbuffered" option
> all the time might not be so bad.
>
> The underlying issue is that the C-based 'stdio' buffering mechanism
> doesn't in and of itself provide any kind of "flush my buffers on program
> exit"
>   facility--because C doesn't really have anything like that.  So
> higher-level environments, like Python have mechanisms to take care of that
>   "most" of the time, except when you brutally kill them with a
> signal--the buffers remain uncommitted to the kernel and the program
>   leaves the building, so to speak.  However, if you use "unbuffered", the
> writes are committed immediately to the OS, which means that
>   they're already conceptually "on disk" from the perspective of any
> external observer.
>
>
>
>
>
> On Wed, Jun 13, 2018 at 2:34 PM, Martin Braun 
> wrote:
>
>> I would expect it grow indefinitely, but it might slow down after 1.2
>> MB. If repeat is on, expect lots of data.
>>
>> The 106 bytes vs. 64 bytes is more interesting. I don't see why, but
>> maybe somewhere the last 42 bytes are getting stuck. It might even be in
>> GNU Radio.
>>
>> Try a file that's a multiple of your SPP value, and see what happens
>> then (with repeat set to off).
>>
>> -- m
>>
>>
>> On 06/12/2018 01:37 AM, Nives Novković via USRP-users wrote:
>> > Hi Michael,
>> >
>> > Thank you for your answer. I am sending attached screenshot of the
>> > flowgraph and the console. I saw that if I modify the File Source block
>> > option repeat to "No" I receive only 64 bytes of a file that is 106
>> > bytes large. If I set it to "Yes" then the content of the sent file will
>> > repeat itself until it fills up 1.2MB on the receiving end.
>> >
>> > Also I tried using Head block but that only helps if I want to send a
>> > file that is smaller than 1.2MB.
>> >
>> >
>> > uto, 12. lip 2018. u 01:57 Michael West > > > napisao je:
>> >
>> > Hi Nives,
>> >
>> > It is difficult to help without more information.  If you share the
>> > flowgraph and console output, people on the list might be able to
>> > help more.
>> >
>> > Regards,
>> > Michael
>> >
>> > On Mon, Jun 11, 2018 at 1:01 AM, Nives Novković via USRP-users
>> > mailto:usrp-users@lists.ettus.com>>
>> wrote:
>> >
>> > Hi everyone,
>> >
>> > I am starting to familiarize myself with GNU radio and RFNoC.
>> > First thing I tried is simply to send a file to X310 using GNU
>> > radio and receive it back unchanged. For that I used blocks -
>> > File Source, Throttle, RFNoC: FIFO and File Sink. But no matter
>> > what size the file I send, I always receive 1.2MB. Even if my
>> > sent file is smaller than that it just multiplies the file
>> > content until it reaches 1.2MB. Do you have any idea what could
>> > be the problem?
>> >
>> > Kind regards,
>> > Nives
>> >
>> > ___
>> > 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 
> listUSRP-users@lists.ettus.comhttp://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] Run E310 without loading idle fpga image

[EJ Kreinar via USRP-users]

Hi Anisha,

There's a quick gotcha here: the "no_reload_fpga" flag also skips
programming the FPGA when *starting* the program.

You should try programming the FPGA manually before running with
"no_reload_fpga": `cat imagename.bit > /dev/xdevcfg`

Cheers,
EJ

On Wed, Jun 13, 2018 at 10:24 AM Anisha Gorur via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi,
>
> Is there a way to run the e310 without loading the idle image after
> completion? I saw from here:
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2016-September/021984.html
> that there is a flag you can pass called "no_reload_fpga", however, when I
> try uhd_usrp_probe --args=no_reload_fpga, I receive the error
> "RuntimeError: [ad9361_device_t] BBPLL not locked" almost immediately.
>
> Thanks,
>
> Anisha
>
>
> ___
> 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] Vivado 2017.4 testbench hangs at update_compile_order

[EJ Kreinar via USRP-users]

Hi All,

I'm seeing some odd behavior after upgrading uhd-fpga to Vivado 2017.4. It
appears some of my larger testbenches take a noticeably longer time to
complete the "update_compile_order" command before progressing.

Here's an example (see elapsed time of 10+ minutes, after the
update_compile_order tcl command with the -verbose option):

```
# set_property top $sim_top [get_filesets $sim_fileset]
# set_property default_lib xil_defaultlib [current_project]
# update_compile_order -fileset sim_1 -verbose
update_compile_order: *Time (s): cpu = 00:09:30 ; elapsed = 00:10:24 *.
Memory (MB): peak = 1218.863 ; gain = 20.000 ; free physical = 21745 ; free
virtual = 28625
# set_property target_simulator $simulator [current_project]
# if [expr [string equal $simulator "XSim"] == 1] {
# set_property verilog_define "WORKING_DIR=\"$working_dir\""
[get_filesets $sim_fileset]
# } else {
# set_property verilog_define "WORKING_DIR=$working_dir" [get_filesets
$sim_fileset]
# }
[...etc...]
```

The same OOT module testbench running Vivado 2015.4 and uhd-fpga
commit 434943b takes 18 seconds:

```
# set_property top $sim_top [get_filesets $sim_fileset]
# set_property default_lib xil_defaultlib [current_project]
# update_compile_order -fileset sim_1 -verbose
update_compile_order: *Time (s): cpu = 00:00:18 ; elapsed = 00:00:18 *.
Memory (MB): peak = 979.520 ; gain = 42.805 ; free physical = 12432 ; free
virtual = 26832
# set_property target_simulator $simulator [current_project]
# if [expr [string equal $simulator "XSim"] == 1] {
# set_property verilog_define "WORKING_DIR=\"$working_dir\""
[get_filesets $sim_fileset]
# } else {
# set_property verilog_define "WORKING_DIR=$working_dir" [get_filesets
$sim_fileset]
# }
[...etc...]
```

I havent tested or debugged exhaustively yet, but it will definitely become
a point of friction for simulations to take 10+ minutes to load. Has anyone
else seen this behavior? Is it a regression in Vivado? Thoughts appreciated.

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

Re: [USRP-users] Multiple Output RFNoC Block

[EJ Kreinar via USRP-users]

Hi Brian,

Fascinating question! I'm not sure many have considered this possibility
(1-input, 4-output RFNoC block), though I agree I'd like to see RFNoC
support this use-case...

Looks to me like this for loop in device3_io_impl could be getting in the
way:
https://github.com/EttusResearch/uhd/blob/rfnoc-devel/host/lib/usrp/device3/device3_io_impl.cpp#L569

Correct me if I'm wrong here, but it appears to be looping through all
upstream nodes and writing the response destination using the block port of
the *terminator* node, rather than the block port that's connected in the
RFNoC graph. This suggests to me there's an assumption that each block port
is always connected to the corresponding block port number of all upstream
nodes-- which is probably how the blocks are used in the majority of
configurations (2-channel radio -> 2-channel DDC -> 2-channel DMA FIFO),
but may not be sufficient for the arbitrary case...

Is my interpretation correct??
EJ



On Mon, May 28, 2018 at 5:35 PM, Brian Padalino via USRP-users <
usrp-users@lists.ettus.com> wrote:

> I've got a single input, 4-output RFNoC block that I am trying to hook up
> to a C++ testbench, but I'm having some trouble.
>
> Referencing the unaligned output version from gr-ettus:
>
>   https://github.com/EttusResearch/gr-ettus/blob/
> master/lib/rfnoc_block_impl.cc
>
> My graph is Radio -> DDC -> Custom Block -> Host.
>
> I am setting up my device_addr_t with 3 attributes: block_id, block_port,
> and block_portX where X is from 0 to 3.
>
> When I print my args I am sending into get_rx_stream(), they look
> appropriate:
>
>   block_id=0/MYBLOCK_0,block_port=0,block_port0=0
>
> The issue is when I get to block port 2, I get a LookupError about
> 0/Radio_0:
>
>   Error: LookupError: KeyError: [0/Radio_0] sr_write(): No such port: 2
>
> I'm sure I'm just doing something incorrectly, but I can't find much
> documentation on getting the streams working with multiple unaligned output
> ports from the same block coming back to the host.  I'm very confused why
> port 2 of the Radio is being addressed?
>
> I've used the noc_block_invert_tb as my guide to produce the streams in
> the FPGA:
>
>   https://github.com/EttusResearch/fpga/tree/rfnoc-
> devel/usrp3/lib/rfnoc/noc_block_invert_tb
>
> And an HDL testbench appears to work correctly.  Host UHD guidance is
> appreciated.  It would be nice to see real example C++ code interacting
> with UHD directly with the stock FPGA image.  I believe fosphor has 2
> output ports and 1 input port?
>
> Thanks,
> Brian
>
> ___
> 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] N310 streaming documentation

[EJ Kreinar via USRP-users]

I also find this confusing...

Even better: how about a scheme where x3xx finds both x300/x310, but x310
only gets x310, etc??

EJ


On Fri, May 11, 2018, 6:17 PM Marcus D. Leech via USRP-users <
usrp-users@lists.ettus.com> wrote:

> On 05/11/2018 06:14 PM, Brent Stapleton wrote:
>
> The `type` should be n3xx, not n300.
>
> --args "addr=192.168.10.2,type=n3xx"
>
> Brent
>
> Ah.  That's a change from N2xx and B2xx series.   Might I suggest putting
> in synonyms, so that folks used to previous naming schemes won't become
>   confused?
>
>
>
> On Fri, May 11, 2018 at 3:06 PM, Marcus D. Leech via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> On 05/11/2018 05:57 PM, Louis Brown via USRP-users wrote:
>>
>>>
>>> Is there documentation on getting the N310 streaming interface working?
>>> I'm able to ping the SFP0 port at 192.168.10.2 and the on-board at
>>> 192.168.1.4, but uhd_find_devices and uhd_usrp_probe find nothing:
>>>
>>> uhd_usrp_probe --args "addr=192.168.10.2"
>>> [INFO] [UHD] linux; GNU C++ version 8.1.1 20180502 (Red Hat 8.1.1-1);
>>> Boost_106600; UHD_3.11.1.0-0-g34c56104
>>> Error: LookupError: KeyError: No devices found for ->
>>> Device Address:
>>> addr: 192.168.10.2
>>>
>>> I did update the SD card image with:
>>>
>>>
>>> http://files.ettus.com/binaries/cache/n3xx/meta-ettus-v3.11.0.1-20180419/n3xx_common_sdimg_default-v3.11.0.1-20180419.zip
>>>
>>>
>>> The ASCII art spectrum test works fine, so the hardware seems to be
>>> working.
>>>
>>> Thanks,
>>> Lou
>>>
>>> COuld you try adding "type=n300" to your --args ??
>>
>> --args "addr=192.168.10.2,type=n300"
>>
>>
>>
>> ___
>> 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] RFNoC FPGA clear_tx_seqnum behavior

[EJ Kreinar via USRP-users]

Hi Ashish,

Awesome! Thanks for clarifying.

Just a thought here...

>If you download an FPGA image, run flow
>graph A, then without reloading the image you want to run flow graph B
>with a different topology then the clear signal will ensure that
>things are cleaned up properly between A and B. Do you really have to
>switch applications to reconfigure the topology? In theory, no, but we
>have some work to do on the graph resolution side in software to allow
>changing the topology on the fly. That feature isn't as high a
>priority because it is simple enough to just tear down and recreate
>the graph/device3 in UHD.

I'm not "here" yet, but I (eventually) have a requirement to run rfnoc
applications independently and simultaneously on an N310-like device. For
example: initialize one gnuradio application attached to one of the
noc_block_radios (basically tb.start()) , and then reconfigure a few of the
unused rfnoc blocks to bring up and down *different* gnuradio applications
using the second noc_block_radio and likely other noc_blocks, while the
first application is still streaming.

It looks to me like the fundamental fpga architecture should be able to run
this sort of application, but are you saying the current "clear" operations
in software will get in the way as-is?

If so, I will be happy to help work on this feature in the next 1-6 months.

Thanks!!

EJ

On Thu, May 3, 2018, 7:28 PM Ashish Chaudhari 
wrote:

> Hi EJ,
>
> On Thu, May 3, 2018 at 5:06 AM, EJ Kreinar  wrote:
> > Hi Ashish,
> >
> > Thanks for the info about rfnoc changes. Quick question:
> >
> >> In rfnoc, we make a
> >> distinction between reset and clear. A "reset" is meant to reset
> >> everything in a module to the power-up state. A "clear" only resets
> >> things that are not software controlled, like settings regs. The
> >> expectation is that you can configure your block, clear it to re-arm
> >> packet processing engines, etc and still preserve the settings you
> >> configured.
> >
> > Can you elaborate a little more? I understand that we want reset signal
> to
> > reset everything. But in your "cear" example, I expect that settings regs
> > *are* software controlled (configured via block constructor, for
> example),
> > and therefore we would not want them cleared.
> >
> > ... As I type this, I realize that is probably what you intended from the
> > original sentence. Is that correct??
>
> Yes, that is correct.
>
> > Thanks! Also very interested in hearing updates from Brian's questions...
>
> I just responded. Feel free to chime in if you have any follow ups.
>
> >
> > EJ
> >
> > On Wed, May 2, 2018 at 7:15 PM, Brian Padalino via USRP-users
> >  wrote:
> >>
> >> Hey Ashish,
> >>
> >> On Wed, May 2, 2018 at 7:02 PM Ashish Chaudhari
> >>  wrote:
> >>>
> >>> Hi Brian,
> >>>
> >>> >> > Moreover, it seems like axi_wrapper.v uses clear_tx_seqnum to pass
> >>> >> > out
> >>> >> > config bus messages, so now that clear_tx_seqnum is set I am not
> >>> >> > able to
> >>> >> > use
> >>> >> > the config bus from the axi_wrapper.
> >>> >>
> >>> >> I think this is a side effect of the assumption that data cannot
> flow
> >>> >> through the block when it is not in a graph. The AXI-Stream config
> bus
> >>> >> uses clear_tx_seqnum to hold itself in reset to you cannot use that
> >>> >> either when the data-path is disabled. Do you need to use the config
> >>> >> bus before you connect your block downstream? If so, you can try
> (as a
> >>> >> debugging step) to tied the clear signal to 0 here:
> >>> >>
> >>> >>
> >>> >>
> https://github.com/EttusResearch/fpga/blob/rfnoc-devel/usrp3/lib/rfnoc/axi_wrapper.v#L200
> .
> >>> >> If that makes your block work then it would confirm that the
> >>> >> aforementioned assumption is breaking your block. If so, we will go
> >>> >> back re-evaluate if we need to apply the clear_tx_seqnum to just the
> >>> >> data path and leave the control path alone.
> >>> >
> >>> >
> >>> > I re-created the old strobe methodology and fed that version into
> >>> > axi_wrapper and it fixed my issue, so it's definitely the thing that
> >>> > was
> >>> > gating me.
> >>>
> >>> OK, so I looked though the code and clear_tx_seqnum should not be
> >>> clearing the the config FIFO. That is the only place where it bleeds
> >>> into the control path. The primary purpose of that signal was to clear
> >>> the data path only. We will push the following patch into master (and
> >>> rfnoc-devel) to remedy that issue. In the meanwhile can you check if
> >>> that fixes your issue? You should not need to revert back to the
> >>> strobe approach or change anything in software.
> >>>
> >>> diff --git a/usrp3/lib/rfnoc/axi_wrapper.v
> >>> b/usrp3/lib/rfnoc/axi_wrapper.v
> >>> index f438587..1193692 100755
> >>> --- a/usrp3/lib/rfnoc/axi_wrapper.v
> >>> +++ b/usrp3/lib/rfnoc/axi_wrapper.v
> >>> @@ -197,7 +197,7 @@ module axi_wrapper
> >>> 

Re: [USRP-users] RFNoC: FIR Filter final tap never gets written to settings register

[EJ Kreinar via USRP-users]

Hey there,

A pretty useful test to see what's going on in hardware domain would be
like this:

File source => FIR => FIFO => File sink

In your file source, I'd suggest making a file that's all complex zeros
except for one sample that is set to "1" (or 1+1j). Running an impulse
(Dirac Delta) through a FIR filter will output each FIR tap, one at a time.
Just look at the output of the file sink and confirm all the taps have been
programmed correctly!

Hope this helps,
EJ

On Sat, Apr 21, 2018, 3:57 AM switchlanez via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Oh yeah... I actually knew that! Noticed that line several months ago but
> overlooked it this time because I was so determined to find the culprit for
> something else (Function Probe polling a file of tap values to rewrite taps
> to noc FIR block causes splashing across spectrum). Might post a new topic
> on that with video if we can't figure it out.
>
> That half sample shift doesn't happen when we run noc_block_fir_filter
> against its SystemVerilog testbench. Hoping the shift only happens if
> datastream crosses from hardware to host domain which would be fine since
> our application keeps the datastream on hardware. Just not sure how to
> verify no half sample shift is happening in the hardware domain.
>
> On Fri, Apr 20, 2018 at 3:56 PM, Jon Pendlum via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hey Andrew,
>>
>> The next line in fir_block_ctrl_impl.cpp sends the final tap:
>> sr_write(SR_RELOAD_TLAST, uint32_t(taps.back()));
>>
>> The half a sample shift is odd though.
>>
>> On Sat, Apr 21, 2018, 6:23 AM Marcus D. Leech via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> On 04/20/2018 12:01 PM, switchlanez via USRP-users wrote:
>>>
>>> Hello,
>>>
>>>
>>>
>>> An oddity regarding the RFNoC FIR Filter block. fir_block_ctrl_impl.cpp
>>> writes tap values to the settings registers with:
>>>
>>>
>>>
>>> for (size_t i = 0; i < taps.size() - 1; i++) {
>>> sr_write(SR_RELOAD, uint32_t(taps[i]));
>>>
>>> }
>>>
>>>
>>>
>>> which loops from 0 to taps.size() - 1. So if I define 41 taps from GRC,
>>> it only takes taps indexed from 0 to 39 and never writes tap index 40 (the
>>> 41st tap) to the settings register.
>>>
>>>
>>>
>>> I sort of confirmed this by comparing the RFNoC FIR Filter output
>>> against the GNU Radio Decimating FIR Filter (with Decimation=1) output with
>>> the same 41 taps and same input fed to both. Output gets shifted by half
>>> of a complex sample:
>>>
>>>
>>>
>>> GR FIR:
>>>
>>> 1 + .997j
>>>
>>> .994 + .991j
>>>
>>> .988 + ...
>>>
>>>
>>>
>>> RFNoC FIR:
>>>
>>> 0 + 1j
>>>
>>> .997 +.994j
>>>
>>> .991 + .988j
>>>
>>>
>>>
>>> Which is an effect of a FIR filter that has an even number of taps (40
>>> instead of 41).
>>>
>>>
>>>
>>> So I modified the condition in the FIR driver file to write from 0
>>> to taps.size() instead of taps.size()-1. Defined the 1st tap value to
>>> be 1000 with all remaining 40 taps as 0s. Viewed output on a spec an and
>>> saw nothing on output. Then moved the non-zero tap to the middle (21st
>>> index) with leading 20 and trailing 20 taps being 0s and saw the input fed
>>> to output. Now if I didn't modify the FIR driver file so it stops at
>>> taps.size()-1 and writes only 40 of my 41 taps and set the first tap to
>>> 1000 with 40 trailing zeros, I see input fed to output. Was the
>>> taps.size()-1 check intentional?
>>>
>>>
>>>
>>> Andrew
>>>
>>> This definitely looks to me like a subtle bug in the "off by one" error
>>> category.
>>>
>>> One of our RFNoC devs will probably chime in at this point, and provide
>>> an opinion
>>>
>>>
>>>
>>> ___
>>> 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
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Running neural network ex_1layer example on x310

[EJ Kreinar via USRP-users]

Well, looks like I've been called out...

Sorry Francesco: Unfortunately, I have not had a chance to 1) test the
examples on an x310  (I used E310 during development) or 2) update to
recent rfnoc-devel releases past GRCon 2017.

Usually "timeouts" in SW are not (by themselves) an indicator of an rfnoc
error, yet there should still be output for this example...

A few questions:
 - Are you using the 2015.4 rfnoc-devel branch? Could you specify your
uhd-fpga and uhd sha1s?
 - Is the .py file generated directly from the example?

I'll also add, in lieu of a helpful answer, there's a fun project called
hls4ml, recently released, that converts trained Keras models to an
HLS-compatible network: https://github.com/hls-fpga-machine-learning/hls4ml

I do intend to update the RFNoC-HLS-NeuralNet repo to interact with hls4ml
at some point, but no schedule for it yet :)

EJ



On Thu, Apr 19, 2018 at 11:42 AM, Neel Pandeya via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello Francesco:
>
> We do not directly provide technical support for the RFNoC blocks created
> by the teams in the Vivado HLS Challenge from last year.
>
> The ex_1layer example is from HLS Neuralnet, and the repository is at the
> link below.
>
> https://github.com/Xilinx/RFNoC-HLS-NeuralNet
>
> If you have any technical questions, you may want to reach out directly to
> the authors, although I think that they are on this list and are usually
> active.
>
> --​Neel Pandeya
>
>
>
> On 12 April 2018 at 07:59, Francesco Restuccia via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hi all,
>>
>> I was trying to run the ex_1layer example for neural networks on FPGA.
>>
>> Although the flowgraph starts, I get a series of ''timeout on chan0" and
>> no output is produced.
>>
>> Any suggestion?
>>
>> Thanks,
>>
>> Francesco
>>
>> Below is my code:
>>
>> ###
>>
>> #!/usr/bin/env python2
>> # -*- coding: utf-8 -*-
>> ##
>> # GNU Radio Python Flow Graph
>> # Title: Nnet Example 1Layer
>> # Generated: Thu Apr 12 08:45:12 2018
>> ##
>>
>> from gnuradio import blocks
>> from gnuradio import eng_notation
>> from gnuradio import gr
>> from gnuradio import uhd
>> from gnuradio.eng_option import eng_option
>> from gnuradio.filter import firdes
>> from optparse import OptionParser
>> import ettus
>> import pmt
>>
>>
>> class nnet_example_1layer(gr.top_block):
>>
>> def __init__(self, args=""):
>> gr.top_block.__init__(self, "Nnet Example 1Layer")
>>
>> ##
>> # Parameters
>> ##
>> self.args = args
>>
>> ##
>> # Variables
>> ##
>> self.device3 = variable_uhd_device3_0 =
>> ettus.device3(uhd.device_addr_t( ",".join(('type=x300', '')) ))
>> self.samp_rate = samp_rate = 784*1000
>>
>> ##
>> # Blocks
>> ##
>> self.uhd_rfnoc_streamer_fifo_0 = ettus.rfnoc_generic(
>> self.device3,
>> uhd.stream_args( # TX Stream Args
>> cpu_format="u8",
>> otw_format="u8",
>> args="gr_vlen=2,spp=2"
>> ),
>> uhd.stream_args( # RX Stream Args
>> cpu_format="u8",
>> otw_format="u8",
>> args="gr_vlen=2,spp=2"
>> ),
>> "FIFO", 0, -1,
>> )
>> self.fpgannet_ex1layer_0 = ettus.rfnoc_generic(
>> self.device3,
>> uhd.stream_args(
>> cpu_format="s16",
>> otw_format="s16",
>> args="gr_vlen=1,spp=1"
>> ),
>> uhd.stream_args(
>> cpu_format="s16",
>> otw_format="s16",
>> args="gr_vlen=1,spp=1"
>> ),
>> "ex1layer", -1, -1,
>> )
>>
>> self.blocks_throttle_0 = blocks.throttle(gr.sizeof_short*1,
>> samp_rate,True)
>> self.blocks_null_sink_0 = blocks.null_sink(gr.sizeof_short*1)
>> self.blocks_file_source_0 = blocks.file_source(gr.sizeof_short*1,
>> 'mnist_data_input.s16', False)
>> self.blocks_file_source_0.set_begin_tag(pmt.PMT_NIL)
>> self.blocks_file_sink_0 = blocks.file_sink(gr.sizeof_short*1,
>> 'mnist_rfnoc_output.s16', False)
>> self.blocks_file_sink_0.set_unbuffered(False)
>> self.blocks_deinterleave_0 = blocks.deinterleave(gr.sizeof_short*1,
>> 1)
>> self.blocks_copy_0 = blocks.copy(gr.sizeof_short*1)
>> self.blocks_copy_0.set_enabled(True)
>>
>>
>>
>> ##
>> # 

Re: [USRP-users] E310 default build of uhd-fpga/rfnoc-devel placer fails

[EJ Kreinar via USRP-users]

As a quick followup, it appears that resources requirements are just a tad
too high for the instantiations defined in rfnoc_ce_auto_inst_e310.v.

Editing the file to remove one of the two FIFOs builds successfully.

EJ

On Thu, Apr 19, 2018 at 10:19 AM, EJ Kreinar  wrote:

> Hi all,
>
> I've recently checked out the rfnoc-devel branch of uhd-fpga (which is now
> set to use Vivado 2017.4), SHA1 9c8c2ba...
>
> A default build from scratch (make E310_RFNOC_sg3) seems to fail to place
> all resources. Here's the tail of my console  output:
>
> [00:13:03] Current task: Placer +++ Current Phase: 1.2 IO Placement/ Clock
> Placement/ Build Placer Device
> [00:13:32] Current task: Placer +++ Current Phase: 1.3 Build Placer
> Netlist Model
> [00:13:33] Current task: Placer +++ Current Phase: 1.4 Constrain
> Clocks/Macros
> [00:14:48] Current task: Placer +++ Current Phase: 2 Global Placement
> [00:14:48] Current task: Placer +++ Current Phase: 3 Detail Placement
> [00:15:23] Current task: Placer +++ Current Phase: 3.1 Commit Multi Column
> Macros
> [00:15:24] Current task: Placer +++ Current Phase: 3.3 Area Swap
> Optimization
> [00:15:25] Current task: Placer +++ Current Phase: 3.4 Pipeline Register
> Optimization
> ERROR: [Place 30-487] The packing of instances into the device could not
> be obeyed. There are a total of 13300 slices in the pblock, of which 9305
> slices are available, however, the unplaced instances require 9329 slices.
> Please analyze your design to determine if the number of LUTs, FFs, and/or
> control sets can be reduced.
> ERROR: [Place 30-99] Placer failed with error: 'Detail Placement failed
> please check previous errors for details.'
> ERROR: [Common 17-69] Command failed: Placer could not place all instances
> [00:15:56] Current task: Placer +++ Current Phase: 3.5 Small Shape Detail
> Placement
> [00:15:56] Current task: Placer +++ Current Phase: Finished
> [00:15:56] Process terminated. Status: Failure
>
> 
> Warnings:   656
> Critical Warnings:  37
> Errors: 3
>
> Makefile.e300.inc:103: recipe for target 'bin' failed
> make[1]: *** [bin] Error 1
> make[1]: Leaving directory '/home/ejk/prefix/fpga-ettus/
> fpga/usrp3/top/e300'
> Makefile:71: recipe for target 'E310_RFNOC_sg3' failed
> make: *** [E310_RFNOC_sg3] Error 2
>
>
> This seems a little odd because the post_synth_util.rpt suggests we should
> have enough resources available after synthesis:
>
>
> ++---+---+---+---+
> |  Site Type |  Used | Fixed | Available | Util% |
> ++---+---+---+---+
> | Slice LUTs*| 42516 | 0 | 53200 | 79.92 |
> |   LUT as Logic | 33321 | 0 | 53200 | 62.63 |
> |   LUT as Memory|  9195 | 0 | 17400 | 52.84 |
> | LUT as Distributed RAM |  3990 | 0 |   |   |
> | LUT as Shift Register  |  5205 | 0 |   |   |
> | Slice Registers| 68993 |12 |106400 | 64.84 |
> |   Register as Flip Flop| 68993 |12 |106400 | 64.84 |
> |   Register as Latch| 0 | 0 |106400 |  0.00 |
> | F7 Muxes   |  1407 | 0 | 26600 |  5.29 |
> | F8 Muxes   |   254 | 0 | 13300 |  1.91 |
> ++---+---+---+---+
> +---+--+---+---+---+
> | Site Type | Used | Fixed | Available | Util% |
> +---+--+---+---+---+
> | Block RAM Tile|  121 | 0 |   140 | 86.43 |
> |   RAMB36/FIFO*|  108 | 0 |   140 | 77.14 |
> | RAMB36E1 only |  108 |   |   |   |
> |   RAMB18  |   26 | 0 |   280 |  9.29 |
> | RAMB18E1 only |   26 |   |   |   |
> +---+--+---+---+---+
> ++--+---+---+---+
> |Site Type   | Used | Fixed | Available | Util% |
> ++--+---+---+---+
> | DSPs   |  142 | 0 |   220 | 64.55 |
> |   DSP48E1 only |  142 |   |   |   |
> ++--+---+---+---+
>
> I'll try a build next with less "stuff" in the rfnoc_ce_auto_inst.v -- but
> is this currently expected behavior?
>
> Appreciate the help, thanks!
> EJ
>
>
>
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] E310 default build of uhd-fpga/rfnoc-devel placer fails

[EJ Kreinar via USRP-users]

Hi all,

I've recently checked out the rfnoc-devel branch of uhd-fpga (which is now
set to use Vivado 2017.4), SHA1 9c8c2ba...

A default build from scratch (make E310_RFNOC_sg3) seems to fail to place
all resources. Here's the tail of my console  output:

[00:13:03] Current task: Placer +++ Current Phase: 1.2 IO Placement/ Clock
Placement/ Build Placer Device
[00:13:32] Current task: Placer +++ Current Phase: 1.3 Build Placer Netlist
Model
[00:13:33] Current task: Placer +++ Current Phase: 1.4 Constrain
Clocks/Macros
[00:14:48] Current task: Placer +++ Current Phase: 2 Global Placement
[00:14:48] Current task: Placer +++ Current Phase: 3 Detail Placement
[00:15:23] Current task: Placer +++ Current Phase: 3.1 Commit Multi Column
Macros
[00:15:24] Current task: Placer +++ Current Phase: 3.3 Area Swap
Optimization
[00:15:25] Current task: Placer +++ Current Phase: 3.4 Pipeline Register
Optimization
ERROR: [Place 30-487] The packing of instances into the device could not be
obeyed. There are a total of 13300 slices in the pblock, of which 9305
slices are available, however, the unplaced instances require 9329 slices.
Please analyze your design to determine if the number of LUTs, FFs, and/or
control sets can be reduced.
ERROR: [Place 30-99] Placer failed with error: 'Detail Placement failed
please check previous errors for details.'
ERROR: [Common 17-69] Command failed: Placer could not place all instances
[00:15:56] Current task: Placer +++ Current Phase: 3.5 Small Shape Detail
Placement
[00:15:56] Current task: Placer +++ Current Phase: Finished
[00:15:56] Process terminated. Status: Failure


Warnings:   656
Critical Warnings:  37
Errors: 3

Makefile.e300.inc:103: recipe for target 'bin' failed
make[1]: *** [bin] Error 1
make[1]: Leaving directory '/home/ejk/prefix/fpga-ettus/fpga/usrp3/top/e300'
Makefile:71: recipe for target 'E310_RFNOC_sg3' failed
make: *** [E310_RFNOC_sg3] Error 2


This seems a little odd because the post_synth_util.rpt suggests we should
have enough resources available after synthesis:


++---+---+---+---+
|  Site Type |  Used | Fixed | Available | Util% |
++---+---+---+---+
| Slice LUTs*| 42516 | 0 | 53200 | 79.92 |
|   LUT as Logic | 33321 | 0 | 53200 | 62.63 |
|   LUT as Memory|  9195 | 0 | 17400 | 52.84 |
| LUT as Distributed RAM |  3990 | 0 |   |   |
| LUT as Shift Register  |  5205 | 0 |   |   |
| Slice Registers| 68993 |12 |106400 | 64.84 |
|   Register as Flip Flop| 68993 |12 |106400 | 64.84 |
|   Register as Latch| 0 | 0 |106400 |  0.00 |
| F7 Muxes   |  1407 | 0 | 26600 |  5.29 |
| F8 Muxes   |   254 | 0 | 13300 |  1.91 |
++---+---+---+---+
+---+--+---+---+---+
| Site Type | Used | Fixed | Available | Util% |
+---+--+---+---+---+
| Block RAM Tile|  121 | 0 |   140 | 86.43 |
|   RAMB36/FIFO*|  108 | 0 |   140 | 77.14 |
| RAMB36E1 only |  108 |   |   |   |
|   RAMB18  |   26 | 0 |   280 |  9.29 |
| RAMB18E1 only |   26 |   |   |   |
+---+--+---+---+---+
++--+---+---+---+
|Site Type   | Used | Fixed | Available | Util% |
++--+---+---+---+
| DSPs   |  142 | 0 |   220 | 64.55 |
|   DSP48E1 only |  142 |   |   |   |
++--+---+---+---+

I'll try a build next with less "stuff" in the rfnoc_ce_auto_inst.v -- but
is this currently expected behavior?

Appreciate the help, thanks!
EJ
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] USRP: AD9361

[EJ Kreinar via USRP-users]

Hi,

I'll admit, I do not know how to answer these specific questions because
they're pretty far outside the typical use case of the b200 device.
However, Nick Foster and others have already responded to similar questions
about your application. Please explain your results when you followed their
advice. In summary:

1. Do not edit the fpga for b200. Use off-the-shelf UHD software to
generate a chirp.

2. Read the user manual that describes how to use the b200.

There's many people here who could help you generate and transmit a chirp
in software without modifying the fpga. Editing the fpga to do the same
task is probably not necessary with the B200. If you believe fpga edits are
required, please explain why the provided UHD interface is not sufficient
for your application.

Thanks,
EJ

On Wed, Apr 18, 2018, 11:24 PM Yeo Jin Kuang Alvin (IA) via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi all,
>
>
>
> I need to control the AD9361 in the USRP board and I have the
> AD93611_ctrl.cpp code.
>
>
>
> The question is if I can just build the ad9361_ctrl.cpp and run the .exe
> file to control it in the board (Not sure if it will send to the AD9361 in
> the board) or must I build a certain top  file that is higher ‘hierarchy’
> and then edit the ad9361_ctrl.cpp file, build the top file . So that the
> board can reads it and if this is so, may I know which file to build so
> that it also consist of the ad9361.cpp files.
>
>
>
> Thank you in advance!
> ___
> 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] About RFNoC development

[EJ Kreinar via USRP-users]

Hi Leo!

Just a few things to add:

> *  I see the rfnoc-devel branch on the Github repository hasn't been
updated in the last 6 months, and grepping code I've seen you've included
"RFNoC stuff" in the maint branch, which is the one I'm currently using.
The thing is I don't see the Python scripts to create RFNoC OOT modules
anymore.

Funny enough, I believe rfnoc-devel branches of uhd and fpga repos were
updated earlier this week. Vivado version is bumped to 2017.4 and there's
many changes/bug fixes. I'm not totally clear on the differences between
branches myself, but I understand the rfnoc-devel branches are the only
ones that fully provide the "rfnoc api" that allows users to write/plug in
other rfnoc blocks-- which is why you won't see the python scripts there.

> is it possible to address directly a certain Crossbar port from the API
and send / receive samples from that RFNoC block to the host and back
without changing anything within the UHD? (even if the block is not
properly "recognized")

I would suggest trying to get your block recognized by UHD. The UHD
software uses a factory generator to enumerate all blocks on a particular
FPGA image, and it also provides a number of other helpful tasks like
exposing set/get registers and associating any required C++ software with
the fpga block.

Another thing to keep in mind: if you want to use the gr-ettus plugins to
design flowgraphs in gnuradio-companion, I believe you need *two* blocks in
order to send data from Processor -> FPGA -> Processor, but this can be
easily resolved by adding a FIFO before or after your block under test.

Hope this helps,
EJ

On Thu, Apr 5, 2018, 4:41 PM Brian Padalino via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hey Leo,
>
> On Thu, Apr 5, 2018 at 3:01 PM, Leandro Echevarría via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hey everybody,
>>
>> I've begun working on an X310 board, and I need to make modifications to
>> the Verilog code to include my own code. My strength is on HDL design, but
>> I lack experience on the software part. I've got some questions (in order
>> from most urgent to more annecdotical) I'd very much appreciate you'd help
>> me with:
>>
>> *  I see the rfnoc-devel branch on the Github repository hasn't been
>> updated in the last 6 months, and grepping code I've seen you've included
>> "RFNoC stuff" in the maint branch, which is the one I'm currently using.
>> The thing is I don't see the Python scripts to create RFNoC OOT modules
>> anymore. I've got no worries as to how to integrate my modules inside the
>> Verilog (I saw those scripts were somehow about automating instantiation
>> code), but I'm a little lost as to WHAT part of the UHD API should I modify
>> and recompile in order for a custom RFNoC module to be recognized by the
>> host computer and be able to communicate with it. The guides and
>> application notes about this also seem to be a little outdated. Any hint?
>>
>
> This repository was the most help to me:
>
>   https://github.com/ejk43/rfnoc-ootexample
>
> You run everything out of tree, and I think it helps understand the
> separation of where code lives.
>
> The thing to note is that, for UHD, you need to have at least an XML file
> in the rfnoc/blocks directory that defines the input/output ports and the
> block ID.  This is enough to tell UHD about your block, but not much else
> like registers.  You can implement your own class for controlling your
> block all out of tree as well.
>
>
>> * Is the AXI Crossbar configured in any way from the host? Or is there
>> just a mapping between the crossbar ports / modules ID and the blocks the
>> host understands should be inside the FPGA? Where is the "signal path"
>> (i.e.: DBA-RX2 -> DDC0 --> FFT --> host) defined? Understand I've been
>> studying the design "upwards", reading first a lot of Verilog code, and I'm
>> beginning to explore the API itself.
>> * Following the last question: is it possible to address directly a
>> certain Crossbar port from the API and send / receive samples from that
>> RFNoC block to the host and back without changing anything within the UHD?
>> (even if the block is not properly "recognized")
>>
>
> The CHDR has a source and destination that's programmed into the header
> and that programs the block itself.  This is how each block is addressed
> and moves data.
>
> Something to also note is there is a limit to the number of RFNoC blocks
> you can have in the design without making major modifications - I believe
> it's 10 or 11, so don't make every small thing it's own block.  You should
> definitely consolidate into things that make sense.
>
> Good luck!
>
> Brian
> ___
> 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

Re: [USRP-users] Assigning and output to rfnoc block and grc integration

[EJ Kreinar via USRP-users]

Hi Steve,

First, lets look at the code. I'm not convinced this is doing what you
think it is doing. See inline comments

// Assuming i_out is 16 bits wide, i_out will *always* equal the I value
from pipe_in_tdata
assign   i_out  =   pipe_in_tdada [31:16];
// q_out will equal 16'h0001 when the Q value from pipe_in_tdata is > thresh
// q_out will equal 16'h when the Q value from pipe_in_tdata is < thresh
assign   q_out =  (pipe_in_tdada[15:0] > thresh) ? 1 :
0;
// Now assign thresh_out to the concatenation of i_out and q_out
wire [31:0] thresh_out =  {i_out [15:0], q_out [15:0]};

So I would expect the I-component of thresh_out to always be equal to the
input, while the Q-component is either 0 or 1, which is not really a
"threshold" operation. Is this what you had in mind?

Regarding your questions:

> The testbench duplicates the bits I assign to the output, so instead of a
"0...01" (32 bits) I get a "0..010...01" (64 bits). I've tried various
numbers, and always get the 32 bits duplicated to a completely different
output. does this have anything to do with the AXI wrapper? How am I
supposed to assign values to the output of a block?

There's two ways to interact with the rfnoc testbench:

A. `tb_streamer.recv(recv_payload, metadata)`
  - Here, each word in the recv_payload is 64 bits long, which
represents two concatenated samples of 32 bits. The RFNoC crossbar handles
data as 64-bit words, so I'm assuming this is closer to the natural
representation of the RFNoC data
  - Examples: noc_block_digital_gain_tb.sv, noc_block_addsub_tb.sv,
noc_block_duc_tb.sv, among others

B. `tb_streamer.pull_word({real_val, imag_val}, last)`
 - Here, the pull_word command returns a 32-bit sample,  which has
16-bits I and 16-bits Q as expected. I find this approach is generally a
bit easier to tackle.
 - Examples: noc_block_fir_filter_tb.sv, noc_block_fft_tb.sv, among
others

You might want to try approach B.


> In some awkward permutation of the above code, the problem didn't occur.
when implementing in the grc, the block didn't really do anything - inputs
continued as they are to the output. How is this possible? Doesn't my
design strictly allow only ones and zero's to pass?

I agree this is strange, but probably needs more context to debug.


> General understanding of rfnoc integration in the grc: If I were to
connect a constant source to a standard sink, I would be able to assign any
amplitude of my choice - 8,5,17. But when I put a Rfnoc block in the flow
(e.g. the gain from the tutorial), then the sink receives values within
[-1,1] only. why does this happen and what does it mean?

RFNoC, and most FPGA DSP implementations in general, requires a fixed-point
data type. The fixed point format for RFNoC has been chosen as 1-integer
bit + 15 fractional bits (Q format: Q1.15 -- see
https://en.wikipedia.org/wiki/Q_(number_format) ), so you can represent
data between -1 and +1. Any values outside this range will be coerced and
become either -1 or +1 when moving data from software to the FPGA.


Hope this helps,
EJ


On Tue, Mar 27, 2018 at 4:07 AM, shachar J. brown via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi all,
>
> I'm trying to write a very simple block via Rfnocmodtool, and I'm
> confronting various problems. I believe I've missed some core concepts of
> the whole rfnoc structure and would like to settle things straight.
>
> Following the "gain" example from the tutorial, I tried writing a simple
> threshold block. I created input and output fifo's, similar to those in the
> tutorial, and between them added the following code:
>
> assign   i_out  =   pipe_in_tdada [31:16];
> assign   q_out =  (pipe_in_tdada[15:0] > thresh) ? 1
> : 0;
> wire [31:0] thresh_out =  {i_out [15:0], q_out [15:0]};
>
> Quite simple, ain't it? I receive the following problems:
>
>
>1. The testbench duplicates the bits I assign to the output, so
>instead of a "0...01" (32 bits) I get a "0..010...01" (64 bits). I've tried
>various numbers, and always get the 32 bits duplicated to a completely
>different output. does this have anything to do with the AXI wrapper? How
>am I supposed to assign values to the output of a block?
>2. In some awkward permutation of the above code, the problem didn't
>occur. when implementing in the grc, the block didn't really do anything -
>inputs continued as they are to the output. How is this possible? Doesn't
>my design strictly allow only ones and zero's to pass?
>3. General understanding of rfnoc integration in the grc: If I were to
>connect a constant source to a standard sink, I would be able to assign any
>amplitude of my choice - 8,5,17. But when I put a Rfnoc block in the flow
>(e.g. the gain from the tutorial), then the sink receives values within
>[-1,1] only. why does this happen and what does it mean?
>
> Thank you so much 

Re: [USRP-users] RFNOC [ERROR] [UHD] Exception caught in safe-call while running uhd_usrp_probe

[EJ Kreinar via USRP-users]

Hi Kailash,

As far as I'm aware, this remains a known problem with the E310s. See a
mailing-list thread here for the status as of January of 2018:
https://www.mail-archive.com/usrp-users@lists.ettus.com/msg03926.html

There's also reports of this problem going back to April-ish 2017. Since
uhd/rfnoc-devel is still tracking an October 2017 commit, you are likely
seeing a similar issue. I've heard mention that it's not a "blocking"
problem, that is, it should not impact nominal operation of E310 programs;
just the shutdown sequence.

Hope this helps,
EJ

On Fri, Mar 23, 2018 at 5:42 AM, kailash kumar via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi,
>
> I've successfully installed  RFNoC for e312.
>
> but after running  uhd_usrp_probe I am getting an error -  [ERROR] [UHD]
> Exception caught in safe-call.
>
> the same Exception is coming when I run the UHD example
> ./rx_samples_to_file
>
> I am using
>
> UHD: UHD_4.0.0.rfnoc-devel-409-gec9138eb
>
> GNURADIO: 3.7.12git-361-g713629cc
>
> GR_ETTUS: branch master/
>
>
>
>
> root@ettus-e3xx-sg3:~# uhd_usrp_probe
> [INFO] [UHDlinux; GNU C++ version 5.2.0; Boost_105800;
> UHD_4.0.0.rfnoc-devel-409-gec9138eb]
> [INFO] [E300] Loading FPGA image: /usr/share/uhd/images/usrp_e31
> 0_fpga_sg3.bit...
> [INFO] [E300] FPGA image loaded
> [INFO] [E300] Initializing core control (global registers)...
>
> [INFO] [E300] Performing register loopback test...
> [INFO] [E300] Register loopback test passed
> [INFO] [RFNOC RADIO] Register loopback test passed
> [INFO] [RFNOC RADIO] Register loopback test passed
> [WARNING] [RFNOC] [0/fosphor_0] defines 2 input buffer sizes, but 1 input
> ports
> [INFO] [AD936X] Performing CODEC loopback test...
> [INFO] [AD936X] CODEC loopback test passed
> [INFO] [AD936X] Performing CODEC loopback test...
> [INFO] [AD936X] CODEC loopback test passed
> [INFO] [CORES] Performing timer loopback test...
> [INFO] [CORES] Timer loopback test passed
>   _
>  /
> |   Device: E-Series Device
> | _
> |/
> |   |   Mboard: E3XX
> |   |   product: 30675
> |   |   revision: 6
> |   |   serial: 312EE16
> |   |   mac-addr: 00:80:2f:17:d1:46
> |   |   FPGA Version: 255.0
> |   |   FPGA git hash: f764326-dirty
> |   |   RFNoC capable: Yes
> |   |
> |   |   Time sources:  none, internal, external
> |   |   Clock sources: internal
> |   |   Sensors: temp, ref_locked
> |   | _
> |   |/
> |   |   |   RX DSP: 0
> |   |   |
> |   |   |   Freq range: 0.000 to 0.000 MHz
> |   | _
> |   |/
> |   |   |   RX DSP: 1
> |   |   |
> |   |   |   Freq range: 0.000 to 0.000 MHz
> |   | _
> |   |/
> |   |   |   RX Dboard: A
> |   |   |   ID: E310 MIMO XCVR (0x0110)
> |   |   |   Serial: 312CB16
> |   |   | _
> |   |   |/
> |   |   |   |   RX Frontend: A
> |   |   |   |   Name: FE-RX2
> |   |   |   |   Antennas: TX/RX, RX2
> |   |   |   |   Sensors: temp, rssi, lo_locked
> |   |   |   |   Freq range: 50.000 to 6000.000 MHz
> |   |   |   |   Gain range PGA: 0.0 to 76.0 step 1.0 dB
> |   |   |   |   Bandwidth range: 20.0 to 5600.0 step 0.0 Hz
> |   |   |   |   Connection Type: IQ
> |   |   |   |   Uses LO offset: No
> |   |   | _
> |   |   |/
> |   |   |   |   RX Frontend: B
> |   |   |   |   Name: FE-RX1
> |   |   |   |   Antennas: TX/RX, RX2
> |   |   |   |   Sensors: temp, rssi, lo_locked
> |   |   |   |   Freq range: 50.000 to 6000.000 MHz
> |   |   |   |   Gain range PGA: 0.0 to 76.0 step 1.0 dB
> |   |   |   |   Bandwidth range: 20.0 to 5600.0 step 0.0 Hz
> |   |   |   |   Connection Type: IQ
> |   |   |   |   Uses LO offset: No
> |   |   | _
> |   |   |/
> |   |   |   |   RX Codec: A
> |   |   |   |   Name: E3x0 RX dual ADC
> |   |   |   |   Gain Elements: None
> |   | _
> |   |/
> |   |   |   TX DSP: 0
> |   |   |
> |   |   |   Freq range: 0.000 to 0.000 MHz
> |   | _
> |   |/
> |   |   |   TX DSP: 1
> |   |   |
> |   |   |   Freq range: 0.000 to 0.000 MHz
> |   | _
> |   |/
> |   |   |   TX Dboard: A
> |   |   |   ID: E310 MIMO XCVR (0x0110)
> |   |   |   Serial: 312CB16
> |   |   | _
> |   |   |/
> |   |   |   |   TX Frontend: A
> |   |   |   |   Name: FE-TX2
> |   |   |   |   Antennas: TX/RX
> |   |   |   |   Sensors: temp, lo_locked
> |   |   |   |   Freq range: 50.000 to 6000.000 MHz
> |   |   |   |   

Re: [USRP-users] RFNoC spp rate limitation

[EJ Kreinar via USRP-users]

Hi Sebastian,

> Do you think that it would suffice to change the packet size at my last
RFNoC block before the host? I will try out the already available
packet_resizer block tomorrow.

Yes, this is probably the easiest solution. But, if you're not opposed to
custom HDL, an alternate option could be to create a modified FFT block
that simply outputs an integer number of FFTs within a single packet.

> So the question would be if RFNoC can handle passing packets with spp=64
at 200 MSps between RFNoC blocks

That's a good question... RFNoC blocks all share a crossbar, which runs at
a particular bus_clk rate, so there is a max throughput that the bus can
handle... Each sample on the crossbar is 8 bytes, so you get a total
throughput of bus_clk*8 bytes/second. There's also a header overhead of 16
bytes per packet (or 8 bytes if there's no timestamp).

I'm actually not sure what the current X310 bus_clk rate is set to... I
just noticed a recent commit that supposedly changes bus_clk to 187.5 MHz (
https://github.com/EttusResearch/fpga/commit/d08203f60d3460
a170ad8b3550b478113b7c5968). So I'm not exactly clear what the bus_clk was
set to before that, or on the rfnoc-devel branch...

But unless I'm misunderstanding, having multiple RFNoC blocks running at a
full 200 Msps might saturate the bus? Is that correct?

EJ

On Thu, Mar 22, 2018 at 3:33 PM, Sebastian Leutner via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi all,
>
> when working with RFNoC at 200 MSps on the X310 using 10GbE I
> experience overruns when using less than 512 samples per packet (spp).
> A simple flow graph [RFNoC Radio] -> [RFNoC FIFO] -> [Null sink] with
> the spp stream arg set at the RFNoC Radio block shows the following
> network utilization:
>
> spp | throughput [Gbps]
> 
> 1024 | 6.49
> 512 | 6.58
> 256 | 3.60
>  64 | 0.70
>
> Although I understand that the total load will increase a little bit
> for smaller packets due to increased overhead (headers) as seen from
> spp=1024 to spp=512, I find it confusing that so many packets are
> dropped for spp <= 256.
>
> Total goodput should be 200 MSps * 4 byte per sample (sc16) = 800 MBps
> = 6.40 Gbps.
>
> Is RFNoC somehow limited to a certain number of packets per second
> (regardless of their size)?
> Could this be resolved by increasing the STR_SINK_FIFOSIZE noc_shell
> parameter of any blocks connected to the RFNoC Radio?
>
> I would like to use spp=64 because that is the size of the RFNoC FFT I
> want to use. I am using UHD 4.0.0.rfnoc-devel-409-gec9138eb.
>
> Any help or ideas appreciated!
>
> Best,
> Sebastian
>
> This is almost certainly an interrupt-rate issue having to do with your
 ethernet controller, and nothing to do with RFNoC, per se.

 If you're on Linux, try:

 ethtool --coalesce   adaptive-rx on
 ethtool --coalesce  adaptive-tx on

>>>
>>> Thanks Marcus for your quick response. Unfortunately, that did not help.
>>> Also, `ethtool -c enp1s0f0` still reports "Adaptive RX: off TX: off"
>>> afterwards. I also tried changing `rx-usecs` which reported correctly but
>>> did not help either. I am using Intel 82599ES 10-Gigabit SFI/SFP+
>>> controller with the driver ixgbe (version: 5.1.0-k) on Ubuntu 16.04.
>>>
>>> Do you know anything else I could try?
>>>
>>> Thanks,
>>> Sebastian
>>>
>> The basic problem is that in order to achieve good performance at
>> very-high sample-rates, jumbo-frames are required, and using a very small
>> SPP implies
>>very small frames, which necessarily leads to poor ethernet
>> performance.
>>
>> Do you actually need the FFT results to appear at the host at "real-time"
>> rates, or can you do an integrate-and-dump within RFNoC, to reduce host side
>>traffic?
>>
>
> Yes, I need all the samples. Since it will be a full receiver
> implementation in RFNoC the output to the host will be much less than 6.40
> Gbps but still a decent amount and definitely more than the 0.7 Gbps I was
> able to achieve with spp=64.
>
> Do you think that it would suffice to change the packet size at my last
> RFNoC block before the host? I will try out the already available
> packet_resizer block tomorrow.
>
> So the question would be if RFNoC can handle passing packets with spp=64
> at 200 MSps between RFNoC blocks. If this is likely to be a problem, I
> could try wrapping all my HDL code into one RFNoC block and handle the
> packet resizing at input and output of this block. However, I would like to
> avoid this step if possible.
>
> Thanks for your help!
>
>
> ___
> 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

Re: [USRP-users] RFNoC block timeouts

[EJ Kreinar via USRP-users]

Hi Sebastian,

> Does RFNoC assume that a block always has to output samples within a
certain time limit? Can someone explain to me, where the timeout is checked
and raised?

You can find the "timeout on chan 0" message implemented in
gr-ettus/lib/rfnoc_block_impl.cc. As you suspected (correctly), it is a
harmless output that can be ignored if no data is actually coming from your
RFNoC block. It is driven by receiving a timeout from the streamer->recv()
function -- it looks like the timeout defaults to 0.1 seconds.


I'm not familiar with the second error, however :) Sorry!

EJ


On Thu, Mar 15, 2018 at 1:55 PM, Sebastian Leutner via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi all,
>
> I have a custom RFNoC block which detects data packets in a stream of
> I/Q-samples coming from a file source or the RFNoC Radio block. It only
> outputs samples if it detects a packet, otherwise it does not output
> anything. This works fine in simulation but when using the synthesized
> block, I get "timeout on chan 0" messages as soon as there is nothing
> detected and thus no output from my block. I suppose this principle is
> relevant for any radio receiver implementation in RFNoC. I am using the
> X310 with UHD 4.0.0.rfnoc-devel-409-gec9138eb.
>
> I have problems figuring out how this timeout is implemented exactly. Does
> RFNoC assume that a block always has to output samples within a certain
> time limit? Can someone explain to me, where the timeout is checked and
> raised? Is the ZPU responsible for this?
>
> Just ignoring the timeout messages works up to a certain point where I get
> the following error messages. Valid data samples are not processed any
> more after this happens.
>   [ERROR] [X300] x300 fw communication failure #1 EnvironmentError:
> IOError: x300 fw poke32 - reply timed out
>   [ERROR] [X300] x300 fw communication failure #2 EnvironmentError:
> IOError: x300 fw poke32 - reply timed out
>   [ERROR] [X300] x300 fw communication failure #3 EnvironmentError:
> IOError: x300 fw poke32 - reply timed out
>   [ERROR] [UHD] An unexpected exception was caught in a task loop.The
> task loop will now exit, things may not work. x300 fw communication failure
> #3 EnvironmentError: IOError: x300 fw poke32 - reply timed out
>
> Any help or ideas appreciated!
>
> Best regards,
> Sebastian
>
>
> ___
> 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] How to change RFNoC pkt_size in port_def?

[EJ Kreinar via USRP-users]

ally help here unless I'm
>>> misunderstanding something. You need to send shorter packets, yes, but
>>> changing the stream sink FIFO size won't change that. The FIFO doesn't have
>>> to be full before it passes your packet along. That said, I don't think
>>> I've had to specify packet size on packets from the PS on E310 before, so
>>> I'm no help figuring that out. On X310 you can just set your MTU, and for
>>> RX applications you can pass "spp=" to the RX radio block. But I
>>> haven't had to do it on E310 before.
>>>
>>> But on another note, because whole packets are buffered before
>>> processing by each block, your first instinct was good -- consolidating
>>> your blocks will help more than just about anything else to reduce latency.
>>>
>>> On E310, there's another approach that can help as well: force the CE
>>> clock to run at full rate. By default, E310 runs the compute engine clock
>>> at the minimum required rate to process samples -- i.e., the radio clock
>>> rate. But you can force the compute engines to run at the full bus rate
>>> (64MHz) by changing rfnoc_ce_auto_inst.v so that instead of:
>>>
>>> wire ce_clk = radio_clk;
>>> wire ce_rst = radio_rst;
>>>
>>> ...it says:
>>>
>>> wire ce_clk = bus_clk;
>>> wire ce_rst = bus_rst;
>>>
>>> You'll consume more power, but you'll reduce latency some. It's also a
>>> helpful trick to be able to run 1-input-N-output blocks in loopback, at
>>> least up to something less than half the bus_clk rate.
>>>
>>> Nick
>>>
>>> On Thu, Mar 1, 2018 at 12:48 PM EJ Kreinar via USRP-users <
>>> usrp-users@lists.ettus.com> wrote:
>>>
>>>> Hi All,
>>>>
>>>> I have an RFNoC setup with 5+ blocks contributing to a transmit path.
>>>> I've measured the latency to get a signal through this RFNoC graph is
>>>> non-negligible at my bit-rate -- I'm seeing several 10s of ms.
>>>>
>>>> Before I go crazy consolidating RFNoC blocks, I decided to try
>>>> shrinking the STR_SINK_FIFOSIZE from 2^11 down to 2^9. I have a known MTU
>>>> packet limit that's something like 1024 *bytes*, which should be manageble
>>>> with a 2^9 FIFO size. This could potentially reduce the latency due to
>>>> input FIFOs by 4x, which might be a good start. But, I hit a few problems
>>>> here...
>>>>
>>>> When setting the STR_SINK_FIFOSIZE to 9, I get the following error:
>>>>
>>>> -- Assuming max packet size for 0/he360encoder_0
>>>> Traceback (most recent call last):
>>>>   File "./e310_ground_modem.py", line 330, in 
>>>> main()
>>>>   File "./e310_ground_modem.py", line 319, in main
>>>> tb = top_block_cls(bitstream=options.bitstream,
>>>> clk_rate=options.clk_rate, conv=options.conv, device=options.device,
>>>> freq=options.freq, hdlc_enable=options.hdlc_enable,
>>>> lo_offset=options.lo_offset, probeconsole=options.probeconsole,
>>>> probecsv=options.probecsv, rate=options.rate, rs_enable=options.rs_enable,
>>>> rxaddr=options.rxaddr, tx_gain=options.tx_gain)
>>>>   File "./e310_ground_modem.py", line 169, in __init__
>>>> self.device3.connect(self.fpgacomms_he360encoder_0.get_block_id(),
>>>> 0, self.hawkeye_qpsk_modulator_0.get_block_id(), 0)
>>>>   File "/deploy/dev-ejk/lib/python2.7/site-packages/ettus/ettus_swig.py",
>>>> line 1595, in connect
>>>> return _ettus_swig.device3_sptr_connect(self, *args)
>>>> RuntimeError: RuntimeError: Input FIFO for block 0/qpskmodulator_0 is
>>>> too small (4 kiB) for packets of size 7 kiB
>>>> coming from block 0/he360encoder_0.
>>>>
>>>>
>>>> When setting the STR_SINK_FIFOSIZE to 10, I get a different error:
>>>>
>>>> -- [0/he360encoder_0] source_block_ctrl_base::configure_flow_control_out()
>>>> buf_size_pkts==1
>>>> Traceback (most recent call last):
>>>>   File "./e310_ground_modem.py", line 330, in 
>>>> main()
>>>>   File "./e310_ground_modem.py", line 319, in main
>>>> tb = top_block_cls(bitstream=options.bitstream,
>>>> clk_rate=options.clk_rate, conv=options.conv, device=options.device,
>>>> freq=options.freq, hdlc_enable=options.hdlc_enable,
>>>> lo_offset=options.

Re: [USRP-users] How to change RFNoC pkt_size in port_def?

[EJ Kreinar via USRP-users]

Hey Nick,

I realize I've forgotten a key piece of information: My first block in the
RFNoC transmit chain accepts bursty data packets from the host, and encodes
the data using HDLC formatting, including inserting fill frames -- the goal
here is to generate a continuous transmit output without fully saturating
the PS->PL transport, keeping the PS load down, etc. FPGA fill-frame
creation is throttled via axi-stream backpressure from the radio endpoint,
which means the HDLC fill-frames will fill up all FIFO buffers of
downstream blocks. So, the latency of a single data packet to travel in the
FPGA from the PS to Radio output is largely driven by the size of the FIFOs
in the RFNoC path, and the output sample rate of the radio.

I agree consolidation is the "right" answer for best performance. But, I'm
trying to use a few off-the-shelf RFNoC blocks to reduce development time,
so if possible I'd prefer to tweak the exposed parameters rather than go
through the full process for a new FPGA block and software interface.

The STR_SINK_FIFOSIZE looks like a parameter that ought to be user
configurable -- but the limitation (from what I can tell) is that there
doesnt appear to be an easy way to change the pkt_size parameter on the
block port to stop the graph_impl.cc from erroring

> On X310 you can just set your MTU, and for RX applications you can pass
"spp=" to the RX radio block. But I haven't had to do it on E310 before

On the E310 (as on the X310), the spp parameter does influence packet size,
but the relevant port_def "pkt_size" parameter seems to be a different
beast which is not updated to reflect the estimated spp from the
stream_args.. Perhaps it should?

Thanks!
EJ





On Thu, Mar 1, 2018 at 4:44 PM, Nick Foster <bistrom...@gmail.com> wrote:

> EJ,
>
> Reducing the stream sink FIFO size won't really help here unless I'm
> misunderstanding something. You need to send shorter packets, yes, but
> changing the stream sink FIFO size won't change that. The FIFO doesn't have
> to be full before it passes your packet along. That said, I don't think
> I've had to specify packet size on packets from the PS on E310 before, so
> I'm no help figuring that out. On X310 you can just set your MTU, and for
> RX applications you can pass "spp=" to the RX radio block. But I
> haven't had to do it on E310 before.
>
> But on another note, because whole packets are buffered before processing
> by each block, your first instinct was good -- consolidating your blocks
> will help more than just about anything else to reduce latency.
>
> On E310, there's another approach that can help as well: force the CE
> clock to run at full rate. By default, E310 runs the compute engine clock
> at the minimum required rate to process samples -- i.e., the radio clock
> rate. But you can force the compute engines to run at the full bus rate
> (64MHz) by changing rfnoc_ce_auto_inst.v so that instead of:
>
> wire ce_clk = radio_clk;
> wire ce_rst = radio_rst;
>
> ...it says:
>
> wire ce_clk = bus_clk;
> wire ce_rst = bus_rst;
>
> You'll consume more power, but you'll reduce latency some. It's also a
> helpful trick to be able to run 1-input-N-output blocks in loopback, at
> least up to something less than half the bus_clk rate.
>
> Nick
>
> On Thu, Mar 1, 2018 at 12:48 PM EJ Kreinar via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hi All,
>>
>> I have an RFNoC setup with 5+ blocks contributing to a transmit path.
>> I've measured the latency to get a signal through this RFNoC graph is
>> non-negligible at my bit-rate -- I'm seeing several 10s of ms.
>>
>> Before I go crazy consolidating RFNoC blocks, I decided to try shrinking
>> the STR_SINK_FIFOSIZE from 2^11 down to 2^9. I have a known MTU packet
>> limit that's something like 1024 *bytes*, which should be manageble with a
>> 2^9 FIFO size. This could potentially reduce the latency due to input FIFOs
>> by 4x, which might be a good start. But, I hit a few problems here...
>>
>> When setting the STR_SINK_FIFOSIZE to 9, I get the following error:
>>
>> -- Assuming max packet size for 0/he360encoder_0
>> Traceback (most recent call last):
>>   File "./e310_ground_modem.py", line 330, in 
>> main()
>>   File "./e310_ground_modem.py", line 319, in main
>> tb = top_block_cls(bitstream=options.bitstream,
>> clk_rate=options.clk_rate, conv=options.conv, device=options.device,
>> freq=options.freq, hdlc_enable=options.hdlc_enable,
>> lo_offset=options.lo_offset, probeconsole=options.probeconsole,
>> probecsv=options.probecsv, rate=options.rate, rs_enable=options.rs_enable,
>> rxaddr=options.rxaddr, tx_gain=options.tx_gain)
>&

[USRP-users] How to change RFNoC pkt_size in port_def?

[EJ Kreinar via USRP-users]

Hi All,

I have an RFNoC setup with 5+ blocks contributing to a transmit path. I've
measured the latency to get a signal through this RFNoC graph is
non-negligible at my bit-rate -- I'm seeing several 10s of ms.

Before I go crazy consolidating RFNoC blocks, I decided to try shrinking
the STR_SINK_FIFOSIZE from 2^11 down to 2^9. I have a known MTU packet
limit that's something like 1024 *bytes*, which should be manageble with a
2^9 FIFO size. This could potentially reduce the latency due to input FIFOs
by 4x, which might be a good start. But, I hit a few problems here...

When setting the STR_SINK_FIFOSIZE to 9, I get the following error:

-- Assuming max packet size for 0/he360encoder_0
Traceback (most recent call last):
  File "./e310_ground_modem.py", line 330, in 
main()
  File "./e310_ground_modem.py", line 319, in main
tb = top_block_cls(bitstream=options.bitstream,
clk_rate=options.clk_rate, conv=options.conv, device=options.device,
freq=options.freq, hdlc_enable=options.hdlc_enable,
lo_offset=options.lo_offset, probeconsole=options.probeconsole,
probecsv=options.probecsv, rate=options.rate, rs_enable=options.rs_enable,
rxaddr=options.rxaddr, tx_gain=options.tx_gain)
  File "./e310_ground_modem.py", line 169, in __init__
self.device3.connect(self.fpgacomms_he360encoder_0.get_block_id(), 0,
self.hawkeye_qpsk_modulator_0.get_block_id(), 0)
  File "/deploy/dev-ejk/lib/python2.7/site-packages/ettus/ettus_swig.py",
line 1595, in connect
return _ettus_swig.device3_sptr_connect(self, *args)
RuntimeError: RuntimeError: Input FIFO for block 0/qpskmodulator_0 is too
small (4 kiB) for packets of size 7 kiB
coming from block 0/he360encoder_0.


When setting the STR_SINK_FIFOSIZE to 10, I get a different error:

-- [0/he360encoder_0] source_block_ctrl_base::configure_flow_control_out()
buf_size_pkts==1
Traceback (most recent call last):
  File "./e310_ground_modem.py", line 330, in 
main()
  File "./e310_ground_modem.py", line 319, in main
tb = top_block_cls(bitstream=options.bitstream,
clk_rate=options.clk_rate, conv=options.conv, device=options.device,
freq=options.freq, hdlc_enable=options.hdlc_enable,
lo_offset=options.lo_offset, probeconsole=options.probeconsole,
probecsv=options.probecsv, rate=options.rate, rs_enable=options.rs_enable,
rxaddr=options.rxaddr, tx_gain=options.tx_gain)
  File "./e310_ground_modem.py", line 169, in __init__
self.device3.connect(self.fpgacomms_he360encoder_0.get_block_id(), 0,
self.hawkeye_qpsk_modulator_0.get_block_id(), 0)
  File "/deploy/dev-ejk/lib/python2.7/site-packages/ettus/ettus_swig.py",
line 1595, in connect
return _ettus_swig.device3_sptr_connect(self, *args)
RuntimeError: RuntimeError: Invalid window size 1 for block
0/he360encoder_0. Window size must at least be 2.


Both errors trace back to uhd/host/lib/rfnoc/graph_impl.cc, where it
appears that the graph is attempting to read the FIFO size, compare to the
expected packet size, and intelligently throw errors when there's a
potential issue. I appreciate this feature, but I cant find how to set the
pkt_size argument... Passing a pkt_size stream_arg into the rfnoc block
constructor does not change the port_def to have a different pkt_size.

Any ideas? What am I missing? Do I manually need to access the tree to edit
the port_def parameter at "_root_path/ports/direction/port_index" for my
block?

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

Re: [USRP-users] RFNoC FPGA OOT Xilinx IP Addition

[EJ Kreinar via USRP-users]

Sure, glad to help!

Most of magic variables come from the Makefile workflow in uhd-fpga
(suggest doing some greps in both uhd-fpga/usrp3/tools/make and
uhd-fpga/usrp3/top).

The OOT_DIR is a magic variable that's passed to the OOT directory, and it
lets the Makefiles resolve relative pathing issues. The
uhd_image_builder.py tools should wrap this correctly when generating FPGA
images. It's not exactly the cleanest interface, since it requires a ":="
operation in the OOT Makefile. I'm definitely open to other suggestions,
but it's worked well for me so far.

Hope to see your OOT FPGA blocks :D
EJ

On Tue, Feb 27, 2018 at 2:23 PM, Brian Padalino  wrote:

> Hey EJ,
>
> On Tue, Feb 27, 2018 at 6:27 AM, EJ Kreinar  wrote:
>
>> Hi Brian,
>>
>> There's a supported method to include OOT repos that can build and
>> include xilinx IP (or basically any other IP that you need, including HLS.
>> I've yet to try it with sysgen blocks, but that would probably work too).
>> Basically you can use uhd_image_builder.py or uhd_image_builder_gui.py to
>> include a Makefile.inc from an OOT repo, rather than copying the text from
>> the Makefile.srcs.
>>
>> See my repo here for a minimal basic example: https://github.com/ej
>> k43/rfnoc-ootexample
>>
>> There's also an open source FPGA polyphase channelizer OOT module that
>> uses this approach: https://github.com/e33b1711/rfnoc-ppchan
>>
>> Good luck! Let me know if this helps
>>
>
> This is exactly what I was looking for.  Now, is there anything that
> defines these magic variables used in the Makefile.inc?  Things like
> OOT_DIR, LIB_IP_XCI_SRCS, TOOLS_DIR, etc?  There's a lot of magic going
> on in those Makefiles and the environment in general it seems.
>
> For now, though, this looks like it will work perfectly.
>
> Thanks,
> 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 FPGA OOT Xilinx IP Addition

[EJ Kreinar via USRP-users]

Hi Brian,

There's a supported method to include OOT repos that can build and include
xilinx IP (or basically any other IP that you need, including HLS. I've yet
to try it with sysgen blocks, but that would probably work too). Basically
you can use uhd_image_builder.py or uhd_image_builder_gui.py to include a
Makefile.inc from an OOT repo, rather than copying the text from the
Makefile.srcs.

See my repo here for a minimal basic example:
https://github.com/ejk43/rfnoc-ootexample

There's also an open source FPGA polyphase channelizer OOT module that uses
this approach: https://github.com/e33b1711/rfnoc-ppchan

Good luck! Let me know if this helps

Best regards,
EJ

On Feb 26, 2018 2:37 PM, "Brian Padalino via USRP-users" <
usrp-users@lists.ettus.com> wrote:

> Hi,
>
> I'm trying to add a piece of Xilinx IP using an .xci file, similar to how
> the normal flow for the FPGA build goes, but I want to keep it associated
> with my OOT source, and not change the main FPGA repository.
>
> I haven't found any instructions on how to do this, so I figure I'd ask
> here.
>
> Is it as simple as adding a .xci file to the list of sources and having it
> build?  The normal FPGA build seems to go through a lot more steps to
> generate all the IP and list their simulation and synthesis sources.
>
> Guidance is appreciated on how to do this "correctly" with an OOT module.
>
> Thanks,
> Brian
>
> ___
> 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] [RFNoC] uhd_usrp_probe fails and throws uhd::lookup_error

[EJ Kreinar via USRP-users]

Well Done!

> I edited my custom block changing one of my wires from 'delay' to
'delay_val'
> I have no idea if/why this would cause an issue, but my reasoning behind
it might be that the compiler is getting confused when mapping the timing
constraints.
> Please let me know what you think about this?

Sounds like a red herring. Unless it fails timing and tells you, I wouldnt
blame the timing constraints... that way lies madness. Neither would
changing a wire name be a likely issue.

I've personally had problems keeping track of my "rfnoc_ce_auto_inst"
files-- it's easy to edit and then re-edit and lose an old copy, which
might be the more likely culprit. If you'd like to convince yourself,
perhaps try rebuilding again with the wire named "delay" instead of
"delay_val". I'd be very surprised if it's a problem.

Cheers,
EJ

On Wed, Jan 24, 2018 at 3:29 PM, Adam Kurisko  wrote:

> Hi EJ,
>
>
> Good catch EJ. I actually caught that almost immediately after sending the
> email and corrected it right away.
>
>
> I do not think that was what was causing my initial errors, however I may
> have just figured out the issue I was having.
>
>
> I edited my custom block changing one of my wires from 'delay' to
> 'delay_val'
>
>
> I have no idea if/why this would cause an issue, but my reasoning behind
> it might be that the compiler is getting confused when mapping the timing
> constraints.
>
>
> Please let me know what you think about this?
>
>
>
> Correcting the rfnoc_ce_auto_inst.v file may have also played a role in
> this, however I am not sure why I would get that error initially with the
> file being correct.
>
>
> So, to fix it, I edited my noc block and corrected my rfnoc_ce_auto_inst.v
> file. Then ran 'make clean' and 'make E310_RFNOC'
>
>
> I am very glad I was successful. Thank you so much for your help. This was
> my final output:
>
>
> root@ettus-e3xx-sg1:~/localinstall/usr/share/uhd/images# uhd_usrp_probe
> --args="fpga=usrp_e310_fpga_RFNOC.bit"
> [INFO] [UHDlinux; GNU C++ version 4.9.2; Boost_105700;
> UHD_4.0.0.rfnoc-devel-409-gec9138eb]
> [INFO] [E300] Loading FPGA image: usrp_e310_fpga_RFNOC.bit...
> [INFO] [E300] FPGA image loaded
> [INFO] [E300] Initializing core control (global registers)...
>
> [INFO] [E300] Performing register loopback test...
> [INFO] [E300] Register loopback test passed
> [INFO] [RFNOC RADIO] Register loopback test passed
> [INFO] [RFNOC RADIO] Register loopback test passed
> [INFO] [AD936X] Performing CODEC loopback test...
> [INFO] [AD936X] CODEC loopback test passed
> [INFO] [AD936X] Performing CODEC loopback test...
> [INFO] [AD936X] CODEC loopback test passed
> [INFO] [CORES] Performing timer loopback test...
> [INFO] [CORES] Timer loopback test passed
>   _
>  /
> |   Device: E-Series Device
> | _
> |/
> |   |   Mboard: E3XX
> |   |   product: 30674
> |   |   revision: 4
> |   |   serial: 308A556
> |   |   mac-addr: 00:80:2f:21:15:a2
> |   |   FPGA Version: 255.0
> |   |   FPGA git hash: bbd81be-dirty
> |   |   RFNoC capable: Yes
> |   |
> |   |   Time sources:  none, internal, external
> |   |   Clock sources: internal
> |   |   Sensors: temp, ref_locked
> |   | _
> |   |/
> |   |   |   RX DSP: 0
> |   |   |
> |   |   |   Freq range: 0.000 to 0.000 MHz
> |   | _
> |   |/
> |   |   |   RX DSP: 1
> |   |   |
> |   |   |   Freq range: 0.000 to 0.000 MHz
> |   | _
> |   |/
> |   |   |   RX Dboard: A
> |   |   |   ID: E310 MIMO XCVR (0x0110)
> |   |   |   Serial: 308532C
> |   |   | _
> |   |   |/
> |   |   |   |   RX Frontend: A
> |   |   |   |   Name: FE-RX2
> |   |   |   |   Antennas: TX/RX, RX2
> |   |   |   |   Sensors: temp, rssi, lo_locked
> |   |   |   |   Freq range: 50.000 to 6000.000 MHz
> |   |   |   |   Gain range PGA: 0.0 to 76.0 step 1.0 dB
> |   |   |   |   Bandwidth range: 20.0 to 5600.0 step 0.0 Hz
> |   |   |   |   Connection Type: IQ
> |   |   |   |   Uses LO offset: No
> |   |   | _
> |   |   |/
> |   |   |   |   RX Frontend: B
> |   |   |   |   Name: FE-RX1
> |   |   |   |   Antennas: TX/RX, RX2
> |   |   |   |   Sensors: temp, rssi, lo_locked
> |   |   |   |   Freq range: 50.000 to 6000.000 MHz
> |   |   |   |   Gain range PGA: 0.0 to 76.0 step 1.0 dB
> |   |   |   |   Bandwidth range: 20.0 to 5600.0 step 0.0 Hz
> |   |   |   |   Connection Type: IQ
> |   |   |   |   Uses LO offset: No
> |   |   | _
> |   |   |/
> |   |   |   |   RX Codec: A
> |   |   |   |   Name: E3x0 RX dual ADC
> |   |   |   |   Gain Elements: None

Re: [USRP-users] [RFNoC] uhd_usrp_probe fails and throws uhd::lookup_error

[EJ Kreinar via USRP-users]

Adam,

In the rfnoc_ce_auto_inst.v you posted, it looks like the NUM_CE (6) does
not match your actual number of CEs (2):

```
  localparam NUM_CE = 6;  // Must be no more than 14 (2 ports taken by
radio core & PS-PL DMA).

  wire [NUM_CE*64-1:0] ce_flat_o_tdata, ce_flat_i_tdata;
  wire [63:0]  ce_o_tdata[0:NUM_CE-1], ce_i_tdata[0:NUM_CE-1];
  wire [NUM_CE-1:0]ce_o_tlast, ce_o_tvalid, ce_o_tready, ce_i_tlast,
ce_i_tvalid, ce_i_tready;
  wire [63:0]  ce_debug[0:NUM_CE-1];

  // Flattern CE tdata arrays
  genvar k;
  generate
for (k = 0; k < NUM_CE; k = k + 1) begin
  assign ce_o_tdata[k] = ce_flat_o_tdata[k*64+63:k*64];
  assign ce_flat_i_tdata[k*64+63:k*64] = ce_i_tdata[k];
end
  endgenerate

  wire ce_clk = radio_clk;
  wire ce_rst = radio_rst;

  noc_block_axi_fifo_loopback inst_noc_block_axi_fifo_loopback (
.bus_clk(bus_clk), .bus_rst(bus_rst),
.ce_clk(ce_clk), .ce_rst(ce_rst),
.i_tdata(ce_o_tdata[0]), .i_tlast(ce_o_tlast[0]),
.i_tvalid(ce_o_tvalid[0]), .i_tready(ce_o_tready[0]),
.o_tdata(ce_i_tdata[0]), .o_tlast(ce_i_tlast[0]),
.o_tvalid(ce_i_tvalid[0]), .o_tready(ce_i_tready[0]),
.debug(ce_debug[0]));

  noc_block_delay_fifo inst_noc_block_delay_fifo (
.bus_clk(bus_clk), .bus_rst(bus_rst),
.ce_clk(ce_clk), .ce_rst(ce_rst),
.i_tdata(ce_o_tdata[1]), .i_tlast(ce_o_tlast[1]),
.i_tvalid(ce_o_tvalid[1]), .i_tready(ce_o_tready[1]),
.o_tdata(ce_i_tdata[1]), .o_tlast(ce_i_tlast[1]),
.o_tvalid(ce_i_tvalid[1]), .o_tready(ce_i_tready[1]),
.debug(ce_debug[1]));
```

I might recommend trying to use the uhd_image_builder.py or
uhd_image_builder_gui.py applications as described in the tutorial here:
https://kb.ettus.com/Getting_Started_with_RFNoC_Development

EJ

On Wed, Jan 24, 2018 at 12:09 PM, Adam Kurisko  wrote:

> Hi again EJ and Martin,
>
>
> With the fresh install, I am still receiving the same error with a few
> extra error lines now. The error is shown below.
>
>
> root@ettus-e3xx-sg1:~/localinstall/usr/share/uhd/images# uhd_usrp_probe
> --args="fpga=usrp_e310_fpga_RFNOC.bit"[INFO] [UHDlinux; GNU C++ version
> 4.9.2; Boost_105700; UHD_4.0.0.rfnoc-devel-409-gec9138eb]
> [INFO] [E300] Loading FPGA image: usrp_e310_fpga_RFNOC.bit...
> [INFO] [E300] FPGA image loaded
> [INFO] [E300] Initializing core control (global registers)...
>
> [INFO] [E300] Performing register loopback test...
> [INFO] [E300] Register loopback test passed
> [INFO] [RFNOC RADIO] Register loopback test passed
> [INFO] [RFNOC RADIO] Register loopback test passed
> [ERROR] [UHD] Exception caught in safe-call.
>   in virtual ctrl_iface_impl::~ctrl_iface_impl()
>   at /home/kurisko/e310/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:76
> this->peek32(0); -> EnvironmentError: IOError: Block ctrl (CE_03_Port_40)
> no response packet - AssertionError: bool(buff)
>   in uint64_t ctrl_iface_impl::wait_for_ack(bool)
>   at /home/kurisko/e310/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:197
>
> terminate called after throwing an instance of 'uhd::lookup_error'
>   what():  LookupError: Path not found in tree: /mboards/0/tx_dsps/0
> Aborted
> root@ettus-e3xx-sg1:~/localinstall/usr/share/uhd/images#
>
>
> For reference, the rfnoc_ce_aut_inst.v file used to create the bitstream
> is shown below
>
>
>
>   localparam NUM_CE = 6;  // Must be no more than 14 (2 ports taken by
> radio core & PS-PL DMA).
>
>   wire [NUM_CE*64-1:0] ce_flat_o_tdata, ce_flat_i_tdata;
>   wire [63:0]  ce_o_tdata[0:NUM_CE-1], ce_i_tdata[0:NUM_CE-1];
>   wire [NUM_CE-1:0]ce_o_tlast, ce_o_tvalid, ce_o_tready, ce_i_tlast,
> ce_i_tvalid, ce_i_tready;
>   wire [63:0]  ce_debug[0:NUM_CE-1];
>
>   // Flattern CE tdata arrays
>   genvar k;
>   generate
> for (k = 0; k < NUM_CE; k = k + 1) begin
>   assign ce_o_tdata[k] = ce_flat_o_tdata[k*64+63:k*64];
>   assign ce_flat_i_tdata[k*64+63:k*64] = ce_i_tdata[k];
> end
>   endgenerate
>
>   wire ce_clk = radio_clk;
>   wire ce_rst = radio_rst;
>
>   noc_block_axi_fifo_loopback inst_noc_block_axi_fifo_loopback (
> .bus_clk(bus_clk), .bus_rst(bus_rst),
> .ce_clk(ce_clk), .ce_rst(ce_rst),
> .i_tdata(ce_o_tdata[0]), .i_tlast(ce_o_tlast[0]),
> .i_tvalid(ce_o_tvalid[0]), .i_tready(ce_o_tready[0]),
> .o_tdata(ce_i_tdata[0]), .o_tlast(ce_i_tlast[0]),
> .o_tvalid(ce_i_tvalid[0]), .o_tready(ce_i_tready[0]),
> .debug(ce_debug[0]));
>
>   noc_block_delay_fifo inst_noc_block_delay_fifo (
> .bus_clk(bus_clk), .bus_rst(bus_rst),
> .ce_clk(ce_clk), .ce_rst(ce_rst),
> .i_tdata(ce_o_tdata[1]), .i_tlast(ce_o_tlast[1]),
> .i_tvalid(ce_o_tvalid[1]), .i_tready(ce_o_tready[1]),
> .o_tdata(ce_i_tdata[1]), .o_tlast(ce_i_tlast[1]),
> .o_tvalid(ce_i_tvalid[1]), .o_tready(ce_i_tready[1]),
> .debug(ce_debug[1]));
>
> Also this on a fresh install of the most recent UHD rfnoc-devel branch.
> No xml was included on this build of it so I have ruled out the xml as
> causing the issue.
>
> Does this mean it may be my user code 

Re: [USRP-users] [RFNoC] uhd_usrp_probe fails and throws uhd::lookup_error

[EJ Kreinar via USRP-users]

Hi Adam,

Please copy/paste your rfnoc_ce_auto_inst.v

In my experience, these errors are usually due to something wrong in this
file. Probably causes are that NUM_CE != the actual number of CEs. Or that
when you added a new CE, you didn't increment the index of the wires, so
two blocks are on the same index. Or, if you've tried to instantiate a DDC
with NUM_CHAN=1, but did not change the NOC_BLOCK_ID to reflect only one
channel

Of course, could be something else-- those are just the problems I've
personally found (multiple times) that throw similar errors.

EJ



On Jan 23, 2018 6:18 PM, "Martin Braun via USRP-users" <
usrp-users@lists.ettus.com> wrote:

> On 01/23/2018 03:01 PM, Adam Kurisko wrote:
> > I am unsure if I had edited the property subtrees, however I decided to
> > fresh install UHD to see if that might fix the problem. I will let you
> > know if I experience similar errors.
> >
> >
> > In the mean time while it is installing, could you explain the process
> > for implementing the block using UHD without GNU Radio.
> >
> >
> > I have my block made and it simulates/synths/impls in Vivado.
> >
> > I changed the Makefile.srcs in ..lib/rfnoc to include my custom block.
> >
> > I changed rfnoc_ce_auto_inst.v in ..top/e300 to instantiate my block.
> >
> > I run 'make E310_RFNOC' to generate a bitstream.
> >
> > I then secure copy the generated bitstream into the correct images
> > directory on my board
>
> ...this all looks good...
> >
> > and finally run 'uhd_usrp_probe' with my custom .bit file.
>
> ...and this should now list your block. Does it?
>
> > Does all that seem correct or am I missing a vital step in there
> somewhere?
> >
> > I read in one of your slide shows that I may also need to create a .xml
> > file, but is this solely for GNU Radio or do I need to do this for UHD
> > as well?
>
> If you change nothing on the software side, your block will be listed as
> "Block_0". You need one XML for UHD and GNU Radio each (so 2 total if
> you want to use GNU Radio, but at least 1).
>
> You can start by literally hacking up an XML file and copying it into
> the XML directory, on the E310 it's under
> /usr/share/uhd/rfnoc/blocks/*.xml. Also check out our knowledge base
> articles on RFNoC block writing.
>
> Cheers,
> Martin
>
>
>
>
>
> ___
> 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] x310 simulating RFNoC block with Xilinx IP

[EJ Kreinar via USRP-users]

Hi Tien,

If the Xilinx IP is included in the uhd-fpga/usrp3/lib repo, you can follow
the example provided in the Makefile for the noc_block_fft_tb: https://
github.com/EttusResearch/fpga/blob/rfnoc-devel/usrp3/lib/
rfnoc/noc_block_fft_tb/Makefile

Note the three steps:
1. set LIB_IP_DIR
2. Include the Makefile.inc associated with the Xilinx IP
3. Append generated IP to the DESIGN_SRCS

If the Xilinx IP you want to use is contained in an OOT repo, then you
would want to follow the Makefile.inc process of including the OOT repo:
https://github.com/ejk43/rfnoc-ootexample

The "noc_block_complextomagphase_tb" example shows an example of how to
include and simulate Xilinx IP inside an OOT repo: https://github.com/
ejk43/rfnoc-ootexample/blob/master/rfnoc/testbenches/noc_
block_complextomagphase_tb/Makefile

For another example, this repo with a polyphase channelizer also shows how
to include and simulate Xilinx IP in an OOT repo: https://github.com/
e33b1711/rfnoc-ppchan

Hope this helps,
EJ

On Fri, Jan 19, 2018 at 10:28 PM, Dang tien Vo-Huu via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi all,
> I have this error when trying to simulate a custom RFNoC block in an OOT
> module:
>
> $ make noc_block_hbFilter_tb
> .
> .
> Starting static elaboration
> ERROR: [VRFC 10-2063] Module  not found while processing
> module instance  [/home/tienvh/workspace/rfnoc/
> src/rfnoc-filters/rfnoc/fpga-src/noc_block_hbFilter.v:179]
> ERROR: [XSIM 43-3322] Static elaboration of top level Verilog design
> unit(s) in library work failed.
> INFO: [USF-XSim-99] Step results log file:'/home/tienvh/workspace/r
> fnoc/src/rfnoc-filters/rfnoc/testbenches/noc_block_hbFilter_
> tb/xsim_proj/xsim_proj.sim/sim_1/behav/elaborate.log'
> ERROR: [USF-XSim-62] 'elaborate' step failed with error(s). Please check
> the Tcl console output or '/home/tienvh/workspace/rfnoc/
> src/rfnoc-filters/rfnoc/testbenches/noc_block_hbFilter_tb/
> xsim_proj/xsim_proj.sim/sim_1/behav/elaborate.log' file for more
> information.
> .
> .
>
> I can build an FPGA image with the custom RFNoC block following the
> instruction here: http://www.synchronouslabs.com/blog/creating-a-custom-
> rfnoc-block-with-using-xillinx-ip
> but I haven't found a way to simulate this block.
> Is there any way to run the simulation in this situation? Otherwise it
> would be difficult to debug if anything goes wrong..
>
> Thanks in advance.
>
> Best,
> Tien
>
> ___
> 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] what is the best way to rapidly change the sample rate of the E310 while using gnuradio

[EJ Kreinar via USRP-users]

Hi Jack,

I'll hit the RFNoC side...

> I have tried using the RFNOC USRP block, however, this block does not
have the "command" PMT message input for retuning while a flowgraph is
running. And a related question is that the RFNOC block only has a master
clock rate and a Bandwidth and no sample rate.  Would it be safe to say the
when using this block with the E310, that the sample rate and the clock
rate are set to the same value always?

This is correct. The "RFNoC Radio" GRC block attaches to the radio block in
the FPGA, and the output rate is equal to the master_clock_rate.

If you set up the following RFNoC connections, you'll get comparable
functionality to the "USRP Source":

RFNoC Radio -> RFNoC DDC -> Processor

Using the RFNoC DDC, you can downsample from a master_clock_rate to your
desired sample rate (also, if you want an "LO offset", you'll need to
manually off-tune the RFNoC Radio center frequency, and then frequency
shift in the opposite direction in the RFNoC DDC).


> What I'm trying to do is rapidly retune between 24 Msps and 12 Msps, and
possibly other arbitrary rates too shortly

How rapidly? Like, 10s of microseconds? Or several Hz?

A fundamental limitation for both the B200 and the E310 when changing the
master_clock_rate or center frequency is going to be the characteristics of
the AD9361 chip itself... I'd refer to the datasheet/manual/source code
here, but there are definite switching penalties for changing center
frequency, and there are likely limitations on changing master_clock_rate,
too (you probably cant hit 10 microseconds when changing center frequency
or master_clock_rate). However, since the FPGA includes digital
downsampling performed in the DDC, you *should* be able to change the
sample rate between 24 and 12 Msps very easily... I'd imagine a "rapid"
sample rate change in the B200 relies on changing some digital downsampling
parameters.


I'd also be a little concerned trying to hit 12 Msps between the FPGA and
Processor on the E310. Usually my tests max out around 1 to 2 Msps
continuous streaming before I get Overflows. Have you had success with
these higher sample rates on the E310??

EJ

On Thu, Jan 4, 2018 at 3:48 PM, Jack Ziegler via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello,
>
> I'm using gnuradio with the usrp_source block.  What I'm trying to do is
> rapidly retune between 24 Msps and 12 Msps, and possibly other arbitrary
> rates too shortly.
>
> This is easy to do with a B200 series radio using the usrp_source block
> and the command message port by sending a PMT message of the "rate" type.
>
> However, I'm now using an E310 and it will not easily retune.  I can do 24
> and 12 Msps by starting out with a 24 and 12 as the clock rate, however,
> the current API only allows setting the sample rate and not the clock rate
> during run time.  Would it make sense for the E310 only to hack the
> usrp_source block code to set the clock rate and the sample rate at the
> same time?
>
> Also, I have a related question. I have tried using the RFNOC USRP block,
> however, this block does not have the "command" PMT message input for
> retuning while a flowgraph is running. And a related question is that the
> RFNOC block only has a master clock rate and a Bandwidth and no sample
> rate.  Would it be safe to say the when using this block with the E310,
> that the sample rate and the clock rate are set to the same value always?
>
> Thanks
>
> Jack
>
> ___
> 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] Multiple RFNoC blocks instantiated

[EJ Kreinar via USRP-users]

Hi Mark,

Yes, multiple distinct instances of an rfnoc block can be supported.

In the flowgraph, you need to place a component representing each RFNoC
block you want to attach to-- then set the "block select" parameter to
unique indices. For example, to use two FIFOs, set up with "RFNoC Config"
-> "FIFO Select" to be 0 and 1 for your two instances respectively.
Flowgraph might look something like this:

[image: Inline image 1]

Hope this helps
EJ


On Dec 8, 2017 7:49 AM, "Mark Luscombe via USRP-users" <
usrp-users@lists.ettus.com> wrote:

P.S. Obviously i have compiled 2 instances of the block into the FPGA
image, maybe i need to add some unique identification at this point?

On 8 December 2017 at 12:42, Mark Luscombe  wrote:

> Hi,
>
> I've found that if i add a second instance of the same RFNoC block to a
> GRC signal flow it fails to compile, complaining that there are duplicate
> connections to the first instance of the RFNoC block. This happens with
> either my own RFNoC blocks or Ettus RFNoC blocks. Am i missing something as
> it seems like the environment currently cannot handle multiple instances. I
> guess worse case i could make duplicates of the RFNoC blocks i want
> multiple instances of, so that each instance is unique but this is not
> ideal.
>
> Thanks, Mark.
>
>

___
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] build uhd rfnoc for e310 get some errors

[EJ Kreinar via USRP-users]

Hi Carry,

This looks like a repeat of an issue from March of this year:
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2017-March/023950.html

It doesnt look like it measurably impacts E310 performance. I havent tried
recent builds of rfnoc, so I cannot personally confirm if it's fixed or
not, but I'm not aware of any updates to this issue (I've also seen this on
the mailing list a few times since March).

Cheers,
EJ

On Tue, Dec 12, 2017 at 6:46 AM, carry chen via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi,list,
>
> I complie uhd rfnoc version for e310 follow the link:
>
>
> https://kb.ettus.com/Software_Development_on_the_E3xx_USRP_-
> _Building_RFNoC_UHD_/_GNU_Radio_/_gr-ettus_from_Source
>
>
>
> but when run on e310, I get some error:
>
> [INFO] [UHDlinux; GNU C++ version 4.9.2; Boost_105700;
> UHD_4.0.0.rfnoc-devel-409-gec9138eb]
> [INFO] [E300] Loading FPGA image: /home/root/newinstall/usr/
> share/uhd/images/usrp_e310_fpga_sg3.bit...
> [INFO] [E300] FPGA image loaded
> [INFO] [E300] Initializing core control (global registers)...
>
> [INFO] [E300] Performing register loopback test...
> [INFO] [E300] Register loopback test passed
> [INFO] [RFNOC RADIO] Register loopback test passed
> [INFO] [RFNOC RADIO] Register loopback test passed
> [WARNING] [RFNOC] [0/fosphor_0] defines 2 input buffer sizes, but 1 input
> ports
> [INFO] [AD936X] Performing CODEC loopback test...
> [INFO] [AD936X] CODEC loopback test passed
> [INFO] [AD936X] Performing CODEC loopback test...
> [INFO] [AD936X] CODEC loopback test passed
> [INFO] [CORES] Performing timer loopback test...
> [INFO] [CORES] Timer loopback test passed
>   _
>  /
> |   Device: E-Series Device
> | _
> |/
> |   |   Mboard: E3XX
> |   |   product: 30675
> |   |   revision: 6
> |   |   serial: F65F2F
> |   |   mac-addr: 00:80:2f:16:0b:fd
> |   |   FPGA Version: 255.0
> |   |   FPGA git hash: f764326-dirty
> |   |   RFNoC capable: Yes
> |   |
> |   |   Time sources:  none, internal, external
> |   |   Clock sources: internal
> |   |   Sensors: temp, ref_locked
> |   | _
> |   |/
> |   |   |   RX DSP: 0
> |   |   |
> |   |   |   Freq range: 0.000 to 0.000 MHz
> |   | _
> |   |/
> |   |   |   RX DSP: 1
> |   |   |
> |   |   |   Freq range: 0.000 to 0.000 MHz
> |   | _
> |   |/
> |   |   |   RX Dboard: A
> |   |   |   ID: E310 MIMO XCVR (0x0110)
> |   |   |   Serial: 3102B9F
> |   |   | _
> |   |   |/
> |   |   |   |   RX Frontend: A
> |   |   |   |   Name: FE-RX2
> |   |   |   |   Antennas: TX/RX, RX2
> |   |   |   |   Sensors: temp, rssi, lo_locked
> |   |   |   |   Freq range: 50.000 to 6000.000 MHz
> |   |   |   |   Gain range PGA: 0.0 to 76.0 step 1.0 dB
> |   |   |   |   Bandwidth range: 20.0 to 5600.0 step 0.0 Hz
> |   |   |   |   Connection Type: IQ
> |   |   |   |   Uses LO offset: No
> |   |   | _
> |   |   |/
> |   |   |   |   RX Frontend: B
> |   |   |   |   Name: FE-RX1
> |   |   |   |   Antennas: TX/RX, RX2
> |   |   |   |   Sensors: temp, rssi, lo_locked
> |   |   |   |   Freq range: 50.000 to 6000.000 MHz
> |   |   |   |   Gain range PGA: 0.0 to 76.0 step 1.0 dB
> |   |   |   |   Bandwidth range: 20.0 to 5600.0 step 0.0 Hz
> |   |   |   |   Connection Type: IQ
> |   |   |   |   Uses LO offset: No
> |   |   | _
> |   |   |/
> |   |   |   |   RX Codec: A
> |   |   |   |   Name: E3x0 RX dual ADC
> |   |   |   |   Gain Elements: None
> |   | _
> |   |/
> |   |   |   TX DSP: 0
> |   |   |
> |   |   |   Freq range: 0.000 to 0.000 MHz
> |   | _
> |   |/
> |   |   |   TX DSP: 1
> |   |   |
> |   |   |   Freq range: 0.000 to 0.000 MHz
> |   | _
> |   |/
> |   |   |   TX Dboard: A
> |   |   |   ID: E310 MIMO XCVR (0x0110)
> |   |   |   Serial: 3102B9F
> |   |   | _
> |   |   |/
> |   |   |   |   TX Frontend: A
> |   |   |   |   Name: FE-TX2
> |   |   |   |   Antennas: TX/RX
> |   |   |   |   Sensors: temp, lo_locked
> |   |   |   |   Freq range: 50.000 to 6000.000 MHz
> |   |   |   |   Gain range PGA: 0.0 to 89.8 step 0.2 dB
> |   |   |   |   Bandwidth range: 20.0 to 5600.0 step 0.0 Hz
> |   |   |   |   Connection Type: IQ
> |   |   |   |   Uses LO offset: No
> |   |   | _
> |   |   |/
> |   |   |   |  

Re: [USRP-users] RFNoC Out-of-tree block controller setup

[EJ Kreinar via USRP-users]

Well, per usual, I believe I've figured this out with some more digging...

1. If I run a python program that includes my OOT module, the blocks are
registered correctly with the block_ctrl_base_factory, and the
initialization call to ettus.device3 will correctly correlate my FPGA CE
with the OOT controller.

2. I assume that a C program will also register blocks correctly if it uses
the my class and links to the OOT module

3. But the uhd_usrp_probe is *not* linked to my OOT module, so I dont think
I should expect it to register my new controller class.

Conclusion #3 is sad because I like using uhd_usrp_probe as a debug tool to
evaluate whether blocks are configured and initialized correctly, but I'm
not sure if there's a way to get around this.. Maybe I could create an OOT
uhd_usrp_probe function that compiles/links with my OOT repo(s)?

Is this all correct?
EJ

On Fri, Dec 8, 2017 at 11:52 AM, EJ Kreinar  wrote:

> Hi All,
>
> I'm having trouble getting an OOT RFNoC block controller to register
> correctly with the rfnoc block factory. The goal here is to create a block
> controller class that attaches to the FPGA CE.
>
> I've traced this operation down to the block_ctrl_base_factory.cpp, which
> exposes the register_block(...) function that is called from RFNoC block
> controllers using the UHD_RFNOC_BLOCK_REGISTER macro. When I add a debug
> statement in the register_block function, I can see all of the block
> controllers in the UHD repo getting registered at the start of a
> uhd_usrp_probe, but my OOT block is not registered here.
>
> Register block adding key: Block
> Register block adding key: DDC
> Register block adding key: DUC
> Register block adding key: FIR
> Register block adding key: NullSrcSink
> Register block adding key: Window
> Register block adding key: SigGen
> Register block adding key: DmaFIFO
> Register block adding key: X300Radio
>
> If I take the SAME block controller cpp and hpp files from my OOT repo,
> insert into the UHD repo with corresponding CMakeLists edits, and then
> rerun, I can see the block controller get registered on startup.
>
> Any suggestions how to register the blocks from the OOT repos??  Am I
> missing something obvious?
>
> Thanks!
> EJ
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] RFNoC Out-of-tree block controller setup

[EJ Kreinar via USRP-users]

Hi All,

I'm having trouble getting an OOT RFNoC block controller to register
correctly with the rfnoc block factory. The goal here is to create a block
controller class that attaches to the FPGA CE.

I've traced this operation down to the block_ctrl_base_factory.cpp, which
exposes the register_block(...) function that is called from RFNoC block
controllers using the UHD_RFNOC_BLOCK_REGISTER macro. When I add a debug
statement in the register_block function, I can see all of the block
controllers in the UHD repo getting registered at the start of a
uhd_usrp_probe, but my OOT block is not registered here.

Register block adding key: Block
Register block adding key: DDC
Register block adding key: DUC
Register block adding key: FIR
Register block adding key: NullSrcSink
Register block adding key: Window
Register block adding key: SigGen
Register block adding key: DmaFIFO
Register block adding key: X300Radio

If I take the SAME block controller cpp and hpp files from my OOT repo,
insert into the UHD repo with corresponding CMakeLists edits, and then
rerun, I can see the block controller get registered on startup.

Any suggestions how to register the blocks from the OOT repos??  Am I
missing something obvious?

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

Re: [USRP-users] Siggen not working in E310

[EJ Kreinar via USRP-users]

Hi Tom and John,

Just thought I'd revive this thread to confirm Nick Foster's suggested
approach for rfnoc loopback works successfully for Siggen Tx on E310
(Siggen -> Radio Tx):
https://www.mail-archive.com/usrp-users@lists.ettus.com/msg02916.html

It ended up as ~30-minute fix to add the edits, rebuild gr-ettus, deploy to
E310, and confirm functionality. Overall quite a good result :)

My manual edits to the GRC-generated flowgraph were as follows:

1. In the __init__ function of the flowgraph, after all the connections are
created, add the following
line: self.uhd_rfnoc_streamer_radio_0_0.set_tx_streamer(True, 0)

2. In the main function, after starting the flowgraph, enable the Siggen.
For example:

tb.start()
tb.uhd_rfnoc_streamer_siggen_0.set_arg("enable", True)
try:
raw_input('Press Enter to quit: ')
except EOFError:
pass


Empirically, I've found that the siggen enable can be in the __init__
function after set_tx_streamer(True,0) from step #1. However if I enable
siggen before the connections, I fail to transmit any output. My hypothesis
is that perhaps an internal buffer in siggen gets full, but enabling the
siggen after rfnoc connections are ready will let the siggen output
propagate through to the Radio TX block correctly.

EJ

On Mon, Sep 25, 2017 at 6:11 PM, Tom Bereknyei via USRP-users <
usrp-users@lists.ettus.com> wrote:

> My experiments with SIGGEN on the E310 were similar. At the moment my
> workaround is to just send noise or burst samples from the CPU exactly when
> needed. I would be interested in a way to use siggen. I am also working on
> a siggen-like block which will hop frequencies. I am interested in any
> design considerations, thoughts, or advice on the design of the block. If
> it can be general enough it can be pushed to upstream.
>
> On Mon, Sep 25, 2017 at 18:04 John Medrano via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hello,
>>
>> I have been working on getting Siggen working under E310. I built RFNOC
>> image with siggen for E310. I have been able to use that image to generate
>> a signal from RFNOC_SIGGEN -> HOST, but when I try to rung RFNOC_SIGGEN ->
>> RFNOC_DUC -> RFNOC_RADIO I received an error. The error I received goes
>> away if I start with siggen enable = FALSE.
>>
>> See below, the script was modified to enable siggen after 2 seconds, and
>> again it does not complain, but I get absolutely no output.
>>
>> Following are script and original error that I receive.
>>
>> Please advise,
>> John
>>
>> #!/usr/bin/env python2
>> # -*- coding: utf-8 -*-
>> ##
>> # GNU Radio Python Flow Graph
>> # Title: Rfnoc Sin Radio E310
>> # Generated: Thu Sep 21 14:12:08 2017
>> ##
>>
>> from gnuradio import eng_notation
>> from gnuradio import gr
>> from gnuradio import uhd
>> from gnuradio.eng_option import eng_option
>> from gnuradio.filter import firdes
>> from optparse import OptionParser
>> import ettus
>>
>>
>> class RFNoc_Sin_Radio_e310(gr.top_block):
>>
>> def __init__(self):
>> gr.top_block.__init__(self, "Rfnoc Sin Radio E310")
>>
>> ##
>> # Variables
>> ##
>> self.samp_rate = samp_rate = 2e6
>> self.device3 = variable_uhd_device3_0 =
>> ettus.device3(uhd.device_addr_t( ",".join(('type=e3x0',
>> "fpga=/home/root/rfnoc/usr/share
>> /uhd/images/usrp_e310_fpga_RFNOC_sg3.bit")) ))
>> self.up_rate = up_rate = 12e6
>> self.gain = gain = 0.5
>> self.freq = freq = samp_rate/10
>> self.enable = enable = False
>> self.ampl_q = ampl_q = 1
>> self.ampl_i = ampl_i = 1
>>
>> ##
>> # Blocks
>> ##
>> self.uhd_rfnoc_streamer_siggen_0 = ettus.rfnoc_generic(
>> self.device3,
>> uhd.stream_args( # TX Stream Args
>> cpu_format="fc32", # TODO: This must be made an option
>> otw_format="sc16",
>> args="",
>> ),
>> uhd.stream_args( # RX Stream Args
>> cpu_format="fc32", # TODO: This must be made an option
>> otw_format="sc16",
>> args="",
>> ),
>> "SigGen", -1, -1,
>> )
>> self.uhd_rfnoc_streamer_siggen_0.set_arg("spp",  364)
>> self.uhd_rfnoc_streamer_siggen_0.set_arg("frequency",
>> ((2*freq)/samp_rate))
>> self.uhd_rfnoc_streamer_siggen_0.set_arg("waveform", "SINE_WAVE")
>> self.uhd_rfnoc_streamer_siggen_0.set_arg("gain", gain)
>> self.uhd_rfnoc_streamer_siggen_0.set_arg("enable", enable)
>> self.uhd_rfnoc_streamer_siggen_0.set_arg("amplitude_i",
>> complex(ampl_i , ampl_q).real)
>> 

Re: [USRP-users] Error creating RFNoC FPGA image with OOT module

[EJ Kreinar via USRP-users]

Hi Jose,

You've encountered a new feature of the uhd-fpga build process. If your OOT
repo has a Makefile.inc, the uhd_image_builder.py script will point to
those makefiles in the OOT repo. This is especially useful for synthesizing
Xilinx IP or HLS cores. (See the Makefile.inc files here for a dummy
example: https://github.com/ejk43/rfnoc-ootexample/tree/master/rfnoc) This
is a feature that is (as of today, Oct 2017) not currently supported with
rfnocmodtool, so it's somewhat "advanced", but we'd like to add this
capability to rfnocmodtool soon :)

It looks like your noc_block_twochannelsiggen is just not getting found.
This is probably an issue with the Makefiles in your OOT repo.

For example, this configuration might work:

1. /rfnoc-siggench2/rfnoc/Makefile.inc:

RFNOC_SIGGEN2CH_DIR := $(OOT_DIR)
include $(abspath $(RFNOC_SIGGEN2CH_DIR)/fpga-src/Makefile.inc)


2. /rfnoc-siggench2/rfnoc/fpga-src/Makefile.inc:

RFNOC_SRCS += $(addprefix $(RFNOC_SIGGEN2CH_DIR)/fpga-src/, \
noc_block_twochannelsiggen.v \
)

A side note, it's important to use " := $(OOT_DIR)" to define a
unique variable that represent the out-of-tree directory-- this reads the
value of the OOT_DIR immediately, rather than deferring evaluation until
later, a nagging "feature" of the make process.



Of course, if you have no need of IP cores or HLS, you can happily delete
all the Makefile.inc files in your repo and use the Makefile.srcs format
that's supported via rfnocmodtool. Perhaps it's the easiest solution.

EJ


On Tue, Oct 3, 2017 at 4:52 PM, Nicolas Cuervo via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello Jose,
>
> please try running the following:
>
> $ ./uhd_image_builder.py twochannelsiggen duc fft *-I
> /home/joseavila/Documents/gnuradio_source/rfnoc-siggen2ch/* -d x310 -t
> X310_RFNOC_HG -m 6 --fill-with-fifos
>
> which means pointing to the top OOT directory instead to directly the
> fpga-srcs directory. This small change was recently introduced and might be
> the source of your issue. I just modified the guide accordingly.
>
> Also, there is a possibility that you will face another path problem that
> has already been fixed, but is yet to be pushed into the repository. To
> avoid it, before running the uhd_image_builder, please go into the
> uhd_image_builder.py file and modify the L239 from:
>
> -curr_srcs = curr_srcs.replace('SOURCES_PATH',
> os.path.join(oot_path, 'rfnoc', 'fpga-src'))
>
> to:
>
> +curr_srcs = curr_srcs.replace('SOURCES_PATH',
> os.path.join(oot_path, 'rfnoc', 'fpga-src', ''))
>
> As said, this fix will be pushed soon, but for now you can avoid problems
> by doing it manually.
>
> Regards,
> - Nicolas
>
> On Tue, Oct 3, 2017 at 9:21 PM, Avila, Jose A via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> We are currently getting an error attempting to build a fpga image when
>> running the following which points to the OOT module using the -I option
>>
>>
>>
>> *./uhd_image_builder.py twochannelsiggen duc fft -I
>> /home/joseavila/Documents/gnuradio_source/rfnoc-siggen2ch/rfnoc/fpga-src/
>> -d x310 -t X310_RFNOC_HG -m 6 --fill-with-fifos*
>>
>>
>>
>> The testbench ran successfully but now the image builder is giving an
>> error saying module *noc_block_twochannelsiggen not found
>> [.../top/x300/rfnoc_ce_auto_inst_x310.v]*
>>
>> twochannelsiggen is the OOT module created with rfnocmodtool in the
>> rfnoc-siggen2ch directory.  We tried editing the Makefile.OOT.inc in
>> /…/top/x300 with the following two lines
>>
>>
>>
>> *OOT_DIR =
>> /home/joseavila/Documents/gnuradio_source/rfnoc-siggen2ch/rfnoc*
>>
>> *include $(OOT_DIR)/Makefile.inc*
>>
>>
>>
>> As well as editing the subsequent makefiles in the OOT rfnoc directory.
>> We did notice that the Makefile.OOT.inc would get erased after running the
>> image builder and it erroring out.  The following is the error
>> encountered with the image builder
>>
>>
>>
>>
>> Parameter my_addr bound to: 237 - type: integer
>>
>>
>>
>> Parameter awidth bound to: 8 - type: integer
>>
>>
>>
>> Parameter width bound to: 32 - type: integer
>>
>>
>>
>> Parameter at_reset bound to: 0 - type: integer
>>
>>
>>
>> INFO: [Synth 8-256] done synthesizing module
>> 'setting_reg__parameterized18' (136#1) [/home/joseavila/Documents/gnu
>> radio_source/fpga/usrp3/lib/control/setting_reg.v:12]
>>
>>
>>
>> INFO: [Synth 8-256] done synthesizing module 'rx_frontend_gen3' (137#1)
>> [/home/joseavila/Documents/gnuradio_source/fpga/usrp3/lib/ra
>> dio/rx_frontend_gen3.v:5]
>>
>>
>>
>> ERROR: [Synth 8-439] module 'noc_block_twochannelsiggen' not found
>> [/home/joseavila/Documents/gnuradio_source/fpga/usrp3/top/x3
>> 00/rfnoc_ce_auto_inst_x310.v:22]
>>
>>
>>
>> ERROR: [Synth 8-285] failed synthesizing module 'x300_core'
>> [/home/joseavila/Documents/gnuradio_source/fpga/usrp3/top/x3
>> 00/x300_core.v:2]
>>
>>
>>
>> ERROR: [Synth 8-285] failed synthesizing module 'x300'
>> 

Re: [USRP-users] Building USRP Image with Vivado GUI

[EJ Kreinar via USRP-users]

Hi Luis,

In my experience this is a very common FPGA error! It gets me very often.
It's not specific to the GUI workflow...

You must make sure the following factors agree in the rfnoc_ce_auto_inst.v:
 1. The number of CEs localparam (NUM_CE) must equal to the actual number
of CEs instantiated. (Your NUM_CE = 6, while there's only 4 CEs
instantiated, included those in the generate loop)
 2. The ce_i_tdata and ce_o_tdata indices need to start at 0 and progress
to NUM_CE - 1. (You skip indices 0 and 1)

Basically, you'll get that run time error if the software tries to interact
with a CE that is not actually on the AXI crossbar.

I've attached a modified version of your file that should work (though
untested). Hope this helps,

EJ

On Wed, Sep 27, 2017 at 4:24 AM, Torres Figueroa, Luis Angel via USRP-users
 wrote:

> Hi folks,
>
>
>
> I want to modify and build FPGA images using the Vivado GUI, however I’m
> still having problems with this. Here the procedure I have followed.
>
>
>
> I have first set up the environment using the command “make X310_RFNOC_HG
> GUI=1” and then run the synthesis/implementation; this worked fine and I
> could build a correct image and load it onto the USRP. Then I modified just
> the rfnoc_ce_auto_inst_x310.v file (modification attached) in Vivado
> project mode and tried to build a new image with fewer CEs, as referred in
> http://lists.ettus.com/pipermail/usrp-users_lists.
> ettus.com/2016-September/021709.html. However even though the building
> process did not show any error, after loading it onto the USRP I got the
> following error message:
>
>
>
> [INFO] [UHDlinux; GNU C++ version 4.8.4; Boost_105400;
> UHD_4.0.0.rfnoc-devel-369-g1908672f]
>
> [INFO] [X300] X300 initialization sequence...
>
> [INFO] [X300] Determining maximum frame size...
>
> [INFO] [X300] Maximum frame size: 1472 bytes.
>
> [INFO] [X300] Setup basic communication...
>
> [INFO] [X300] Loading values from EEPROM...
>
> [INFO] [X300] Setup RF frontend clocking...
>
> [INFO] [X300] Radio 1x clock:200
>
> [INFO] [X300] Detecting internal GPSDO
>
> [INFO] [GPS] Found an internal GPSDO: LC_XO, Firmware Rev 0.929a
>
> [ERROR] [UHD] Exception caught in safe-call.
>
>   in virtual ctrl_iface_impl::~ctrl_iface_impl()
>
>   at /home/ltorresf/source/uhd/host/lib/rfnoc/ctrl_iface.cpp:76
>
> this->peek32(0); -> EnvironmentError: IOError: Block ctrl (CE_00_Port_30)
> no response packet - AssertionError: bool(buff)
>
>   in uint64_t ctrl_iface_impl::wait_for_ack(bool)
>
>   at /home/ltorresf/source/uhd/host/lib/rfnoc/ctrl_iface.cpp:197
>
>
>
> Error: EnvironmentError: IOError: Block ctrl (CE_00_Port_30) no response
> packet - AssertionError: bool(buff)
>
>   in uint64_t ctrl_iface_impl::wait_for_ack(bool)
>
>   at /home/ltorresf/source/uhd/host/lib/rfnoc/ctrl_iface.cpp:197
>
>
>
> Has anyone had a similar problem and know how to solve it?
>
>
>
> Best,
>
> Luis
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
/
// Auto-generated by gen_rfnoc_inst.py! Any changes
// in this file will be overwritten the next time
// this script is run.
/
localparam NUM_CE = 4;
wire [NUM_CE*64-1:0] ce_flat_o_tdata, ce_flat_i_tdata;
wire [63:0]  ce_o_tdata[0:NUM_CE-1], ce_i_tdata[0:NUM_CE-1];
wire [NUM_CE-1:0]ce_o_tlast, ce_o_tvalid, ce_o_tready, ce_i_tlast, ce_i_tvalid, ce_i_tready;
wire [63:0]  ce_debug[0:NUM_CE-1];
// Flattern CE tdata arrays
genvar k;
generate
  for (k = 0; k < NUM_CE; k = k + 1) begin
assign ce_o_tdata[k] = ce_flat_o_tdata[k*64+63:k*64];
assign ce_flat_i_tdata[k*64+63:k*64] = ce_i_tdata[k];
  end
endgenerate
wire ce_clk = radio_clk;
wire ce_rst = radio_rst;

noc_block_fft inst_fft (
  .bus_clk(bus_clk), .bus_rst(bus_rst),
  .ce_clk(ce_clk), .ce_rst(ce_rst),
  .i_tdata(ce_o_tdata[0]), .i_tlast(ce_o_tlast[0]), .i_tvalid(ce_o_tvalid[0]), .i_tready(ce_o_tready[0]),
  .o_tdata(ce_i_tdata[0]), .o_tlast(ce_i_tlast[0]), .o_tvalid(ce_i_tvalid[0]), .o_tready(ce_i_tready[0]),
  .debug(ce_debug[0])
);

// Fill remaining crossbar ports with loopback FIFOs
genvar n;
generate
  for (n = 1; n < NUM_CE; n = n + 1) begin
noc_block_axi_fifo_loopback inst_noc_block_axi_fifo_loopback (
  .bus_clk(bus_clk), .bus_rst(bus_rst),
  .ce_clk(ce_clk), .ce_rst(ce_rst),
  .i_tdata(ce_o_tdata[n]), .i_tlast(ce_o_tlast[n]), .i_tvalid(ce_o_tvalid[n]), .i_tready(ce_o_tready[n]),
  .o_tdata(ce_i_tdata[n]), .o_tlast(ce_i_tlast[n]), .o_tvalid(ce_i_tvalid[n]), .o_tready(ce_i_tready[n]),
  .debug(ce_debug[n])
);
  end
endgenerate

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

Re: [USRP-users] E310 "subdev spec" equivalent in RFNoC?

[EJ Kreinar via USRP-users]

Hello again,

Wanted to send some more results in case anyone is following...

I narrowed the problem down to a few lines in gr-ettus's rfnoc_block_impl
that specifically overrides the block_port for each channel; the
"block_port" stream_args in device->get_rx_stream(stream_args) function was
coerced to equal the port of the gnuradio flowgraph.  (See code here:
https://github.com/EttusResearch/gr-ettus/blob/814a7de651cd4c5595ff66a0326e0f2927d2baef/lib/rfnoc_block_impl.cc#L334
)

I have a suggested change on on a PR that's available on my fork of
gr-ettus: https://github.com/ejk43/gr-ettus/tree/ejk/rfnoc-port-edit

Essentially this fix will NOT override any block_portX stream args you
specify in the stream args.

So we should be able to do this to target channel 1 of the E300: (note the
Stream args where block_port0=1)

[image: Inline image 1]

That does the trick for me. Hope this helps!
EJ



On Mon, Sep 25, 2017 at 9:38 AM, EJ Kreinar <ejkrei...@gmail.com> wrote:

> Hi all,
>
> On further inspection, I've had no more luck using python RFNoC to record
> on channel 1 (channel B)...
>
> Sadly, manually editing the stream args in the rfnoc radio did not appear
> to have any effect (see below). And, editing the "connect" in python
> command still errors out as per Test 3 of my original email.
>
> self.uhd_rfnoc_streamer_radio_0 = ettus.rfnoc_radio(
> self.device3,
> uhd.stream_args( # Tx Stream Args
> cpu_format="fc32",
> otw_format="sc16",
> args="block_port=1",
> ),
> uhd.stream_args( # Rx Stream Args
> cpu_format="fc32",
> otw_format="sc16",
> args="block_port=1",
> ),
> 0, -1
> )
>
> It appears that the rfnoc_rx_to_file takes a far more manual approach to
> running the application, rather than using gnuradio-- the rfnoc_rx_to_file
> creates the rfnoc graph and then calls the recv function in a loop, and
> does not use GR to link up to a file sink, as in the python flowgraph.
>
> Any other ideas? I'm currently leaning towards the conclusion that
> switching the receive channel is simply not currently supported with Rfnoc
> + Gnuradio.  Agreed??
>
> EJ
>
> On Mon, Sep 25, 2017 at 9:11 AM, EJ Kreinar <ejkrei...@gmail.com> wrote:
>
>> Thanks Tom, Quick update here...
>>
>> I've found a set of options that will control the E300 receive channel
>> using rfnoc software:
>>
>> rfnoc_rx_to_file --freq  --rate  --ant TX/RX
>> --radio-chan 0
>> rfnoc_rx_to_file --freq  --rate  --ant RX2
>> --radio-chan 0
>> rfnoc_rx_to_file --freq  --rate  --ant TX/RX
>> --radio-chan 1
>> rfnoc_rx_to_file --freq  --rate  --ant RX2
>> --radio-chan 1
>>
>>
>> Tracking where/how rfnoc_rx_to_file sets the appropriate channel, it
>> appears that it simply sets the "block_port" streamer args:
>>
>> streamer_args["block_port"] = str(boost::format("%d") %
>> radio_chan);
>>
>>
>> Or, alternatively, if there's a block inserted via the command line, then
>> the correct port is connected in the rx_graph:
>>
>> rx_graph->connect(radio_ctrl_id, radio_chan,
>> blk_ctrl->get_block_id(), uhd::rfnoc::ANY_PORT);
>>
>> Interestingly, this seems to suggest an approach closest to my "test 3"
>> earlier. I'll look for how this can tie into python rfnoc software now...
>>
>>
>> EJ
>>
>>
>> On Thu, Sep 21, 2017 at 4:24 PM, Tom Bereknyei <t...@dds.mil> wrote:
>>
>>> EJ,
>>>
>>> I went through that same sequence of attempts and never got a solution
>>> other than using TX/RX and RX2 on the same A channel.
>>>
>>> On Thu, Sep 21, 2017 at 14:05 EJ Kreinar via USRP-users <
>>> usrp-users@lists.ettus.com> wrote:
>>>
>>>> Hi all,
>>>>
>>>> I'm trying to specify exactly which channel to record from an RFNoC
>>>> flowgraph on the E310, but I cant seem to get this to work
>>>>
>>>> Typically, in non-RFNoC applications, or in the "legacy_compat" mode,
>>>> you can use the following options:
>>>>
>>>> uhd_rx_cfile -r  -f  -A TX/RX --spec=A:A
>>>> recording.c32
>>>> uhd_rx_cfile -r  -f  -A RX2 --spec=A:A
>>>> recording.c32
>>>> uhd_rx_cfile -r  -f  -A TX/RX --spec=A:B
>>>> recording.c32
>>>> uhd_rx_cfile -r  -f  -A RX2 --spec

Re: [USRP-users] E310 "subdev spec" equivalent in RFNoC?

[EJ Kreinar via USRP-users]

Hi all,

On further inspection, I've had no more luck using python RFNoC to record
on channel 1 (channel B)...

Sadly, manually editing the stream args in the rfnoc radio did not appear
to have any effect (see below). And, editing the "connect" in python
command still errors out as per Test 3 of my original email.

self.uhd_rfnoc_streamer_radio_0 = ettus.rfnoc_radio(
self.device3,
uhd.stream_args( # Tx Stream Args
cpu_format="fc32",
otw_format="sc16",
args="block_port=1",
),
uhd.stream_args( # Rx Stream Args
cpu_format="fc32",
otw_format="sc16",
args="block_port=1",
),
0, -1
)

It appears that the rfnoc_rx_to_file takes a far more manual approach to
running the application, rather than using gnuradio-- the rfnoc_rx_to_file
creates the rfnoc graph and then calls the recv function in a loop, and
does not use GR to link up to a file sink, as in the python flowgraph.

Any other ideas? I'm currently leaning towards the conclusion that
switching the receive channel is simply not currently supported with Rfnoc
+ Gnuradio.  Agreed??

EJ

On Mon, Sep 25, 2017 at 9:11 AM, EJ Kreinar <ejkrei...@gmail.com> wrote:

> Thanks Tom, Quick update here...
>
> I've found a set of options that will control the E300 receive channel
> using rfnoc software:
>
> rfnoc_rx_to_file --freq  --rate  --ant TX/RX
> --radio-chan 0
> rfnoc_rx_to_file --freq  --rate  --ant RX2
> --radio-chan 0
> rfnoc_rx_to_file --freq  --rate  --ant TX/RX
> --radio-chan 1
> rfnoc_rx_to_file --freq  --rate  --ant RX2
> --radio-chan 1
>
>
> Tracking where/how rfnoc_rx_to_file sets the appropriate channel, it
> appears that it simply sets the "block_port" streamer args:
>
> streamer_args["block_port"] = str(boost::format("%d") %
> radio_chan);
>
>
> Or, alternatively, if there's a block inserted via the command line, then
> the correct port is connected in the rx_graph:
>
> rx_graph->connect(radio_ctrl_id, radio_chan,
> blk_ctrl->get_block_id(), uhd::rfnoc::ANY_PORT);
>
> Interestingly, this seems to suggest an approach closest to my "test 3"
> earlier. I'll look for how this can tie into python rfnoc software now...
>
>
> EJ
>
>
> On Thu, Sep 21, 2017 at 4:24 PM, Tom Bereknyei <t...@dds.mil> wrote:
>
>> EJ,
>>
>> I went through that same sequence of attempts and never got a solution
>> other than using TX/RX and RX2 on the same A channel.
>>
>> On Thu, Sep 21, 2017 at 14:05 EJ Kreinar via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Hi all,
>>>
>>> I'm trying to specify exactly which channel to record from an RFNoC
>>> flowgraph on the E310, but I cant seem to get this to work
>>>
>>> Typically, in non-RFNoC applications, or in the "legacy_compat" mode,
>>> you can use the following options:
>>>
>>> uhd_rx_cfile -r  -f  -A TX/RX --spec=A:A
>>> recording.c32
>>> uhd_rx_cfile -r  -f  -A RX2 --spec=A:A
>>> recording.c32
>>> uhd_rx_cfile -r  -f  -A TX/RX --spec=A:B
>>> recording.c32
>>> uhd_rx_cfile -r  -f  -A RX2 --spec=A:B
>>> recording.c32
>>>
>>> And each option, in turn, records data from a different receive port on
>>> the E310.
>>>
>>>
>>> But, I cant figure out the correct combination to get the rfnoc_radio
>>> software to support recording on channel B. A few things I've tried:
>>>
>>> 1. Changing the rfnoc_radio dropdown to "Radio Select = B". This errors
>>> like this:
>>>
>>> Traceback (most recent call last):
>>>   File "/home/root/test_rx.py", line 138, in 
>>> main()
>>>   File "/home/root/test_rx.py", line 127, in main
>>> tb = top_block_cls(args=options.args, freq=options.freq,
>>> gain=options.gain, rate=options.rate)
>>>   File "/home/root/test_rx.py", line 52, in __init__
>>> 1, -1
>>>   File "/usr/lib/python2.7/site-packages/ettus/ettus_swig.py", line
>>> 1980, in make
>>> return _ettus_swig.rfnoc_radio_make(*args, **kwargs)
>>> RuntimeError: Cannot find a block for ID: Radio_1
>>> -- Loading FPGA image: /boot/system_top.bit... done
>>>
>>>
>>> 2. Adding a FIFO to the FPGA on the second channel, and "dropping" the
>>> samples from the first channel.
>>>

Re: [USRP-users] E310 "subdev spec" equivalent in RFNoC?

[EJ Kreinar via USRP-users]

Thanks Tom, Quick update here...

I've found a set of options that will control the E300 receive channel
using rfnoc software:

rfnoc_rx_to_file --freq  --rate  --ant TX/RX
--radio-chan 0
rfnoc_rx_to_file --freq  --rate  --ant RX2
--radio-chan 0
rfnoc_rx_to_file --freq  --rate  --ant TX/RX
--radio-chan 1
rfnoc_rx_to_file --freq  --rate  --ant RX2
--radio-chan 1


Tracking where/how rfnoc_rx_to_file sets the appropriate channel, it
appears that it simply sets the "block_port" streamer args:

streamer_args["block_port"] = str(boost::format("%d") % radio_chan);


Or, alternatively, if there's a block inserted via the command line, then
the correct port is connected in the rx_graph:

rx_graph->connect(radio_ctrl_id, radio_chan,
blk_ctrl->get_block_id(), uhd::rfnoc::ANY_PORT);

Interestingly, this seems to suggest an approach closest to my "test 3"
earlier. I'll look for how this can tie into python rfnoc software now...


EJ


On Thu, Sep 21, 2017 at 4:24 PM, Tom Bereknyei <t...@dds.mil> wrote:

> EJ,
>
> I went through that same sequence of attempts and never got a solution
> other than using TX/RX and RX2 on the same A channel.
>
> On Thu, Sep 21, 2017 at 14:05 EJ Kreinar via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hi all,
>>
>> I'm trying to specify exactly which channel to record from an RFNoC
>> flowgraph on the E310, but I cant seem to get this to work
>>
>> Typically, in non-RFNoC applications, or in the "legacy_compat" mode, you
>> can use the following options:
>>
>> uhd_rx_cfile -r  -f  -A TX/RX --spec=A:A
>> recording.c32
>> uhd_rx_cfile -r  -f  -A RX2 --spec=A:A
>> recording.c32
>> uhd_rx_cfile -r  -f  -A TX/RX --spec=A:B
>> recording.c32
>> uhd_rx_cfile -r  -f  -A RX2 --spec=A:B
>> recording.c32
>>
>> And each option, in turn, records data from a different receive port on
>> the E310.
>>
>>
>> But, I cant figure out the correct combination to get the rfnoc_radio
>> software to support recording on channel B. A few things I've tried:
>>
>> 1. Changing the rfnoc_radio dropdown to "Radio Select = B". This errors
>> like this:
>>
>> Traceback (most recent call last):
>>   File "/home/root/test_rx.py", line 138, in 
>> main()
>>   File "/home/root/test_rx.py", line 127, in main
>> tb = top_block_cls(args=options.args, freq=options.freq,
>> gain=options.gain, rate=options.rate)
>>   File "/home/root/test_rx.py", line 52, in __init__
>> 1, -1
>>   File "/usr/lib/python2.7/site-packages/ettus/ettus_swig.py", line
>> 1980, in make
>> return _ettus_swig.rfnoc_radio_make(*args, **kwargs)
>> RuntimeError: Cannot find a block for ID: Radio_1
>> -- Loading FPGA image: /boot/system_top.bit... done
>>
>>
>> 2. Adding a FIFO to the FPGA on the second channel, and "dropping" the
>> samples from the first channel.
>> [image: Inline image 1]
>>
>> But this fails like so:
>>
>> -- [0/FIFO_0] source_node_ctrl::set_rx_streamer() 0 -> 1
>> -- [0/Radio_0] radio_ctrl_impl::set_rx_streamer() 1 -> 1
>> -- [0/Radio_0] e3xx_radio_ctrl_impl::_update_enables()
>> -- [0/Radio_0] e3xx_radio_ctrl_impl::_update_gpio_state()
>> -- [Device3] updating RX streamer to RX Terminator 0
>> --   New tick_rate == 25  New samp_rate == 25 New scaling ==
>> 3.05185e-05
>> -- [0/FIFO_0] source_block_ctrl_base::issue_stream_cmd()
>> -- [0/Radio_0] radio_ctrl_impl::issue_stream_cmd() 0 a
>> -- [0/Radio_0] radio_ctrl_impl::issue_stream_cmd() called on inactive
>> channel. Skipping.
>> timeout on chan 0
>> timeout on chan 0
>>
>> And no data is recorded.
>>
>> 3. I also tried (foolishly) manually editing the generated python to
>> connect the File Sink to port 1 of the rfnoc_radio, rather than port 0.
>>
>> I used this flowgraph:
>> [image: Inline image 3]
>> And then I manually changed the following lines:
>>
>> self.connect((self.uhd_rfnoc_streamer_radio_0, 0),
>> (self.blocks_file_sink_0_0, 0))
>> =becomes==>
>> self.connect((self.uhd_rfnoc_streamer_radio_0, 1),
>> (self.blocks_file_sink_0_0, 0))
>>
>> I was hopeful that port 1 actually existed and was initialized correctly
>> in UHD, but alas, port 1 clearly does not exist for me to attach the file
>> sink to:
>>
>> Traceback (most recent call last):
>>   File "/home/root/test_rx.py", line 138, in 
>> main()
>>   File "/home/root/test_rx.py", line 128, i

[USRP-users] E310 "subdev spec" equivalent in RFNoC?

[EJ Kreinar via USRP-users]

Hi all,

I'm trying to specify exactly which channel to record from an RFNoC
flowgraph on the E310, but I cant seem to get this to work

Typically, in non-RFNoC applications, or in the "legacy_compat" mode, you
can use the following options:

uhd_rx_cfile -r  -f  -A TX/RX --spec=A:A
recording.c32
uhd_rx_cfile -r  -f  -A RX2 --spec=A:A recording.c32
uhd_rx_cfile -r  -f  -A TX/RX --spec=A:B
recording.c32
uhd_rx_cfile -r  -f  -A RX2 --spec=A:B recording.c32

And each option, in turn, records data from a different receive port on the
E310.


But, I cant figure out the correct combination to get the rfnoc_radio
software to support recording on channel B. A few things I've tried:

1. Changing the rfnoc_radio dropdown to "Radio Select = B". This errors
like this:

Traceback (most recent call last):
  File "/home/root/test_rx.py", line 138, in 
main()
  File "/home/root/test_rx.py", line 127, in main
tb = top_block_cls(args=options.args, freq=options.freq,
gain=options.gain, rate=options.rate)
  File "/home/root/test_rx.py", line 52, in __init__
1, -1
  File "/usr/lib/python2.7/site-packages/ettus/ettus_swig.py", line 1980,
in make
return _ettus_swig.rfnoc_radio_make(*args, **kwargs)
RuntimeError: Cannot find a block for ID: Radio_1
-- Loading FPGA image: /boot/system_top.bit... done


2. Adding a FIFO to the FPGA on the second channel, and "dropping" the
samples from the first channel.
[image: Inline image 1]

But this fails like so:

-- [0/FIFO_0] source_node_ctrl::set_rx_streamer() 0 -> 1
-- [0/Radio_0] radio_ctrl_impl::set_rx_streamer() 1 -> 1
-- [0/Radio_0] e3xx_radio_ctrl_impl::_update_enables()
-- [0/Radio_0] e3xx_radio_ctrl_impl::_update_gpio_state()
-- [Device3] updating RX streamer to RX Terminator 0
--   New tick_rate == 25  New samp_rate == 25 New scaling ==
3.05185e-05
-- [0/FIFO_0] source_block_ctrl_base::issue_stream_cmd()
-- [0/Radio_0] radio_ctrl_impl::issue_stream_cmd() 0 a
-- [0/Radio_0] radio_ctrl_impl::issue_stream_cmd() called on inactive
channel. Skipping.
timeout on chan 0
timeout on chan 0

And no data is recorded.

3. I also tried (foolishly) manually editing the generated python to
connect the File Sink to port 1 of the rfnoc_radio, rather than port 0.

I used this flowgraph:
[image: Inline image 3]
And then I manually changed the following lines:

self.connect((self.uhd_rfnoc_streamer_radio_0, 0),
(self.blocks_file_sink_0_0, 0))
=becomes==>
self.connect((self.uhd_rfnoc_streamer_radio_0, 1),
(self.blocks_file_sink_0_0, 0))

I was hopeful that port 1 actually existed and was initialized correctly in
UHD, but alas, port 1 clearly does not exist for me to attach the file sink
to:

Traceback (most recent call last):
  File "/home/root/test_rx.py", line 138, in 
main()
  File "/home/root/test_rx.py", line 128, in main
tb.start()
  File "/usr/lib/python2.7/site-packages/gnuradio/gr/top_block.py", line
109, in start
top_block_start_unlocked(self._impl, max_noutput_items)
  File "/usr/lib/python2.7/site-packages/gnuradio/gr/runtime_swig.py", line
3671, in top_block_start_unlocked
return _runtime_swig.top_block_start_unlocked(*args, **kwargs)
RuntimeError: rfnoc_radio(1): missing connection from output port 0
-- Loading FPGA image: /boot/system_top.bit... done


I cant seem to figure this out.. Any suggestions?? Am I missing something
obvious, or is RFNoC missing this support?

(by the way, I am admittedly still behind on my UHD version. So perhaps
there's updates that resolve this issue recently?)

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

Re: [USRP-users] RFNoC: complex_vector support from reprogrammable embedded settings registers

[EJ Kreinar via USRP-users]

Ehh, I dont think that's an accurate description of what's going on...

Take a look at the 32-bit floating point definition:
https://en.wikipedia.org/wiki/Single-precision_floating-point_format  The
wikipedia definition seems to be essentially what's going on here, with the
added twist that the output is 16-bit fixed point, so there's some
shortcuts to get the datatypes to match.

Some quick thoughts... The sign bit specifies the sign of the value. The
8-bits pulled out into "shift_val" represents the exponent,  while the
remaining 24-bits are the mantissa (captured in "shift" -- you can see the
"shift" variable takes the round_fraction and right-shifts by the
shift_val). I expect the magic numbers in round_fraction and shift are due
to the 16-bit fixed point output, and you'd want to confirm the Q-style
format (# integer bits, # fractional bits)  is correct on the output.

You might be able to use this block to read convert a 32-bit floating point
register in the FPGA to your desired 16-bit fixed point, which could be a
fine solution. But if you're already programming taps, you definitely need
a C++ controller anyway, so I'd suggest doing the conversion there.

EJ

On Mon, Aug 14, 2017 at 4:06 PM, Andrew Lanez  wrote:

> Hi EJ,
>
> Thanks for the pointers. Ok, I think I see now that float_to_iq module is
> fixed point. Am I interpreting these lines of code correctly that put an
> 8-bit bound on the mantissa with a 2's complement sign bit, leaving the
> remaining 8-bits for radix:
>
>
> assign shift_val = (in[30:23] > 127)? (in[30:23] - 127): (127 - in[30:23]);
>
> ...
>
> wire [15:0] final_val = (in[31] == 1)?(~shift + 1'b1):shift;
>
>
> I've been pursuing this conversion from within my noc block but doing it
> in the block controller instead is looking more attractive.
>
> Thanks,
> Andrew
>
>
>
>
> On Mon, Aug 14, 2017 at 4:49 AM, EJ Kreinar  wrote:
>
>> Hi Andrew,
>>
>> As far as I can tell, that particular verilog block implements a 32-bit
>> floating point to 16-bit fixed point conversion. The name may be a misnomer
>> because it does not actually break the input into I/Q channels.
>>
>> For floating to fixed conversion in software, I usually refer to this
>> wikipedia page, which includes notation information and provides a
>> quick/easy conversion: https://en.wikipedia.org/wiki/Q_(number_format)
>>
>> Usually my rule of thumb is that if there's a plausible way to do
>> something in software, it's better to do it in software :D The C++ control
>> block driver is a good place to wrap some helper code (e.g., converting
>> taps, calculating magic numbers, etc etc) around your time-critical and
>> performance-intensive FPGA operations.
>>
>> EJ
>>
>> On Sun, Aug 13, 2017 at 7:30 AM, Andrew Lanez 
>> wrote:
>>
>>> EJ,
>>>
>>> I spent some time wrestling with the 32-bit to 16-bit conversion in my
>>> verilog noc block then realized doing the conversion in the C++ control
>>> block driver might be more straightforward. I'm trying to digest the
>>> following:
>>>
>>> https://raw.githubusercontent.com/EttusResearch/fpga/b108e88
>>> 865ee0fa68e685461681d8ca6a320b937/usrp3/lib/vita/float_to_iq.v
>>>
>>> I can't tell if that converter is fixed-point. I'm inclined to believe
>>> it's 16-bit compressed floating point. Do you or anyone have references to
>>> do an equivalent conversion in C++?
>>>
>>> Andrew
>>>
>>> On Thu, Aug 10, 2017 at 8:51 AM, EJ Kreinar  wrote:
>>>
 Hi Andrew,

 The OOT module .xml file definition currently only supports writing
 scalar registers, so you need a custom C++ driver. The int_vector option
 has not been implemented, and honestly I'm not sure if it would even make
 sense because there's many different ways the HDL could implement a
 "vector" of taps... it's not really a one-size-fits-all problem.

 My recommendation would be to model your hf_chlizer's C++ driver on the
 in-tree fir_block_ctrl_impl. Use the sr_write functions to program your
 taps as your HDL code requires.

 You'll notice fir_block_ctrl_impl uses integer taps. This ends up being
 a little clumsy when developing flowgraphs, since your flowgraph
 application needs to handle the floating point / fixed point conversion. In
 the past, I've created a C++ driver that accepts floating point inputs and
 converts to fixed point before programming to FPGA registers. Your
 preference.

 Hope this helps,
 EJ



 On Tue, Aug 8, 2017 at 6:00 AM, Andrew Lanez via USRP-users <
 usrp-users@lists.ettus.com> wrote:

> Typo, the 3rd to last paragraph should read:
>
> Or I could hack *rfnoc_fir_cci()*. I started this by replacing int
> vectors with std::complex vectors everywhere FIR taps were referenced in
> the in-tree module's C++ library but I stopped when it traced up to 
> block.h
> because that may affect 

Re: [USRP-users] RFNoC: complex_vector support from reprogrammable embedded settings registers

[EJ Kreinar via USRP-users]

Hi Andrew,

As far as I can tell, that particular verilog block implements a 32-bit
floating point to 16-bit fixed point conversion. The name may be a misnomer
because it does not actually break the input into I/Q channels.

For floating to fixed conversion in software, I usually refer to this
wikipedia page, which includes notation information and provides a
quick/easy conversion: https://en.wikipedia.org/wiki/Q_(number_format)

Usually my rule of thumb is that if there's a plausible way to do something
in software, it's better to do it in software :D The C++ control block
driver is a good place to wrap some helper code (e.g., converting taps,
calculating magic numbers, etc etc) around your time-critical and
performance-intensive FPGA operations.

EJ

On Sun, Aug 13, 2017 at 7:30 AM, Andrew Lanez  wrote:

> EJ,
>
> I spent some time wrestling with the 32-bit to 16-bit conversion in my
> verilog noc block then realized doing the conversion in the C++ control
> block driver might be more straightforward. I'm trying to digest the
> following:
>
> https://raw.githubusercontent.com/EttusResearch/fpga/b108e88
> 865ee0fa68e685461681d8ca6a320b937/usrp3/lib/vita/float_to_iq.v
>
> I can't tell if that converter is fixed-point. I'm inclined to believe
> it's 16-bit compressed floating point. Do you or anyone have references to
> do an equivalent conversion in C++?
>
> Andrew
>
> On Thu, Aug 10, 2017 at 8:51 AM, EJ Kreinar  wrote:
>
>> Hi Andrew,
>>
>> The OOT module .xml file definition currently only supports writing
>> scalar registers, so you need a custom C++ driver. The int_vector option
>> has not been implemented, and honestly I'm not sure if it would even make
>> sense because there's many different ways the HDL could implement a
>> "vector" of taps... it's not really a one-size-fits-all problem.
>>
>> My recommendation would be to model your hf_chlizer's C++ driver on the
>> in-tree fir_block_ctrl_impl. Use the sr_write functions to program your
>> taps as your HDL code requires.
>>
>> You'll notice fir_block_ctrl_impl uses integer taps. This ends up being a
>> little clumsy when developing flowgraphs, since your flowgraph application
>> needs to handle the floating point / fixed point conversion. In the past,
>> I've created a C++ driver that accepts floating point inputs and converts
>> to fixed point before programming to FPGA registers. Your preference.
>>
>> Hope this helps,
>> EJ
>>
>>
>>
>> On Tue, Aug 8, 2017 at 6:00 AM, Andrew Lanez via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Typo, the 3rd to last paragraph should read:
>>>
>>> Or I could hack *rfnoc_fir_cci()*. I started this by replacing int
>>> vectors with std::complex vectors everywhere FIR taps were referenced in
>>> the in-tree module's C++ library but I stopped when it traced up to block.h
>>> because that may affect other modules.
>>>
>>> On Tue, Aug 8, 2017 at 2:56 AM, Andrew Lanez 
>>> wrote:
>>>
 Hi,

 I am developing a FIR filter that will eventually accepts complex taps
 reprogrammable during runtime. As a first iteration, I want to verify it
 works like the in-tree module with int_vector real taps. So I configure the
 settings register in OOT module's .xml file to take int_vector taps but
 running it returns:
 RuntimeError: RuntimeError: not yet implemented: int_vector

 I guess it's because the in-tree module's ettus.rfnoc_fir_cci() make
 function supports int_vector whereas my rfnocmodtool generated make
 function hf_chlizer.fir() does not.

 So I changed my OOT module's .xml to use ettus.rfnoc_fir_cci() instead
 of hf_chlizer.fir() and output shows both I and Q samples are filtered
 identically by real taps.

 But ettus.rfnoc_fir_cci() does not seem to support complex_vector taps.
 So I must revert to hf_chlizer.fir() in which case I get:
 RuntimeError: RuntimeError: Invalid block definition in
 /home/switchlanez/rfnoc/share/uhd/rfnoc/blocks/fir.xml: RuntimeError:
 Found invalid arguments for block fir.

 Or I could hack hf_chlizer.fir(). I started this by replacing int
 vectors with std::complex vectors everywhere FIR taps were referenced in
 the in-tree module's C++ library but I stopped when it traced up to block.h
 because that may affect other modules.

 1) What's the best approach to implement a vector of complex taps
 reprogrammable during runtime?

 2) My verilog code assumes one complex tap is 32 bits (leftmost 16 bits
 for I, rightmost 16 bits for Q) and formats complex samples the same
 (in-tree module also handles complex sample this way). Will UHD
 automatically convert complex floats incoming from the host to sc16 for the
 embedded settings registers?

 Thanks,
 Andrew

>>>
>>>
>>> ___
>>> USRP-users mailing list
>>> 

Re: [USRP-users] FPGA Build problem

[EJ Kreinar via USRP-users]

Hi Nauman,

I'm guessing you're building FPGA for the X300 series.. Typically this is a
problem with setting the environment correctly.

In the build directory (uhd-fpga/usrp3/top/x300), first run "source
setupenv.sh". This calls uhd-fpga/usrp3/tools/scripts/setupenv_base.sh,
which populates the FPGA part types in your environment.

Hope this helps,
EJ

On Wed, Aug 2, 2017 at 6:45 AM, Nauman Iqbal via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi,
>
>I am getting this error while I am trying to build the project from
> makefile. I have vivado paths already set.
>
>
>
> source /home/workspace/fpga/usrp3/tools/scripts/viv_generate_ip.tcl
>
> # set xci_file $::env(XCI_FILE)   ;
>
> # set part_name$::env(PART_NAME)  ;
>
> # set gen_example_proj $::env(GEN_EXAMPLE);
>
> # set synth_ip $::env(SYNTH_IP)   ;
>
> # set ip_name [file rootname [file tail $xci_file]]   ;
>
> # file delete -force "$xci_file.out"
>
> # create_project -part $part_name -in_memory -ip
>
> WARNING: [#UNDEF] No parts matched ''
>
> ERROR: [Coretcl 2-106] Specified part could not be found.
>
>
>
> Regards
>
>
>
> Nauman
>
> ___
> 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