Hello,
Preface: When I checkout older RFNoC versions and using "rfnocmodtool
newmod" I also have to use the srcdir flag as suggested above in your
thread:
rfnocmodtool newmod [NAME OF THE MODULE] --srcdir
~/{USER_PREFIX}/src/gr-ettus/python/rfnoc_
modtool/rfnoc-newmod/
That works fine, but there are other problems I face after that:
Issue #1: I went through building the OOT "Gain" example from your "Getting
Started with RFNoC" knowledge base wiki. After doing "make install" in the
build directory and opening GNU Radio Companion, I do not see the Gain
block in the options list (confirms result I get with another custom OOT
block I'm working on).
Issue #2: When building the FPGA image of my custom OOT module using the
make command, I get this error:
Makefile.x300.inc:111: recipe for target 'bin' failed
make[1]: *** [bin] Error 1
Line 111 of Makefile.x300.inc looks like this:
# DESIGN_SRCS and VERILOG_DEFS must be defined
bin: .prereqs $$(DESIGN_SRCS) ip
$(call BUILD_VIVADO_DESIGN,$(abspath
./build_x300.tcl),$(TOP_MODULE),$(PART_ID))
In both issues #1 and #2 it looks like files aren't getting linked
properly for any OOT module. Before I start going into files and modifying
them, I'd like to know what you recommend for both issues (similar to the
rfnocmodtool's --srcdir solution I prefaced).
If it matters I am using these older versions (git hashes in parentheses)
of UHD (ec9138eb6634b0af106762832c7518c887576a94), gr-ettus
(22e1e3634c3f74fd9cbcf4162117a4765b781c60), GNU Radio
(a098720f430fae36fbd28d7e9c1548a1e6c4fdf4), and uhd-fpga
(b0890fa97ef3dc7d90ed8047d678ca280c72ad61). I need to use these versions to
do this full hardware loopback hack which I haven't found to work on newer
versions: https://corvid.io/2017/04/22/stupid-rfnoc-tricks-loopback/
V/R,
Andrew
On Thu, Jul 13, 2017 at 9:54 AM Nicolas Cuervo via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Hi Michael,
>
> if you are certain that having the templates for QA in either python or
> cpp (any specific language you are using from these two for the unit
> tests?) is useful for you (and potentially for other users), then I will
> push them back.
>
> From this discussion, I will also set a more descriptive warning then the
> "newmod" template is not found.
>
>
>
> On Thu, Jul 13, 2017 at 5:45 PM, Michael Wentz <mchlw...@gmail.com> wrote:
>
>> Hi Nicolas,
>>
>> Thanks for the feedback. Interesting since I had a few blocks with
>> underscores in the name and had just removed the underscore from the XML
>> that UHD uses.
>>
>> Regarding the QA tests, I tried porting some of the code I was using
>> before and am mostly getting 'timeout on chan 0' when using vector
>> source/sink to send test vectors through. In the past I had some success
>> with this, not only when using GR but with other tests I wrote using only
>> UHD. From my prospective it would definitely be nice to repeat the type of
>> tests I do in RTL simulation with hardware in the loop, i.e. doing a
>> loopback through the FPGA with signals generated from software.
>>
>> -Michael
>>
>> On Thu, Jul 13, 2017 at 7:18 AM, Nicolas Cuervo <nicolas.cue...@ettus.com
>> > wrote:
>>
>>> Hello Michael,
>>>
>>> It seems that 'import sys' is missing from the top of
>>>> gr-ettus/python/utils/rfnocmodtool
>>>>
>>> Yeah, this was known actually, and the fix is there. It just needs to be
>>> pushed public. We are sorry you had to face this.
>>>
>>>
>>>> After changing that, I ran into this problem:
>>>>
>>>> rfnocmodtool newmod test
>>>> Could not find rfnoc-newmod source dir
>>>>
>>>> It turns out that gr-ettus/modtool_newmod.py is not set up for people
>>>> that do not use PYBOMBS but do have a custom install prefix. All I had to
>>>> do was copy that over to PYBOMBS_PREFIX and then newmod worked. I would
>>>> have thought my install prefix would have been set up in any necessary
>>>> files during cmake?
>>>>
>>> The path hint that the modtool uses is PyBombs (as you correctly point
>>> out) and the common /usr/local/ and such. When the path is custom,
>>> rfnocmodtool requires the path of the newmod to be given with the
>>> "--srcdir" option.
>>>
>>> $ rfnocmodtool help newmod
>>> General options:
>>> .
>>> .
>>> .
>>> newmod:
>>> New out-of-tree module options
>>>
>>> --srcdir SRCDIR Source directory for the module template.
>>>
>>> Maybe a more descriptive "Could not find message" would be required,
>>> where it is said that the --srcdir option might be required to be
>>> explicitly given.
>>>
>>>
>>>> I was also wondering if there are reasons why underscores are not
>>>> allowed in block names
>>>>
>>> The underscores are not allowed in the names because we use them to
>>> designate block identifiers. This means, for example, that under the hood
>>> we refer to the "RFNoC: Radio" on channel 0 as 0/Radio_0 and so on. Given
>>> this, some naming that has underscores in it will lead to code
>>> mismatches and conflicts that could only be solved by code refactoring.
>>> This is the reason why we just added this constraint as a requirement.
>>>
>>>
>>> , and why the QA templates were removed (I liked using these to do tests
>>>> with hardware in the loop)?
>>>>
>>> We sincerely thought that no one was using this, as having hardware in
>>> the loop for, lets say, a python QA code, was not a trivial use case. If
>>> you are willing to elaborate on exactly how you are achieving this, we
>>> would not be against bringing the QA templates back.
>>>
>>> Regards,
>>> - Nicolas
>>>
>>>
>>>
>>>
>>>> -Michael
>>>>
>>>> _______________________________________________
>>>> 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
