[Discuss-gnuradio] How do I use arguments outside of functions

[Ashley Neboschick]

I am trying to create an io signature with multiple inputs greater than 3
using makev.  in order to do this, I learned to do it according to the code
below.  My issue is that I need to derive the input sizes from the input
arguments but I don't know how I would do that.  I imagine using a separate
function but I am just learning objects and do not know how I would word it
specifically for gnuradio. An example would be extremely helpful. Any help
much appreciated.


//static int ios[] = {sizeof(gr_complex)*nAz*M, sizeof(gr_complex)*M*M,
sizeof(gr_complex)*M*L, sizeof(float)}; //but I want to get this line to
work instead
static int ios[] = {sizeof(gr_complex)*121*4, sizeof(gr_complex)*4*4,
sizeof(gr_complex)*4*128, sizeof(float)}; //this line already works...^^^
static std::vector iosig(ios, ios+sizeof(ios)/sizeof(int));

/*
 * The private constructor
 */
MVDR_impl::MVDR_impl(int L, int M, int nAz, float InitialLook)
  : gr::sync_block("MVDR",
gr::io_signature::makev(4, 4, iosig),
//gr::io_signature::makev(4, 4, sizeof(gr_complex)*nAz*M,
sizeof(gr_complex)*M*M, sizeof(gr_complex)*M*L, sizeof(float) ),
//steering vectors (all), covariance matrix (RXX),look direction
(LookDir), origional MxL IQ Data matrix

gr::io_signature::make(1, 1, sizeof(gr_complex)*L)), //"steered"
data
d_L(L),
d_M(M),
d_nAz(nAz),
d_InitialLook(InitialLook) //not used currently
{}
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] OS X Sierra complete build

[Gregory Ratcliff]

Just following up to help others in the future.
Over the years, when I try to get gnuradio on a new platform, I’ve always 
wanted a “just tell me what worked”, so I can start there.

3.7.10 works well with QT blocks on OS X Sierra on MacBook Pro 15 (December, 
2016)
Using Python 2.7.10
Using Xcode 8.1 (8B62)
Using Mac port 11-2016 works
Using XQuartz 2.7.11

Michael, your suggestion to remove and reinstall doxygen followed by gnuradio 
worked perfectly.
Also used the USRP utility on Mac to flash update a n210.  Well done.

Used the status youtube video tutorial to create a wide band fm receiver which 
worked perfectly:
How To Build an FM Receiver with the USRP in Less Than 10 Minutes … 



Greg


> On Dec 6, 2016, at 8:53 PM, Michael Dickens  wrote:
> 
> Hi Greg - What usually works is the following:
> {{{
> sudo port clean doxygen 
> sudo port install doxygen 
> sudo port clean gnuradio 
> sudo port install gnuradio
> }}}
> If that fails, email me off-list & I'll help debug. - MLD
> 
> On Tue, Dec 6, 2016, at 01:43 PM, Gregory Ratcliff wrote:
>> Just following instructions here: 
>> http://gnuradio.org/redmine/projects/gnuradio/wiki/MacInstall 
>>  precisely 
>> for the first time with a new Mac.
>> 
>> Xcode went well
>> XQuartz went well
>> Command line tools went well
>> 
>> 
>> 
>> sudo port install gnuradio
>> … lots of lines of success
>> 
>> Then end the end 
>> 
>> --->  Fetching archive for doxygen
>> --->  Attempting to fetch doxygen-1.8.10_2.darwin_16.x86_64.tbz2 from 
>> https://packages.macports.org/doxygen 
>> --->  Attempting to fetch doxygen-1.8.10_2.darwin_16.x86_64.tbz2 from 
>> http://sea.us.packages.macports.org/macports/packages/doxygen 
>> 
>> --->  Attempting to fetch doxygen-1.8.10_2.darwin_16.x86_64.tbz2 from 
>> http://mse.uk.packages.macports.org/sites/packages.macports.org/doxygen 
>> 
>> --->  Fetching distfiles for doxygen
>> --->  Attempting to fetch doxygen-1.8.10.src.tar.gz from 
>> https://distfiles.macports.org/doxygen 
>> 
>> --->  Verifying checksums for doxygen
>>
>> --->  Extracting doxygen
>> --->  Applying patches to doxygen
>> --->  Configuring doxygen
>> --->  Building doxygen
>> Error: org.macports.build for port doxygen returned: command execution failed
>> 
>> 
>> Has anyone else encountered oxygen build issues?
> 

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] PMT Oddities

[Dave NotTelling]

Thoughts?

On Mon, Dec 5, 2016 at 4:56 PM, Dave NotTelling  wrote:

> Marcus & Martin:
>
>  I tried the dict_keys() method of checking, but even that can fail.
> Here is an example:
>
> [code]
>
> import pmt
>
> d = pmt.make_dict()
> d = pmt.dict_add(d, pmt.intern('a'), pmt.intern('a'))
> d = pmt.dict_add(d, pmt.intern('b'), pmt.intern('b'))
> d = pmt.dict_add(d, pmt.intern('c'), pmt.intern('c'))
>
> a = pmt.cons(d, pmt.make_u8vector(10, 10))
>
> print pmt.dict_keys(a)
>
> [/code]
>
> You end up with: ((c . c))
>
> The dict_keys() method will bomb if there are no elements in the
> dictionary:
>
> print pmt.dict_keys(pmt.cons(pmt.make_dict(), pmt.make_u8vector(10, 10)))
>
>
> On Tue, Nov 22, 2016 at 5:55 PM, Dave NotTelling 
> wrote:
>
>> Thanks for the explanation!
>>
>> On Tue, Nov 22, 2016 at 5:29 PM, Marcus Müller 
>> wrote:
>>
>>> That's a long story. Essentially, a list is a pair of the first element
>>> and a pair of a second element and a pair of the third element and a pair
>>> of …
>>>
>>> Cheers,
>>> Marcus
>>>
>>> On 22.11.2016 23:18, Dave NotTelling wrote:
>>>
>>> I ask because it feels like a bug.  Things like ((a . b), (c . d), (e .
>>> f)) are definitely not pairs (assuming a pair is 2 elements) and (in my
>>> opinion) should not return true for pmt.is_pair().
>>>
>>> On Tue, Nov 22, 2016 at 5:12 PM, Dave NotTelling 
>>> wrote:
>>>
 Martin,

  Was that done on purpose?

  Thank you for the link!  I hadn't thought about checking that way.

 Thanks!

 -Dave

 On Tue, Nov 22, 2016 at 5:08 PM, Martin Braun 
 wrote:

> Dave,
>
> pairs pass is_dict(), which is possibly the root cause here. See also:
> https://github.com/gnuradio/gnuradio/blob/31b28f0cf4694378b2
> 6617616d08b4082668962f/gr-uhd/lib/usrp_block_impl.cc#L487-L494
>
> Cheers,
> M
>
> On 11/22/2016 01:47 PM, Dave NotTelling wrote:
> > I noticed today that the is_dict and is_pair checks are not
> appearing to
> > work properly.  Here is an example that shows the issue:
> >
> > [code]
> >
> > #!/usr/bin/python
> >
> > import pmt
> >
> > def print_pmt(dictVar):
> > print 'isPair:%05s, isDict:%05s, isTuple:%05s  =>  %s' %
> > (pmt.is_pair(dictVar), pmt.is_dict(dictVar), pmt.is_tuple(dictVar),
> dictVar)
> >
> > print 'DICT'
> >
> > d = pmt.make_dict()
> > print_pmt(d)
> >
> > d = pmt.dict_add(d, pmt.intern('a'), pmt.intern('b'))
> > print_pmt(d)
> >
> > d = pmt.dict_add(d, pmt.intern('c'), pmt.intern('d'))
> > print_pmt(d)
> >
> > d = pmt.dict_add(d, pmt.intern('e'), pmt.intern('f'))
> > print_pmt(d)
> >
> > print '\nCONS'
> >
> > p = pmt.cons(pmt.make_dict(), pmt.make_u8vector(0,0))
> > print_pmt(p)
> >
> > [/code]
> >
> > Run that and you'll see what I consider strange behavior.  The
> values of
> > is_pair and is_dict to not match what is expected.  Is that by
> design?
> > If so, why?
> >
> > ((a . b)) is not a pair...  It's a single element dictionary
> > ((c . d) (a . b)) i can sorta see this being a pair, but it wasn't
> > created that way
> > ((e . f) (c . d) (a . b)) definitely not a pair as it's 3 elements
> >
> > (() . #[]) don't dictionaries have to be nested?
> >
> >
> > Thanks!
> >
> >
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>


>>>
>>>
>>> ___
>>> Discuss-gnuradio mailing 
>>> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>>
>>>
>>> ___
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>>
>>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Feature request: add max-length to vector_sink

[Eugene Grayver]

Adding a maximum length for a vector sink will make it easier to use for 
'realtime' QA code.  Minor change required.




Eugene Grayver, Ph.D.
Aerospace Corp., Sr. Eng. Spec.
Tel: 310.336.1274

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] gr-ieee 802.11 and integration with linux stack (wpa_supplicant)

[Manolis Surligas]

Hi Bastian,

back then I tried to published it under GPL but the legal department of 
my institution did not like it.. Perhaps now, after 2 years I 
can give a try again :)


Anw, if some of you need more info on this I will be glad to help.

Cheers!

On 12/06/2016 01:47 PM, Bastian Bloessl wrote:

Hi,

On 12/06/2016 12:35 PM, Manolis Surligas wrote:

Hi all,

we have done it two years ago as part of my master thesis and it works
like a charm! The SDR IEEE 802.11 implementation can be configured as AP
using hostapd or adhoc via the network manager. We had some problems
making it work as a normal client however.

Our approach has a kernel module that provides an interface for
receiving and sending PDUs from/to SDR PHY. Internally, the kernel
module communicates with the mac80211 for passing around these PDUs.



wow that sounds cool. Would it be possible to share the code? I would 
love to give this a try.


Best,
Bastian





On 12/06/2016 06:21 AM, Bastian Bloessl wrote:

Hi,


On 5 Dec 2016, at 21:10, sumitstop mailto:sumit.ku...@research.iiit.ac.in>> wrote:

Has anyone tried integration of gr-ieee 802.11 with Linux stack
(wpa_supplicant)?




I guess no, but since it doesn’t have a standard compliant MAC layer
that might be of limited benefit.

If you really want to look into integrating it in Linux, I would
implement it as virtual WiFi device, similar to hwsim
(https://wireless.wiki.kernel.org/en/users/drivers/mac80211_hwsim).
Then the higher layer stuff like hostap and wpa_supplicant would just
work out of the box.

Best,
Bastian


--
/* Code is the Law! */


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Decoding speed of the FECs in GR

[hanwen]

Dear Johannes,

Very interesting work! I'll read it through. Many thanks.

BR, Hanwen


-- Forwarded message --
From: Johannes Demel 
Date: 2016-12-07 14:17 GMT+01:00
Subject: Re: [Discuss-gnuradio] Decoding speed of the FECs in GR
To: "discuss-gnuradio@gnu.org" 


Hey Hanwen,

in my master thesis [0] I did some benchmarks for polar codes and there
should be one benchmark for LDPC codes. All benchmarks use the GNU Radio
implementation.

[0] https://github.com/jdemel/socis-2015-gr-results


On 07.12.2016 00:52, hanwen wrote:

> Dear all,
>
> I just want to know is there any benchmark results of the decoding speed
> of the various FEC decoder in GR: CC, turbo, LDPC and polar. How much
> Mbps can be achieved for these FECs respectively.
>
> Thanks in advance.
>
> Br, Hanwen
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] [USRP-users] Bug in GPS time reported by the USRP

[Michael West]

Hi Eugene,

The sensor returns a time_t value, which is based on the Unix epoch.  Your
application can translate that value however it needs.  You can also get
the GPRMC NMEA string by calling USRP.get_mboard_sensor('gps_gprmc') and
get the raw value from that if necessary.

Regards,
Michael

On Tue, Dec 6, 2016 at 6:25 PM, Dan CaJacob via USRP-users <
usrp-us...@lists.ettus.com> wrote:

> Hi Eugene,
>
> Please check that time stamp here: http://www.unixtimestamp.com/index.php
> It looks alright to me.  It *is* reporting the correct time in a unix
> timestamp format.  Maybe you are making a more subtle point about
> nomenclature?  As in the GPS epoch is not the same as the Unix timestamp
> epoch  in 1970?  In any event, a unix time stamp is fairly common,
> unambiguous way to specify a time.
>
> Thanks,
>
> Dan
>
> On Tue, Dec 6, 2016 at 8:19 PM Eugene Grayver 
> wrote:
>
>> This is being posted to both GR and Ettus forums because both groups
>> should be aware.
>>
>>
>> The value returned by  USRP.get_mboard_sensor('gps_time') is incorrect.
>> It is NOT the GPS epoch, but is time relative to the UNIX epoch.  Only off
>> by a decade or so...
>>
>>
>> 'GPS epoch time: 1481073287 seconds'
>>
>>
>>
>> 
>>
>> Eugene Grayver, Ph.D.
>> Aerospace Corp., Sr. Eng. Spec.
>> Tel: 310.336.1274 <(310)%20336-1274>
>> 
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
> --
> Very Respectfully,
>
> Dan CaJacob
>
> ___
> USRP-users mailing list
> usrp-us...@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Segfault with volk_32fc_32f_dot_prod_32fc_a_avx

[Andy Walls]

On Wed, 2016-12-07 at 12:10 -0500, Andy Walls wrote:

> > From GDB I can see
> > 
> > 
> > d_filtnum = 0
> > count = -67108696
> > d_out_idx = 0
> > 
> 
> This is a garbage-in, garbage-out problem I've seen exactly before with
> other blocks and the PFB clock sync block.
> 
> 1. Check to make sure that your filter taps don't trace out a function
> that has discontinuities or flat spots (i.e. a square pulse), and the
> PFB clock sync algorithms can't handle that.

typo:  ... *as* the PFB clock sync algorithms can't handle that.

> 2. Add a tag_debug block before the PFB clock_sync and look for time_est
> tags with values outside the range [0.0, 1.0).
> 
> -Andy



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Segfault with volk_32fc_32f_dot_prod_32fc_a_avx

[West, Nathan]

Typo in there count can never be less than 0.

The other thing that I think makes sense is that we might need some history
to scroll back to, but I don't think it's necessarily bounded how much
history... Are you using an upstream block that provides time_est tags?
Also, what parameters are you providing to the clock sync? number of
filters/filter size is the most interesting parameter here, but others
might be useful too.

Nathan

On Wed, Dec 7, 2016 at 12:00 PM, West, Nathan 
wrote:

> Some sanity appears!
>
> From what I can tell, count is keeping track of how many input samples
> have been processed, which can never be 0. My proposed fix would be to
> clamp count to 0 somewhere after line 462, but it would be nice for someone
> to confirm this makes sense.
>
> Nathan
>
> On Wed, Dec 7, 2016 at 10:18 AM, devin kelly  wrote:
>
>> I rebuilt GR with CMAKE_BUILD_TYPE=Debug.  The al and ar vairables got
>> optimized out, what's the compiler option to prevent that?
>>
>> I think I've found part of the problem:
>>
>> Looking here (on frame 2 in gdb):
>>
>> https://github.com/gnuradio/gnuradio/blob/master/gr-digital/
>> lib/pfb_clock_sync_ccf_impl.cc#L465
>>
>> This is the line where filter is called (which is where the segfault
>> occurs):
>>
>> d_filters[d_filtnum]->filter(&in[count+d_out_idx])
>>
>> From GDB I can see
>>
>> d_filtnum = 0
>> count = -67108696
>> d_out_idx = 0
>>
>> (gdb) bt
>> #0  0x7fedd163e77f in volk_32fc_32f_dot_prod_32fc_generic
>> (result=0x539eb40, input=0x7fed94b925a0, taps=0x53bb9a0, num_points=45) at
>> /local_disk/spectrum_challenge_src/volk/kernels/volk/volk_
>> 32fc_32f_dot_prod_32fc.h:83
>> #1  0x7fedbdedcc3f in gr::filter::kernel::fir_filter
>> _ccf::filter(std::complex const*) (this=0x53af290,
>> input=input@entry=0x7fed94b925a0) at /local_disk/spectrum_challenge
>> _src/gnuradio/gr-filter/lib/fir_filter.cc:232
>> #2  0x7fedbe22e041 in 
>> gr::digital::pfb_clock_sync_ccf_impl::general_work(int,
>> std::vector >&, std::vector> std::allocator >&, std::vector
>> >&) (this=
>> 0x53a1800, noutput_items=256, ninput_items=..., input_items=...,
>> output_items=std::vector of length 1, capacity 1 = {...})
>> at /local_disk/spectrum_challenge_src/gnuradio/gr-digital/lib/
>> pfb_clock_sync_ccf_impl.cc:465
>> #3  0x7fedd1bbdd17 in gr::block_executor::run_one_iteration()
>> (this=this@entry=0x7fedafffedb0)
>> at /local_disk/spectrum_challenge_src/gnuradio/gnuradio-
>> runtime/lib/block_executor.cc:451
>> #4  0x7fedd1bfc6aa in gr::tpb_thread_body::tpb_threa
>> d_body(boost::shared_ptr, int) (this=0x7fedafffedb0,
>> block=..., max_noutput_items=)
>> at /local_disk/spectrum_challenge_src/gnuradio/gnuradio-
>> runtime/lib/tpb_thread_body.cc:122
>> #5  0x7fedd1bf0ed1 in boost::detail::function::void_
>> function_obj_invoker0,
>> void>::invoke(boost::detail::function::function_buffer&)
>> (this=0x53ddc90, this=)
>> at /local_disk/spectrum_challenge_src/gnuradio/gnuradio-
>> runtime/lib/scheduler_tpb.cc:44
>> #6  0x7fedd1bf0ed1 in boost::detail::function::void_
>> function_obj_invoker0,
>> void>::invoke(boost::detail::function::function_buffer&) (this=0x53ddc90)
>> at /local_disk/spectrum_challenge_src/gnuradio/gnuradio-
>> runtime/include/gnuradio/thread/thread_body_wrapper.h:51
>> #7  0x7fedd1bf0ed1 in boost::detail::function::void_
>> function_obj_invoker0,
>> void>::invoke(boost::detail::function::function_buffer&)
>> (function_obj_ptr=...)
>> at /usr/include/boost/function/function_template.hpp:153
>> #8  0x7fedd1ba5050 in boost::detail::thread_data
>> >::run() (this=)
>> at /usr/include/boost/function/function_template.hpp:767
>> #9  0x7fedd1ba5050 in boost::detail::thread_data
>> >::run() (this=)
>> at /usr/include/boost/thread/detail/thread.hpp:117
>> #10 0x7fedd06a527a in thread_proxy () at
>> /lib64/libboost_thread-mt.so.1.53.0
>> #11 0x7fedec395dc5 in start_thread () at /lib64/libpthread.so.0
>> #12 0x7fedeb9bb73d in clone () at /lib64/libc.so.6
>> (gdb) f 1
>> #1  0x7fedbdedcc3f in gr::filter::kernel::fir_filter_ccf::filter
>> (this=0x53af290, input=input@entry=0x7fed94b925a0)
>> at /local_disk/spectrum_challenge_src/gnuradio/gr-filter/lib/
>> fir_filter.cc:232
>> 232   (d_ntaps+al));
>> (gdb) info locals
>> ar = 
>> al = 
>> (gdb) print d_ntaps
>> $1 = 45
>> (gdb) print al
>> $2 = 
>> (gdb) print d_aligned_taps[al]
>> value has been optimized out
>> (gdb) print d_aligned_taps[0]
>>
>>
>>
>> $3 = (float *) 0x53bb9a0
>> (gdb) print d_aligned_taps[1]
>>
>>
>>
>> $4 = (float *) 0x53bbac0
>> (gdb) print input
>> $5 = (const gr_complex *) 0x7fed94b925a0
>> (gdb) print *input
>> Cannot access memory at address 0x7fed94b925a0
>> (gdb) print real(*input)
>> No symbol "real" in current context.
>> (gdb) print ar
>> $6 = 
>>
>> (gdb) f 2
>> #2  0x7fedbe22e041 in gr::digital::pfb_clock_sync_ccf_impl::general_work
>> (this=0x53a1800, noutput_items=256,
>>

Re: [Discuss-gnuradio] Segfault with volk_32fc_32f_dot_prod_32fc_a_avx

[Andy Walls]

>  From: 
> devin kelly
>   Subject: 
> Re: [Discuss-gnuradio] Segfault
> with
> volk_32fc_32f_dot_prod_32fc_a_avx
>  Date: 
> Wed, 7 Dec 2016 10:18:32 -0500
> 
> __


> I think I've found part of the problem:
> 
> 
> Looking here (on frame 2 in gdb):
> 
> https://github.com/gnuradio/gnuradio/blob/master/gr-digital/lib/pfb_clock_sync_ccf_impl.cc#L465
> 
> 
> 
> This is the line where filter is called (which is where the segfault
> occurs):
> 
> 
> d_filters[d_filtnum]->filter(&in[count+d_out_idx])
> 
> 
> From GDB I can see
> 
> 
> d_filtnum = 0
> count = -67108696
> d_out_idx = 0
> 

This is a garbage-in, garbage-out problem I've seen exactly before with
other blocks and the PFB clock sync block.

1. Check to make sure that your filter taps don't trace out a function
that has discontinuities or flat spots (i.e. a square pulse), and the
PFB clock sync algorithms can't handle that.

2. Add a tag_debug block before the PFB clock_sync and look for time_est
tags with values outside the range [0.0, 1.0).

-Andy


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Segfault with volk_32fc_32f_dot_prod_32fc_a_avx

[West, Nathan]

Some sanity appears!

>From what I can tell, count is keeping track of how many input samples have
been processed, which can never be 0. My proposed fix would be to clamp
count to 0 somewhere after line 462, but it would be nice for someone to
confirm this makes sense.

Nathan

On Wed, Dec 7, 2016 at 10:18 AM, devin kelly  wrote:

> I rebuilt GR with CMAKE_BUILD_TYPE=Debug.  The al and ar vairables got
> optimized out, what's the compiler option to prevent that?
>
> I think I've found part of the problem:
>
> Looking here (on frame 2 in gdb):
>
> https://github.com/gnuradio/gnuradio/blob/master/gr-
> digital/lib/pfb_clock_sync_ccf_impl.cc#L465
>
> This is the line where filter is called (which is where the segfault
> occurs):
>
> d_filters[d_filtnum]->filter(&in[count+d_out_idx])
>
> From GDB I can see
>
> d_filtnum = 0
> count = -67108696
> d_out_idx = 0
>
> (gdb) bt
> #0  0x7fedd163e77f in volk_32fc_32f_dot_prod_32fc_generic
> (result=0x539eb40, input=0x7fed94b925a0, taps=0x53bb9a0, num_points=45) at
> /local_disk/spectrum_challenge_src/volk/kernels/
> volk/volk_32fc_32f_dot_prod_32fc.h:83
> #1  0x7fedbdedcc3f in 
> gr::filter::kernel::fir_filter_ccf::filter(std::complex
> const*) (this=0x53af290, input=input@entry=0x7fed94b925a0) at
> /local_disk/spectrum_challenge_src/gnuradio/gr-
> filter/lib/fir_filter.cc:232
> #2  0x7fedbe22e041 in 
> gr::digital::pfb_clock_sync_ccf_impl::general_work(int,
> std::vector >&, std::vector std::allocator >&, std::vector
> >&) (this=
> 0x53a1800, noutput_items=256, ninput_items=..., input_items=...,
> output_items=std::vector of length 1, capacity 1 = {...})
> at /local_disk/spectrum_challenge_src/gnuradio/gr-
> digital/lib/pfb_clock_sync_ccf_impl.cc:465
> #3  0x7fedd1bbdd17 in gr::block_executor::run_one_iteration()
> (this=this@entry=0x7fedafffedb0)
> at /local_disk/spectrum_challenge_src/gnuradio/
> gnuradio-runtime/lib/block_executor.cc:451
> #4  0x7fedd1bfc6aa in gr::tpb_thread_body::tpb_
> thread_body(boost::shared_ptr, int) (this=0x7fedafffedb0,
> block=..., max_noutput_items=)
> at /local_disk/spectrum_challenge_src/gnuradio/
> gnuradio-runtime/lib/tpb_thread_body.cc:122
> #5  0x7fedd1bf0ed1 in boost::detail::function::void_
> function_obj_invoker0,
> void>::invoke(boost::detail::function::function_buffer&) (this=0x53ddc90,
> this=)
> at /local_disk/spectrum_challenge_src/gnuradio/gnuradio-runtime/lib/
> scheduler_tpb.cc:44
> #6  0x7fedd1bf0ed1 in boost::detail::function::void_
> function_obj_invoker0,
> void>::invoke(boost::detail::function::function_buffer&) (this=0x53ddc90)
> at /local_disk/spectrum_challenge_src/gnuradio/
> gnuradio-runtime/include/gnuradio/thread/thread_body_wrapper.h:51
> #7  0x7fedd1bf0ed1 in boost::detail::function::void_
> function_obj_invoker0,
> void>::invoke(boost::detail::function::function_buffer&)
> (function_obj_ptr=...)
> at /usr/include/boost/function/function_template.hpp:153
> #8  0x7fedd1ba5050 in boost::detail::thread_data
> >::run() (this=)
> at /usr/include/boost/function/function_template.hpp:767
> #9  0x7fedd1ba5050 in boost::detail::thread_data
> >::run() (this=)
> at /usr/include/boost/thread/detail/thread.hpp:117
> #10 0x7fedd06a527a in thread_proxy () at /lib64/libboost_thread-mt.so.
> 1.53.0
> #11 0x7fedec395dc5 in start_thread () at /lib64/libpthread.so.0
> #12 0x7fedeb9bb73d in clone () at /lib64/libc.so.6
> (gdb) f 1
> #1  0x7fedbdedcc3f in gr::filter::kernel::fir_filter_ccf::filter
> (this=0x53af290, input=input@entry=0x7fed94b925a0)
> at /local_disk/spectrum_challenge_src/gnuradio/gr-
> filter/lib/fir_filter.cc:232
> 232   (d_ntaps+al));
> (gdb) info locals
> ar = 
> al = 
> (gdb) print d_ntaps
> $1 = 45
> (gdb) print al
> $2 = 
> (gdb) print d_aligned_taps[al]
> value has been optimized out
> (gdb) print d_aligned_taps[0]
>
>
>
> $3 = (float *) 0x53bb9a0
> (gdb) print d_aligned_taps[1]
>
>
>
> $4 = (float *) 0x53bbac0
> (gdb) print input
> $5 = (const gr_complex *) 0x7fed94b925a0
> (gdb) print *input
> Cannot access memory at address 0x7fed94b925a0
> (gdb) print real(*input)
> No symbol "real" in current context.
> (gdb) print ar
> $6 = 
>
> (gdb) f 2
> #2  0x7fedbe22e041 in gr::digital::pfb_clock_sync_ccf_impl::general_work
> (this=0x53a1800, noutput_items=256,
> ninput_items=..., input_items=..., output_items=std::vector of length
> 1, capacity 1 = {...})
> at /local_disk/spectrum_challenge_src/gnuradio/gr-
> digital/lib/pfb_clock_sync_ccf_impl.cc:465
> 465   out[i+d_out_idx] = d_filters[d_filtnum]->filter(&
> in[count+d_out_idx]);
> (gdb) print d_filtnum
> $7 = 0
> (gdb) print count
> $8 = -67108696
> (gdb) print d_out_idx
> $9 = 0
> (gdb) print in
> $10 = (gr_complex *) 0x7fedb4b92060
> (gdb) print count+d_out_idx
> $11 = -67108696
> (gdb) in[count+d_out_idx]
> Ambiguous command "in[count+d_out_idx]": .
> (gdb) print in[count+d_out_idx]
> Cannot acc

Re: [Discuss-gnuradio] Segfault with volk_32fc_32f_dot_prod_32fc_a_avx

[devin kelly]

I rebuilt GR with CMAKE_BUILD_TYPE=Debug.  The al and ar vairables got
optimized out, what's the compiler option to prevent that?

I think I've found part of the problem:

Looking here (on frame 2 in gdb):

https://github.com/gnuradio/gnuradio/blob/master/gr-digital/lib/pfb_clock_sync_ccf_impl.cc#L465

This is the line where filter is called (which is where the segfault
occurs):

d_filters[d_filtnum]->filter(&in[count+d_out_idx])

>From GDB I can see

d_filtnum = 0
count = -67108696
d_out_idx = 0

(gdb) bt
#0  0x7fedd163e77f in volk_32fc_32f_dot_prod_32fc_generic
(result=0x539eb40, input=0x7fed94b925a0, taps=0x53bb9a0, num_points=45) at
/local_disk/spectrum_challenge_src/volk/kernels/volk/volk_32fc_32f_dot_prod_32fc.h:83
#1  0x7fedbdedcc3f in
gr::filter::kernel::fir_filter_ccf::filter(std::complex const*)
(this=0x53af290, input=input@entry=0x7fed94b925a0) at
/local_disk/spectrum_challenge_src/gnuradio/gr-filter/lib/fir_filter.cc:232
#2  0x7fedbe22e041 in
gr::digital::pfb_clock_sync_ccf_impl::general_work(int, std::vector >&, std::vector >&, std::vector >&) (this=
0x53a1800, noutput_items=256, ninput_items=..., input_items=...,
output_items=std::vector of length 1, capacity 1 = {...})
at
/local_disk/spectrum_challenge_src/gnuradio/gr-digital/lib/pfb_clock_sync_ccf_impl.cc:465
#3  0x7fedd1bbdd17 in gr::block_executor::run_one_iteration()
(this=this@entry=0x7fedafffedb0)
at
/local_disk/spectrum_challenge_src/gnuradio/gnuradio-runtime/lib/block_executor.cc:451
#4  0x7fedd1bfc6aa in
gr::tpb_thread_body::tpb_thread_body(boost::shared_ptr, int)
(this=0x7fedafffedb0, block=..., max_noutput_items=)
at
/local_disk/spectrum_challenge_src/gnuradio/gnuradio-runtime/lib/tpb_thread_body.cc:122
#5  0x7fedd1bf0ed1 in
boost::detail::function::void_function_obj_invoker0,
void>::invoke(boost::detail::function::function_buffer&) (this=0x53ddc90,
this=)
at
/local_disk/spectrum_challenge_src/gnuradio/gnuradio-runtime/lib/scheduler_tpb.cc:44
#6  0x7fedd1bf0ed1 in
boost::detail::function::void_function_obj_invoker0,
void>::invoke(boost::detail::function::function_buffer&) (this=0x53ddc90)
at
/local_disk/spectrum_challenge_src/gnuradio/gnuradio-runtime/include/gnuradio/thread/thread_body_wrapper.h:51
#7  0x7fedd1bf0ed1 in
boost::detail::function::void_function_obj_invoker0,
void>::invoke(boost::detail::function::function_buffer&)
(function_obj_ptr=...)
at /usr/include/boost/function/function_template.hpp:153
#8  0x7fedd1ba5050 in boost::detail::thread_data
>::run() (this=)
at /usr/include/boost/function/function_template.hpp:767
#9  0x7fedd1ba5050 in boost::detail::thread_data
>::run() (this=)
at /usr/include/boost/thread/detail/thread.hpp:117
#10 0x7fedd06a527a in thread_proxy () at
/lib64/libboost_thread-mt.so.1.53.0
#11 0x7fedec395dc5 in start_thread () at /lib64/libpthread.so.0
#12 0x7fedeb9bb73d in clone () at /lib64/libc.so.6
(gdb) f 1
#1  0x7fedbdedcc3f in gr::filter::kernel::fir_filter_ccf::filter
(this=0x53af290, input=input@entry=0x7fed94b925a0)
at
/local_disk/spectrum_challenge_src/gnuradio/gr-filter/lib/fir_filter.cc:232
232   (d_ntaps+al));
(gdb) info locals
ar = 
al = 
(gdb) print d_ntaps
$1 = 45
(gdb) print al
$2 = 
(gdb) print d_aligned_taps[al]
value has been optimized out
(gdb) print
d_aligned_taps[0]

$3 = (float *) 0x53bb9a0
(gdb) print
d_aligned_taps[1]

$4 = (float *) 0x53bbac0
(gdb) print input
$5 = (const gr_complex *) 0x7fed94b925a0
(gdb) print *input
Cannot access memory at address 0x7fed94b925a0
(gdb) print real(*input)
No symbol "real" in current context.
(gdb) print ar
$6 = 

(gdb) f 2
#2  0x7fedbe22e041 in
gr::digital::pfb_clock_sync_ccf_impl::general_work (this=0x53a1800,
noutput_items=256,
ninput_items=..., input_items=..., output_items=std::vector of length
1, capacity 1 = {...})
at
/local_disk/spectrum_challenge_src/gnuradio/gr-digital/lib/pfb_clock_sync_ccf_impl.cc:465
465   out[i+d_out_idx] =
d_filters[d_filtnum]->filter(&in[count+d_out_idx]);
(gdb) print d_filtnum
$7 = 0
(gdb) print count
$8 = -67108696
(gdb) print d_out_idx
$9 = 0
(gdb) print in
$10 = (gr_complex *) 0x7fedb4b92060
(gdb) print count+d_out_idx
$11 = -67108696
(gdb) in[count+d_out_idx]
Ambiguous command "in[count+d_out_idx]": .
(gdb) print in[count+d_out_idx]
Cannot access memory at address 0x7fed94b925a0






On Tue, Dec 6, 2016 at 2:04 PM, Marcus Müller 
wrote:

> Hi,
> hm, you're right, the only way that can happen is if either the input or
> the tap pointers are invalid; strange.
>
> Since the line in question,
>  465   out[i+d_out_idx] = d_filters[d_filtnum]->filter(&
> in[count+d_out_idx]);
> in pfb_clock_sync_ccf.cc isn't all that suspicious, let's harass GDB for a
> moment.
>
> 1. since you're in stack frame #0 by default, can you see whether you can
> `print number` from the gdb shell? It's possible that GCC optimized that
> variable away, so try `print bP

Re: [Discuss-gnuradio] Decoding speed of the FECs in GR

[Johannes Demel]

Hey Hanwen,

in my master thesis [0] I did some benchmarks for polar codes and there 
should be one benchmark for LDPC codes. All benchmarks use the GNU Radio 
implementation.


[0] https://github.com/jdemel/socis-2015-gr-results

On 07.12.2016 00:52, hanwen wrote:

Dear all,

I just want to know is there any benchmark results of the decoding speed
of the various FEC decoder in GR: CC, turbo, LDPC and polar. How much
Mbps can be achieved for these FECs respectively.

Thanks in advance.

Br, Hanwen


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] polar code example in GRC

[Johannes Demel]

Hi Junxiao,

so, the tests for polar codes pass? But in GRC the examples won't run?

What does GRC report? I'm referring to the flowgraph error window.
Can you disable some blocks in GRC until it is executable? This might 
point us in the correct direction. Also, which example do you try?


Cheers
Johannes

On 07.12.2016 03:25, JX wrote:

Hi,

In GRC, I cann't run the polar code example. I found when I double click
the block of polar code  (any block of polar code), it just do nothing
and then I can't run GRC.
My GRC works well when I use the other modules. In another computer with
the different version of GNU Radio, I have the same problem.
When I run the test file in the build folder of GNU Radio, the qa test
programs of polar code work correctly.
I tested under GNU Radio Companion 3.7.10 and the last version from github.

Does anyone have the similar problem when running polar code example in GRC?

Thank you.
Junxiao







___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Add RFNoC FIFO

[Nicolas Cuervo]

Vishwesh,

 And to do that the only way is to write the corresponding
"noc_block_fir.v" and put it in the lib/rfnoc folder?
Yes.

you have to create the noc_block_fir if you haven't done that yet. What I
wrote with "USE_HLS" is how you tell the noc_block_addsub.v that he should
pick the HLS IP. I don't know the contents of your design, so I'm assuming
that you are writing the functionality of a FIR filter only (i.e., not
adding it into a CE). In fewer words, that is adding the functionality for
the block. What it is left to do is to add the block itself.

Note that you *don't* have to add that "USE_HLS" parameter to every block.
It is just the way the addsub block does it, because it can choose. It is
an example.

You can check any of the noc_block_* files, the boilerplate is more or less
the same, what is left to do is to instantiate your IP inside. Please check
the noc_block_skeleton, which you can use as a template to add your IP
inside under "USER IP". The rest of the CE is already written.

- N


On Wed, Dec 7, 2016 at 12:25 PM, Vishwesh Rege  wrote:

> Hi,
>
> "TL;DR: You are writing your IP (module) in HLS, but you need to put it
> into the Computation Engine to use the block in the RFNoC Framework"
>
> And to do that the only way is to write the corresponding
> "noc_block_fir.v" and put it in the lib/rfnoc folder?
>
> From what you wrote, I thought I could instantiate my block as
> noc_block_fir #(USE_HLS=1) inst_noc_block_fir (...);
> in rfnoc_ce_auto_inst_x310.v and bypass that step
> But that gave me a syntax error.
>
> So I guess I need to figure out how to write my own noc_block_fir.v
> If there indeed is an alternative easier way, let me know.
>
>
> Thanks,
> Vishwesh
>
>
>
>
> On Wed, Dec 7, 2016 at 3:07 AM, Nicolas Cuervo 
> wrote:
>
>> Hi Vishwesh,
>>
>> Please take a look at [1] which is not-that-new reference, but the idea
>> is still the same (this reference can be also found in the getting started
>> guide [2] which at the end has links to the videos of the presentation that
>> uses this slides). Specifically at slide 7. The noc_block_* is doing
>> several tasks, and for a start, regardless of the application, you'd focus
>> on the "user IP", which is the part that you are going to add and that will
>> perform your design task. In the case of addsub, clearly, it adds and
>> subtracts. You can check the addsub_hls to see that the functionality is
>> simple and rather obvious. Now this simple IP is inside the noc_block,
>> which sets registers, translates the AXI stream into chdr packets (AXI
>> wrapper) and prepares everything necessary for your block to be used in the
>> RFNoC framework, which is a huge task (Luckily, you dont have to worry much
>> about this for now). You can see that this is not to in HLS, but in
>> verilog.
>>
>> Your IP can be written in HLS, VHDL or verilog, but you need to put it
>> inside de noc_block; the whole is what we refer as Computation Engine (CE).
>>
>>  Currently the noc_block_addsub.v file has USE_HLS = 0. Does this
>> mean it isn't using the HLS sources?
>>
>> It is not doing so by default, but using the verilog sources (which in
>> this case are also provided). For the noc_block_addsub to use the HLS, the
>> parameter has to be set to true in the rfnoc_ce_auto_inst file at its
>> instantiation with something like:
>>
>> noc_block_addsub #( USE_HLS=1) inst_noc_block_addsub (...);
>>
>> You don't have to have this in every block if you are only using one type
>> of sources. You can base your design for the noc block file on the
>> rfnoc/lib/noc_block_skeleton.v, where the place where the user IP is to
>> be put is marked with comments.
>>
>> TL;DR: You are writing your IP (module) in HLS, but you need to put it
>> into the Computation Engine to use the block in the RFNoC Framework
>>
>> Cheers,
>> - N
>>
>>
>> [1] https://www.ettus.com/content/files/RFNoC_Wireless_at_VT_FPGA.pdf
>> [2] https://kb.ettus.com/Getting_Started_with_RFNoC_Development
>>
>> On Wed, Dec 7, 2016 at 11:47 AM, Vishwesh Rege 
>> wrote:
>>
>>> Hi,
>>>
>>> No I haven't added noc_block_fir.v file. Am I supposed to add it in
>>> lib/rfnoc folder along with other files such as noc_block_addsub.v? Also is
>>> there any guide on how to write this file?
>>>
>>> I didn't get your last line
>>> "and the way it uses to choose if the sources that it is going to use
>>> (either .v or hls) is done by the parameter "USE_HLS". In case you haven't
>>> done this, you may want to add the noc_block*, or maybe modify the
>>> noc_block_fir_filter.v to add the USE_HLS in there."
>>>
>>> Currently the noc_block_addsub.v file has USE_HLS = 0. Does this mean it
>>> isn't using the HLS sources?
>>>
>>> Just to clarify, I want to add my own custom 'fir' block written in HLS,
>>> I don't want to use the existing noc_block_fir_filter block.
>>>
>>> Appreciate your feedback
>>>
>>> Thanks,
>>> Vishwesh
>>>
>>>
>>>
>>> On Wed, Dec 7, 2016 at 2:29 AM, Nicolas Cuervo >> > wrote:
>>>
 HI Vishwesh,

Re: [Discuss-gnuradio] Add RFNoC FIFO

[Vishwesh Rege]

Hi,

"TL;DR: You are writing your IP (module) in HLS, but you need to put it
into the Computation Engine to use the block in the RFNoC Framework"

And to do that the only way is to write the corresponding "noc_block_fir.v"
and put it in the lib/rfnoc folder?

>From what you wrote, I thought I could instantiate my block as
noc_block_fir #(USE_HLS=1) inst_noc_block_fir (...);
in rfnoc_ce_auto_inst_x310.v and bypass that step
But that gave me a syntax error.

So I guess I need to figure out how to write my own noc_block_fir.v
If there indeed is an alternative easier way, let me know.


Thanks,
Vishwesh



On Wed, Dec 7, 2016 at 3:07 AM, Nicolas Cuervo 
wrote:

> Hi Vishwesh,
>
> Please take a look at [1] which is not-that-new reference, but the idea is
> still the same (this reference can be also found in the getting started
> guide [2] which at the end has links to the videos of the presentation that
> uses this slides). Specifically at slide 7. The noc_block_* is doing
> several tasks, and for a start, regardless of the application, you'd focus
> on the "user IP", which is the part that you are going to add and that will
> perform your design task. In the case of addsub, clearly, it adds and
> subtracts. You can check the addsub_hls to see that the functionality is
> simple and rather obvious. Now this simple IP is inside the noc_block,
> which sets registers, translates the AXI stream into chdr packets (AXI
> wrapper) and prepares everything necessary for your block to be used in the
> RFNoC framework, which is a huge task (Luckily, you dont have to worry much
> about this for now). You can see that this is not to in HLS, but in
> verilog.
>
> Your IP can be written in HLS, VHDL or verilog, but you need to put it
> inside de noc_block; the whole is what we refer as Computation Engine (CE).
>
>  Currently the noc_block_addsub.v file has USE_HLS = 0. Does this mean
> it isn't using the HLS sources?
>
> It is not doing so by default, but using the verilog sources (which in
> this case are also provided). For the noc_block_addsub to use the HLS, the
> parameter has to be set to true in the rfnoc_ce_auto_inst file at its
> instantiation with something like:
>
> noc_block_addsub #( USE_HLS=1) inst_noc_block_addsub (...);
>
> You don't have to have this in every block if you are only using one type
> of sources. You can base your design for the noc block file on the
> rfnoc/lib/noc_block_skeleton.v, where the place where the user IP is to
> be put is marked with comments.
>
> TL;DR: You are writing your IP (module) in HLS, but you need to put it
> into the Computation Engine to use the block in the RFNoC Framework
>
> Cheers,
> - N
>
>
> [1] https://www.ettus.com/content/files/RFNoC_Wireless_at_VT_FPGA.pdf
> [2] https://kb.ettus.com/Getting_Started_with_RFNoC_Development
>
> On Wed, Dec 7, 2016 at 11:47 AM, Vishwesh Rege 
> wrote:
>
>> Hi,
>>
>> No I haven't added noc_block_fir.v file. Am I supposed to add it in
>> lib/rfnoc folder along with other files such as noc_block_addsub.v? Also is
>> there any guide on how to write this file?
>>
>> I didn't get your last line
>> "and the way it uses to choose if the sources that it is going to use
>> (either .v or hls) is done by the parameter "USE_HLS". In case you haven't
>> done this, you may want to add the noc_block*, or maybe modify the
>> noc_block_fir_filter.v to add the USE_HLS in there."
>>
>> Currently the noc_block_addsub.v file has USE_HLS = 0. Does this mean it
>> isn't using the HLS sources?
>>
>> Just to clarify, I want to add my own custom 'fir' block written in HLS,
>> I don't want to use the existing noc_block_fir_filter block.
>>
>> Appreciate your feedback
>>
>> Thanks,
>> Vishwesh
>>
>>
>>
>> On Wed, Dec 7, 2016 at 2:29 AM, Nicolas Cuervo 
>> wrote:
>>
>>> HI Vishwesh,
>>>
>>> For the first part, yes, please only add noc_block elements into the
>>> auto inst file.
>>>
>>> For the second part, if you add that like into the
>>> lib/rfnoc/Makefile.srcs you are telling the build system that you added
>>> verilog sources with that name. Given that you are using HLS for that, that
>>> may be the source of that error response.
>>>
>>>  So I added the line "noc_block_fir.v \" to the
>>> lib/rfnoc/Makefile.srcs file
>>>
>>> Now, it is saying that it can not find the noc_block_fir.v. Just as a
>>> sanity check: did you add a noc_block_fir.v file? I just ask to be sure, as
>>> you didn't explicitly say that in your email and that may be the source of
>>> the issue. The HLS sources will add the core functionality for your block,
>>> but the noc_block_*.v has functions such as the AXI wrapping and
>>> interfacing with the crossbar. Going back to the addsub example, you can
>>> see that it also has a noc_block_addsub.v, and the way it uses to choose if
>>> the sources that it is going to use (either .v or hls) is done by the
>>> parameter "USE_HLS". In case you haven't done this, you may want to add the
>>> noc_block*, or maybe modify the noc_block_fi

Re: [Discuss-gnuradio] Add RFNoC FIFO

[Nicolas Cuervo]

Hi Vishwesh,

Please take a look at [1] which is not-that-new reference, but the idea is
still the same (this reference can be also found in the getting started
guide [2] which at the end has links to the videos of the presentation that
uses this slides). Specifically at slide 7. The noc_block_* is doing
several tasks, and for a start, regardless of the application, you'd focus
on the "user IP", which is the part that you are going to add and that will
perform your design task. In the case of addsub, clearly, it adds and
subtracts. You can check the addsub_hls to see that the functionality is
simple and rather obvious. Now this simple IP is inside the noc_block,
which sets registers, translates the AXI stream into chdr packets (AXI
wrapper) and prepares everything necessary for your block to be used in the
RFNoC framework, which is a huge task (Luckily, you dont have to worry much
about this for now). You can see that this is not to in HLS, but in
verilog.

Your IP can be written in HLS, VHDL or verilog, but you need to put it
inside de noc_block; the whole is what we refer as Computation Engine (CE).

 Currently the noc_block_addsub.v file has USE_HLS = 0. Does this mean
it isn't using the HLS sources?

It is not doing so by default, but using the verilog sources (which in this
case are also provided). For the noc_block_addsub to use the HLS, the
parameter has to be set to true in the rfnoc_ce_auto_inst file at its
instantiation with something like:

noc_block_addsub #( USE_HLS=1) inst_noc_block_addsub (...);

You don't have to have this in every block if you are only using one type
of sources. You can base your design for the noc block file on the
rfnoc/lib/noc_block_skeleton.v, where the place where the user IP is to be
put is marked with comments.

TL;DR: You are writing your IP (module) in HLS, but you need to put it into
the Computation Engine to use the block in the RFNoC Framework

Cheers,
- N


[1] https://www.ettus.com/content/files/RFNoC_Wireless_at_VT_FPGA.pdf
[2] https://kb.ettus.com/Getting_Started_with_RFNoC_Development

On Wed, Dec 7, 2016 at 11:47 AM, Vishwesh Rege  wrote:

> Hi,
>
> No I haven't added noc_block_fir.v file. Am I supposed to add it in
> lib/rfnoc folder along with other files such as noc_block_addsub.v? Also is
> there any guide on how to write this file?
>
> I didn't get your last line
> "and the way it uses to choose if the sources that it is going to use
> (either .v or hls) is done by the parameter "USE_HLS". In case you haven't
> done this, you may want to add the noc_block*, or maybe modify the
> noc_block_fir_filter.v to add the USE_HLS in there."
>
> Currently the noc_block_addsub.v file has USE_HLS = 0. Does this mean it
> isn't using the HLS sources?
>
> Just to clarify, I want to add my own custom 'fir' block written in HLS, I
> don't want to use the existing noc_block_fir_filter block.
>
> Appreciate your feedback
>
> Thanks,
> Vishwesh
>
>
>
> On Wed, Dec 7, 2016 at 2:29 AM, Nicolas Cuervo 
> wrote:
>
>> HI Vishwesh,
>>
>> For the first part, yes, please only add noc_block elements into the auto
>> inst file.
>>
>> For the second part, if you add that like into the
>> lib/rfnoc/Makefile.srcs you are telling the build system that you added
>> verilog sources with that name. Given that you are using HLS for that, that
>> may be the source of that error response.
>>
>>  So I added the line "noc_block_fir.v \" to the
>> lib/rfnoc/Makefile.srcs file
>>
>> Now, it is saying that it can not find the noc_block_fir.v. Just as a
>> sanity check: did you add a noc_block_fir.v file? I just ask to be sure, as
>> you didn't explicitly say that in your email and that may be the source of
>> the issue. The HLS sources will add the core functionality for your block,
>> but the noc_block_*.v has functions such as the AXI wrapping and
>> interfacing with the crossbar. Going back to the addsub example, you can
>> see that it also has a noc_block_addsub.v, and the way it uses to choose if
>> the sources that it is going to use (either .v or hls) is done by the
>> parameter "USE_HLS". In case you haven't done this, you may want to add the
>> noc_block*, or maybe modify the noc_block_fir_filter.v to add the USE_HLS
>> in there.
>>
>> If you indeed have done what I just said, please let us know so that we
>> can check what else is going on.
>>
>> Cheers,
>> - N
>>
>>
>>
>> On Wed, Dec 7, 2016 at 10:51 AM, Vishwesh Rege 
>> wrote:
>>
>>> Hi,
>>>
>>> Thanks for the detailed reply.
>>>
>>> >>From these I could add noc_block_digital_gain (built successfully)
>>> >>but couldn't add chdr_fifo_large (running make X310_RFNOC_HLS_HG
>>> gave an error)
>>>
>>> Could you please tell us what error did it throw?
>>>
>>> I inserted the following code in rfnoc_ce_auto_inst_x310.v file to add
>>> chdr_fifo_large:
>>>
>>>
>>>
>>>
>>>
>>>
>>> *chdr_fifo_large
>>> inst_chdr_fifo_la

Re: [Discuss-gnuradio] Add RFNoC FIFO

[Vishwesh Rege]

Hi,

No I haven't added noc_block_fir.v file. Am I supposed to add it in
lib/rfnoc folder along with other files such as noc_block_addsub.v? Also is
there any guide on how to write this file?

I didn't get your last line
"and the way it uses to choose if the sources that it is going to use
(either .v or hls) is done by the parameter "USE_HLS". In case you haven't
done this, you may want to add the noc_block*, or maybe modify the
noc_block_fir_filter.v to add the USE_HLS in there."

Currently the noc_block_addsub.v file has USE_HLS = 0. Does this mean it
isn't using the HLS sources?

Just to clarify, I want to add my own custom 'fir' block written in HLS, I
don't want to use the existing noc_block_fir_filter block.

Appreciate your feedback

Thanks,
Vishwesh



On Wed, Dec 7, 2016 at 2:29 AM, Nicolas Cuervo 
wrote:

> HI Vishwesh,
>
> For the first part, yes, please only add noc_block elements into the auto
> inst file.
>
> For the second part, if you add that like into the lib/rfnoc/Makefile.srcs
> you are telling the build system that you added verilog sources with that
> name. Given that you are using HLS for that, that may be the source of that
> error response.
>
>  So I added the line "noc_block_fir.v \" to the
> lib/rfnoc/Makefile.srcs file
>
> Now, it is saying that it can not find the noc_block_fir.v. Just as a
> sanity check: did you add a noc_block_fir.v file? I just ask to be sure, as
> you didn't explicitly say that in your email and that may be the source of
> the issue. The HLS sources will add the core functionality for your block,
> but the noc_block_*.v has functions such as the AXI wrapping and
> interfacing with the crossbar. Going back to the addsub example, you can
> see that it also has a noc_block_addsub.v, and the way it uses to choose if
> the sources that it is going to use (either .v or hls) is done by the
> parameter "USE_HLS". In case you haven't done this, you may want to add the
> noc_block*, or maybe modify the noc_block_fir_filter.v to add the USE_HLS
> in there.
>
> If you indeed have done what I just said, please let us know so that we
> can check what else is going on.
>
> Cheers,
> - N
>
>
>
> On Wed, Dec 7, 2016 at 10:51 AM, Vishwesh Rege 
> wrote:
>
>> Hi,
>>
>> Thanks for the detailed reply.
>>
>> >>From these I could add noc_block_digital_gain (built successfully)
>> >>but couldn't add chdr_fifo_large (running make X310_RFNOC_HLS_HG
>> gave an error)
>>
>> Could you please tell us what error did it throw?
>>
>> I inserted the following code in rfnoc_ce_auto_inst_x310.v file to add
>> chdr_fifo_large:
>>
>>
>>
>>
>>
>>
>> *chdr_fifo_large
>> inst_chdr_fifo_large (.bus_clk(bus_clk), .bus_rst(bus_rst),
>> .ce_clk(ce_clk), .ce_rst(ce_rst),.i_tdata(ce_o_tdata[5]),
>> .i_tlast(ce_o_tlast[5]), .i_tvalid(ce_o_tvalid[5]),
>> .i_tready(ce_o_tready[5]),.o_tdata(ce_i_tdata[5]),
>> .o_tlast(ce_i_tlast[5]), .o_tvalid(ce_i_tvalid[5]),
>> .o_tready(ce_i_tready[5]),.debug(ce_debug[5]));*
>> 
>> 
>>
>> From your reply I gather that I cannot add chdr_fifo_large block (since
>> only blocks starting with "noc_block_" are allowed) but following is the
>> error I got:
>> 
>> 
>> 
>> 
>> INFO: [Synth 8-256] done synthesizing module
>> 'chdr_fifo_large__parameterized0' (170#1) [/home/vrege/rfnoc/src/uhd-fpg
>> a/usrp3_rfnoc/lib/rfnoc/chdr_fifo_large.v:5]
>> ERROR: [Synth 8-448] named port connection 'bus_clk' does not exist for
>> instance 'inst_chdr_fifo_large' of module 'chdr_fifo_large'
>> [/home/vrege/rfnoc/src/uhd-fpga/usrp3_rfnoc/top/x300/rfnoc_
>> ce_auto_inst_x310.v:56]
>> ERROR: [Synth 8-448] named port connection 'bus_rst' does not exist for
>> instance 'inst_chdr_fifo_large' of module 'chdr_fifo_large'
>> [/home/vrege/rfnoc/src/uhd-fpga/usrp3_rfnoc/top/x300/rfnoc_
>> ce_auto_inst_x310.v:56]
>> ERROR: [Synth 8-448] named port connection 'ce_clk' does not exist for
>> instance 'inst_chdr_fifo_large' of module 'chdr_fifo_large'
>> [/home/vrege/rfnoc/src/uhd-fpga/usrp3_rfnoc/top/x300/rfnoc_
>> ce_auto_inst_x310.v:57]
>> ERROR: [Synth 8-448] named port connection 'ce_rst' does not exist for
>> instance 'inst_chdr_fifo_large' of module 'chdr_fifo_large'
>> [/home/vrege/rfnoc/src/uhd-fpga/usrp3_rfnoc/top/x300/rfnoc_
>> ce_auto_inst_x310.v:57]
>> ERROR: [Synth 8-448] named port connection 'debug' does not exist for
>> instance 'inst_chdr_fifo_large' of module 'chdr_fifo_large'
>> [/home/vrege/rfnoc/src/uhd-fpga/usrp3_rfnoc/top/x300/rfnoc_
>> ce_auto_inst_x310.v:60]
>> ...
>> ERROR: [Synth 8-285] failed synthesizing module
>> 'synchronizer_impl__parameterized0' [/h

Re: [Discuss-gnuradio] Add RFNoC FIFO

[Nicolas Cuervo]

HI Vishwesh,

For the first part, yes, please only add noc_block elements into the auto
inst file.

For the second part, if you add that like into the lib/rfnoc/Makefile.srcs
you are telling the build system that you added verilog sources with that
name. Given that you are using HLS for that, that may be the source of that
error response.

 So I added the line "noc_block_fir.v \" to the lib/rfnoc/Makefile.srcs
file

Now, it is saying that it can not find the noc_block_fir.v. Just as a
sanity check: did you add a noc_block_fir.v file? I just ask to be sure, as
you didn't explicitly say that in your email and that may be the source of
the issue. The HLS sources will add the core functionality for your block,
but the noc_block_*.v has functions such as the AXI wrapping and
interfacing with the crossbar. Going back to the addsub example, you can
see that it also has a noc_block_addsub.v, and the way it uses to choose if
the sources that it is going to use (either .v or hls) is done by the
parameter "USE_HLS". In case you haven't done this, you may want to add the
noc_block*, or maybe modify the noc_block_fir_filter.v to add the USE_HLS
in there.

If you indeed have done what I just said, please let us know so that we can
check what else is going on.

Cheers,
- N



On Wed, Dec 7, 2016 at 10:51 AM, Vishwesh Rege  wrote:

> Hi,
>
> Thanks for the detailed reply.
>
> >>From these I could add noc_block_digital_gain (built successfully)
> >>but couldn't add chdr_fifo_large (running make X310_RFNOC_HLS_HG
> gave an error)
>
> Could you please tell us what error did it throw?
>
> I inserted the following code in rfnoc_ce_auto_inst_x310.v file to add
> chdr_fifo_large:
>
>
>
>
>
>
> *chdr_fifo_large
> inst_chdr_fifo_large (.bus_clk(bus_clk), .bus_rst(bus_rst),
> .ce_clk(ce_clk), .ce_rst(ce_rst),.i_tdata(ce_o_tdata[5]),
> .i_tlast(ce_o_tlast[5]), .i_tvalid(ce_o_tvalid[5]),
> .i_tready(ce_o_tready[5]),.o_tdata(ce_i_tdata[5]),
> .o_tlast(ce_i_tlast[5]), .o_tvalid(ce_i_tvalid[5]),
> .o_tready(ce_i_tready[5]),.debug(ce_debug[5]));*
> 
> 
>
> From your reply I gather that I cannot add chdr_fifo_large block (since
> only blocks starting with "noc_block_" are allowed) but following is the
> error I got:
> 
> 
> 
> 
> INFO: [Synth 8-256] done synthesizing module 'chdr_fifo_large__parameterized0'
> (170#1) [/home/vrege/rfnoc/src/uhd-fpga/usrp3_rfnoc/lib/rfnoc/
> chdr_fifo_large.v:5]
> ERROR: [Synth 8-448] named port connection 'bus_clk' does not exist for
> instance 'inst_chdr_fifo_large' of module 'chdr_fifo_large'
> [/home/vrege/rfnoc/src/uhd-fpga/usrp3_rfnoc/top/x300/
> rfnoc_ce_auto_inst_x310.v:56]
> ERROR: [Synth 8-448] named port connection 'bus_rst' does not exist for
> instance 'inst_chdr_fifo_large' of module 'chdr_fifo_large'
> [/home/vrege/rfnoc/src/uhd-fpga/usrp3_rfnoc/top/x300/
> rfnoc_ce_auto_inst_x310.v:56]
> ERROR: [Synth 8-448] named port connection 'ce_clk' does not exist for
> instance 'inst_chdr_fifo_large' of module 'chdr_fifo_large'
> [/home/vrege/rfnoc/src/uhd-fpga/usrp3_rfnoc/top/x300/
> rfnoc_ce_auto_inst_x310.v:57]
> ERROR: [Synth 8-448] named port connection 'ce_rst' does not exist for
> instance 'inst_chdr_fifo_large' of module 'chdr_fifo_large'
> [/home/vrege/rfnoc/src/uhd-fpga/usrp3_rfnoc/top/x300/
> rfnoc_ce_auto_inst_x310.v:57]
> ERROR: [Synth 8-448] named port connection 'debug' does not exist for
> instance 'inst_chdr_fifo_large' of module 'chdr_fifo_large'
> [/home/vrege/rfnoc/src/uhd-fpga/usrp3_rfnoc/top/x300/
> rfnoc_ce_auto_inst_x310.v:60]
> ...
> ERROR: [Synth 8-285] failed synthesizing module 
> 'synchronizer_impl__parameterized0'
> [/home/vrege/rfnoc/src/uhd-fpga/usrp3_rfnoc/lib/control/
> synchronizer_impl.v:5]
> ERROR: [Synth 8-285] failed synthesizing module
> 'synchronizer__parameterized0' [/home/vrege/rfnoc/src/uhd-
> fpga/usrp3_rfnoc/lib/control/synchronizer.v:5]
> ERROR: [Synth 8-285] failed synthesizing module 'x300_core'
> [/home/vrege/rfnoc/src/uhd-fpga/usrp3_rfnoc/top/x300/x300_core.v:2]
> ERROR: [Synth 8-285] failed synthesizing module 'x300'
> [/home/vrege/rfnoc/src/uhd-fpga/usrp3_rfnoc/top/x300/x300.v:15]
> 
> 
> 
> 
>
> In that directory there is an 'addsub' block written in HLS as an
> example.
>
> I want to actually add a custom 'fir' block that I have written in HLS to
> the built image.
> So I created another fir_hls directory in the lib/hls fol

Re: [Discuss-gnuradio] Add RFNoC FIFO

[Vishwesh Rege]

Hi,

Thanks for the detailed reply.

>>From these I could add noc_block_digital_gain (built successfully)
>>but couldn't add chdr_fifo_large (running make X310_RFNOC_HLS_HG gave
an error)

Could you please tell us what error did it throw?

I inserted the following code in rfnoc_ce_auto_inst_x310.v file to add
chdr_fifo_large:






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


>From your reply I gather that I cannot add chdr_fifo_large block (since
only blocks starting with "noc_block_" are allowed) but following is the
error I got:

INFO: [Synth 8-256] done synthesizing module
'chdr_fifo_large__parameterized0' (170#1)
[/home/vrege/rfnoc/src/uhd-fpga/usrp3_rfnoc/lib/rfnoc/chdr_fifo_large.v:5]
ERROR: [Synth 8-448] named port connection 'bus_clk' does not exist for
instance 'inst_chdr_fifo_large' of module 'chdr_fifo_large'
[/home/vrege/rfnoc/src/uhd-fpga/usrp3_rfnoc/top/x300/rfnoc_ce_auto_inst_x310.v:56]
ERROR: [Synth 8-448] named port connection 'bus_rst' does not exist for
instance 'inst_chdr_fifo_large' of module 'chdr_fifo_large'
[/home/vrege/rfnoc/src/uhd-fpga/usrp3_rfnoc/top/x300/rfnoc_ce_auto_inst_x310.v:56]
ERROR: [Synth 8-448] named port connection 'ce_clk' does not exist for
instance 'inst_chdr_fifo_large' of module 'chdr_fifo_large'
[/home/vrege/rfnoc/src/uhd-fpga/usrp3_rfnoc/top/x300/rfnoc_ce_auto_inst_x310.v:57]
ERROR: [Synth 8-448] named port connection 'ce_rst' does not exist for
instance 'inst_chdr_fifo_large' of module 'chdr_fifo_large'
[/home/vrege/rfnoc/src/uhd-fpga/usrp3_rfnoc/top/x300/rfnoc_ce_auto_inst_x310.v:57]
ERROR: [Synth 8-448] named port connection 'debug' does not exist for
instance 'inst_chdr_fifo_large' of module 'chdr_fifo_large'
[/home/vrege/rfnoc/src/uhd-fpga/usrp3_rfnoc/top/x300/rfnoc_ce_auto_inst_x310.v:60]
...
ERROR: [Synth 8-285] failed synthesizing module
'synchronizer_impl__parameterized0'
[/home/vrege/rfnoc/src/uhd-fpga/usrp3_rfnoc/lib/control/synchronizer_impl.v:5]
ERROR: [Synth 8-285] failed synthesizing module
'synchronizer__parameterized0'
[/home/vrege/rfnoc/src/uhd-fpga/usrp3_rfnoc/lib/control/synchronizer.v:5]
ERROR: [Synth 8-285] failed synthesizing module 'x300_core'
[/home/vrege/rfnoc/src/uhd-fpga/usrp3_rfnoc/top/x300/x300_core.v:2]
ERROR: [Synth 8-285] failed synthesizing module 'x300'
[/home/vrege/rfnoc/src/uhd-fpga/usrp3_rfnoc/top/x300/x300.v:15]


In that directory there is an 'addsub' block written in HLS as an
example.

I want to actually add a custom 'fir' block that I have written in HLS to
the built image.
So I created another fir_hls directory in the lib/hls folder using the
addsub_hls as an example with my own fir_hls.cpp, .tcl and Makefile.inc
I also modified the Makefile.inc in the lib/hls folder correspondingly.
Then I added "noc_block_fir" to the rfnoc_ce_auto_inst file.
On running make X310_RFNOC_HLS_HG I got the following error:

ERROR: [Synth 8-439] module 'noc_block_fir' not found
[/home/vrege/rfnoc/src/uhd-fpga/usrp3_rfnoc/top/x300/rfnoc_ce_auto_inst_x310.v:62]
ERROR: [Synth 8-285] failed synthesizing module 'x300_core'
[/home/vrege/rfnoc/src/uhd-fpga/usrp3_rfnoc/top/x300/x300_core.v:2]
ERROR: [Synth 8-285] failed synthesizing module 'x300'
[/home/vrege/rfnoc/src/uhd-fpga/usrp3_rfnoc/top/x300/x300.v:15]


So I added the line "noc_block_fir.v \" to the lib/rfnoc/Makefile.srcs file
But that gave another error:
make[1]: *** No rule to make target
`/home/vrege/rfnoc/src/uhd-fpga/usrp3_rfnoc/lib/rfnoc/noc_block_fir.v',
needed by `bin'.  Stop.

What changes do I need to make in the procedure to add my custom FIR block
to the image built by make?

Thanks,
Vishwesh




On Wed, Dec 7, 2016 at 12:16 AM, Nicolas Cuervo 
wrote:

> Hello Vikesh,
>
>

Re: [Discuss-gnuradio] Add RFNoC FIFO

[Nicolas Cuervo]

Hello Vikesh,

Please take a look at this section of our "Getting started with RFNoC
Development" guide, specifically the "wiring CE" section [1]. As Marcus
stated, NoC blocks start with "noc_block_", and this is the way to identify
them in the sources.

On 12/06/2016 10:37 PM, Vishwesh Rege wrote:
What are the list of blocks that I can add?

In that page that I just referenced there is a list of the current
noc_blocks provided by Ettus.

But what functionality do the other FIFOs provide (when am I supposed
to use them)?
chdr_fifo_large
noc_block_axi_dma_fifo
split_stream_fifo
ram_to_fifo ... etc.

Talking about "blocks' in a really general way, you'd only have to take in
consideration the 'noc_block_axi_dma_fifo". The others that you listed are
part of the library because the serve other functions at a lower level of
abstraction to generate the blocks that you are going to use directly in
your application.

Using the make.py approach:
From what I understand make.py only generates an output.v file right?
After running make.py do I have to copy the contents of the output.v file
to rfnoc_ce_auto_inst_x310.v?

No. make.py will take the blocks that you provided as parameters, and with
that it will generate your rfnoc_ce_auto_inst file and right after will
kick your bitstream build. The script only needs you to have vivado
installed, but you don't have to copy contents of files. It appears that
you gave the script the "-o output.v" option. This will generate a file
without kicking the build, but this option you'd use as a verification of
the file correctness. If you just skip this option, the
rfnoc_ce_auto_inst_x310.v file will be overwritten directly and your build
will start automatically.

From these I could add noc_block_digital_gain (built successfully)
but couldn't add chdr_fifo_large (running make X310_RFNOC_HLS_HG gave
an error)

Could you please tell us what error did it throw?

Finally what difference does it make if I run "make X310_RFNOC_HG"
versus "make X310_RFNOC_HLS_HG"

The X310_RFNOC_HLS_HG target uses "High Level Synthesis" to generate the
build. This is a way of generating hardware designs by the means of
software algorithms (i.e. you use C, C++ or SystemC to describe your
hardware, and the build system will translate that into hardware). By
selecting this target you are telling the build system that you wrote some
C/C++/SystemC code, located it at usrp3/lib/hls, and you want it to be part
of your design. In that directory there is an 'addsub' block written in HLS
as an example.

The X310_RFNOC_HG will synthesize your design using verilog sources.

Cheers,

- Nicolas

[1]
https://kb.ettus.com/Getting_Started_with_RFNoC_Development#Wiring_up_computation_engines_and_building_the_FPGA_image



On Tue, Dec 6, 2016 at 10:45 PM, Marcus Müller 
wrote:

> A NoC block should, as far as I can tell, always start with noc_block_.
>
>
> Best regards,
>
> Marcus
>
> On 12/06/2016 10:37 PM, Vishwesh Rege wrote:
>
> Hi,
>
> What are the list of blocks that I can add?
>
> For example,
> Looking at the list of blocks in usrp3_rfnoc/lib/rfnoc/Makefile.srcs
>
> From these I could add noc_block_digital_gain (built successfully)
> but couldn't add chdr_fifo_large (running make X310_RFNOC_HLS_HG gave an
> error)
>
> How do I know which blocks will work?
>
> For the error I'm getting in GRC "FIFO_0 block missing" I think
> noc_block_axi_fifo_loopback is probably the right one
> But what functionality do the other FIFOs provide (when am I supposed to
> use them)?
> chdr_fifo_large
> noc_block_axi_dma_fifo
> split_stream_fifo
> ram_to_fifo ... etc.
>
> Thanks,
> Vishwesh
>
> --
> To change the blocks, you need to edit rfnoc_ce_auto_inst_x310.v twice:
> You need to change NUM_CE (at the top), and then the actual block list.
>
> For FIFOs, you can go to the bottom and use the generate for loop to add
> more FIFOs.
>
> You can use make.py to autogenerate this file (in
> usrp3/tools/scripts/make.py).
>
> Cheers,
> Martin
>
> On 12/04/2016 05:55 PM, Vishwesh Rege wrote:
> > Hi,
> >
> > I want to add the FIFO block in usrp3_rfnoc/lib/fifo to USRP along with
> > the addsub module in usrp3_rfnoc/lib/hls folder.
> >
> > I'm running make X310_RFNOC_HLS_HG from usrp3_rfnoc/top/x300 directory
> > and then flashing the generated image in build/.
> >
> > However, the FIFO isn't included in the image for some reason. Only the
> > following RFNoC blocks are actually flashed:
> > | | | * DmaFIFO_0
> > | | | * Radio_0
> > | | | * Radio_1
> > | | | * AddSub_0
> > | | | * FIR_0
> > | | | * FFT_0
> > | | | * Window_0
> > | | | * NullSrcSink_0
> > | | | * SigGen_0
> > | | | * MovingAverage_0
> > | | | * VectorIIR_0
> > | | | * KeepOneInN_0
> > | | | * fosphor_0
> >
> > The Makefile usrp3_rfnoc/top/x300/Makefile.x300.inc already includes
> > FIFO_SRCS in DESIGN_SRCS
> >
> > Do I need to make any changes to include the FIFO?
> >
> > Any help is appreciated.
> >
> >
> >
> >
>
>
> ___